次世代言語22 Go Nim Rust Swift Kotlin TypeScript

レス数が1000を超えています。これ以上書き込みはできません。
2021/08/22(日) 08:59:03.31ID:QorwbXcj
スレタイ以外の言語もok

前スレ
次世代言語21 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1587276362/
2021/08/22(日) 09:45:11.46ID:vEK5NNFF
スレタイの言語はNim以外はどれも現役世代だね
2021/08/22(日) 10:27:07.87ID:QorwbXcj
永遠に次世代？
4デフォルトの名無しさん
垢版 |
2021/08/22(日) 10:31:36.24ID:0Cz6ueFz
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴 バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412


Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
2021/08/22(日) 10:40:01.99ID:A59qHoiu
>>4
このコピペ難読性が高い
2021/08/22(日) 10:42:34.82ID:23z7MXhT
>>4
NimはGCがあるからC++やRustの立ち位置には立てないよ
2021/08/22(日) 11:47:58.60ID:F7Qbx3up
NimやるならGoでよくね？ってなる
2021/08/22(日) 12:02:38.26ID:TsBps+dy
▼スレタイランキング
1位：Rust（21回 Part1～）
2位：Go（15回 Part1～）
3位：Kotolin（14回 Part4～）
4位：TypeScript（14回 Part7～）
5位：Swift（10回 Part7～）
6位：Haskell（7回 Part7～）
7位：Scale（5回 Part1～）
8位：Elixir（4回 Part1～）
9位：Dart（3回 Part9～）
10位：Julia（3回 Part14～）
11位：Erlang（2回 Part1～）
12位：Nim（2回 Part21～）
13位：Crystal（1回 Part14～）
14位：Bosque（1回 Part17～）
15位：V（1回 Part19～）
2021/08/22(日) 12:03:30.88
>>8
説明を求めます
2021/08/22(日) 12:09:40.80ID:TsBps+dy
>>9
このスレのスレタイに入ってる言語はスレを立てる人が次世代だと思う言語を自由に入れていい
このランキングはスレタイに入った言語を集計したもの
○○回は入った回数、Part○～は初出のスレ番号
11デフォルトの名無しさん
垢版 |
2021/08/22(日) 12:13:56.42ID:0Cz6ueFz
>>970

マクロのシンタックスを別で覚える必要がない
Rust のマクロは構文が全く変わってしまいます。
そしてそれは脳が全力で受付を拒否する素敵な仕上がりとなっております。
公式で自ら「マクロベースのコードの欠点は、組み込みルールの少なさに
由来するそのコードの理解のしづらさです。」と言いのけちゃう代物で
「なんじゃそりゃ」と言う言葉しか出ません。

Nim は構文がそのまま使えます。なので強力なマクロを使いこなすための
障壁の低さは比べ物になりません。
2021/08/22(日) 12:18:13.68ID:pVXVequb
>>7
NimのライバルはGoやね
13デフォルトの名無しさん
垢版 |
2021/08/22(日) 12:31:26.49ID:0Cz6ueFz
>>970

Rust の良いところ
さすがに Rust を批判ばかりしていては公平性に欠ける報道となり官邸から怒られます。
Rust にも良いところはあります。

fn <- 短い！

proc <- 長い！

これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。
2021/08/22(日) 12:43:28.59ID:9KEf5rUH
>>13
まともなプログラマーはタイプ数を気にすることはない
それよりも目的毎の機能性質で使い分ける
functionと長い言語もあればCやshのように0文字の言語もあるがタイプ数で何かを決めることはない
15デフォルトの名無しさん
垢版 |
2021/08/22(日) 13:54:26.77ID:cx6/dnxW
Cで充分
2021/08/22(日) 14:45:49.07ID:1RKLPni9
func を fn とするだけで開発効率が上がると思ってとかどうしようもない馬鹿だろ。
2021/08/22(日) 14:48:48.39ID:1fJ/nSvN
Nimの最新のガベージコレクタARC(Automatic Reference Counting)は参照カウンタ方式でRustのRc<T>やC++のstd::shared_ptr<T>と似たようなもの。
C++のshared_ptrと違ってカウンタはatomic intじゃないので複数スレッドから共有はできないけど高速にカウントを増減できる。
Move semanticsによって余計なコピーが発生しない。
変数が不要にったところに自動的にデストラクタが挿入されるのでメモリが解放されるタイミングは決定論的に決まる。
(他の言語のガベージコレクタのように実行するたびに違うタイミングでメモリが解放されることはない)

前スレで勘違いされていたけど、NimのView typesやRustのボローチェッカーって
スタックから消された変数とか解放されたヒープを間違って参照したり書き込んだりを
防ぐものでメモリリークを防ぐものではない。
Nimはガーベージコレクタ、Rustはスコープから出たらメモリ解放するとか参照カウンタを使って
メモリリークしないようにしている。

NimでARCを使っておけばガベージコレクタのコストは参照カウントの増減だけなので
パフォーマンスに影響することは殆どない。
NimをGC無しで使う必要性はほんどない。

Nimを組み込みに使っている人もいる。
2021/08/22(日) 14:51:17.95ID:1fJ/nSvN
NimのARCに関する情報
nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html

Nimを組み込みに使っているプロジェクト
github.com/PMunch/badger
github.com/exelotl/natu
github.com/clj/nim-esp8266-examples
2021/08/22(日) 16:20:01.00ID:5RAXclM6
結論
NimをGC無しにすることは不可能
つまりC/C++/Rustの代わりに用いることはできない
2021/08/22(日) 17:01:59.91ID:emx92kjF
Cはスタックを無しにすることは不可能
つまりアセンブラの代わりに用いることはできない
2021/08/22(日) 17:11:25.30ID:BUYgKjYJ
>>17
嘘つき
参照カウンタ方式はコストが高いので、
Rustでは必要最小限の部分でのみ、プログラマーが明示的にRc型(Reference counter型)を指定した時だけ使われます。
Rustでは通常時は参照カウンタなんて使われません。もっと高速に動作します。
22デフォルトの名無しさん
垢版 |
2021/08/22(日) 17:36:42.19ID:0Cz6ueFz
>>4

技術書典に出会っていなかったら俺はNimをさわってないと思う

背景
俺たち「そろそろ技術書典に参戦するか」
俺たち「何書く？」
俺たち「マイナー言語を触ってみよう。言語選択は早い者勝ちね」
ワイ「(マイナーの定義はさておき)Nimでオナシャス」
ワイ「(アドカレあるし、記事まとめておくかぁ...)」

Nimとは？
Nim は アンドレアス・ランプフ氏によって設計・開発された命令型、マルチパラダイム、
コンパイル言語という特徴を持つプログラミング言語です。

アンドレアス・ランプフ氏は3DICC社に所属するエンジニアです。彼はNim開発以前に様々
な言語を触っていたようです。が、どの言語も満足せず、自身で作成することにしたようです。
それがNimプロジェクトの始まりで、2005年頃のようでした。

当初NiｍはNimrod(旧約聖書の登場人物)という名前でしたが、マーケティング上の理由から
2014年12月29日にリリースされたバージョン 0.10.2 からNimに変更されました。
2021/08/22(日) 17:38:20.64ID:9u04hent
Nim ARCは全て参照カウンタ方式になってしまうからパフォーマンスに影響が出て不利だね
2021/08/22(日) 17:58:26.12ID:sVqTe99t
Rustでグラフ構造を作れないとか言いそうな奴に
ARCでグラフを作らせたら駄目だろ常識的に考えて
25デフォルトの名無しさん
垢版 |
2021/08/22(日) 20:28:01.36ID:A59qHoiu
>>20
ちょっと意味が分からない
2021/08/22(日) 21:04:38.19ID:+3UN9nhX
つまりレジスタだけ使ってのプログラムってことだろ。
そんなんやる必要ほとんどないが。
2021/08/22(日) 21:13:45.05ID:nqrywZna
本当に知らない人のために言うと、全部ブログ記事のパクリ
なので相手にしてもマトモなレスが返ってこない。無視で良いよ
28デフォルトの名無しさん
垢版 |
2021/08/22(日) 21:21:33.85ID:0Cz6ueFz
>>4

Nimの特徴
直感的でわかりやすいシンタックス
公式サイトの記載からNimの特徴を見てみましょう。

以下は公式サイトに掲載されているNimのコード例です。

Nimの最初の特徴して挙げられているのが、そのシンタックスで、曰く「直感的でわかりやすい」とのことです。
Python(のインデントを含めた多くの特徴)やPascalを参考にしているらしいので似ていると思いますが、シンプルですね。

import strformat
type
Person = object
name*: string # Field is exported using `*`.
age: Natural # Natural type ensures the age is positive.

var people = [
Person(name: "John", age: 45),
Person(name: "Kate", age: 30)
]

for person in people:
# Type-safe string interpolation.
echo(fmt"{person.name} is {person.age} years old")
29デフォルトの名無しさん
垢版 |
2021/08/22(日) 21:27:47.34ID:A59qHoiu
>>26
アセンブラだってスタック使うでしょ？
2021/08/22(日) 22:19:09.36ID:8ga57bIU
>>29
組込みだとRAMチェックが終わるまではスタック使わないとか普通にあったりする
31デフォルトの名無しさん
垢版 |
2021/08/22(日) 23:42:29.56ID:A59qHoiu
>>30
ほー、なるほどね
だからって>20はおかしいよね
2021/08/23(月) 00:53:35.51ID:dRBSj4mI
アセンブラは型がない
アセンブラだけで作ったライブラリも可読性のためにはCの型を宣言する
宣言したらもうCのライブラリとして利用可能にするだろ常識的に

つまり旧世代言語のコードを減らすとかいうおかしな目的意識の代わりに
ライブラリを増やすという適切な意図がある
2021/08/23(月) 01:09:17.02ID:PPErbdyj
そこはCもC++もRustも同じでアセンブリ含めて相互に呼び出し可能
だったらコンパイル通った時点でメモリ安全性を保証できるRustで基本的に書いてどうしても必要な部分のみアセンブリというのが現在の流れ
2021/08/23(月) 03:28:42.97ID:UerQU9YF
型付けアセンブリ言語という研究かなり昔にあったよね？
どうなったの
2021/08/23(月) 05:35:18.87ID:js8xmVB9
>>31
おかしくないよ、そういうコードはアセンブラでないと書けないから
2021/08/23(月) 05:39:50.18
一応 MASM には型はありますが？
2021/08/23(月) 06:59:34.18ID:53a1qHWJ
>>34
masm とかでも構造体を定義できたりするけどやればやるほどC言語で良くね？とかなりがち
38デフォルトの名無しさん
垢版 |
2021/08/23(月) 13:47:20.63ID:Rq8RLuIS
どうせWEB屋が好きな/使ってみたい言語ランキングでしょ
39デフォルトの名無しさん
垢版 |
2021/08/23(月) 18:03:58.81ID:Rrt4HCug
nim もっとカッコイイ名前が良かった
julia よりマシだが
2021/08/23(月) 18:27:25.22ID:w0EZLKOJ
GoもRustもNimもJuliaも検索性わるすぎるんよー
2021/08/23(月) 19:25:50.37ID:zx6dvezD
Cは？
42デフォルトの名無しさん
垢版 |
2021/08/23(月) 21:15:07.01ID:4kP0uHrS
>>35
せいぜいCで代替できないケースもある、だな
「代用不可」は言い過ぎ
2021/08/23(月) 21:19:05.15ID:Rok9YfeI
C/C++/Rustは中でアセンブリ書けるので大丈夫
どうしても必要な部分がある時は使われている
2021/08/23(月) 21:38:44.27ID:7bphh6MO
>>42
スタック無しが要件なら代替不可
そうでないならあんたの言う通り
2021/08/23(月) 22:01:28.04ID:S3FojqMf
>>39
G. M. Julia 「……」
https://ja.wikipedia.org/wiki/%E3%82%AC%E3%82%B9%E3%83%88%E3%83%B3%E3%83%BB%E3%82%B8%E3%83%A5%E3%83%AA%E3%82%A2
2021/08/23(月) 23:23:44.42ID:A8ur8654
>>34
それに近いのがllvm ir
2021/08/24(火) 00:13:51.84ID:+0eKMgme
wasmとllvmって
どうしても必要とは言えない所でアセンブラ使ってるよな
48デフォルトの名無しさん
垢版 |
2021/08/24(火) 01:00:35.96ID:Fpbrw/6U
>>44
もうトートロジーに陥ってるじゃん…
無理しないで>20は命題として偽だって認めなよ
2021/08/24(火) 05:37:31.25ID:IO38Iq2z
>>48
ああ、それでいいんじゃね？
別にお前がそう思うのは自由だし
2021/08/24(火) 06:23:15.51ID:hoyVPhaC
>>21
>>23
NimはGCがあるから遅いと言っている人はNimではすべての変数がヒープ上に確保されると勘違いしているのでは。
基本的にはNimでヒープが確保されるのは組み込み型のstring、seq[T]とref型とクロージャがキャプチャした変数を入れるenvironmentだけ。
seqはC++のstd::vector, Rustのstd::vecに相当するもの。
最適化で実際にはヒープに格納されない場合もある。
C/C++/Rustと同様に関数内でvar x = 1と書いたらその変数はスタックに作られる。

以下のコードのようにobject型をrefをつけずに作るとヒープは確保されない。
NimとC++でCircleオブジェクトとPointオブジェクトを作って与えられた点が円の内側にあるかどうかテストするプログラムを作った。
最適化をオンにするとNimもC++と同様にtestCodeはレジスタだけを使って計算するコードを出力している。
godbolt.org/z/fG7cbcq8P
godbolt.org/z/G7Yf6nd34

以下のコードでは変数名sでseq[Circle]を作っている。
seq[Circle]はヒープにオブジェクトを格納するがCircleオブジェクトのデータはヒープ上に連続して格納される。
なのでseq[Circle]のヒープのアドレスを無理やりfloat配列へのアドレスにキャストするとCircleの内容を見ることができる。
wandbox.org/permlink/AiTKGe0YPkryduPB
2021/08/24(火) 06:24:41.13ID:hoyVPhaC
このリポジトリではレイトレーサーを様々なプログラミング言語で実装し
実行速度を比較してるがNimが一番速い。
また行数も比較的短い。
github.com/edin/raytracer

こちらでは単語の数を数えるプログラムを様々なプログラミング言語で実装し
実行速度を比較してる。
github.com/benhoyt/countwords
結果として簡単に書いたプログラムではNimのほうがRustより速くなり
最適化したコードではNimがRustより僅かに遅くなる程度。
benhoyt.com/writings/count-words/#performance-results-and-learnings

簡単に再帰関数でフィボナッチ数列を計算するNimとRustのコードを書いてみたんだが
Rustのほうが遅い。
オーバーフローチェック有
Nim 287ミリ秒
wandbox.org/permlink/eHu9IOiFfhMUY66y
Rust 376ミリ秒
wandbox.org/permlink/SHxQij4aj9pYFUZn
オーバーフローチェック無し
Nim 187ミリ秒
wandbox.org/permlink/KM2XOoSHLO9Oy5Rx
Rust 300ミリ秒
wandbox.org/permlink/6SQgnE1rPcUqzfZK
2021/08/24(火) 09:08:23.82ID:8IlJ2cew
大手IT企業たちをはじめ次々となぜRustを採用しているのかの理由のうち一番大きな点は、
直面しているセキュリティ等のバグの原因の大半がメモリ安全性の逸脱に伴うものであり、
メモリ安全性を保証する論文に基づいたRustがそれら問題点を解決することが明確となっている点にある。
2021/08/24(火) 10:07:34.07ID:BT6OtRuy
>>52
論文に基づいたメモリ安全性の保証が大きいですね
IT業界の状況

プログラミング言語「Rust」のための「Rust Foundation」設立 -- AWS(Amazon)、Microsoft、Google、Mozilla、Huaweiが創設
https://japan.zdnet.com/article/35166267/

Facebookが「Rust Foundation」に参加
https://japan.zdnet.com/article/35170192/
2021/08/24(火) 14:54:36.93ID:MFD20u5I
>>51
コード読んだ訳じゃないけど1番上のやつnimはコメントにfast inverse square root使ってるって書いてあるし比較できなくね？
55デフォルトの名無しさん
垢版 |
2021/08/29(日) 20:34:53.75ID:TMfqiUgQ
>>52
言ってる事は正しいが実際の理由はそうではないと思う。C/C++に比べればメモリ安全性はその通りだが
多くの言語ではGCがあるためにメモリ安全性をほぼ保障をしているが、わざわさRustを採用するのは
極めて大きいメモリーを扱うプログラムやリアルタイム性を追求される要件があり、それがGCのSTWや
GC時間を無視できないから
2021/08/30(月) 00:46:35.99ID:kkNE5PqB
メモリ安全性の話にGC持ってくるとは
何か勘違いしてないか
57デフォルトの名無しさん
垢版 |
2021/08/30(月) 10:54:55.14ID:6iKzd6aE
GCに限った話でなくてもUnsafe使えば全部同じ、自身が使ってなくても（速度を出すために）ライブラリで使ってる。
Unsafe使わなくても完全に防げるわけでは無い。これはgoもnimもDも同じ
「大手IT企業たちをはじめ次々となぜRustを採用しているのか」の一番の要因は55の言う通りだと思う
2021/08/30(月) 11:07:11.50ID:M/wulqx+
>>55
扱うメモリーの大きさは関係ない

応答速度の程度のことをリアルタイム性とは言わない
プログラミングの分野でリアルタイム性という言葉は別の意味を持つ
Rustはリアルタイム性を求めて使われてるわけではない
2021/08/30(月) 11:19:37.82ID:laDLLmjr
C/C++の移行とJavaやGoからの移行では理由が異なる
現状大半は前者
つまりもともとGCを利用してない分野なので>>55の認識は間違い
2021/08/31(火) 08:45:13.59ID:SlncBcTV
>>59
現状、SNSなどのサーバーサイドのプログラムでGCのStop The World が遅くて
移行した企業を見たが。見たのは一例だけど。
C++からの移行は、Rustを作ったところのMozilla自身がFireFoxで行ったものが
有名で後は数例だけを聞いた。
61デフォルトの名無しさん
垢版 |
2021/08/31(火) 08:57:06.99ID:7zPv8PJ6
いやいやC/C++でも今で土器は大規模プログラムだとGC使用してる場合がある。Boehm GCや
TCMallocなんてまさにそれ、もちろんカーネルプログラミングやドライバ開発では使用されないが
純粋なC/C++で起こりうる何も考えていないヒープ確保の断片化による肥大化を抑える。ただし
GCの最大時間を指定できるものもあるが、Rustに比べれば確実にこのブロックでメモリー解放が
起こるという予測可能性が無い。
大手IT企業という話であれば、これはカーネルプログラミングなどでは無いだろう。
確かにSTWなどからの低レテンシーやCPUスパイクが小さい事をリアルタイム性とは言わないが
現実として自動運転や大規模ウェブサイトでは、ほんの数十ミリ応答を受け付けない事は致命的で
あり、すべてではないがそういった見方を排除あるいは全否定すべきではない
言語的なバッファオーバーフロー耐性などは１側面に過ぎない。
2021/08/31(火) 16:03:34.84ID:pBk/Kvod
GCは参照されないオブジェクトを探すだけなので
参照カウントが1か2以上かチェックしたくなったらもうGCは役に立たない
2021/08/31(火) 16:56:17.54ID:s/B3pX4y
>>61
自動運転の制御プログラムでGC使ってたのがRustに移行した事例あるの？

Discordの事例はレイテンシが致命的だったわけではないぞ
それにサーバーサイドでRustへの移行がペイするDiscordレベルの規模と速度が求められるようなシステムは0.01%もないから
残りの99.99%はどうなのかが重要
2021/08/31(火) 18:27:45.08ID:2Z3a814f
GCがサーバの遅延原因とわかるなら、重いGCを動作しない設定にしといて
一時的にサービスから外す＞プロセス再起動＞サービス再開
で済む話
2021/08/31(火) 18:56:45.11ID:+8DUbqPW
そもそもDiscordはC/C++じゃなくてGoだった
GoからC++に変えるよりもGoからRustに書き換える方が良さげなのは何となく分かる

C/C++をRustで書き直したってあるのかね？servoも最初っからRustだったはず
2021/08/31(火) 19:35:22.26ID:wuud9+ob
数年後rustは糞言語だったって評価されそう
2021/08/31(火) 19:36:48.62ID:tid2JAjH
C++が既に十分に優れているということを言いたいのかもしれないけど、
C++からRustに書き換えないのは単純に難しいからだと思うぞ
2021/08/31(火) 20:00:37.49ID:JHqwYLi1
違うよ
既にあるものを移植する案件が少ないだけ
しかし大規模改修や新規案件ではC++を利用する意義がなくなったのでRust採用が多い
もちろんC++だけからではなくFacebookのようにJavaからRustのパターンもある
2021/08/31(火) 20:56:18.00ID:Srcy774Z
>>65
ChromiumOSやAndroidはコンポーネント単位でRust導入が進んでるプロジェクトかな
あとはcurlがバックエンドをRustにする作業中
2021/09/01(水) 00:08:09.87ID:+dwouIiT
>>66
糞言語でも広まると糞言語だと言われない場合も多い。
広まってしまったらそれまで。例えばPythonとか。
2021/09/01(水) 01:35:43.66ID:GVO/11SU
最良言語を目指すやつはすぐ仕様変更するのが欠点だな
Pythonも仕様変更はあったが古いバージョンを虐待しなかったのがよかった
2021/09/01(水) 03:34:40.38ID:MtyAaHfZ
>>71
Rustはedition制で後方互換性を完全に保証しているから安心して使用できますね
2021/09/01(水) 06:09:56.27ID:OZGdMA/h
>>65
Firefoxがそうだろ
あと、Windows10の一部もRustに書き換え中ってニュースもあったな
2021/09/02(木) 15:26:46.45ID:ONfZsKfr
サーバー書くならGoかRustかって感じだけどどっちもパッとしないんだよな
シンプルと複雑の中間が欲しいわ
2021/09/02(木) 17:59:05.47ID:PDrIjWiD
>>74
無難にいくなら
TypeScript/Node
C#
Java or Kotlin
あたりだろうな
2021/09/02(木) 18:06:33.02ID:wNaONt6G
Dartはサーバ側でも使ってねとアナウンスあったけど、
クライアント側と同じ言語で書ける以外の利点は特に無いのかな
2021/09/02(木) 18:11:04.37ID:2FuyxSW6
>>74
複雑？？
イメージだけで語ってるやろ
78デフォルトの名無しさん
垢版 |
2021/09/02(木) 18:37:13.19ID:6gOJWbCR
サーバ用途ならcrystalがええんちゃうかね。rubyをコピーした資産が多そう
2021/09/02(木) 18:51:33.01ID:UQhR0inN
別に1つの言語に拘る必要なくね
rust導入するとしても丸ごとリプレースする必要はない
2021/09/02(木) 19:29:02.15ID:bHl+beee
>>71
pythonも2から3への移行はだいぶ苦労したろ。
あれで脱落しなかったのは割と奇跡的だと思うわ。
2021/09/02(木) 20:00:41.23ID:XW9HOgOw
もしコンパイラ言語ならgccとかllvmも同時に移行しないとコンパイルできなかったりして
82デフォルトの名無しさん
垢版 |
2021/09/02(木) 20:34:58.67ID:lSTkj0Rg
>>80
慌てる乞食は儲けが少ない
2021/09/02(木) 22:06:53.19ID:2FuyxSW6
AndroidでもRust使うってよ
https://security.googleblog.com/2021/04/rust-in-android-platform.html
2021/09/03(金) 13:29:52.44ID:gdUOZxn5
Rustの最大の欠点はシンタックス。異論は認めない
2021/09/03(金) 15:16:50.54ID:9y+1HwQb
>>84
他にも色々あるよ。
2021/09/03(金) 15:34:17.82ID:yHlVBJE7
誤解を恐れずに言うとRustが嫌われるのはバカには理解出来ない難解さだろ
2021/09/03(金) 17:09:30.99ID:K5OdE3wo
本質的でない複雑さもあるからね
たとえばRustは標準ライブラリがGoなんかに比べると貧弱なので、自前で実装したりコミュニティのパッケージに頼らざるを得ないシーンが多い
2021/09/03(金) 18:25:24.07ID:qtYdCVwr
>>86
rustの問題はこういうバカがイキってる所だと思う
2021/09/03(金) 19:59:54.63ID:9y+1HwQb
少なくとも、全てのアルゴリズムをRustではアプリのsafeモードでは扱えない。
例えライブラリをunsafeモードで書いたとしても。
それが最大の欠点。
書き方が面倒なのが次の欠点。
2021/09/03(金) 20:30:12.82ID:33gOMWg5
全部unsafeで書けば面倒さは無くなりそう
2021/09/03(金) 22:16:03.68ID:9y+1HwQb
Rustでライブラリやメソッドを unsafe で書いて、それを safe モードから
使っても、決してCと同じ効率では利用できないアルゴリズムが存在する。
2021/09/03(金) 22:27:23.15ID:9y+1HwQb
>>91
理由は、Cで昔から至って普通に使われていたアルゴリズムのかなりもののが、
Rustだと借用規則に違反してしまうから。
学問的にも正しくて使い方を誤りさえしなければ安全である事が分かっていても、
Rustでは借用規則に違反するので最初からコンパイルエラーになってしまって
使えない。
それらのアルゴリズムは、unsafeモードの中だけに借用違反を閉じ込めよう
としても無理。なぜんばら、根本的に借用規則に違反していて、
それがそのアルゴリズムの本質で要(かなめ)の部分だから。
2021/09/03(金) 23:01:26.75ID:HcIIq6Rh
>>84
様々なプログラミング言語と比較しても
Rustの基本シンタックス記法は素直なほぼ標準タイプ
最大派閥のC系と比較してもRustは条件式にカッコが不要なくらいかな
2021/09/03(金) 23:02:45.90ID:HcIIq6Rh
>>92
嘘つき
未だに例示できないくせに
2021/09/03(金) 23:30:25.11ID:EGT6hvvH
次にお前は連結リストと言う
2021/09/03(金) 23:34:16.62ID:ojcqN+X9
ハッシュマップ
2021/09/04(土) 02:34:46.85ID:j+KqajCA
rustって最終的にはjavaみたいな奴隷専用言語になりそう
2021/09/04(土) 03:07:14.01ID:7+Hy81Ja
そうだ。rustは君のものだ。
2021/09/04(土) 04:09:47.08ID:iqtSb51S
たしかにRustは非常に書きやすいしコンパイラのrustcが賢くてミスを直す候補を探し出してきて表示してくれるので便利だけど
奴隷の生産性まで上がるものなのかね
2021/09/04(土) 04:50:10.07ID:7+Hy81Ja
今の日本はだいたいが奴隷。

https://oshiete.goo.ne.jp/qa/3737411.html
> １５世紀のアメリカでは、教育と結婚の権利を与えられ財産を持つことも可能で、低賃金の労働者と言えるものでした。
2021/09/04(土) 08:12:27.52ID:elqVYRSe
元々、共有やコピー、参照の違いをまともに理解してない奴に限ってrustを評価する傾向にあるのがな。。
はっきり言ってそれをまともに意識してるコード書くやつはそれほど便利だと思ってない。
2021/09/04(土) 11:12:27.56ID:EwYrh1qJ
>>94
あなたは、数学は出来ないね？
俺は数学は得意だから、例がすぐ浮かぶぞ。
2021/09/04(土) 11:14:39.89ID:EwYrh1qJ
ヒント:
safeモードに借用規則がある限り、メソッドの中にunsafeを閉じ込めようとしても
絶対に無理なアルゴリズムが存在する。

これが理解できないのは、数学力が足りない。数学力は生まれつきのものが大きくて、
ワーキングエリアの大きさや、想像力の問題。
2021/09/04(土) 11:17:19.47ID:EwYrh1qJ
なぜ例を提示しないかと言えば、本当のことを教えたくないからだ。
嘘だからではない。
本当のことを教えるのはもっと時間が経った後でいい。
時間が経ったらだんだんと本当の事が広まっていくだろう。
俺は最初からそれがわかるが、分からない人は分からない人なりの人生を送れば
いい。それが俺の才能だから。
俺の才能を全ての人に分け与えるわけにはいかない。
2021/09/04(土) 11:20:31.21ID:EwYrh1qJ
コンピュータの世界は、どんなに頭のいい人でも時間が経てば追いつかれる。
平易に解説されたり、または、ライブラリなどが難しいことを閉じ込めて
誰でも使えるようにしてしまうからだ。
だから頭のいい人もその間のタイムラグだけで差を付けるしかない。
だから、本当の事をすべては明かさない。
2021/09/04(土) 11:30:28.20ID:GpbNmj1Q
入力するデータに依存するアルゴリズムなんじゃないの
C/C++なら自由に実装できるけど実務上は不正データがないかチェックするハメになるという
2021/09/04(土) 12:30:13.91ID:EwYrh1qJ
>>106
全く関係ない。
数年後には秀才達が解説してくれるだろうから、分からない人はそれまで待とう。
2021/09/04(土) 12:37:18.23ID:HK0EkPCX
もしかして、ボローチェッカに怒られるコードをunsafeブロックに入れればエラーを回避できると思ってやってみたらできなくて、
それでここまでずっと言い訳してるのか？
2021/09/04(土) 13:11:05.75ID:gkfG02et
例示しろって言われてアウアウしてるんだろw
長文で言い訳グダグダ書いてるのが哀れですらある
2021/09/04(土) 14:04:36.94ID:jLCLkIuV
引っ込みがつかないとはまさにこのこと
2021/09/04(土) 14:14:32.96ID:qlWaKbMU
借用で表現できないアルゴリズムって何だろう。
2021/09/04(土) 14:19:15.62ID:qlWaKbMU
ループで書けないけど再帰でならかける、とかはあるけど、完全に書けないのはあるかなぁ…
2021/09/04(土) 14:31:27.43ID:EwYrh1qJ
やはり、数学の才能の無いやつらには、分からないんだな。
2021/09/04(土) 14:34:12.53ID:ZqoEpBUe
>>112
>ループで書けないけど再帰でならかける、とかはあるけど
ないでしょ
2021/09/04(土) 16:16:10.33ID:kqbJw6T2
>>104
教えたくないならこのスレくんなよ
2021/09/04(土) 16:22:49.98ID:ZtXzgEKZ
はい、スルー検定4級不合格です
2021/09/04(土) 17:35:39.84ID:HcNFP2te
数学的才能がない人は、人から言われたことを鵜呑みにするだけで自分で考える事が出来ない。
2021/09/04(土) 17:40:09.63ID:iqtSb51S
どのスレでもどの問題についてもいつも同じパターン
指摘されても具体的なケースを示せない人や具体的なコードを出せない人は『イチャモンをつけるだけのダメな人』
2021/09/04(土) 17:40:36.61ID:HcNFP2te
今回の事を見ても分かるように、ヒントを与えられても、それを部品として
組み立てて結論を導くことが出来ない。
そういうひとはいいプログラムはできない。
自分でアルゴリズムを発明することも出来ない。
2021/09/04(土) 17:41:48.84ID:HcNFP2te
>>118
違う。
ヒントを与えられても、自分で組み立てて正しい答えをひらめくことが出来ない
人しかそのスレに来ていないだけ。
答えを知っていても、与えないだけ。
2021/09/04(土) 17:48:30.37ID:FwiYtexa
実世界でも一緒だな。
言い訳ばかりして具体例を出せない人を相手にしても話が進まず時間の無駄。
そういうバカは無視するのが正しい。
2021/09/04(土) 17:54:17.63ID:HcNFP2te
優秀な人から正しい答えを簡単に教えてもらえると思ってるのはどういう教育されて
きたんだろう。
情報量も払わないくせに。
2021/09/04(土) 17:55:05.92ID:HcNFP2te
>>121
それはあなたの周りに居る程度の低い人の話。
俺は違う。
2021/09/04(土) 17:58:34.94ID:GpbNmj1Q
お前の情報なんて要らんからコテつけてくれ
最初から避けるから
2021/09/04(土) 18:25:26.65ID:HcNFP2te
情報は与えないが、本当のことを言ってるのにうそ扱いしないでくれ。
ちゃんと思考力や理解力が有る人には正しいことが分かる。
このスレに今居る人は、俺以外は数学的能力が足りてない。
2021/09/04(土) 18:29:06.33ID:kqbJw6T2
>>125
十分説得できるくらいの話をする気がないやつなんざウソつきとして扱うしかないやろ
2021/09/04(土) 18:40:45.92ID:HcNFP2te
>>126
だから、詳細を不特定多数の人達に言うわけにはいかないと何度も行ってるじゃないか。
問題点を明確にしたら改良されてしまう恐れがある。
それは俺の立場からしたら最悪で、問題点は問題点のまま改良されずにずっと
残っていてくれたほうが都合が良い。
2021/09/04(土) 18:57:20.36ID:FwiYtexa
無能なやつが思い込みで延々と言い訳に終始。
スレの邪魔でしかない。
2021/09/04(土) 20:36:57.34ID:j+KqajCA
>>127
問題が１パターンだけなら
それだけ意識すればいいんじゃん
2021/09/04(土) 20:45:10.80ID:iqtSb51S
存在するかどうかすら例示されていない空想の問題について話をするのは
少なくともプログラミング言語のスレでは無意味
131デフォルトの名無しさん
垢版 |
2021/09/04(土) 21:51:42.85ID:CUdge0sZ
>>130
同意
2021/09/05(日) 04:52:30.40ID:j+9BaQO4
これでは日常生活も大変だろう‥
2021/09/05(日) 11:58:59.75ID:TAzC3d8r
スレのレベルが低すぎ。
本当に頭のいい人が言ってる正しいことが理解できない人ばっか。
2021/09/05(日) 11:59:36.21ID:TAzC3d8r
このスレでは、たった一人だけが正しいことを言って、他はみんな間違ってる。
2021/09/05(日) 12:08:33.41ID:2jP3+tuQ
はいNG
136デフォルトの名無しさん
垢版 |
2021/09/05(日) 12:11:17.36ID:3IKjsp8l
自分のことをたった1人とか言っちゃう猿
2021/09/05(日) 12:32:10.27ID:TAzC3d8r
アホどもめ。
2021/09/05(日) 15:07:01.68ID:LgQhIBwq
Aを教えてくれ→解答a
Bを教えてくれ→解答b
Cを教えてくれ→解答c
一生これを続けるつもりか？(たまにそういう人物がいるが明らかに向いてない)

気をまわして x 使え！
(そうすれば A も B も C も解決するよ！！)
っていう解答が来ると「教えてくれない！！！」とキレる
2021/09/05(日) 22:17:48.95ID:XzVpFLw9
糖質御用達言語RUST
2021/09/06(月) 05:10:39.90ID:xB3x8Lax
>>139
逆だぞ
この糖質はRustのアンチ
2021/09/06(月) 09:30:22.04ID:NkVKbvcc
フェルマーでさえ問題そのものは明らかに提示したというのに、問題そのものも一意に定まらない状態で教えてｸﾚｸﾚしかここには居ないバカばっかりって言ってるんだよな
2021/09/07(火) 09:33:01.92ID:AwNiMUSI
生ポインタがない言語では
まずグローバルな配列を使うアルゴリズムに変換し
次にグローバル変数とかstatic変数禁止の規則に違反しないように書き直す

これができない人はJavaでもstatic変数を使うことになる
2021/09/08(水) 12:12:45.69ID:on4QL4Ij
めっちゃパフォーマンス悪くなりそう
2021/09/08(水) 20:56:23.70ID:UIi59Wds
ポインタと配列インデックスはパフォーマンス的に等価じゃね？
2021/09/08(水) 22:07:00.68ID:qzNSvV6w
等価っていうかそれを遅いと宣言したらJavaもC#もGoもみんな等しく遅いことになる
2021/09/08(水) 23:52:20.69ID:7Stt1ihW
Cみたいな無能言語を除けば配列インデックスには境界チェックが入るからポインタと同じではないよ
2021/09/09(木) 00:23:24.04ID:3/x9wOmm
少なくともC++とNim言語ではコンパイルオプションで配列、vector、seqの境界チェックをオフにすることができる。
2021/09/09(木) 00:54:48.17ID:ByOcyvaf
vector<T>型を更に抽象化してV<T>とすれば
高速なVと安全なVを二刀流できたのに
2021/09/09(木) 09:35:35.54ID:H5Pm1mBI
少なくともRustは境界チェックを全とっぱするのではなく必要に応じてuncheckする仕組みがある
2021/09/09(木) 09:49:27.01ID:nDPpxxc9
実際のところ境界チェックのロスってどんなもんなの
組み込み向けはともかく一般的なCPUだと分岐予測とパイプラインのおかげでロス少なそうな印象だが
151デフォルトの名無しさん
垢版 |
2021/09/09(木) 14:53:53.92ID:a5R4sWP8
少なくとも{.push checks: off.}あるいは{.push boundChecks: off.}でNimも部分的にオフにできるはずだが
コンパイル時の境界チェックだけであれば、これは(通常はboundary checkをしないが)C/C++などにも、当然
ながら出来るだろう。RustはもちろんUnsafe{}でほぼすべてチェックを除外することも可能だが、通常は
releaseでも（当然Debugでも）Runtime boundary checkは入る。Goの場合も同様だが、少しずつ”不要な”
ランタイム時のチェックは最適化/改善されて来ている、これはRustも同様であろう
https://go101.org/article/bounds-check-elimination.html

もちろん実行時のチェックが入ることが問題と言っている訳ではなく、通常は安全ではないなら入れる”べき”
だし、デフォルトで入らない安全性側に倒れない言語は古いとしか言いようがない。この実行時のチェックを
エリミネイトする記述の、この分野はJavaの最適化が一番進んでいると思う。

boundary checkに掛るコストを見積もるのは非常に困難だが、上記の言う通りCPUに余裕があり、分岐予測や
投機実行に空きがあれば”さほど”の違いは無いが、最悪は２倍近いメモリと、１ループ毎に２つ程度のCMP命令が
入る事により、全くチェックしないC99などと比べれば1.5倍-2倍程度遅くなるのも当然
152デフォルトの名無しさん
垢版 |
2021/09/09(木) 23:38:57.23ID:f/JM052X
>>150
正解
2021/09/11(土) 04:07:36.44ID:w5S7rLqj
『具体例は教えられないが問題がある！』君は敗走しちゃったね
2021/09/14(火) 22:08:36.31ID:s29FvQzO
負けました。もう勘弁してくらはい。
2021/10/03(日) 20:16:28.62ID:rU4PBp3b
Stack OverflowのServeyであった
給料が高くて人気な言語に
Rust Julia Elixir Clojureあったけど
みんなマクロがあるからなのかな？

マクロがある言語じゃないと今後スケールはしない？
2021/10/03(日) 21:21:16.47ID:f+cxTxee
人気あるって言えるのかな？案件の絶対数は他の言語に比べて少ないと思うが。
2021/10/03(日) 21:30:20.91ID:+hZ9cv9k
バッチやdcl、スクリプト系の非効率実行、脆弱性がクラウド提供側で嫌われて
突き詰めたところに制御構造をメタ記述出来るコンパイル言語の需要が有ったかんじ
2021/10/11(月) 22:26:58.15ID:BHOOgNKr
Rustって、本当に流行ってるんですか？
海外では、総じてプログラマのスキルが高いから流行っているのですか？
日本の感覚だと、一部の技術好きの人達がベンチャー精神にあふれる会社で使っているだけのイメージなのですが。

C言語すら、まともに使えているのかあやしい開発体制の多い日本で、Rustは難しすぎないですか？
（流石に、C言語は言い過ぎかもですが、C++でまともに開発できる体制なんて、夢のまた夢ですよね。）
将来的には、一部のOS開発等を除いて、Goとか敷居の低い言語に落ち着くのだと思っているのですが。
2021/10/12(火) 00:32:47.27ID:c4kB5fU7
チームにバカが居ると開発効率が悪くなるからRustの難しさはバカよけになる
2021/10/12(火) 02:21:39.98ID:1W2DSIiH
>>158
Rustはむしろ簡単
考え方を変えることで単純化することに成功した
C++などの既存の複雑な考え方に囚われてしまう頭の固い人にとっては難しくみえるだけにすぎない
2021/10/12(火) 08:35:14.39ID:H70LQP2o
メモリ破壊バグのないCとかデータ競合バグのないGoを書くのに比べたらRustは簡単
コンパイラに怒られたら直せばいいだけ
162デフォルトの名無しさん
垢版 |
2021/10/12(火) 14:00:16.57ID:JJ3t9gVC
Rustはプログラム書いたことない意識高い系が喧嘩する。forを使うなだとか、こっちの方が短く書けるだとか
2021/10/12(火) 15:05:47.06ID:1W2DSIiH
>>162
Rustでそういうことは起きていない
ちなみにC言語のfor ( ; ; )文はRustに存在せずIteratorベースのもののみ
164デフォルトの名無しさん
垢版 |
2021/10/13(水) 13:28:21.94ID:V99uCirA
>>158
Pythonも10年前はそんな感じだった
日本は相当遅れてると観て良い
165デフォルトの名無しさん
垢版 |
2021/10/13(水) 13:29:46.77ID:V99uCirA
>>159
同じ理由でC++よりCの方が良いって言われてるね
166デフォルトの名無しさん
垢版 |
2021/10/13(水) 17:06:10.92ID:+919yhfB
>>163
for-inは普通にあるし、map/filter/fold/collectを使えと言う話は読み易さの問題はある。
いまでもrustスレは意識高い系が喧嘩してるようなもの、競技プログラミング的な書き方は
止めろだとか、初心者が書いたコードを貶す
2021/10/13(水) 18:19:54.35ID:fXfbCLiK
>>166
そんな喧嘩は起きていない
初心者が書いても同じになりイテレータをメソッドチェーンで回すかfor inで回すかの2通りしかない
競技プログラミングの件はどの言語でも同じだが速さだけ求めて汚いプログラミングするのは競プロ専用スレでやるべきなのだろう
168デフォルトの名無しさん
垢版 |
2021/10/13(水) 19:35:38.13ID:VbHeyYt0
こんな奴ばっかり
2021/10/13(水) 23:53:56.11ID:W/9iWpHx
>>166
for-inを使うにはIntoIterator実装が条件だから結局イテレータの元で統一されていますね
そこに混乱はないと思います
2021/10/13(水) 23:57:31.98ID:wiC5i83X
これが会話のドッジボールですか
171デフォルトの名無しさん
垢版 |
2021/10/15(金) 12:49:40.87ID:nPSdjqiL
そう言う事を言ってるんじゃないのに、「統一されてますね」このにじみ出る性格の悪さとしつこさが嫌。
そりゃ他人から嫌がられるよお前は、一生ロンパーロンパーしとけよ
2021/10/15(金) 13:35:11.51ID:TiF/o4Oy
そして静かにC/C++が生き残る・・・とな
2021/10/15(金) 14:08:53.65ID:8deGlJY8
ほんと進歩ないよな。。だから歴史って重要なわけよ。
2021/10/15(金) 14:48:47.55ID:5sSC8oS1
歴史から長いものにはまかれろという以外にどんな教訓が学べるというのか
2021/10/15(金) 15:16:58.35ID:8deGlJY8
機能ゴテゴテ盛り込んで失敗。くらいはそろそろ理解して欲しいもんだがね。
2021/10/15(金) 16:31:03.08ID:XGfxQXO+
無駄な機能が多すぎる言語は失敗してるよな
一方でRustとGoが成功したのは不要な機能を見極めて削ったことも大きい
どちらもclassすら無いしtry-throw-catchも無い
シンプルでわかりやすい言語となり成功した
2021/10/15(金) 17:14:22.04ID:5sSC8oS1
つかれたよ
2021/10/15(金) 20:33:51.67ID:w61IhFeo
まあ、テキストの塊で表現していることに変わり無いしな。
これからはビジュアルプログラミングだろう。
2021/10/15(金) 20:40:41.27ID:w61IhFeo
>>176
C++のclass自体は簡単で便利な仕掛けだけどね。やってることはそんなに難しいことでもないし。
Rustは学習コストが大きいっていうのはよく言われることだけどね。
2021/10/15(金) 20:46:36.53ID:XGfxQXO+
>>179
むしろ学習コストは低い
GoもRustもclassなんか導入していなくてC言語と同じくstructつまり構造体を用いる
2021/10/15(金) 22:47:09.07ID:rb+Oscx7
Rustの学習コストが低いと思っているのはなかなかすごいな
メジャーな言語で、Rustより学習コストが高い言語挙げてみいよ
2021/10/15(金) 22:50:16.66ID:5sSC8oS1
Scala
2021/10/15(金) 22:50:39.45ID:5sSC8oS1
Haskell
2021/10/15(金) 22:50:55.08ID:5sSC8oS1
C++
2021/10/15(金) 22:59:02.83ID:cXrj7rPD
C++は最初にある程度かけるようになるまではそんなに大変じゃないけど
コンパイラの挙動が怪しいから言語仕様読んでどこかでUB踏んでないか調べる、みたいなとこまでいくと
Rustの方が簡単だったなぁ、と思う
2021/10/15(金) 23:54:26.80ID:awitBW+b
そもそもの話
次世代言語って必要なの？
って最近疑問に思ってる
187デフォルトの名無しさん
垢版 |
2021/10/16(土) 00:14:02.74ID:dPfgeqZY
>>186
ずっとFORTRANとCOBOLでも使ってろ
2021/10/16(土) 00:40:25.95ID:O4GIW+Mr
>>187
それは流石に前世代なんでない？

現行世代の似たような言語が増えてってるだけで
その中から次世代を探そうとしても一長一短があるだけで
次世代って感じはどの言語からも感じられない
って個人的な疑問
189デフォルトの名無しさん
垢版 |
2021/10/16(土) 01:01:04.43ID:GQKUTzD/
いま次世代でも数年たてば時代遅れになる。
それならいつでも最新のC++にすれば良いのでは？
次世代ではないけれど。
2021/10/16(土) 01:33:55.93ID:0owCAudu
>>188
そういう意味では画期的なプログラミング言語はRustしかない
C/C++を完全に置き換えることができる条件「ネイティブコードにコンパイルされる」「ガベージコレクションが無い」「低レイヤもすべて操作可能」を満たしながら
「メモリ安全性を保証」という従来は相容れなかった条件を同時に満たした初めてのプログラミング言語がRust

そのため二つの方向の移行が進んでいる
・C/C++ → Rust　(メリット: メモリ安全性が保証される)
・Java等GC言語 → Rust　(メリット: GCなくネイティブに最高速となる)

>>189
Rustの出現でついにC++から解放された
2021/10/16(土) 02:05:47.39ID:N8k1BZc2
Rust個人的には推しだけど確かに最近の5chは変な信者が多い
2021/10/16(土) 02:49:28.47ID:MVC0A82Z
>>190
だから歴史を学べと。
それまるっきり30年前にc++が言われてたことまんまだから。
2021/10/16(土) 03:21:07.83ID:0owCAudu
>>192
Rustはコンパイルが通ったらメモリ安全性を保証するが
C++はコンパイルが通ってもメモリ安全性を保証しない
そのためC++で書かれたものはメモリ安全に関するバグを産出してきてそれがセキュリティ脆弱性の7割を占めているとGoogleもMicrosoftも述べている現状
2021/10/16(土) 12:10:44.93ID:MVC0A82Z
だからGoogleもMicrosoftもどれだけ言語ダメにしてきたか、少し頭使って調べてみてくれ。
そのお題目がいかに名目だけか実際大規模でビルド体制整えて運用してみればよくわかるから。
2021/10/16(土) 12:33:30.03ID:vbkw9O81
>だからGoogleもMicrosoftもどれだけ言語ダメにしてきたか、少し頭使って調べてみてくれ。

GoogleやMicrosoftがダメにした言語ってなんだろう？
自分で作って結局普及しなくて捨てた言語ってことかな。
2021/10/16(土) 12:55:55.35ID:6WTAYzCY
Googleが作った言語ってGoとDartだけ？だったらどっちもダメにしてないな
Minecraftは多そう
2021/10/16(土) 12:56:41.58ID:6WTAYzCY
>>196
予測変換ミス
2021/10/16(土) 13:33:53.37ID:N8k1BZc2
>>194
大規模でビルド体制整えて運用してみて発生する問題って、技術によって解決すべき問題ではないんじゃね？
具体的な話を聞かないと何とも言えないけど、デマルコ本で言われるような社会学的側面の問題じゃなかろうか
2021/10/16(土) 14:38:48.10ID:0owCAudu
>>194
・RustはGoogleが作った言語ではないしMicrosoftが作った言語でもない
・RustはFirefox開発のためにMozillaが作った言語
・前代未聞の革命的な言語>>190であったためライバル社たちも導入した
・さらにAmazonやFacebookなどIT大手が揃ってRustを支持し採用している
200デフォルトの名無しさん
垢版 |
2021/10/16(土) 17:59:55.50ID:5x+WFlZB
>>191
分かるわ…、宗教のような気持ち悪さを感じる。rust推しだけど
2021/10/16(土) 20:13:04.25ID:nF4n8/aE
>>186
よくあるのは、CやRustのマクロは必要ないからマクロ無し言語が必要だというパターン
2021/10/16(土) 22:43:22.32ID:MVC0A82Z
>>199
mozillaがネットスケープも含めてどれだけ失敗したか理解してるか？
facebookで多く使われてるphpがそんな素晴らしいか？
amazonのc++コードの汚なさを理解してるか？
バカは何度でもブランド意識でくだらんことを広めたがる。そして忘れた頃に同じことを繰り返す。
そういうバカはもううんざりなんだよ。
2021/10/16(土) 23:05:31.31ID:nF4n8/aE
たとえばPythonとRustのような両極端なら同じことを繰り返してない感がある

両者の中間ぐらいを理想とすると変化に乏しいバカに見えるからやめたほうがいい
2021/10/16(土) 23:24:00.10ID:yuQVo/8c
>>202
貴方はRustを叩けるほどRustを理解することが出来なかったため
仕方なくRustと全く無関係なことを一生懸命に叩いている
結果的にRustを叩くことが一つも出来ていない
2021/10/16(土) 23:28:51.24ID:N8k1BZc2
個人攻撃やめなー
2021/10/17(日) 05:07:24.12ID:Aq3hRABL
なんでRustって成功しているの？
MSもGoogleもAppleもダメだったのに、やっぱり少し不親切なぐらいの方がいいのかな・・・・
207デフォルトの名無しさん
垢版 |
2021/10/17(日) 06:34:07.94ID:atjZW8su
Kotlin もよろしく
2021/10/17(日) 06:58:29.73ID:PnF0LE+q
CとかJavaとかPythonみたいなメインストリーム言語であるような、
他の言語の経験がない人を対象にした、プログラミング自体をその言語使って学んでいく初学者向けの分かりやすい本ってRustにはないよね
どの本もプログラミング既学者向け
2021/10/17(日) 08:11:41.68ID:y3veWc+v
本は無い
コミュ力で盗め
ってみんな割と本気で思ってそう
終わりだねこの力
2021/10/17(日) 11:05:04.81ID:MkgjpPUe
>>180
classの基本は変数とそれを操作するメソッドを一体化して扱おうっていうことだから、
ハードウェアのアナロジーとして捉えればそれ自体はさほど難しい概念ではないけどね。
まぁ、C++もいささか肥大化しすぎた感じでもあるけれど（笑）

Rustはclassを廃止したけど、結局structだけでは無理だから
implやtraitを持ち込んだんだよね？

traitの段階でどこにimplされるのかが決まっていないから、どのstructの
メンバを参照するのかを探すのがちょいとうっとおしかったかな。
Cで、構造体に関数へのポインタを入れた時は第一引数に構造体自体への
ポインタを渡したりしたから、ソースコード上でも、「こいつはどこを見るつもり？」
というのはよく分かったけどRustじゃ&selfだから、一見すると、
「お前は誰だぁ！？？」って感じで。

継承ができない・・・とかいっても、そもそもRustはオブジェクト指向言語って
わけじゃないから、そのあたりは割り引いて考えないといけないんだろうけど。
2021/10/17(日) 11:23:57.78ID:Lu+6ZGga
成功してると思い込みたいバカが持ち上げてるだけだろ。
それだけ学習すれば済むと思い込みたいバカがな。
2021/10/17(日) 12:18:01.28ID:3vXZmfmW
JAVAの良さは何かな
最初の頃は一度書いたらすべてのプラットフォームで動作すると宣伝していたのに
2021/10/17(日) 13:50:04.06ID:y3veWc+v
>>212
本を買わなくても無料の情報と空気を読めばプログラミングができる

一方C++は本を買わないとついていけないビジネスモデル
2021/10/17(日) 14:16:08.94ID:6j2makCm
Javaは次々に新しいフレームワークができて
バージョンアップも早い
動かすだけで一苦労
が何回も繰り返される
2021/10/17(日) 16:18:33.33ID:KyO3PKvk
>>210
> Rustはclassを廃止したけど、
> 結局structだけでは無理だから
> implやtraitを持ち込んだんだよね？

その発想はオブジェクト指向プログラミングに毒されているかなと思います
むしろRustは関数型プログラミングの視点から見れば素直に理解しやすいです

まず代数的データ型としてRustでは
『直積』をC言語と同じstructで
『直和』はC言語のunionでは機能不足なので値付きenum (＝タグ付きunion)で表しています
もちろんこれらstructとenumはジェネリックに定義されて0個以上の他の型から構成されます
それらの上での(Haskell等の)『型クラス』としての位置付けがRustのtraitです

つまりある一つの側面としては
RustはC言語に関数型言語の概念を持ち込んだ手続き型言語という捉え方をするとわかりやすいでしょう
加えてC言語系統では今まで実現できていなかったメモリ安全性の保証に成功したことが大きいですね
2021/10/17(日) 18:28:05.52ID:ESmnvthu
>>212
ちゃんとしたオブジェクト指向
217デフォルトの名無しさん
垢版 |
2021/10/17(日) 18:33:14.43ID:YptL43pX
classを廃止したとか笑うわw
2021/10/17(日) 18:35:13.51ID:7+j7XRcJ
>>196
Dartって一時期めっちゃ死にかけてなかった？
2021/10/17(日) 18:48:49.33ID:MaJoh28m
>>218
各ブラウザにDartVM積んでJavaScriptを置き換えようとしてたけど断念し、選ぶ価値の無いAltJSと化した死に損ない
最近はFlutterで息を吹き返して、Dart単体でも多少は使えるようになってきたような
2021/10/17(日) 19:14:55.95ID:MkgjpPUe
>>215
オブジェクトと実体が一体になるというのは、組み込み用途でもわかりやすい
アナロジーなんだよね。

Rustの「こいつは誰をいじってるの？」というのが宣言されている段階で
確定していないというのは読む側のことを考えていないからなぁ。
メモリ安全というけど、間違った構造体にimplしてしまうと、そちらのメンバを
壊すことになるわけで、そこはコンパイラも実行段階でも引っかからないしね。

違う型の構造体に同じ名前のメソッドが来るというのは割とよくある話なんで、
そのあたりの混乱というのか、コンタミネーションをしないように
ファイルを分割するなりして、記述の時点で気をつけないといけないかなぁ。

そのあたりを「書き方」で工夫してやらないといけない。
221デフォルトの名無しさん
垢版 |
2021/10/17(日) 19:26:32.07ID:QqhGhKAl
そもそも実用レベルのプログラミングでリソースの確保解放でバグは出ない。
意味のない営業文句。
2021/10/17(日) 19:51:35.57ID:uRTUEgiz
>>220
> Rustの「こいつは誰をいじってるの？」というのが宣言されている段階で
> 確定していないというのは読む側のことを考えていないからなぁ。

その辺はOOPにおけるインターフェースと同じでは？

> メモリ安全というけど、間違った構造体にimplしてしまうと、そちらのメンバを
> 壊すことになるわけで、そこはコンパイラも実行段階でも引っかからないしね。

これどういうこと？
2021/10/17(日) 19:58:40.22ID:y3veWc+v
ネットの無料の情報には意味のない営業文句などが大量に混ざっている
224デフォルトの名無しさん
垢版 |
2021/10/17(日) 20:43:02.47ID:QqhGhKAl
伸長するメモリー領域には素直にstd::vectorを使えば良い。
性能は順当に劣化するが、それで良いと思う。
225デフォルトの名無しさん
垢版 |
2021/10/17(日) 23:37:29.30ID:QqhGhKAl
明日の朝は大阪で11度らしいのでコートを忘れずに。
2021/10/17(日) 23:48:16.60ID:KyO3PKvk
>>220
Rustではジェネリックな型から見ると様々なtraitを実装する(指定する)ということは次々と制約を課すことであり
対象はstructだけではなく全ての型であってenumでも数値でも文字列でも何に対しても共通です
その上で別視点から見るとある型に様々なtraitを実装していくということは様々なtraitの機能をサポートしていくことでもあるわけです

> 間違った構造体にimplしてしまうと、
> そちらのメンバを壊すことになるわけで、

そんなことは起こりえません
あるtraitをその構造体に実装(impl)できたのならば間違っていなかったわけです
そしてその実装は自分で行うのですからメンバを壊すという意味不明なことは起こりえません
おそらくプログラミングをしたことがなくて大きな勘違いをしていると思われます
227デフォルトの名無しさん
垢版 |
2021/10/17(日) 23:50:24.15ID:QqhGhKAl
本当にそれでバグが無くなるなら良いが、見当違いのことを一生懸命してるように見えるぞ。
2021/10/17(日) 23:53:18.81ID:Rod/beEv
>>221
それは君が間違っている。
以下の記事引用の最後の段落を読んで現実を知ろう。

グーグルやマイクロソフトが「Rust」言語でOS開発、背景に国家による諜報活動の影
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

　1970年代初めにUNIXの開発にC言語が採用されて以来、OS開発はCやその後継であるC++の独壇場だった。グーグルはこれまでもAndroidの開発にJavaやKotlinを採用していたが、カーネルやデバイスドライバーなどOSの下位レイヤーの開発にはC/C++しか使ってこなかった。RustはC/C++と同様に下位レイヤーの開発に使用する。

　グーグルは数千万行にも及ぶ既存のC/C++のコードを書き換えるのは不可能としており、新規のコードの開発にのみRustを適用する方針だ。それでもOS開発の常識が数十年ぶりに変わるのだけは間違いない。

　RustはWebブラウザー「Firefox」を開発する米Mozilla Foundation（モジラ財団）が開発を主導するプログラミング言語だ。開発が始まったのは2006年で、安定版であるバージョン1がリリースされたのも2015年のことだ。まだ新しいプログラミング言語をグーグルやマイクロソフトがOS開発に採用する理由は、OSのセキュリティー強化にある。

　Rustは、プログラムに必要なメモリーの確保や解放に関連するバグが生じない「メモリー安全」が保証されたプログラミング言語である。それに対してこれまでのOS開発に使われてきたC/C++は「大規模な開発においてメモリー安全なコードを記述することがほぼ不可能」（マイクロソフトのブログ「We need a safer systems programming language」より）なのだという。

【脆弱性の70％がメモリー管理バグに起因】

　グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。
229デフォルトの名無しさん
垢版 |
2021/10/18(月) 00:00:05.81ID:U4M03mzh
>>228
10年後にはまた別のことを言ってる。
再現性のないバグのほとんどすべてがメモリーに起因するのは間違いないが、メモリーの確保解放とはまた別の話。
Rustのやり方で上手くいかないことは、C++を使う者ならとうの昔に気付いている。
230デフォルトの名無しさん
垢版 |
2021/10/18(月) 00:03:14.89ID:U4M03mzh
Haskellこそ救世主である。
2021/10/18(月) 00:09:24.28ID:gU1bKDav
>>229
Rustがメモリ安全性の問題を解決している
これはC++とRust両方でプログラミングしたことある人ならば全員が理解していること
232デフォルトの名無しさん
垢版 |
2021/10/18(月) 01:15:23.81ID:U4M03mzh
Rustじゃ無理、Haskellこそ次世代言語。
233デフォルトの名無しさん
垢版 |
2021/10/18(月) 02:37:41.54ID:mrfOLNSK
>>227
ほんそれ
234デフォルトの名無しさん
垢版 |
2021/10/18(月) 02:39:28.50ID:mrfOLNSK
>>225
温暖化ωですね判りますωω
235デフォルトの名無しさん
垢版 |
2021/10/18(月) 02:42:33.77ID:mrfOLNSK
>>229 に同意
>>228 読んで騙される香具師は素人
2021/10/18(月) 03:31:02.12ID:cK47AFx9
Rustがメモリ安全だって主張している人はRustのメモリ安全とは具体的に何なのかソースも添えて説明すべきでしょう。
そうしないとあの言語だってメモリ安全だとか俺ならC/C++でも十分メモリ安全に書けるからRust不要って言われちゃうよ。

俺の知っている限りではRustのメモリ安全にはメモリリークしないことは含まれていないのでリークする可能性があるらしい。
RustにはC++のようなデストラクタがあるので解放し忘れることはないらしいが
C++のstd::shared_ptrに相当するRc<T>はReference count方式なのでお互いに参照しあうとメモリが解放されない。
2021/10/18(月) 05:42:04.96ID:gU1bKDav
>>235
GoogleとMicrosoftが嘘を言ってると主張？？
その記事にあるようにAndroidやMS製品に存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するとGoogleとMicrosoftがそれぞれ同じ主張をしている

>>236
C++わかるなら話が早い
ご存知のようにC++のスマートポインタは使い方を間違えてもコンパイラは通してしまい気付くチャンスがない
つまりC++は人間によるチェックに依存しているためコードが複雑化するとどこかでメモリ安全性を壊すバグが生じてきた
Rustはその言語仕様からメモリ安全性を壊すコードをコンパイラが認識してコンパイルを通さない
そのためコンパイルが通ったコードはメモリ安全性が保証される初のプログラミング言語となった
そこでIT大手各社がRustを採用支持>>53するというプログラミング言語の歴史でも初の事態となった
2021/10/18(月) 09:29:18.21ID:deQZOXkA
>>208
GoやってからRustやれば良い
間違ってもJSから入ってはいけない
2021/10/18(月) 10:40:12.86ID:oPyph5kC
静的チェック万能論者は信用できんわな。
それで減るものも多いが、あいつらは嘘を信じ始めている。
2021/10/18(月) 11:26:29.68ID:CRhgpEvH
これ四色定理でやったやつだ
証明が嘘ではないことと証明の可読性を両立するのをやめた

証明が万能だと信じるなら両立をあきらめられない
万能ではないと判断すれば可読性は捨てられる
2021/10/18(月) 12:55:52.50ID:nWV7c8cM
>>236
公式ドキュメントには確かにメモリ安全性をちゃんと定義した箇所って無いね
近いのはあるけど……
https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

> If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.
2021/10/18(月) 13:49:45.64ID:4dXA0uuo
ダングリングポインタを作らない、に尽きるんじゃないの
2021/10/18(月) 14:15:47.57ID:CRhgpEvH
変数の寿命が有限になった原因は2種類ある
スタックとヒープ
一部の言語ではヒープの定義をライブラリに丸投げするから言語仕様で定義しない
あとはスタックを定義するだけ
244デフォルトの名無しさん
垢版 |
2021/10/18(月) 15:25:39.78ID:fRkWn8Ak
237のような気持ち悪い信仰がとてつもなくrustの普及を阻んでいる。
245デフォルトの名無しさん
垢版 |
2021/10/18(月) 15:42:51.62ID:r9t2S6+p
メモリ破壊やリークが絶対存在しないプログラムでも
データ次第ではいくらでも飛ばせる
246デフォルトの名無しさん
垢版 |
2021/10/18(月) 16:41:38.35ID:a937BLhH
なんかずれていってんな。
誰も万能とか言ってないのに、あくまでも他言語と比較しての話なのに。
247デフォルトの名無しさん
垢版 |
2021/10/18(月) 17:24:02.54ID:+nrbTxfF
rustはgc使わずにメモリ解放できるから速くて安全ということなのだと思ってたけど、そういう単純な話でもないのかな
2021/10/18(月) 17:55:52.34ID:sVAVzshE
奴隷はrust使ってくれた方が助かる
2021/10/18(月) 18:18:29.34ID:W4UMdHtn
優秀な人からRustへ流れてるよな
C++が言語として完全敗北してしまったところが興味深い
2021/10/18(月) 18:26:09.16ID:sw4A5qdT
Rustのセールストークなどに惑わされず
Rustがやろうとしたことを冷静に理解しきってるのがC++erという
C++を知らなかったりニワカ知識だったりする人が騒いだり対立を煽って楽しんでる
2021/10/18(月) 19:13:39.89ID:gU1bKDav
>>250
C++とRust両方のプログラミングができるならば
C++の欠陥であるポインタ使用ミスがあってもコンパイルが通りメモリ問題を引き起こしてきた件をRustが解決したと理解できるはずだが
2021/10/18(月) 19:54:57.93ID:sw4A5qdT
いたずらに否定したりせず
慈しみ、見守ってるってこと
2021/10/18(月) 20:29:15.76ID:CRhgpEvH
トークがどれだけうまくなっても人の話を聞かない相手には効果がないよな
聞き方や読み方のレベルを上げた方が早い
254デフォルトの名無しさん
垢版 |
2021/10/18(月) 20:40:39.51ID:9iPUXHWE
C/C++理解してれば
Rustは不要ですよ
2021/10/18(月) 20:44:49.04ID:oPyph5kC
むしろrustで問題解決とか言ってるやつのc++コードがどれだけひどいのか観て見たくなってきたわw
2021/10/18(月) 21:28:21.41ID:CRhgpEvH
事実が見えるまで粘るより仮定した方が早い
2021/10/18(月) 21:57:02.11ID:W4UMdHtn
もしC++がRustに勝る点が一つでも残っていれば
C++しか書けない人がこれほど発狂することなかったろうに
258デフォルトの名無しさん
垢版 |
2021/10/18(月) 23:49:18.78ID:k0GYnhD+
超次世代言語Dart
2021/10/19(火) 01:27:04.57ID:PbORd8vw
C/C++で完璧なコードかけるならどこいっても歓迎されると思うよ
それが誰もできないんだからrustに流れてるってことでしょ
2021/10/19(火) 03:17:45.56ID:+8M5kAvN
>>259
いや完璧なコードを書けるというのが勘違いであり凄いプログラマーでも間違いを起こすことがある
だからこそ人間頼みではなくコンパイラがチェックした方が良いと誰もが辿り着いた
261デフォルトの名無しさん
垢版 |
2021/10/19(火) 05:43:42.06ID:mawS91w/
>>255
俺も。
メモリーの確保解放ですべて解決みたいな主張してるから余計に不思議。
262デフォルトの名無しさん
垢版 |
2021/10/19(火) 07:01:04.92ID:3gMaYVXy
俺はここの耄碌よりGAFAMを信じますけどね
2021/10/19(火) 07:40:41.53ID:HngacVLx
自分で考えろ低能
2021/10/19(火) 07:49:05.09ID:+Znhh+E9
GAFAM？
FAANGじゃなくて？
Mって何？
2021/10/19(火) 08:22:28.00ID:0uJXMEOT
自分で考えている時には命令文や疑問文を使う必要がない
否定文なら使ってもいいけど
2021/10/19(火) 08:25:01.48ID:L5e5F1nS
>>264
Google
Apple
Facebook
Amazon
Microsoft
2021/10/19(火) 08:47:54.47ID:T9srRJav
GoがC/C++/Rustに比べて若干遅くなる要因ってGC以外なにがあるの？
2021/10/19(火) 08:56:27.98ID:9axoCOPN
二番目はAppleと言われてるけどどう考えてもAmazon
ケツから将来性の無い順番で消える、つまりGAFAMのMが消えてGAFAになったので
次のAppleが消えてGAFになる
2021/10/19(火) 09:55:30.99ID:T9srRJav
GAFAMって言葉が生まれたのはGAFAより後では？
MSをハブったらかわいそうってことで生まれたような
将来性が一番微妙だからハブられてたんかもしれんけども
270デフォルトの名無しさん
垢版 |
2021/10/19(火) 10:09:08.48ID:L/QTVpd7
まあFacebookよりは明らかに上やから入って当然ではある
2021/10/19(火) 13:41:00.66ID:HngacVLx
国産検索エンジンはなぜつぶされるのか
272デフォルトの名無しさん
垢版 |
2021/10/19(火) 19:00:05.85ID:089JTvXc
Crystal入れてちょんまげ
273デフォルトの名無しさん
垢版 |
2021/10/19(火) 19:37:36.30ID:OaBrXs9n
crystalはrubyライクという以外あまり特徴がないよな。次世代言語としてどこで存在感出せばいいのか
274デフォルトの名無しさん
垢版 |
2021/10/19(火) 20:15:37.83ID:LrPlA7Vp
>>254
一人で作業するなら好きな言語使えば？
275デフォルトの名無しさん
垢版 |
2021/10/20(水) 09:10:49.09ID:OEiI06HQ
>>261
++
276デフォルトの名無しさん
垢版 |
2021/10/20(水) 16:10:03.72ID:lLepbwfw
Nim version 1.6 is now officially released!
2021/10/21(木) 09:29:50.15ID:Hd41fW1K
Nimくん自分とこのスレに書き込まれずにこっちにばかり話題が来るのちょっとかわいそうになってきた
278デフォルトの名無しさん
垢版 |
2021/10/23(土) 00:34:45.65ID:o3xA5lbA
>>273
Crystalの開発は、Rubyの特徴である優雅さと生産性の高さ、コンパイラ言語の特徴である実行速度の速さと
効率の良さと型安全を目的として、2011年6月に開始された。バックエンドにLLVMを利用することによって
効率的な機械語を生成することができる。
他のコンパイラ言語と比較して、高度な型推論とユニオン型の組み合わせによって、高水準スクリプト言語の
ような簡潔な記述を実現している。
Goに影響されたファイバー間の通信を行うための軽量なチャネルとファイバーが実装されている
2021/10/23(土) 01:42:06.05ID:psrWRCod
俺が思うに
このスレに登場する言語は次世代言語なんかでは無く
狂信者がいる言語にしか見えない
次世代言語の話してるのに「C++」という単語の出現頻度の高さがそれを物語ってる

旧来の狂信者がいる言語と新しい狂信者がいる言語の
宗教戦争の場がこのスレだと感じた
2021/10/23(土) 08:56:00.74ID:qfDvYrOr
気がつくのが遅いよ、きみ!
2021/10/23(土) 10:07:43.64ID:rv17aNSC
>>279
ちょっと前まではC++が最速最強言語だったからでしょう
ただし唯一の欠点がメモリ安全でないコードも生じ得て現実にセキュリティ脆弱性なども招いていること
そこで次世代言語としてC/C++と同じく最速でありつつメモリ安全性を保証する真の最速最強言語Rustが登場したことから旧世代のC++が比較対象として話に出るのでしょう
2021/10/23(土) 11:45:11.96ID:kIBEGvOM
むしろアニメの登場人物全員JKにするみたいな奴が狂信者
爺婆はいても信者はいない
283デフォルトの名無しさん
垢版 |
2021/10/23(土) 12:14:12.92ID:OTpUh678
c++の唯一の欠点とかw
2021/10/23(土) 13:05:15.91ID:kIBEGvOM
賛成とか反対とか言えなくてへらへら笑ってるのも悪いんだよ
2021/10/23(土) 15:14:01.04ID:kbstlDmN
>>281
結局最速にするにはunsafeするやん。そういう誤魔化しをあえて語らんところが信用を失うんだよ。
286デフォルトの名無しさん
垢版 |
2021/10/23(土) 17:40:45.89ID:o3xA5lbA
rusterの気持ち悪いのが一番嫌い、お前が自分とこの発音で盛り上がるスレに書いてろ
2021/10/23(土) 17:46:02.31ID:Usgnsf5k
最初から全部unsafeで書けばいいのに
2021/10/23(土) 18:07:07.88ID:A4VxVCoL
>>285
意味不明
比較ベンチマークのRustプログラム等を見ても普通のアプリのRustソースを見てもunsafeは出てこない
2021/10/23(土) 18:10:31.38ID:dzQukzcx
RustってC++のmoveが楽になった言語の認識だったけど
ここ読むと捉え方ちがうような気がしてきた
2021/10/23(土) 18:12:33.07ID:rnZCdbOY
>>288
競プロでもしてんじゃね
2021/10/23(土) 18:14:14.05ID:kIBEGvOM
最安で欲しい物を手に入れる方法が購入ではなく盗むことだとしたら盗むか？

unsafeで最速にするというアイデアはそういうイメージ
2021/10/23(土) 18:26:04.70ID:A4VxVCoL
>>289
メモリ安全性保証などの話は別にしても
C++は最初の小さな家Cを何度も建て増ししてきたような言語
Rustは最初から最新のパラダイムを洗練して採り入れた言語なのでプログラミングのしやすさがかなり違うかな
293デフォルトの名無しさん
垢版 |
2021/10/23(土) 18:53:49.04ID:OfW/Ted4
誰もがc++ありえんと思ってて、代わりの候補もたくさん出てきた中で、ようやく使い物になりそうなのがrust
2021/10/23(土) 19:14:18.65ID:JF+Bwqfj
C++が互換性を無視して不必要な機能をばっさり切り捨てることができればだいぶましな言語になる気がするけどそんなことはできないんだろうな。
2021/10/23(土) 19:41:04.11ID:kIBEGvOM
互換性がないバージョン1から3があるなら
最も不必要なのは2なんだよ
2を無視して1の互換性を重視するのは言うほど悪くない
296デフォルトの名無しさん
垢版 |
2021/10/23(土) 20:21:23.52ID:8QkqEddx
たしか、あわしろ氏がLinuxをRustで書き直すプロジェクト始めたはず。
2021/10/23(土) 20:24:24.83ID:rnZCdbOY
どこで？
298デフォルトの名無しさん
垢版 |
2021/10/23(土) 21:01:07.99ID:WtF24tRL
>>285
0か100しか認めないタイプか？
ストレスでハゲてそうだな。
299デフォルトの名無しさん
垢版 |
2021/10/23(土) 23:36:13.26ID:rsO/lln+
Rustは難しい言語ではない。気軽に始めてみるところからスタートしよう。Rust活用企業の現場に聞いてみた
https://engineer-lab.findy-code.io/rust

松本おおおおおおおお！
2021/10/24(日) 14:51:32.96ID:x5aKIXa7
FacebookはReactとかVRあるから日本でも結構重要なポジションになりつつあるな
SNSは全然流行ってないとしても
2021/10/24(日) 17:16:59.20ID:MlWNQcCM
c++の安心側に制約を追加したSmart c++は欲しい。Rustは要らない。
2021/10/24(日) 18:13:51.90ID:NLtlOSxj
D言語の話した？
303デフォルトの名無しさん
垢版 |
2021/10/24(日) 19:18:02.70ID:4GW3Pp+f
F#……
2021/10/24(日) 20:44:53.71ID:x5aKIXa7
F#って結局何作れる言語なの？
2021/10/24(日) 23:46:02.08ID:J36a/Om9
>>301
プログラミングしやすいRustがあるのにC++ベースにはもう戻りたくないよね
2021/10/24(日) 23:51:33.94ID:x5aKIXa7
そういえばWebAssembly Studioなんてのがあるのを最近知った
https://webassembly.studio/
307デフォルトの名無しさん
垢版 |
2021/10/25(月) 00:38:46.00ID:Zg5tRANc
>>301
c++23で契約プログラミングが標準化されたら改善するかも？
308デフォルトの名無しさん
垢版 |
2021/10/25(月) 00:42:01.96ID:Zg5tRANc
そういやrustって契約プログラミングをサポートする文法あったっけ？
2021/10/25(月) 01:31:51.79ID:13mKJPww
https://crates.io/crates/contracts
2021/10/25(月) 23:17:33.61ID:vPVmdF1Z
結局、データの共有かコピーかが楽に設定できるかどうかってことに焦点が当たって、
rustは捨てられることになるよ。
こんな明らかなことさえわからん連中ばっかなのが面倒ごとだな。
2021/10/25(月) 23:55:02.93ID:Hh6pHipi
コピーの反対はムーブかもしれないので、コピーの反対は共有だろうという雑な考えを捨てよう
312デフォルトの名無しさん
垢版 |
2021/10/26(火) 10:23:33.99ID:oHFZf85O
>>267
goroutineのネイティブスレッドとM:N関係。軽量と言っても、当然、中でコンテキストスイッチのように
実行の切り替えがある。他の言語は（機能が）無いので真っ当に比較出来ないが、ほかの言語で似た外部の
ライブラリを入れるとgoより重たいし、nodeのように、I/Oバウンドな非同期しかないと1つが詰まったら
全部止まるデメリットがある。goのGCが遅めなのは、当然、このgoroutineの並行性における不可分操作が
難しいからであり、rustのRc/Arcやnimの--gc:arc/orcに比べ並行性を保ちながら参照カウントを不可分の
操作にするとコストがとても大きくなるためと言われる。多くの人が勘違いしているのは、理論上はRcより
（トレース系のGCは）GCのほうが効率的（高速化が望める）だ、ただしGCはネックが生じる
2021/10/26(火) 11:22:52.21ID:UCZJSiVy
バカが老害ガー言われ始めるのに大体１０年くらいかかる。
こうして流行は終わる。
314デフォルトの名無しさん
垢版 |
2021/10/27(水) 12:05:58.55ID:6tzLPjk/
Crystal入れてください
2021/10/27(水) 14:14:45.58ID:P9D6Cr2V
存在感微妙だし。nimもいらんな
2021/10/27(水) 15:48:46.91ID:G9Y5/nKM
Zigでもいれとく？
2021/10/27(水) 16:26:23.01ID:Jg7L84/d
Vがいいかも
2021/10/28(木) 12:19:59.27ID:pk2ZbUG1
Vの良さでも語ってくれ
情報少なすぎてよく分からない
2021/10/28(木) 13:00:24.39ID:owG9GWEY
あれは詐欺だろ
320デフォルトの名無しさん
垢版 |
2021/10/29(金) 00:13:25.52ID:RD2SEv+6
vlangは0.3が全然出ないね。mutを後から導入したのがよほど不具合頻発になったのだろうか
2021/10/30(土) 02:12:19.09ID:CsJIfRO2
次に取り沙汰されるのはKokaみたいなAlgebraic Effectsのある言語だと思う
2021/10/30(土) 02:29:08.63ID:qGEfyGin
取り沙汰される、って何年後のことやねん
やたら表現力高そうだし、ベストプラクティスがなかなか定まらなそう
2021/10/30(土) 03:11:26.17ID:U9OTRLVf
rustだgoだと言ってたら一瞬Vが騒がれて消えてなくなって今はnimなの？
今ならrustでいいじゃん
クッソ速くて賢くて小さくて安全でどこでも動いて便利な使いやすい言語誰か作ってくれ
一番大事なのは速いことな
2021/10/30(土) 08:15:37.97ID:fF4OSUNs
Nim is efficient, expressive, and elegant.

どこらへんがどうエレガントなのか謎やわ
2021/10/30(土) 10:49:51.87ID:5VdQtJkF
「エレガントさ」とか「楽しさ」で売ってる言語はクソの法則
2021/10/30(土) 11:52:44.92ID:YSY9yYdl
他の言語の存在を無視したりOSの存在を無視したりしたら
まともな説明ができなくなる
空虚な言葉を使うのは原因というよりむしろ結果
2021/10/30(土) 13:21:47.38ID:U9OTRLVf
むしろ複数のコンピュータをまとめて1つの環境として扱い、その環境で最適化して実行可能な言語を作ってくれ
2021/10/30(土) 13:40:35.45ID:OQ2dRDm5
>>327
速度優先とメモリ効率優先は誰が決めるの?
2021/10/30(土) 14:03:03.78ID:U9OTRLVf
>>328
細かい部分は最適配分して決めるとしか
最初は適当なヒューリスティックでいい
330デフォルトの名無しさん
垢版 |
2021/10/30(土) 22:25:15.35ID:G/S2+R78
>>324
公式は3つ挙げてる。macro記述と言語そのもの差異がほとんど無いことを挙げている。$aとか別言語になったり
してない。もう１つはpython風の構文がエレガントだと言っている（これはpython風の構文を多くの人が嫌うの
で賛否が分かれると思う）もう１つは多くの言語が該当するので書かない。個人的にはvar/letじゃなくlet mutや
いちいち打つ::や、マクロで!とかの方がエレガントだと思わんけど、goでいえばpanicがあるのにtry/catchが無い
（多値戻りの2番目にerrorを入れてif判定させる）、genericsがまだ無いのもエレガントとは思えない
331デフォルトの名無しさん
垢版 |
2021/10/30(土) 22:27:20.82ID:G/S2+R78
>>327
Juliaでは、標準ライブラリの一つとして提供されているDistributedモジュールで分散メモリ並列計算を実装して
いる。Juliaのベースインストール状態では、2種類のクラスタがサポートされる。（1つはローカル）
・複数のマシンからなるクラスタ。--machine-fileオプションで指定する。パスワードが不要なSSHを
用いてJuliaのワーカプロセスを指定した計算機で分散される
@distributed for i = 1:100000
a[i] + b[i]
end
こういうのが１つの実行環境で複数のコンピュータでクラスタ実行される
--machine-fileで
3 164.67.165.21 # 3process
5 164.67.165.22 # 5process
332デフォルトの名無しさん
垢版 |
2021/10/30(土) 22:36:16.21ID:G/S2+R78
まあmacro記述を簡単にインライン展開するために別言語風になるのも分かるけど、、名前衝突が起きないように
デフォルトで別名に自動で名前を付けて展開してインライン展開する場合は特殊タグを付けるほうが
2021/10/30(土) 23:31:55.44ID:U9OTRLVf
>>331
そんなの言語レベルのサポートいらんやん
分散も並列化も勝手にやってくれ
プロセスもマシンも意識したくない
意識してもいいけど必須じゃなく、自動で可能な限り適切にリソースが配分されてほしい
プロセスとかそんなざっくりした単位でもなくね
それが実現可能な言語を用意せよと言っている
2021/10/31(日) 00:40:29.24ID:Qz/5KmYR
それって言語じゃなくてOSとか別のレイヤーが果たす役割じゃね？
335デフォルトの名無しさん
垢版 |
2021/10/31(日) 00:43:34.15ID:e5ZzvOAs
言語レベルサポートが無いということは、分散も並列化も勝手にやったら不可分解の通常のforループも
分解されてしまうので、そんなことは不可能。繰り返し順次実行と、（表現上は繰り返しだが）並列実行
では意味も結果も異なる。
要らないというコンピューター言語学での証明は無い。思想的には集合要素に対するmap/reduceなどが
並列の操作ができるからと言って、forだけで表現できる語彙ではない。言語の標準ライブラリにreduce
などのAPIがある事は、それそのものが（並列に実行していないのに）並列性の表現と同じ意味。
CPU側でそれが並行操作可能か、何らしらのマーカーは必要というのは素人以外はすぐ分かる事
>”言語を用意せよと言っている”おまえ何様やねんｗ
2021/10/31(日) 00:44:58.68ID:LjLsZLEJ
プログラミング言語という概念すら理解してないのがこのスレの住人のレベル
337デフォルトの名無しさん
垢版 |
2021/10/31(日) 01:28:26.60ID:e5ZzvOAs
>>334
その通り。分散コンピューティング/グリッド・コンピューティングなどではミドルウェアが利用される。
Erlangなどでも、分散処理できるがspawn(node, ...)などノードを意識しなくてはならない。また
CPU処理が分散できたからと言って、ファイルシステムなどローカルしかないため、大規模分散には
分散ファイルシステムが必要になり、Googleのようにbigtableができ、その上で耐故障性を備えるように
仮想化して、スケールアウトやオーケストレーションのためにkubernetesなどなど、別レイヤーが
果たす役割が多い
2021/10/31(日) 01:35:34.83ID:sAwtPlvj
そういうことじゃないｗ
俺様が言ってるのはマシン/アプリ/ライブラリ/OS/デバイスの垣根を超えて
言語とそれらの複合環境がカバーしうる汎用な表現が可能な言語やｗ
作れｗ
339デフォルトの名無しさん
垢版 |
2021/10/31(日) 01:43:15.98ID:e5ZzvOAs
基地外かあ…、この業界こういうの大杉壮大な能無し基地外のかまってちゃん
2021/10/31(日) 01:47:23.36ID:sAwtPlvj
例えば組み込み制御系で使えばCの配列を作るのと同じ記述でスケールしたら分散KVSもどきやらが出来上がるような言語
並列実行可能かどうかはあるロジックの入力が別のロジックの出力を使ってるかどうかだけ
2021/10/31(日) 01:58:47.24ID:sAwtPlvj
できそうにないだろ？
既存のアーキテクチャにどっぷりなら
高速にぶん回したかったらrustでもC++でもgolangでも使えばいいし
スケールするだけで十分な速度が出るなら誰でも使える言語を使ってスケールすればいいし
僅かに違う新しめの言語の差分をネタに趣味・嗜好を語るよりは夢を語った方が有意義でないかい？ｗ
2021/10/31(日) 02:01:52.96ID:dE1SXutD
Common Lisp
343デフォルトの名無しさん
垢版 |
2021/10/31(日) 02:08:26.79ID:e5ZzvOAs
おまえのチンポコの穴から並列でションベン出来るか考えてロンパーロンパーしてろｗくそ基地外ｗ
344デフォルトの名無しさん
垢版 |
2021/10/31(日) 02:12:58.45ID:e5ZzvOAs
おまえがいるだけで世の中迷惑、人の足引っ張りまくり、親に迷惑かけまくり、誰もがお前を見ると顔をしかめる。
クズの癖に１つも優れた能力も、努力もなく、相手を貶し、悦に入る
問題の原因の根本たるおまえが消えて無くなれば、よほど有意義
345デフォルトの名無しさん
垢版 |
2021/10/31(日) 10:57:39.56ID:dKAtRzTx
LISP専用CPUとRISC-CPUを聴き間違えたけど同じもの？
2021/10/31(日) 11:13:06.97ID:gOKmIPxI
>>330
微妙だね。
マクロもオフサイドルールも賛否分かれそうだし、最後に至っては「Goよりはエレガント」ってｗ
347デフォルトの名無しさん
垢版 |
2021/10/31(日) 12:55:57.25ID:o3yW9Bfn
>>346
公式はgoと比べてる訳じゃないよ？
2021/10/31(日) 13:41:46.14ID:nF8ypkXG
Goは断捨離の観点でエレガント
try throw catchなんか無くても関数は返り値をエラー値とタプルで返せばいいし
classなんかなくても構造体と関数でいいし
イテレータなんか使わずともfor回せばいい
2021/10/31(日) 13:50:44.46ID:5SuYQG0J
落ち着いていて品のよいさま。上品。優雅。エレガン。
（考え方や手法などが）簡潔で要を得たさま。手際のよいさま。明快なさま。

抽象度は高めたほうが優雅なのでは？
2021/10/31(日) 13:56:01.91ID:sAwtPlvj
昔のperlみたいにならないよう糖衣構文やそれに類するモノはどちらかに振った方がいい(エレガントな)こともある
結局は好みだけどなｗ
2021/10/31(日) 14:23:30.67ID:512CMESs
中置記法をユーザー定義する構文糖を否定したやつは失敗
PythonとC++は少なくともその失敗をしなかった
2021/10/31(日) 15:04:58.04ID:OVPW0Dsp
Nim言語では最近特定のunicode文字を2項演算子としてオーバーロードできるようになりました。
unicodeにある文字を演算子として使うのは文字を入力し辛いとか∪∨がアルファベットのUVと似ていて紛らわしいとかで反対派もいるようですが。

https://nim-lang.org/docs/manual.html#lexical-analysis-unicode-operators

proc `*` (x: Dollar, y: int): Dollar =
result = Dollar(int(x) * y)


みたいな感じで'*'演算子を定義できます。

https://nim-lang.org/docs/manual.html#procedures
2021/10/31(日) 15:42:26.32ID:OVPW0Dsp
Nim言語にはtype classというのがあって、これを使うと特定の種類の型のみに限定されたgeneric procedureを簡単にかけます。
詳しくは
https://nim-lang.org/docs/manual.html#generics-type-classes

Nim言語ではprocedure/template/macroを呼び出す方法が複数あって、
foo(arg1, arg2)という普通の書き方に加えarg1.foo(arg2)というオブジェクト指向のメソッドぽく呼ぶMethod call syntaxと括弧を省略してコマンドラインぽくfoo arg1, arg2と書くcommand invocation syntaxがあります。
https://nim-lang.org/docs/manual.html#procedures-method-call-syntax
https://nim-lang.org/docs/manual.html#procedures-command-invocation-syntax
2021/10/31(日) 15:50:59.21ID:15Fr5KXV
実に表現豊かでエレガントですねぇ…☺
2021/10/31(日) 16:18:17.43ID:nF8ypkXG
>>353
type classは関数型言語Haskell発祥
そのNimのページを見る限りその貧弱なおもちゃ版に見える
例えばNimと同じ手続き型言語のRustのtraitも用語は違えどtype classなので比較するとわかりやすいが機能面でも型付け面でも強力
356デフォルトの名無しさん
垢版 |
2021/10/31(日) 17:04:32.64ID:r7nTmIjE
>>348
言ってる事はその通り。goで構文上、覚える事の少なさは”非常に良い”が、上の簡潔で要を得たさまを借りて
言えば、finallyに相当するdeferはあるのに、?演算子が無いだけでerrが2番目というルールでifを多発させる。
これはRust/Swift/HaskellのResult/Option/Either標準伴うルールとほぼ同じだが、?演算子が無いだけで
if err != nil { return nil, err }を書かなくてはならない。あるいは(panicではなく)exceptionに対する
try/catch/finallyとも言い換えることが出来る
2021/10/31(日) 17:32:36.81ID:Qz/5KmYR
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
このドラフトでもRustの?演算子とかが言及されてるけど、そういうのはやっぱ欲しいわ
358デフォルトの名無しさん
垢版 |
2021/10/31(日) 18:15:22.28ID:4KbMhR6u
演算子なら
∩∪⊕
あたりは欲しい
359デフォルトの名無しさん
垢版 |
2021/10/31(日) 18:21:20.58ID:d0afoHzs
>>355
最初に実装されたのはHaskellだがコンピュータサイエンスではもっと早く提唱されていた。NimはAdaから影響で
Haskellからも影響は当然あるが、範囲型の実装などはAdaから来ていると一般的には言われる。逆に、Rustは
機能面でHaskellのType classはフルセットでサポートしていない。traitは別の概念でType classを一部限定して
サポートしているに過ぎない。範囲型すら無いし、type c = a or cなんて出来ない、それとコンパイラ言語で
型付け面が強力では無い言語なんていまどきの言語なら珍しい、ランタイムが無くnative-compileなら尚更。
360デフォルトの名無しさん
垢版 |
2021/10/31(日) 18:42:57.86ID:d0afoHzs
Goに関して言えばユーザー定義のiteratorは何度もproposalされて撥ねられてるがいずれ入るちゃうかな？
演算子に関して言うならinや->,=== ,<>,instanceofなんていうものが世の中あるので、UTF-8/16で
関数名が書ける言語なら、uniform-func-callが出来る言語ならなおさら出来ないのはおかしかった
2021/10/31(日) 20:07:49.45ID:yTUS2Zye
>>359
typeのorならばRustでも色んな複数の方法で様々なアレンジ付けて出来るよ
例えばi32と&strのorをそのtraitを用いてするのも可能で
trait I32OrStr {}
impl I32OrStr for i32 {}
impl I32OrStr for &str {}

fn print<T: I32OrStr + std::fmt::Display>(x: T) {
　println!("{}", x);
}

fn main() {
　print(100);
　print("abc");
}
これでi32と&str以外の型は受け付けないprint()関数の出来上がり
あとtraitとimplの中身が{}で空なところにアレンジを書いたり
2021/10/31(日) 20:24:12.66ID:yTUS2Zye
例えば素朴な例だけどこんな感じ？
trait I32OrStr {
　fn info(&self) -> String;
}
impl I32OrStr for i32 {
　fn info(&self) -> String {
　　format!("{} <-- i32", self)
　}
}
impl I32OrStr for &str {
　fn info(&self) -> String {
　　format!("{} <-- &str", self)
　}
}

fn print<T: I32OrStr>(x: T) {
　println!("{}", x.info());
}

fn main() {
print(100);
print("abc");
}
これで>>361と同じくprint()関数はi32と&strしか受け付けないけど
実行結果は>>361と異なり型毎に別表示
100 <-- i32
abc <-- &str
2021/10/31(日) 20:38:03.38ID:yTUS2Zye
trait利用でなくもちろんenum利用で型のorも可能ですね
使い勝手が異なるのでRustでは両者を使い分け用いることが出来ます
enum I32OrStr<'a> {
　I32(i32),
　Str(&'a str),
}

fn print(x: I32OrStr) {
　match x {
　　I32OrStr::I32(n) => println!("i32: {}", n),
　　I32OrStr::Str(s) => println!("&str: {}", s),
　}
}

fn main() {
　let n = I32OrStr::I32(100);
　print(n);
　let s = I32OrStr::Str("abc");
　print(s);
}
2021/10/31(日) 22:21:09.61ID:rLjO7mCc
>>356
それくらい書けやとしか思わんわ。
まあパターンマッチで変なnullチェック減らすとかは入れてもいいと思うが。
2021/10/31(日) 23:58:11.44ID:sAwtPlvj
rustってデフォルトだと共用体みたいな形になるんだっけ？
366デフォルトの名無しさん
垢版 |
2021/11/01(月) 08:07:15.03ID:cuJVsFXJ
だからそれはtraitでありtype classじゃないでしょ。どっちが”貧弱なおもちゃ”やねん。こんな単純な事を
表現するためにクダラナイ事を何度も何行も貼り付けるなよ。もう一つについてはTagged Unionだが、Adaも
Swift/Nim/Pythonも出来るし、”両者を使い分け用いる”なんて必要ない。そもそも単純に書こうとしたら
or表現や、Typescriptのようにtype C = A | B;部分型だし、このように表現するのが限りなく一般的で
一行でシンプルです。Rust唯一教徒の話は回りくどい上にキモ過ぎる、別にRustそのものを否定している訳じゃ
無いし、traitは他にあまり無い十分に柔軟性がある特性なんだから、奇妙な信仰的な推し方をすんな
367デフォルトの名無しさん
垢版 |
2021/11/01(月) 08:14:17.55ID:cuJVsFXJ
go2もgenericsと関連して、Tagged union的なType set/Type list/Sum typeが入るはず
2021/11/01(月) 10:40:50.02ID:GebKB2vN
めっちゃ早(ry
2021/11/01(月) 11:40:40.03ID:vX/UhvAM
趣味・嗜好は昇華して信仰になる！
実際に共用体になるのとポインタだけ入るのを同じに分類したら何でもありな気はするｗ
2021/11/01(月) 23:50:22.01ID:HKf+kmzN
>>366
それは君の理解が浅く、君が間違っている。

まず、Rustのtraitはいわゆるtraitとは異なる。
つまりシェリルのtrait論文に従う他の言語のtraitとは異なっており、
複数traitでメソッドの名前衝突重複が起きたときに、メソッドの排除や名前の変更利用などのtraitが満たす条件を備えていない。
一方でRustのtraitでは重複自体は許して、メソッド呼び出しは一意性がないため許さず、関連関数呼び出しが自由に許される。

次に、Rustのtraitはいわゆる(Haskellの)type classに基本的な部分で合致している。
一番重要なところでいうと、Rustのtrait境界はHaskellのtype class制約である。
もちろん一般的なtraitにはこのような概念機能はない。
つまりRustのtraitはtraitではなくtype classであることがわかっていただけると思う。きちんと理解しているならば。
2021/11/02(火) 01:20:08.88ID:Ou8VP/7A
そもそもB | Cのようなad-hocな型制約をRust開発者が好まないというだけのことだと思う
関数オーバーロードもC++のテンプレート特殊化みたいなのも無いし
372デフォルトの名無しさん
垢版 |
2021/11/02(火) 01:42:04.85ID:GkRdNW5V
はあ…基地外が一生懸命調べて反論してるって感じだな、何が論文だ？気持ち悪りぃ

”一番重要なところでいうと、Rustのtrait境界はHaskellのtype class制約である”
Type classは制約だけではありません、アドホック多相を実現するための機能です。概念だけなら20年前の
Haskellから影響を受けているのは近代的な言語なら当然ですが、RustのtraitはHaskellのType classではなく
実装はSubtypingです。そもそも”貧弱なおもちゃ”に負けてるRange typeとかSum typeとか、Typescriptに
すらあるのに無い事、無理やりコードを書いて実現しようと自己弁護している事、Rustの書き手が減るような
非常に醜い弁護行為なので止めなさい

”つまりRustのtraitはtraitではなくtype classであることがわかっていただけると思う”
日本語でも、英語でも理解してますか？他の言語のtraitとは同じだと誰も主張していませんよ？そもそもこれも
因果関係が逆転しています。type classの「ほんの一部」を実現するために(rustの）traitを用いているだけです。

きちんと日本語と英語を理解しているならば、このような「間違い」は起きないはずです。それは君が理解が
難癖を付けたい基地外であり、おまえのような態度が気持ち悪い奴らRustの発展を阻害しているのです。
2021/11/02(火) 02:02:23.69ID:AchKVKlJ
ググってみたがRustのtraitは普通のtraitではない話がたくさんあるな
あとRustのtraitはHaskellの型クラスだという話も多数あるな
世間での認識は>>370で合ってるんじゃね？
374デフォルトの名無しさん
垢版 |
2021/11/02(火) 02:15:11.25ID:GkRdNW5V
ID変えてまた自己弁護、市ね基地外
2021/11/02(火) 07:36:44.59ID:+/VenZ/0
ようはCommon Lispみたいなマクロ使える言語が最強って事だろ？
2021/11/02(火) 08:27:57.62ID:65SbHznP
>>372
Rustで実装できない具体例を挙げたら？
そっちの方が早い。
377デフォルトの名無しさん
垢版 |
2021/11/02(火) 08:34:53.92ID:dHCyhX6F
>>375
せや、あんたが優勝や
378デフォルトの名無しさん
垢版 |
2021/11/02(火) 08:39:57.46ID:yi7goDxw
このクズは誰も言って無い事を言い出す、「他の言語のtraitとは同じ」「Rustで実装できない」
こんなことは誰も言ってない。
おまえはさ、Rustの発展にも、会社にも、社会にも邪魔だから消えろよ？おまえみたいのは、まだ技術が
浅く新しい人が入ってくる障害だからね
2021/11/02(火) 10:07:28.88ID:A2ISzYRE
>>378
お前は>>372？
じゃあ、「無理やりコードを書いて実現」についてのHaskellとの具体的なコードの比較でいいよ。
あと、「type classの「ほんの一部」を実現するために(rustの）traitを用いているだけです。」について、Rustのtraitで実装できないtype classのHaskell実装例。

まずはそれについて>>370に反論させりゃいい。
コードもないんじゃ傍から見ててつまらんよ。
2021/11/02(火) 11:09:50.76ID:cXpPn69w
人の話を聞くのは正しいことかもしれないが
つまらない話を禁止したり面白い話を強制するぐらいなら人の話を聞かない方が正しい
2021/11/02(火) 11:15:37.18ID:Svesn2Xo
両方とも気持ち悪いなと思ってたら
もう一人気持ち悪いのが出てきたww
いつもの次世代wスレ
382デフォルトの名無しさん
垢版 |
2021/11/02(火) 11:48:12.43ID:Hfhc0VzY
また違う人物のふりして出現か、傍から見てる人が「お前は」なんてイキナリ怒り心頭顔真っ赤で言うかよ。
おめーがつまんねえから
2021/11/02(火) 12:12:25.90ID:cXpPn69w
C++のtemplate引数はダックタイピング
ダックタイピングは気持ち悪い
HaskellとRustは気持ち悪くない

マクロ引数の問題はtemplate引数よりも更に気持ち悪い
2021/11/02(火) 12:29:54.01ID:LR6fq+wY
Haskellを悪く言うやつを見たことがない
もう全部Haskellでいいよ
2021/11/02(火) 13:43:18.32ID:aJCYG77w
C++もね、conceptでだいぶマシになったんだけどね
そもそもどれだけの環境でC++20が使えるんだという話をされるとぐうの音も出なくなる
2021/11/02(火) 14:57:01.19ID:jqcpDrr+
>>384
俺は毎日のように悪く言ってるよ
数学オタクが作った非実用的な言語だってな
387デフォルトの名無しさん
垢版 |
2021/11/02(火) 15:36:03.35ID:px0qcy1y
3人いようが4人いようがそれ以上でも
描き込み全部気持ち悪い事実は変わらない
2021/11/02(火) 16:14:12.44ID:TM2Ai9P9
お前らが気持ち悪さに敏感なのは良いことだと思う
気持ち悪さの応酬をして平気なツラしてるような地獄のスレもある
2021/11/02(火) 18:13:46.42ID:4qET4FIO
Nim言語にもconceptがあります。(まだexperimentalだけど)
https://nim-lang.org/docs/manual_experimental.html#concepts

conceptやtype classを使ってgenerics(c++のtemplateに相当)の引数に指定できる型を制限すれば気持ち悪さを軽減できるか思います。

けどNimのseq[T](C++のstd:::vector<T>、Rustのstd::Vec<T>に相当)のようなコンテナ型にはコピー可能な型なら何でも指定できるわけですが、こういうのが気持ち悪いと言われても指定できる型を限定すれば不便になるだけだと思うのですが。
2021/11/02(火) 22:59:17.06ID:N6sgsEFk
Nimの並列ってどうなん？何か特徴有ったりする？
2021/11/03(水) 11:54:22.69ID:Klx8o89d
ポケモンしか見つからんのですが
2021/11/03(水) 12:42:45.74ID:JMRJWcyj
キミに決め・・・られないｗ
393デフォルトの名無しさん
垢版 |
2021/11/03(水) 15:41:03.34ID:M0DzS1St
言語が気持ち悪いんじゃない
俺も含めおまいらが全員気持ち悪いんです。次世代言語と銘打ってるのにあの言語はこの機能がないからゴミだ
あの言語は（高尚な）Haskellが元だ、などなど。ポジティブな意見ではなく、ネガティブ丸出し全開なんです。

RFC for anonymous variant types, a minimal ad-hoc sum type
https://github.com/rust-lang/rfcs/pull/2587

高速ゼロコスト言語の次世代言語Rustだってこういう提案はされて、別言語の悪口なんて出てこないんです
2021/11/03(水) 15:54:38.31ID:JMRJWcyj
ネガってるのとそのレスに極端な反応してるのは他人を基地外呼ばわりしてる1人しかいないと思うんだけどｗ
他の人は他言語と正確に比較してるだけで否定的な論調もなく他人の趣味・嗜好を尊重してるｗ
2021/11/03(水) 21:11:03.58ID:Jc+nuIwU
バグ報告したら不正アクセスだって言われるのと似たような現象
2021/11/03(水) 23:58:41.87ID:UFPQir4N
まあ仕事で使う上では言語の強みより弱みや落とし穴を知っとく方が価値あるわな。
どうせ選ぶ権利ない場合がほとんどだし。
その辺が学生、アマチュアなんかとの差だろうね。
2021/11/04(木) 03:09:20.83ID:DB49gC4z
>>390
Nimでは競合状態を防ぐためにスレッド毎にガーベージコレクタで管理されたヒープメモリを持っていて、
グローバル変数以外スレッド間で共有できなくなっています。
そのおかげでガーベージコレクタが効率よく動きます。
コンパイル時にスレッド間でヒープメモリを共有していないかチェックします。

詳しくはこちら
nim-lang.org/docs/manual.html#threads

Channelを使ってスレッド間でデータのやりとりができます。
nim-lang.org/docs/channels_builtin.html

試験段階ですがthreadpoolモジュールにあるParallelとSpawnを使って並列処理できます。
nim-lang.org/docs/manual_experimental.html#parallel-amp-spawn
nim-lang.org/docs/threadpool.html

Nimの標準ライブラリじゃないのですがWeaveというパフォーマンス重視なライブラリもあります。
github.com/mratsim/weave
2021/11/04(木) 07:19:03.96ID:6aa/TylF
>>397
スドップザワールドもスレッド単位でしか起こらんということなん？
399デフォルトの名無しさん
垢版 |
2021/11/04(木) 08:00:34.54ID:iBQltfW1
>>385
現場で使えわせてくれるのはあと2,3年はかかりそうだな
400デフォルトの名無しさん
垢版 |
2021/11/04(木) 08:47:03.06ID:GROwH+E9
>>398
基本的にはストップザワールドは発生しないマーク＆スイープガーベージコレクタが今はデフォルト(refc)
ガーベージコレクタを選べるのでARC(rustと同じ)を選べばストップザワールドは無いが循環参照はリークする。
(これはrustも同じ）循環参照をガーベージコレクションするARC+サイクルコレクターがORCなって、ストップ
は起こらないが、少しパフォーマンスが落ちる。C系と相性の良いboehmとか、dllを作ってgoとリンクさせる
ようならストップザワールドが発生するガーベージコレクタを使用する場合がある

Multi-paradigm Memory Management Strategies（中段当たりの表）
https://nim-lang.org/docs/gc.html
2021/11/04(木) 10:57:37.34ID:lAAyXHqu
何を見ても聞いてもnimには一切興味がわかない・・・
なんというか特徴がなさすぎる
2021/11/04(木) 11:41:59.42ID:vVwsjj5J
Haskellとかもそうだけどオタクの中のオタクの間だけで持て囃されてる言語には近寄らない方が吉
403デフォルトの名無しさん
垢版 |
2021/11/04(木) 12:00:51.59ID:tx1xmHYz
Rustこそ至高の言語、NimとHaskellなんて糞、GoはまあGoogleがやってるから認めるけど
言語的にはジェネリクスも無い90年代の時代遅れ
NimだとかHaskellだとか、糞気持ち悪いオタクの匂いがする。どっちもゴミ
SwiftとKotlin、そしてTypeScriptともにスマホで使う
2021/11/04(木) 12:19:18.72ID:wrxqAvPZ
rustはこれからjavaになるんだろ
2021/11/04(木) 13:07:01.54ID:UnTZr4yd
>>403
Nimも悪くないとは思うけど
欲しい基本がまだexperimentalなど多いのと人口の少なさ
あと競合しているRustがコンパイル通ればメモリ安全性保証してるので
結論はRustでいいじゃんとなりました
2021/11/04(木) 13:17:36.87ID:fybR+JX+
Goが良いのは、関連エコシステムと、あと強いていうなら並列処理らへんぐらいかな。
プログラミング言語としてはさすがにしょぼすぎるけど、エコシステムが優れてるからなんだかんだ便利。
PythonとかJavaScriptとかはエコシステムが最強な言語の一つだよね。
逆にD言語とかはエコシステムがウンコすぎて使い物にならなかった。
2021/11/04(木) 13:19:04.19ID:bqbD3Nhm
Nimはなんか中庸って感じがする
そこにピッタリはまる人にはいいんだろうけど
もっと楽に書きたい人はGo、ちゃんと書きたい人はRustに流れてしまって
あまりユーザが増えないのではないかな
2021/11/04(木) 15:00:22.37ID:OXP1jNWB
オタク臭いやつと臭くないやつの違いは一般人でもわかる
TypescriptとGoとNimの違いがわかるのは重度のオタクだけだろ
2021/11/04(木) 15:11:34.22ID:lAAyXHqu
やっぱ言語の普及には有名企業の後押しがいるんか？でもrustってなんか後押しあったっけ？
まあ案件レベルだと全然ないけどｗ
2021/11/04(木) 15:13:41.91ID:F8fi5yeE
Nim少し見てみたけどインデントか、ちょっと苦手かも
2021/11/04(木) 15:18:21.88ID:fybR+JX+
大企業の後押しは必須ではないだろうけど、後押しあると強い、というか、やっぱエコシステムが育ちやすいと思う。
すぐに潰されない言語だ、って思って他の企業とかも投資できるからかな。
TypeScriptが人気あるせいか、Dartはなんかイマイチ広まりきれてない感じだったけどね。

Rustは新規ミドルウェアを作るような現場では需要あるんじゃないの？
2021/11/04(木) 15:26:36.67ID:8l/Jusr1
いまRust推しの大企業といえばAmazonだな
MozillaからリストラされたRustコミッタを相当取り込んでるし
影響力が強すぎるんじゃないかと不安視されるくらい
2021/11/04(木) 15:26:54.42ID:DB49gC4z
これは他のコンパイル言語にはあまりない特徴だと思うけど、Nim言語はスクリプト言語のように使うこともできる。
Nimはコンパイル時に実行されるコードをNimに埋め込まれたvirtual machine上で実行するんだが
このVMを他の用途にも使うことができる。

コンパイルに使う設定ファイルやnimble(RustのCargoのようなもの)ファイルをNimScriptで記述できる。
nim-lang.org/docs/nims.html
github.com/nim-lang/nimble

Nimのコードを拡張子がnimsとなるようにファイルに保存してnim myscript.nimsと実行すれば
実行ファイルを生成せずに実行される。
NimScriptにはFFIが使えないとか制限があるがファイル操作や他の実行ファイルを呼ぶことができるので
shellスクリプトやバッチファイルの代わりに使うことができる。

C/C++だとプログラムにスクリプト言語を埋め込むときはPythonとかLuaを使うことが多いと思うけど
Nim言語ではNimScriptを埋め込むことが可能。
github.com/beef331/nimscripter
2021/11/04(木) 15:32:39.45ID:DB49gC4z
>>410
どの言語を書く時でも基本的にはインデントするから
インデントでコードブロックを作ることによってソースコードの中に
{}とか;が頻繁にでてこないようにしたほうがソースコードがすっきりして読みやすくなると思うんだけどな。
2021/11/04(木) 15:46:29.06ID:4stXfNK+
>>414
ルールで言うならyamlみたいなインデント or カッコの両対応がいいんだけどねぇ。そんなの無いけど。
2021/11/04(木) 15:47:23.54ID:eo9m+3ij
行頭に } って書いてあると終わった感がある
2021/11/04(木) 15:51:50.87ID:fybR+JX+
Rubyみたいな do end もそんなに悪くなかったし、エディタのサポートがあれば慣れの問題かなあ、って気がしてしまう
2021/11/04(木) 16:30:26.61ID:62sZMwyh
>>414
それをすっきりして読みやすいと思うか、必要な情報が欠落していて読みにくいと思うかは個人差あると思う
個人的にはインデントの戻り量が視覚的に判断しづらいから } がないと読みづらく感じる
419デフォルトの名無しさん
垢版 |
2021/11/04(木) 16:40:09.48ID:oJ9Lbupd
int hoge = 1;
int hage = 2;
if ... {
　　hoge += 3;
hage = 4;
}
理論上は見た目とコンピューター的なパース処理を一致させる考えがPythonやNim、CoffeeScriptなどの
オフサイドルールという書き方。
上記の例でCなどから、主流で余分な空白を無視して波括弧 { と } でブロックを表すという記法が、C#や
Java、Rust、Javascriptなど。もう１つは、begin-endでブロック的なスコープを表す記法で、これは
Pascal/Delphi、Ruby、PL/SQL・TSQLなど。他は純関数言語でErlangやHaskellなどはこの限りではない。

Cなどの記法は、空白あるいはタブがどのような形でも{}が対応していて、;が１手続きの終わりであり
プログラマの好みによって、字下げ・字上げ・空白することが可能であるという利点がある。しかしながら
上のように書く人は居ない。{}の対応するかっこを上下位置で揃える古いK&R的な書き方をする人はいるが
近年のgolangのように、きっちりフォーマットする（goだとエラーになる場合もある）

Python的な見た目に拒否感が起こる人は、「空白字下げの入れ忘れがバグにつながるのでは？」と言う。
for ... :
　　hoge += 6
hage = 7
しかしながら、上のように書く人は存在するがあまり読みづらく、ループに入れるなら字下げすべきだし
入れないのであれば、forの終わりに１行空行を入れる。Rubyは厳密にはxxx-endだけではなく、{}も
あって意味が違うのだが長くなりすぎるので説明しない。
もう１つはIDEなどがソースコードを勝手に整形するので、スペースではない明確な表示文字で区切りたい
という人もいる。当然このようなことを言い出したらキリがないが、最終的には好みで言語を選ぶわけで
無く仕事なら無条件であり、慈悲も和解もない。
2021/11/04(木) 16:51:58.52ID:F8fi5yeE
>>414
インデントはフォーマッターに任せる温い環境に慣れすぎて自分でやるのは辛ぽよ
421デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:02:13.15ID:oJ9Lbupd
そしてなぜPythonのようなCとC++の、ある意味で伝統を受け継がない物が出来たかと言えば演算子の順序で
a = b + c * dと書いた場合、c * d が優先されるのだが、ニワカは a = b + ( c * d )と書いたりする。
これをプログラマは冗長、あるいはダサいと言う風潮が出来て、「余計なカッコはカッコ悪い」となった。

ここから、whileやifに普通の丸カッコを付けない言語が多くなる。v = if true { 5 } else { 6 };
このように評価式にはtrueで、()を付けない、これが長い評価式の行になったとしても同じ

いわばカッコ言語と称される言語は、Pythonから見るとカッコ（悪い）言語になり、逆に伝統的なプログラマから
見ると、空白がブロックを左右するいい加減な言語に見える。よって又しても慈悲も和解もない
2021/11/04(木) 17:14:28.06ID:MjRPJM3Z
{ } な言語ばかりやってきたので
インデント言語について素朴な質問です

スコープブロックはどのように作るのですか？
例えばスコープブロック作成のために数行だけを { } の中に閉じ込めたりするのですが
インデント言語では括弧も何もなく数行だけを深くインデントするのですか？
2021/11/04(木) 17:15:03.57ID:DB49gC4z
>>406
>>411
NimはC, C++, pythonで書かれた豊富なライブラリを簡単に使うことができるようにすることで
ライブラリの少なさを補っている。
Cのライブラリを使える言語は結構あるけどNimはバックエンドにC++コンパイラを使うこともできるので
C++で書かれたライブラリも使うことができる。

c2nimを使えばC/C++のヘッダーファイルを自動的にNimのコードに変換してくれる。
C/C++のコードを完全にNimのコードに変換できるわけではないが
NimからC/C++のコードを呼び出すのに必要なコードを出してくれる。
github.com/nim-lang/c2nim

ここにあるコードのようにimportcppプラグマを使えば
C++のstd::mapやstd::vectorのようなテンプレートクラスをNimのgenericsのように使うことも可能。
nim-lang.org/docs/manual.html#importcpp-pragma-importcpp-for-objects

NimからPythonの関数を読んだりNimでPythonモジュールを作れるようにするライブラリ
github.com/yglukhov/nimpy

Nimのコードをマクロを使ってコンパイル時にGLSLのコードに変換するライブラリ
github.com/treeform/shady
424デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:36:48.75ID:d2BeURFt
>>422
Pythonだと、PEP340という、Anonymous Block Statementsの提案がなされていたが
block expr as x: # expr as x はおそらく省略できる
　　...
このように書ける提案だったがリジェクトされて、PEP343となりwithブロックになった。
with open(path) as f:
　　...
ほかの言語だとこのblockという無名または名前付きのスコープが作れるものが多いと思う
block "A sealed": # 文字列は名前で省略できる
　　...
そうはいっても、以下のようにすればブロックは勝手にできるあまり意味はない。どこかでBLOCK = true
if BLOCK:
　　...
425デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:40:02.16ID:d2BeURFt
他にもlabel（？だったか）として名前付きのものもあったな、これは、多重のforなどのbreakで名前が指定できる
2021/11/04(木) 17:40:29.24ID:lAAyXHqu
bindingはどの言語でもあるし簡単に作れるよ
ただ純正コードで書くのと同じくらい適切に運用させるのが困難な場合が多いので、誰もそれが簡単だとは言わない
個人的には正直nimアピールいらんｗ 何か書かれる度にどんどんnimから離れて行きたくなるｗ
2021/11/04(木) 17:40:46.86ID:DB49gC4z
>>422
Nimではblock文/block式というのがあります。
nim-lang.org/docs/manual.html#statements-and-expressions-block-statement
nim-lang.org/docs/manual.html#statements-and-expressions-block-expression

変数aはblock:の下のインデントされたブロッグ内のスコープ内でのみ使えます。
block:
　　let a = 1
　　echo a

こんな感じでblockに名前を付けてbreak文を使っていっきにblockから抜けることもできます。
var found = false
block myblock:
　　for i in 0..3:
　　　　for j in 0..3:
　　　　　　if a[j][i] == 7:
　　　　　　　found = true
　　　　　　　break myblock #forループの上にあるmyblockから抜ける。
echo found

block式を使うとblock文と同じように新しいスコープを作りますがblock内の最後の式がblock式の値になります。
let a = block:
　　var fib = @[0, 1]
　　for i in 0..10:
　　　　fib.add fib[^1] + fib[^2]
　　fib # fibの値がこのblock式の値になってaに代入される。
echo a # @[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144] が出力される
2021/11/04(木) 17:44:36.59ID:fybR+JX+
nimアピールすごいな。
宣伝したいならQiitaとかでいっぱい記事書いたほうがいいんじゃないかな・・・。
429デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:50:32.91ID:d2BeURFt
言語なんて日本だけで流行っても、しょーがないし、流行るとしたら海外で流行らないと、Pythonだって
海外で流行っていて、Rubyの作者が日本人だから、日本ではRubyというかRoRが一色になりかけたのに
Pythonなんて誰もやってなかった（言い杉か）
2021/11/04(木) 17:54:52.55ID:eo9m+3ij
pythonで
a = b*c + d
というスペースの空け方を推奨してて、なるほどと思った
2021/11/04(木) 18:01:05.24ID:UnTZr4yd
>>427
ブロックも式になって最後の値を返すとか
ブロックで変数スコープがあらたにつくられるとか
Rustなどと一緒だね

あとはRustみたいに変数スコープブロックを抜けると(または変数のライフタイムが尽きると)
ファイルオープン変数だった場合に自動クローズとかもあるのかな？
具体的には、Pythonだとwith、C#だとusing、Goだとdefer、などそれそれ必要なところ
Rustはそういう特殊構文なくて
変数が解放されると自動closeされる
432デフォルトの名無しさん
垢版 |
2021/11/04(木) 18:13:51.03ID:DB49gC4z
>>431
defer文でcloseできます。
nim-lang.org/docs/manual.html#exception-handling-defer-statement

コードを書けばデストラクタからcloseできるようになるけどNimにデストラクタができたのが最近なんで
標準ライブラリのFileはdefer文使うか自分でcloseを呼ぶ必要があります。
2021/11/04(木) 18:30:25.81ID:MjRPJM3Z
Rustはファイルディスクリプタ類を関数を超えて持ち回ったり複雑化しても使い終わると即座に確実にクローズが自動的にされるのが凄いよね
434デフォルトの名無しさん
垢版 |
2021/11/04(木) 18:37:46.92ID:7RmUj5cL
それは標準ライブラリがDropトレイとで成り立ってるだけの話で、openとcloseが完全対になるような
リソースならそれで良いがBufWriterの場合とかflushしなければならないし、何回もopen呼んでも良い
ようなリソース管理は、結局は自分で実装しないとならない
2021/11/04(木) 19:00:18.43ID:UnTZr4yd
>>433
即座に着実安全にメモリ解放が自動でなされるRustにとって
その程度はオマケのついでの楽勝なだけにすぎない
2021/11/04(木) 19:33:56.36ID:lAAyXHqu
その分とっつきにくいけどな
2021/11/04(木) 19:53:06.80ID:UnTZr4yd
>>436
え？他の言語よりはわかりやすくてとっつきやすい
2021/11/04(木) 20:10:30.05ID:lAAyXHqu
「rust 難しい」とかで検索すれば出てくるけど、残念ながら世の人々はそうは思わんのだよ
比較的進歩的な人でもそういう意見をよく聞くし、所有権は理解しないわけにいかない基礎だから端折れない

逆にgoではほとんどそういうことがない
2021/11/04(木) 20:22:55.80ID:MjRPJM3Z
Goはガベージコレクション言語だから比較の土俵が違うような
さらにGoはプログラミング言語として様々な機能を失いすぎてプログラミングしにくいのが辛いですね
2021/11/04(木) 20:26:36.52ID:lAAyXHqu
比較的守備範囲の近い、とっつきやすい言語の例ｗ
2021/11/04(木) 20:33:45.40ID:iRkMc3Gk
失い過ぎたｗ
意図して実装してないだけだがｗ
2021/11/04(木) 20:42:10.69ID:UnTZr4yd
>>440
Goは守備範囲が狭すぎて違う
Rustの元々の守備範囲はC/C++が使われている領域
その領域に加えてGC無くメモリ安全性の保証によりJavaなどの置き換えにも使われつつある
さらに加えてイテレータ等の現代的なプログラミングスタイルがメインとなってコーディングしやすいためスクリプト言語を含めた幅広い方面からの移行/兼用が起きている
いずれもGoは満たせない要件
2021/11/04(木) 20:55:34.08ID:wrxqAvPZ
だからこれからのコーディングの奴隷はRustで決まりってことなんだろ
2021/11/04(木) 21:00:15.23ID:lAAyXHqu
goとrustならrustの方が守備範囲狭いよｗ
ひとえに難しいからｗ

OS周りならC/C++でいいし
現状ではweb周りのごくごく一部の超高速領域を除きrustには置き換わっていない
javaからの置き換えならgoでいい
2021/11/04(木) 21:09:43.64ID:MjRPJM3Z
>>442
その3種類ともGoは対象外なことに驚きました
実はGoとRustは領域あまり被っていなくて競合していないのかもしれませんね
2021/11/04(木) 21:16:55.71ID:lAAyXHqu
他rust向きの領域だとdatabaseかなぁ・・・
ただ既存のDBを置き換えるのはなかなか厳しそうｗ
何かに特化したやつならいいかもねｗ
2021/11/04(木) 21:31:58.67ID:7+L798k8
RustがJavaの代わりってマジか
Scalaみたいな負債の再来か
2021/11/04(木) 21:36:42.56ID:UnTZr4yd
>>447
Meta (旧Facebook)が基幹システムをJavaからRustへ移行した
IT業界ではそういう流れ
2021/11/04(木) 21:42:25.68ID:lAAyXHqu
ビルドシステムなｗ
https://www.itmedia.co.jp/news/articles/2107/28/news152.html
2021/11/04(木) 22:03:32.17ID:C83Gt3We
ビルドシステムでGCの動きを気にすることってほぼないけどな。
なんかやばい方向いってるね。
2021/11/04(木) 22:27:26.54ID:lAAyXHqu
rustのスポンサー企業一覧
https://foundation.rust-lang.org/members/
プラチナメンバが錚々たる顔ぶれｗ リンゴおらんｗ

nimのスポンサー企業一覧
https://nim-lang.org/sponsors.html
2021/11/04(木) 22:47:21.35ID:3s9ShBm/
まあrustは天才向け言語と思うので、コアなところがrust縛りになってくれると安心なところはあるね。goとかnimとかはちょろい分野で頑張れば良い
2021/11/04(木) 22:51:16.80ID:kgE3GEs9
て、天才ww
2021/11/04(木) 22:53:26.72ID:fybR+JX+
nimも良い言語だと思うけど、GAFAMみたいなとこがバックアップしてるわけじゃないし、仕事では使う気せえへんなあ。もったいない。
趣味ユーザが使いまくってエコシステムが充実するまで待つしかないな。
2021/11/04(木) 23:11:49.09ID:mYdjk53s
>>451
リンゴにはswiftがあるからなあ
2021/11/05(金) 02:15:48.45ID:KGYxGlBy
python嫌いだからnimも嫌いなんだわ
457デフォルトの名無しさん
垢版 |
2021/11/05(金) 05:25:56.07ID:Q0weZe1J
嫌いっていうより、ウチの爺らはPythonすら出来なそうだけどね
2021/11/05(金) 06:52:06.45ID:0gW7V402
>>451
Rustのスポンサー企業一覧にTOYOTAがあるね
さすが日本のトップ企業
2021/11/05(金) 09:11:02.86ID:pAK9gvBl
しょーもない見栄張ってるだけだな
2021/11/05(金) 09:40:04.97ID:ZsL5S5NL
サーバーサイドに企業のバックアップなどいらぬ
趣味で弄れない仕様になってる車の内部やスマホのアプリを企業がしっかり作れよ
2021/11/05(金) 10:28:44.23ID:ShfctMVX
Node.jsの話？
2021/11/05(金) 11:30:58.07ID:pLniUbgZ
>>458
自動車ってガソリン車の時点でもう低レベルファームウェアの塊だもんな
これからEVとなるとなおさら…
2021/11/05(金) 12:57:06.14ID:oXyREoQy
死ぬほど恥ずかしい知ったかだなこれ
2021/11/05(金) 12:58:33.47ID:MOYeaH5z
新手の自己紹介か？
2021/11/05(金) 20:37:57.51ID:DvmJ6O3T
>>458
国外も国内も大手有名どころはRust採用で大勢が決した感じね
2021/11/05(金) 21:28:24.58ID:Xs8oV2Az
国外も国内も全然違うｗ
467デフォルトの名無しさん
垢版 |
2021/11/06(土) 00:50:02.35ID:iXKnTImN
rustもアピールすごいな、内容の無いrust押しもどんどんrustから離れて行きたくなるけど
2021/11/06(土) 01:56:27.18ID:x0h3LLto
YouTube で有名な、雑食系エンジニア・KENTA のサロンでは、
キャリアパスは、Ruby on Rails → Go のみ

Rust, Elixir などは、普及のキャズムを越えなかったので、やる必要なし。
なのに、Rustが再評価され始めたのか
2021/11/06(土) 02:00:59.99ID:EdP5MzkQ
C++でいろんな新規開発する組織ではRustが好評価されてるでしょ
それ以外の現場ではめったに見向きされない
2021/11/06(土) 06:29:11.65ID:bdG9YXuk
転職サイトとかフリーランスのサイトでRustで検索したら1桁か2桁ぐらいしか求人が出てこないけど国外国内で覇権を握る言語らしい
2021/11/06(土) 07:32:09.49ID:a2wAz4xJ
Rustでもユーチューバーでも国会議員でもそうなるわな
2021/11/06(土) 12:03:26.15ID:2f1Vgy/C
rustが評価されてるのは高速・安全の2点
これらが難しさを無視できるほど重要になる領域では唯一の選択肢になる
世界規模のサービスでは特にクリティカルな問題になるのでこの分野の発展を望む巨人共が投資してる
2021/11/06(土) 12:24:00.21ID:WoXv+kRZ
>>469
転職サイトw
2021/11/06(土) 20:58:43.30ID:9KDcj+aF
>>468
Goは言語仕様の欠陥により全くオススメ出来ない
Goでは例えばうっかりローカル変数の参照(ポインタ)をそのスコープ外へ持ち出しても
言語仕様としてコンパイラにもチェックされずそして禁止もされず
そのまま通ってしまうため実運用で致命的なバグを引き起こしてしまい
実際に以下のような大事件まで引き起こしている

Go言語で書かれたLet's encryptが300万以上の証明書の失効を迫られた致命的バグはRustで実装していたら防げたの？→Yes
https://qiita.com/komasayuki/items/02785730d486ec4b397f
2021/11/06(土) 21:25:57.27ID:8rFQ20lW
そういう問題じゃねーわ。
そこでポインタを外に出すようなバカはどんな言語使っても同じようにカスなことやってるよ。。
2021/11/06(土) 21:32:11.29ID:v/Totsm8
>>475
人間必ずミスをする
そしてこれは言語の仕様としてそのようなことが起きないように禁止すれば済む話
Rustならコンパイラがその禁止事項でエラーとなるから人間が万が一のミスをしても大丈夫
2021/11/06(土) 21:37:20.60ID:wE/AlpPI
じゃあunsafeも禁止にしないと
478デフォルトの名無しさん
垢版 |
2021/11/06(土) 21:45:46.17ID:f6JHtgP7
>>475
だから、よりチェックが厳密な(100%とは言わない)rustが良いのでは。
2021/11/06(土) 22:24:42.47ID:2f1Vgy/C
rustにしたら防げたのかもしれないが、だからってrustにした方が良いとは思わんｗ
2021/11/06(土) 22:30:30.69ID:v/Totsm8
少なくともその分野のプログラミングならばRustを用いるのがベスト
他に解がない
2021/11/06(土) 22:34:25.16ID:PDDtrjdC
静的解析さん……
2021/11/06(土) 22:35:30.57ID:bqXF1v8h
Last
2021/11/06(土) 22:38:46.87ID:twTYwhnI
Rustは天才向け言語だからそんな凡ミスするやつが使うべきじゃない
はい終わり
2021/11/06(土) 23:12:13.85ID:2f1Vgy/C
rustにしたらメンテナンスできる人や便利にしてくれる人が減ってしまう
明確に別の問題があるんだよ
本当にそれしか解がないのなら問題が起きる前に誰かがすでに書き換えている
2021/11/06(土) 23:18:58.54ID:EdP5MzkQ
全人類Rustを極めてたらいいのに
2021/11/06(土) 23:27:58.99ID:2f1Vgy/C
それな
2021/11/06(土) 23:32:27.72ID:9KDcj+aF
>>484
Rustにしたらメンテナンスもしやすくなったよ
例えば機能追加で今回の件のようなバグが紛れ込むことも無くなった
もしその種のミスをしているとコンパイルが通らないから安心してメンテナンスできる
2021/11/06(土) 23:35:57.66ID:bBqH6KfG
天才が使う言語なんだからならそもそもメンテナンスなんてしなくていいだろ
はい終わり
2021/11/06(土) 23:36:45.09ID:2f1Vgy/C
メンテナンスできる人の数の話をしてるのに、そもそもメンテナンスできる人がメンテナンスしやすくなったからって関係ないよね
2021/11/07(日) 09:04:00.93ID:bwFiQ/UZ
アスペ＝天才
2021/11/07(日) 13:38:59.39ID:XJB+ymj6
たまに紙一重のやつがいるのは認めるが
イコールではないな
アスペ⊆天才でもないし
アスペ⊇天才でもない
2021/11/07(日) 13:50:16.34ID:Wnisb2X3
サヴァンみたいな一点豪華な才能は気苦労も伴うからな
2021/11/07(日) 14:10:35.95ID:/d1krDIr
他のスレで暴れてるMbってやつは天才？
2021/11/07(日) 14:21:05.01ID:nhZF9/LT
召喚すんな
2021/11/07(日) 15:13:11.87ID:XJB+ymj6
天才でも凡人でも地方でも
最低限のマナーすら守れない香具師は何やっても成功しない
2021/11/07(日) 15:30:00.12ID:/d1krDIr
マナーなんて無くても天才と馬鹿は行動力があれば成功するだろ
マナーが一番必要なのは凡人だけ
2021/11/07(日) 16:47:03.65ID:NoqiBvXu
488の煽りごときから天才の話を続けようとすんな
498デフォルトの名無しさん
垢版 |
2021/11/07(日) 22:52:33.86ID:NYPA2RTD
>>489
PHPでも使ったら？一番人集まりやすいんでないか？
2021/11/08(月) 00:15:26.32ID:vASCcAjA
メンテナンスなんて少しも考えてないバカがrustすげーって騒いでるだけだろ。
どうせGAFAも認める言語使ってる俺すげーしてクソコード残して立ち去るような仕事のやり方ばっかしてんだろうね。
2021/11/08(月) 00:21:07.56ID:SITQ70se
メンテナンスならばRustがもっともしやすいだろう
コンパイルが通ればメモリ安全性が保証される点で他の言語より抜きん出る
これは大きな利点である
2021/11/08(月) 00:38:47.53ID:rlmkL2+c
それでメモリ安全性の定義ってなんだっけ
意味論を定義したうえで形式的に証明されてるんだっけ
2021/11/08(月) 01:21:00.52ID:vrtVczFq
GoとRustってCのアドレス演算的なことはできるのですか？

int arr[] = {1, 2, 3};
int *p = arr;
p += 1; // ←これです
printf("%d\n", *p); // 2
2021/11/08(月) 02:24:21.55ID:p+/Hds0z
>>502
C/C++のようなポインタ演算は安全性のためにできないようにしてるが
Goならunsafe.Add、Rustならpointer::offsetやpointer::wrapping_offsetで同じようなことはできる
2021/11/08(月) 02:29:59.56ID:J6d/ajGt
マンドクセ
2021/11/08(月) 02:59:59.38ID:6BzlB5w0
>>501
Rustは多くの論文が出ている
https://rustc-dev-guide.rust-lang.org/appendix/bibliography.html#papers-about-rust

>>502
生ポインタと呼ばれていて通常のプログラミングでは使わないが実行可能
Rustコンパイラによるメモリ安全性の保証外などとなることを宣言するunsafe{ ... }の中で使える

以下はRustのコードでコメント部分(＝各行の//以降)に対応するCコード
let a = &[1, 10, 100]; // int a[] = {1, 10, 100};
let mut ptr = &a[0] as *const i32; // int *ptr = a;
println!("{:p}: {}", ptr, unsafe{*ptr}); // printf("%lx: %d\n", ptr, *ptr);
　→ 0x5645a1293000: 1
ptr = unsafe{ptr.offset(1)}; // ptr += 1;
println!("{:p}: {}", ptr, unsafe{*ptr}); // printf("%lx: %d\n", ptr, *ptr);
　→ 0x5645a1293004: 10
2021/11/08(月) 10:23:03.43ID:LdTjNXcL
>>501
絶対的メモリ安全性の定義が難しいなら
javascriptとtypescriptのような相対的な優位性を証明すればいい
2021/11/08(月) 13:03:54.54ID:vrtVczFq
>>503
なるほど
ありがとう
508デフォルトの名無しさん
垢版 |
2021/11/08(月) 14:46:35.97ID:PFM3PqQ9
>>420
(if true:
　echo "You can do this if you want"
　(block:
　echo "but everyone will hate you" # None indentation is OK
　)
　(for n in 0..5:
　echo n # None indentation is OK
　)
)
#for n in 6..10:
#echo n　# <-- Error: invalid indentation
https://play.nim-lang.org/#ix=3EmH
2021/11/08(月) 15:56:14.25ID:dWDs4ee0
nimでスレが止まってるとイラっとするまでになってしまったｗ
前まで比較的好きだったのに・・・
510デフォルトの名無しさん
垢版 |
2021/11/08(月) 16:03:45.86ID:KvpLYeV7
全員目をつむりなさい、この中に前から嫌いなのにA子さんの縦笛を盗んだ人がいます！
正直に手を挙げなさい！先生は怒りませんよ！
2021/11/08(月) 16:29:20.11ID:jye9PFXO
先生（クソッ、なんでバレたんだ…なんとか誤魔化さないと…）
512デフォルトの名無しさん
垢版 |
2021/11/08(月) 17:47:01.28ID:zeI+S7c1
>>500
いまどきメモリー安全じゃない言語なんてC/C++/Delphiぐらいなもんだろw、Java/KotlinもC#もNimも、D言語も
Swiftもunsafe的なコードじゃなきゃメモリー安全。Microsoftも採用基準はメモリー安全以外だと言っているよ
2021/11/08(月) 18:45:37.45ID:SITQ70se
>>512
GC言語でもメモリ安全じゃないケースはある
例えばGo言語は>>474の実例のようにメモリ安全ではないことが示された
そしてGCなしネイティブコンパイル言語となるとメモリ安全な言語はレア
2021/11/08(月) 19:23:50.63ID:dWDs4ee0
言葉の定義でしかないなｗ メモリ安全なんて言葉は使わない方がいいｗ
2021/11/08(月) 19:47:27.37ID:SITQ70se
>>514
例えば>>474の現実例のようにメモリに関するバグをコンパイラが見逃して通してしまうプログラミング言語はメモリ安全性が保証されていない
516デフォルトの名無しさん
垢版 |
2021/11/08(月) 19:54:02.50ID:9Ys8k33F
ほんとアホは相手しちゃだめだな。長さ不定のリスト構造に要素の追加を値渡しではなく参照にしてしまうのは
メモリー安全性なんて一切関係ないｗ、型チェックの厳密性（緩さ）の違いだけGoは確かに緩いけど、Rustが
強い型付けをしているから。更に極端な例を言うなら秘密情報を一文字違う宛先に送った明らかなプログラミング
ミスと何ら変わりない。代わりにRustはキャストが大変になってる

GCなしなんてSwiftでもNimでも実質Rustと同じ参照カウントだし、S.T.Wで停止をしなければ高負荷な環境の
分野以外で問題になることはない。CrystalなんかでもARCの（まだ無いが）実装が検討されている。
この強烈な匂い立つような他の言語を貶める人たちへ、距離を置きたくなる。
言語のせいじゃないから困るわ・・・もっとアピールすべき点は他にあるでしょ
2021/11/08(月) 19:58:54.68ID:6BzlB5w0
>>516
そこは型チェックの厳密さは関係ない
ライフタイムの問題である
利用先よりも寿命が早くやってくる物の参照を渡したから問題なだけである
つまり型チェックの厳密さは関係ない
518デフォルトの名無しさん
垢版 |
2021/11/08(月) 20:10:59.23ID:CQj4IFht
>>517
違います。 利用先へ渡された参照渡しされたデータは寿命はやってきません。値渡しもしくは値コピーであれば
コピー元のデータは普通に寿命を迎えます。そんな事も分かってないのに強烈な初心者のような言い訳は意味が
ありません。他にも参照渡しされたデータたちの構造がリング状になることを循環参照と言いますが、（この
ような欠陥を作るのは大変ですが）Rustはこれを参照カウントで回収しません、これはARCだけを採用している
他の言語でも同じです。
2021/11/08(月) 20:54:01.15ID:6BzlB5w0
>>518
基本的なことを理解していないようなので補足説明しますよ

まず関数内のローカル変数をスタック上に置く言語と全てヒープ上に置く言語の2種類に分かれます
このうち必ずヒープ上に置く言語でガベージコレクションを行なう言語は今回の問題が起きないので
ここでの説明では関数内のローカル変数をスタック上に置く言語を対象とします

スタック上に置かれたローカル変数の参照(ポインタ)を用いて関数内で様々な処理をしてももちろん大丈夫です
さらに別の関数を呼び出して先ほどのローカル変数の参照(ポインタ)を渡して別の関数で処理するのも問題ありませんし孫関数でも曾孫でも大丈夫です
そしてそれらの関数引き渡しの時に他の構造体変数に格納されて引き渡されることもあるでしようがそれでも大丈夫です
つまり他の複合的なデータ(配列や構造体など)に参照(ポインタ)が組み込まれて受け渡されることもありますが子孫の呼び出し関数にいるときは大丈夫です

問題が発生するのはその関数内ローカル変数を含む関数を終えたときです
ローカル変数の参照(ポインタ)が単体もしくは他の複合的なデータに格納されたまま呼び出し上位の関数に戻ってしまった時に問題が発生します
もちろん御存知のようにスタック上にローカル変数を確保した言語の話ですから関数を終えたときにスタックは開放されて参照(ポインタ)は無効となっています

この問題はCGの有無とは関係なくスタック上にも変数を確保する言語の場合は生じ得ます
さらにヒープ上に確保した場合でも非CG言語では生じ得ます
そして強力な型チェックを行なっていてもそれだけでは回避できない点にこの問題の難しさがあります
唯一の解決方法は言語が各変数(領域)のライフタイムを管理して更にその参照が渡って行く先々のライフタイムがそれより短いことを言語が保証することによります
520デフォルトの名無しさん
垢版 |
2021/11/08(月) 21:03:57.19ID:r0oqOAIx
RAIIですべて解決。
そもそも循環参照とか考えなければならなくなったら、自分の頭が狂っていないか病院で検査したほうが良い。
必要になってる時点で何かがおかしい。
2021/11/08(月) 21:08:03.70ID:q/kOwwo+
クソみたいな長文書く前に
https://github.com/golang/go/wiki/CommonMistakes#using-reference-to-loop-iterator-variable
をちゃんと読んでこいよ
これをメモリ安全の問題だと思うのはアホだけだろ
2021/11/08(月) 21:09:44.36ID:j/frnJ3w
>>520
助言ありがとう。早速病院に行ってきた

医者「それで……本日はどのような件で？」

俺「循環参照を考えなければいけなくなったので、検査してもらってもいいですか？」

医者「？？？？？どういうことだね？」

俺「だから……！！！循環参照を考えないといけないんです！！！検査してください！！！」

医者「だめだこりゃw」

とりあえず精神薬は貰えるっぽい。ありがとうな
523デフォルトの名無しさん
垢版 |
2021/11/08(月) 21:15:19.22ID:WC/FOJEL
>>519
基本的なことを理解していないのはあなたです、それはメモリー安全性ではありません。メモリー安全性は
バッファオーバーフローなど配列の添え字や境界を超えてアクセスを許してしまう事です。（または無効な
アドレスを許してしまう）簡潔に説明出来ないのはあなたが言い訳しているからです。

あなたが説明しているのはRustのRAIIを言っているに過ぎません。当然それはメモリー安全性ではありません
これはファイルのクローズ処理などでも限定された処理を自動化しますが、解放を強制しているだけです。
またこのRAIIの自動リソース資源の解放も万能でありません。ある意味では、メモリー（他の資源を含む）
リーク回避策の実装（解決策の１つであり唯一ではない）でしかありません
2021/11/08(月) 21:20:36.74ID:6BzlB5w0
>>521
それも全く同じです
ライフタイムが尽きたのにその参照を維持してままだから生じた問題です
ライフタイムを管理する言語ならばそのケースも同様にコンパイラがそのコードの問題を指摘します
2021/11/08(月) 21:27:40.83ID:6BzlB5w0
>>523
落ち着きましょう
様々な原因(スコープを外れたり再利用のために)自動開放されてしまったものへの参照を維持し続けてしまい発生するその問題は明らかにメモリ管理使用ミスの問題でありメモリ安全性の問題です
あなたが主張するバッファオーバーフローはメモリ安全性の問題の一つに過ぎません
526デフォルトの名無しさん
垢版 |
2021/11/08(月) 21:29:14.32ID:WC/FOJEL
>>524-525
じゃあ世の中にメモリー安全性を謳う他の言語の本家に文句言って、この言語たちはメモリー安全ではないと
ホームページを書き換えろと文句言いなさいよ。どうせ相手にしてもらえませんがね
RAIIをアピールするならまだしも、それをメモリー安全性なんて言って勘違いし他を暗に危険だと貶める行為は
とても褒められませんし、なんの意味もなく必死なアピールが嫌悪を伴います。正当なアピールでさえ、最近は
ウザいと嫌がられますよ？

「ライフタイムが尽きたのにその参照を維持してままだから生じた問題です」
ライフタイムが尽きたと考えられるのはGo言語のソースでRust的なコードの見方をしているからです。何度も
言っているように参照で渡したデータの寿命は尽きていません。
2021/11/08(月) 21:36:44.29ID:6BzlB5w0
>>526
>> 何度も言っているように参照で渡したデータの寿命は尽きていません。

寿命が尽きて参照先が再利用されてしまい参照が無効状態になっていることをマジで理解できないのですか？
528デフォルトの名無しさん
垢版 |
2021/11/08(月) 21:43:30.84ID:WC/FOJEL
>>527
あなた自分の上げた記事さえ読んでいませんね？「参照が無効状態になっている」無効にはなっていません
$ ./test_gomistake
Values: 3 3 3
ですから問題が起こったのです。もうメモリー安全性でも私の逃げでもイイから勝ち誇って嫌われなさい
Rustには偉い迷惑な存在なので、もう相手しませんよ
2021/11/08(月) 21:43:51.47ID:q/kOwwo+
Goの変数は参照がある限り存在するからお前が全て間違ってる
はっきりして良かったな
2021/11/08(月) 21:56:52.12ID:6BzlB5w0
>>528
わかりやすいように1回目のiをi1と表現すると
i1への参照を他が持ったままi1は寿命が尽きて解放されてますよね
そして2回目のi2が同じ領域を割り当てられて別の値2となりそれも尽きて
最後に3回目のi3が同じ領域を割り当てられて別の値3となりそれも尽きて解放
つまりPrintlnした時点で未割り当ての領域の値3を指していますよね？
2021/11/08(月) 22:12:26.06ID:IqA5SPsy
C言語でもメモリ的に危ないコードにはunsafeってコメント書いとけば
rustと同じで安心安全だよね
2021/11/08(月) 22:49:01.85ID:DpBlQeQQ
上から下までunsafeまみれになるわ
2021/11/08(月) 23:13:31.22ID:LdTjNXcL
GCにも矛盾はあるんだよ
参照できなくなったポインタの集合を参照できないならばGCの実装は不可能

現実的にはunsafeでweakな参照を使って無理矢理GCを実装している
2021/11/08(月) 23:48:37.92ID:dWDs4ee0
だからメモリ安全って言葉使うなって言ったのにｗ
2021/11/08(月) 23:49:59.34ID:jye9PFXO
分煙と言えば
ミドリ安全です
2021/11/09(火) 00:03:37.26ID:/IIRMA31
プログラマーってメモリが安全かどうかでずーーーーっと同じような話しててキモいわ
安全日とか危険日とかどうでもいいだろ消えろ
2021/11/09(火) 01:09:11.48ID:Ziut+B8+
>>521
そのバグ問題やってみたが興味深い問題だな。
func main() {
　var out []*int
　for i := 0; i < 3; i++ {
　　out = append(out, &i)
　}
　fmt.Println("Values:", *out[0], *out[1], *out[2])
}
上記のバギーなGoコードをそのまま普通に以下のRustコードにすると、
fn main() {
　let mut out = vec![];
　for i in 0..3 {
　　out.push(&i);
　}
　println!("Values: {} {} {}", *out[0], *out[1], *out[2]);
}
コンパイルエラーとなり「変数iの借用(参照)がforループの外で使われてる!」とライフタイムの問題。
そこで変数iを強引にループの外へ追い出して、この問題が起きないように以下のコードにすると、
fn main() {
　let mut out = vec![];
　let mut i = 0;
　loop {
　　if i < 3 {
　　　out.push(&i);
　　　i += 1;
　　} else {
　　　break;
　　}
　}
コンパイルエラーとなり「変数iが借用(参照)されたままで変数iを書き換えてる!」と書き換え競合の問題。
つまりRustは少なくとも2種類の方法でこの種のバグが生じないように防いでいるということか。
2021/11/09(火) 03:57:16.61ID:d6arxLIn
どこかで拾ったGoの変な挙動を示すコード

slice1 := make([]int, 0, 5)
slice2 := slice1
for i := 0; i < 10; i++ {
slice1 = append(slice1, i)
slice2 = append(slice2, i + 100)
}
fmt.Println("slice1 =", slice1) // => [100 101 102 103 104 5 6 7 8 9]
fmt.Println("slice2 =", slice2) // => [100 101 102 103 104 105 106 107 108 109]

これはなかなか常人には理解しがたい
2021/11/09(火) 04:12:13.75ID:2q5nPARu
実行してみると確かにそうなるな。なんじゃこりゃ
2021/11/09(火) 05:02:02.91ID:mTU/Ys0g
>>538
常人には、というかsliceの仕様を知らないと全くわからんよ。理解してみればシンプル。

sliceはコピーするとバッファも共有されてしまう。
バッファのキャパシティを超えるまでは、同じバッファに書き込まれることになる。
下のページの Slice internals らへんをちゃんと読めばよくわかるよ。
https://go.dev/blog/slices-intro

そのコードの場合は、slice1とslice2はバッファが共有されていて、そのキャパシティは5なので、5番目の要素までは同じバッファに書き込まれてしまう。

そのあとキャパシティを超えるので、slice1とslice2でそれぞれ別々の新しいバッファがallocateされて、元の共有バッファの要素がコピーされる。
なので、6番目からは別々に書き込まれる。

> slice2 := slice1
ここのコードは slice2 := append([]int{}, slice1...) とかに変更すればバッファが共有されないので、違和感のない動作になるぞ。
https://play.golang.org/p/3fCafqo9L5v

このへんか、deferが実行されるタイミングとか、 >>521 らへんは初心者がハマる罠だな。
次にハマるのは goroutine とか channel 使ったときの race condition らへんだな。
2021/11/09(火) 08:45:42.78ID:dNM7/Umh
>>536
変数の型も書かないPythonが人気ナンバー1だからキモいのは少数派
2021/11/09(火) 09:26:15.28ID:Ziut+B8+
>>540
Goのスライスの諸問題は親スライス(＝元)と子スライス(＝バッファ部分がキャパシティを超えるまでは共有される)が同じスライスとして扱われるところにあるよな

一方でRustはそれをVec(＝親＝実体)とスライス(＝子＝部分参照)の2種類へ明確に分離して諸問題を防いでいる
さらにRustのスライスは親がVec(＝伸長可)でも配列(＝固定長)でも区別なく統一して使える
そしてスライスも参照の一種であるため「読み取り専用共有スライス」と「書き換え可能専有スライス」に分けることで並行＆並列処理での競合問題にも対処して安全な効率化を実現している
543デフォルトの名無しさん
垢版 |
2021/11/09(火) 09:57:47.67ID:cs0y0gBS
わざわざmakeでキャパ5作ってるのに、その後に10未満までappendするなんて
バカゴミクズしかこんな事しない。
ほんとRustのせいじゃないのに、このバカゴミクズは何もわかってないので
早く市んでほしい。イメージ最悪

構造をもったコレクション構造と連続領域確保のアロケーションを比べるなんて
頭がどこまでもおかしくなればこんないい加減なことを言えるのか
2021/11/09(火) 10:05:19.89ID:t/ZCl1K7
めっちゃ分かりやすくありがたい挙動ｗ
545デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:06:48.86ID:cs0y0gBS
比べるなら、配列やVecじゃなく、heap::allocate(size, align);なのに
長々と無駄な事を書いて、Vec::with_capacity(len);と比べているという
スパナと釘を比べて、どっちが安全と説いているバカゴミクズ勘違い野郎
2021/11/09(火) 10:16:31.45ID:p+4WEtUZ
>>545
俺もクソみたいなRust推しはどうかと思ってるが
今回の件は君よりもそのゴミクズ野郎のほうが問題の本質を理解してる
547デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:21:06.21ID:cs0y0gBS
また顔真っ赤の何も言わない援護射撃が現れる
2021/11/09(火) 10:23:15.72ID:t/ZCl1K7
C++なんてこれ1だからなｗ
#include <iostream>
struct s{};
int main() {
std::cout<<sizeof(s)<<std::endl; // 1
return 0;
}
理由は同じポインタ値を同じオブジェクトにしたいからだとｗ
言語仕様なんて実用本位でそんなもんｗ
ちなみにCは0ｗ
#include <stdio.h>
struct s{};
int main() {
printf("%ld\n",sizeof(struct s)); // 0
return 0;
}
2021/11/09(火) 10:33:38.60ID:E/uEHC7F
>>545
GoのスライスはRustのVecで合っている
どちらも以下の点で同じ
・3つ組で構成される(領域へのポインタ、確保されている長さキャパシティ、そのうち使用中の長さ)
・append/pushなどで長さは伸長することが出来る
・長さが伸長してキャパシティを超えると自動的にヒープ領域の再割り当てを行ないデータは移動する
・その時に3つ組のポインタ部分は当然変化する

>>545
>> heap::allocate(size, align);なのに

そのようなヒープ領域割り当てはとは異なる
GoのスライスとRustのVecはどちらも伸長して足りなくなるたびにヒープ領域の再割り当てを何度でも自動的に行なう
もちろん再割り当てが頻繁に起きないように大きく確保してそれがキャパシティ
550デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:37:04.74ID:cs0y0gBS
調べてきた
Cでは、構造体が名前付きメンバーなしで定義されている場合、プログラムの動作は"未定義"です。
ですから、処理系によっては0ではない違う値ということもあり得ます、なので0だ、というのは
少々違います。C++の場合、 標準ではサイズ0 のオブジェクトは許可されないため値1を返します。
clangに-std=c++17でCのソースをコンパイルすれば1になります。

未定義動作が多い言語は確かによろしくないですが、それだけ多くの処理系がある事の裏返しです
551デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:39:15.18ID:cs0y0gBS
必死に顔真っ赤になってレス付けてくるけど相手にしません、読むのも嫌
2021/11/09(火) 11:07:58.08ID:t/ZCl1K7
CとC++は実際違う言語だから、CのソースをC++の処理系にかけてもC++として処理されるだけｗ
gccでもclangでも言語オプションは-xなので、-x cでC言語、-x c++でC++になるｗ
Cなら-std=c++17ではなく-std=c17かなｗ
Cの場合古い分事実上の標準に合わせて標準化されてる感じが強いから未定義という扱いになるのは仕方ないｗ
実際gccでも警告すら出ず--pedantic-errors付けてようやく怒られる程度の話ｗ
2021/11/09(火) 11:20:15.97ID:Ziut+B8+
>>549
単体で使う限りGoのスライスとRustのVecは同じ構造も持ち同じ挙動だが
共有されると両者の挙動が異なってくる

Goのスライスは>>538のようにバッファ部分が共有されていると
別スライスでもキャパシティ限度内ならば書き換えや伸長があっても変化が共有される
そしてキャパシティを超えてバッファ部分再割り当ての時に二つに分岐してそれぞれが最終的にGCで回収される

Rustは競合回避のためsingle writer xor multi readersの原則があるので
RustのVecに書き換えや伸長が起きるときは共有されていない
だからキャパシティを超えてバッファ部分再割り当ての時は移動のみで旧バッファ部分は即座に解放回収
2021/11/09(火) 12:35:36.43ID:UAERt8tt
goは比較的新しい言語とは思えないほど危険がいっぱいなんだな。rustどころかnimや crystalにも大きく劣る言語仕様なのに、信者が無理矢理な理屈で自分を騙してる印象
2021/11/09(火) 12:36:57.75ID:6MNHnF6e
>>540
素直にcopyか参照にしとけば良かったのにね。
効率求めるならCOWにした方が良さそう。なんでCOWにしなかったのかな？COWは並列処理とあんまり相性良くないけど。
556デフォルトの名無しさん
垢版 |
2021/11/09(火) 12:47:14.84ID:Smk+8XDy
スケープゴートを用意し比較的人口の多いGoを攻撃する、Rustは悪くないのに"危険がいっぱいなこいつ"の悪辣性
2021/11/09(火) 12:56:13.87ID:t/ZCl1K7
go最強！！！！
2021/11/09(火) 13:08:33.41ID:0dhxEnJG
>>554
信者が無理矢理な理屈で暴れてるのはRust信者だろ
そんなことしてるからいつまで経っても普及しないオタク言語止まりなんだよ
2021/11/09(火) 17:57:07.15ID:m+qVFCof
capacity は、単なるデフォルト値だろ

別に、それを超えても良いのだろ？
560デフォルトの名無しさん
垢版 |
2021/11/09(火) 18:50:44.35ID:sYcGGX0V
RustはD言語の再来と言われるほど期待されてる。
2021/11/09(火) 19:55:55.57ID:qOqV7S2Y
倒してしまっても構わんのだろ？
562デフォルトの名無しさん
垢版 |
2021/11/09(火) 20:01:35.84ID:NdU8gMYv
うんこ野郎の独演会
2021/11/09(火) 20:12:33.83ID:mTU/Ys0g
>>559
超えていいよ。超えたときには別のバッファが作成されて、元のバッファの要素がコピーされる、ってだけだから。

キャパシティを意識するとしたら、このようなバッファ作成回数を減らしたいっていうような、パフォーマンスを意識するときが多いんじゃないかな。
普通は明示的にキャパシティを設定せずとも、デフォルトの2のべき乗サイズのキャパシティがいい感じのパフォーマンスになるけどね。
2021/11/09(火) 20:57:16.81ID:dNM7/Umh
スライス<T>型がユーザー定義型だったら
それは言語の欠陥ではなくユーザーのミスでしかなかったのに

スライス<T>型をユーザーが再発明できない原因をよく考えるべき
565デフォルトの名無しさん
垢版 |
2021/11/09(火) 23:26:26.60ID:8kpY2GOq
>RustはD言語の再来と言われるほど

言われたくないだろうな
2021/11/09(火) 23:33:50.69ID:t/ZCl1K7
注目度がだいぶ劣るけど後継は多分nimだから・・・
2021/11/10(水) 01:07:58.28ID:trxD4DJA
C++の再来はありますか？
2021/11/11(木) 10:10:47.29ID:SpIFedoW
去ってないから
2021/11/11(木) 14:23:06.64ID:Cobl5Yvk
C/C++は簡単にやばいコードを書けてそれを発見するコストが高いという問題がある
特にC++は使いこなすための練度のハードルが高いせいか凶悪と言ってもいいｗ
2021/11/11(木) 14:56:27.50ID:JCk4+0H4
C++がよくあそこまで流行ったもんだよね
こうなる前に他の言語を作る動きはなかったのかしら。まあそれが1995年のJavaだったのかなあ。昔すぎて自分にはよくわからんけど
2021/11/11(木) 15:12:54.92ID:Cobl5Yvk
むしろそれまではCしかなかった
Windowsが出てきて、その開発の主要言語でVisual C++が出てきたのでC++が流行った
と思ってる
インターネットが急速に発展したのはWindows 95以降だったので、それまでの流行りは処理系の人気に依存してた
と思う
その頃のUnix系や汎用機の世界までは俺も知らんｗ
勝手にUnix系はCで汎用機はCOBOLだったんじゃないかと思ってるｗ
2021/11/11(木) 15:29:17.41ID:jwvU2w1D
要は、スマホのように説明書不要と称する物を特許とか著作権とかの規制で縛って課金する方法と
本体を無料であげる代わりに分厚い説明書を買わせる方法がある
2021/11/11(木) 17:04:48.90ID:JCk4+0H4
>>571
なるほど。たしかにWindowsとVisual Studioがキラーアプリケーションだったんだ
MicrosoftがObjective-Cを採用してたら、Objective-Cがめちゃ流行ったんだろうし、やはりプラットフォーマーは強いな
MicrosoftかAppleのいずれかがLispを採用してたら、Lispの存在感も桁違いだったんだろうなあ。そういう世界線を見てみたい
2021/11/11(木) 17:23:23.65ID:jwvU2w1D
ネットの怪文書を処理する難度がC++よりも凶悪なのでC++が良心的に思える
2021/11/11(木) 18:27:16.30ID:2aD4x3mr
C++は諦めが肝心の言語
機能を全部使うと死ぬ
2021/11/11(木) 19:54:16.99ID:Cobl5Yvk
関数型の言語は当時Unix系の開発者(学術系多め)がemacs lispを中心に好んで使ってたよ(開発ツールとして)
ただWindowsとPCの普及にともなってunixやemacs自体が段々下火になっていった
処理系とはIDEのことなので、IDEの開発効率とその付属ライブラリが言語選択の決め手ということ
当時はC++以外だとpascal(delphiなど)を使う人やVBを使う人がいた
appleは丁度ジョブスいなかったので低迷中だったかな
当時強かったのはMS/IBM/Sunあたりかなぁ
※個人の感想/主観であることに注意
2021/11/11(木) 23:33:58.00ID:jahl/MWB
どうしてprologのことを無視するかなあ
80年代後半から90年代初頭にかけては
unixではprologの天下
Cよりも早くコーディングできた
2021/11/11(木) 23:45:48.82ID:JCk4+0H4
それ天下とはいっても流行してた、って意味じゃないよね？
GNUのソフトウェアもほとんどC言語だろうし・・・。
2021/11/11(木) 23:50:14.50ID:PBlMMjPy
prologはいいんだけどrust製prologのscryerとか見てるとISO準拠にこだわるのやめてくれと思う
文法とか組み込みオペレータ、組み込みプレディケートとかライブラリも新時代に合わせて工夫してほしい
昔ながらのコードをそのまま動かせる…
それは昔ながらのPrologで動かしてもろて…
じゃあprologじゃなくていいじゃんって？
そうだよ！基礎コンセプトそのままでガワを新しく整えたのがほしいんだよ！
2021/11/12(金) 00:06:01.94ID:Zs9GMSbc
Prologが分かる奴はErlangもRustも分かるから早急に次世代に行けた
2021/11/12(金) 02:10:18.26ID:MFojYN0L
prologなんて誰も使ってなかったよｗ
2021/11/12(金) 14:30:35.33ID:MwEAyDic
>>579
それ、何てOz？
Oz触ったこと無いけど。
2021/11/12(金) 14:41:26.85ID:MFojYN0L
swi-prologなら若干拡張されてるけど、prolog自体が昔からほぼ使われておらず
存在自体あまり知られてないし、結局手続き的思考が必要だし、用途が限定される使いにくい言語だと俺は思ってるｗ
2021/11/12(金) 14:59:17.99ID:CoiyKYqf
調べてみるとICOTとかいう、Prologをメインに使って、500億円も予算をかけたプロジェクトがあったらしいけど、なんだったんだろうな
585デフォルトの名無しさん
垢版 |
2021/11/12(金) 21:33:34.72ID:x+I3WYUz
第五世代コンピューターと論理プログラミングを基にした現代の深層学習とは違う人工知能・・・ウッ頭が
つまりはアランケイのSmalltalkが最強ってことだろ？
2021/11/13(土) 11:37:24.38ID:gACfz8Jy
コストが高いか安いかでくるくる掌返すのはポジショントークだよな
しかもサンクコスト
2021/11/13(土) 12:37:16.91ID:LtGGXPX8
Prologは夢を見すぎたな
結局バグは仕様そのものとかいろんな理由で起きるというのに
2021/11/13(土) 13:27:58.51ID:gACfz8Jy
メモリ安全みたいなテーマに限定すれば夢が無限に大きくはならんだろ
夢を見たことではなくテーマを表す言葉を使わなかったことを反省しよう
2021/11/13(土) 13:40:18.34ID:pG0a2gxf
ループをすべて再帰で書くというのがちょっと難しいが
デバグが楽だし、保守もしやすい
ライブラリをどさっと作れば流行ったかもしれないな
のちのperl,javaのように
2021/11/13(土) 15:45:12.67ID:m5D80op7
>>589
末尾再帰ループ化できない再帰はスタックが溢れる
最近はループを更にわかりやすくイテレータ連鎖で書くのが主流だね

>>588
Rustの発想は目からウロコだった
他の言語たちが最初からガベージコレクション前提にしてた状況でGCなし言語があそこまで出来るとは驚き

>>587
論理宣言型言語は結局は現実のCPU命令手続きとのギャップを処理系でカバーするも効率面も厳しく
591デフォルトの名無しさん
垢版 |
2021/11/13(土) 16:19:14.47ID:1+Mic26n
また過大評価してGC無しなんて言うけど理論上は参照カウントはGCアルゴリズムだし、そんなのは原始的で
最も基本のGCに分類される。仮にこれから今のRc系のGCに参照カウントGCの非同期が搭載されたりすれば
その動作はスイープマーク系や世代別GCに近くなる。（その可能性は少ないが）現在なぜ良い結果が出るかと
いえば構造上、連鎖的な多量GCが少なくなるために、スループットが高くなる事だけ。
レテンシーで見ればJavaやC#のGoなどの処理は毎回GCするとは限らないので、その分だけ処理が速い
2021/11/13(土) 16:22:04.94ID:0J1co5Uq
君、頭悪いでしょ
2021/11/13(土) 17:00:56.00ID:hvma83bs
末尾呼び出し最適化が保証されてる言語でのみ
枕を高くして再帰で書きまくれるというもの
ocamlはいいぞ
2021/11/13(土) 17:01:06.08ID:m5D80op7
>>591
まずほとんどのデータは参照カウントで管理しないから極一部のケース対象にしか論じていないね
次に参照カウントゼロ時に即座に解放する場合はガベージが一度も発生しないためガベージコレクションとは通常言わないです
最後に列挙しているGC言語はC/C++/Rustよりもベンチマークでも遅いですね
595デフォルトの名無しさん
垢版 |
2021/11/13(土) 17:14:56.21ID:o5Yybg23
末尾再帰はプログラミングテクニックではなく、コンパイラ等におけるコード最適化の技術です。
（多くは手続き言語における自己呼び出しをTailに変形してスタック消費をゼロにしたりする）

「ループを再帰で書く」まったく意味ないどころか、言語問わず末尾再帰最適化が未実装のコンパイラ等では
弊害しかありません。「イテレータ連鎖？で書く」は普通のループ大きく変わりませんが、言語によりけりで
手続き言語では非同期処理やサイドエフェクトのある処理では上手く書けません。

そもそもPrologの一階述語論理における再帰処理というのは再帰定義自体が、関数型プログラミングの元と
なる論理型プログラミングで、多くの普及している手続き言語のような弊害がないために成り立つだけです。
596デフォルトの名無しさん
垢版 |
2021/11/13(土) 17:29:13.45ID:o5Yybg23
>>594
(1)多くの言語のデータ管理はヒープとスタックです。スタックには（よほど特殊なOSでない限り）違いがありません。

(2)「参照カウントゼロ時に即座に解放する場合」意味のある日本語で書きましょう、開放すると言っておきながら
ガベージが無いといったり、RustであればRc<T>やArc<T>で参照カウントゼロ時は確保してないということです。

(3)「ベンチマークでも遅い」例えばCPUのベンチマークだって幾つも項目がありますが、その中のスループットは
高い（near =早い）と言っているのです。一方で レテンシーは遅いのです。

なぜそんなに強引に推し通したいのか、理解不能です。
2021/11/13(土) 18:05:59.35ID:gACfz8Jy
ベンチマークの数値ってもうRustのコンパイルエラーと同じぐらい意味不明と思われてるね
Prologさんを500億の言語にしても誰もほめてくれないし
2021/11/13(土) 18:55:57.32ID:kpA91CRo
GCなければキャッシュの効果は高くなりそうだけどねｗ
2021/11/13(土) 19:58:21.21ID:H/IZ/H8E
>>596
おそらくC++やRustを使ったことがないのだろうけどC++のshared_ptrやRustのRc Arcを使うのは所有者が複数になる特殊ケースのみ
それらのみが参照カウンタを用いるけど所有者がいなくなった時点で自動的にリソース解放される
これをGCと呼ぶ人はいない
もちろんそれ以外のケースは参照カウンタも使わずに解放される
そのためGC言語は原理的にどうやってもCやC++やRustに勝つことはできない
2021/11/13(土) 20:16:30.44ID:blWxI0OX
特殊な界隈でそういう習慣があるのか知らんが
参照カウンタは普通にGCの実装方式の一つと
言われてるだろ
2021/11/13(土) 20:50:12.12ID:pG0a2gxf
末尾再帰ができないのをループで書いても
スタックがあふれるけど
602デフォルトの名無しさん
垢版 |
2021/11/13(土) 20:53:18.97ID:qcFvcADm
例えば、ベンチマーク時間が30秒だとして、どれだけ回数を多く実行できるかがスループットであり
gcのあると言われる言語の中でgcの時間/頻度を調整できるものは30秒gcをしなければ、余計な処理が
走らないために数値が当然高くなる。もちろん処理中に使用メモリが常に増大して終了時のみに解放を
するため整合性のある説得力のあるベンチマークとは言いませんが、特定の処理に限ってメモリーが
溢れないのであれば、十分に取りうる選択肢です。

そして1msが致命的となるような処理では重要ですが特定桁までPIを求めたりフィボナッチ数列の処理
時間を計測したり、あんまり意味がないですね
多くは最適化がどこまでなされているか、配列などの範囲チェックなどのランタイムチェックが足枷に
なっているか、などが違うだけで言語的な特性だとは言いません。

上のほうでshared_ptrなんて持ち出してバカ言ってる人がいるけど言語は適用範囲が違えば有利な分野が
違います。「勝つ」なんて、Cなんて基本は配列などの範囲チェックなんかはやってないわけで原理的な
説明に１つもなってません。CとRustを同列に並べることがどうかしてる、Rustは範囲チェックなどは
安全な言語として当然やってるわけでRustだってアロケーションは他のgcの言語と同じく従来はjemallocで
今は違いますが確保と解放がセットになっている事が、今は有利に働いているが、将来的にはそうだという
確信はありません。そうでなければgcの研究なんて見捨てられるでしょう
2021/11/13(土) 21:00:37.35ID:YXy1PChK
またGCの定義をmalloc/freeとreference countとtracing GCの3つの間でお手玉して好き放題言う流れか
604デフォルトの名無しさん
垢版 |
2021/11/13(土) 21:05:09.14ID:qcFvcADm
更に言えば多くの独立したgcのある言語は、gcにおけるメモリー断片化を防ぐコンパクション処理を独自にやっている訳でOSに任せているRustが有利なのはその通りですが、だからと言ってその処理を行って無い事を不正という話には全くなりませんし、原理的にどうやっても等という結論出すことは全く意味がありませんね
2021/11/13(土) 21:14:45.54ID:H/IZ/H8E
>>600
参照カウンタはオペレーティングシステム内でもファイルシステムでも用いられている普遍的なデータ管理方式
参照カウンタを用いていることをガベージコレクションだと主張する人はいない
C++もRustも所有者が複数とせざるを得ない特殊ケースにおいて最適最速な方式として参照カウンタを用いている

>>602
やはりCもC++使ってことがない初心者だったのか
shared_ptrはCではなくC++です
そしてC++のshared_ptrはRustのArcと同じもので参照カウンタを用いている
あなたの無茶苦茶な主張では「C++とRustはGC言語」となるが世間では当然そんな主張は存在しない
もう一つのあなたのデタラメな主張「GC言語は速い」というデータも世間には見当たらない
2021/11/13(土) 21:24:08.80ID:qcFvcADm
ガベージコレクション
https://ja.wikipedia.org/wiki/ガベージコレクション
じゃあページの記述を削除して直して来いよ。顔真っ赤にしなくても良い話だぜ？書き間違いぐらい読もうよ？
「GC言語は速い」などという主張はしていないのも読めないから呆れるんだよ、妄信するあんたらを
2021/11/13(土) 21:51:51.77ID:m5D80op7
もっと詳しく書かれている英語版に明確に書かれていますね
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Many programming languages require garbage collection, ...
these are said to be garbage collected languages.
Other languages were designed for use with manual memory management,
but have garbage-collected implementations available (for example, C and C++).
「多くのプログラミング言語はGCを必要としていてそれらはGC言語と言われる」
「その他の言語は手動メモリ管理で設計されたがGC実装も利用可能(例としてCとC++)」
つまりCとC++および状況が全く同じRustはGC言語ではないです
2021/11/13(土) 22:03:01.49ID:qcFvcADm
はあ。。馬鹿馬鹿しい
2021/11/13(土) 22:10:48.49ID:gACfz8Jy
お前らの判断が遅いのは「審判は第三者でなければならない」という習慣のせいかな
自分が審判になって自分で好き放題に判断すれば早いんだが
2021/11/13(土) 22:13:59.53ID:npSc0+BO
tracing GC の方が有利なアプリケーションって具体的に何？
2021/11/13(土) 22:29:17.51ID:riokxr1E
いろいろなプロセスが動かないバッチ処理なんかは逐一確保と解放を繰り返さない分だけ、調整すれば早いでしょ
2021/11/13(土) 23:05:29.89ID:H/IZ/H8E
>>611がここでプロセスとか言い出してるのを見てもわかるように
GC言語が有利というトンデモ主張している人は基本的な常識知識がないようだ
2021/11/13(土) 23:09:26.37ID:PG5C5bM3
自分の間違いを認める人が全くいなくてこのスレはわけわからん
2021/11/13(土) 23:10:29.14ID:5/jXyZUV
馬鹿はほっとけ
2021/11/13(土) 23:31:48.59ID:kpA91CRo
前提の違う話が交錯してるだけｗ 言いたいやつに言わせとけばいいｗ
2021/11/13(土) 23:42:47.00ID:m5D80op7
>>611さんの解読
(1)バッチ処理だといろいろなプロセスが動かなくて
(2)つまりバッチ処理でなければいろいろなプロセスが動いて
(3)そしてバッチ処理でいろんなプロセスが動かなければ逐一確保と解放を繰り返さなくて
(4)逐一確保と解放を繰り返さない分だけ調整すれば早い
とおっしゃってるようだけど

(1)バッチ処理でもよくあるパイプライン式ならいろんなプロセスは動くし
(2)バッチ処理でなくてリアルタイムにストリーム処理でもプロセス一つだけもあってそもそもバッチ処理とプロセス数は関係ないし
(3)プロセス数が増えてメモリを使うことで起きうる確保と解放ならばOSによるメモリ管理とスワップの話になるし
(4)OSによるスワッピングが起きなければ起きた時より確かに実行速いのはその通りだけど
プログラミング言語によるメモリ管理やGCの話とは関係ないですね
2021/11/13(土) 23:55:33.15ID:gACfz8Jy
言いたいことを自由に言うのは良いことだよ
ただ、言われたことを全部聞く義務があると思うのは悪い
2021/11/14(日) 00:37:07.99ID:TIZIlibM
GCの方式の一つとして参照カウント方式があるが増減のオーバヘッドや不完全性からGCとしては少数派で主流はトレーシング方式
一方でC++/shared_ptrやRust/Rcは参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな
そのためC/C++/RustはGCのない言語と一般的に言われている
このあたりは共通認識でよいのではなかろうか
2021/11/14(日) 00:48:00.30ID:FBepD5Vv
書き込みが多すぎてなんの前提で話をしてるのかよくわからんが、通常のGCじゃないならなんなんだ。PerlはGCじゃないのか
2021/11/14(日) 00:54:15.03ID:TIZIlibM
>>619
そこは日本語をちゃんと読んで欲しかった

＞参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな
2021/11/14(日) 00:55:47.54ID:FBepD5Vv
ごめん。それでもわからんけど、Perlは参照カウント方式を使ってるんだけど、通常のGC言語ではない、ってこと？
2021/11/14(日) 01:02:54.74ID:TIZIlibM
>>621
ま、まじですか？
日本語で「WWWはXXX方式をとっているがYYYという状況のためZZZではない」な文章を「XXX方式はZZZでない」と解釈する人を初めて見ましたｗ
2021/11/14(日) 01:04:14.81ID:FBepD5Vv
つまり、君は何が言いたいの？
2021/11/14(日) 01:17:50.43ID:TIZIlibM
意図的に歪曲して言いがかりを付けたいだけなようなのでやめときます
一般的な共通認識を>>618に書いただけです
2021/11/14(日) 01:42:47.96ID:H2p4AXVo
ビジー状態とアイドル状態を繰り返すようなアプリはアイドル時にGCできるから有利な場合もあるのかな
shared_ptrでも実装工夫すれば同じことはできはするだろうけどめんどくさそう
2021/11/14(日) 07:13:40.75ID:RmFILMax
C#も、ついに10.0まできた。
貪欲に機能を追加し、着実に進化(複雑化)しているし、最先端とは言わないけど先端を走っていると思うんだ。
もう少し評価してあげてもいいと思うんだけど、みんな興味ないの？正直Goより・・・・
2021/11/14(日) 08:17:41.01ID:VI/aOYOP
C#はjavaと比べられる位置なので・・・興味ないというか既にみんな知ってるよね
2021/11/14(日) 11:00:50.01ID:fX3uqiQX
まだやってたのかｗｗ
ＧＣ言語であるない論破ｗｗｗもとを見ればＧＣアルゴリズムだって言ってるけど、途中で
絶対Rustに勝てないマンがＧＣ言語ではない言い出してるが、マジどうでもいいなｗｗｗ

絶対勝てないならここを見る必要もないだろ、Rustすれでワッショイワッショイやってろ
2021/11/14(日) 13:01:51.01ID:K/AOP3t+
C#は開発者文化を含めJava以上に単一言語で全部済ませる志向が強い言語なんだよね
実際俺も信者だったし信者ばかりの環境で仕事してたこともあって、いかにC#が優れているかはよく分かってるつもり
チームにC#を導入したら最後、他に手を出す理由を正当化することができなくなってしまい、結局つまんない職場になっちゃうんだよ
だから俺は一切C#使わないことにしてる
2021/11/14(日) 13:56:35.32ID:E00roTgy
Good は Great の敵
2021/11/14(日) 15:27:05.72ID:TIZIlibM
>>625
C++にはGCが無いためそういうのは必要ない
shared_ptrは単なるスマートポインタで使い終わると自動的にdeleteが呼ばれるだけ
RustのRcも同じ
2021/11/14(日) 16:22:12.42ID:H2p4AXVo
>>631
shared_ptrなりRcなりは普通にコーディングするとスコープ抜けたり所有権失ったり獲得した領域が不要になったタイミングで即時freeされるけど
ビジー状態終了後にまとめてfreeしたいならそれまで参照を生かしておくなどの工夫が必要だよね
いわゆるGCならGCを一時的に止めるだけで比較的簡単に実現できる

ただ、C++やRustでこういう状況に対応しようとしたら arena 使うのが定石な気もするのであまり意味のない比較だったかも

そもそもこういうワークロードが現実的にどの程度存在するかもよくわからないし
freeのオーバーヘッドがどの程度大きいかにも依るので
実際のアプリケーションのベンチマークとかとらないとちゃんとした議論はできない気がしてきた
2021/11/14(日) 17:11:54.46ID:1fsz29jn
shared_ptrやRcは参照カウント方式のGC機能を提供するライブラリ
これらをGCとは呼ばないというのは無理がありすぎる

「GC言語」はGCの利用を基本的前提として設計されてる言語という意味なので
non-GC言語にGC機能が用意されてるからといってGC言語に分類されるわけではない
2021/11/14(日) 17:18:41.30ID:jU07kwMv
>>626
C#はこの前メソッドチェーンでとやかく言ってた人たちには、LINQ表現などはさらに一歩進んだ考えだが、彼らが
このような記述表現が、仮にお気に入りの言語に入っても大喜びするとはとても思えない。
GCの観点でいえば、JavaやC#などのclassで参照を多用して並列GCでストップのあるものと、Goのようにstruct値
だけだが、軽量スレッドがあるために並列GCにしなければならなかったものとは同じ土俵で比べるべきではない
これは同じく、並列GCを用いないDIO様がいない世界の言語とも比べらずらい。
2021/11/14(日) 17:26:09.38ID:a1LUiRLL
>>633
shared_ptrやRcはライブラリではありません
単なるスマートポインタです
ポインタを使い終えると対象を自動的に解放します

例えばC++では同じスマートポインタとしてunique_ptrもあって使い終わると自動的にdeleteが呼ばれて解放されます
同様にshared_ptrもあって使い方終わると自動的にdeleteが呼ばれて解放されます

これらのどこにガベージコレクションの要素がありますか？
shared_ptrをGCだと主張するならばunique_ptrについてはどうですか？
もし仮にdeleteが呼ばれて解放することをGCだと主張するならばC++では常にGCが行われていることになってしまいますが？？
2021/11/14(日) 17:53:57.69ID:oGwX+s7w
>>632
freeはそんなに重くないにしても、メモリアロケーションは論理アドレスから仮想アドレスへ変換し更には連続し
適したサイズの空間を見つけるために当然ながら重くなる。
Linuxカーネルの場合のBuddy実装があるに、tcmalloc/jemalloc/dlmalloc/mimalloc/boehmなど、プログラムに
より適化したOSSの実装が次々と出来ていることからも、仮にプログラムがメモリ漸増するものではなく決定論的な
予測が可能である場合なら、逐一メモリー確保のためにOSに介在するよりも、プログラム開始時にドカンとメモリを
確保したほうが早くなる可能性もある。もし可能なら今の型推論と同じくこれはコンパイル時に解決されるだろう

そういった意味で言えばアロケーションと解放のプログラムからの切り離しは、Goにおけるコンテキストスイッチの
話とも似ていて、言わばローテクともいえる参照カウントや逐一解放が絶対的、将来に渡って良いとは言い切れない。
もちろん並列GCのおける全停止は問題だが
2021/11/14(日) 18:45:12.28ID:IFj7jNe6
流れまったく読んでないけど
スマートポインタはGCではないだろうｗ
Javaが出るときC++とくらべてこんなにもシンプル！というのと
C++とくらべてGCがある！という宣伝だったと思うけど
2021/11/14(日) 19:33:55.78ID:hzlmyWav
ランタイムレベルてmark-and-sweepしたりcopy GCしたりするやつはtracing GCという名前が付いています
使い分けよう
2021/11/14(日) 19:59:08.54ID:H2p4AXVo
>>637
Javaが出たときにスマートポインタってあったのか？
2021/11/14(日) 20:11:47.32ID:ZVLFUc33
疎結合という便利な言葉を思い出したから使おう
言語仕様を一切変更することなくスマートポインタを追加とか削除できるのは疎結合だよな
2021/11/14(日) 20:20:08.21ID:nX++DjHB
なんでGCの有無を気にするかというと、GCの挙動があるとやりづらい対象があるからでしょ？
GCが前提にある言語だと、大抵はその言語の普通のスタイルからかけ離れた、マイナーなテクニックが必要になってウザい
GCが無くても普通に使える言語ってのは、プログラマのUXを変えずにそういうジャンルに手が届く＝同じノウハウを共有できるから良い

そういう意味ではRustはRc無しで十分に使えてる。何でもかんでもRcやArc！みたいな風潮は無い
2021/11/14(日) 20:23:46.45ID:hzlmyWav
>>640
単にopt-inであるってだけじゃないですかねそれは
疎結合っていうとインターフェースが適切に定義されていて特定の実装に依存していないこと
2021/11/14(日) 20:24:33.68ID:aMI8HmcJ
意味不明なことを書いたやつが一番偉い
2021/11/14(日) 22:27:20.79ID:1fsz29jn
>>635
参照カウント方式はGCじゃないって主張なの？
それならshared_ptrやRcはGCじゃないって言うのは理解はできる(同意はしないけど)

参照カウント方式もGCの一種だけど
それを実装してるshared_ptrやRcはGCじゃないって主張ならちょっと理解不能

ちなみに有名なGC本の「The Garbage Collection Handbook」には
shared_ptrやunique_ptrが参照カウント方式のGCとして説明されてるよ
2021/11/14(日) 23:54:26.37ID:a1LUiRLL
>>644
C++もRustもこの点で全く同じだからC++で説明すると

まずunique_ptrは所有者が常に1人だけのスマートポインター
所有権は譲渡することができる
所有者のスコープが尽きたら自動的にdeleteが呼ばれて開放(回収)される

次にshared_ptrは所有者が複数可能なスマートポインター
所有権は共有することができる
全ての所有者のスコープが尽きたら自動的にdeleteが呼ばれて開放(回収)される

このようにどちらも全く同じ仕組み
(1) shared_ptrでは所有者の数を数えるためにカウントしているけれどカウントしているとGCなの？
(2) unique_ptrでは所有者1人だからカウントはしていないけど全く同様に自動的にdeleteされて回収だけどGCなの？
(3) スマートポインターを使わない場合は手動でdeleteを呼んで回収だけどGCなの？

以上の3点をよろしくおねがいします
3つとも仕組みは全く同じで同じように回収されていきますがカウントしているとガベージコレクションなのですか？
2021/11/15(月) 00:19:00.87ID:G6Uf4SLx
教科書等の標準的な定義と違うことを言い出す奴が
説明しろよ
2021/11/15(月) 00:48:36.22ID:4clAYLzs
garbage collectorとgarbage collectionは別だろう
645の1,2,3はいずれも後者の一手法に該当する
前者は後者を実行する主体であり、スマポは前者には該当しないとするのが普通
能動的にgarbage collectionを行うというよりプログラマ自身がそれを行うための補助に過ぎないからな
2021/11/15(月) 02:20:47.19ID:I69rZ/Of
俺が信じるGCを信じろ！
2021/11/15(月) 06:44:36.60ID:IExf6kKf
手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGCだよって言えばshared_ptr、unique_ptrはGCになるでしょう。
でもヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGCだっていえばshared_ptrとunique_ptrはGCにならないでしょう。
2021/11/15(月) 06:52:03.10ID:a976/UsH
>>649
＞手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGC
足りない。
この条件＋「循環参照も問題なく扱える」という条件を追加して！

＞ヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGC
動作タイミングはGCの本質ではないとおもいます
2021/11/15(月) 09:26:37.89ID:VyWPF7Kj
>>648
藁人形論法が標準化されたら平和になるどころか争いが増えるだけだな
2021/11/15(月) 10:23:26.99ID:erRzLCTJ
なんだ朝鮮人か
2021/11/15(月) 10:35:19.43ID:jmulRpeu
うっせー！GCじゃないぞ！こ、これはセガサターンだ！(笑)
2021/11/15(月) 10:59:52.82ID:VyWPF7Kj
争いの原因は多様性ではなく
テンプレ化した標準的な決まり文句なんだよ
2021/11/15(月) 11:17:46.17ID:A0Oqbbcg
なんか変なこと言われてたような気がしたけど、Perlは参照カウンタ方式のGCを採用した言語だよ
2021/11/15(月) 11:36:02.99ID:EiiKCwr/
「The C++ Programming Language(4th)」もshared_ptr達をgarbage collectionの一種として説明してるね

===引用===
Thus, shared_ptr provides a form of garbage collection that respects the destructor-based resource management of the memory-managed objects.
(中略)

We can address problems related to the lifetime of a shared subobject by introducing a form of garbage collection. For example:
struct S2 {
　shared_ptr<int> p;
};
(中略)
In fact, shallow copy and such entangled objects are among the sources of demands for garbage collection. Entangled objects lead to code that is very hard to manage without some form of garbage collection (e.g., shared_ptrs).
=========
2021/11/15(月) 12:56:43.04ID:1YFhL4pj
擬似問題起こしているな。
とりあえず>>633はちゃんと区別して議論したら？

c++は「GCを前提とした言語」じゃないけど「GCの機能のある言語」だろ。
2021/11/15(月) 13:03:44.58ID:0QQJPtP8
garbage collectionを実行するのがプログラマなのかgarbage collectorなのかというだけの話だな
プログラマから見てgarbage collectionが完全に隠蔽されているなら、
参照カウント方式だろうと何だろうと、もはやどこかにgarbage collectorなるものが存在していると考えていいだろう
C++のスマポはプログラマが意識しなくていいという程ではないからふつうgarbage collectorとは呼ばない
2021/11/15(月) 13:23:45.49ID:aBLKVvRB
参照カウンタはgcでは無い、ということにすると
なんか技術的な発展あるの？
2021/11/15(月) 14:49:22.20ID:5AOSdK5N
gcの実装手段の1つとして参照カウンタはある
しかし参照カウンタだからといってgcということにはならない
それだけｗ
2021/11/15(月) 14:52:33.47ID:I69rZ/Of
コア言語レベルだと、GCのある言語/無い言語って区分は正確じゃなくて
手動でメモリ管理しなくていい言語/しないといけない言語
っていうのが正しいよね

手動管理しないといけない言語でも、ライブラリのサポートによって部分的にGCまかせにすることはできる
その場合でもGCを使う選択だけはプログラマが明示的に行う必要がある
2021/11/15(月) 14:58:20.09ID:VwWTxToJ
>>659
純粋な参照カウント方式のみでは循環参照に対応することができず、一般にGC付きの言語とされているもので参照カウント方式を採用している言語は、それ以外にマークアンドスイープなどで循環参照が起きた場合それら自身以外から（プロセスのRootから連鎖的に）指されていないことを見つけ出して削除する方法を併用している

これを行わない場合、つまりC++のshared_ptrなどの例の場合は、適宜手動でweak_ptrを用いるなどして循環参照が起きないようにプログラマが管理するか、プロセスが終わるまで循環参照が残存する事を許容する必要がある

従って参照カウント方式そのものをGCでないということにすると、完全に自動化されているGCを考える場合は、その循環参照への対処に対する+αの手法が何かというところに重点が置かれるし、その+αが弱参照のような手動の手法である場合、メモリ管理が完全には自動化されていないという点でGCでないと線引きする事ができる

と、私は認識している
間違いがあったら有識者は叩いてくれ
2021/11/15(月) 14:58:31.40ID:OV4818+l
>>645
プログラマーの視点からはその(1)(2)(3)の3つともGCではないな
C++言語仕様的にその3つは全く同様にdeleteで配列でもクラスのインスタンスでもメモリ回収されていく
だから参照カウンタを用いているshared_ptrだけGCだとの主張にも実態との大きな乖離があり違和感がある
GC派の人は以上の点をどう捉えている？
2021/11/15(月) 15:10:31.33ID:U/bVngDM
>>636
GCの未来を考えると、確かに、特定のアプリケーション領域に特化したメモリー確保やアライメントがあるわけで
tcmallocやhoardが低スレッド数では明らかにglibなどのmallocより速い事は、現状のシンプルな参照カウントが
絶対的に有利とはいえないね。GCであるない分類なんてどうでも良い話だわ

ちょっと前の話で出てきたUnity3Dで構築済みのオブジェクトをキャッシュして使いまわしパラレルGC（もっと
言えばS.T.W)を発生させないというテクニックも一歩前に進んで考えれば、都度のメモリー確保と破棄の時間を
省略し、さらに進めば複雑なオブジェクト構築に掛かる時間も部分的には省略可能なわけで、そこまでGC実装が
手が届くかはまだ疑問が多いが、今コンパイラにある最適化して実行速度を速めるフラグにはあまり使われない
バイナリーを小さくするトレードオフなフラグがあるが、メモリー効率を無視してより実行速度を高めるような
最適化を行うことを行いだしても不思議ではない。C系のコンパイラだとシステムコールや標準ライブラリには
厳密な意味があるのでメモリーの事前確保は難しいかもしれないが、他の言語でよくあるList構造なんかでは
それが必ずメモリー確保を必ず同期的に行うとは深く言及していない言語は、そのような道をたどるかもしれない。
tcmalloc/jemallocなんかもメモリプールを随分前に導入しているしね
2021/11/15(月) 15:22:07.43ID:A0Oqbbcg
>>662
Perlに限っていうと、参照カウント式のGCしかなくて、循環参照を自動で削除するような方法は併用されていません
よって、おっしゃるようにプログラマが弱参照を使ってくれないとメモリリークが簡単に起きます

でもPerlもGC言語の仲間に入れてください。お願いします
2021/11/15(月) 15:26:35.98ID:5AOSdK5N
まあgcは自力で実装できるしね
2021/11/15(月) 15:34:27.74ID:Yv2HsXEI
Rust 使っとけばオケという事でオケ？
2021/11/15(月) 15:35:25.23ID:OV4818+l
>>665
Perlは全てが参照カウンタでありプログラマーはそれを意識することなく回収されていくから明確にGC
一方でC++やRustは基本的に参照カウンタは用いておらずプログラマーは複数所有になる時のみ意識してshared_ptrやRcを用いており回収される時には付加動作もプログラミング可能だからGCではない
2021/11/15(月) 15:47:49.42ID:A0Oqbbcg
せやな
2021/11/15(月) 15:49:13.29ID:+RUh9SHS
>>664
まあメモリーの少ない環境で処理のピークとなるようなメモリー確保を行うのは迷惑かもしれんが、現状だって
多くのアロケーターはvec![1, 2, 3]やmake([]int,5)としても断片化させないために2^Nの確保を行うからね。
逆を言えばメモリーの使用量効率が圧倒的に（現在の理論の範囲では）良いのはRust/C++だろうけども使用量が
ピークに耐えうる環境で無ければ、実行できないか例外やパニックになり目的の動作を達成しえないわけで
逐次の動的確保と解放を完全否定するものではないが、アロケータのメモリープールは実装され実証されていて
GCというか確保と解放をプログラミングから切り離す事は正常な発展の道だとも思える

GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけで、それを全員認めて広く世に
一般化がなされても自己満足以外に何か得られるようなものではない
2021/11/15(月) 15:58:26.75ID:g6hTEDoE
Perlは循環参照だめなのか
そりゃ廃れるわ
2021/11/15(月) 16:04:42.57ID:+RUh9SHS
RustもSwiftも循環参照はダメだぞ
2021/11/15(月) 16:13:30.50ID:OV4818+l
>>670
ヒープを用いるだけのことまでもGCとみなすその考えはおかしいのではないか？
その考えだとC言語でfree()することもGCとなってしまう
2021/11/15(月) 16:34:13.53ID:OV4818+l
>>672
CでもC++でも循環参照は当然起きるけど何を問題にしている？
所有者の概念のある諸言語は所有権を持たない弱参照が必ずあるので困ることはない
同時に生ポインタがある諸言語は自分で管理することも可能
そこがGC言語との大きな違い
2021/11/15(月) 16:35:06.88ID:rXstoGa9
>>673
ちゃんと元読んでます？ハードウェア寄りのOSやドライバーを書く言語では、厳密性が求められるだろうから
実際に確保しない/実際には開放しないなんて許されないだろうけど、C言語でも数あるアロケーターはfreeで
実際には使われていないマーキングだけが行われる事もある。そしてfreeでOSに返却した場合でも、OS自体が
コンパクションの動作を行うなどはGCであるとは言えないが、GCのような動作を行う。何が違うかといえば
アプリケーションが関与してないだけであり、重要なのはCPUは使用されるという事であり無駄を省くという
観点からいえば、GCという枠を超えメモリー管理は特化した最適化が行えるだろうという話
2021/11/15(月) 16:47:58.36ID:OV4818+l
>>675
そこは明確にレイヤーが異なる
(1)OSからシステムコールでヒープ領域の大きさを変更するレイヤー
(2)確保されているヒープ領域の中を管理するレイヤー
(3)GCやデストラクタ等でプログラムから利用された部分をヒープ領域に戻すレイヤー (逆の確保も含む)
今回行われているGCの件は(3)の話
2021/11/15(月) 16:51:08.56ID:OV4818+l
>>676
誤記を訂正しておく
ごめんね

誤: (1)OSからシステムコールでヒープ領域の大きさを変更するレイヤー

正: (1)OSへのシステムコールでヒープ領域の大きさを変更するレイヤー
2021/11/15(月) 16:52:32.87ID:u/x8IP+K
>>676
あなたがしたい話をしている場ではありません。全く１つも理解していないのに絡んで来ないでください。
私は所有者だの弱参照だの話してませんし正常に話す気が１つもない人を相手にするつもりはありません
2021/11/15(月) 17:18:38.26ID:0t2kAlwU
Swiftは何でもそろってるので何でも対応可能
strong参照
weak参照
unowned参照
UnsafePointer
UnsafeMutablePointer
UnsafeRawPointer
UnsafeMutableRawPointer
UnsafeBufferPointer
UnsafeMutableBufferPointer
UnsafeRawBufferPointer
UnsafeMutableRawBufferPointer
AutoreleasingUnsafeMutablePointer
OpaquePointer
などなど
2021/11/15(月) 17:52:45.80ID:ZplVgP5c
スマートポインタをGCであるということにして
誰がどう嬉しいんだろう？
持ったポインタをデストラクタでdeleteするだけのコンテナに対してだ
2021/11/15(月) 19:53:26.70ID:VyWPF7Kj
こうすれば嬉しいという理想よりも
どうしようもない現実の方を重視する人もいるかもしれない
2021/11/15(月) 20:12:28.41ID:Xr7xQZWT
循環参照OKな言語ってあるの？
2021/11/15(月) 20:20:40.01ID:SRkaJxph
>>680
>GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけ

辛辣www
ほとんどの人は興味ないが、某お気に入り言語の一部の狂信者が、同じく参照カウントのSwiftはGCと
言われるのに、お気に入りの言語はそう呼ばれくなくて信者を増やしたんだろう？そんなことで集めた
信者なんて役に立たないどころか稚拙なコードの手直しをすることになりかねないのにね
公式がそのような文言で宣伝してるから、ある意味では勅命とか聖戦みたいなもんだな
2021/11/15(月) 20:35:30.27ID:1YFhL4pj
>>680
スマートポインタは「GC機能」の実装（のひとつ）だろ。このスレでいう「GCを前提とした言語」になるわけではないが。

一部の人間が悪意を持って「GC機能」と「GC言語」を混同しようとしているからグダグダになる。>>683に同意せざるを得ない。

そもそもの話、wikipediaの定義（解説）に異論のあるやつは居るの？

ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である。
2021/11/15(月) 21:05:38.94ID:VIw7Bjxz
近頃の言語でGCのタイミングをプログラムから制御できるのはないの?
2021/11/15(月) 21:07:57.52ID:mUBmyW6D
スマートポインタはGCではないということにして
誰がどう嬉しいんだろう？
2021/11/15(月) 21:08:32.33ID:0t2kAlwU
>>684
>>ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である

それだけだとC++(11以降)もSwiftもRustもGC言語ということになってしまいます
だからその定義が不十分なんだと思います
2021/11/15(月) 21:21:58.47ID:PbjRD0ud
>>687
いや、それはGCの定義なんだから十分だろう
不足してるとするなら「GC言語」の定義
まぁ言語機能にGCが組み込まれてるならGC言語で
ライブラリとして実装されてるだけ（C++やRust）はGC言語ではないって感じだと思うが、正確な定義は知らん
2021/11/15(月) 21:28:35.39ID:VyWPF7Kj
>>685
参照されなくなったポインタをデストラクタに渡したらデストラクタ内で参照される
デストラクタ内でポインタを復活させるようなコードを容認するとGCの性能がどんどん下がる
だからGCの性能を上げたい言語にはデストラクタ機能がないのが合理的
2021/11/15(月) 22:06:51.83ID:a8RVVDGO
>>685
Golangは、SetGCPercent(-1)でスタートさせてruntime.GC()を手動で呼び出す事は可能らしい。Java系というか
JVMだとSystem.gc()というものがあるが、これは確実にGCを行うわけでもなくて提案なのであまり意味がない。
Java11ではno-op garbage collectorが-XX:+UseEpsilonGCが実装された。いわゆる上のほうで書いてあるような
短期間で直線的な定量のメモリで終わるバッチのようなプログラム用だが・・・
C#というか.NETだとSystem.GC.Collect()とか、GC.TryStartNoGCRegion()でGCを動かさない指定ができる。
SwiftはARCが強制でもないのでGCを自作すれば…できる
2021/11/15(月) 22:07:26.02ID:9V9ekymj
>>687
「機能である」と書いてあるだろ。
よく読めよ。どこに「言語である」と書いてあるんだよ。

お前は「機能である」ことに同意しないのか？
2021/11/15(月) 22:14:38.76ID:ZplVgP5c
自動的ってとこに着目できるかもな
スマポをプログラマが手動で使うのに
自動的に開放とはこれいかに

ガベコレ言語がもたらす本当の自動を知っているプログラマなら
スマポはあくまで手動にすぎない
内部でdeleteをしてるコンテナを使ってるだけにすぎない
2021/11/15(月) 22:17:50.89ID:9V9ekymj
>>688
そりゃそうだ。「GC言語」のまともな定義なんて無いからな。整理しようとするレスも無視しているしな。
定義も無いまま同意構築もしないまま、擬似問題をグルグル繰り返しているだけ。
しかも自分のお気に入り言語を擁護するために、何回も何回も何回も繰り返し引っ張り出すから腹立たしい。
2021/11/15(月) 22:27:16.63ID:9V9ekymj
>>692
プログラマが「いつ」スマートポインタの参照先のリソースを手動で解放する操作をするのか説明してもらえませんか？

「スマートポインタ」が分かりづらいというなら、c++の「shared_ptr」でいいですよ。
2021/11/15(月) 22:31:47.59ID:5AOSdK5N
正直定義なんてどうでもいいと思うんだが・・・
伝わればいいと思う
2021/11/15(月) 23:07:31.08ID:ESQg0oe1
>>682
ARCだけじゃなければ循環参照を回収するサイクルコレクターが動くので、OKというか循環参照全体を参照する
変数が消えれば消える。ARCの強参照は当然ながら連鎖的には消えない。
これがよく言うARCのメモリーリークでSwiftやObjective Cで起こる現象、親の所有者が消えたのだから内部で
参照しあっていても消えると考えてしまう。サークルを作らず直線状なデーターやツリー上のデーターならば
連鎖的に消える。
ただし、サイクルコレクターがある場合でもグローバル変数になっている場合には終了時のすべての変数が寿命を
迎えるだけなのでそこで壮大なメモリー解放が起こる（これを指して意味がなく壮大な無駄だという人もいるが）
そして、SIGTERMを送ってもなかなか終了しないプログラムは一生懸命メモリー解放を行っていたりする
2021/11/16(火) 00:38:45.88ID:cHZw5Yem
同じように参照カウントを用いていても状況が真逆で決定的に異なる

GC言語
[対象] 全て
[手段] プログラマーは何もしない
[期限] プログラマーは意識していない
[適用] プログラマーから適用機構は見えない
[機能] 解放のみ

C++のshared_ptrやRustのRc
[対象] 所有者が複数となるレアケースのみ対象
[手段] 明示的にshared_ptrやRcをプログラマーが使用
[期限] どうなると解放されるかタイミングをプログラマーが把握
[適用] 解放のためにdelete(デストラクタ)やdropが適用される
[機能] 解放時にデストラクタにて関連プログラミングが可能 (ファイルを自動クローズなど)

したがってC++やRustは手動メモリ管理でありGCの定義「自動的に解放する機能である」を満たしていない
あくまでもC言語と同じく手動メモリ管理の延長(省力化)でありGCではない

【結論】
『C++やRustのスマートポインタはGCではない』
2021/11/16(火) 00:54:53.09ID:O0etR+7l
>>697
その定義でwikipediaの説明風にGCの説明書いてみてよ
2021/11/16(火) 00:56:44.96ID:cq8/Yorc
>>697
主観的な記述だと思いますね
私は循環参照を許容できなければ、それはもはや GC ではないと思っています
マークスゥイープかコピーGC（そしてその発展系）しか私は認めません…①

①はともかく、何ができて何ができないか、により GC か GC でないかを明晰に分別すべきかと
2021/11/16(火) 03:05:17.23ID:O0etR+7l
プログラマがfree相当の処理を明示的に書かなくてもメモリが解放されるのがGC

解放契機がGCの回収だろうがスコープを抜けるタイミングだろうが
コンパイラやランタイムといった処理系が暗黙的に解放処理を挿入するという点では同じ
サイクルを回収できる/できないの違いは、保守的GCと正確なGCの差違のように、GCという大枠の中での細部の差違でしかない
2021/11/16(火) 03:08:48.13ID:O0etR+7l
単にGCと言ったときにガベージコレクションを意味するのかガベージコレクタを意味するのかが場合によって異なるから混乱を招いているのか
2021/11/16(火) 03:19:14.90ID:cHZw5Yem
>>700
プログラマーがfree相当の処理を明示的に書くことが
プログラマーがスマートポインタを明示的に宣言することに変わっただけなので
『スマートポインタはGCではない』となりますね
つまりプログラマーが明示的に関わっているか否かが要点
2021/11/16(火) 05:03:45.36ID:GjD3AmtU
>>702
「スマートポインタを明示的に宣言すること」がどうして「free相当の処理を明示的に書くこと」
になるのか理解できないなぁ。
宣言している時点では参照先のリソースを使用しているので、その宣言で解放されると困るわな。

ついでに言うと、shared_ptrにリソースの管理を任せるときは、shared_ptrがプログラムコードの
どの部分で（ソースコード記述的に）リソースを解放するのか決定できないことが多々ある。
これは「free相当の処理を明示的に書くこと」と決定的に異なる部分だな。
2021/11/16(火) 06:34:55.21ID:2/DPJM9H
じゃRustは所有権管理方式のGCってことでいいのかな？
2021/11/16(火) 06:46:59.83ID:rMNMpo6C
>>704
これまでのお約束とは異なる新しい判断ですね。
2021/11/16(火) 08:06:16.34ID:KQuNI5Eh
>>704
機能だけ見れば、Rustは参照カウント方式の「GC機能」を持っていると言えるだろ。

「GC言語」とかいう定義もはっきりしないバズワードに当てはまるかどうかは知らん。
2021/11/16(火) 08:37:19.90ID:mhJuEb25
「GC機能」とやらはどこで定義されてるん？
2021/11/16(火) 08:42:24.55ID:KQuNI5Eh
>>707
>>684にWikipediaの記載を引用したから。
それともWikipediaの記載に異論あり？
2021/11/16(火) 08:47:56.56ID:cHZw5Yem
以下いずれもやっていること・行われることは全て同じ
抽象化と省力化が進んだのみ

C「free()で解放」
　↓抽象化＋付加機能
C++「deleteでデストラクタを呼んで解放」
　↓自動化＋所有概念(専有vs.共有)
現C++「スマートポインタ利用でdeleteを自動行使」
　↓全般化＋静的完全性チェックbyコンパイラ
Rust「全てがスマートポインタ相当扱い」

これらとGC言語の違いは「プログラマーがメモリ管理をしていること」
つまり一見すると自動解放されるためメモリ管理していないように見えるが
プログラマーは所有権を管理することでメモリ管理をしている

GCの定義を「利用者がメモリ管理をせずとも自動的にメモリが解放される」とすることで皆が納得できる
2021/11/16(火) 08:59:05.41ID:2/DPJM9H
>>706
Arc/Rcのことじゃないよ

動的に確保したメモリ領域を指してる所有権のある変数が
ムーブされずにスコープを抜ければ解放されるようコンパイラがよろしくやってくれる
これも参照カウント方式？
2021/11/16(火) 09:08:46.14ID:mhJuEb25
>>708
ソースはWikipediaなの？

ちなにみ英語版では
> In computer science, garbage collection (GC) is a form of automatic memory management.
となってて機能というより形式って感じかな？　どうでもいいけど

あと
https://en.wikipedia.org/wiki/Manual_memory_management
のページのRAIIの段には
> This can also be used with deterministic reference counting.
> In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework,
> use of the shared_ptr template in the language's standard library to perform memory management is a common paradigm.
こういうのがでてきてるね
automate memory deallocation ね
2021/11/16(火) 11:32:23.17ID:O0etR+7l
RustやC++にGCがないという言及でGCが意味するところはガベージコレクタというランタイム処理ののことで
ガベージコレクションの仕組みがないとは言っていないという理解をしている
2021/11/16(火) 11:59:42.80ID:cHZw5Yem
>>712
C++とRustは所有権による手動メモリ管理
ガベージコレクションではない
2021/11/16(火) 12:16:23.63ID:/J0mEe48
いつまでやるんだよこの話
GCスレでも作ってそっちでやれ
2021/11/16(火) 13:00:34.21ID:KQuNI5Eh
>>710
カウントしていないから違うんじゃないのかね。実際、他が参照していても（不要でなくても）スコープ抜けると解放されるし。

>>711
読み込めてないけど、スタックの積み降ろしでリソースを管理するのは昔からあったね。スタックマシンとかスタックのみforthとか。

>>713
さんざん指摘しているのにGC機能の定義が間違っているから話にならない。
2021/11/16(火) 13:01:16.80ID:pnSrHZZq
ぼくのかんがえたさいきょうのGC言語の定義なんぞ
プログラム作成になんの役にも立たんから
好きにしてくれ
2021/11/16(火) 13:24:00.95ID:cHZw5Yem
>>715
GCの定義ははっきりしている

ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち不要になった領域を、手動メモリ管理に依らず、自動的に解放されること。
2021/11/16(火) 14:12:09.47ID:2/DPJM9H
>>712
その場合はガベージコレクタとは何か？
ランタイム処理とは何か？って定義がないと境界線が曖昧なまま

ガベージコレクションを行う主体(行為者)をガベージコレクタ、
コンパイル時じゃなく実行時に解放タイミングを決定する意味でランタイム処理と言ってるなら
RustのRcやC++shared_ptrはGCの意味するところに当てはまる

ランタイム処理がGoやObjective-Cのようなruntime libraryによって行われる処理って意味で言ってるならあてはまらない
2021/11/16(火) 14:12:38.51ID:vHF3kJ9c
wikipedia含め自然言語の定義など絶対的なものじゃないよ
その言葉を使った文脈で意味が正しく伝わればいいだけ
2021/11/16(火) 14:16:08.22ID:x6Dvmgzi
>>714
Rust狂信者がGC無いということにして布教したくて、大暴れして嫌われてる真っ最中。完全頭がイカれてる
個々人の見方によればどうでも良い事なんだが、狂信者の"信仰が揺らぐ"ので納得しない。
2021/11/16(火) 14:24:20.34ID:JxdD+I2A
科学技術と科学技術が対立するのはよくある現実

対立するのは科学と宗教だと思ってるのは現実逃避
2021/11/16(火) 14:25:50.64ID:SlziVE7V
>>720
C++とRustはGCが無いよ
その代わり自分で所有権の管理をしないといけない
見返りとしては速い
2021/11/16(火) 14:26:44.88ID:2/DPJM9H
>>715
参照カウントじゃないとしてGCの定義にしたがった場合にRustのやり方は何らかの方式のGCなのかどうか？

あとSafe Rustなら他が参照してればコンパイルエラーじゃないかな
unsafeなら参照側を長生きさせるバグを埋め込むことは可能
2021/11/16(火) 14:28:43.97ID:QRdL5Qqy
参照カウントは、GCか、GCじゃないのか

クソどうでもいい
まあGCだけどね
2021/11/16(火) 14:28:57.30ID:hZl5lwq3
>>722
明確に間違いだな
自分で所有権の管理ができない場合にARCを使うんだろ？
2021/11/16(火) 14:31:25.51ID:x6Dvmgzi
Rust寄りの話をすればGCの有無という定義より、現時点のコンパイラの方法は、Rustがメモリー回収の
コスト(CPU消費）が他に比べて小さいだけの話。参照カウントやBoxのようなスコープで解放と確保を
繰り返す事を「GCの有無に関せず」コストを話している人にも定義の有無の話にレイヤーが違うなどと
言いつつ巻き込んでくる。マジもんの狂信者には言葉は通じない
2021/11/16(火) 14:34:03.96ID:SlziVE7V
>>725
Arcはマルチスレッドで共有する時にRcに対してアトミック操作が必要な時にRcの代わりに用いる

シングルスレッド共有:　Rc
マルチスレッド共有:　Arc　shared_ptr

もちろん後者の方がコストが高い
2021/11/16(火) 14:40:58.65ID:x6Dvmgzi
SwiftやObjective Cなんかはさらに進んでいて、ARCだけだとカウントがボトルネックになる場合があるから
特定のデータ構造についてはGCみたいのを自作する。狂信者は聖典に書いてあることが真理。
レイヤーはネ申が決めた侵さざるべき領域、なんじネ申の言葉たるRustを喋れ、邪教たる他言語を駆逐せよ
2021/11/16(火) 14:42:11.98ID:SlziVE7V
>>725
そしてもちろんshared_ptrもArcもRcも所有権を管理するために用いる
所有者が複数可能

一方でunique_ptrやRustの一般は所有者が1人のみなので所有権は維持するか譲渡するかになる
2021/11/16(火) 14:57:58.41ID:bbFwgKot
>>727
ARCってこれのことでは？std::sync::Arcじゃなくてさ
https://en.m.wikipedia.org/wiki/Automatic_Reference_Counting
2021/11/16(火) 15:08:54.50ID:SlziVE7V
>>730
それはSwiftやObjective-Cの話
一方で>>725はC++とRustの話に対してレスしている
2021/11/16(火) 15:26:54.21ID:mhJuEb25
https://doc.rust-lang.org/std/rc/struct.Rc.html
> A single-threaded reference-counting pointer. ‘Rc’ stands for ‘Reference Counted’.

https://doc.rust-lang.org/std/sync/struct.Arc.html
> A thread-safe reference-counting pointer. ‘Arc’ stands for ‘Atomically Reference Counted’.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
> In computer science, garbage collection (GC) is a form of automatic memory management.

GCを自動メモリ管理の一形態と定義するなら
RCもARCも手動メモリ管理側に属するやろね
したがってGCではない

https://en.wikipedia.org/wiki/Manual_memory_management
> In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework
> C ++では、この機能(訳注：RAII)をさらに活用して、手動のフレームワーク内でメモリの割り当て解除を自動化します。
2021/11/16(火) 15:32:41.58ID:hFtCxoVx
嫌われ者の屁理屈大会
2021/11/16(火) 15:45:11.75ID:SlziVE7V
>>732
それはもちろんそう
GCは定義にあるように自動メモリ管理
一方でC++とRustのスマートポインタは手動メモリ管理
したがってGCではないことが明白
2021/11/16(火) 16:05:00.39ID:hZl5lwq3
>>729
その複数の所有者によって共有される所有権を管理してるのは誰？
プログラマではなく「自動参照カウント機能付きのスマートポインタ」が、「自動的に」所有権を管理しているんだろ？
2021/11/16(火) 16:07:51.68ID:wMIJ1Zq8
GC言語でもどの変数がどのオブジェクトの所有者か意識してコードを書けばそれは手動管理しているからGCじゃないってことになるの？
C++やRust使ってても所有者を気にせずに全部shared_ptrかRcにするようなコードの書き方をすればGCになっちゃうの?
2021/11/16(火) 16:09:38.42ID:QRdL5Qqy
Perlでメモリリークしがちな参照カウント方式でもGCとみなしてくれるなら許す
2021/11/16(火) 16:21:49.03ID:SlziVE7V
>>735
いえいえ
GCのように見えない意識しない魔法があるわけではなくて
例えばRcはstruct Rcという構造体の型に過ぎなくてプログラマーは管理のために色んなメソッドを発行することも出来るんですよ
例えばRcから弱参照のWeakを作り出したりRc自身の弱参照数を得たり増減したら強参照数も同様です
つまり手動メモリ管理の範囲内なんですよ

>>736
GC言語には所有権の譲渡の機能もないし手動解放の機能もないためGC言語で手動メモリ管理は無理だと思います
2021/11/16(火) 16:39:25.01ID:mhJuEb25
https://en.cppreference.com/w/cpp/memory/shared_ptr
ここにもズラズラ並んでるけどいろんな手動管理をさせてくれるよね
reset, swap, get, use_countなどなど
そもそも
https://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr
コンストラクタの時点で豊富にプログラマに選択肢を与えてる
アロケータやデリータも指定できて自由自在
このように、色々やることあるねプログラマ側は
2021/11/16(火) 16:42:40.84ID:mhJuEb25
あ、ズラズラというならRcのほうを引用したほうがさらにズラズラだったか…
2021/11/16(火) 16:49:31.73ID:XOoLtgC/
ちなみにshared_ptr/RcがGCじゃない派の人って
C++のBoehmGCはどっち判定なの？
使い方的にはshared_ptrと同じくプログラマが明示的にBoehmGCからメモリ割り当てないといけないから
GCじゃないって扱いになるわけ？
2021/11/16(火) 17:11:12.20ID:SlziVE7V
>>741
BoehmGCは手動メモリ管理ではなく
自動メモリ管理なのでGCです
プログラマーは所有権の譲渡や共有などのメモリ管理を全く意識せずに使えるからです
2021/11/16(火) 17:15:07.88ID:7dBj/34m
屁理屈大将
2021/11/16(火) 17:18:12.78ID:4mjXbMzz
>>741
「手動メモリ管理はGCじゃない」んだからBohemGCもGCじゃないんだろ、そいつらの中では。
2021/11/16(火) 17:23:12.05ID:SlziVE7V
>>744
BoehmGCはプログラマーが何も管理しないので自動メモリ管理ですよ
2021/11/16(火) 17:29:26.94ID:R8o6+SB5
GC_MALLOC(100000); // なにも管理しないぞ！mallocじゃないけどな！必死に自分の考えを押し付けようと１日張り付いてるニート
2021/11/16(火) 17:35:28.45ID:4mjXbMzz
>>742
手動メモリ管理と自動メモリ管理を定義して、BohemGCとshared_ptrの違いを明確化してから主張してくれ。

所有権とか言っているけど、shared_ptrもBohemGCもshared_ptr・BohemGCがリソースの解放責任を持つ（プログラマが解放するのは非推奨・未定義）ことには変わりないから、所有権とか言うならその違いも明確化してくれ。

>>745
shared_ptrだって「プログラマーが何も管理しない」だろ。何を管理すると主張する？
2021/11/16(火) 17:37:18.20ID:R8o6+SB5
vec![ 0; 100000 ]; // 何も管理しないぞ！GCじゃねえったらGCじゃねーんだ！黙れ小僧！Rustの宣伝を受け入れろ！
2021/11/16(火) 18:01:15.45ID:SlziVE7V
>>747
本気で言ってますか？
スマートポインタではプログラマーが所有権の管理をしているからこそ
毎回プログラマーはここで使うべきはunique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながらプログラミングしているのです
これを使い間違えるとメモリ管理ミスとなる多重解放や解放忘れや解放済み領域参照などが起きてしまうのです
Rustでもほぼ同様ですが使い間違えているとコンパイルが通らない点だけ異なります
C++とRustどちらもプログラマーが上述の手動メモリ管理をしながらプログラミングする点で同じです

一方でBoehmGCでは上述の手動メモリ管理をせずに使えます
自動メモリ管理方式となっています
2021/11/16(火) 18:41:22.00ID:c2zT3/Zj
Rustも使い方を間違えると循環参照ができてコンパイルは通ります。Boehmでもnew (GC) char[size]で
class Foo: public gc{}しなければ回収されません。
その他ではディストラクタの回収ではなく不定期改修ではnew (GC)で、gc_cleanupから派生させる必要が
あります。とてもではないですが、「手動」「自動メモリ管理方式」などと、屁理屈を捏ねて言い負かそうと
必死こいてる哀れな狂信者は言葉は通じないです。
2021/11/16(火) 19:14:07.66ID:cHZw5Yem
>>750
BoehmGCは言語の機能ではなくライブラリなのだから呼ばなければGCが始まらないのは当たり前
自動メモリ管理と手動メモリ管理の区別はそんな表層的などうでもいいことではない
それを理解できない人がいるとは驚いた

C++スマートポインタとRustでは手動メモリ管理のため
使い方を間違えるとメモリ管理が破綻して深刻なバグが生じたりコンパイルが通らなかったりする
これを解決するにはプログラマーがメモリ管理を常に考えてどこにどんなスマートポインタを用いたり所有権は渡さずに参照にするのか譲渡するのかコピーするのかなど毎回各所で全て考えて手動メモリ管理を行なう

一方でGC言語やBoehmGCなどは自動メモリ管理なのでプログラマーは上述のようなことを考えなくてもよい
言語システムやGCライブラリにお任せとなる
2021/11/16(火) 19:27:51.29ID:4mjXbMzz
>>749
プログラマが
「unique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながら」
プログラムしているからGCじゃないという主張か。

なら、すべてshared_ptrに統一して所有権の管理なんてしなければいい。実際、既存コードとの互換性問題やプログラムの性能問題が無ければ推奨されるshared_ptrの使い方だしな。
そうすれば>>749の主張する「自動メモリ管理方式」とやらも実現できるからBoehmGCみたいなものだ。

あと、>>751の主張をするなら、まず初めに「自動メモリ管理方式」「手動メモリ管理方式」の定義と差分を明確にしなくては話にならない。

「使い方を間違えると」とか、曖昧な話でごまかすなよ。「それを理解できない人がいるとは驚いた」みたいな人格攻撃する暇あったら、グウの音も出なくなるぐらい堅牢な議論をしてみろよ。
2021/11/16(火) 19:27:54.43ID:mhJuEb25
BohemGCは昔から気になってるけど
結局一度も触ったことが無いな

https://www.hboehm.info/gc/
> The Boehm-Demers-Weiser conservative garbage collector
> can be used as a garbage collecting replacement for C malloc or C++ new.
> Boehm-Demers-Weiserの保守的なガベージコレクターは、
> C mallocまたはC++ newのガベージコレクションの代替として使用できます。

作者（？）が言ってるようにこの場合は garbage collector なんよね
しかもガベージコレクションの代替として使用できるとのこと

なんか知らんけど色々プログラマ側から触れるようになってるんだとしたら
結局は手動メモリ管理って感じもするけど（よく知らない状態での想像）
2021/11/16(火) 19:28:00.82ID:ayQ3yI+l
Rustの不都合なことを言われて、知りもしないのに墓穴を掘る狂信者ｗ
さっきはRustならコンパイルが通らない点だけ異なりますと言っていたのに、今度は深刻なバグが生じたりと言い出す。
手動自動なんていう浅はかな考えを押し通そうとしているから、知らない事を突かれる。
まあRustの肩をもつなら、Rustは独立したスレッドのサイクルコレクターが無い点が「フルスペックのGC」では無いといえるかもしれんが
狂信者の話には１つも出てこない。あんたのその理論というにはお粗末な考えで全員が黙ったとしても、ここに顔出す人以外は
GC的なアルゴリズムだろ？と言われてまたワンワン噛みつくのか？めっちゃ迷惑だと思うがｗ
2021/11/16(火) 19:52:23.46ID:O0etR+7l
言語の分類に関して言うなら性能特性に着目して分類するのが有用
malloc/freeグループといわゆるGCグループに分けられて、スマートポインタは前者になる

>>718
後者の意図
プログラムの実行とは切り離された別のコンテキストで回収処理が行われる場合に
その行為者をガベージコレクタと呼んでいた

コンテキストという言葉は適切じゃないかもしれないが、別スレッドとか別タスクとか、そういう意味で使っている
2021/11/16(火) 19:55:08.32ID:GLAM0io0
いつの世も狂信者というのは害がないうちは、公式のご本尊や、偉い人から見逃されるけど
害を及ぼすような事をやり出したら破門されんねん、ほんま迷惑
2021/11/16(火) 19:58:48.30ID:O0etR+7l
プログラマが解放処理の呼び出しを書く必要があるのが手動メモリ管理
書かなくても(典型的なケースで)自動的に解放処理が呼び出されるのが自動メモリ管理

malloc/freeは手動メモリ管理
GCやスマートポインタは自動メモリ管理

というかスマートポインタという名前自体プログラマが介在しなくてもよしなにやってくれる賢いポインタという意味なので
これを手動メモリ管理と呼んでしまうのは違和感しかない
2021/11/16(火) 20:03:07.86ID:O0etR+7l
プログラマがshared_ptrとunique_ptrを選択しないといけないから手動メモリ管理との主張だが
仮にshared_ptrしかない言語が存在したとしたらそれは自動メモリ管理になるのか？
2021/11/16(火) 20:12:14.40ID:SlziVE7V
>>754
Rustでは手動メモリ管理を間違えても深刻な事態は起きないよ
並行時と並列時も含めてメモリ競合も問題が起きないように設計されていてコンパイラが静的に検出してくれる
メモリ関連で静的に検出できないのは循環参照くらいだよね
原理的に無理なのだからこれは仕方ない

>>752
> なら、すべてshared_ptrに統一して所有権の管理なんてしなければいい。

それだとプログラマーが管理すべきことが消えて自動メモリ管理すなわちGCになってしまうよ
もちろんshared_ptrはコストが高く遅すぎてそんなことをするプログラマーはいないね
あと一時参照やunique_ptrを駆使すれば済むところを全てshared_ptrにすると循環参照の生じる機会が激増しちゃう
だからshared_ptrの使用は最小限に抑えて他を用いる
最小限のshared_ptr使用でも循環参照の起きうるところがあるならばweak_ptrを用いて循環参照を回避する
これらもプログラマーの手による手動メモリ管理

>>757
このようにスマートポインタは手動メモリ管理です
2021/11/16(火) 20:20:02.11ID:/J0mEe48
>>755の説明が一番しっくりくるな
これならRustもGC言語じゃないって言えるしこの辺で手を打ちませんか？
2021/11/16(火) 20:38:12.95ID:UQ2IYGru
見たくない真実はガン無視する手動自動マンｗ
”サイクルコレクターが無い点が「フルスペックのGC」では無いといえるかもしれん”をガン無視して
世紀の難解手動自動相対性理論に取り組む、いまだに答えは出ないが何やら信念があるらしい。知りたくもないｗ
2021/11/16(火) 20:42:55.59ID:g0Tjvy/G
そもそもキッチリ区別できるようなGCの定義なんて元々ないでしょ

数学みたいな厳密性などはもちろんなく、ただの処理系や実装上の戦略のようなもんみたいだし、
どっちつかずな処理系もありそう
2021/11/16(火) 20:46:35.71ID:qWBIGGWe
「全部shared_ptrにしたらGCになる」ってすごいな
使い方によってなったりならなかったりするのか
その調子だとJavaにJNI経由でC由来のポインタ持ち込んだら手動管理になってGCじゃなくなりそう
2021/11/16(火) 20:47:19.95ID:LUYvY2UY
>>759
> それだとプログラマーが管理すべきことが消えて自動メモリ管理すなわちGCになってしまうよ
なら、>>759の心の中でもshared_ptrはGCということだな。
>>759の中では、GCがGCかどうかはGCをどう使うかで決まるとういことかよ。
アホらしい話だな。
2021/11/16(火) 20:55:04.64ID:7RJdn/T9
>>762
ええ意見。手動自動マンのいうとおりならSwiftはRustでいうRc,Arcなんてものは無く、弱参照はあるものの
自動でARCが動くんだけど、彼の高等理論ならどっちに分類されるんだろ…？ｗ
まあ彼・彼女？個人的な見方は否定しないけど、どうあっても他人を全否定したいみたいだけどGCの話より
どういう人なのか少し気になるｗ
2021/11/16(火) 21:08:21.89ID:cHZw5Yem
>>763 >>764
ホントに理解できていないのか理解できていないフリをしての冷やかしなのか分からなくて悩む
仕方ないので補足説明する

【以前の手動メモリ管理】
malloc等に対して直接freeをどこでどのタイミングで行うかで手動メモリ管理していた

【スマートポインタ時代の手動メモリ管理】
各種スマートポインタの使用・譲渡・コピー等および各種参照形態を
どのように使い分けてどのように組み合わせて用いるかという形で手動メモリ管理をしている

だからその使い分け組み合わせパーツの一つにすぎないshared_ptrというポインタに対してそれはGCだ！との主張は意味がないことが明らかで
もし理解出来ていない人がいるならばここで躓いている
2021/11/16(火) 21:34:08.28ID:LUYvY2UY
>>766
ちゃんと定義して、それぞれの違いを明確化するまで「手動メモリ管理」「自動メモリ管理」は使用禁止な。
エスパーじゃないんだから、>>766の心の中にある想像上の「手動メモリ管理」なんて理解できるわけ無いだろ。
この分じゃ>>766も「手動メモリ管理」「自動メモリ管理」の差分すら明確化できていないだろ。

> だからその使い分け組み合わせパーツの一つにすぎないshared_ptrというポインタに
> 対してそれはGCだ！との主張は意味がないことが明らかで

おいおい、>>759で「shared_ptrで統一すればGCになる」と発言しているだろうが。
何で「GCだ！との主張は意味がないことが明らかで」なんだよ。
>>759は意味のない主張をするようなデタラメなやつだと言いたいのか？
2021/11/16(火) 22:10:19.07ID:vHF3kJ9c
言葉の定義がどうのというバカが現れると必ずこうなるよな
2021/11/16(火) 22:30:38.03ID:SlziVE7V
>>767
wikipediaに明確な定義がありますね

『ガベージコレクション (Garbage Collection)』
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
> In computer science, garbage collection (GC) is a form of automatic memory management.
ガベージコレクション(GC)とは、自動メモリ管理です。

『手動メモリ管理 (Manual Memory Management)』
https://en.wikipedia.org/wiki/Manual_memory_management
> In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage.
手動メモリ管理とは、使われていないガベージを解放するためにプログラマが手動で命令を書くことです。
> Manual memory management has one correctness advantage, which is that it allows automatic resource management via the Resource Acquisition Is Initialization (RAII) paradigm.
手動メモリ管理にはその正しさの利点があり、RAIIを介した自動リソース管理を可能にします。
> This can also be used with deterministic reference counting. In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework,
これは参照カウントとともに使用することもでき、C++ではshared_ptrにより手動のフレームワーク内でメモリ解放を自動化しています。
> use of the shared_ptr template in the language's standard library to perform memory management is a common paradigm.

つまり上記のwikipediaにおける定義をまとめると
・自動メモリ管理　←GCはここ
・手動メモリ管理　←shared_ptrはここ
2021/11/16(火) 23:08:56.24ID:hZl5lwq3
>>769
いやそれshared_ptr自体は自動メモリ管理であり、手動管理と組み合わせて使用できるって言ってるじゃん
2021/11/16(火) 23:11:50.79ID:SlziVE7V
>>770
え？
自動メモリ管理とは書かれていませんよ
2021/11/16(火) 23:49:36.51ID:8BenLMiv
ウンコが都合の悪いことが書かれると、デカいの張り付けて手動自動理論に持っていくｗｗｗ
愛してるはずのRustにすら害を及ぼす腐った狂信者ウンコ。残ったのは自尊心のみ。「ここ」は便所の落書き
2021/11/16(火) 23:59:32.22ID:cHZw5Yem
>>770
手動メモリ管理のアドバンテージとしてshare_ptrの例が出ている>>769
774デフォルトの名無しさん
垢版 |
2021/11/17(水) 00:04:50.96ID:SsdWlmrh
>>709
これが一番納得
2021/11/17(水) 00:07:56.38ID:bZI3gHq3
じゃあSwiftは自動で管理してるからARCだけどGCなんだな？どんどんRustが嫌いになっていく…
2021/11/17(水) 00:43:47.98ID:YCf/hpfl
言語機能にどういうラベルを貼り付けるかの議論でよくもまあここまで盛り上がれるな
別に言語がGC含むとされようがされなかろうが
実態は変わらないだろうに
2021/11/17(水) 00:59:15.40ID:eNp19Ga9
>>769
Wikipedia英語版で決着ついたのか
これでスマートポインタは手動メモリ管理であってGCではないと確定だな
2021/11/17(水) 01:32:43.67ID:fpCU2YNN
まず決着を付ける目的はなんなの？
今更で申し訳無いが
2021/11/17(水) 02:15:20.38ID:iywzxd5E
>>769
そこのwikiにはshared_ptrが手動メモリ管理なんて一言も書いてないね
結論捻じ曲げすぎてびっくりしたわ
2021/11/17(水) 02:19:34.31ID:+JwFzM8R
当たり前の話なのに
びっくりしてるとしたら
そっちのが恥ずかしい
2021/11/17(水) 03:01:08.49ID:eNp19Ga9
>>779
書いてあるようだが
手動メモリ管理のよってRAIIを介したshared_ptr等の自動リソース管理を可能にしていると

>>769
>>手動メモリ管理にはその正しさの利点があり、RAIIを介した自動リソース管理を可能にします。
>>これは参照カウントとともに使用することもでき、C++ではshared_ptrにより手動のフレームワーク内でメモリ解放を自動化しています。
2021/11/17(水) 04:04:22.02ID:7Zsf8uTz
ようやくこのスレも役目を果たし終えたな
2021/11/17(水) 08:38:44.32ID:m4/STksY
>>769
なんで
手動メモリ管理　←shared_ptrはここ
という結論になると判断しているのか全然わからん。

手動メモリ管理とは、使われていないガベージを解放するためにプログラマが【手動で命令を書くこと】です。

C++ではshared_ptrにより手動のフレームワーク内で【メモリ解放を自動化して】います。

で、shared_ptrは【メモリ解放を自動化して】なので【手動で命令を書くこと】を満足していないから、手動メモリ管理ではないという結論にしかならんが。
2021/11/17(水) 08:49:09.28ID:zCczxc5o
>>778
私利私欲を捨てさせることが目的のように見える
私的な目的を持たないことが目的みたいな
2021/11/17(水) 09:00:58.02ID:MZt3q0rg
>>783
英語を読めないの？
>>769には、手動メモリ管理の有利な点としてRAIIによる自動リソース管理を可能とすることが挙げられ、C++では手動のフレームワークの範囲内でメモリ解放を自動化するshared_ptrが使われている、と書かれている
つまりshared_ptrは手動メモリ管理の代表選手
2021/11/17(水) 09:09:38.98ID:C+w8kxrc
>>783の解釈で正しいよ
そもそも出典の記載もなく俺が書いたかもしれないwikipediaの記事にどれだけ意味があるのかは知らんが
2021/11/17(水) 09:27:03.70ID:MZt3q0rg
>>786
ウソはよくないな
>>769には引用されていないけど
「手動メモリ管理の有利な点とし
てRAIIを可能としC++にはshared_ptrがある」の直後に
「このアプローチはGC言語(＝自動メモリ管理)では使用できない」と明記されている
shared_ptrは手動メモリ管理であることが明確になった
2021/11/17(水) 09:28:38.23ID:fpCU2YNN
でもC++/CLIってGC言語だけどshared_ptr使えるじゃん
2021/11/17(水) 09:32:57.00ID:C+g/MvKJ
weak_ptrの存在もあれだよな
必要だったらコレ使ってなんとかしろよ？という
循環参照も自動で解放できるんならコレいらないしな
2021/11/17(水) 09:35:09.37ID:fpCU2YNN
定義定義ってうるさいよ
何を目的としてその定義があるのかという視点から考えないからこういうコーナーケースで無用な論争に発展する
2021/11/17(水) 10:04:21.19ID:/Jn+6Ag0
自演の荒らしだと思う
2021/11/17(水) 10:05:52.29ID:TggxfUz+
〇〇かGCか否かという議論に決着がつくと
プログラム書く上で何か役に立つんですかねえ
あるいは学術的な発展でもするんですかねえ
2021/11/17(水) 10:22:36.39ID:C+g/MvKJ
じゃあ次はお前らの大好きなNimの話でもする？
Efficient, expressive, elegant
どこがエレガントなのかどうぞ
2021/11/17(水) 10:29:14.01ID:sX0XtunN
>>785
それはshared_ptrの実装に手動メモリ管理の枠組みが使われているという話で
shared_ptrが提供する機能性が手動メモリ管理に分類されるとは言っていないと思うが
2021/11/17(水) 10:43:46.53ID:wlAtkNPK
auto変数はすべてGC(キリっ)
2021/11/17(水) 10:45:44.25ID:wlAtkNPK
allocaはGC(キリっ)
2021/11/17(水) 10:51:30.59ID:ZQ/D1zVP
Garbage Collectionを持つ言語
Garbage Collectorがある言語
Garbage Collectが行える言語
2021/11/17(水) 11:35:29.78ID:Vki78NxX
>>785 >>787
shared_ptrは「 further use to automate memory deallocation within an otherwise-manual framework」であって、shared_ptr自体がmanual frameworkだとは言っていないけど？

文章で言うなら、「put to further use to automate memory deallocation」だからmanual frameworkの外にある機能を追加する（=manual frameworkには無い機能）と読むのが自然。
2021/11/17(水) 11:45:13.07ID:vmbAdT3A
スレの半分はこいつでできています
http://hissi.org/read.php/tech/20211116/U2x6aVZFN1Y.html
2021/11/17(水) 11:50:46.89ID:MZt3q0rg
>>798
そこにもあるように
あくまでも手動メモリ管理の範囲内でのメモリ解放の自動化
とはっきり書かれている
しかも手動メモリ管理のアドバンテージの説明として書かれているわけだから
shared_ptrは手動メモリ管理であってしかもそのアドバンテージ
801デフォルトの名無しさん
垢版 |
2021/11/17(水) 11:57:20.20ID:YG2/9hEL
不毛とハゲの違いってなんだよ？
英文持ってきて貼り付けて一仕事終えるじゃなく、自分の言葉で説明しろよ！
アドバンテージ！
2021/11/17(水) 12:04:02.33ID:C+g/MvKJ
RAIIで解放タイミングを把握できるのはメリットだね
GC標準装備言語だとそうはいかないもん
C#だとusingとIDisposableを使ってまで同じようなことをしたがるけど
using (StreamReader r = new("foo.txt")) {/*処理*/}
2021/11/17(水) 12:13:29.09ID:iywzxd5E
>>781
>手動メモリ管理のよってRAIIを介したshared_ptr等の自動リソース管理を可能にしていると

おいおい・・・
無駄かもしれんが一応書いておく

まず大前提として1行目に
「In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage. (手動メモリ管理というのは使われなくなったオブジェクト(ガベージ)を識別してメモリを解放するのにプログラマーが手動命令を使用することを指す)」と書いてある
つまりはここで言う手動メモリ管理はどのオブジェクトを解放すべきかを判断するコードやメモリを解放するコード(freeやdelete)をプログラマーが直接書くことを意味してる

でもってRAIIの説明箇所にある「This can also be used with deterministic reference counting.(RAIIは決定的参照カウント方式と一緒に使うこともできます)」は”手動メモリ管理だけでなく参照カウント方式とも一緒に使える”と言ってるわけ

「In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework」(C++ではこの機能を、その他の点では手動のフレームワークにおいて、メモリの解放を自動化するのに活用している)
otherwise-manual frameworkと書いてることからわかるようににC++が活用してる内容は”自動”の範疇に含まれると記事の書いた人間は考えてる
2021/11/17(水) 12:14:43.77ID:iywzxd5E
>>798
かぶったな
でも真っ当な理解ができる人がいてよかった
2021/11/17(水) 12:18:06.70ID:iP5L/cQW
外部DLLに渡すヒープデータなんて普通にコントロールするのが当たり前、GC”非標準装備”言語だってそう
じゃなければDLLを起点にクラッシュする。おまえほんとはなにもしらねーんじゃねえの（笑）ｗ
C#だって当然そういう事を考えるだろう、アホ信者言語と同じことをしたいんじゃない
2021/11/17(水) 12:18:07.56ID:eNp19Ga9
>>802
だな
C++やRustなどは即座に解放のためデストラクタでファイルcloseやlock解放を自動化できてプログラマーは気にしなくて済むもんな
GC言語はこれをするのに各言語で苦労しているのと対照的
2021/11/17(水) 12:22:44.44ID:eNp19Ga9
>>803
それはかなりの曲解
自動化しているのは結果として起こる「メモリ解放」
その「メモリ管理」自体は手動の範囲内だとはっきり書かれている
2021/11/17(水) 12:26:39.90ID:mpgcjn44
一生懸命にC++を味方に引き込もうとする姿が哀れに思える。C++は全部プログラマが気にして細心の注意を
払い神のごとくコントロールする言語なのに、一緒にされたらC++プログラマーは嫌
2021/11/17(水) 12:39:06.76ID:C+g/MvKJ
RAIIでやりくりするほうがある種スッキリしてるし
それを欲する層は居なくはならないよ
2021/11/17(水) 12:50:33.28ID:Vki78NxX
>>803
追加解説サンキュー。
普通はそう考えるよなぁ。

自分で引用しているのにその内容を無視するのはなぁ。
それで騙せると相手を馬鹿にしているのか、本当にそうだと幻覚でも見ているのか……

>>807
まずははっきり書かれている部分を示してくれない？確認するから。
2021/11/17(水) 12:53:41.30ID:iywzxd5E
>>807
>その「メモリ管理」自体は手動の範囲内だとはっきり書かれている

どこに？
どこにshared_ptrの利用は手動メモリ管理の範囲内ですってはっきり書かれてるの？
shared_ptrに言及してるのはそのページでは↓ここしかないけど？
「This can also be used with deterministic reference counting. In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework, use of the shared_ptr template in the language's standard library to perform memory management is a common paradigm. shared_ptr is not suitable for all object usage patterns, however. 」
2021/11/17(水) 13:09:29.01ID:R0jdljey
>>806
goのdefer文のがよっぽど楽だと思うけどね。
デストラクタみたいにオブジェクトに紐づくのは不自然なことが多い。
2021/11/17(水) 13:20:45.45ID:bNLdqk4Y
そもそもWikipediaをソースに議論するのが間違っとる
2021/11/17(水) 13:58:13.62ID:nFfaA0w6
実用上はGCのタイミングとやり方をプログラマが制御できるかどうかだね
2021/11/17(水) 14:00:09.94ID:kLyb71mm
「RustはGCじゃない！」
「え？ARCでしょ？別にどうでも良いじゃん？」
「shared_ptrがうんたら、なんちゃらで、RustのArcの”A”は自動じゃない！Wikiによると（長すぎるので省略）」
「C++やRustはスッキリ！C#のIDisposableはRustの真似！」
「？？？」
「C++を仲間に引き入れたいだけだろｗ」
「だからWikiによると（長すぎるので省略）shared_ptrは手動なんだ！うぇぇん！バーカｗ」
2021/11/17(水) 14:15:10.37ID:wlAtkNPK
第三者目線で観ると一人で自演してるようにしか観えない
2021/11/17(水) 14:49:34.87ID:/Jn+6Ag0
だろ？
2021/11/17(水) 14:55:08.33ID:htHLdEY/
>>812
例えばどういうケースで不自然になるの？
2021/11/17(水) 15:14:14.44ID:0sKaSg3R
>>802は別にGC起因の問題じゃなくて単なるシンタックスの問題だろ
メモリの解放とその他のリソースの解放を、GC言語ではレイヤの異なる別の問題として扱っているだけだ
C++やRustではそのusingに相当する言語機構を用いてメモリ解放の面倒も見なければならないわけで、本質的には負担が増えている
最近のバージョンのC#では using var r = みたいな記法もできるようになって記述負荷の問題は解決したが、そういう問題じゃないんだろ？
2021/11/17(水) 16:14:57.91ID:wlAtkNPK
copy constructor と
move constructor だな
821デフォルトの名無しさん
垢版 |
2021/11/17(水) 18:32:09.16ID:iuNg9UQr
そもそshared_ptr自体使わない。
new/deleteも使わない。
RAII、所有権と唱えると設計がすっきりする。
2021/11/17(水) 18:46:34.87ID:leUGQUzv
>>821
単独所有者限定はRustですら諦めたデザインなのに。
823デフォルトの名無しさん
垢版 |
2021/11/17(水) 18:56:42.09ID:iuNg9UQr
>>822
HTML5仕様のパーサー、木コンテナ、ダブル配列ベースのTRIE木コンテナ、それら木へのイテレータ/アダプター、CSS Syntax Module Lv3仕様のパーサーなど書いた結論。
new/deleteすら要らない。
偉い人が言ってることは全部ほんとだった。
2021/11/17(水) 19:10:07.77ID:jveHssXi
ｗｗｗ
2021/11/17(水) 19:32:37.01ID:MZt3q0rg
>>811
ずばりそこに書かれてる

　This can also be used with deterministic reference counting.
　In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework, use of the shared_ptr ...
　C++においては、RAIIを決定論的参照カウント方式と共に使うことで、メモリ解放を自動化するのに利用している。その他の点では手動のフレームワークの範囲内で。

ようするに自動化はあくまでも『メモリ解放』だけであって
その他の点で(otherwise)は『手動のフレームワーク』すなわちこのwikipedia項目『手動メモリ管理』の範囲内(within)だと明記されている
shared_ptrが自動でメモリ解放するのは当たり前だけどもあくまでも手動メモリ管理の範囲内ということ
826デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:02:17.52ID:iuNg9UQr
vector、listなどSTLのコンテナは基本的なストレージとして設計されてるそうで、実際、その他のコンテナはこの上に実装できる。
tree、ダブル配列ベースのTRIE木などをこれらの上に実装して不都合は無かった。
速度的にもmap、unordered_mapなどと比較するレベルで、普通に使える。
827デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:07:40.05ID:iuNg9UQr
イテレータを使い分けることで、終了タグが現れる行きがかり順の走査と単純な木としての走査を行える二面性を持つHTML木も作ってみた。
単純な木として走査するならDOMのように見え、HTML文書として走査するなら（タグのバランスが取れていない）壊れたHTMLも扱える。
2021/11/17(水) 20:10:27.74ID:7Zsf8uTz
うん
829デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:11:35.74ID:iuNg9UQr
そういう作業をした結果、HTML5とは、インターネットエクスプローラーを倒すためにデザインされており、プログラミング的な合理性は全くないと理解した。
また、HTMLを簡単に扱えないようにするため、いろいろ詭弁を使いながら仕込みを行っている。
HTML5のおかげで、賢いベンチャーが現れてグーグルを倒すようなことを防げる。
830デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:21:18.87ID:iuNg9UQr
R！A！I！I！
これですべて解決。
RAII強し。
2021/11/17(水) 20:21:26.12ID:fpCU2YNN
>>825
メモリ解放を自動化しているならそれはGCでは？
逆にGCはそれ以外何の仕事をすると？
2021/11/17(水) 20:26:26.17ID:MZt3q0rg
>>831
例えばunque_ptrもメモリ解放を自動化していますがGCとは呼ばれませんよね
つまりメモリ解放の自動化とGCは別のことです
2021/11/17(水) 20:30:25.82ID:LATxpwY3
セガサターン言語！
2021/11/17(水) 20:34:46.44ID:C+g/MvKJ
RAIIで無駄なくやりくりするのがC++の思想なんだろうね
スマートポインタもRAIIがもたらすリソース解除実行の一例で
ヒープメモリをデストラクタでdeleteしてるだけだから
2021/11/17(水) 21:40:20.88ID:MiIYKiV6
>>831
>>832は（今までのやり取りにもある通り）悪意を持って情報を隠すから気をつけろ。

>>684以降、誰も異論を挟んでいないWikipediaの解説
ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、
『不要になった』領域を自動的に解放する機能である。
にある通り、『不要になった』かどうかを自動的に判断するのがポイント。

自動で判断しないc++のunique_ptrはGCの機能とは言わんが、（仕様に従う限り）自動で判断するshared_ptrはGCの機能と言える。
2021/11/17(水) 22:09:03.50ID:eNp19Ga9
>>835
またゴールポストを移動させたの？
その「自動的に判断」「自動に判断」などは今までこのスレに一度も出て来ておらず誰も主張してきていない初登場の言葉
そしてその意味の定義がなされていないから解釈次第になる
837デフォルトの名無しさん
垢版 |
2021/11/17(水) 22:12:01.05ID:SsdWlmrh
Rust 2021 Edition
2021/11/17(水) 22:12:58.72ID:45MpLEpa
だぜぇｗｗｗ
2021/11/17(水) 22:14:09.96ID:7Zsf8uTz
ちゃんと必要十分条件を考えてください
2021/11/17(水) 22:57:46.68ID:bNLdqk4Y
こいつらがプログラム作るの勘弁してほしいんだが
841デフォルトの名無しさん
垢版 |
2021/11/17(水) 23:08:50.98ID:iuNg9UQr
法律で禁止するべきと？
2021/11/17(水) 23:14:03.88ID:QI1gBPox
まだWikipediaとか不毛なことやってたのか
もうちょっとまともな文献を挙げてみると
リチャード・ジョーンズ「ガベージコレクション」
では参照カウント方式GCの具体例としてBoostのshared_ptrを取り上げて、トレーシングGCとの比較が行われている
著者はメモリ管理についての国際会議（ISMM）の創設者なので、少なくとも学会レベルではshared_ptrはGCの一形態として認識されていると考えていい
もちろん学会が世の中の全てではないから「俺の常識ではGCではない」と主張するのは自由だけど
2021/11/17(水) 23:16:21.20ID:Wt07eo3Q
激おこなの？
2021/11/17(水) 23:42:21.78ID:iywzxd5E
>>825
やっぱり何言っても無駄だったか

「自動だけどそれは手動の範囲内」ww
2021/11/17(水) 23:49:51.44ID:C+g/MvKJ
GCはGCまかせのタイミングでいつかきっとメモリを解放できる
RAIIはRAIIオブジェクト破棄のタイミングで※1リソース※2を解放できる

※1 shared_ptrの場合は参照カウンタを見て
※2 shared_ptrの場合はメモリを
846デフォルトの名無しさん
垢版 |
2021/11/17(水) 23:55:15.10ID:SsdWlmrh
shared_ptrがGCかそうでないかはどうでもいいからさ、
GCの動作有無をアプリ開発層のプログラマから制御できる次世代言語はどれよ？
2021/11/17(水) 23:56:56.28ID:/Jn+6Ag0
真実は>>660
それ以上でもそれ以下でもない
2021/11/18(木) 00:02:29.34ID:1J6GnuLp
【結論】紅しょうがは無料だけど良心の範囲内！
2021/11/18(木) 00:30:08.00ID:xv2SjNGH
>>846
D
2021/11/18(木) 07:15:04.87ID:5A0vzciY
99％のプログラマーはこんなアスペルガーの領域のことまで考えてプログラミングやってないと思う
2021/11/18(木) 08:11:30.53ID:Q5lW897P
>>836
ゴールポストは>>684から変えてないし、まともな異論も出てない。「手動メモリ管理」とかも>684を否定しているわけではないだろ。それとも>684はデタラメと主張するのかね？
嘘ばかりの歴史改竄主義者だな。

世間一般の認識は>>842みたいだから、>836の心の中のGCについては勝手にすれば？ 歴史改竄しないかぎりだけど。
2021/11/18(木) 08:57:24.74ID:5v/hszDl
キミはおそらく誰からも相手されとらんだけではｗ
2021/11/18(木) 09:07:54.56ID:Ip1KYC/r
お前らが大好きなWikipediaの文言だぞ

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

Reference counting
Main article: Reference counting

Reference counting garbage collection is where each object has a count of the number of references to it. Garbage is identified by having a reference count of zero. An object's reference count is incremented when a reference to it is created, and decremented when a reference is destroyed. When the count reaches zero, the object's memory is reclaimed.

As with manual memory management, and unlike tracing garbage collection, reference counting guarantees that objects are destroyed as soon as their last reference is destroyed, and usually only accesses memory which is either in CPU caches, in objects to be freed, or directly pointed to by those, and thus tends to not have significant negative side effects on CPU cache and virtual memory operation.

There are a number of disadvantages to reference counting; this can generally be solved or mitigated by more sophisticated algorithms

https://ja.wikipedia.org/wiki/%E3%82%AC%E3%83%99%E3%83%BC%E3%82%B8%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

スマートポインタ

なお、C言語で参照カウント方式のガベージコレクションを利用する場合、通常煩雑なコーディングを必要とするが、C++では以下のようなRAIIを活用したスマートポインタを利用することで緩和できる。

・Boost C++ライブラリのboost::shared_ptrおよびboost::shared_array。
・参照カウントの増減処理をカスタマイズできるboost::intrusive_ptrもある。
・C++11以降のstd::shared_ptr
・Active Template LibraryのATL::CComPtr - COMオブジェクトのスマートポインタ。
・Windows Runtime LibraryのMicrosoft::WRL::ComPtr - Windowsランタイムオブジェクトのスマートポインタ。COMオブジェクトにも使用可能。
854デフォルトの名無しさん
垢版 |
2021/11/18(木) 11:21:14.46ID:/He/baLS
>>823
否定はしないが賛成もしない
new を出来るだけ避ける様に心がければ delete の心配が無くなるのは当たり前
2021/11/18(木) 11:30:02.24ID:/He/baLS
>>846
node.js
2021/11/18(木) 13:20:13.82ID:5Kqa+JGe
>>823
newを使わない要らないとはヒープを一切使わないという意味ですか？
それともC言語のように自分でmalloc等を用いてヒープメモリ管理を行うべきという意味ですか？
前者はそれら挙げている物のプログラミングが不可能だから後者の何十年も前に戻っただけですか？
2021/11/18(木) 13:51:24.01ID:+0r8+Axf
>>856
C++の標準ライブラリにあるstd::string、コンテナクラス、unique_ptr、shared_ptrなどを使っていればnewを書かずにヒープメモリを使うことができるし、shared_ptr以外はスコープを抜けたときに自動的にデストラクタを呼んでヒープを解放してくれる。
ちゃんとC++を使えばほとんどの場合手動でメモリ解放せずに済むよ。
2021/11/18(木) 14:53:32.65ID:/He/baLS
>>856
それはRAIIを判ってない発言だからたぶん恥ずかしい
2021/11/18(木) 14:56:26.80ID:/He/baLS
>>857
コンテナの中身がポインタだったら？
2021/11/18(木) 14:57:53.21ID:+tJnStuG
本人も認めてるけどRAIIってネーミングセンスがないよな
2021/11/18(木) 15:10:40.66ID:+tJnStuG
>>856
この辺見るといいと思う
https://www.youtube.com/watch?v=86xWVb4XIyE&;t=1790s

shared_ptrがGCの一種って話も出てくる
2021/11/18(木) 15:13:07.47ID:5Kqa+JGe
>>857
しかし元の方は>>821でdeleteを使わないだけでなくshared_ptrも使わないとおっしゃっているのです
つまり解放をどうするのか問題が残ります
あとコンテナ自体の解放に加えて要素が値だけで構成されずポインタを含む場合はその先の解放も必要ですよね
2021/11/18(木) 16:00:24.60ID:5Kqa+JGe
>>858
ある程度の構造を持ったデータを扱う場合
RAIIではそのクラスのデストラクタでdeleteが発生しますよね？
>>823はdeleteも要らないと書いていますがそこはどうするのでしょう？
2021/11/18(木) 16:21:52.26ID:BzFs1LlE
new/deleteを明記しないってだけやろ
2021/11/18(木) 16:36:40.14ID:f69aBKlz
golangなんかだとbenchでB/opやallocs/opが取れるけど、他の言語はあまりメモリー量は重要視してないのかな？
最終的にはエネルギー毎のjoule/opとか出してほしいけど、IntelとAMDそしてARMで全然違うのはCOP21とかは
何も考えてない偽善だろう
2021/11/18(木) 17:16:59.79ID:x5F/kwMZ
>>862
所有権について言及してるしunique_ptrを使うのでしょう
867デフォルトの名無しさん
垢版 |
2021/11/18(木) 18:07:16.31ID:dthIgn7Y
流れを踏まえると
C#はせっかくGCがあるのに
自分でいちいち手動のDisposeを描かされる

残念な言語(キリっ

と言わざるを得ない
2021/11/18(木) 18:10:14.42ID:z3VijVy2
GoやJavaなんかだとGCがあるからやばい、って思えるほどシビアなプロジェクトの開発をしてみたいもんだ
869デフォルトの名無しさん
垢版 |
2021/11/18(木) 18:13:29.70ID:P63H+fUW
>>863-864
デストラクタ内のdeleteは勘定に入れなくて良いルールなんだろう
2021/11/18(木) 18:20:18.80ID:MFoti6qx
>>867
というより可能な限りGCを動かさないように
値型を多用してコレクションも
System.Collectionsじゃなくて
System.Collections.Genericのほうを使うとかして
ヒープ側を使わないようにする悲しい頑張りが必要
2021/11/18(木) 18:21:21.59ID:Hn1JS7XJ
まあ、ネイティブコンパイラが必須なケースが少ないからこそ
JavaScriptインタプリタのようなものをC++やRustで書いて使ってるんだよな
2021/11/18(木) 18:27:54.82ID:+6yu0rNA
>>870
C#ならガベージの生成を避けるようなケースでもC++なら気にせずヒープ使いまくれるってことか？
そうでないならそれはGCの問題ではないことになるぞ
2021/11/18(木) 18:28:22.88ID:7LzjmfPa
まだgcの定義の話してんのかよ
文脈依存用語を絶対的な意味で決めつけようとする意味あんの？
2021/11/18(木) 18:37:38.93ID:EV0O2NnK
Railsの高速化に貢献する新たなJITコンパイラを搭載したRuby 3.1プレビュー1が公開
2021/11/18(木) 18:44:25.05ID:+6yu0rNA
>>874
すまないがもはや汎用言語でない言語はスレ違い
2021/11/18(木) 18:47:30.80ID:BzFs1LlE
>>869
newしないんだったらdeleteだって書く必要ないでしょデストラクタであっても
2021/11/18(木) 19:27:50.79ID:z3VijVy2
「汎用言語」と呼ばれるにはミドルウェアを書くのにも適してる言語じゃないといけないの？
2021/11/18(木) 19:36:07.29ID:x5F/kwMZ
Rubyより採用実績の少ない言語は皆専用言語
2021/11/18(木) 19:51:50.15ID:rsuv1+NH
このスレといいフレームワーク系のスレといい、お気に入り以外を攻撃してワンワン噛みつく奴ばっかや…
ニュースリリースぐらい大目に見たれよ？Wikipediaを何行も張り付けるウンコの１０倍は有用だぜ？
2021/11/18(木) 20:17:22.46ID:5Kqa+JGe
>>864
なるほど
クラス宣言側でdeleteを使っていても関数側でdeleteを明記しなければdeleteを使っていないことになるのですね

>>821
> deleteも使わない。

>>823
> deleteすら要らない。

ここまではっきりと書かれているので当然クラス宣言の中でもdeleteを使わない意味だと受け取っていました

ところでクラス宣言のデストラクタでdeleteを使う形はスマートポインタと完全に同じ形になっていますが
この自動的にメモリを解放する手法はGCに該当するのでしょうか？
2021/11/18(木) 20:28:31.75ID:Hn1JS7XJ
いちいち質問して答えを待ってると判断が遅いんだよね
自分のお気に入りの答えを自分で判断する方が圧倒的に早い
882デフォルトの名無しさん
垢版 |
2021/11/18(木) 21:25:37.77ID:PdOXvPCx
C++はJavaと違うって事では。
2021/11/18(木) 21:51:51.02ID:tNnQbC1E
早漏DTの意見でした
2021/11/18(木) 22:44:57.81ID:2INYRpvr
組み込みのmruby は、apache などのmiddleware も書ける。
C の文字列の代わりに、mruby の文字列を使うと簡単・安全

人工衛星、イザナギ・イザナミなどに使っている

mrubyの本も出た。
micro python, Lua の代わりに使う
2021/11/18(木) 22:59:55.28ID:QovEQeBY
>>880
自動的に開放しているからGCの一種
2021/11/19(金) 00:42:48.75ID:mxTjN9mz
>>880
クラス宣言ってshared_ptrの実装のこと言ってる？
2021/11/19(金) 05:13:09.95ID:DX593LKr
mrubyとか名前ダサくね？
信者になればかっこよく見えるの？
名前重要とかどこいった
2021/11/19(金) 10:31:20.07ID:eyeX0xyM
ruby.js
889デフォルトの名無しさん
垢版 |
2021/11/19(金) 12:27:45.87ID:fGKSbVlD
そんなこと言ってるとrustに別実装の処理系が出来た時にディスられるぞ
rustだからstainlessとか
2021/11/19(金) 12:47:40.77ID:mxTjN9mz
すでに別実装はあったような
2021/11/19(金) 13:41:02.55ID:rEwMjqRY
>>889
なんでもかんでもxxx.rsって付くのはダサいけど、xxx.jsと同じかな
2021/11/19(金) 13:55:37.85ID:XZPDRrte
GCある言語でもインスタンスの生成や参照切れで解放されることくらいは
知ってる必要があるんだが、それもまともにわかってなさげなやつで溢れてる。
893デフォルトの名無しさん
垢版 |
2021/11/19(金) 13:56:15.69ID:eyeX0xyM
ださい拡張子
.cs
.ts
.ps
.gs
894デフォルトの名無しさん
垢版 |
2021/11/19(金) 14:56:18.17ID:nTNvNEE2
>>892
誰一人まったく解放されないなんて言ってる奴いないと思うが、どこの世界線から来た人？
895デフォルトの名無しさん
垢版 |
2021/11/19(金) 18:18:36.72ID:cPtoFLsh
>>886

class foo
{
　　~foo()=delete; // このdeleteのことを言ってる。
};
2021/11/19(金) 19:21:02.67ID:p3l3yC+x
>>895
アスペか？
897デフォルトの名無しさん
垢版 |
2021/11/19(金) 19:55:35.05ID:cPtoFLsh
>>896
ID末尾をxにしてるのは、C++とC#の両方を表現してるのかい？
898デフォルトの名無しさん
垢版 |
2021/11/19(金) 19:57:08.72ID:cPtoFLsh
宣言のdeleteって言うから。
2021/11/19(金) 20:09:20.65ID:M2ROgxHD
>>898
流石にnew/deleteとdelete宣言は別物だろうなぁ。
同じ単語を使っているのはc++のケチ臭い用語の流用の結果だし。
900デフォルトの名無しさん
垢版 |
2021/11/19(金) 20:52:12.15ID:cPtoFLsh
デストラクタのdelete自体も嵐を呼ぶ話題だけど。
2021/11/19(金) 21:04:37.53ID:eorWY7YE
>>895
それならRAIIで本体をGCさせる時に連動GCさせる時の常套手段
902デフォルトの名無しさん
垢版 |
2021/11/19(金) 21:11:17.06ID:cPtoFLsh
たぶんJavaの人じゃないかと思うんだよね。
2021/11/19(金) 22:08:12.78ID:CstSAS10
>>901
本体もGCと呼ぶかは議論が分かれそうだが
付属部分を連動GCすることだけを目的に本体が実体を無くしたものがunique_ptrだよな
904デフォルトの名無しさん
垢版 |
2021/11/20(土) 00:19:22.26ID:OQv16NeR
自動変数もGCなのか？
2021/11/20(土) 02:24:49.30ID:V+twZ/1f
>>584
電気メーカーが糊口をしのぐための税金バラマキ国プロ
昔も今も変わらない
2021/11/20(土) 08:44:52.28ID:V7jlhcsx
1. 昔も今もどっちも変わらない
2. GCもスマポもどっちも変わらない
3. 1も2も3もどれでも変わらない
907デフォルトの名無しさん
垢版 |
2021/11/20(土) 11:42:49.09ID:NkWaDqk7
>>904
約一名にとってはそうみたい
2021/11/20(土) 11:51:59.21ID:/G7VwRdk
>>904
自動変数は参照あっても解放されるからGCにはならんね。
2021/11/20(土) 12:28:48.64ID:/C1S+OCl
君らはいつになったら回収されるん？
910デフォルトの名無しさん
垢版 |
2021/11/20(土) 16:24:03.02ID:lK9Ghq6L
Rustの悪口言ったやつ許さんから
2021/11/20(土) 16:27:17.15ID:pWBsNJLr
Rustの母ちゃんでべそ～
2021/11/20(土) 16:42:56.01ID:H5f9Qsz8
RustがすごいんじゃなくてGCがクソ
913デフォルトの名無しさん
垢版 |
2021/11/20(土) 18:07:02.96ID:OQv16NeR
バグを無くすにはGCじゃなくテストですよ。
2021/11/21(日) 10:14:13.30ID:UyY2TlzJ
ソースを読まなくてもできるテストは
不正アクセスと同じではないが似ている
2021/11/22(月) 20:18:26.53ID:pPz4fu4C
抽象バカはテストが書けないので困る。
2021/11/25(木) 08:38:48.33ID:KcP0JmbS
rustは少なくともCである程度のプログラムを書いてハマった経験がないと
この機能何のためにあるの？ってのがわからない
2021/11/25(木) 10:28:07.08ID:dqP+a0eJ
Rustを最近学んでるだけど、すぐに学習曲線やばい言語だということを納得した
おれはC++のスマートポインタらへん知ってるから、かなりマシなほうだと思うけど、
たしかにC/C++やってない人にはそうとうにキツそうだね

やってない人にオススメできる気がしない
2021/11/25(木) 10:35:35.35ID:6PNOZvLH
>>917
それは逆
Rustに苦労している人たちはC++経験者かつ頭が固くてC++から離れて頭をゼロにして学習する能力がない人たちだと言われている
2021/11/25(木) 10:56:21.20ID:lTzmbhqT
>>918
そんな話どこで言われてるの？
2021/11/25(木) 10:58:35.45ID:iyas0vJe
まぁC++一筋十数年って人だと大変かもね
C++に加えてScalaとかHaskellあたりを履修済みだとだいぶ楽
2021/11/25(木) 11:45:21.45ID:lTzmbhqT
rustもC++もScalaもHaskellも分かるが、まるでそうは思わないｗ
2021/11/25(木) 11:45:21.46ID:lTzmbhqT
rustもC++もScalaもHaskellも分かるが、まるでそうは思わないｗ
2021/11/25(木) 12:14:40.21ID:OYLxCDo4
C++11以降の流れをある程度追えているなら問題なかろうよ
2021/11/25(木) 12:38:43.29ID:lTzmbhqT
03で止まってる人なら辛いかもね
2021/11/25(木) 14:54:39.16ID://sjBQgD
最新のC++の方向性見るとこれなら
最初からRustやればとは思わない？
2021/11/25(木) 15:14:28.01ID:lTzmbhqT
C++はCみたいな書き方も出来るが、rustは最初からrustでないといけないから難しいと思う
2021/11/25(木) 15:50:19.56ID:662tr9PH
今はc/c++の知識を階段として学んでいる人多いだろうけど、今後はrustしかわかりませんみたいなrustネイティブも出てくるのかな？
これってアセンブリ→cのときにも言われてた？
cを理解するにはアセンブリがわかってないと無理みたいな
2021/11/25(木) 16:03:54.47ID:dqP+a0eJ
よくしらんけど、学習曲線を緩和させるような取り組みもいちおう検討されてるんでしょ？
2021/11/25(木) 16:04:26.05ID:ypEo7i9g
>>926
Cみたいな書き方できるのをメリットと見るかデメリットと見るか？
2021/11/25(木) 16:59:45.85ID:lTzmbhqT
CはBASICほど遅くなくアセンブラ(機械語)が必要ない、当時俺にとっては奇跡の言語だった
C/C++/VB→Javaのときは実際にJavaしか分かりません、が大量に発生した
2021/11/25(木) 17:35:06.78ID:88pS2ZzI
今後のネイティブ系プログラミングは基礎入門C言語→Rustになるでしょう
C++は今となっては中途半端でありやる価値を失った
2021/11/25(木) 17:51:06.67ID:dqP+a0eJ
言語仕様でいえばC++よりRustのほうがいいと思うけど、C++で作られた過去の資産が巨大すぎて、そう簡単に価値がないとはならなそうかなあ
まあ10年後とかにはCOBOLみたいに、悲しい負の遺産扱いされてるかな
933デフォルトの名無しさん
垢版 |
2021/11/25(木) 18:17:02.30ID:YKvzJ4Sm
まさか5年前にはc++がcobolのような負の遺産という立ち位置になっていくんだろうなっていうのが目に見えるようになるなんて思いもしなかったわ
2021/11/25(木) 18:31:54.46ID:htMyv0Y1
c++は新しい部分もあるけど古いダメな書き方もできるからな
新しい部分は古い部分に触れた人には喜べるけどだったらc#やjava使ったらと思う
rustはエグイなと思うので書かない

c++は新しい書き方だけを強制できるような仕組みが必要なんじゃないかな
自由度が高いことこそが最大の利点だ見たいな考えは古い
2021/11/25(木) 18:34:36.25ID:htMyv0Y1
>>933
大体15年前はすでにC++は負の遺産だったよ
クールだった時代はかなり短い

新しい言語が形を成してた2000年前半にはもう粗大ごみ扱い
2021/11/25(木) 19:23:28.39ID:l4YrYzBR
そのうちc++のオブジェクトファイルとリンクできるけど取り扱いの難しい機能を禁止したSmartC++が出てくるんじゃない？

生ポインタ禁止(スマートポインタ強制)するだけでもいい感じになると思うけどなぁ。
2021/11/25(木) 19:26:08.23ID:sK32tKJd
EC++ぶっつぶしたC++標準委員会には無理
2021/11/25(木) 19:34:59.70ID:6PNOZvLH
>>936
今となっては全てが自動的にスマートポインタ扱いとなっているRustを使えばよい話
しかもunique_ptrはコストゼロになっていて効率もいい
2021/11/25(木) 20:09:06.46ID:SwFLZgNz
馬鹿なRusterたちがこんなスレでわっしょいわっしょいｗ
一口にC/C++と言っても、当面はOSのkernelなんかは10年以上はC99だろうし、組み込みもCでしょう。
C++は一時は止まってたがC++20とか、確かに古いダメな書き方が出来るが、分岐予測CPU用のlikelyと
unlikelyなんかRustにも”降りてきた機能”。こういう表現が言えるのはC++が実験的/先進的であるから
Rustのような言語は破綻させないために先進的な（あるいは実験的な）機能は入れにくい。
ところがC++は違う、破綻しようが滅茶苦茶だろうが関係ない。使いたい人がその機能を使う
負の遺産だとも、クールではないとも異議は唱えないが、根本的なところが違う
940デフォルトの名無しさん
垢版 |
2021/11/25(木) 20:11:54.48ID:mXEi3hQs
あわしろ氏もC++はオワコンと言ってる。
2021/11/25(木) 20:26:41.70ID:dqP+a0eJ
せやな
C++という言語自体というより、C++で作られた資産が負の遺産だと思っているよ
2021/11/25(木) 20:40:18.41ID:pEcDGUra
まるで第二Rustスレだな
2021/11/25(木) 20:51:59.29ID:88pS2ZzI
スレタイの諸言語は限定した環境においてはRustに対して優位性があるけど
C++は過去しか優位性がないので仕方ないのでは
2021/11/25(木) 21:18:43.03ID:lTzmbhqT
rustは難しいからなぁ・・・
945デフォルトの名無しさん
垢版 |
2021/11/25(木) 21:22:32.76ID:YKvzJ4Sm
誰もCが悪いなんて言ってなくね
C++だったらRustの方が無難と言ってるだけで
2021/11/25(木) 21:27:45.38ID:I+op7MmV
Rustになんか優位性ない。スレタイの諸言語に対してもそう、Swiftは参照カウントでボトルネックになる
ところを自前で管理可能だし、Nimは同じ参照カウントに切り替え可能だし、Golangは他にない超高速な
軽量スレッドを有している。 KotlinとTypeScript は知らんけど
2021/11/25(木) 21:37:57.24ID:lTzmbhqT
C++は難しいを通り越してユーザーに厳しい？というかピーキー？というかマニアック？な言語だと思う
好きな奴だけ使う言語
948デフォルトの名無しさん
垢版 |
2021/11/25(木) 21:41:06.37ID:QrEUJ+3X
>>934
>c++は新しい書き方だけを強制できるような仕組みが必要

ほんそれ
2021/11/25(木) 21:44:35.39ID:/vPuyV+m
新しい書き方の強制はclang-tidyなどのlintである程度できるのでは
今時マージ前にCIでlint通すくらいはやっているでしょう
2021/11/25(木) 21:54:04.18ID:6PNOZvLH
>>946
あまりに無知
参照カウントの話にしてもRustのRcは単なる構造体によるライブラリに過ぎず必要なら自前で同じ物も似た物も違う物も作れて自由自在
そして必要ならガベージコレクションするRustのモジュールも多数存在している
つまりその分野ではRustは最強

> Golangは他にない超高速な軽量スレッドを有している。

これもRustのタスクの方が軽量かつ高速
そしてRustではそのスケジューリングも含めて自由自在に出来る
2021/11/25(木) 21:58:25.51ID:lTzmbhqT
C++の新しい書き方だけを強制とか言ってるアホは何なの？ｗ
何が新しくて何が古いのか何を強制したいのかできるのか知らんけど、使いたくなければ使わなければいいだけ
2021/11/25(木) 22:05:56.88ID:662tr9PH
>>951
そりゃ一人で作ってりゃ好きにやればいいけど、仕事でやるなら複数人でやることだってあるでしょ。　コーディングルールだぁって縛ったって漏れる可能性があるなら、古い機能(使いたくない機能)を使えなくするってのはいい手だと思うけどなぁ
2021/11/25(木) 22:08:20.71ID:QrEUJ+3X
>>941
使用者が
2021/11/25(木) 23:31:57.01ID:lTzmbhqT
>>952
C++が使える奴だけで作れなければやめればいいだけｗ
どんな言語でも使えるやつだけで作ればある程度適切な使い方になる

そうでなければ原則goみたいな言語で作ればいい
都合のいい制約を言語レベルで作りたいなら自分で言語を作れ
2021/11/26(金) 00:49:44.30ID:QMqJW7g5
>>950
こういう外部ライブラリを持ち出して顔真っ赤になるやつがいるから、大嫌いRuster。なにが無知やお前が無知や
一生わっしょいわっしょいしとれ
2021/11/26(金) 01:01:56.78ID:Ye0bskEh
>>954
使えるやつだけで作れる状況にできれば理想だけど規模が大きかったりするとそうも言ってられない
GitHubで公開してpullreq受け付けるようなプロジェクトの場合はそもそも人を限定できないわけで
よろしくないコードを機械的にチェックできる仕組みはあった方が良い

ただそれを言語仕様でやれというのはおかしな話というのは同意
linterなりコンパイラなり使えばよい
2021/11/26(金) 01:20:16.56ID:5+U4u14D
>>955
> こういう外部ライブラリを持ち出して

さすがにそんなこと言ってるようでは無知と言われてもしょうがないと思いますよ
Rust言語自体はコンパクトに作られているので何かする時は外部ライブラリを使います
例えばその話のスケジューリングランタイムにしてもRust自体は持っていませんから外部ライブラリを使うのは当たり前です
もっとわかりやすい例を出すとC言語ではstdlibにある乱数ですらRustのstdライブラリにはありませんから外部ライブラリを使います
2021/11/26(金) 02:55:58.38ID:SID+Dg53
>>939
ラスターじゃなくてカストディアンとか言うんじゃなかったっけ？
2021/11/26(金) 03:08:12.78ID:xSrpn+m5
>>939
＞ところがC++は違う、破綻しようが滅茶苦茶だろうが関係ない。使いたい人がその機能を使う

なるほど、かなり納得させられました、「標準化の行く末は緩慢な死」だと考えているんですね、押井攻殻だったっけ
2021/11/26(金) 08:17:35.81ID:iKOSBZIS
Rustは今までの悪習度合いが高い程苦痛を感じる言語なんだよ。

何で、こんな書き方させんだ？
何で、この構造が作りにくいんだ？
何で、簡単だったアレが、こんなに手間かかるんだ？

一度素直に受け入れれば、今までどんだけウンコードを書いてきたかが分かる。
2021/11/26(金) 08:34:53.72ID:GoGODfBQ
>>960
なら、「なぜ」の説明を強化することがRustの普及に不可欠ということだろ。
他人のせいにする暇なんてあるんですかねえ。
2021/11/26(金) 08:41:46.89ID:XtGzaRsE
普通に説明はあるだろ。それでもわからない人にまで普及させる義務なんてないしな。
2021/11/26(金) 10:06:14.10ID:5+U4u14D
>>960
むしろRustは非常に書きやすくて筋の良い言語と感じる
実際にプログラマー利用調査でもRustが愛され度No.1がこれで何年連続だっけ
プログラミング言語の中で一番好評であると調査データが出ている現実がある
2021/11/26(金) 10:27:30.05ID:rkWLGs8X
>>963
そういう主観でない話には根拠が必要
2021/11/26(金) 10:47:51.69ID:5+U4u14D
「Rust」、5年連続で開発者から愛されている言語第1位に
https://news.mynavi.jp/article/20200601-1045348/
https://news.mynavi.jp/article/20200601-1045348/images/001.jpg
2021/11/26(金) 11:09:43.97ID:STLLuOh7
最近Kotlinを少し書いたけどあれダメだな
Android以外に普及しない理由がよくわかった
2021/11/26(金) 11:27:37.91ID:9vzq3NLg
>>963
>>960みたいなアホなコメントが出てくるのに、どこが書きやすいの？
2021/11/26(金) 12:33:42.54ID:rkWLGs8X
欲しかった言語がそこにある感だろうね
そう感じる輩には刺さる
2021/11/26(金) 14:28:27.23ID:w9v4Cei8
c++で挫折した奴だろ。
どうでもええわ。
2021/11/26(金) 16:12:16.13ID:pv19rM7a
11月TIOBEプログラミング言語人気ランキング、PHPの下落続く
https://news.mynavi.jp/article/20211109-2181586/

どっかの分けわからんサイトのLOVEデータ引っ張ってきて、ごり押しで「書きやすい」なんて言うから
バカは貶される。あえて言うなら業務や趣味ｗで使用してなくて初心者が「これから覚えたい」ぐらいの
指標なのに「非常に書きやすくて筋の良い言語」なんて気持ち悪い公開オナニーを始める
こういうやつはマジで迷惑だからRustに近寄らないでほしい
2021/11/26(金) 16:15:26.83ID:Ax1NjXBR
Stack Overflowが分けわからんサイトw
2021/11/26(金) 16:19:53.66ID:ZG1tAy2R
Stack overflowは初心者質問サイトみたいなもの、そもそも「非常に書きやすくて筋の良い言語」の
根拠がまったく示せていない。公開オナニーのうんこ名無しの張り付いてるスレ
2021/11/26(金) 17:08:45.19ID:Ye0bskEh
その話に異論はないんたけどなぜTIOBEの記事貼ったのか
2021/11/26(金) 17:55:40.26ID:2onFAjF8
え、Stack Overflowなんて聞いたことねーよ
そんなわけわからんサイトなぜ貼ったしｗｗｗ
2021/11/26(金) 18:13:51.40ID:2NJWIteX
次のスレタイはどの言語が選ばれるか
976デフォルトの名無しさん
垢版 |
2021/11/26(金) 18:15:17.74ID:E7I1X7f8
もう次スレ立てるな
2021/11/26(金) 18:18:13.32ID:ON4GO5uK
https://i.imgur.com/7ik4K6Y.png
ASP.NET Core
2021/11/26(金) 18:53:05.45ID:Hq7eoo6P
>>968
https://www.youtube.com/watch?v=AdZD42q-XDA
https://www.youtube.com/watch?v=ia8GncoXA1s
https://www.youtube.com/watch?v=heif61jIlYg
2021/11/26(金) 19:41:03.78ID:rkWLGs8X
確かに荒らされてるだけだしな埋めて終わりにしよう
2021/11/26(金) 19:49:06.65ID:o6j9/HV6
rustのシャドーイングのメリットが今一つ分からんな
新しい名前を考える必要がない
というけどシャドーイング前の状態に戻せないと
メリットがないような気がするが
2021/11/26(金) 20:36:21.93ID:3UDOk5VY
もう「非常に書きやすくて筋の良次世代言語Rust23」だけでええやろ、本スレで知識の披露も質問回答も
できない攻撃性の高いクズの植民地みたいなもん、他の言語の話すると荒らしだす
2021/11/26(金) 20:49:39.48ID:rkWLGs8X
nimに続いてrustまで嫌いになりそうで嫌だし終わろう
2021/11/26(金) 20:58:37.40ID:Ye0bskEh
>>980
元に戻す場合はシャドーイングすべきではないと思う
初期化の過程で値をBoxやMutexに包む場合や、
逆にBufReaderから中身のReaderを取り出す場合など、
所有権の移動を伴うときにシャドーイングされることが多い気がする

例えば
let x = ...;
let x = Box::new(x);
といったコードがあるときに元々のxはムーブされて使えなくなっているから
x_boxed みたいな別名をつけるのではなく x という名前を再利用することが好まれている気がする
2021/11/26(金) 21:00:50.30ID:fVkS1Mpr
>>8 にランキングがあるけど、そこに入ってない良い言語あった？
2021/11/26(金) 21:31:21.70ID:3UDOk5VY
Pony言語とかアクターベースでErlangが元でORCAガーベージコレクションとか、box/ref/tag/val/isoとか
2021/11/26(金) 23:53:19.85ID:MbvsChzk
>>983
Resultエラー時は上へ投げればいいだけの時に?で外すのが最小例かな
for line in buf_reader.lines() {
　let line = line?;
　...
}
2021/11/28(日) 08:20:36.12ID:EZoi2zbw
Rust植民地
2021/11/28(日) 09:04:05.71ID:vGdYFLV6
Rust文法が好きになれない
なにfnって
2021/11/28(日) 09:48:09.06ID:D9WzSDH3
rustはアスペ専用
990デフォルトの名無しさん
垢版 |
2021/11/28(日) 10:30:37.63ID:9xwjyQVv
>>988
単語を省略しない方が良いのか？省略していない言語は少ないと思うが。
2021/11/28(日) 11:10:07.28ID:gZqbEyz/
fn func function 明示でなく文脈で判定

どれがいいのだろうか？
2021/11/28(日) 11:47:01.16ID:y5HuhJRG
自明なら短い方が良い、名前大切を勘違いした輩がスコープが数行しかないのにダラダラ長いAuto変数名書いてたの思い出すわ
Dryを勘違いした輩が、共有しちゃ駄目な処理も全部入れたUtil定義してたり
Javaと名が付く系統から派生した輩はマジで碌なのが居ない
2021/11/28(日) 11:53:32.46ID:w5BI4f4u
fnは短すぎて俺もわかりにくいと思う
変数名は文化だと思ってるので言語によって変えてる
994デフォルトの名無しさん
垢版 |
2021/11/28(日) 12:17:43.95ID:O4oXyxzb
ML系のようにfunならまだいい
2021/11/28(日) 12:39:28.24ID:qezuw3R9
Rustはfnよりもasが変数名として使えないのが困る
2021/11/28(日) 12:42:37.21ID:gZqbEyz/
asなんて変数どこで使うの？
2021/11/28(日) 13:09:39.78ID:UxDkzTV7
>>995
どう困る？
2021/11/28(日) 13:11:08.58ID:w5BI4f4u
おっと天下のpythonの悪口はそこまでだ
>>> as=None
File "<stdin>", line 1
as=None
^
SyntaxError: invalid syntax
>>>
2021/11/28(日) 13:11:50.45ID:qezuw3R9
xsとかysみたいなノリでasって名前をつけたくなったとき・・・
困るはちょっと言いすぎましたかね
1000デフォルトの名無しさん
垢版 |
2021/11/28(日) 13:37:26.38ID:O4oXyxzb
関数型の悩みやな
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 98日 4時間 38分 23秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況