X
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
レス数が1000を超えています。これ以上書き込みはできません。
0004デフォルトの名無しさん
垢版 |
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 は我々に教えてくれます
0008デフォルトの名無しさん
垢版 |
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～）
0010デフォルトの名無しさん
垢版 |
2021/08/22(日) 12:09:40.80ID:TsBps+dy
>>9
このスレのスレタイに入ってる言語はスレを立てる人が次世代だと思う言語を自由に入れていい
このランキングはスレタイに入った言語を集計したもの
○○回は入った回数、Part○～は初出のスレ番号
0011デフォルトの名無しさん
垢版 |
2021/08/22(日) 12:13:56.42ID:0Cz6ueFz
>>970

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

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

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

fn <- 短い！

proc <- 長い！

これはメリットですよ。タイプが2回ずつ減るのは素敵なことです。
しっかしこれだけ馬鹿げた冗長さを押し付けてくる言語のくせして、
何故ここだけすっきりしているのやらさっぱり意味がわからないです。
あ、結局ディスってもうた・・・。
0014デフォルトの名無しさん
垢版 |
2021/08/22(日) 12:43:28.59ID:9KEf5rUH
>>13
まともなプログラマーはタイプ数を気にすることはない
それよりも目的毎の機能性質で使い分ける
functionと長い言語もあればCやshのように0文字の言語もあるがタイプ数で何かを決めることはない
0015デフォルトの名無しさん
垢版 |
2021/08/22(日) 13:54:26.77ID:cx6/dnxW
Cで充分
0016デフォルトの名無しさん
垢版 |
2021/08/22(日) 14:45:49.07ID:1RKLPni9
func を fn とするだけで開発効率が上がると思ってとかどうしようもない馬鹿だろ。
0017デフォルトの名無しさん
垢版 |
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を組み込みに使っている人もいる。
0018デフォルトの名無しさん
垢版 |
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
0019デフォルトの名無しさん
垢版 |
2021/08/22(日) 16:20:01.00ID:5RAXclM6
結論
NimをGC無しにすることは不可能
つまりC/C++/Rustの代わりに用いることはできない
0020デフォルトの名無しさん
垢版 |
2021/08/22(日) 17:01:59.91ID:emx92kjF
Cはスタックを無しにすることは不可能
つまりアセンブラの代わりに用いることはできない
0021デフォルトの名無しさん
垢版 |
2021/08/22(日) 17:11:25.30ID:BUYgKjYJ
>>17
嘘つき
参照カウンタ方式はコストが高いので、
Rustでは必要最小限の部分でのみ、プログラマーが明示的にRc型(Reference counter型)を指定した時だけ使われます。
Rustでは通常時は参照カウンタなんて使われません。もっと高速に動作します。
0022デフォルトの名無しさん
垢版 |
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に変更されました。
0023デフォルトの名無しさん
垢版 |
2021/08/22(日) 17:38:20.64ID:9u04hent
Nim ARCは全て参照カウンタ方式になってしまうからパフォーマンスに影響が出て不利だね
0024デフォルトの名無しさん
垢版 |
2021/08/22(日) 17:58:26.12ID:sVqTe99t
Rustでグラフ構造を作れないとか言いそうな奴に
ARCでグラフを作らせたら駄目だろ常識的に考えて
0025デフォルトの名無しさん
垢版 |
2021/08/22(日) 20:28:01.36ID:A59qHoiu
>>20
ちょっと意味が分からない
0026デフォルトの名無しさん
垢版 |
2021/08/22(日) 21:04:38.19ID:+3UN9nhX
つまりレジスタだけ使ってのプログラムってことだろ。
そんなんやる必要ほとんどないが。
0027デフォルトの名無しさん
垢版 |
2021/08/22(日) 21:13:45.05ID:nqrywZna
本当に知らない人のために言うと、全部ブログ記事のパクリ
なので相手にしてもマトモなレスが返ってこない。無視で良いよ
0028デフォルトの名無しさん
垢版 |
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")
0029デフォルトの名無しさん
垢版 |
2021/08/22(日) 21:27:47.34ID:A59qHoiu
>>26
アセンブラだってスタック使うでしょ？
0031デフォルトの名無しさん
垢版 |
2021/08/22(日) 23:42:29.56ID:A59qHoiu
>>30
ほー、なるほどね
だからって>20はおかしいよね
0032デフォルトの名無しさん
垢版 |
2021/08/23(月) 00:53:35.51ID:dRBSj4mI
アセンブラは型がない
アセンブラだけで作ったライブラリも可読性のためにはCの型を宣言する
宣言したらもうCのライブラリとして利用可能にするだろ常識的に

つまり旧世代言語のコードを減らすとかいうおかしな目的意識の代わりに
ライブラリを増やすという適切な意図がある
0033デフォルトの名無しさん
垢版 |
2021/08/23(月) 01:09:17.02ID:PPErbdyj
そこはCもC++もRustも同じでアセンブリ含めて相互に呼び出し可能
だったらコンパイル通った時点でメモリ安全性を保証できるRustで基本的に書いてどうしても必要な部分のみアセンブリというのが現在の流れ
0037デフォルトの名無しさん
垢版 |
2021/08/23(月) 06:59:34.18ID:53a1qHWJ
>>34
masm とかでも構造体を定義できたりするけどやればやるほどC言語で良くね？とかなりがち
0038デフォルトの名無しさん
垢版 |
2021/08/23(月) 13:47:20.63ID:Rq8RLuIS
どうせWEB屋が好きな/使ってみたい言語ランキングでしょ
0039デフォルトの名無しさん
垢版 |
2021/08/23(月) 18:03:58.81ID:Rrt4HCug
nim もっとカッコイイ名前が良かった
julia よりマシだが
0042デフォルトの名無しさん
垢版 |
2021/08/23(月) 21:15:07.01ID:4kP0uHrS
>>35
せいぜいCで代替できないケースもある、だな
「代用不可」は言い過ぎ
0043デフォルトの名無しさん
垢版 |
2021/08/23(月) 21:19:05.15ID:Rok9YfeI
C/C++/Rustは中でアセンブリ書けるので大丈夫
どうしても必要な部分がある時は使われている
0048デフォルトの名無しさん
垢版 |
2021/08/24(火) 01:00:35.96ID:Fpbrw/6U
>>44
もうトートロジーに陥ってるじゃん…
無理しないで>20は命題として偽だって認めなよ
0050デフォルトの名無しさん
垢版 |
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
0051デフォルトの名無しさん
垢版 |
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
0052デフォルトの名無しさん
垢版 |
2021/08/24(火) 09:08:23.82ID:8IlJ2cew
大手IT企業たちをはじめ次々となぜRustを採用しているのかの理由のうち一番大きな点は、
直面しているセキュリティ等のバグの原因の大半がメモリ安全性の逸脱に伴うものであり、
メモリ安全性を保証する論文に基づいたRustがそれら問題点を解決することが明確となっている点にある。
0054デフォルトの名無しさん
垢版 |
2021/08/24(火) 14:54:36.93ID:MFD20u5I
>>51
コード読んだ訳じゃないけど1番上のやつnimはコメントにfast inverse square root使ってるって書いてあるし比較できなくね？
0055デフォルトの名無しさん
垢版 |
2021/08/29(日) 20:34:53.75ID:TMfqiUgQ
>>52
言ってる事は正しいが実際の理由はそうではないと思う。C/C++に比べればメモリ安全性はその通りだが
多くの言語ではGCがあるためにメモリ安全性をほぼ保障をしているが、わざわさRustを採用するのは
極めて大きいメモリーを扱うプログラムやリアルタイム性を追求される要件があり、それがGCのSTWや
GC時間を無視できないから
0057デフォルトの名無しさん
垢版 |
2021/08/30(月) 10:54:55.14ID:6iKzd6aE
GCに限った話でなくてもUnsafe使えば全部同じ、自身が使ってなくても（速度を出すために）ライブラリで使ってる。
Unsafe使わなくても完全に防げるわけでは無い。これはgoもnimもDも同じ
「大手IT企業たちをはじめ次々となぜRustを採用しているのか」の一番の要因は55の言う通りだと思う
0058デフォルトの名無しさん
垢版 |
2021/08/30(月) 11:07:11.50ID:M/wulqx+
>>55
扱うメモリーの大きさは関係ない

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

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

C/C++をRustで書き直したってあるのかね？servoも最初っからRustだったはず
0067デフォルトの名無しさん
垢版 |
2021/08/31(火) 19:36:48.62ID:tid2JAjH
C++が既に十分に優れているということを言いたいのかもしれないけど、
C++からRustに書き換えないのは単純に難しいからだと思うぞ
0068デフォルトの名無しさん
垢版 |
2021/08/31(火) 20:00:37.49ID:JHqwYLi1
違うよ
既にあるものを移植する案件が少ないだけ
しかし大規模改修や新規案件ではC++を利用する意義がなくなったのでRust採用が多い
もちろんC++だけからではなくFacebookのようにJavaからRustのパターンもある
0069デフォルトの名無しさん
垢版 |
2021/08/31(火) 20:56:18.00ID:Srcy774Z
>>65
ChromiumOSやAndroidはコンポーネント単位でRust導入が進んでるプロジェクトかな
あとはcurlがバックエンドをRustにする作業中
0070デフォルトの名無しさん
垢版 |
2021/09/01(水) 00:08:09.87ID:+dwouIiT
>>66
糞言語でも広まると糞言語だと言われない場合も多い。
広まってしまったらそれまで。例えばPythonとか。
0071デフォルトの名無しさん
垢版 |
2021/09/01(水) 01:35:43.66ID:GVO/11SU
最良言語を目指すやつはすぐ仕様変更するのが欠点だな
Pythonも仕様変更はあったが古いバージョンを虐待しなかったのがよかった
0074デフォルトの名無しさん
垢版 |
2021/09/02(木) 15:26:46.45ID:ONfZsKfr
サーバー書くならGoかRustかって感じだけどどっちもパッとしないんだよな
シンプルと複雑の中間が欲しいわ
0076デフォルトの名無しさん
垢版 |
2021/09/02(木) 18:06:33.02ID:wNaONt6G
Dartはサーバ側でも使ってねとアナウンスあったけど、
クライアント側と同じ言語で書ける以外の利点は特に無いのかな
0078デフォルトの名無しさん
垢版 |
2021/09/02(木) 18:37:13.19ID:6gOJWbCR
サーバ用途ならcrystalがええんちゃうかね。rubyをコピーした資産が多そう
0079デフォルトの名無しさん
垢版 |
2021/09/02(木) 18:51:33.01ID:UQhR0inN
別に1つの言語に拘る必要なくね
rust導入するとしても丸ごとリプレースする必要はない
0080デフォルトの名無しさん
垢版 |
2021/09/02(木) 19:29:02.15ID:bHl+beee
>>71
pythonも2から3への移行はだいぶ苦労したろ。
あれで脱落しなかったのは割と奇跡的だと思うわ。
0081デフォルトの名無しさん
垢版 |
2021/09/02(木) 20:00:41.23ID:XW9HOgOw
もしコンパイラ言語ならgccとかllvmも同時に移行しないとコンパイルできなかったりして
0082デフォルトの名無しさん
垢版 |
2021/09/02(木) 20:34:58.67ID:lSTkj0Rg
>>80
慌てる乞食は儲けが少ない
0087デフォルトの名無しさん
垢版 |
2021/09/03(金) 17:09:30.99ID:K5OdE3wo
本質的でない複雑さもあるからね
たとえばRustは標準ライブラリがGoなんかに比べると貧弱なので、自前で実装したりコミュニティのパッケージに頼らざるを得ないシーンが多い
0089デフォルトの名無しさん
垢版 |
2021/09/03(金) 19:59:54.63ID:9y+1HwQb
少なくとも、全てのアルゴリズムをRustではアプリのsafeモードでは扱えない。
例えライブラリをunsafeモードで書いたとしても。
それが最大の欠点。
書き方が面倒なのが次の欠点。
0091デフォルトの名無しさん
垢版 |
2021/09/03(金) 22:16:03.68ID:9y+1HwQb
Rustでライブラリやメソッドを unsafe で書いて、それを safe モードから
使っても、決してCと同じ効率では利用できないアルゴリズムが存在する。
0092デフォルトの名無しさん
垢版 |
2021/09/03(金) 22:27:23.15ID:9y+1HwQb
>>91
理由は、Cで昔から至って普通に使われていたアルゴリズムのかなりもののが、
Rustだと借用規則に違反してしまうから。
学問的にも正しくて使い方を誤りさえしなければ安全である事が分かっていても、
Rustでは借用規則に違反するので最初からコンパイルエラーになってしまって
使えない。
それらのアルゴリズムは、unsafeモードの中だけに借用違反を閉じ込めよう
としても無理。なぜんばら、根本的に借用規則に違反していて、
それがそのアルゴリズムの本質で要(かなめ)の部分だから。
0093デフォルトの名無しさん
垢版 |
2021/09/03(金) 23:01:26.75ID:HcIIq6Rh
>>84
様々なプログラミング言語と比較しても
Rustの基本シンタックス記法は素直なほぼ標準タイプ
最大派閥のC系と比較してもRustは条件式にカッコが不要なくらいかな
0099デフォルトの名無しさん
垢版 |
2021/09/04(土) 04:09:47.08ID:iqtSb51S
たしかにRustは非常に書きやすいしコンパイラのrustcが賢くてミスを直す候補を探し出してきて表示してくれるので便利だけど
奴隷の生産性まで上がるものなのかね
0101デフォルトの名無しさん
垢版 |
2021/09/04(土) 08:12:27.52ID:elqVYRSe
元々、共有やコピー、参照の違いをまともに理解してない奴に限ってrustを評価する傾向にあるのがな。。
はっきり言ってそれをまともに意識してるコード書くやつはそれほど便利だと思ってない。
0103デフォルトの名無しさん
垢版 |
2021/09/04(土) 11:14:39.89ID:EwYrh1qJ
ヒント:
safeモードに借用規則がある限り、メソッドの中にunsafeを閉じ込めようとしても
絶対に無理なアルゴリズムが存在する。

これが理解できないのは、数学力が足りない。数学力は生まれつきのものが大きくて、
ワーキングエリアの大きさや、想像力の問題。
0104デフォルトの名無しさん
垢版 |
2021/09/04(土) 11:17:19.47ID:EwYrh1qJ
なぜ例を提示しないかと言えば、本当のことを教えたくないからだ。
嘘だからではない。
本当のことを教えるのはもっと時間が経った後でいい。
時間が経ったらだんだんと本当の事が広まっていくだろう。
俺は最初からそれがわかるが、分からない人は分からない人なりの人生を送れば
いい。それが俺の才能だから。
俺の才能を全ての人に分け与えるわけにはいかない。
0105デフォルトの名無しさん
垢版 |
2021/09/04(土) 11:20:31.21ID:EwYrh1qJ
コンピュータの世界は、どんなに頭のいい人でも時間が経てば追いつかれる。
平易に解説されたり、または、ライブラリなどが難しいことを閉じ込めて
誰でも使えるようにしてしまうからだ。
だから頭のいい人もその間のタイムラグだけで差を付けるしかない。
だから、本当の事をすべては明かさない。
0106デフォルトの名無しさん
垢版 |
2021/09/04(土) 11:30:28.20ID:GpbNmj1Q
入力するデータに依存するアルゴリズムなんじゃないの
C/C++なら自由に実装できるけど実務上は不正データがないかチェックするハメになるという
0107デフォルトの名無しさん
垢版 |
2021/09/04(土) 12:30:13.91ID:EwYrh1qJ
>>106
全く関係ない。
数年後には秀才達が解説してくれるだろうから、分からない人はそれまで待とう。
0108デフォルトの名無しさん
垢版 |
2021/09/04(土) 12:37:18.23ID:HK0EkPCX
もしかして、ボローチェッカに怒られるコードをunsafeブロックに入れればエラーを回避できると思ってやってみたらできなくて、
それでここまでずっと言い訳してるのか？
0109デフォルトの名無しさん
垢版 |
2021/09/04(土) 13:11:05.75ID:gkfG02et
例示しろって言われてアウアウしてるんだろw
長文で言い訳グダグダ書いてるのが哀れですらある
0112デフォルトの名無しさん
垢版 |
2021/09/04(土) 14:19:15.62ID:qlWaKbMU
ループで書けないけど再帰でならかける、とかはあるけど、完全に書けないのはあるかなぁ…
0117デフォルトの名無しさん
垢版 |
2021/09/04(土) 17:35:39.84ID:HcNFP2te
数学的才能がない人は、人から言われたことを鵜呑みにするだけで自分で考える事が出来ない。
0118デフォルトの名無しさん
垢版 |
2021/09/04(土) 17:40:09.63ID:iqtSb51S
どのスレでもどの問題についてもいつも同じパターン
指摘されても具体的なケースを示せない人や具体的なコードを出せない人は『イチャモンをつけるだけのダメな人』
0119デフォルトの名無しさん
垢版 |
2021/09/04(土) 17:40:36.61ID:HcNFP2te
今回の事を見ても分かるように、ヒントを与えられても、それを部品として
組み立てて結論を導くことが出来ない。
そういうひとはいいプログラムはできない。
自分でアルゴリズムを発明することも出来ない。
0120デフォルトの名無しさん
垢版 |
2021/09/04(土) 17:41:48.84ID:HcNFP2te
>>118
違う。
ヒントを与えられても、自分で組み立てて正しい答えをひらめくことが出来ない
人しかそのスレに来ていないだけ。
答えを知っていても、与えないだけ。
0121デフォルトの名無しさん
垢版 |
2021/09/04(土) 17:48:30.37ID:FwiYtexa
実世界でも一緒だな。
言い訳ばかりして具体例を出せない人を相手にしても話が進まず時間の無駄。
そういうバカは無視するのが正しい。
0122デフォルトの名無しさん
垢版 |
2021/09/04(土) 17:54:17.63ID:HcNFP2te
優秀な人から正しい答えを簡単に教えてもらえると思ってるのはどういう教育されて
きたんだろう。
情報量も払わないくせに。
0125デフォルトの名無しさん
垢版 |
2021/09/04(土) 18:25:26.65ID:HcNFP2te
情報は与えないが、本当のことを言ってるのにうそ扱いしないでくれ。
ちゃんと思考力や理解力が有る人には正しいことが分かる。
このスレに今居る人は、俺以外は数学的能力が足りてない。
0127デフォルトの名無しさん
垢版 |
2021/09/04(土) 18:40:45.92ID:HcNFP2te
>>126
だから、詳細を不特定多数の人達に言うわけにはいかないと何度も行ってるじゃないか。
問題点を明確にしたら改良されてしまう恐れがある。
それは俺の立場からしたら最悪で、問題点は問題点のまま改良されずにずっと
残っていてくれたほうが都合が良い。
0130デフォルトの名無しさん
垢版 |
2021/09/04(土) 20:45:10.80ID:iqtSb51S
存在するかどうかすら例示されていない空想の問題について話をするのは
少なくともプログラミング言語のスレでは無意味
0131デフォルトの名無しさん
垢版 |
2021/09/04(土) 21:51:42.85ID:CUdge0sZ
>>130
同意
0133デフォルトの名無しさん
垢版 |
2021/09/05(日) 11:58:59.75ID:TAzC3d8r
スレのレベルが低すぎ。
本当に頭のいい人が言ってる正しいことが理解できない人ばっか。
0134デフォルトの名無しさん
垢版 |
2021/09/05(日) 11:59:36.21ID:TAzC3d8r
このスレでは、たった一人だけが正しいことを言って、他はみんな間違ってる。
0136デフォルトの名無しさん
垢版 |
2021/09/05(日) 12:11:17.36ID:3IKjsp8l
自分のことをたった1人とか言っちゃう猿
0138デフォルトの名無しさん
垢版 |
2021/09/05(日) 15:07:01.68ID:LgQhIBwq
Aを教えてくれ→解答a
Bを教えてくれ→解答b
Cを教えてくれ→解答c
一生これを続けるつもりか？(たまにそういう人物がいるが明らかに向いてない)

気をまわして x 使え！
(そうすれば A も B も C も解決するよ！！)
っていう解答が来ると「教えてくれない！！！」とキレる
0141デフォルトの名無しさん
垢版 |
2021/09/06(月) 09:30:22.04ID:NkVKbvcc
フェルマーでさえ問題そのものは明らかに提示したというのに、問題そのものも一意に定まらない状態で教えてｸﾚｸﾚしかここには居ないバカばっかりって言ってるんだよな
0142デフォルトの名無しさん
垢版 |
2021/09/07(火) 09:33:01.92ID:AwNiMUSI
生ポインタがない言語では
まずグローバルな配列を使うアルゴリズムに変換し
次にグローバル変数とかstatic変数禁止の規則に違反しないように書き直す

これができない人はJavaでもstatic変数を使うことになる
0145デフォルトの名無しさん
垢版 |
2021/09/08(水) 22:07:00.68ID:qzNSvV6w
等価っていうかそれを遅いと宣言したらJavaもC#もGoもみんな等しく遅いことになる
0146デフォルトの名無しさん
垢版 |
2021/09/08(水) 23:52:20.69ID:7Stt1ihW
Cみたいな無能言語を除けば配列インデックスには境界チェックが入るからポインタと同じではないよ
0147デフォルトの名無しさん
垢版 |
2021/09/09(木) 00:23:24.04ID:3/x9wOmm
少なくともC++とNim言語ではコンパイルオプションで配列、vector、seqの境界チェックをオフにすることができる。
0148デフォルトの名無しさん
垢版 |
2021/09/09(木) 00:54:48.17ID:ByOcyvaf
vector<T>型を更に抽象化してV<T>とすれば
高速なVと安全なVを二刀流できたのに
0149デフォルトの名無しさん
垢版 |
2021/09/09(木) 09:35:35.54ID:H5Pm1mBI
少なくともRustは境界チェックを全とっぱするのではなく必要に応じてuncheckする仕組みがある
0150デフォルトの名無しさん
垢版 |
2021/09/09(木) 09:49:27.01ID:nDPpxxc9
実際のところ境界チェックのロスってどんなもんなの
組み込み向けはともかく一般的なCPUだと分岐予測とパイプラインのおかげでロス少なそうな印象だが
0151デフォルトの名無しさん
垢版 |
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倍程度遅くなるのも当然
0152デフォルトの名無しさん
垢版 |
2021/09/09(木) 23:38:57.23ID:f/JM052X
>>150
正解
0155デフォルトの名無しさん
垢版 |
2021/10/03(日) 20:16:28.62ID:rU4PBp3b
Stack OverflowのServeyであった
給料が高くて人気な言語に
Rust Julia Elixir Clojureあったけど
みんなマクロがあるからなのかな？

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

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

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

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

>>189
Rustの出現でついにC++から解放された
0193デフォルトの名無しさん
垢版 |
2021/10/16(土) 03:21:07.83ID:0owCAudu
>>192
Rustはコンパイルが通ったらメモリ安全性を保証するが
C++はコンパイルが通ってもメモリ安全性を保証しない
そのためC++で書かれたものはメモリ安全に関するバグを産出してきてそれがセキュリティ脆弱性の7割を占めているとGoogleもMicrosoftも述べている現状
0194デフォルトの名無しさん
垢版 |
2021/10/16(土) 12:10:44.93ID:MVC0A82Z
だからGoogleもMicrosoftもどれだけ言語ダメにしてきたか、少し頭使って調べてみてくれ。
そのお題目がいかに名目だけか実際大規模でビルド体制整えて運用してみればよくわかるから。
0195デフォルトの名無しさん
垢版 |
2021/10/16(土) 12:33:30.03ID:vbkw9O81
>だからGoogleもMicrosoftもどれだけ言語ダメにしてきたか、少し頭使って調べてみてくれ。

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

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

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

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

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

一方C++は本を買わないとついていけないビジネスモデル
0214デフォルトの名無しさん
垢版 |
2021/10/17(日) 14:16:08.94ID:6j2makCm
Javaは次々に新しいフレームワークができて
バージョンアップも早い
動かすだけで一苦労
が何回も繰り返される
0215デフォルトの名無しさん
垢版 |
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言語系統では今まで実現できていなかったメモリ安全性の保証に成功したことが大きいですね
0217デフォルトの名無しさん
垢版 |
2021/10/17(日) 18:33:14.43ID:YptL43pX
classを廃止したとか笑うわw
0219デフォルトの名無しさん
垢版 |
2021/10/17(日) 18:48:49.33ID:MaJoh28m
>>218
各ブラウザにDartVM積んでJavaScriptを置き換えようとしてたけど断念し、選ぶ価値の無いAltJSと化した死に損ない
最近はFlutterで息を吹き返して、Dart単体でも多少は使えるようになってきたような
0220デフォルトの名無しさん
垢版 |
2021/10/17(日) 19:14:55.95ID:MkgjpPUe
>>215
オブジェクトと実体が一体になるというのは、組み込み用途でもわかりやすい
アナロジーなんだよね。

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

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

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

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

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

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

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

そんなことは起こりえません
あるtraitをその構造体に実装(impl)できたのならば間違っていなかったわけです
そしてその実装は自分で行うのですからメンバを壊すという意味不明なことは起こりえません
おそらくプログラミングをしたことがなくて大きな勘違いをしていると思われます
0227デフォルトの名無しさん
垢版 |
2021/10/17(日) 23:50:24.15ID:QqhGhKAl
本当にそれでバグが無くなるなら良いが、見当違いのことを一生懸命してるように見えるぞ。
0228デフォルトの名無しさん
垢版 |
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を採用するに至ったというわけだ。
0229デフォルトの名無しさん
垢版 |
2021/10/18(月) 00:00:05.81ID:U4M03mzh
>>228
10年後にはまた別のことを言ってる。
再現性のないバグのほとんどすべてがメモリーに起因するのは間違いないが、メモリーの確保解放とはまた別の話。
Rustのやり方で上手くいかないことは、C++を使う者ならとうの昔に気付いている。
0230デフォルトの名無しさん
垢版 |
2021/10/18(月) 00:03:14.89ID:U4M03mzh
Haskellこそ救世主である。
0231デフォルトの名無しさん
垢版 |
2021/10/18(月) 00:09:24.28ID:gU1bKDav
>>229
Rustがメモリ安全性の問題を解決している
これはC++とRust両方でプログラミングしたことある人ならば全員が理解していること
0232デフォルトの名無しさん
垢版 |
2021/10/18(月) 01:15:23.81ID:U4M03mzh
Rustじゃ無理、Haskellこそ次世代言語。
0233デフォルトの名無しさん
垢版 |
2021/10/18(月) 02:37:41.54ID:mrfOLNSK
>>227
ほんそれ
0234デフォルトの名無しさん
垢版 |
2021/10/18(月) 02:39:28.50ID:mrfOLNSK
>>225
温暖化ωですね判りますωω
0235デフォルトの名無しさん
垢版 |
2021/10/18(月) 02:42:33.77ID:mrfOLNSK
>>229 に同意
>>228 読んで騙される香具師は素人
0236デフォルトの名無しさん
垢版 |
2021/10/18(月) 03:31:02.12ID:cK47AFx9
Rustがメモリ安全だって主張している人はRustのメモリ安全とは具体的に何なのかソースも添えて説明すべきでしょう。
そうしないとあの言語だってメモリ安全だとか俺ならC/C++でも十分メモリ安全に書けるからRust不要って言われちゃうよ。

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

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

証明が万能だと信じるなら両立をあきらめられない
万能ではないと判断すれば可読性は捨てられる
0243デフォルトの名無しさん
垢版 |
2021/10/18(月) 14:15:47.57ID:CRhgpEvH
変数の寿命が有限になった原因は2種類ある
スタックとヒープ
一部の言語ではヒープの定義をライブラリに丸投げするから言語仕様で定義しない
あとはスタックを定義するだけ
0244デフォルトの名無しさん
垢版 |
2021/10/18(月) 15:25:39.78ID:fRkWn8Ak
237のような気持ち悪い信仰がとてつもなくrustの普及を阻んでいる。
0245デフォルトの名無しさん
垢版 |
2021/10/18(月) 15:42:51.62ID:r9t2S6+p
メモリ破壊やリークが絶対存在しないプログラムでも
データ次第ではいくらでも飛ばせる
0246デフォルトの名無しさん
垢版 |
2021/10/18(月) 16:41:38.35ID:a937BLhH
なんかずれていってんな。
誰も万能とか言ってないのに、あくまでも他言語と比較しての話なのに。
0247デフォルトの名無しさん
垢版 |
2021/10/18(月) 17:24:02.54ID:+nrbTxfF
rustはgc使わずにメモリ解放できるから速くて安全ということなのだと思ってたけど、そういう単純な話でもないのかな
0249デフォルトの名無しさん
垢版 |
2021/10/18(月) 18:18:29.34ID:W4UMdHtn
優秀な人からRustへ流れてるよな
C++が言語として完全敗北してしまったところが興味深い
0250デフォルトの名無しさん
垢版 |
2021/10/18(月) 18:26:09.16ID:sw4A5qdT
Rustのセールストークなどに惑わされず
Rustがやろうとしたことを冷静に理解しきってるのがC++erという
C++を知らなかったりニワカ知識だったりする人が騒いだり対立を煽って楽しんでる
0251デフォルトの名無しさん
垢版 |
2021/10/18(月) 19:13:39.89ID:gU1bKDav
>>250
C++とRust両方のプログラミングができるならば
C++の欠陥であるポインタ使用ミスがあってもコンパイルが通りメモリ問題を引き起こしてきた件をRustが解決したと理解できるはずだが
0253デフォルトの名無しさん
垢版 |
2021/10/18(月) 20:29:15.76ID:CRhgpEvH
トークがどれだけうまくなっても人の話を聞かない相手には効果がないよな
聞き方や読み方のレベルを上げた方が早い
0254デフォルトの名無しさん
垢版 |
2021/10/18(月) 20:40:39.51ID:9iPUXHWE
C/C++理解してれば
Rustは不要ですよ
0255デフォルトの名無しさん
垢版 |
2021/10/18(月) 20:44:49.04ID:oPyph5kC
むしろrustで問題解決とか言ってるやつのc++コードがどれだけひどいのか観て見たくなってきたわw
0257デフォルトの名無しさん
垢版 |
2021/10/18(月) 21:57:02.11ID:W4UMdHtn
もしC++がRustに勝る点が一つでも残っていれば
C++しか書けない人がこれほど発狂することなかったろうに
0258デフォルトの名無しさん
垢版 |
2021/10/18(月) 23:49:18.78ID:k0GYnhD+
超次世代言語Dart
0259デフォルトの名無しさん
垢版 |
2021/10/19(火) 01:27:04.57ID:PbORd8vw
C/C++で完璧なコードかけるならどこいっても歓迎されると思うよ
それが誰もできないんだからrustに流れてるってことでしょ
0260デフォルトの名無しさん
垢版 |
2021/10/19(火) 03:17:45.56ID:+8M5kAvN
>>259
いや完璧なコードを書けるというのが勘違いであり凄いプログラマーでも間違いを起こすことがある
だからこそ人間頼みではなくコンパイラがチェックした方が良いと誰もが辿り着いた
0261デフォルトの名無しさん
垢版 |
2021/10/19(火) 05:43:42.06ID:mawS91w/
>>255
俺も。
メモリーの確保解放ですべて解決みたいな主張してるから余計に不思議。
0262デフォルトの名無しさん
垢版 |
2021/10/19(火) 07:01:04.92ID:3gMaYVXy
俺はここの耄碌よりGAFAMを信じますけどね
0265デフォルトの名無しさん
垢版 |
2021/10/19(火) 08:22:28.00ID:0uJXMEOT
自分で考えている時には命令文や疑問文を使う必要がない
否定文なら使ってもいいけど
0268デフォルトの名無しさん
垢版 |
2021/10/19(火) 08:56:27.98ID:9axoCOPN
二番目はAppleと言われてるけどどう考えてもAmazon
ケツから将来性の無い順番で消える、つまりGAFAMのMが消えてGAFAになったので
次のAppleが消えてGAFになる
0269デフォルトの名無しさん
垢版 |
2021/10/19(火) 09:55:30.99ID:T9srRJav
GAFAMって言葉が生まれたのはGAFAより後では？
MSをハブったらかわいそうってことで生まれたような
将来性が一番微妙だからハブられてたんかもしれんけども
0270デフォルトの名無しさん
垢版 |
2021/10/19(火) 10:09:08.48ID:L/QTVpd7
まあFacebookよりは明らかに上やから入って当然ではある
0272デフォルトの名無しさん
垢版 |
2021/10/19(火) 19:00:05.85ID:089JTvXc
Crystal入れてちょんまげ
0273デフォルトの名無しさん
垢版 |
2021/10/19(火) 19:37:36.30ID:OaBrXs9n
crystalはrubyライクという以外あまり特徴がないよな。次世代言語としてどこで存在感出せばいいのか
0274デフォルトの名無しさん
垢版 |
2021/10/19(火) 20:15:37.83ID:LrPlA7Vp
>>254
一人で作業するなら好きな言語使えば？
0275デフォルトの名無しさん
垢版 |
2021/10/20(水) 09:10:49.09ID:OEiI06HQ
>>261
++
0276デフォルトの名無しさん
垢版 |
2021/10/20(水) 16:10:03.72ID:lLepbwfw
Nim version 1.6 is now officially released!
0277デフォルトの名無しさん
垢版 |
2021/10/21(木) 09:29:50.15ID:Hd41fW1K
Nimくん自分とこのスレに書き込まれずにこっちにばかり話題が来るのちょっとかわいそうになってきた
0278デフォルトの名無しさん
垢版 |
2021/10/23(土) 00:34:45.65ID:o3xA5lbA
>>273
Crystalの開発は、Rubyの特徴である優雅さと生産性の高さ、コンパイラ言語の特徴である実行速度の速さと
効率の良さと型安全を目的として、2011年6月に開始された。バックエンドにLLVMを利用することによって
効率的な機械語を生成することができる。
他のコンパイラ言語と比較して、高度な型推論とユニオン型の組み合わせによって、高水準スクリプト言語の
ような簡潔な記述を実現している。
Goに影響されたファイバー間の通信を行うための軽量なチャネルとファイバーが実装されている
0279デフォルトの名無しさん
垢版 |
2021/10/23(土) 01:42:06.05ID:psrWRCod
俺が思うに
このスレに登場する言語は次世代言語なんかでは無く
狂信者がいる言語にしか見えない
次世代言語の話してるのに「C++」という単語の出現頻度の高さがそれを物語ってる

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

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

松本おおおおおおおお！
0300デフォルトの名無しさん
垢版 |
2021/10/24(日) 14:51:32.96ID:x5aKIXa7
FacebookはReactとかVRあるから日本でも結構重要なポジションになりつつあるな
SNSは全然流行ってないとしても
0303デフォルトの名無しさん
垢版 |
2021/10/24(日) 19:18:02.70ID:4GW3Pp+f
F#……
0307デフォルトの名無しさん
垢版 |
2021/10/25(月) 00:38:46.00ID:Zg5tRANc
>>301
c++23で契約プログラミングが標準化されたら改善するかも？
0308デフォルトの名無しさん
垢版 |
2021/10/25(月) 00:42:01.96ID:Zg5tRANc
そういやrustって契約プログラミングをサポートする文法あったっけ？
0310デフォルトの名無しさん
垢版 |
2021/10/25(月) 23:17:33.61ID:vPVmdF1Z
結局、データの共有かコピーかが楽に設定できるかどうかってことに焦点が当たって、
rustは捨てられることになるよ。
こんな明らかなことさえわからん連中ばっかなのが面倒ごとだな。
0311デフォルトの名無しさん
垢版 |
2021/10/25(月) 23:55:02.93ID:Hh6pHipi
コピーの反対はムーブかもしれないので、コピーの反対は共有だろうという雑な考えを捨てよう
0312デフォルトの名無しさん
垢版 |
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はネックが生じる
0313デフォルトの名無しさん
垢版 |
2021/10/26(火) 11:22:52.21ID:UCZJSiVy
バカが老害ガー言われ始めるのに大体１０年くらいかかる。
こうして流行は終わる。
0314デフォルトの名無しさん
垢版 |
2021/10/27(水) 12:05:58.55ID:6tzLPjk/
Crystal入れてください
0320デフォルトの名無しさん
垢版 |
2021/10/29(金) 00:13:25.52ID:RD2SEv+6
vlangは0.3が全然出ないね。mutを後から導入したのがよほど不具合頻発になったのだろうか
0322デフォルトの名無しさん
垢版 |
2021/10/30(土) 02:29:08.63ID:qGEfyGin
取り沙汰される、って何年後のことやねん
やたら表現力高そうだし、ベストプラクティスがなかなか定まらなそう
0323デフォルトの名無しさん
垢版 |
2021/10/30(土) 03:11:26.17ID:U9OTRLVf
rustだgoだと言ってたら一瞬Vが騒がれて消えてなくなって今はnimなの？
今ならrustでいいじゃん
クッソ速くて賢くて小さくて安全でどこでも動いて便利な使いやすい言語誰か作ってくれ
一番大事なのは速いことな
0326デフォルトの名無しさん
垢版 |
2021/10/30(土) 11:52:44.92ID:YSY9yYdl
他の言語の存在を無視したりOSの存在を無視したりしたら
まともな説明ができなくなる
空虚な言葉を使うのは原因というよりむしろ結果
0327デフォルトの名無しさん
垢版 |
2021/10/30(土) 13:21:47.38ID:U9OTRLVf
むしろ複数のコンピュータをまとめて1つの環境として扱い、その環境で最適化して実行可能な言語を作ってくれ
0330デフォルトの名無しさん
垢版 |
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がまだ無いのもエレガントとは思えない
0331デフォルトの名無しさん
垢版 |
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
0332デフォルトの名無しさん
垢版 |
2021/10/30(土) 22:36:16.21ID:G/S2+R78
まあmacro記述を簡単にインライン展開するために別言語風になるのも分かるけど、、名前衝突が起きないように
デフォルトで別名に自動で名前を付けて展開してインライン展開する場合は特殊タグを付けるほうが
0333デフォルトの名無しさん
垢版 |
2021/10/30(土) 23:31:55.44ID:U9OTRLVf
>>331
そんなの言語レベルのサポートいらんやん
分散も並列化も勝手にやってくれ
プロセスもマシンも意識したくない
意識してもいいけど必須じゃなく、自動で可能な限り適切にリソースが配分されてほしい
プロセスとかそんなざっくりした単位でもなくね
それが実現可能な言語を用意せよと言っている
0335デフォルトの名無しさん
垢版 |
2021/10/31(日) 00:43:34.15ID:e5ZzvOAs
言語レベルサポートが無いということは、分散も並列化も勝手にやったら不可分解の通常のforループも
分解されてしまうので、そんなことは不可能。繰り返し順次実行と、（表現上は繰り返しだが）並列実行
では意味も結果も異なる。
要らないというコンピューター言語学での証明は無い。思想的には集合要素に対するmap/reduceなどが
並列の操作ができるからと言って、forだけで表現できる語彙ではない。言語の標準ライブラリにreduce
などのAPIがある事は、それそのものが（並列に実行していないのに）並列性の表現と同じ意味。
CPU側でそれが並行操作可能か、何らしらのマーカーは必要というのは素人以外はすぐ分かる事
>”言語を用意せよと言っている”おまえ何様やねんｗ
0336デフォルトの名無しさん
垢版 |
2021/10/31(日) 00:44:58.68ID:LjLsZLEJ
プログラミング言語という概念すら理解してないのがこのスレの住人のレベル
0337デフォルトの名無しさん
垢版 |
2021/10/31(日) 01:28:26.60ID:e5ZzvOAs
>>334
その通り。分散コンピューティング/グリッド・コンピューティングなどではミドルウェアが利用される。
Erlangなどでも、分散処理できるがspawn(node, ...)などノードを意識しなくてはならない。また
CPU処理が分散できたからと言って、ファイルシステムなどローカルしかないため、大規模分散には
分散ファイルシステムが必要になり、Googleのようにbigtableができ、その上で耐故障性を備えるように
仮想化して、スケールアウトやオーケストレーションのためにkubernetesなどなど、別レイヤーが
果たす役割が多い
0338デフォルトの名無しさん
垢版 |
2021/10/31(日) 01:35:34.83ID:sAwtPlvj
そういうことじゃないｗ
俺様が言ってるのはマシン/アプリ/ライブラリ/OS/デバイスの垣根を超えて
言語とそれらの複合環境がカバーしうる汎用な表現が可能な言語やｗ
作れｗ
0339デフォルトの名無しさん
垢版 |
2021/10/31(日) 01:43:15.98ID:e5ZzvOAs
基地外かあ…、この業界こういうの大杉壮大な能無し基地外のかまってちゃん
0340デフォルトの名無しさん
垢版 |
2021/10/31(日) 01:47:23.36ID:sAwtPlvj
例えば組み込み制御系で使えばCの配列を作るのと同じ記述でスケールしたら分散KVSもどきやらが出来上がるような言語
並列実行可能かどうかはあるロジックの入力が別のロジックの出力を使ってるかどうかだけ
0341デフォルトの名無しさん
垢版 |
2021/10/31(日) 01:58:47.24ID:sAwtPlvj
できそうにないだろ？
既存のアーキテクチャにどっぷりなら
高速にぶん回したかったらrustでもC++でもgolangでも使えばいいし
スケールするだけで十分な速度が出るなら誰でも使える言語を使ってスケールすればいいし
僅かに違う新しめの言語の差分をネタに趣味・嗜好を語るよりは夢を語った方が有意義でないかい？ｗ
0343デフォルトの名無しさん
垢版 |
2021/10/31(日) 02:08:26.79ID:e5ZzvOAs
おまえのチンポコの穴から並列でションベン出来るか考えてロンパーロンパーしてろｗくそ基地外ｗ
0344デフォルトの名無しさん
垢版 |
2021/10/31(日) 02:12:58.45ID:e5ZzvOAs
おまえがいるだけで世の中迷惑、人の足引っ張りまくり、親に迷惑かけまくり、誰もがお前を見ると顔をしかめる。
クズの癖に１つも優れた能力も、努力もなく、相手を貶し、悦に入る
問題の原因の根本たるおまえが消えて無くなれば、よほど有意義
0345デフォルトの名無しさん
垢版 |
2021/10/31(日) 10:57:39.56ID:dKAtRzTx
LISP専用CPUとRISC-CPUを聴き間違えたけど同じもの？
0346デフォルトの名無しさん
垢版 |
2021/10/31(日) 11:13:06.97ID:gOKmIPxI
>>330
微妙だね。
マクロもオフサイドルールも賛否分かれそうだし、最後に至っては「Goよりはエレガント」ってｗ
0347デフォルトの名無しさん
垢版 |
2021/10/31(日) 12:55:57.25ID:o3yW9Bfn
>>346
公式はgoと比べてる訳じゃないよ？
0348デフォルトの名無しさん
垢版 |
2021/10/31(日) 13:41:46.14ID:nF8ypkXG
Goは断捨離の観点でエレガント
try throw catchなんか無くても関数は返り値をエラー値とタプルで返せばいいし
classなんかなくても構造体と関数でいいし
イテレータなんか使わずともfor回せばいい
0349デフォルトの名無しさん
垢版 |
2021/10/31(日) 13:50:44.46ID:5SuYQG0J
落ち着いていて品のよいさま。上品。優雅。エレガン。
（考え方や手法などが）簡潔で要を得たさま。手際のよいさま。明快なさま。

抽象度は高めたほうが優雅なのでは？
0350デフォルトの名無しさん
垢版 |
2021/10/31(日) 13:56:01.91ID:sAwtPlvj
昔のperlみたいにならないよう糖衣構文やそれに類するモノはどちらかに振った方がいい(エレガントな)こともある
結局は好みだけどなｗ
0351デフォルトの名無しさん
垢版 |
2021/10/31(日) 14:23:30.67ID:512CMESs
中置記法をユーザー定義する構文糖を否定したやつは失敗
PythonとC++は少なくともその失敗をしなかった
0352デフォルトの名無しさん
垢版 |
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
0353デフォルトの名無しさん
垢版 |
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
0355デフォルトの名無しさん
垢版 |
2021/10/31(日) 16:18:17.43ID:nF8ypkXG
>>353
type classは関数型言語Haskell発祥
そのNimのページを見る限りその貧弱なおもちゃ版に見える
例えばNimと同じ手続き型言語のRustのtraitも用語は違えどtype classなので比較するとわかりやすいが機能面でも型付け面でも強力
0356デフォルトの名無しさん
垢版 |
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とも言い換えることが出来る
0358デフォルトの名無しさん
垢版 |
2021/10/31(日) 18:15:22.28ID:4KbMhR6u
演算子なら
∩∪⊕
あたりは欲しい
0359デフォルトの名無しさん
垢版 |
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なら尚更。
0360デフォルトの名無しさん
垢版 |
2021/10/31(日) 18:42:57.86ID:d0afoHzs
Goに関して言えばユーザー定義のiteratorは何度もproposalされて撥ねられてるがいずれ入るちゃうかな？
演算子に関して言うならinや->,=== ,<>,instanceofなんていうものが世の中あるので、UTF-8/16で
関数名が書ける言語なら、uniform-func-callが出来る言語ならなおさら出来ないのはおかしかった
0361デフォルトの名無しさん
垢版 |
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の中身が{}で空なところにアレンジを書いたり
0362デフォルトの名無しさん
垢版 |
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
0363デフォルトの名無しさん
垢版 |
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);
}
0364デフォルトの名無しさん
垢版 |
2021/10/31(日) 22:21:09.61ID:rLjO7mCc
>>356
それくらい書けやとしか思わんわ。
まあパターンマッチで変なnullチェック減らすとかは入れてもいいと思うが。
0366デフォルトの名無しさん
垢版 |
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は他にあまり無い十分に柔軟性がある特性なんだから、奇妙な信仰的な推し方をすんな
0367デフォルトの名無しさん
垢版 |
2021/11/01(月) 08:14:17.55ID:cuJVsFXJ
go2もgenericsと関連して、Tagged union的なType set/Type list/Sum typeが入るはず
0369デフォルトの名無しさん
垢版 |
2021/11/01(月) 11:40:40.03ID:vX/UhvAM
趣味・嗜好は昇華して信仰になる！
実際に共用体になるのとポインタだけ入るのを同じに分類したら何でもありな気はするｗ
0370デフォルトの名無しさん
垢版 |
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であることがわかっていただけると思う。きちんと理解しているならば。
0371デフォルトの名無しさん
垢版 |
2021/11/02(火) 01:20:08.88ID:Ou8VP/7A
そもそもB | Cのようなad-hocな型制約をRust開発者が好まないというだけのことだと思う
関数オーバーロードもC++のテンプレート特殊化みたいなのも無いし
0372デフォルトの名無しさん
垢版 |
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の発展を阻害しているのです。
0373デフォルトの名無しさん
垢版 |
2021/11/02(火) 02:02:23.69ID:AchKVKlJ
ググってみたがRustのtraitは普通のtraitではない話がたくさんあるな
あとRustのtraitはHaskellの型クラスだという話も多数あるな
世間での認識は>>370で合ってるんじゃね？
0374デフォルトの名無しさん
垢版 |
2021/11/02(火) 02:15:11.25ID:GkRdNW5V
ID変えてまた自己弁護、市ね基地外
0377デフォルトの名無しさん
垢版 |
2021/11/02(火) 08:34:53.92ID:dHCyhX6F
>>375
せや、あんたが優勝や
0378デフォルトの名無しさん
垢版 |
2021/11/02(火) 08:39:57.46ID:yi7goDxw
このクズは誰も言って無い事を言い出す、「他の言語のtraitとは同じ」「Rustで実装できない」
こんなことは誰も言ってない。
おまえはさ、Rustの発展にも、会社にも、社会にも邪魔だから消えろよ？おまえみたいのは、まだ技術が
浅く新しい人が入ってくる障害だからね
0379デフォルトの名無しさん
垢版 |
2021/11/02(火) 10:07:28.88ID:A2ISzYRE
>>378
お前は>>372？
じゃあ、「無理やりコードを書いて実現」についてのHaskellとの具体的なコードの比較でいいよ。
あと、「type classの「ほんの一部」を実現するために(rustの）traitを用いているだけです。」について、Rustのtraitで実装できないtype classのHaskell実装例。

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

マクロ引数の問題はtemplate引数よりも更に気持ち悪い
0385デフォルトの名無しさん
垢版 |
2021/11/02(火) 13:43:18.32ID:aJCYG77w
C++もね、conceptでだいぶマシになったんだけどね
そもそもどれだけの環境でC++20が使えるんだという話をされるとぐうの音も出なくなる
0387デフォルトの名無しさん
垢版 |
2021/11/02(火) 15:36:03.35ID:px0qcy1y
3人いようが4人いようがそれ以上でも
描き込み全部気持ち悪い事実は変わらない
0388デフォルトの名無しさん
垢版 |
2021/11/02(火) 16:14:12.44ID:TM2Ai9P9
お前らが気持ち悪さに敏感なのは良いことだと思う
気持ち悪さの応酬をして平気なツラしてるような地獄のスレもある
0389デフォルトの名無しさん
垢版 |
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>に相当)のようなコンテナ型にはコピー可能な型なら何でも指定できるわけですが、こういうのが気持ち悪いと言われても指定できる型を限定すれば不便になるだけだと思うのですが。
0393デフォルトの名無しさん
垢版 |
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だってこういう提案はされて、別言語の悪口なんて出てこないんです
0394デフォルトの名無しさん
垢版 |
2021/11/03(水) 15:54:38.31ID:JMRJWcyj
ネガってるのとそのレスに極端な反応してるのは他人を基地外呼ばわりしてる1人しかいないと思うんだけどｗ
他の人は他言語と正確に比較してるだけで否定的な論調もなく他人の趣味・嗜好を尊重してるｗ
0396デフォルトの名無しさん
垢版 |
2021/11/03(水) 23:58:41.87ID:UFPQir4N
まあ仕事で使う上では言語の強みより弱みや落とし穴を知っとく方が価値あるわな。
どうせ選ぶ権利ない場合がほとんどだし。
その辺が学生、アマチュアなんかとの差だろうね。
0397デフォルトの名無しさん
垢版 |
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
0399デフォルトの名無しさん
垢版 |
2021/11/04(木) 08:00:34.54ID:iBQltfW1
>>385
現場で使えわせてくれるのはあと2,3年はかかりそうだな
0400デフォルトの名無しさん
垢版 |
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
0401デフォルトの名無しさん
垢版 |
2021/11/04(木) 10:57:37.34ID:lAAyXHqu
何を見ても聞いてもnimには一切興味がわかない・・・
なんというか特徴がなさすぎる
0402デフォルトの名無しさん
垢版 |
2021/11/04(木) 11:41:59.42ID:vVwsjj5J
Haskellとかもそうだけどオタクの中のオタクの間だけで持て囃されてる言語には近寄らない方が吉
0403デフォルトの名無しさん
垢版 |
2021/11/04(木) 12:00:51.59ID:tx1xmHYz
Rustこそ至高の言語、NimとHaskellなんて糞、GoはまあGoogleがやってるから認めるけど
言語的にはジェネリクスも無い90年代の時代遅れ
NimだとかHaskellだとか、糞気持ち悪いオタクの匂いがする。どっちもゴミ
SwiftとKotlin、そしてTypeScriptともにスマホで使う
0405デフォルトの名無しさん
垢版 |
2021/11/04(木) 13:07:01.54ID:UnTZr4yd
>>403
Nimも悪くないとは思うけど
欲しい基本がまだexperimentalなど多いのと人口の少なさ
あと競合しているRustがコンパイル通ればメモリ安全性保証してるので
結論はRustでいいじゃんとなりました
0406デフォルトの名無しさん
垢版 |
2021/11/04(木) 13:17:36.87ID:fybR+JX+
Goが良いのは、関連エコシステムと、あと強いていうなら並列処理らへんぐらいかな。
プログラミング言語としてはさすがにしょぼすぎるけど、エコシステムが優れてるからなんだかんだ便利。
PythonとかJavaScriptとかはエコシステムが最強な言語の一つだよね。
逆にD言語とかはエコシステムがウンコすぎて使い物にならなかった。
0407デフォルトの名無しさん
垢版 |
2021/11/04(木) 13:19:04.19ID:bqbD3Nhm
Nimはなんか中庸って感じがする
そこにピッタリはまる人にはいいんだろうけど
もっと楽に書きたい人はGo、ちゃんと書きたい人はRustに流れてしまって
あまりユーザが増えないのではないかな
0408デフォルトの名無しさん
垢版 |
2021/11/04(木) 15:00:22.37ID:OXP1jNWB
オタク臭いやつと臭くないやつの違いは一般人でもわかる
TypescriptとGoとNimの違いがわかるのは重度のオタクだけだろ
0409デフォルトの名無しさん
垢版 |
2021/11/04(木) 15:11:34.22ID:lAAyXHqu
やっぱ言語の普及には有名企業の後押しがいるんか？でもrustってなんか後押しあったっけ？
まあ案件レベルだと全然ないけどｗ
0411デフォルトの名無しさん
垢版 |
2021/11/04(木) 15:18:21.88ID:fybR+JX+
大企業の後押しは必須ではないだろうけど、後押しあると強い、というか、やっぱエコシステムが育ちやすいと思う。
すぐに潰されない言語だ、って思って他の企業とかも投資できるからかな。
TypeScriptが人気あるせいか、Dartはなんかイマイチ広まりきれてない感じだったけどね。

Rustは新規ミドルウェアを作るような現場では需要あるんじゃないの？
0412デフォルトの名無しさん
垢版 |
2021/11/04(木) 15:26:36.67ID:8l/Jusr1
いまRust推しの大企業といえばAmazonだな
MozillaからリストラされたRustコミッタを相当取り込んでるし
影響力が強すぎるんじゃないかと不安視されるくらい
0413デフォルトの名無しさん
垢版 |
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
0414デフォルトの名無しさん
垢版 |
2021/11/04(木) 15:32:39.45ID:DB49gC4z
>>410
どの言語を書く時でも基本的にはインデントするから
インデントでコードブロックを作ることによってソースコードの中に
{}とか;が頻繁にでてこないようにしたほうがソースコードがすっきりして読みやすくなると思うんだけどな。
0415デフォルトの名無しさん
垢版 |
2021/11/04(木) 15:46:29.06ID:4stXfNK+
>>414
ルールで言うならyamlみたいなインデント or カッコの両対応がいいんだけどねぇ。そんなの無いけど。
0417デフォルトの名無しさん
垢版 |
2021/11/04(木) 15:51:50.87ID:fybR+JX+
Rubyみたいな do end もそんなに悪くなかったし、エディタのサポートがあれば慣れの問題かなあ、って気がしてしまう
0418デフォルトの名無しさん
垢版 |
2021/11/04(木) 16:30:26.61ID:62sZMwyh
>>414
それをすっきりして読みやすいと思うか、必要な情報が欠落していて読みにくいと思うかは個人差あると思う
個人的にはインデントの戻り量が視覚的に判断しづらいから } がないと読みづらく感じる
0419デフォルトの名無しさん
垢版 |
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などがソースコードを勝手に整形するので、スペースではない明確な表示文字で区切りたい
という人もいる。当然このようなことを言い出したらキリがないが、最終的には好みで言語を選ぶわけで
無く仕事なら無条件であり、慈悲も和解もない。
0421デフォルトの名無しさん
垢版 |
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から見るとカッコ（悪い）言語になり、逆に伝統的なプログラマから
見ると、空白がブロックを左右するいい加減な言語に見える。よって又しても慈悲も和解もない
0422デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:14:28.06ID:MjRPJM3Z
{ } な言語ばかりやってきたので
インデント言語について素朴な質問です

スコープブロックはどのように作るのですか？
例えばスコープブロック作成のために数行だけを { } の中に閉じ込めたりするのですが
インデント言語では括弧も何もなく数行だけを深くインデントするのですか？
0423デフォルトの名無しさん
垢版 |
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
0424デフォルトの名無しさん
垢版 |
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:
　　...
0425デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:40:02.16ID:d2BeURFt
他にもlabel（？だったか）として名前付きのものもあったな、これは、多重のforなどのbreakで名前が指定できる
0426デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:40:29.24ID:lAAyXHqu
bindingはどの言語でもあるし簡単に作れるよ
ただ純正コードで書くのと同じくらい適切に運用させるのが困難な場合が多いので、誰もそれが簡単だとは言わない
個人的には正直nimアピールいらんｗ 何か書かれる度にどんどんnimから離れて行きたくなるｗ
0427デフォルトの名無しさん
垢版 |
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] が出力される
0428デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:44:36.59ID:fybR+JX+
nimアピールすごいな。
宣伝したいならQiitaとかでいっぱい記事書いたほうがいいんじゃないかな・・・。
0429デフォルトの名無しさん
垢版 |
2021/11/04(木) 17:50:32.91ID:d2BeURFt
言語なんて日本だけで流行っても、しょーがないし、流行るとしたら海外で流行らないと、Pythonだって
海外で流行っていて、Rubyの作者が日本人だから、日本ではRubyというかRoRが一色になりかけたのに
Pythonなんて誰もやってなかった（言い杉か）
0431デフォルトの名無しさん
垢版 |
2021/11/04(木) 18:01:05.24ID:UnTZr4yd
>>427
ブロックも式になって最後の値を返すとか
ブロックで変数スコープがあらたにつくられるとか
Rustなどと一緒だね

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

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

OS周りならC/C++でいいし
現状ではweb周りのごくごく一部の超高速領域を除きrustには置き換わっていない
javaからの置き換えならgoでいい
0445デフォルトの名無しさん
垢版 |
2021/11/04(木) 21:09:43.64ID:MjRPJM3Z
>>442
その3種類ともGoは対象外なことに驚きました
実はGoとRustは領域あまり被っていなくて競合していないのかもしれませんね
0446デフォルトの名無しさん
垢版 |
2021/11/04(木) 21:16:55.71ID:lAAyXHqu
他rust向きの領域だとdatabaseかなぁ・・・
ただ既存のDBを置き換えるのはなかなか厳しそうｗ
何かに特化したやつならいいかもねｗ
0450デフォルトの名無しさん
垢版 |
2021/11/04(木) 22:03:32.17ID:C83Gt3We
ビルドシステムでGCの動きを気にすることってほぼないけどな。
なんかやばい方向いってるね。
0452デフォルトの名無しさん
垢版 |
2021/11/04(木) 22:47:21.35ID:3s9ShBm/
まあrustは天才向け言語と思うので、コアなところがrust縛りになってくれると安心なところはあるね。goとかnimとかはちょろい分野で頑張れば良い
0454デフォルトの名無しさん
垢版 |
2021/11/04(木) 22:53:26.72ID:fybR+JX+
nimも良い言語だと思うけど、GAFAMみたいなとこがバックアップしてるわけじゃないし、仕事では使う気せえへんなあ。もったいない。
趣味ユーザが使いまくってエコシステムが充実するまで待つしかないな。
0457デフォルトの名無しさん
垢版 |
2021/11/05(金) 05:25:56.07ID:Q0weZe1J
嫌いっていうより、ウチの爺らはPythonすら出来なそうだけどね
0460デフォルトの名無しさん
垢版 |
2021/11/05(金) 09:40:04.97ID:ZsL5S5NL
サーバーサイドに企業のバックアップなどいらぬ
趣味で弄れない仕様になってる車の内部やスマホのアプリを企業がしっかり作れよ
0462デフォルトの名無しさん
垢版 |
2021/11/05(金) 11:30:58.07ID:pLniUbgZ
>>458
自動車ってガソリン車の時点でもう低レベルファームウェアの塊だもんな
これからEVとなるとなおさら…
0467デフォルトの名無しさん
垢版 |
2021/11/06(土) 00:50:02.35ID:iXKnTImN
rustもアピールすごいな、内容の無いrust押しもどんどんrustから離れて行きたくなるけど
0468デフォルトの名無しさん
垢版 |
2021/11/06(土) 01:56:27.18ID:x0h3LLto
YouTube で有名な、雑食系エンジニア・KENTA のサロンでは、
キャリアパスは、Ruby on Rails → Go のみ

Rust, Elixir などは、普及のキャズムを越えなかったので、やる必要なし。
なのに、Rustが再評価され始めたのか
0469デフォルトの名無しさん
垢版 |
2021/11/06(土) 02:00:59.99ID:EdP5MzkQ
C++でいろんな新規開発する組織ではRustが好評価されてるでしょ
それ以外の現場ではめったに見向きされない
0470デフォルトの名無しさん
垢版 |
2021/11/06(土) 06:29:11.65ID:bdG9YXuk
転職サイトとかフリーランスのサイトでRustで検索したら1桁か2桁ぐらいしか求人が出てこないけど国外国内で覇権を握る言語らしい
0472デフォルトの名無しさん
垢版 |
2021/11/06(土) 12:03:26.15ID:2f1Vgy/C
rustが評価されてるのは高速・安全の2点
これらが難しさを無視できるほど重要になる領域では唯一の選択肢になる
世界規模のサービスでは特にクリティカルな問題になるのでこの分野の発展を望む巨人共が投資してる
0474デフォルトの名無しさん
垢版 |
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
0475デフォルトの名無しさん
垢版 |
2021/11/06(土) 21:25:57.27ID:8rFQ20lW
そういう問題じゃねーわ。
そこでポインタを外に出すようなバカはどんな言語使っても同じようにカスなことやってるよ。。
0476デフォルトの名無しさん
垢版 |
2021/11/06(土) 21:32:11.29ID:v/Totsm8
>>475
人間必ずミスをする
そしてこれは言語の仕様としてそのようなことが起きないように禁止すれば済む話
Rustならコンパイラがその禁止事項でエラーとなるから人間が万が一のミスをしても大丈夫
0478デフォルトの名無しさん
垢版 |
2021/11/06(土) 21:45:46.17ID:f6JHtgP7
>>475
だから、よりチェックが厳密な(100%とは言わない)rustが良いのでは。
0479デフォルトの名無しさん
垢版 |
2021/11/06(土) 22:24:42.47ID:2f1Vgy/C
rustにしたら防げたのかもしれないが、だからってrustにした方が良いとは思わんｗ
0480デフォルトの名無しさん
垢版 |
2021/11/06(土) 22:30:30.69ID:v/Totsm8
少なくともその分野のプログラミングならばRustを用いるのがベスト
他に解がない
0483デフォルトの名無しさん
垢版 |
2021/11/06(土) 22:38:46.87ID:twTYwhnI
Rustは天才向け言語だからそんな凡ミスするやつが使うべきじゃない
はい終わり
0484デフォルトの名無しさん
垢版 |
2021/11/06(土) 23:12:13.85ID:2f1Vgy/C
rustにしたらメンテナンスできる人や便利にしてくれる人が減ってしまう
明確に別の問題があるんだよ
本当にそれしか解がないのなら問題が起きる前に誰かがすでに書き換えている
0487デフォルトの名無しさん
垢版 |
2021/11/06(土) 23:32:27.72ID:9KDcj+aF
>>484
Rustにしたらメンテナンスもしやすくなったよ
例えば機能追加で今回の件のようなバグが紛れ込むことも無くなった
もしその種のミスをしているとコンパイルが通らないから安心してメンテナンスできる
0488デフォルトの名無しさん
垢版 |
2021/11/06(土) 23:35:57.66ID:bBqH6KfG
天才が使う言語なんだからならそもそもメンテナンスなんてしなくていいだろ
はい終わり
0489デフォルトの名無しさん
垢版 |
2021/11/06(土) 23:36:45.09ID:2f1Vgy/C
メンテナンスできる人の数の話をしてるのに、そもそもメンテナンスできる人がメンテナンスしやすくなったからって関係ないよね
0491デフォルトの名無しさん
垢版 |
2021/11/07(日) 13:38:59.39ID:XJB+ymj6
たまに紙一重のやつがいるのは認めるが
イコールではないな
アスペ⊆天才でもないし
アスペ⊇天才でもない
0495デフォルトの名無しさん
垢版 |
2021/11/07(日) 15:13:11.87ID:XJB+ymj6
天才でも凡人でも地方でも
最低限のマナーすら守れない香具師は何やっても成功しない
0496デフォルトの名無しさん
垢版 |
2021/11/07(日) 15:30:00.12ID:/d1krDIr
マナーなんて無くても天才と馬鹿は行動力があれば成功するだろ
マナーが一番必要なのは凡人だけ
0498デフォルトの名無しさん
垢版 |
2021/11/07(日) 22:52:33.86ID:NYPA2RTD
>>489
PHPでも使ったら？一番人集まりやすいんでないか？
0499デフォルトの名無しさん
垢版 |
2021/11/08(月) 00:15:26.32ID:vASCcAjA
メンテナンスなんて少しも考えてないバカがrustすげーって騒いでるだけだろ。
どうせGAFAも認める言語使ってる俺すげーしてクソコード残して立ち去るような仕事のやり方ばっかしてんだろうね。
0500デフォルトの名無しさん
垢版 |
2021/11/08(月) 00:21:07.56ID:SITQ70se
メンテナンスならばRustがもっともしやすいだろう
コンパイルが通ればメモリ安全性が保証される点で他の言語より抜きん出る
これは大きな利点である
0501デフォルトの名無しさん
垢版 |
2021/11/08(月) 00:38:47.53ID:rlmkL2+c
それでメモリ安全性の定義ってなんだっけ
意味論を定義したうえで形式的に証明されてるんだっけ
0502デフォルトの名無しさん
垢版 |
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
0503デフォルトの名無しさん
垢版 |
2021/11/08(月) 02:24:21.55ID:p+/Hds0z
>>502
C/C++のようなポインタ演算は安全性のためにできないようにしてるが
Goならunsafe.Add、Rustならpointer::offsetやpointer::wrapping_offsetで同じようなことはできる
0505デフォルトの名無しさん
垢版 |
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
0506デフォルトの名無しさん
垢版 |
2021/11/08(月) 10:23:03.43ID:LdTjNXcL
>>501
絶対的メモリ安全性の定義が難しいなら
javascriptとtypescriptのような相対的な優位性を証明すればいい
0508デフォルトの名無しさん
垢版 |
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
0509デフォルトの名無しさん
垢版 |
2021/11/08(月) 15:56:14.25ID:dWDs4ee0
nimでスレが止まってるとイラっとするまでになってしまったｗ
前まで比較的好きだったのに・・・
0510デフォルトの名無しさん
垢版 |
2021/11/08(月) 16:03:45.86ID:KvpLYeV7
全員目をつむりなさい、この中に前から嫌いなのにA子さんの縦笛を盗んだ人がいます！
正直に手を挙げなさい！先生は怒りませんよ！
0512デフォルトの名無しさん
垢版 |
2021/11/08(月) 17:47:01.28ID:zeI+S7c1
>>500
いまどきメモリー安全じゃない言語なんてC/C++/Delphiぐらいなもんだろw、Java/KotlinもC#もNimも、D言語も
Swiftもunsafe的なコードじゃなきゃメモリー安全。Microsoftも採用基準はメモリー安全以外だと言っているよ
0513デフォルトの名無しさん
垢版 |
2021/11/08(月) 18:45:37.45ID:SITQ70se
>>512
GC言語でもメモリ安全じゃないケースはある
例えばGo言語は>>474の実例のようにメモリ安全ではないことが示された
そしてGCなしネイティブコンパイル言語となるとメモリ安全な言語はレア
0515デフォルトの名無しさん
垢版 |
2021/11/08(月) 19:47:27.37ID:SITQ70se
>>514
例えば>>474の現実例のようにメモリに関するバグをコンパイラが見逃して通してしまうプログラミング言語はメモリ安全性が保証されていない
0516デフォルトの名無しさん
垢版 |
2021/11/08(月) 19:54:02.50ID:9Ys8k33F
ほんとアホは相手しちゃだめだな。長さ不定のリスト構造に要素の追加を値渡しではなく参照にしてしまうのは
メモリー安全性なんて一切関係ないｗ、型チェックの厳密性（緩さ）の違いだけGoは確かに緩いけど、Rustが
強い型付けをしているから。更に極端な例を言うなら秘密情報を一文字違う宛先に送った明らかなプログラミング
ミスと何ら変わりない。代わりにRustはキャストが大変になってる

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

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

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

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

この問題はCGの有無とは関係なくスタック上にも変数を確保する言語の場合は生じ得ます
さらにヒープ上に確保した場合でも非CG言語では生じ得ます
そして強力な型チェックを行なっていてもそれだけでは回避できない点にこの問題の難しさがあります
唯一の解決方法は言語が各変数(領域)のライフタイムを管理して更にその参照が渡って行く先々のライフタイムがそれより短いことを言語が保証することによります
0520デフォルトの名無しさん
垢版 |
2021/11/08(月) 21:03:57.19ID:r0oqOAIx
RAIIですべて解決。
そもそも循環参照とか考えなければならなくなったら、自分の頭が狂っていないか病院で検査したほうが良い。
必要になってる時点で何かがおかしい。
0522デフォルトの名無しさん
垢版 |
2021/11/08(月) 21:09:44.36ID:j/frnJ3w
>>520
助言ありがとう。早速病院に行ってきた

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

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

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

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

医者「だめだこりゃw」

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

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

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

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

現実的にはunsafeでweakな参照を使って無理矢理GCを実装している
0536デフォルトの名無しさん
垢版 |
2021/11/09(火) 00:03:37.26ID:/IIRMA31
プログラマーってメモリが安全かどうかでずーーーーっと同じような話しててキモいわ
安全日とか危険日とかどうでもいいだろ消えろ
0537デフォルトの名無しさん
垢版 |
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種類の方法でこの種のバグが生じないように防いでいるということか。
0538デフォルトの名無しさん
垢版 |
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]

これはなかなか常人には理解しがたい
0540デフォルトの名無しさん
垢版 |
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 らへんだな。
0542デフォルトの名無しさん
垢版 |
2021/11/09(火) 09:26:15.28ID:Ziut+B8+
>>540
Goのスライスの諸問題は親スライス(＝元)と子スライス(＝バッファ部分がキャパシティを超えるまでは共有される)が同じスライスとして扱われるところにあるよな

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

構造をもったコレクション構造と連続領域確保のアロケーションを比べるなんて
頭がどこまでもおかしくなればこんないい加減なことを言えるのか
0545デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:06:48.86ID:cs0y0gBS
比べるなら、配列やVecじゃなく、heap::allocate(size, align);なのに
長々と無駄な事を書いて、Vec::with_capacity(len);と比べているという
スパナと釘を比べて、どっちが安全と説いているバカゴミクズ勘違い野郎
0546デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:16:31.45ID:p+4WEtUZ
>>545
俺もクソみたいなRust推しはどうかと思ってるが
今回の件は君よりもそのゴミクズ野郎のほうが問題の本質を理解してる
0547デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:21:06.21ID:cs0y0gBS
また顔真っ赤の何も言わない援護射撃が現れる
0548デフォルトの名無しさん
垢版 |
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;
}
0549デフォルトの名無しさん
垢版 |
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はどちらも伸長して足りなくなるたびにヒープ領域の再割り当てを何度でも自動的に行なう
もちろん再割り当てが頻繁に起きないように大きく確保してそれがキャパシティ
0550デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:37:04.74ID:cs0y0gBS
調べてきた
Cでは、構造体が名前付きメンバーなしで定義されている場合、プログラムの動作は"未定義"です。
ですから、処理系によっては0ではない違う値ということもあり得ます、なので0だ、というのは
少々違います。C++の場合、 標準ではサイズ0 のオブジェクトは許可されないため値1を返します。
clangに-std=c++17でCのソースをコンパイルすれば1になります。

未定義動作が多い言語は確かによろしくないですが、それだけ多くの処理系がある事の裏返しです
0551デフォルトの名無しさん
垢版 |
2021/11/09(火) 10:39:15.18ID:cs0y0gBS
必死に顔真っ赤になってレス付けてくるけど相手にしません、読むのも嫌
0552デフォルトの名無しさん
垢版 |
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付けてようやく怒られる程度の話ｗ
0553デフォルトの名無しさん
垢版 |
2021/11/09(火) 11:20:15.97ID:Ziut+B8+
>>549
単体で使う限りGoのスライスとRustのVecは同じ構造も持ち同じ挙動だが
共有されると両者の挙動が異なってくる

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

Rustは競合回避のためsingle writer xor multi readersの原則があるので
RustのVecに書き換えや伸長が起きるときは共有されていない
だからキャパシティを超えてバッファ部分再割り当ての時は移動のみで旧バッファ部分は即座に解放回収
0554デフォルトの名無しさん
垢版 |
2021/11/09(火) 12:35:36.43ID:UAERt8tt
goは比較的新しい言語とは思えないほど危険がいっぱいなんだな。rustどころかnimや crystalにも大きく劣る言語仕様なのに、信者が無理矢理な理屈で自分を騙してる印象
0555デフォルトの名無しさん
垢版 |
2021/11/09(火) 12:36:57.75ID:6MNHnF6e
>>540
素直にcopyか参照にしとけば良かったのにね。
効率求めるならCOWにした方が良さそう。なんでCOWにしなかったのかな？COWは並列処理とあんまり相性良くないけど。
0556デフォルトの名無しさん
垢版 |
2021/11/09(火) 12:47:14.84ID:Smk+8XDy
スケープゴートを用意し比較的人口の多いGoを攻撃する、Rustは悪くないのに"危険がいっぱいなこいつ"の悪辣性
0558デフォルトの名無しさん
垢版 |
2021/11/09(火) 13:08:33.41ID:0dhxEnJG
>>554
信者が無理矢理な理屈で暴れてるのはRust信者だろ
そんなことしてるからいつまで経っても普及しないオタク言語止まりなんだよ
0560デフォルトの名無しさん
垢版 |
2021/11/09(火) 18:50:44.35ID:sYcGGX0V
RustはD言語の再来と言われるほど期待されてる。
0562デフォルトの名無しさん
垢版 |
2021/11/09(火) 20:01:35.84ID:NdU8gMYv
うんこ野郎の独演会
0563デフォルトの名無しさん
垢版 |
2021/11/09(火) 20:12:33.83ID:mTU/Ys0g
>>559
超えていいよ。超えたときには別のバッファが作成されて、元のバッファの要素がコピーされる、ってだけだから。

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

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

言われたくないだろうな
0569デフォルトの名無しさん
垢版 |
2021/11/11(木) 14:23:06.64ID:Cobl5Yvk
C/C++は簡単にやばいコードを書けてそれを発見するコストが高いという問題がある
特にC++は使いこなすための練度のハードルが高いせいか凶悪と言ってもいいｗ
0570デフォルトの名無しさん
垢版 |
2021/11/11(木) 14:56:27.50ID:JCk4+0H4
C++がよくあそこまで流行ったもんだよね
こうなる前に他の言語を作る動きはなかったのかしら。まあそれが1995年のJavaだったのかなあ。昔すぎて自分にはよくわからんけど
0571デフォルトの名無しさん
垢版 |
2021/11/11(木) 15:12:54.92ID:Cobl5Yvk
むしろそれまではCしかなかった
Windowsが出てきて、その開発の主要言語でVisual C++が出てきたのでC++が流行った
と思ってる
インターネットが急速に発展したのはWindows 95以降だったので、それまでの流行りは処理系の人気に依存してた
と思う
その頃のUnix系や汎用機の世界までは俺も知らんｗ
勝手にUnix系はCで汎用機はCOBOLだったんじゃないかと思ってるｗ
0572デフォルトの名無しさん
垢版 |
2021/11/11(木) 15:29:17.41ID:jwvU2w1D
要は、スマホのように説明書不要と称する物を特許とか著作権とかの規制で縛って課金する方法と
本体を無料であげる代わりに分厚い説明書を買わせる方法がある
0573デフォルトの名無しさん
垢版 |
2021/11/11(木) 17:04:48.90ID:JCk4+0H4
>>571
なるほど。たしかにWindowsとVisual Studioがキラーアプリケーションだったんだ
MicrosoftがObjective-Cを採用してたら、Objective-Cがめちゃ流行ったんだろうし、やはりプラットフォーマーは強いな
MicrosoftかAppleのいずれかがLispを採用してたら、Lispの存在感も桁違いだったんだろうなあ。そういう世界線を見てみたい
0576デフォルトの名無しさん
垢版 |
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あたりかなぁ
※個人の感想/主観であることに注意
0577デフォルトの名無しさん
垢版 |
2021/11/11(木) 23:33:58.00ID:jahl/MWB
どうしてprologのことを無視するかなあ
80年代後半から90年代初頭にかけては
unixではprologの天下
Cよりも早くコーディングできた
0578デフォルトの名無しさん
垢版 |
2021/11/11(木) 23:45:48.82ID:JCk4+0H4
それ天下とはいっても流行してた、って意味じゃないよね？
GNUのソフトウェアもほとんどC言語だろうし・・・。
0579デフォルトの名無しさん
垢版 |
2021/11/11(木) 23:50:14.50ID:PBlMMjPy
prologはいいんだけどrust製prologのscryerとか見てるとISO準拠にこだわるのやめてくれと思う
文法とか組み込みオペレータ、組み込みプレディケートとかライブラリも新時代に合わせて工夫してほしい
昔ながらのコードをそのまま動かせる…
それは昔ながらのPrologで動かしてもろて…
じゃあprologじゃなくていいじゃんって？
そうだよ！基礎コンセプトそのままでガワを新しく整えたのがほしいんだよ！
0583デフォルトの名無しさん
垢版 |
2021/11/12(金) 14:41:26.85ID:MFojYN0L
swi-prologなら若干拡張されてるけど、prolog自体が昔からほぼ使われておらず
存在自体あまり知られてないし、結局手続き的思考が必要だし、用途が限定される使いにくい言語だと俺は思ってるｗ
0584デフォルトの名無しさん
垢版 |
2021/11/12(金) 14:59:17.99ID:CoiyKYqf
調べてみるとICOTとかいう、Prologをメインに使って、500億円も予算をかけたプロジェクトがあったらしいけど、なんだったんだろうな
0585デフォルトの名無しさん
垢版 |
2021/11/12(金) 21:33:34.72ID:x+I3WYUz
第五世代コンピューターと論理プログラミングを基にした現代の深層学習とは違う人工知能・・・ウッ頭が
つまりはアランケイのSmalltalkが最強ってことだろ？
0586デフォルトの名無しさん
垢版 |
2021/11/13(土) 11:37:24.38ID:gACfz8Jy
コストが高いか安いかでくるくる掌返すのはポジショントークだよな
しかもサンクコスト
0587デフォルトの名無しさん
垢版 |
2021/11/13(土) 12:37:16.91ID:LtGGXPX8
Prologは夢を見すぎたな
結局バグは仕様そのものとかいろんな理由で起きるというのに
0588デフォルトの名無しさん
垢版 |
2021/11/13(土) 13:27:58.51ID:gACfz8Jy
メモリ安全みたいなテーマに限定すれば夢が無限に大きくはならんだろ
夢を見たことではなくテーマを表す言葉を使わなかったことを反省しよう
0589デフォルトの名無しさん
垢版 |
2021/11/13(土) 13:40:18.34ID:pG0a2gxf
ループをすべて再帰で書くというのがちょっと難しいが
デバグが楽だし、保守もしやすい
ライブラリをどさっと作れば流行ったかもしれないな
のちのperl,javaのように
0590デフォルトの名無しさん
垢版 |
2021/11/13(土) 15:45:12.67ID:m5D80op7
>>589
末尾再帰ループ化できない再帰はスタックが溢れる
最近はループを更にわかりやすくイテレータ連鎖で書くのが主流だね

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

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

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

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

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

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

なぜそんなに強引に推し通したいのか、理解不能です。
0597デフォルトの名無しさん
垢版 |
2021/11/13(土) 18:05:59.35ID:gACfz8Jy
ベンチマークの数値ってもうRustのコンパイルエラーと同じぐらい意味不明と思われてるね
Prologさんを500億の言語にしても誰もほめてくれないし
0599デフォルトの名無しさん
垢版 |
2021/11/13(土) 19:58:21.21ID:H/IZ/H8E
>>596
おそらくC++やRustを使ったことがないのだろうけどC++のshared_ptrやRustのRc Arcを使うのは所有者が複数になる特殊ケースのみ
それらのみが参照カウンタを用いるけど所有者がいなくなった時点で自動的にリソース解放される
これをGCと呼ぶ人はいない
もちろんそれ以外のケースは参照カウンタも使わずに解放される
そのためGC言語は原理的にどうやってもCやC++やRustに勝つことはできない
0600デフォルトの名無しさん
垢版 |
2021/11/13(土) 20:16:30.44ID:blWxI0OX
特殊な界隈でそういう習慣があるのか知らんが
参照カウンタは普通にGCの実装方式の一つと
言われてるだろ
0602デフォルトの名無しさん
垢版 |
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の研究なんて見捨てられるでしょう
0603デフォルトの名無しさん
垢版 |
2021/11/13(土) 21:00:37.35ID:YXy1PChK
またGCの定義をmalloc/freeとreference countとtracing GCの3つの間でお手玉して好き放題言う流れか
0604デフォルトの名無しさん
垢版 |
2021/11/13(土) 21:05:09.14ID:qcFvcADm
更に言えば多くの独立したgcのある言語は、gcにおけるメモリー断片化を防ぐコンパクション処理を独自にやっている訳でOSに任せているRustが有利なのはその通りですが、だからと言ってその処理を行って無い事を不正という話には全くなりませんし、原理的にどうやっても等という結論出すことは全く意味がありませんね
0605デフォルトの名無しさん
垢版 |
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言語は速い」というデータも世間には見当たらない
0606デフォルトの名無しさん
垢版 |
2021/11/13(土) 21:24:08.80ID:qcFvcADm
ガベージコレクション
https://ja.wikipedia.org/wiki/ガベージコレクション
じゃあページの記述を削除して直して来いよ。顔真っ赤にしなくても良い話だぜ？書き間違いぐらい読もうよ？
「GC言語は速い」などという主張はしていないのも読めないから呆れるんだよ、妄信するあんたらを
0607デフォルトの名無しさん
垢版 |
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言語ではないです
0609デフォルトの名無しさん
垢版 |
2021/11/13(土) 22:10:48.49ID:gACfz8Jy
お前らの判断が遅いのは「審判は第三者でなければならない」という習慣のせいかな
自分が審判になって自分で好き放題に判断すれば早いんだが
0611デフォルトの名無しさん
垢版 |
2021/11/13(土) 22:29:17.51ID:riokxr1E
いろいろなプロセスが動かないバッチ処理なんかは逐一確保と解放を繰り返さない分だけ、調整すれば早いでしょ
0612デフォルトの名無しさん
垢版 |
2021/11/13(土) 23:05:29.89ID:H/IZ/H8E
>>611がここでプロセスとか言い出してるのを見てもわかるように
GC言語が有利というトンデモ主張している人は基本的な常識知識がないようだ
0616デフォルトの名無しさん
垢版 |
2021/11/13(土) 23:42:47.00ID:m5D80op7
>>611さんの解読
(1)バッチ処理だといろいろなプロセスが動かなくて
(2)つまりバッチ処理でなければいろいろなプロセスが動いて
(3)そしてバッチ処理でいろんなプロセスが動かなければ逐一確保と解放を繰り返さなくて
(4)逐一確保と解放を繰り返さない分だけ調整すれば早い
とおっしゃってるようだけど

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

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

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

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

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

「GC言語」はGCの利用を基本的前提として設計されてる言語という意味なので
non-GC言語にGC機能が用意されてるからといってGC言語に分類されるわけではない
0634デフォルトの名無しさん
垢版 |
2021/11/14(日) 17:18:41.30ID:jU07kwMv
>>626
C#はこの前メソッドチェーンでとやかく言ってた人たちには、LINQ表現などはさらに一歩進んだ考えだが、彼らが
このような記述表現が、仮にお気に入りの言語に入っても大喜びするとはとても思えない。
GCの観点でいえば、JavaやC#などのclassで参照を多用して並列GCでストップのあるものと、Goのようにstruct値
だけだが、軽量スレッドがあるために並列GCにしなければならなかったものとは同じ土俵で比べるべきではない
これは同じく、並列GCを用いないDIO様がいない世界の言語とも比べらずらい。
0635デフォルトの名無しさん
垢版 |
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が行われていることになってしまいますが？？
0636デフォルトの名無しさん
垢版 |
2021/11/14(日) 17:53:57.69ID:oGwX+s7w
>>632
freeはそんなに重くないにしても、メモリアロケーションは論理アドレスから仮想アドレスへ変換し更には連続し
適したサイズの空間を見つけるために当然ながら重くなる。
Linuxカーネルの場合のBuddy実装があるに、tcmalloc/jemalloc/dlmalloc/mimalloc/boehmなど、プログラムに
より適化したOSSの実装が次々と出来ていることからも、仮にプログラムがメモリ漸増するものではなく決定論的な
予測が可能である場合なら、逐一メモリー確保のためにOSに介在するよりも、プログラム開始時にドカンとメモリを
確保したほうが早くなる可能性もある。もし可能なら今の型推論と同じくこれはコンパイル時に解決されるだろう

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

そういう意味ではRustはRc無しで十分に使えてる。何でもかんでもRcやArc！みたいな風潮は無い
0642デフォルトの名無しさん
垢版 |
2021/11/14(日) 20:23:46.45ID:hzlmyWav
>>640
単にopt-inであるってだけじゃないですかねそれは
疎結合っていうとインターフェースが適切に定義されていて特定の実装に依存していないこと
0644デフォルトの名無しさん
垢版 |
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として説明されてるよ
0645デフォルトの名無しさん
垢版 |
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つとも仕組みは全く同じで同じように回収されていきますがカウントしているとガベージコレクションなのですか？
0647デフォルトの名無しさん
垢版 |
2021/11/15(月) 00:48:36.22ID:4clAYLzs
garbage collectorとgarbage collectionは別だろう
645の1,2,3はいずれも後者の一手法に該当する
前者は後者を実行する主体であり、スマポは前者には該当しないとするのが普通
能動的にgarbage collectionを行うというよりプログラマ自身がそれを行うための補助に過ぎないからな
0649デフォルトの名無しさん
垢版 |
2021/11/15(月) 06:44:36.60ID:IExf6kKf
手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGCだよって言えばshared_ptr、unique_ptrはGCになるでしょう。
でもヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGCだっていえばshared_ptrとunique_ptrはGCにならないでしょう。
0650ハノン ◆QZaw55cn4c
垢版 |
2021/11/15(月) 06:52:03.10ID:a976/UsH
>>649
＞手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGC
足りない。
この条件＋「循環参照も問題なく扱える」という条件を追加して！

＞ヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGC
動作タイミングはGCの本質ではないとおもいます
0655デフォルトの名無しさん
垢版 |
2021/11/15(月) 11:17:46.17ID:A0Oqbbcg
なんか変なこと言われてたような気がしたけど、Perlは参照カウンタ方式のGCを採用した言語だよ
0656デフォルトの名無しさん
垢版 |
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).
=========
0657デフォルトの名無しさん
垢版 |
2021/11/15(月) 12:56:43.04ID:1YFhL4pj
擬似問題起こしているな。
とりあえず>>633はちゃんと区別して議論したら？

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

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

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

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

と、私は認識している
間違いがあったら有識者は叩いてくれ
0663デフォルトの名無しさん
垢版 |
2021/11/15(月) 14:58:31.40ID:OV4818+l
>>645
プログラマーの視点からはその(1)(2)(3)の3つともGCではないな
C++言語仕様的にその3つは全く同様にdeleteで配列でもクラスのインスタンスでもメモリ回収されていく
だから参照カウンタを用いているshared_ptrだけGCだとの主張にも実態との大きな乖離があり違和感がある
GC派の人は以上の点をどう捉えている？
0664デフォルトの名無しさん
垢版 |
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なんかもメモリプールを随分前に導入しているしね
0665デフォルトの名無しさん
垢版 |
2021/11/15(月) 15:22:07.43ID:A0Oqbbcg
>>662
Perlに限っていうと、参照カウント式のGCしかなくて、循環参照を自動で削除するような方法は併用されていません
よって、おっしゃるようにプログラマが弱参照を使ってくれないとメモリリークが簡単に起きます

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

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

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

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

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

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

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

ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である。
0687デフォルトの名無しさん
垢版 |
2021/11/15(月) 21:08:32.33ID:0t2kAlwU
>>684
>>ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である

それだけだとC++(11以降)もSwiftもRustもGC言語ということになってしまいます
だからその定義が不十分なんだと思います
0688デフォルトの名無しさん
垢版 |
2021/11/15(月) 21:21:58.47ID:PbjRD0ud
>>687
いや、それはGCの定義なんだから十分だろう
不足してるとするなら「GC言語」の定義
まぁ言語機能にGCが組み込まれてるならGC言語で
ライブラリとして実装されてるだけ（C++やRust）はGC言語ではないって感じだと思うが、正確な定義は知らん
0689デフォルトの名無しさん
垢版 |
2021/11/15(月) 21:28:35.39ID:VyWPF7Kj
>>685
参照されなくなったポインタをデストラクタに渡したらデストラクタ内で参照される
デストラクタ内でポインタを復活させるようなコードを容認するとGCの性能がどんどん下がる
だからGCの性能を上げたい言語にはデストラクタ機能がないのが合理的
0690デフォルトの名無しさん
垢版 |
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を自作すれば…できる
0691デフォルトの名無しさん
垢版 |
2021/11/15(月) 22:07:26.02ID:9V9ekymj
>>687
「機能である」と書いてあるだろ。
よく読めよ。どこに「言語である」と書いてあるんだよ。

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

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

「スマートポインタ」が分かりづらいというなら、c++の「shared_ptr」でいいですよ。
0696デフォルトの名無しさん
垢版 |
2021/11/15(月) 23:07:31.08ID:ESQg0oe1
>>682
ARCだけじゃなければ循環参照を回収するサイクルコレクターが動くので、OKというか循環参照全体を参照する
変数が消えれば消える。ARCの強参照は当然ながら連鎖的には消えない。
これがよく言うARCのメモリーリークでSwiftやObjective Cで起こる現象、親の所有者が消えたのだから内部で
参照しあっていても消えると考えてしまう。サークルを作らず直線状なデーターやツリー上のデーターならば
連鎖的に消える。
ただし、サイクルコレクターがある場合でもグローバル変数になっている場合には終了時のすべての変数が寿命を
迎えるだけなのでそこで壮大なメモリー解放が起こる（これを指して意味がなく壮大な無駄だという人もいるが）
そして、SIGTERMを送ってもなかなか終了しないプログラムは一生懸命メモリー解放を行っていたりする
0697デフォルトの名無しさん
垢版 |
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ではない』
0699ハノン ◆QZaw55cn4c
垢版 |
2021/11/16(火) 00:56:44.96ID:cq8/Yorc
>>697
主観的な記述だと思いますね
私は循環参照を許容できなければ、それはもはや GC ではないと思っています
マークスゥイープかコピーGC（そしてその発展系）しか私は認めません…①

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

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

ついでに言うと、shared_ptrにリソースの管理を任せるときは、shared_ptrがプログラムコードの
どの部分で（ソースコード記述的に）リソースを解放するのか決定できないことが多々ある。
これは「free相当の処理を明示的に書くこと」と決定的に異なる部分だな。
0706デフォルトの名無しさん
垢版 |
2021/11/16(火) 08:06:16.34ID:KQuNI5Eh
>>704
機能だけ見れば、Rustは参照カウント方式の「GC機能」を持っていると言えるだろ。

「GC言語」とかいう定義もはっきりしないバズワードに当てはまるかどうかは知らん。
0709デフォルトの名無しさん
垢版 |
2021/11/16(火) 08:47:56.56ID:cHZw5Yem
以下いずれもやっていること・行われることは全て同じ
抽象化と省力化が進んだのみ

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

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

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

動的に確保したメモリ領域を指してる所有権のある変数が
ムーブされずにスコープを抜ければ解放されるようコンパイラがよろしくやってくれる
これも参照カウント方式？
0711デフォルトの名無しさん
垢版 |
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 ね
0712デフォルトの名無しさん
垢版 |
2021/11/16(火) 11:32:23.17ID:O0etR+7l
RustやC++にGCがないという言及でGCが意味するところはガベージコレクタというランタイム処理ののことで
ガベージコレクションの仕組みがないとは言っていないという理解をしている
0715デフォルトの名無しさん
垢版 |
2021/11/16(火) 13:00:34.21ID:KQuNI5Eh
>>710
カウントしていないから違うんじゃないのかね。実際、他が参照していても（不要でなくても）スコープ抜けると解放されるし。

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

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

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

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

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

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

あとSafe Rustなら他が参照してればコンパイルエラーじゃないかな
unsafeなら参照側を長生きさせるバグを埋め込むことは可能
0726デフォルトの名無しさん
垢版 |
2021/11/16(火) 14:31:25.51ID:x6Dvmgzi
Rust寄りの話をすればGCの有無という定義より、現時点のコンパイラの方法は、Rustがメモリー回収の
コスト(CPU消費）が他に比べて小さいだけの話。参照カウントやBoxのようなスコープで解放と確保を
繰り返す事を「GCの有無に関せず」コストを話している人にも定義の有無の話にレイヤーが違うなどと
言いつつ巻き込んでくる。マジもんの狂信者には言葉は通じない
0727デフォルトの名無しさん
垢版 |
2021/11/16(火) 14:34:03.96ID:SlziVE7V
>>725
Arcはマルチスレッドで共有する時にRcに対してアトミック操作が必要な時にRcの代わりに用いる

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

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

一方でunique_ptrやRustの一般は所有者が1人のみなので所有権は維持するか譲渡するかになる
0732デフォルトの名無しさん
垢版 |
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)をさらに活用して、手動のフレームワーク内でメモリの割り当て解除を自動化します。
0734デフォルトの名無しさん
垢版 |
2021/11/16(火) 15:45:11.75ID:SlziVE7V
>>732
それはもちろんそう
GCは定義にあるように自動メモリ管理
一方でC++とRustのスマートポインタは手動メモリ管理
したがってGCではないことが明白
0735デフォルトの名無しさん
垢版 |
2021/11/16(火) 16:05:00.39ID:hZl5lwq3
>>729
その複数の所有者によって共有される所有権を管理してるのは誰？
プログラマではなく「自動参照カウント機能付きのスマートポインタ」が、「自動的に」所有権を管理しているんだろ？
0736デフォルトの名無しさん
垢版 |
2021/11/16(火) 16:07:51.68ID:wMIJ1Zq8
GC言語でもどの変数がどのオブジェクトの所有者か意識してコードを書けばそれは手動管理しているからGCじゃないってことになるの？
C++やRust使ってても所有者を気にせずに全部shared_ptrかRcにするようなコードの書き方をすればGCになっちゃうの?
0737デフォルトの名無しさん
垢版 |
2021/11/16(火) 16:09:38.42ID:QRdL5Qqy
Perlでメモリリークしがちな参照カウント方式でもGCとみなしてくれるなら許す
0738デフォルトの名無しさん
垢版 |
2021/11/16(火) 16:21:49.03ID:SlziVE7V
>>735
いえいえ
GCのように見えない意識しない魔法があるわけではなくて
例えばRcはstruct Rcという構造体の型に過ぎなくてプログラマーは管理のために色んなメソッドを発行することも出来るんですよ
例えばRcから弱参照のWeakを作り出したりRc自身の弱参照数を得たり増減したら強参照数も同様です
つまり手動メモリ管理の範囲内なんですよ

>>736
GC言語には所有権の譲渡の機能もないし手動解放の機能もないためGC言語で手動メモリ管理は無理だと思います
0739デフォルトの名無しさん
垢版 |
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
コンストラクタの時点で豊富にプログラマに選択肢を与えてる
アロケータやデリータも指定できて自由自在
このように、色々やることあるねプログラマ側は
0740デフォルトの名無しさん
垢版 |
2021/11/16(火) 16:42:40.84ID:mhJuEb25
あ、ズラズラというならRcのほうを引用したほうがさらにズラズラだったか…
0741デフォルトの名無しさん
垢版 |
2021/11/16(火) 16:49:31.73ID:XOoLtgC/
ちなみにshared_ptr/RcがGCじゃない派の人って
C++のBoehmGCはどっち判定なの？
使い方的にはshared_ptrと同じくプログラマが明示的にBoehmGCからメモリ割り当てないといけないから
GCじゃないって扱いになるわけ？
0742デフォルトの名無しさん
垢版 |
2021/11/16(火) 17:11:12.20ID:SlziVE7V
>>741
BoehmGCは手動メモリ管理ではなく
自動メモリ管理なのでGCです
プログラマーは所有権の譲渡や共有などのメモリ管理を全く意識せずに使えるからです
0746デフォルトの名無しさん
垢版 |
2021/11/16(火) 17:29:26.94ID:R8o6+SB5
GC_MALLOC(100000); // なにも管理しないぞ！mallocじゃないけどな！必死に自分の考えを押し付けようと１日張り付いてるニート
0747デフォルトの名無しさん
垢版 |
2021/11/16(火) 17:35:28.45ID:4mjXbMzz
>>742
手動メモリ管理と自動メモリ管理を定義して、BohemGCとshared_ptrの違いを明確化してから主張してくれ。

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

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

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

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

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

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

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

「使い方を間違えると」とか、曖昧な話でごまかすなよ。「それを理解できない人がいるとは驚いた」みたいな人格攻撃する暇あったら、グウの音も出なくなるぐらい堅牢な議論をしてみろよ。
0753デフォルトの名無しさん
垢版 |
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 なんよね
しかもガベージコレクションの代替として使用できるとのこと

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

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

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

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

というかスマートポインタという名前自体プログラマが介在しなくてもよしなにやってくれる賢いポインタという意味なので
これを手動メモリ管理と呼んでしまうのは違和感しかない
0758デフォルトの名無しさん
垢版 |
2021/11/16(火) 20:03:07.86ID:O0etR+7l
プログラマがshared_ptrとunique_ptrを選択しないといけないから手動メモリ管理との主張だが
仮にshared_ptrしかない言語が存在したとしたらそれは自動メモリ管理になるのか？
0759デフォルトの名無しさん
垢版 |
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
このようにスマートポインタは手動メモリ管理です
0760デフォルトの名無しさん
垢版 |
2021/11/16(火) 20:20:02.11ID:/J0mEe48
>>755の説明が一番しっくりくるな
これならRustもGC言語じゃないって言えるしこの辺で手を打ちませんか？
0761デフォルトの名無しさん
垢版 |
2021/11/16(火) 20:38:12.95ID:UQ2IYGru
見たくない真実はガン無視する手動自動マンｗ
”サイクルコレクターが無い点が「フルスペックのGC」では無いといえるかもしれん”をガン無視して
世紀の難解手動自動相対性理論に取り組む、いまだに答えは出ないが何やら信念があるらしい。知りたくもないｗ
0762デフォルトの名無しさん
垢版 |
2021/11/16(火) 20:42:55.59ID:g0Tjvy/G
そもそもキッチリ区別できるようなGCの定義なんて元々ないでしょ

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

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

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

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

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

おいおい、>>759で「shared_ptrで統一すればGCになる」と発言しているだろうが。
何で「GCだ！との主張は意味がないことが明らかで」なんだよ。
>>759は意味のない主張をするようなデタラメなやつだと言いたいのか？
0769デフォルトの名無しさん
垢版 |
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はここ
0770デフォルトの名無しさん
垢版 |
2021/11/16(火) 23:08:56.24ID:hZl5lwq3
>>769
いやそれshared_ptr自体は自動メモリ管理であり、手動管理と組み合わせて使用できるって言ってるじゃん
0772デフォルトの名無しさん
垢版 |
2021/11/16(火) 23:49:36.51ID:8BenLMiv
ウンコが都合の悪いことが書かれると、デカいの張り付けて手動自動理論に持っていくｗｗｗ
愛してるはずのRustにすら害を及ぼす腐った狂信者ウンコ。残ったのは自尊心のみ。「ここ」は便所の落書き
0774デフォルトの名無しさん
垢版 |
2021/11/17(水) 00:04:50.96ID:SsdWlmrh
>>709
これが一番納得
0775デフォルトの名無しさん
垢版 |
2021/11/17(水) 00:07:56.38ID:bZI3gHq3
じゃあSwiftは自動で管理してるからARCだけどGCなんだな？どんどんRustが嫌いになっていく…
0776デフォルトの名無しさん
垢版 |
2021/11/17(水) 00:43:47.98ID:YCf/hpfl
言語機能にどういうラベルを貼り付けるかの議論でよくもまあここまで盛り上がれるな
別に言語がGC含むとされようがされなかろうが
実態は変わらないだろうに
0777デフォルトの名無しさん
垢版 |
2021/11/17(水) 00:59:15.40ID:eNp19Ga9
>>769
Wikipedia英語版で決着ついたのか
これでスマートポインタは手動メモリ管理であってGCではないと確定だな
0779デフォルトの名無しさん
垢版 |
2021/11/17(水) 02:15:20.38ID:iywzxd5E
>>769
そこのwikiにはshared_ptrが手動メモリ管理なんて一言も書いてないね
結論捻じ曲げすぎてびっくりしたわ
0781デフォルトの名無しさん
垢版 |
2021/11/17(水) 03:01:08.49ID:eNp19Ga9
>>779
書いてあるようだが
手動メモリ管理のよってRAIIを介したshared_ptr等の自動リソース管理を可能にしていると

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

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

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

で、shared_ptrは【メモリ解放を自動化して】なので【手動で命令を書くこと】を満足していないから、手動メモリ管理ではないという結論にしかならんが。
0784デフォルトの名無しさん
垢版 |
2021/11/17(水) 08:49:09.28ID:zCczxc5o
>>778
私利私欲を捨てさせることが目的のように見える
私的な目的を持たないことが目的みたいな
0785デフォルトの名無しさん
垢版 |
2021/11/17(水) 09:00:58.02ID:MZt3q0rg
>>783
英語を読めないの？
>>769には、手動メモリ管理の有利な点としてRAIIによる自動リソース管理を可能とすることが挙げられ、C++では手動のフレームワークの範囲内でメモリ解放を自動化するshared_ptrが使われている、と書かれている
つまりshared_ptrは手動メモリ管理の代表選手
0786デフォルトの名無しさん
垢版 |
2021/11/17(水) 09:09:38.98ID:C+w8kxrc
>>783の解釈で正しいよ
そもそも出典の記載もなく俺が書いたかもしれないwikipediaの記事にどれだけ意味があるのかは知らんが
0787デフォルトの名無しさん
垢版 |
2021/11/17(水) 09:27:03.70ID:MZt3q0rg
>>786
ウソはよくないな
>>769には引用されていないけど
「手動メモリ管理の有利な点とし
てRAIIを可能としC++にはshared_ptrがある」の直後に
「このアプローチはGC言語(＝自動メモリ管理)では使用できない」と明記されている
shared_ptrは手動メモリ管理であることが明確になった
0789デフォルトの名無しさん
垢版 |
2021/11/17(水) 09:32:57.00ID:C+g/MvKJ
weak_ptrの存在もあれだよな
必要だったらコレ使ってなんとかしろよ？という
循環参照も自動で解放できるんならコレいらないしな
0790デフォルトの名無しさん
垢版 |
2021/11/17(水) 09:35:09.37ID:fpCU2YNN
定義定義ってうるさいよ
何を目的としてその定義があるのかという視点から考えないからこういうコーナーケースで無用な論争に発展する
0792デフォルトの名無しさん
垢版 |
2021/11/17(水) 10:05:52.29ID:TggxfUz+
〇〇かGCか否かという議論に決着がつくと
プログラム書く上で何か役に立つんですかねえ
あるいは学術的な発展でもするんですかねえ
0793デフォルトの名無しさん
垢版 |
2021/11/17(水) 10:22:36.39ID:C+g/MvKJ
じゃあ次はお前らの大好きなNimの話でもする？
Efficient, expressive, elegant
どこがエレガントなのかどうぞ
0794デフォルトの名無しさん
垢版 |
2021/11/17(水) 10:29:14.01ID:sX0XtunN
>>785
それはshared_ptrの実装に手動メモリ管理の枠組みが使われているという話で
shared_ptrが提供する機能性が手動メモリ管理に分類されるとは言っていないと思うが
0798デフォルトの名無しさん
垢版 |
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には無い機能）と読むのが自然。
0800デフォルトの名無しさん
垢版 |
2021/11/17(水) 11:50:46.89ID:MZt3q0rg
>>798
そこにもあるように
あくまでも手動メモリ管理の範囲内でのメモリ解放の自動化
とはっきり書かれている
しかも手動メモリ管理のアドバンテージの説明として書かれているわけだから
shared_ptrは手動メモリ管理であってしかもそのアドバンテージ
0801デフォルトの名無しさん
垢版 |
2021/11/17(水) 11:57:20.20ID:YG2/9hEL
不毛とハゲの違いってなんだよ？
英文持ってきて貼り付けて一仕事終えるじゃなく、自分の言葉で説明しろよ！
アドバンテージ！
0802デフォルトの名無しさん
垢版 |
2021/11/17(水) 12:04:02.33ID:C+g/MvKJ
RAIIで解放タイミングを把握できるのはメリットだね
GC標準装備言語だとそうはいかないもん
C#だとusingとIDisposableを使ってまで同じようなことをしたがるけど
using (StreamReader r = new("foo.txt")) {/*処理*/}
0803デフォルトの名無しさん
垢版 |
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++が活用してる内容は”自動”の範疇に含まれると記事の書いた人間は考えてる
0805デフォルトの名無しさん
垢版 |
2021/11/17(水) 12:18:06.70ID:iP5L/cQW
外部DLLに渡すヒープデータなんて普通にコントロールするのが当たり前、GC”非標準装備”言語だってそう
じゃなければDLLを起点にクラッシュする。おまえほんとはなにもしらねーんじゃねえの（笑）ｗ
C#だって当然そういう事を考えるだろう、アホ信者言語と同じことをしたいんじゃない
0806デフォルトの名無しさん
垢版 |
2021/11/17(水) 12:18:07.56ID:eNp19Ga9
>>802
だな
C++やRustなどは即座に解放のためデストラクタでファイルcloseやlock解放を自動化できてプログラマーは気にしなくて済むもんな
GC言語はこれをするのに各言語で苦労しているのと対照的
0807デフォルトの名無しさん
垢版 |
2021/11/17(水) 12:22:44.44ID:eNp19Ga9
>>803
それはかなりの曲解
自動化しているのは結果として起こる「メモリ解放」
その「メモリ管理」自体は手動の範囲内だとはっきり書かれている
0808デフォルトの名無しさん
垢版 |
2021/11/17(水) 12:26:39.90ID:mpgcjn44
一生懸命にC++を味方に引き込もうとする姿が哀れに思える。C++は全部プログラマが気にして細心の注意を
払い神のごとくコントロールする言語なのに、一緒にされたらC++プログラマーは嫌
0809デフォルトの名無しさん
垢版 |
2021/11/17(水) 12:39:06.76ID:C+g/MvKJ
RAIIでやりくりするほうがある種スッキリしてるし
それを欲する層は居なくはならないよ
0810デフォルトの名無しさん
垢版 |
2021/11/17(水) 12:50:33.28ID:Vki78NxX
>>803
追加解説サンキュー。
普通はそう考えるよなぁ。

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

>>807
まずははっきり書かれている部分を示してくれない？確認するから。
0811デフォルトの名無しさん
垢版 |
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. 」
0812デフォルトの名無しさん
垢版 |
2021/11/17(水) 13:09:29.01ID:R0jdljey
>>806
goのdefer文のがよっぽど楽だと思うけどね。
デストラクタみたいにオブジェクトに紐づくのは不自然なことが多い。
0815デフォルトの名無しさん
垢版 |
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は手動なんだ！うぇぇん！バーカｗ」
0819デフォルトの名無しさん
垢版 |
2021/11/17(水) 15:14:14.44ID:0sKaSg3R
>>802は別にGC起因の問題じゃなくて単なるシンタックスの問題だろ
メモリの解放とその他のリソースの解放を、GC言語ではレイヤの異なる別の問題として扱っているだけだ
C++やRustではそのusingに相当する言語機構を用いてメモリ解放の面倒も見なければならないわけで、本質的には負担が増えている
最近のバージョンのC#では using var r = みたいな記法もできるようになって記述負荷の問題は解決したが、そういう問題じゃないんだろ？
0821デフォルトの名無しさん
垢版 |
2021/11/17(水) 18:32:09.16ID:iuNg9UQr
そもそshared_ptr自体使わない。
new/deleteも使わない。
RAII、所有権と唱えると設計がすっきりする。
0823デフォルトの名無しさん
垢版 |
2021/11/17(水) 18:56:42.09ID:iuNg9UQr
>>822
HTML5仕様のパーサー、木コンテナ、ダブル配列ベースのTRIE木コンテナ、それら木へのイテレータ/アダプター、CSS Syntax Module Lv3仕様のパーサーなど書いた結論。
new/deleteすら要らない。
偉い人が言ってることは全部ほんとだった。
0825デフォルトの名無しさん
垢版 |
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が自動でメモリ解放するのは当たり前だけどもあくまでも手動メモリ管理の範囲内ということ
0826デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:02:17.52ID:iuNg9UQr
vector、listなどSTLのコンテナは基本的なストレージとして設計されてるそうで、実際、その他のコンテナはこの上に実装できる。
tree、ダブル配列ベースのTRIE木などをこれらの上に実装して不都合は無かった。
速度的にもmap、unordered_mapなどと比較するレベルで、普通に使える。
0827デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:07:40.05ID:iuNg9UQr
イテレータを使い分けることで、終了タグが現れる行きがかり順の走査と単純な木としての走査を行える二面性を持つHTML木も作ってみた。
単純な木として走査するならDOMのように見え、HTML文書として走査するなら（タグのバランスが取れていない）壊れたHTMLも扱える。
0829デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:11:35.74ID:iuNg9UQr
そういう作業をした結果、HTML5とは、インターネットエクスプローラーを倒すためにデザインされており、プログラミング的な合理性は全くないと理解した。
また、HTMLを簡単に扱えないようにするため、いろいろ詭弁を使いながら仕込みを行っている。
HTML5のおかげで、賢いベンチャーが現れてグーグルを倒すようなことを防げる。
0830デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:21:18.87ID:iuNg9UQr
R！A！I！I！
これですべて解決。
RAII強し。
0832デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:26:26.17ID:MZt3q0rg
>>831
例えばunque_ptrもメモリ解放を自動化していますがGCとは呼ばれませんよね
つまりメモリ解放の自動化とGCは別のことです
0834デフォルトの名無しさん
垢版 |
2021/11/17(水) 20:34:46.44ID:C+g/MvKJ
RAIIで無駄なくやりくりするのがC++の思想なんだろうね
スマートポインタもRAIIがもたらすリソース解除実行の一例で
ヒープメモリをデストラクタでdeleteしてるだけだから
0835デフォルトの名無しさん
垢版 |
2021/11/17(水) 21:40:20.88ID:MiIYKiV6
>>831
>>832は（今までのやり取りにもある通り）悪意を持って情報を隠すから気をつけろ。

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

自動で判断しないc++のunique_ptrはGCの機能とは言わんが、（仕様に従う限り）自動で判断するshared_ptrはGCの機能と言える。
0836デフォルトの名無しさん
垢版 |
2021/11/17(水) 22:09:03.50ID:eNp19Ga9
>>835
またゴールポストを移動させたの？
その「自動的に判断」「自動に判断」などは今までこのスレに一度も出て来ておらず誰も主張してきていない初登場の言葉
そしてその意味の定義がなされていないから解釈次第になる
0837デフォルトの名無しさん
垢版 |
2021/11/17(水) 22:12:01.05ID:SsdWlmrh
Rust 2021 Edition
0841デフォルトの名無しさん
垢版 |
2021/11/17(水) 23:08:50.98ID:iuNg9UQr
法律で禁止するべきと？
0842デフォルトの名無しさん
垢版 |
2021/11/17(水) 23:14:03.88ID:QI1gBPox
まだWikipediaとか不毛なことやってたのか
もうちょっとまともな文献を挙げてみると
リチャード・ジョーンズ「ガベージコレクション」
では参照カウント方式GCの具体例としてBoostのshared_ptrを取り上げて、トレーシングGCとの比較が行われている
著者はメモリ管理についての国際会議（ISMM）の創設者なので、少なくとも学会レベルではshared_ptrはGCの一形態として認識されていると考えていい
もちろん学会が世の中の全てではないから「俺の常識ではGCではない」と主張するのは自由だけど
0845デフォルトの名無しさん
垢版 |
2021/11/17(水) 23:49:51.44ID:C+g/MvKJ
GCはGCまかせのタイミングでいつかきっとメモリを解放できる
RAIIはRAIIオブジェクト破棄のタイミングで※1リソース※2を解放できる

※1 shared_ptrの場合は参照カウンタを見て
※2 shared_ptrの場合はメモリを
0846デフォルトの名無しさん
垢版 |
2021/11/17(水) 23:55:15.10ID:SsdWlmrh
shared_ptrがGCかそうでないかはどうでもいいからさ、
GCの動作有無をアプリ開発層のプログラマから制御できる次世代言語はどれよ？
0850デフォルトの名無しさん
垢版 |
2021/11/18(木) 07:15:04.87ID:5A0vzciY
99％のプログラマーはこんなアスペルガーの領域のことまで考えてプログラミングやってないと思う
0851デフォルトの名無しさん
垢版 |
2021/11/18(木) 08:11:30.53ID:Q5lW897P
>>836
ゴールポストは>>684から変えてないし、まともな異論も出てない。「手動メモリ管理」とかも>684を否定しているわけではないだろ。それとも>684はデタラメと主張するのかね？
嘘ばかりの歴史改竄主義者だな。

世間一般の認識は>>842みたいだから、>836の心の中のGCについては勝手にすれば？ 歴史改竄しないかぎりだけど。
0853デフォルトの名無しさん
垢版 |
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オブジェクトにも使用可能。
0854デフォルトの名無しさん
垢版 |
2021/11/18(木) 11:21:14.46ID:/He/baLS
>>823
否定はしないが賛成もしない
new を出来るだけ避ける様に心がければ delete の心配が無くなるのは当たり前
0856デフォルトの名無しさん
垢版 |
2021/11/18(木) 13:20:13.82ID:5Kqa+JGe
>>823
newを使わない要らないとはヒープを一切使わないという意味ですか？
それともC言語のように自分でmalloc等を用いてヒープメモリ管理を行うべきという意味ですか？
前者はそれら挙げている物のプログラミングが不可能だから後者の何十年も前に戻っただけですか？
0857デフォルトの名無しさん
垢版 |
2021/11/18(木) 13:51:24.01ID:+0r8+Axf
>>856
C++の標準ライブラリにあるstd::string、コンテナクラス、unique_ptr、shared_ptrなどを使っていればnewを書かずにヒープメモリを使うことができるし、shared_ptr以外はスコープを抜けたときに自動的にデストラクタを呼んでヒープを解放してくれる。
ちゃんとC++を使えばほとんどの場合手動でメモリ解放せずに済むよ。
0862デフォルトの名無しさん
垢版 |
2021/11/18(木) 15:13:07.47ID:5Kqa+JGe
>>857
しかし元の方は>>821でdeleteを使わないだけでなくshared_ptrも使わないとおっしゃっているのです
つまり解放をどうするのか問題が残ります
あとコンテナ自体の解放に加えて要素が値だけで構成されずポインタを含む場合はその先の解放も必要ですよね
0863デフォルトの名無しさん
垢版 |
2021/11/18(木) 16:00:24.60ID:5Kqa+JGe
>>858
ある程度の構造を持ったデータを扱う場合
RAIIではそのクラスのデストラクタでdeleteが発生しますよね？
>>823はdeleteも要らないと書いていますがそこはどうするのでしょう？
0865デフォルトの名無しさん
垢版 |
2021/11/18(木) 16:36:40.14ID:f69aBKlz
golangなんかだとbenchでB/opやallocs/opが取れるけど、他の言語はあまりメモリー量は重要視してないのかな？
最終的にはエネルギー毎のjoule/opとか出してほしいけど、IntelとAMDそしてARMで全然違うのはCOP21とかは
何も考えてない偽善だろう
0867デフォルトの名無しさん
垢版 |
2021/11/18(木) 18:07:16.31ID:dthIgn7Y
流れを踏まえると
C#はせっかくGCがあるのに
自分でいちいち手動のDisposeを描かされる

残念な言語(キリっ

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

>>821
> deleteも使わない。

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

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

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

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

mrubyの本も出た。
micro python, Lua の代わりに使う
0887デフォルトの名無しさん
垢版 |
2021/11/19(金) 05:13:09.95ID:DX593LKr
mrubyとか名前ダサくね？
信者になればかっこよく見えるの？
名前重要とかどこいった
0889デフォルトの名無しさん
垢版 |
2021/11/19(金) 12:27:45.87ID:fGKSbVlD
そんなこと言ってるとrustに別実装の処理系が出来た時にディスられるぞ
rustだからstainlessとか
0892デフォルトの名無しさん
垢版 |
2021/11/19(金) 13:55:37.85ID:XZPDRrte
GCある言語でもインスタンスの生成や参照切れで解放されることくらいは
知ってる必要があるんだが、それもまともにわかってなさげなやつで溢れてる。
0893デフォルトの名無しさん
垢版 |
2021/11/19(金) 13:56:15.69ID:eyeX0xyM
ださい拡張子
.cs
.ts
.ps
.gs
0894デフォルトの名無しさん
垢版 |
2021/11/19(金) 14:56:18.17ID:nTNvNEE2
>>892
誰一人まったく解放されないなんて言ってる奴いないと思うが、どこの世界線から来た人？
0895デフォルトの名無しさん
垢版 |
2021/11/19(金) 18:18:36.72ID:cPtoFLsh
>>886

class foo
{
　　~foo()=delete; // このdeleteのことを言ってる。
};
0897デフォルトの名無しさん
垢版 |
2021/11/19(金) 19:55:35.05ID:cPtoFLsh
>>896
ID末尾をxにしてるのは、C++とC#の両方を表現してるのかい？
0898デフォルトの名無しさん
垢版 |
2021/11/19(金) 19:57:08.72ID:cPtoFLsh
宣言のdeleteって言うから。
0899デフォルトの名無しさん
垢版 |
2021/11/19(金) 20:09:20.65ID:M2ROgxHD
>>898
流石にnew/deleteとdelete宣言は別物だろうなぁ。
同じ単語を使っているのはc++のケチ臭い用語の流用の結果だし。
0900デフォルトの名無しさん
垢版 |
2021/11/19(金) 20:52:12.15ID:cPtoFLsh
デストラクタのdelete自体も嵐を呼ぶ話題だけど。
0902デフォルトの名無しさん
垢版 |
2021/11/19(金) 21:11:17.06ID:cPtoFLsh
たぶんJavaの人じゃないかと思うんだよね。
0903デフォルトの名無しさん
垢版 |
2021/11/19(金) 22:08:12.78ID:CstSAS10
>>901
本体もGCと呼ぶかは議論が分かれそうだが
付属部分を連動GCすることだけを目的に本体が実体を無くしたものがunique_ptrだよな
0904デフォルトの名無しさん
垢版 |
2021/11/20(土) 00:19:22.26ID:OQv16NeR
自動変数もGCなのか？
0906デフォルトの名無しさん
垢版 |
2021/11/20(土) 08:44:52.28ID:V7jlhcsx
1. 昔も今もどっちも変わらない
2. GCもスマポもどっちも変わらない
3. 1も2も3もどれでも変わらない
0907デフォルトの名無しさん
垢版 |
2021/11/20(土) 11:42:49.09ID:NkWaDqk7
>>904
約一名にとってはそうみたい
0910デフォルトの名無しさん
垢版 |
2021/11/20(土) 16:24:03.02ID:lK9Ghq6L
Rustの悪口言ったやつ許さんから
0913デフォルトの名無しさん
垢版 |
2021/11/20(土) 18:07:02.96ID:OQv16NeR
バグを無くすにはGCじゃなくテストですよ。
0914デフォルトの名無しさん
垢版 |
2021/11/21(日) 10:14:13.30ID:UyY2TlzJ
ソースを読まなくてもできるテストは
不正アクセスと同じではないが似ている
0916デフォルトの名無しさん
垢版 |
2021/11/25(木) 08:38:48.33ID:KcP0JmbS
rustは少なくともCである程度のプログラムを書いてハマった経験がないと
この機能何のためにあるの？ってのがわからない
0917デフォルトの名無しさん
垢版 |
2021/11/25(木) 10:28:07.08ID:dqP+a0eJ
Rustを最近学んでるだけど、すぐに学習曲線やばい言語だということを納得した
おれはC++のスマートポインタらへん知ってるから、かなりマシなほうだと思うけど、
たしかにC/C++やってない人にはそうとうにキツそうだね

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

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

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

生ポインタ禁止(スマートポインタ強制)するだけでもいい感じになると思うけどなぁ。
0938デフォルトの名無しさん
垢版 |
2021/11/25(木) 19:34:59.70ID:6PNOZvLH
>>936
今となっては全てが自動的にスマートポインタ扱いとなっているRustを使えばよい話
しかもunique_ptrはコストゼロになっていて効率もいい
0939デフォルトの名無しさん
垢版 |
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++は違う、破綻しようが滅茶苦茶だろうが関係ない。使いたい人がその機能を使う
負の遺産だとも、クールではないとも異議は唱えないが、根本的なところが違う
0940デフォルトの名無しさん
垢版 |
2021/11/25(木) 20:11:54.48ID:mXEi3hQs
あわしろ氏もC++はオワコンと言ってる。
0941デフォルトの名無しさん
垢版 |
2021/11/25(木) 20:26:41.70ID:dqP+a0eJ
せやな
C++という言語自体というより、C++で作られた資産が負の遺産だと思っているよ
0943デフォルトの名無しさん
垢版 |
2021/11/25(木) 20:51:59.29ID:88pS2ZzI
スレタイの諸言語は限定した環境においてはRustに対して優位性があるけど
C++は過去しか優位性がないので仕方ないのでは
0945デフォルトの名無しさん
垢版 |
2021/11/25(木) 21:22:32.76ID:YKvzJ4Sm
誰もCが悪いなんて言ってなくね
C++だったらRustの方が無難と言ってるだけで
0946デフォルトの名無しさん
垢版 |
2021/11/25(木) 21:27:45.38ID:I+op7MmV
Rustになんか優位性ない。スレタイの諸言語に対してもそう、Swiftは参照カウントでボトルネックになる
ところを自前で管理可能だし、Nimは同じ参照カウントに切り替え可能だし、Golangは他にない超高速な
軽量スレッドを有している。 KotlinとTypeScript は知らんけど
0947デフォルトの名無しさん
垢版 |
2021/11/25(木) 21:37:57.24ID:lTzmbhqT
C++は難しいを通り越してユーザーに厳しい？というかピーキー？というかマニアック？な言語だと思う
好きな奴だけ使う言語
0948デフォルトの名無しさん
垢版 |
2021/11/25(木) 21:41:06.37ID:QrEUJ+3X
>>934
>c++は新しい書き方だけを強制できるような仕組みが必要

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

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

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

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

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

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

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

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

一度素直に受け入れれば、今までどんだけウンコードを書いてきたかが分かる。
0961デフォルトの名無しさん
垢版 |
2021/11/26(金) 08:34:53.72ID:GoGODfBQ
>>960
なら、「なぜ」の説明を強化することがRustの普及に不可欠ということだろ。
他人のせいにする暇なんてあるんですかねえ。
0962デフォルトの名無しさん
垢版 |
2021/11/26(金) 08:41:46.89ID:XtGzaRsE
普通に説明はあるだろ。それでもわからない人にまで普及させる義務なんてないしな。
0963デフォルトの名無しさん
垢版 |
2021/11/26(金) 10:06:14.10ID:5+U4u14D
>>960
むしろRustは非常に書きやすくて筋の良い言語と感じる
実際にプログラマー利用調査でもRustが愛され度No.1がこれで何年連続だっけ
プログラミング言語の中で一番好評であると調査データが出ている現実がある
0966デフォルトの名無しさん
垢版 |
2021/11/26(金) 11:09:43.97ID:STLLuOh7
最近Kotlinを少し書いたけどあれダメだな
Android以外に普及しない理由がよくわかった
0970デフォルトの名無しさん
垢版 |
2021/11/26(金) 16:12:16.13ID:pv19rM7a
11月TIOBEプログラミング言語人気ランキング、PHPの下落続く
https://news.mynavi.jp/article/20211109-2181586/

どっかの分けわからんサイトのLOVEデータ引っ張ってきて、ごり押しで「書きやすい」なんて言うから
バカは貶される。あえて言うなら業務や趣味ｗで使用してなくて初心者が「これから覚えたい」ぐらいの
指標なのに「非常に書きやすくて筋の良い言語」なんて気持ち悪い公開オナニーを始める
こういうやつはマジで迷惑だからRustに近寄らないでほしい
0972デフォルトの名無しさん
垢版 |
2021/11/26(金) 16:19:53.66ID:ZG1tAy2R
Stack overflowは初心者質問サイトみたいなもの、そもそも「非常に書きやすくて筋の良い言語」の
根拠がまったく示せていない。公開オナニーのうんこ名無しの張り付いてるスレ
0974デフォルトの名無しさん
垢版 |
2021/11/26(金) 17:55:40.26ID:2onFAjF8
え、Stack Overflowなんて聞いたことねーよ
そんなわけわからんサイトなぜ貼ったしｗｗｗ
0976デフォルトの名無しさん
垢版 |
2021/11/26(金) 18:15:17.74ID:E7I1X7f8
もう次スレ立てるな
0980デフォルトの名無しさん
垢版 |
2021/11/26(金) 19:49:06.65ID:o6j9/HV6
rustのシャドーイングのメリットが今一つ分からんな
新しい名前を考える必要がない
というけどシャドーイング前の状態に戻せないと
メリットがないような気がするが
0981デフォルトの名無しさん
垢版 |
2021/11/26(金) 20:36:21.93ID:3UDOk5VY
もう「非常に書きやすくて筋の良次世代言語Rust23」だけでええやろ、本スレで知識の披露も質問回答も
できない攻撃性の高いクズの植民地みたいなもん、他の言語の話すると荒らしだす
0983デフォルトの名無しさん
垢版 |
2021/11/26(金) 20:58:37.40ID:Ye0bskEh
>>980
元に戻す場合はシャドーイングすべきではないと思う
初期化の過程で値をBoxやMutexに包む場合や、
逆にBufReaderから中身のReaderを取り出す場合など、
所有権の移動を伴うときにシャドーイングされることが多い気がする

例えば
let x = ...;
let x = Box::new(x);
といったコードがあるときに元々のxはムーブされて使えなくなっているから
x_boxed みたいな別名をつけるのではなく x という名前を再利用することが好まれている気がする
0985デフォルトの名無しさん
垢版 |
2021/11/26(金) 21:31:21.70ID:3UDOk5VY
Pony言語とかアクターベースでErlangが元でORCAガーベージコレクションとか、box/ref/tag/val/isoとか
0986デフォルトの名無しさん
垢版 |
2021/11/26(金) 23:53:19.85ID:MbvsChzk
>>983
Resultエラー時は上へ投げればいいだけの時に?で外すのが最小例かな
for line in buf_reader.lines() {
　let line = line?;
　...
}
0990デフォルトの名無しさん
垢版 |
2021/11/28(日) 10:30:37.63ID:9xwjyQVv
>>988
単語を省略しない方が良いのか？省略していない言語は少ないと思うが。
0992デフォルトの名無しさん
垢版 |
2021/11/28(日) 11:47:01.16ID:y5HuhJRG
自明なら短い方が良い、名前大切を勘違いした輩がスコープが数行しかないのにダラダラ長いAuto変数名書いてたの思い出すわ
Dryを勘違いした輩が、共有しちゃ駄目な処理も全部入れたUtil定義してたり
Javaと名が付く系統から派生した輩はマジで碌なのが居ない
0993デフォルトの名無しさん
垢版 |
2021/11/28(日) 11:53:32.46ID:w5BI4f4u
fnは短すぎて俺もわかりにくいと思う
変数名は文化だと思ってるので言語によって変えてる
0994デフォルトの名無しさん
垢版 |
2021/11/28(日) 12:17:43.95ID:O4oXyxzb
ML系のようにfunならまだいい
0998デフォルトの名無しさん
垢版 |
2021/11/28(日) 13:11:08.58ID:w5BI4f4u
おっと天下のpythonの悪口はそこまでだ
>>> as=None
File "<stdin>", line 1
as=None
^
SyntaxError: invalid syntax
>>>
0999デフォルトの名無しさん
垢版 |
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を超えています。これ以上書き込みはできません。
ニューススポーツなんでも実況