Rust part16

**デフォルトの名無しさん** · 2022/06/27(月) 08:17:03.45

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part15
https://mevius.5ch.net/test/read.cgi/tech/1652347700/

**デフォルトの名無しさん** · 2022/09/11(日) 12:51:18.94

>>693
＞mutを付けずにletで宣言すると書き換わらない値として
＞書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか？というのが心配な点です

しねーよ。
組み込みだろーがそれは変わらない。
letついて束縛変数といわれようが変数は変数。

**デフォルトの名無しさん** · 2022/09/11(日) 13:08:43.20

今はしないけどそうなるような最適化は禁止されてないのでは

**デフォルトの名無しさん** · 2022/09/11(日) 13:49:03.04

コンパイル時に値が確定してないとtextセクションに書けないでしょ

**デフォルトの名無しさん** · 2022/09/11(日) 13:55:35.90

そっちは定数でconstだしそうなる
letはあくまでもimmutableな変数であり定数ではない

**デフォルトの名無しさん** · 2022/09/11(日) 13:57:25.52

コンパイル時に確定するような式なら最適化でありえるんじゃないの？

**デフォルトの名無しさん** · 2022/09/11(日) 14:07:54.90

どのように最適化されようが
constではなくlet x = ...ならば
let mut x = x; とムーブして書き換え可能
これは言語のレベルで保証される

そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう

**デフォルトの名無しさん** · 2022/09/11(日) 14:40:44.81

CloneとCopyについて
let mut bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<[u32; LEN], [ARGB32; LEN]>(bitmap)};
と
#[derive(Clone, Copy, Default)]
＆
let mut bitmap:[ARGB32; 16] = [ARGB32::default(); LEN];
で読み書きを
bitmap[0].red = 0x80;
let x = bitmap[0].red;
bitmap[0].green = x;
としてみたけど出力された読み書き部分のコードは同じでした。もっとでかい構造体じゃないとムーブかコピーかの区別は出来ないのかな

>>696
マジか。Rustでもパディングの問題がつきまとうのか。でも
>Accessing unaligned fields directly with e.g. packed.unaligned is safe however.
って事は.redとかでアクセスする場合はコンパイラが良きに計らってくれるのでアクセス境界の問題は起きないって事かな？
画像データのバイトやビットの並びなんてすでに決まっていてプログラムはそれに合わせるしかないのが普通でしょうし
勝手にパディングされても困ります

実は並行してCでも書いているんだけど構造体のパディングの制御は処理系依存らしくて移植性を優先すると
データは整数の配列で持って論理演算とシフトで分解、構築するコードになってしまってます

**デフォルトの名無しさん** · 2022/09/11(日) 14:49:25.24

そのような実装はしたくないわけですか

**デフォルトの名無しさん** · 2022/09/11(日) 15:13:19.03

どの言語でも同じ
Rustでも&mutでtransmuteしてもendian依存は避けられないな
let mut x = 0x01020304_u32;
let a = unsafe { std::mem::transmute::<&mut u32, &mut [u8; 4]>(&mut x) };
a[1] = 7;
assert_eq!(x, 0x01020704);
とlittle endianでは7の位置はこうなる

**デフォルトの名無しさん** · 2022/09/11(日) 18:54:24.82

このスレでよく出てくる μt ってなんなん？
音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの？

**デフォルトの名無しさん** · 2022/09/11(日) 20:25:15.55

自分も思ったけどブラウザによっては & mut がそうなるみたい

**デフォルトの名無しさん** · 2022/09/11(日) 20:27:57.44

>>708
そうなんだ。

**デフォルトの名無しさん** · 2022/09/11(日) 20:45:42.63

>>708
なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。

**デフォルトの名無しさん** · 2022/09/11(日) 21:25:51.88

HTMLの文字参照で& muがμ

**デフォルトの名無しさん** · 2022/09/11(日) 21:45:56.06

例えば
pixel.alpha = in[0].alpha;
pixel.red = in[0].red / 2;
pixel.green = in[0].green / 2;
pixel.blue = in[0].blue / 2;
out[0] = pixel;
と
red = 0xFF & (in[0] >> 16);
green = 0xFF & (in[0] >> 8);
blue = 0xFF & in[0];
red /= 2;
green /= 2;
blue /= 2;
pixel = 0xFF000000 & in[0];
pixel |= red << 16;
pixel |= green << 8;
pixel |= blue;
out[0] = pixel;
ではだいぶ見やすさが違うような

**デフォルトの名無しさん** · 2022/09/11(日) 21:47:41.04

>>704
パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ
x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする

今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね

**デフォルトの名無しさん** · 2022/09/11(日) 21:50:14.96

>>712
シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは

**デフォルトの名無しさん** · 2022/09/11(日) 23:45:21.14

Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で
相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし

>>713
そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし

>>714
読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして
全てインライン展開＆最適化されますかね？一つでもコールやブランチが残ったら速度が結構落ちるだろうし

**デフォルトの名無しさん** · 2022/09/11(日) 23:59:30.49

>>707
色んなブラウザで見てみたけど
&mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい

**デフォルトの名無しさん** · 2022/09/12(月) 00:37:31.19

&mut テスト

**デフォルトの名無しさん** · 2022/09/12(月) 01:00:12.66

>>716
ほー、chmateはワザとunescapeしてるのか？
5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな

**デフォルトの名無しさん** · 2022/09/12(月) 01:13:39.26

HTML等の文字参照を処理する場合でも
μt (＝ & m u ; t )が μt となるのは正しいけど
&mut (＝ & m u t )が μt となるの間違いだからこれはバグと思われる

**デフォルトの名無しさん** · 2022/09/12(月) 02:30:39.40

あ、たしかにバグっぽい・・・

**デフォルトの名無しさん** · 2022/09/12(月) 06:45:23.29

文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
良し悪しは別にして html を扱うブラウザではそれほど珍しくはない
個人的には余計な事すんなとは思う

**デフォルトの名無しさん** · 2022/09/12(月) 07:14:45.53

これはmateのバグです
& x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです

**デフォルトの名無しさん** · 2022/09/12(月) 07:33:21.32

&mut と書けば良いかな
テスト → &mut

**デフォルトの名無しさん** · 2022/09/12(月) 07:34:32.06

& amp ; amp; を空白なしで書き込んだら & に変換されてしまった
実体参照複数回展開しているのかな
&

**デフォルトの名無しさん** · 2022/09/12(月) 08:15:16.27

ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね
ガワ作って入出力を完全に外部に出さないとコードがみんな消えてしまうのは不便です
最適化レベルによる変化とか全然確認出来ないし

**デフォルトの名無しさん** · 2022/09/12(月) 08:36:58.55

ちょっと意味がわからない
こうなるはずだから困ることはないと思うけど

・最適化によってRustが定めている意味が変わることはない
・pub宣言しているものは中で呼ばれていなくても単体コンパイルで消えることはない
・pub宣言されていないものは中で呼ばれていなければ今後も誰からも呼ばれないためwarningが出て消える

**デフォルトの名無しさん** · 2022/09/12(月) 10:25:58.86

genericな関数だと呼び出し元がないとコード生成されないとか？

**デフォルトの名無しさん** · 2022/09/12(月) 12:04:36.56

その場合でも実際に使う型々でtestを書くだろうからcargo testで確認できるでしょ

**デフォルトの名無しさん** · 2022/09/12(月) 12:46:09.29

>>726
ありゃうちの環境の問題か。pub付けただけじゃ関数丸ごとなかったことにされる
pub extern "C"でRust外の入出力にしてようやく消えなくなる
もうちょっと調べてみる

**デフォルトの名無しさん** · 2022/09/12(月) 14:30:52.03

>>729
ちなみにターゲットはbinと(r)libのどっち？
binならpubでも消えるかも

**デフォルトの名無しさん** · 2022/09/12(月) 19:11:31.91

>>730
変更してみた。staticlibだとpub付けても消える。rlibなら消えないようだ
とりあえずrlibにしておいてある程度形になってきたら変更すればいいか
コード自体はどっちでも大差ないだろうし

**デフォルトの名無しさん** · 2022/09/18(日) 01:08:32.32

[u32; LEN]と[ARGB32; LEN] の件、アラインメントが違うからtransmuteの時点でUBだけど

**デフォルトの名無しさん** · 2022/09/19(月) 02:33:25.46

Tauriで動画プレーヤー的なのを作るサンプルってどっかにある？
ただ再生するデータは既存のmp4ファイルなどではなくRustプログラムから渡したい
あと再生、停止、コマ送り、シークなどの基本的な機能は実装したい

**デフォルトの名無しさん** · 2022/09/19(月) 07:48:35.44

TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ？
そして既存のWeb技術を活かせるのがTauriの利点だろ？
そうならば例えばhls.jsなど既存の好みの動画配信再生フレームワークを使えばいいだけじゃないか？
Webサーバーサイドやったことあるならばフロントエンドからファイルに見えているものは本物のファイルである必要はなくサーバーサイドが算出していれば十分だろ？

**デフォルトの名無しさん** · 2022/09/19(月) 12:27:41.81

>>734
>HLS
ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない
特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど
再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中

ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか？なんか無駄に実装量が増えるけど

**デフォルトの名無しさん** · 2022/09/19(月) 13:11:44.57

その手のやつでオーバーヘッド減らすならOS毎にネイティブ実装するしかなくない？

**デフォルトの名無しさん** · 2022/09/19(月) 18:38:49.00

なんとかtauri使うにしてもJSやらWASMやらで動画レンダリングするようなもの作らないとだめそう

**デフォルトの名無しさん** · 2022/09/19(月) 18:45:15.20

実装を追加させない方法ってありますか？
別個に渡されたふたつの型が同じであるという制約を付けたいという目的で
以下のようなトレイト Same を定義した場合、実装を追加できてしまうと破綻してしまうので、
なんらかの方法で制限できるだろうかという疑問です。

pub trait Same<T> {}
impl<T> Same<T> for T {}

// 使用例
pub fn foo<T, U>(x: T, y: U)
where
T: Same<U>,
{
}

ちなみに目的を上述しましたけども実際には目的というよりは題材です。
つまり具体的な用途は考えておらず、質問はあくまでも「実装させない方法があるかどうか」です。

**デフォルトの名無しさん** · 2022/09/19(月) 19:32:04.41

trait Sealed {}
pub trait Same<T>: Sealed {}

**デフォルトの名無しさん** · 2022/09/19(月) 21:19:03.69

https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed

**デフォルトの名無しさん** · 2022/09/19(月) 21:29:04.18

ふたつの型が同じという制約を付けたいなら
TとUじゃなくTとTにすればいいじゃんか

**デフォルトの名無しさん** · 2022/09/19(月) 21:34:13.52

>>738
達成したいことが特にないらしいからなんとも言えないけど enum を使っても近いことはできるんじゃないかな。

enum Same{SameA(型A),SameB(型B)}

みたいにしてやれば、Same 経由で扱う限り実装は増やせないぞ。

**デフォルトの名無しさん** · 2022/09/19(月) 22:48:26.11

>>739-740
実装を追加させないテクニックのひとつとして有用ですし紹介はありがたいです。
しかしそれだと Sealed を実装した型だけにしか使えず、 >>738 で示したような汎用的に型を比較するトレイトには使えないですよね。
この Same のように機能するトレイトに実装を追加させないというのは前提と考えて欲しいです。

>>741
そういうレスが付くことを避けたいから最後の文をつけたつもりなんですが……。
Rust の初心者として様々な言語機能を理解したいという立場で疑問に思った部分を抜き出し、
説明のために前提条件を設定したのであって、前提条件の部分自体は解決したい課題ではないです。

いわゆるXY問題というものの存在は承知しておりますので
解決したい大元の問題を示さないというのがモヤモヤするだろうなというのはわかります。
わかりますが、大元の問題というものはありません。
この範囲で完結するパズルだと思ってください。

**デフォルトの名無しさん** · 2022/09/20(火) 00:14:22.92

2つの矛盾してる要求を同時に実現は無理だわな

**デフォルトの名無しさん** · 2022/09/20(火) 00:42:08.53

impl Foo for Tが存在する時点で他の型にFoo実装しようとするとconflictしなかったっけ

**デフォルトの名無しさん** · 2022/09/20(火) 00:43:28.04

fundamentalな型に一通り実装しておけば良さそう

**デフォルトの名無しさん** · 2022/09/20(火) 00:48:25.82

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=02e7851289dd00c9ffc8679ad68644d9

**デフォルトの名無しさん** · 2022/09/20(火) 00:50:06.23

fundamental云々はcoherent ruleの話でconflictとは関係なかったわ

**738** · 2022/09/20(火) 01:17:29.77

なるほど、 C++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。
&T とか &mut T とかも先に実装しておけば追加の余地をなくせると。
&T とか &mut T とか以外にどういうのがありえますかね？

**デフォルトの名無しさん** · 2022/09/20(火) 01:40:45.09

>>743
Sealedも<T>にすればいいんじゃないの
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dadd7e289ec4e5bb9746015ac093a9bc

**738** · 2022/09/20(火) 01:53:09.66

>>750
ありがとうございます。
言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。

**デフォルトの名無しさん** · 2022/09/20(火) 18:26:27.74

「Linux」、バージョン6.1でRustを導入へ--トーバルス氏が明言
https://japan.zdnet.com/article/35193491/

**デフォルトの名無しさん** · 2022/09/20(火) 20:25:26.21

>>752
いいね
ここ最近で一番いい知らせだわ

**デフォルトの名無しさん** · 2022/09/20(火) 20:46:56.46

今のところデバドラだけという話だけど
基幹部分の新実装をRustで作りましたという
人が絶対現れるからそのときどうなるだろ

**デフォルトの名無しさん** · 2022/09/20(火) 20:51:48.09

誰もvoldemort typeの名を呼ぼうとしない

**デフォルトの名無しさん** · 2022/09/22(木) 02:33:16.78

MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて
非GC言語が必要な状況ではRustを使うべき時だ」ってツイートしてるけど
Visual StudioでもRustが最初からパッケージングされてるようになるのかな

**デフォルトの名無しさん** · 2022/09/22(木) 09:05:24.01

https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に

**デフォルトの名無しさん** · 2022/09/22(木) 13:36:58.59

>>756
MSがRustの開発環境に投資するならVSCodeのエクステンションじゃない?
いまさらVSに対応言語を追加する気はないでしょ
どう考えてもWindowsユーザーは少ないだろうし

**デフォルトの名無しさん** · 2022/09/22(木) 19:38:28.16

>>756
マーク・ルシノビッチ氏、Microsoft AzureのCTOなのか。
インサイドWindowsにはお世話になったわ。

**デフォルトの名無しさん** · 2022/09/23(金) 05:18:56.24

Iteratorに対するIntoIteratorのように
Futureに対するIntoFutureということか
しかも.awaitに対して自動適用だからもっと効果が大きいか
非同期を返すビルダーに対してFutureを返させるためのビルド完了指示メソッド呼び出しが不要となる

**デフォルトの名無しさん** · 2022/09/23(金) 08:24:08.00

Rust analyzerが優秀過ぎてMSが入る余地なさそう
PythonがMS Storeから落とせるみたいにインストールが楽になるとかならありそう
VSに導入されたらそれはそれで面白いんだけど.Net言語との連携が強化されないと旨味がないな

**デフォルトの名無しさん** · 2022/09/23(金) 08:29:43.60

Rustからから.Net?
意味ないやろ...

**デフォルトの名無しさん** · 2022/09/23(金) 10:08:58.99

既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとなる可能性もあるので意味はある

**デフォルトの名無しさん** · 2022/09/23(金) 10:43:28.96

Rust/Cliとか余計なもの作られそう

**デフォルトの名無しさん** · 2022/09/23(金) 12:31:56.94

>>758
VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな

**デフォルトの名無しさん** · 2022/09/23(金) 17:48:32.43

>>762
書き方悪かったわ
Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった

GoのCGoみたいな仕様だったら色んな意味で面白いと思う

**デフォルトの名無しさん** · 2022/09/23(金) 18:02:01.54

rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか？
編集を破棄して保存前の状態にしたい時があるので、できれば自動で保存したくないのです
Vim系プラグイン等を入れていれば無限に戻せるのかもしれないものの、Vimが使えない身としては困ってしまいます

**デフォルトの名無しさん** · 2022/09/23(金) 18:02:58.63

>>766
ああそれならありだな
まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな

**デフォルトの名無しさん** · 2022/09/23(金) 18:04:41.93

>>767
まあ普通はGitを使うからね

**デフォルトの名無しさん** · 2022/09/23(金) 18:05:33.15

C#も.Netも全く興味ないので知らないが
PythonでもJavaScriptでも何でもRustで作ったライブラリなどを簡単に呼び出すことができる仕組みがそれぞれ整えられている
既存のものの置き換えは無意味だが新たに作られるものはRustで書くことが増えている

**デフォルトの名無しさん** · 2022/09/23(金) 21:26:00.89

repr(C)でCのフリしたRustじゃなくて、俺はありのままのRustが動いている世界線が見たいよ

**デフォルトの名無しさん** · 2022/09/23(金) 21:26:44.38

>>769
でも、破棄ならコミット後の状態にも戻せるぜ？

**デフォルトの名無しさん** · 2022/09/23(金) 21:42:44.57

>>771
ABI安定化するまではFFIでextern "C"は避けられないよ

**デフォルトの名無しさん** · 2022/09/23(金) 21:53:19.36

>>773
そんなことすべきでない
自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト
外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい

**デフォルトの名無しさん** · 2022/09/23(金) 23:40:33.31

双方でマーシャル/アンマーシャルが必要になって無駄だよね

**デフォルトの名無しさん** · 2022/09/23(金) 23:55:09.24

なるほど

**デフォルトの名無しさん** · 2022/09/23(金) 23:58:10.15

対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない
他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない

**デフォルトの名無しさん** · 2022/09/24(土) 00:06:07.91

やっぱエアプの複オジはわかってないなぁ

**デフォルトの名無しさん** · 2022/09/24(土) 00:11:50.36

>>774
pubなitemのABIに最適化関係ある？
なんかと混同してない？

**デフォルトの名無しさん** · 2022/09/24(土) 00:14:18.76

もしかして repr(Rust) のこと言ってる？

**デフォルトの名無しさん** · 2022/09/24(土) 03:05:40.90

Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう
結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう

**デフォルトの名無しさん** · 2022/09/24(土) 08:50:49.84

C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの？

**デフォルトの名無しさん** · 2022/09/24(土) 09:11:44.18

>>781
dylibの場合pubは大いに関係あるよ

**デフォルトの名無しさん** · 2022/09/24(土) 09:15:16.80

ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ

**デフォルトの名無しさん** · 2022/09/24(土) 09:26:53.29

>>782
名前をプログラマが決められるからだよ

**デフォルトの名無しさん** · 2022/09/24(土) 09:44:37.12

>>782
むしろCは決まってるの？
決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/24(土) 10:38:04.73

近年になって作られた高速リンカ mold の作者の話でも、
文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。

C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし
どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、
結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が
解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。

**デフォルトの名無しさん** · 2022/09/24(土) 11:00:33.46

CはCPUベンダーが呼び出し規約を文書化してるよ
moldの話はELFやリンクに関連する話では
確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う

**デフォルトの名無しさん** · 2022/09/24(土) 11:33:36.58

AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ？

>>786
呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ

**デフォルトの名無しさん** · 2022/09/24(土) 13:14:15.81

>>789
そこでいう実装依存ってプラットフォームごとの差違のこと？
それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの？

**デフォルトの名無しさん** · 2022/09/24(土) 14:25:21.27

cdeclとかstdcallみたいなやつ？

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/24(土) 16:06:51.67

>>791
その段階ではあまり曖昧さはない。
リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、
その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。
アーキテクチャによって扱いを変える必要がある場合もあるし。

**デフォルトの名無しさん** · 2022/09/24(土) 16:24:43.84

>>792
コンパイラがリンカに渡す情報って統一規格があるの？

**デフォルトの名無しさん** · 2022/09/24(土) 17:05:25.99

>>793
別に統一されちゃいないがELFとかPEとか

**デフォルトの名無しさん** · 2022/09/24(土) 17:10:20.79

じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは？

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/24(土) 17:36:26.33

>>795
ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。
ただ現実には全てが正しく実装されているわけではなく、
場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。
仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。
そういう歴史的負債がどんどん積み重なってわけわからんようになる。

**デフォルトの名無しさん** · 2022/09/24(土) 19:08:36.35

ARMの規約
https://github.com/ARM-software/abi-aa

**デフォルトの名無しさん** · 2022/09/24(土) 22:13:22.85

元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ
LLVMがよしなにやってくれるのでは