【超高速】C/C++に代わる低級言語を開発したい 8 (364ﾚｽ)
上下前次1-新
1(10): 2012/08/23(木)23:03 AAS
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。
しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。
◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 7
2chｽﾚ:tech
265: 2015/11/11(水)11:53 ID:iOpec/0o(1)調 AAS
型無しのオブジェクト言語って言えばluajitがかなり高速なんだよな、確か。
あれの仕様を上手く転用できないかな。
266: 2015/11/11(水)20:22 ID:1hY3wyl+(1)調 AAS
多分スクリプトとアセンブラの悪いとこ取りじゃね
267: 2015/12/14(月)21:02 ID:LOQs7wcg(1)調 AAS
Rustいつのまにかstableリリース出てたのか・・・
Swiftみたいな負の遺産に塗れたクソ言語に比べりゃ大分>>1の理想に近いと思うんだけど
モジラってOSSの見切り早いし将来性が不安だわ
268: 2016/04/08(金)01:45 ID:sej0xQjF(1)調 AAS
void*最強って話か？ｗ
コンパイラが勝手にトレードオフして機能の一部をFPGAに突っ込んでくれよ
269: 2016/05/24(火)08:42 ID:67ul01kR(1)調 AAS
高速とは無縁だけど多倍長整数ってあるよね
これをビット単位でやるの、管理も緩く1ビットで1バイト使って管理
速度で無いけど全部の計算表現できるよね
文字列とかは考慮してないけど
色々考えた結果、変数の精度、byte,word,duble word,q...
ここら辺がいかにCPUの効率都合に合わせた制限だってよく判る
制限して精度に条件が付いても効率と速度が欲しいって言う
たった1ビットの多倍長数が扱えるだけで何でも表現できるなと思った。ｗｗ
270: 2016/05/24(火)15:58 ID:AJNPSyjI(1)調 AAS
せめてBCDにしれｗｗｗ
271: 2016/06/02(木)01:23 ID:RwzROqD7(1)調 AAS
何で10進数にしたがるかね
272(1): 2017/03/25(土)08:50 ID:Wiqnaowk(1)調 AAS
RustがC++に並ぶぐらい速くなってるみたいだけどRustのサブセットみたいなの作ったら良いのかね
273: 2017/04/03(月)00:12 ID:Eo4f9wsY(1/2)調 AAS
修理するより買い換えた方が安いって話は多いが
もはや解読不可能になったコードのメンテナンスに金は出すくせに
新しく作り直すのはNGってのは恐ろしいな
大手では比較的作り直しもするようだが
274: 2017/04/03(月)00:14 ID:Eo4f9wsY(2/2)調 AAS
もしあらゆる面でC++に勝る言語が出来たとしても、それが流行るかどうかは怪しい
275: 2017/04/03(月)00:53 ID:OlsWZk+G(1)調 AAS
>>272
なんでサブセット？
276: 2017/08/25(金)04:46 ID:QVMMnsrU(1)調 AAS
ネタがないんだね
Cに代わるっておそらく劣化Cになるだろうし
C++は現状仕様が巨大過ぎて大変な状態らしい
最後は、ライブラリーを移植するとき仕様差による移植性の低下をどうカバーするか問題がでる
(ライブラリーなんて一から書いてられないから)
ー＞ 結果現行のC++でも良いじゃん
設計とかコード書くときの作法が問題じゃねーのみたいに収束するのかな
あとは、コードの様子を解析するツールやAIっぽい機能を備えた解析などを行うアシストツールが必要になりそう
10進数の需要って金銭関係や丸め切り捨ては四捨五入で行いたい方面に需要があるんかな、やっぱ
277(1): 2017/08/25(金)11:22 ID:KodDhcxm(1)調 AAS
最近のC++は何を勘違いしたか高級言語気取っててウザイ。
278: 2017/08/25(金)21:39 ID:BZOsNf+t(1)調 AAS
高級っぽく見える言語だな
279: 2017/08/26(土)11:55 ID:lejZryYl(1)調 AAS
トンキンではC++関係者は不審者に見えるらしいw
280: 2018/03/25(日)14:11 AAS
>>3
>◆新言語でのリソース管理方針◆
>
>・確保したリソースを明示的に後始末しなくても問題が発生しない
>・何らかのメリットのために確保したリソースを明示的に後始末してもよい
こういう魔法みたいなことってどうやったらできるんだろうね
もちろん効率重視なのは言うまでもない前提条件として
数十〜数百マイクロ秒単位で使用元・使用先スレッドがガチャガチャ入れ替わる環境で
281: 2018/05/23(水)20:03 ID:Au5e7VGg(1)調 AAS
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
BTGPU
282: 2018/07/05(木)01:37 ID:RfoszcD2(1)調 AAS
DKB
283: 2018/10/20(土)20:00 ID:YPDT0Cqq(1)調 AAS
Cは8進10進16進数が扱えるのに、何で2進数が扱えないんだろう。
ちょっとの工夫でどうとでもなるけど、やっぱ標準であると嬉しいなあ。
284: 2018/10/21(日)14:55 ID:YTn6F4Fk(1)調 AAS
16進数の方が分かりやすいからじゃないの
1010000とか書かれても1の位置がどこかすぐに分からないし
0x50なら一目で分かるけど
285: 2018/10/21(日)17:25 ID:3rYBWp0g(1)調 AAS
gccはじめメジャーなコンパイラなら大抵は2進数リテラルは扱えるから
よく使う処理系基準でいいでしょ
286: 2018/10/21(日)20:17 ID:IbAoaMml(1)調 AAS
C++では0bが使えるようになったけど、Cはまだなのか
つか素直にC++使おう
287: 2018/10/21(日)21:24 ID:y1FMkoBF(1)調 AAS
最近のc++は糞化拡張が止まらないから。
あくまでアセンブラの代替として使いたいのであって、ハード寄りのコードを書きたいのであって、
速度重視、メモリ効率重視が根底にあるのに、c++の仕様拡張してる奴らはただの言語オタクでうざい。
288(1): 2019/05/25(土)11:08 ID:jbgB9jQg(1)調 AAS
Rustが正解に近い。
メジャー化してエコシステムが充実すればいける。
289: 2019/06/03(月)11:49 ID:561P/qAZ(1)調 AAS
armcc, armclang, Linaro GCC
ARMR コンパイラ armcc ユーザガイド
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472jj/index.html
armcc は、標準 C および標準 C++ のソースコードを ARM アーキテクチャベースプロセッサのマシンコードにコンパイルする、最適化 C および C++ コンパイラです。
290: 1 2019/08/13(火)23:00 ID:oTlgbS6H(1)調 AAS
Rustが正解であることが確認されました。
10年弱に渡りお付き合いいただきありがとうございました。
291: 2019/08/21(水)20:28 ID:6xsUkfpB(1)調 AAS
言語が
理解習得し易い
誤認間違い難い
というのもお願いしたい
292: 2019/08/31(土)17:50 ID:54Etlgy2(1)調 AAS
MIT「えっまた俺なんかやっちゃいました？」
julia、軌道に乗る
293: 2019/08/31(土)22:20 ID:XxwPKKvU(1)調 AAS
>>277
大本の思想がランタイム速度落とさずにできるかぎり高級機能入れてこう
ってなところがあるんで自然といえば自然。
ある種の人体実験場みたいなところがc++の意義って気もする。
294(1): 2019/09/01(日)01:01 ID:JdN5NInb(1)調 AAS
>>288
バスト占い思い出した
295: 2019/09/01(日)13:35 ID:gzRpR9B4(1)調 AAS
c++が示したことってのは結局
ランタイム速度
高級機能を追加
の２点だけ追求すれば馬鹿プログラマは寄ってくるってことなんだわ。
296: 2019/09/14(土)20:38 ID:IbeHy12P(1)調 AAS
どうみても今はコード書かない言語オタクが好き勝手に拡張してる。
C++にくだらん機能追加したいなら名前変えろよ。
C++系言語で普及した言語はJavaやC#などいっぱいある。
297: 2020/02/17(月)23:02 ID:R0DiDWe7(1)調 AAS
Low* (Low star)という言語は型システムがすごいのでぜひ取り入れていくべき
298: 2021/10/27(水)10:06 ID:XE3bmMwX(1)調 AAS
演算子オーバーロードって難読化だよね
299(1): 2021/10/28(木)12:18 ID:VQB5DVZJ(1)調 AAS
まあ、もともとCは最適化はあまりやらなくて、プログラマの意思をなるべく素直に伝えるという思想だしな。だから、a=a+1;とa++;は演算後の値は同じでもプログラマの意図は違う。前者は加算命令、後者はインクリメント命令に落ちてほしい。
コンパイラのエラーチェックも最小限で、チェックはlint使えって感じだし。
Rust屋の主張するメモリ安全なんかも「うっせえわ！黙って言う通りにやれ！」って感じ。
あぁ、キャリー/ボローフラグが使えたら良いなあって時はあるかな。
300: ハノン ◆QZaw55cn4c 2021/10/30(土)16:29 ID:nIglmucm(1)調 AAS
>>299
＞キャリー/ボローフラグが使えたら良いなあ
ですよね、ローテート／シフトのときは特に
301: 2021/11/06(土)14:48 ID:b1XdA94q(1)調 AAS
int と size_t がいつも混在して面倒になる
302: 2021/11/26(金)11:52 ID:ARqZ/fb1(1)調 AAS
勝手な整数拡張をやめてくれるある意味cより低級なcが欲しい
パフォーマンス的にワード長で扱うのが良いというのもわかるが
あえてintより小さい型で計算したい時というのはそれなりの理由があるからやるわけで
その型内でオーバーフローしたら切り詰めずに素直に落ちろ
303: 2022/04/19(火)01:58 ID:TThcYTpA(1)調 AAS
しかしそこまで低級なところに降りていくとマクロアセンブラみたいなのが使いやすい感じになっちゃうんだよね。
言語上の表現がどういう機械語に対応付くのか意識するともう直接書いた方がええわ……となる。
304(1): 2022/04/19(火)14:30 ID:1/h8QBeL(1)調 AAS
呼び出し前後のレジスタ退避と回復だけやってくれれば意外とアセンブラはほぼforthだよね
305(1): 2022/04/21(木)17:35 ID:+ZjRtsOn(1)調 AAS
forthは言語とマクロ用言語が同一言語なアセンブラだな
gforthみたいなリッチ実装はコンパイル済の定義を参照するとx86の標準文法を曝け出しちゃってなんだかなぁ、と思う
306: 2022/04/21(木)20:15 ID:O4XEE7U4(1/2)調 AAS
>>304
forthは呼び出し規約の抽象化じゃなくて、型と引数という概念を捨てて自由になった
マシン依存性を排除するためにレジスタを抽象化した汎用dスタックに全ての命令が型と個数の解釈をモラルを守って作用することで成り立ってる
(暗黙の)引数渡しに関してはオーバーヘッドは大きくないので普通はマシンの最大スカラー型
floatはさすがにfスタックがあるけど
dスタックだけで複雑なデータ操作は厳しいから、最大スカラー型である事が保証されてるrスタック(生ハードウェアスタック)が一時領域に便利なのが闇
制御構造も戻りアドレスや添字を積むだけだから、うっかり積み残しがあると戻りアドレスやデータが添字代わりにインクリメントされ続けたり不可解な事に
あとは拡張性が売りの癖に制御構造のポータブルな拡張が難しいのがな…
もちろん制御構造と整合性のある単純な命令くらいは添えられてるのであくまで例だけど
指定回数ループをbreakするには最低で添字と戻りアドレスをpopする必要があるけど、たいてい実装拡張として積まれてるデータは不定、何回popしたらセグフォるか試すことになる
規格の制御構造には不備があるから(これは本当)うちの拡張を推奨ってのが普通の世界
制御構造すら定番がなくて、同じ言語といえるのかという疑問すら湧く
307: 2022/04/21(木)21:15 ID:O4XEE7U4(2/2)調 AAS
>>305
コメント無くなってたり、埋め込んだ定義が等価な表現に置き換わってたりするから、seeは既存のコードを参照してるのでなくて、ブロブからforthコードへのディスアセンブラ(再構築)
ワードを渡せば' でそのワードの指すアドレスは取れるけど、そこから何バイト読むかのオフセット指定をseeは取らない、かなりヒューリスティックだと思う
seeで標準される開始-終了アドレスに、読みすぎてそうなら適当に足すか、途中で切れてるようなコードなら適当に足してaddr nbyte discloseと呼べば大体復元できると思う
dis、+disとかも入ってたっけ
まあ、具体的なレジスタやメモリの名前が分かるだけでforthコードとそんな変わらないという悲しさはあるが
308: 2022/07/30(土)16:21 ID:paa5jUiA(1)調 AAS
Nim++
309: 2022/08/03(水)08:36 ID:G37dUWbH(1)調 AAS
低級言語ならx64特化して構造化アセンブラみたいな感じで
ちょっとオシャレだけどやってる事はほぼむき出しのレジスタ操作みたいな？
310: 2022/08/03(水)11:55 ID:GLMdE3Py(1)調 AAS
masm64でinvokeしまくれば
311: 2022/08/04(木)05:27 ID:Xs8BUVRi(1)調 AAS
例えばループが多重化してループカウンタが複数必要な場合
作法としてRCXを使うけど、処理系が最適化で空いてるレジスタを割り当てたり
退避復帰をしつつRCXを使うとか
固定領域を確保してカウントに使用するとか自動でやってくれるみたいな
プログラムコードは雰囲気コーディングだけど最終出力は忖度された何かみたいな感じ
312: 2022/08/04(木)18:25 ID:+TMVVsOn(1)調 AAS
アセンブリ並みの変態低級言語作る?
313: 2022/08/06(土)14:07 ID:eSBCWCwI(1)調 AAS
Nim++
314: 2023/09/21(木)12:59 ID:7twnyTUv(1)調 AAS
もうそろそろ、おしで祭りや
315: 2023/11/01(水)03:29 ID:5z6NYMjm(1)調 AAS
Nim#
316: 2023/11/05(日)10:42 ID:ol9bMVcc(1)調 AAS
Rust++
317(1): 2023/11/05(日)16:32 ID:M+aCXIKU(1)調 AAS
最近のCPUのアセンブラはほとんどCと変わらないようだけど
318: 2023/11/06(月)06:07 ID:bdWb9xgB(1)調 AAS
昔のCはアセンブラとほとんど変わらなかったから
差は縮まっていない
なにも変わってない
319(1): 2023/11/06(月)16:20 ID:cmjYyIPB(1)調 AAS
最近はむしろC標準が直接サポートしてない命令が増えてるからな
ローテイトなんていまだにないし
320: 2023/11/11(土)12:31 ID:fuGMacjx(1)調 AAS
>>319
良いのが入荷
https://www.youtube.com/watch?v=P6KRbjoFdwY
321(1): 2024/02/11(日)03:12 ID:morq3qnL(1)調 AAS
>>294
Aカップが好きなアセンブラ君、食わず嫌いはいけません高級言語は恐くありませーん
Bカップが好きなBASIC君、少しは毛が生えたけどまだまだ修行が足りません関数に興味はないのですか
Cカップが好きな君は正解に限りなく近い。有象無象の言語はたくさん出てきたけれど結局Cが手ごろサイズで限りなく正解に近いです
Jカップが好きな君は煩悩に振り回されっぱなしです。たまには太陽だけでなく月にも興味を持ちなさい
322: 2024/04/19(金)10:13 ID:uD5nyH4z(1/2)調 AAS
>>1
仮想アセンブラを作ることになるが、かえって誤ったハードウェアと勘違いしそうw
323: 2024/04/19(金)10:14 ID:uD5nyH4z(2/2)調 AAS
>>317
アセンブラがわからないのに語る変なやつw
324: 2024/05/02(木)01:06 ID:f54xPIPf(1)調 AAS
>>321
どうでもいい話だけど、J が Java のことを言ってるようにも見えるので
実際には J 言語てのがあるんだけどね
J はJava や JS とは全く関係ない、APL (という言語) の派生言語で
APL と違って特殊キャラクタを使用せず ASCII のみで記述可能にしたもの
325(1): 2024/12/11(水)21:59 ID:bqdEzJrv(1)調 AAS
>>1
そうして生まれたのがRust
Cと同じことが出来つつCの諸問題を解決した
インラインアセンブラも備えているのでCを置き換えられるようになった
326(1): 03/24(月)12:24 ID:tWxitKr9(1)調 AAS
>>325
let bits = vec![false; 32];
これでbitsのサイズが4バイトになってくれるような仕組みはRustにありますか？
327(3): 03/24(月)13:15 ID:a0wY9RFf(1)調 AAS
>>326
https://docs.rs/bit-vec/ がいいかな
use bit_vec::BitVec;
fn main() {
// 32bit全てfalseで作成
let mut bv = BitVec::from_elem(32, false);
// 7bitおきにtrueセット
for index in (0..32).step_by(7) {
bv.set(index, true);
}
// 0, 7, 14 , 21, 28番目のbitがtrueになった
assert_eq!(bv.get(0), Some(true));
assert_eq!(bv.get(1), Some(false));
assert_eq!(bv.get(7), Some(true));
assert_eq!(bv.get(28), Some(true));
// イテレータでtrueになってる位置のリスト
let v = bv.iter().enumerate().filter_map(|(i, bit)| bit.then_some(i)).collect::<Vec<_>>();
assert_eq!(v, [0, 7, 14, 21, 28]);
// 内部構造は標準でVec<u32>を使っているのでu32が1つ分
assert_eq!(bv.storage(), [0b_10000001000000100000010000001]);
// バイト列にすると4バイト
assert_eq!(bv.to_bytes().len(), 4);
assert_eq!(bv.to_bytes(), [0b_10000001, 0b_00000010, 0b_00000100, 0b_00001000]);
}
328(1): 03/24(月)13:30 ID:S5TsEiko(1)調 AAS
CはPDP-11のアセンブラの高級言語化でしたっけ？
消えたアーキテクチャとは言え未だ有用ではありますが、現役アーキテクチャの8086-64やARMのソレとかの命令セットはどうなっているんでしょ？
多分基本命令そのものは大差ないと思うけど、マルチメディア拡張？ MMXみたいな専用命令はCで直接記述出来ないですよね。
他にも、最近のナウいアーキテクチャは文字列をそのまま扱えるとか聞いて想像の範疇超えてます。
高級言語も楽で良いけど、そういうのは楽なアセンブラの上に構築出来ればそれで良いなあ。
329(1): 03/24(月)19:01 ID:/lNBwDBZ(1)調 AAS
25年位前のレスのコピペかよω
330(1): 03/25(火)03:40 ID:ztarSHRB(1/2)調 AAS
>>327
なんか左右逆で気持ち悪い(bigendian/littleendianともちょっと違う)
bv.set(31, true);
bv.set(32, true);
assert_eq!(bv.to_bytes(), [
0b_10000001, // 0-
0b_00000010,
0b_00000100,
0b_00001001,
0b_10000000]); // 32-
assert_eq!(bv.storage(), [
0b_10010000001000000100000010000001,
0b_1]);
331: 03/25(火)08:18 ID:viWlYIzm(1)調 AAS
>>329
すまない、オッサン通り越してお爺さんだから思想も古いんだ。
332: 03/25(火)08:41 ID:ztarSHRB(2/2)調 AAS
>>327
ありがとう。参考になりました。
多倍長整数の論理演算でbit立てる方法があったので、
それを使ったら簡単で速度もそこそこ出たので満足しました。
>>327 さんのものは不採用です。
333: 03/25(火)09:02 ID:4yBAp1pH(1)調 AAS
>>330
ビットはそういうものだよ
普通にビット演算すればわかる
let mut bits: u32 = 0;
for n in [0, 7, 14, 21, 28, 31] {
bits |= 1 << n;
}
// u32に詰めているからこうなる
assert_eq!(bits, 0b_10010000_00100000_01000000_10000001);
// bit順(index=0..)にバイトで得る
assert_eq!(bits.reverse_bits().to_be_bytes(), [0b_10000001, 0b_00000010, 0b_00000100, 0b_00001001]);
334: 03/25(火)12:13 ID:2SmtLJ6z(1)調 AAS
assert_eq!(bits.storage(), [0b_10010000_00100000_01000000_10000001]);
の結果から想像するに
assert_eq!(bits.reverse_bits().to_be_bytes(), [0b_10000001, 0b_00000010, 0b_00000100, 0b_00001001]);
ではなく
assert_eq!(bits.to_be_bytes(), [0b_10000001, 0b_01000000, 0b_00100000, 0b_10010000]);
の方を期待するのは可笑しいのかなー
正直びっくりエンディアンですわ
335: 03/25(火)19:08 ID:d+t8RnIb(1)調 AAS
byteやword単位のリトルエンディアンじゃなくて
1bit単位のリトルエンディアンだと思えば自然
336(1): 03/27(木)07:21 ID:vU3T1Sq/(1/7)調 AAS
Rustのオペレーターオーバーロードについて質問です
とりあえずtraitを使って
let a: X = X::new();
let b: X = X::new();
let c = a + b;
は出来たのですが
let a = &X::new();
let b = &X::new();
let c = a + b;
だと定義が無いと言われるのでtraitに&のバージョンを追加したら出来ました
ところが
let a = &mut X::new();
let b = &mut X::new();
let c = a + b;
だとまた出来ないのでtraitに&mutバージョンを追加したら出来ました
ところが
let a = &X::new();
let b = &mut X::new();
let c = a + b;
や
let a = X::new();
let b = &mut X::new();
let c = a + b;
や
let a = &X::new();
let b = X::new();
let c = a + b;
が全部出来ません
こういうのはすべての組み合わせをtraitで作っておく必要があるのでしょうか？
それとも一つの表現で全部定義してくれる仕組みは？
337(1): 03/27(木)09:14 ID:vU3T1Sq/(2/7)調 AAS
これかな
https://stackoverflow.com/questions/57911001/how-to-combine-all-operator-overloading-combinations-into-a-single-trait-in-rust
338: 03/27(木)09:22 ID:UV4Rce1I(1/2)調 AAS
>>336 >>337
ここに回答があるよ
https://stackoverflow.com/questions/38811387/how-to-implement-idiomatic-operator-overloading-for-values-and-references-in-rus
339: 03/27(木)09:56 ID:vU3T1Sq/(3/7)調 AAS
ああこれinternalなのね
macro_rules! add_impl とか
macro_rules! forward_ref_binop
(unop とか op_assign とかもあるけど)
340: 03/27(木)09:59 ID:vU3T1Sq/(4/7)調 AAS
これでいいのかな
https://crates.io/crates/forward_ref_generic
341: 03/27(木)10:02 ID:vU3T1Sq/(5/7)調 AAS
ああこっちか
https://crates.io/crates/forward_ref
>>328
それは >>327 の中にリンクがあったので既視です??
342(1): 03/27(木)11:15 ID:vU3T1Sq/(6/7)調 AAS
よさげだったけど&mutのが出来なかったorz
343: 03/27(木)11:35 ID:vU3T1Sq/(7/7)調 AAS
結局自前でmacroコピペして&mutの定義も追加したらいけたわthx
344: 03/27(木)11:46 ID:HDQeQZ5r(1)調 AAS
Copyトレイトは無闇に付けたくないな
345: 03/27(木)11:59 ID:JG6/gkrB(1)調 AAS
Trait爆発ですね判ります
346: 03/27(木)12:14 ID:UV4Rce1I(2/2)調 AAS
>>342
Addでは不変参照しか使わないから& mutは不要
& mutが必要となるのはAddAssignだがこれは& mut selfになる
347(1): 03/28(金)09:26 ID:VPiwRdmL(1)調 AAS
Rust使ってても暗黙のCopyとかに無関心だと【超高速】名乗れなくない？
348: 04/05(土)10:41 ID:wy4OM/NR(1)調 AAS
包丁も食材も上手く使えないと料理は不味い
349(1): 04/06(日)07:52 ID:IvdHyMZx(1)調 AAS
料理が上手なヤツはRustは使わない
350(2): 04/06(日)23:21 ID:p+WNSwb1(1)調 AAS
>>347
暗黙のコピーが発生しまくる諸言語とは異なり
RustではCopyトレイト実装型のみ暗黙のコピーが行われるので最もRustが好ましい
具体的にCopyトレイト実装型とは整数値やポインタおよび不変参照であり
それらを用いた複合型は明示的にCopyトレイト実装することもできる
ちなみに整数値などがなぜ暗黙のコピーが起きても構わないかというと
CPUにとってそれらをポインタ経由で間接的に扱う方が遅くなるからであり値をコピーして用いたほうが速いため
351: 04/07(月)10:58 ID:fwcAlCQF(1)調 AAS
はあ…
352: 04/07(月)12:23 ID:yN1PvO54(1)調 AAS
>>349
マにだって料理が得意な奴はいるだろ
353: 04/07(月)14:31 ID:w0rhHNCz(1)調 AAS
>>350
お前レベル低過ぎ
黙ってろ
354: 04/07(月)14:50 ID:k98JYePi(1)調 AAS
>>350で合ってるでしょ
コストの係るものは明示的に.clone()しないとコピーできないし
コストの係らないものはCopyトレイトのおかげで.clone()しなくてもコピーされるよ
355(1): 05/02(金)09:39 ID:k5bGwZZ0(1)調 AAS
Rustの最大の教訓は、どんな言語でも有名になればバカ(必ずしも頭が悪いわけではなく、本来その言語が想定しない用途に使おうとする奴も含む)が使うってことだろう
Rustの仕様はそれほど効率が重要でない分野でテキトーに使おうとすると無駄なコピーが増えたりしてかえって非効率になりがちな面がある
356: 05/02(金)18:23 ID:kIVCyVUc(1)調 AAS
>>355
Rustは明示的にclone()を呼んだりCopy実装しないとコピーされないから大丈夫だよ
暗黙にコピーされないから無駄なことをしていればコード見るとすぐバレちゃう
まともなコードは必要な極一部を除いてほとんど参照で渡されるね
ちなみに数値や不変参照(ポインタ)はCopy実装されてるため暗黙にコピーされるけどそれが一番速いから問題なし
357(1): 05/03(土)12:05 ID:ekVKJoF2(1)調 AAS
最適化されることを主張するなら証拠を示すべきなのは当然だが、
コピーの最適化を前提にするのなら例えば安易にCopy実装したりcloneしたりすんな、
みたいな意識高い言説は多くの場合無意味になっちゃうわけだけど、Rustおじはそれでいいのだろうか
358: 05/03(土)13:36 ID:BbjMJMxS(1/3)調 AAS
>>357
頭悪いから違いを理解できないのか？
まずCPUのMOVE命令は全てコピーだ
だから数値や参照(アドレス)がCopy実装されていても何のペナルティも存在しない
むしろ数値や参照を参照で扱う方が間接となり遅い
次にCPUのMOVE命令は全てコピーだがコピー元が使われてなければ純粋なムーブと見なすことができる
そのため最適化が可能で例えば2回のムーブは1回に減らすことができる
これはスタック上の変数を扱う場合も同様でレジスタへMOVEした後にレジスタ間の演算で終わるならスタック上の領域は不要で最適化できる
359: 05/03(土)13:38 ID:BbjMJMxS(2/3)調 AAS
RustやC++のムーブも同じで一次的にはコピーをして元を使わないため最適化できる場合が多い
一方でプログラマがコピーやクローンを明示的にした場合は元が生きていて全く異なる
そもそも元も後で使いたいからコピーしているわけだ
だからムーブとは異なり最適化でコピーが消えることはない
もちろん後で使いたい場合はコピーして渡すのではなく参照を渡すのが正解だ
360: 05/03(土)13:39 ID:BbjMJMxS(3/3)調 AAS
したがってプログラマはコピーを可能な限り避けるべきである
暗黙のコピーが行われるプログラミング言語では意識せずコピーしてしまう
プログラムを見ただけですぐにコピーしてあることがわかる方が望ましい
RustではCopyトレイト実装した型のみ暗黙のコピーが起きる
前述のように数値などはその方が有利なので最初からCopy実装されている
ヒープを用いない型ならばプログラマは自由にCopy実装できるがコード上でそれが明示され読む側は気付ける
サイズが大きく参照で扱った方がよい型をCopy実装していればおかしいことがわかる
一方でヒープを用いていればCopy実装はできないがClone実装はできる
これはコード上でfoo.clone()とコピーすることを明示的に記述する必要がある
したがって参照を使えばよいのに無駄なコピーをしていればすぐにわかる
361: 05/04(日)11:58 ID:RkNPiBO2(1)調 AAS
区別できないバカなのか？
ムーブの時などを含めて実態がコピーになるといってもコピー元は二度と使われないのだから最適化できる
一方でclone()などはコピー元をその後も使うためにコピーしている
コピー元を二度と使わないならclone()の必要がない
そしてコピー元をその後も使うから最適化の前提さえ成立しない
362: 05/05(月)10:09 ID:20YqVkB+(1)調 AAS
RustはC++より描き易いけどC++からの置き換えには不適
RustはCより面倒だけどCからの置き換えには最適
363: 05/06(火)06:06 ID:JTtajrxW(1)調 AAS
低レベル言語の開発だよね？
皆さんの会話が高級すぎて戸惑いを隠せない。
OS記述も十分に低レベルだけど、ハードウエア操作はもっと低レベルじゃないかな？
364: 05/06(火)10:06 ID:K1Pjz07i(1)調 AAS
Rustで低レベルするとunsafeだらけになる
(悪いとは言ってない面倒臭いとは思う)
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.578s*