Rust part9
レス数が950を超えています。1000を超えると書き込みができなくなります。
メンバの配置が固定だと移植性も下がるよね
パフォーマンスの低下くらいだったらかわいいけど
下手すればバスエラーで落ちる Cの常識がどこでも通用すると思ってると別の言語でも怪我しそう コンパイラに全て任せればいいって考えのやつのが実際は事故ってるがな。 何に怒ってるのかよく分からないけどコンパイラによる構造体レイアウトの最適化がデフォルトオンになってるのがそんなに気に入らないの？ >>854
それは言語の問題なのか、コンパイラの問題なのか、何が事故ってるの？ ていうかCコンパイラのアラインメントだって最適化の一種じゃ？ そんなに気になるなら、フォークして、
デフォルトの挙動が違うrustを作れば済む話じゃないの？ 最適化でunalignedになって落ちるならコンパイラのバグなんだから直せばいいし、
手動であらゆるアーキ向けにパディングを調整するよりよっぽどいいと思うけどな。 メモリレイアウトの話まだ続いてるの？
C++でダメなところ潰して制約強めでバグ出にくくしようって言語で、コンパイラが信じられないと言われてもコンセプトが違うとしか C++でダメなところ潰して制約強めでバグ出にくくしようってのと、
コンパイラが信じられないからコンパイラ設計を楽にしようってのは別に矛盾しないがな。
頭悪すぎ。 コンパイラ設計を楽にするって、例えばどういうこと？ ここまでの流れでコンパイラがバグるほど難しい事してないと思うけど。何を心配してるの？ 何が問題なのかiefoneか何かで実例出して欲しいな 問題になるのは外部リンゲージな関数で構造体を渡すときだと思うが
コンパイルした後リンクするみたいな本番行為ってiefoneできるんでしたっけ ウィンドーズのAPIの構造体みたいにメンバの数が異なる構造体のシリーズで
先頭部分は同じレイアウトであって欲しい、みたいな要請がある場合は
いかに自動レイアウトの規則が厳格に決まっていても問題を生じるし、
テストで見つけろといっても限界がある
メンバ数3、4、5はOKだった！→５６億年後に弥勒菩薩が6番目のメンバをboolにしたらすべて崩れ去った、みたいな それとも何かねここで言うテストというのはコンパイラの
自動レイアウトするロジックを見通したホワイトボックステストで
カバレッジ100%を目指せというのかね？ かなり減る64 bit整数m個とbool m+1個の構造体で#pragma pack(〜)とかしない場合
順序依存で8*m + 8*(m+1)バイトになるか8*m + ceil((m+1)/8)バイトで済むかの違いがある
引いたらどれだけ減ったかﾜｶﾙ C++だって処理系によってABI違って互換性無いのになに寝ぼけた事言ってんだ状態 ﾋｴｯ…日本語でどづぞ
>>877
処理系がABIを決めるケースはまれ
宇宙誕生以来一桁あるかどうか メーリングリストでそれらを主張してみてはどうか？ここで言ってもrust下げとしか見られない さっぱりわかんねえんだが、
＞先頭部分は同じレイアウトであって欲しい、みたいな要請がある場合は
こんなクソみたいな要請がある案件の場合はrepr(c)でいいんちゃうん？ ｽﾏﾝ>>878はstdcallを念頭に言ったがcdeclはC言語処理系によって決まったと言ってよいかもしれませんねーorz
stdcallの発祥がWindowsとPascalのどちらが先なのかは知りま栓、
>880
>こんなクソみたいな要請がある案件の場合はrepr(c)でいいんちゃうん？
禿げしく同意 >>871
言われてみれば確かに。
alignmentはCPUのBIT数が同じであれば大体同じなので、自動でやってくれもよい
場合も有るが、順序まで変えたのでは困るな。 repr(C)をつけるのでは駄目な理由は誰も言えないのか おじいちゃんが今際の際に｢repr(C)は使うな…ｶﾞｸｯ｣って言ってたんよ… 不満があっても使い続ける必要があるなら、
フォークしちゃえばいいじゃん。
もやもやしつつ使い続けるのは、良くないよ。 C/C++をいまさらフォークしたところで誰も見向きもせず
個人で使うだけで消えていくだけだろうが
rustなら「おっ、おれもこういうのが欲しかった!」
ってやつがむらがってきてワンチャン有名なれる・・かも？ >>887
一貫性のあるc--ができたら可能性あるよ。 >>885
同じおじいちゃんが原理主義者になるなってのも言ってただろうに。 Cargo.tomlかなんかでデフォルトのreprを設定できればいいんすか？
俺は要らんけど repr(C)がついてないデータ型に警告出すようなlint書いてclippyにpullreq出せば良いのでは 別に
構造体XのメモリレイアウトをRustのデフォルトとすべきなのかrepr(C)で扱ってほしいのか（あるいはその他か）は
構造体Xを定義したときに定義した人の意向で決まるから何の問題も無い
別の人が構造体Xを間違ったメモリレイアウトで解釈するプログラムを書く危険性は
（わざとそうするのでもない限り）無い 、と思うんだけどrepr指定が異なる構造体はちゃんと別の型とみなされるの？
つまりrepr(C)のメモリレイアウトな構造体を、（例えば）repr(PACKED)なメモリレイアウトな構造体を引数にとる関数に
渡せてしまうとかあると悲劇なわけだが
Rust使ったことないからよくわからないので教えてくだちい、 >>894
一つの型には一つしかrepr指定できないから指定を変えたければ別の型にするしかないよ
unsafeなtransmuteで強引に変換することは可能だけど、それは当然変換した人の責任 >>874
組み込みの場合、rustのランタイムの大きさ考えたらその程度じゃ全然埋まらないんだが。。
結局まともなユースケースを考えてないんだろうね。 stdがでかいって話かな？
なんかそれも問題になって対応策はあった気がするけど デフォルトでは利便性やリンクの高速化のために大きくなってるけど
組み込み用途ならちゃんと最小化する方法はあるし
Cと同程度まで縮むよ >>896
下記の記事の Executable sizes の節で実行ファイルのサイズについてCとの比較を考察してた
サイズ削減する方法も書いてあったよ
https://kornel.ski/rust-c-speed ちょびっとだけどついにlinux-nextにrustで書かれたコードが入ったか >>896
組み込みデバイスでrustを使いやすくしようとしてるワーキンググループあるから
どういうところで不便に思っているのかコメント寄せてあげたら良いのでは
https://github.com/rust-embedded/wg
issueでコメント募集してるよ 依存しているクレートが多いとビルドが長い、いい加減にしろ。なんじゃこりゃ >>901
だから考えてるスケールが全然違うっつーの Rust の実行ファイルが大きくなりがちなのは何でもかんでもスタティックリンクする文化であって、
そうしてでもうんざりするような (実行時の) 依存関係に悩まされたくないという話なので、
不要なもので肥大化しているわけじゃないよ。 本来必要なものがあるだけ。
もちろん制約の大きい組み込み環境でごく基本的なライブラリすら制約してまで
大きさを削ったら使い勝手は悪いだろうけど、
それは Rust に限った話でもない当たり前のことだし。
メモリが数キロバイトとかいうレベルだったら (少なくとも現時点では) Rust が不向きというのはそうかもしれない。
そんで特に Rust を使いたいというケースでもない。 >>906
具体的に言語化できる能力あったらこんなとこで愚痴垂れてないでしょう Linuxのディストロだとなるべくダイナミックリンクにするようにしてると思うんだけど
Rust製ツールとその方針の相性悪い気がする Q. Rustの倒し方を教えて下さい
A. まずデータセンターを燃やします
フランスのデータセンターで火災…『Rust』に復元不可能なデータロストが発生するなど大規模被害に発展 | エンタメウィーク
https://ent.smt.docomo.ne.jp/article/8989583 Rustってなんか日本人的にわびさびっぽい名前でいいよな そこんところは golang とか rustlang とか書く風習が出来てるから
たいした問題ではないんだが、 C のことを clang とか書き始めるやつが出てきてクソッタレという感じ。
よそでどんな習慣が出来てもいいけど変な汚染するなよな〜〜という。 LLVM ClangはふつうClangて書かない？ Clang は Clang のことなので
C のことを Clang っていわれると困るって話 >>909
というよりその方針だとsoのバージョン非互換で問題が起きて大変なので
GoやRustなど最近の言語はダイナミックリンクを避けている。 >>917
ディストロがビルドして配るバイナリの話だからバージョン非互換は関係ないのでは
非互換が問題になるならソースにパッチ当てられる訳だし
goも同じ問題があるというのはそうだけど >>919
そもそも最近はディストロのパッケージ管理システムに乗りたくなくなっているのでは？いろいろなディストロのいろいろなバージョンに対してバイナリを提供すること自体が大変で。
Gentooやってると依存関係ミスっててコンパイルこけるとかよくある。
（そういう意味でもGoやRustはかなりコンパイルに失敗しづらくて安心感はある）
退化している感もあるけど、GitHubで全ディストロ対応のシングルバイナリ配るのが結局楽だった、という感じなのかも。 場合によっては違うバージョンのライブラリが共存することもあるし
ファイル名のルールでどうにかしたりはすごく面倒
近頃はコンテナにまるごと突っ込むとか言った解決法も取れるが、
それなら全部スタティックリンクしたらええやんというのは
順当な方針だよな パッケージのバージョン管理とかRustは最近のnpmばりによくできてるんじゃないの
知らんけど >>921
gcc コマンドの実態が clang の環境が
存在するのでそれを茶化したジョークだと思う Ruby, Python, Rとか言語独自のパッケージ管理システムもありつつ
同時にディストロのパッケージ管理システムにも有名ライブラリだけは乗ってたりして
なんか二重管理みたいな変な事になってる 開発環境が用意するパッケージ管理は開発環境の管理だし
ディストリビューションの管理は実行環境の管理なんだけど、
ライブラリが実行環境なのか開発環境なのかは不可分な部分もあって単純に二分できんのよ。
C/C++ のライブラリのパッケージ管理が発展してないのは伝統的に
ディストリビューションのパッケージ管理に全力で乗っかる文化があったからで、
モダンな開発環境は分けようとしてかえってややこしくしているような気もする。
元々あった問題があぶりだされただけかもしれんけど。 まあlibcのバージョン違いで困った経験あると、スタティックリンクはやむ無しって思うけど。 >>913
コンパイラをclangという名前にしてしまったAppleが馬鹿なだけ。
ライバルにMSのcl.exeというものが30年ほど前からあるだけでも
ややこしいのに。 >>926
C/C++全盛の頃はコードを書く人と使う人が一致してることが多かったから問題なかった気がする。
自分の環境さえ正しくセットアップすればそれで問題ないという。
今みたいにGitHubでコード共有するのが当然って世界だと違う環境でビルドするのが困難ってのはきつい。
OSSのC++ライブラリを使おうとしたときに、作者と違うディストリビューション使ってる場合、ほぼ確実になんらかのトラブルにはまる印象だなぁ。 てか低レイヤー依存のパッケージは言語パッケージ管理じゃ扱いづらいだろ。 >>928
自分の開発環境に cl.exe があるのを見つけて
「あれ？ Common Lisp なんか入れたっけ？」って思ったことがある。 Rustと関係ない雑談はそろそろよそでやって下さいね 次世代言語21 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1587276362/
あっちのスレの流れの中に投下するものがこっちに誤爆して話題が続いてるだけだぞ 親善試合のプレー中でもないのにパンチを繰り出し、歯を折る韓国人の本質 >>939
証明論関係はプロトコル検証なんかには使えるかもね。 PDA以上の機械はどうやって機械的に証明したらいいんじゃ…… ZDNet Japan: トーバルズ氏が考える、LinuxにおけるRustの居場所とは.
https://japan.zdnet.com/article/35168533/ >要するに、Linuxの記述言語がCからRustへと変わる日は当面の間やってこないだろう。その一方で、Rustベースのプログラムやドライバーをユーザー空間で実行するということに対する関心は高く、それに向けた動きは数多くあるため、いつの日にかLinuxというOSでRustベースのカーネルが採用されるだろう。
まあ当たり前の結論だわな。 Javaやpythonのようなバブルは無いだろうが一定の需要はあるだろう 競技プログラミング分野で謎の注目を集めてるよRust
短時間とか早解きが重要なコンテストでは雑に書けないので使いづらいが、長期間のコンテストでは重宝されてる
強い人たちが使ってるのもあって レス数が950を超えています。1000を超えると書き込みができなくなります。
