Rust part10at TECH
Rust part10 - 暇つぶし2ch456:デフォルトの名無しさん
21/05/06 01:47:50.96 V2I8vwdu.net
それと、型を明示した方が後から見たときにプログラマの脳内の想定もわかり易い。
float a = 1.0f;
float b = a + 5.0f;
みたいなものも、もし、
auto a = 1.0f;
auto b = a + 5.0f;
と書くと b は、double 型になってしまうかもしれないが、テストしても
間違いに気づかず、僅かに速度低下やメモリーを多く食ってしまう
かもしれない。また、思想にもよるが、1.0f などと書かずに
float a = 1;
float b = 5;
と書きたい人も居ると思う。これの方が、後から double 型に変えたときに
右辺を訂正する必要がないメリットもある。

457:デフォルトの名無しさん
21/05/06 03:19:29.71 EVf7RH7G.net
>>446
rustの文字リテラルはu8でもi8でもなくてcharな
それはそれとして型やら括弧やらを明示的に書くことは禁じられてないんだから書けばよいのでは
言語の問題というよりはコーディング規約でなんとかすべき領域かと
タイプ数が多くなるとかはデフォルトをどちらに倒すかの問題で世間の嗜好とずれてるなら多少手間がかかるのは諦めるしかない

458:デフォルトの名無しさん
21/05/06 03:21:51.36 EVf7RH7G.net
誤解を招きそうだから補足しておくとrustのcharはユニコードのコードポイントが格納される32bit符号なし整数型な

459:デフォルトの名無しさん
21/05/06 06:46:11.97 AMAuzv83.net
>>443
こういうのいいな

460:デフォルトの名無しさん
21/05/06 10:08:34.61 VcsxCBNr.net
>>445
var使おうとしてたってマジかー
let (mut a, b) = get_foo_tuple();
みたいなやつとかvarじゃ困るから必然だと思ってたのに

461:デフォルトの名無しさん
21/05/06 10:15:22.90 lmEaR3VD.net
>>445の要約の最後たぶん間違ってる
デイブ氏はキーワードを重ねるとmutableな変数の使用を躊躇させる効果が生じて
プログラマのコーディング方式の選択を咎めることになるから反対だったらしい
チームの決定は初めからlet mutで彼は(珍しく)反対したけど最終的には受け入れた

462:デフォルトの名無しさん
21/05/06 11:35:13.23 hCHdFqbq.net
つまり暗黙の型変換は癌

463:デフォルトの名無しさん
21/05/06 11:48:56.26 f


464:owE0ZYM.net



465:デフォルトの名無しさん
21/05/06 11:52:26.38 a37uwZNi.net
いないいない

466:デフォルトの名無しさん
21/05/06 14:35:25.59 SpjdL+PT.net
>>454
すまん、指示代名詞の指してる先を読み違えた
デイブ氏はvar押しだったんだな

467:デフォルトの名無しさん
21/05/06 16:00:35.75 acc3YL8w.net
タイプ数で優劣を決めようとするアホとは次元が違うな

468:デフォルトの名無しさん
21/05/06 16:31:20.99 q/dBsf9f.net
タイプ数は少ない方が問答無用で良い

469:デフォルトの名無しさん
21/05/06 17:13:47.97 EVf7RH7G.net
fn, ret, cont, break の時代に回帰するか

470:デフォルトの名無しさん
21/05/06 17:27:07.40 ut0g6JOd.net
タイプ数は少ない
って基本型が少ない言語が好みなのかと思った

471:デフォルトの名無しさん
21/05/06 19:28:16.24 fowE0ZYM.net
<?rust
println!("hello rust!!");
?>

472:デフォルトの名無しさん
21/05/06 21:17:13.93 O03dxxkK.net
>>448
型を明示したってバグるくせによく言うのぜ

473:デフォルトの名無しさん
21/05/06 22:42:35.79 pupGSg3O.net
タイプ数が少ないようが絶対良いんなら
むかしGAMEとかいうすべてのキーワードが1文字の言語があったからそれでも使え

474:デフォルトの名無しさん
21/05/06 23:22:18.38 fowE0ZYM.net
Rust ~地図にない場所~

475:デフォルトの名無しさん
21/05/07 03:50:05.38 vAByX/Kb.net
>>464
型明示はバグの軽減に繋がる。
>>465
絶対的に良いわけではないが、let a:i32 = 5; と int a = 5; だと後者の方が楽。

476:デフォルトの名無しさん
21/05/07 07:04:16.43 aU3MjDw9.net
>>467
intが32bitだといつから錯覚していた?

477:デフォルトの名無しさん
21/05/07 08:21:08.42 Dsa6ajo4.net
Announcing Rust for Windows v0.9
URLリンク(blogs.windows.com)

478:デフォルトの名無しさん
21/05/07 09:19:02.07 iG4irUX1.net
言ってる側から落とし穴に嵌っててワロタ

479:デフォルトの名無しさん
21/05/07 10:35:21.40 8IfDDxiK.net
let a = 5_i32;
型は右側だけで決めるのじゃ
両側で合わせるのは無駄、変更するときも面倒じゃろ
・・なに?
aがi32だと明示してバグを軽減したいじゃと?
それなら行を分けるのじゃ
1行にまとめるとせっかくの明示が埋もれてしまうからの
let a: i32; // この行の存在は大きいぞい
a = 5_i32;

480:デフォルトの名無しさん
21/05/07 12:08:53.04 B2UdQUpV.net
>>468
そこまでいうなら、int32 a = 5; や i32 a = 5; と書けばいい。
なお、Rustではこの書き方が出来ない。

481:デフォルトの名無しさん
21/05/07 12:20:12.52 B2UdQUpV.net
>>468
ちなみに、組み込み以外のほとんどのC/C++コンパイラでは、intは32BIT型。
デスクトップマシン用のC/C++では、32BIT/64BIT のどちらでも、intは、
32BIT型のはずで、少なくとも VC++では必ず int は 32BIT。

482:デフォルトの名無しさん
21/05/07 12:24:00.34 w+YL5YRG.net
>>472
int32_tな

483:デフォルトの名無しさん
21/05/07 12:51:05.27 B2UdQUpV.net
>>474
typedef int int32;
typedef int i32;
とすればよいだけ。

484:デフォルトの名無しさん
21/05/07 12:57:04.52 w+YL5YRG.net
>>475
それintが32bitじゃない環境でアホみたいにミスリーディングになるけど?
いい加減スレチだし「int32_t 標準ライブラリ」でググって理解したらこの話終わりにして?

485:デフォルトの名無しさん
21/05/07 13:31:50.44 B2UdQUpV.net
>>476
そんな基本的なことは当たり前で、そのような環境では、
typedef __int32 int32;
typedef __int32 i32;
とする。

486:デフォルトの名無しさん
21/05/07 13:40:18.27 8gopO5Ce.net
どういうバグを作る可能性があるかという点が共有されてないから議論空回りしている感

487:デフォルトの名無しさん
21/05/07 13:42:32.36 B2UdQUpV.net
というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
だと思ったんだ。もし、int32_t が使える環境で賢く使いたい人は、
typedef int32_t int32;
typedef int32_t i32;
typedef int32_t Int32;
などとすればいいという話。
前提とする知識が低すぎる人がいるから困る。

488:デフォルトの名無しさん
21/05/07 13:45:35.27 eN8Lkrsa.net
何を議論してるのか全然分からん

489:デフォルトの名無しさん
21/05/07 14:02:25.02 SIz+0gIF.net
1レス目で即NG
相手してるやつも同じカテゴリなので即NG

490:はちみつ餃子
21/05/07 14:03:01.68 xLSEaA6V.net
議論なんかするつもりがないんだろう。

491:デフォルトの名無しさん
21/05/07 14:40:46.39 r6L15P9a.net
>>479
>というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
>だと思ったんだ。
誰がどこでそんな話をしたのか
ログ辿っても全然分からない件
ついでに言えば
グローバル名前空間の中に標準ライブラリがブチ込む型名として
_tサフィックス以外あり得んので
何も馬鹿なことなんか無い
つーか本当に誰もそんな話してないな
これ突っ込んだら
どんなガイジレスを返すのか興味津々
>>480
論点不明のドッジボールだからな
今はどこでも似たようなやり取りが見られて
5ch終わってる感がハンパない
俺は句点付きが特に頭おかしいと思うけど
レスバ相手はEQがヤバイ感じだが
句点付きはIQがヤバイ

492:デフォルトの名無しさん
21/05/07 14:57:30.94 DUMB7Vls.net
メジャーなGUIアプリで使われているrust製GUIライブラリってなにがありますか?
GUI使いたいんですが長いものにまかれたいので

493:はちみつ餃子
21/05/07 15:02:55.52 xLSEaA6V.net
>>484
プラットフォーム (OS) によって違うんじゃない?
その中ではある程度に淘汰されてると思うけど、
あらゆる環境で万能な決定版は無いと思う。

494:デフォルトの名無しさん
21/05/07 15:53:14.60 B2UdQUpV.net
>>483
>句点付きはIQがヤバイ
実際にIQ150越えてるので、ノーマル一般人が理解できないだけではないか。

495:デフォルトの名無しさん
21/05/07 16:08:00.06 r6L15P9a.net
>>486
証拠うpしてくれ
ID付き画像とかなら最高だ
IQ150超えでもこんなガイジレスするのか
マジで興味あるわ

496:デフォルトの名無しさん
21/05/07 17:04:02.49 +x2jPaur.net
メモリ不足でカーネルパニックが起きることの問題がわからない
普通のパソコン用途に使われてたらユーザーランドのソフトがOOM Killerに殺されようがOS丸ごとクラッシュしようが作業内容が失われるのは変わらん
サーバー用途でも一部のプロセスが殺されて中途半端の状態で動き続けるよりいっその事OSまるごとクラッシュしたほうがいいと思う

497:デフォルトの名無しさん
21/05/07 17:16:13.01 8gopO5Ce.net
>>488
rustでLinuxのドライバー書く話?
メモリ不足時にどうハンドリングされるべきかは使い方によって違うので一律パニックするのは良くない
例えば例に挙げてるOOM Killerだってカーネルがパニックしたら実行されないわけで

498:デフォルトの名無しさん
21/05/07 17:22:12.18 r6L15P9a.net
>>488
何かあった時止まればいいシステムばかりじゃないだろ
ペースメーカーとか原子炉とか
細かいことは知らんけど
昔、組み込み屋のおっさんが最初から1Mぐらい確保して
何かあったらそれを解放してどうにかするみたいなこと言ってた
知らんけど

499:はちみつ餃子
21/05/07 18:25:34.58 xLSEaA6V.net
>>488
システムは単独で動いているわけではない。
カーネルがパニックすることがあって良いという前提で設計して、パニックしうる前提で運用できるならそれでも構わんのだが、
Linux のカーネルでパニックを許すなら今 Linux を基礎にしているあらゆるシステムの運用体制を見直さざるを得ない。
カーネルパニックが絶対に駄目というわけじゃないんだ。
(もちろん発生しないに越したことは無いが。)
Linux では起こさないという前提に皆が従っているので変えられないという話なんだよ。

500:デフォルトの名無しさん
21/05/07 18:53:57.67 XbWp/RIC.net
割り込みが飛んでくる環境で例外なんか扱おうとしたら普通に死ぬだろ

501:デフォルトの名無しさん
21/05/07 19:12:04.63 RYgnWswQ.net
>>488
失われる作業内容の範囲があるだろ。
クライアントOSのWindowsですらBSODで切れる奴が多かったんだから、サーバーOSでそんな考えが許されるはずがない。

502:デフォルトの名無しさん
21/05/07 19:35:24.51 FlZ9PpDj.net
差し当たりRustの言語を広く浅く学習したいのですが、「実践Rustプログラミング入門」の言語部分(100ページ程度)が分量が少なめで気になっています
この本で大きく抜けている文法や機能ってありますか?

503:デフォルトの名無しさん
21/05/07 20:06:32.24 xz5IWUMT.net
>>494
The Bookと比べれば一目瞭然

504:デフォルトの名無しさん
21/05/07 20:11:06.98 8H8V34/d.net
>>493
サーバーOSのほうがクライアントOSよりクラッシュには寛容だぞ
サーバー側の開発したことないのかな?

505:デフォルトの名無しさん
21/05/07 20:22:58.56 fmyiQrUP.net
>>496
最近は仮想化&分散で寛容になっているの?

506:デフォルトの名無しさん
21/05/07 21:23:40.41 EDSX1EuR.net
>>494
最近の本だからasyncまであるし、そんなに大きな抜けはないかな
広く浅くならまぁいいんじゃないかと
もし細かい部分が気になったらthe bookで補完すればいい

507:デフォルトの名無しさん
21/05/07 21:36:25.19 7aFGtcIv.net
>>497
むしろchaos engineeringで積極的に落とす

508:デフォルトの名無しさん
21/05/07 21:52:45.82 Z7WMK8Ny.net
ペースメーカーとか原子炉とか、ノンストップシステムでは常に複数動いている
Kubernetes などでは、ネットワーク分断に備えて、
正常な状態を多数決で決めるから、3, 5, 7 みたいな奇数を動かす
2対2とか偶数だと、どちらが正常か判断できないから

509:500
21/05/07 22:00:09.91 Z7WMK8Ny.net
Netflix などは常に、システムを攻撃して落としたりして、テストしてる。
サイボウズのkintone は、毎日システムを破棄して、作り直しているとか
Kubernetes を使っているのかな?

510:デフォルトの名無しさん
21/05/08 00:03:29.89 4agfhhA1.net
非常時の処理はカーネルの中心部が決めることで
枝葉のモジュールに決定権はないという話なんじゃないの?

511:デフォルトの名無しさん
21/05/08 00:07:56.54 OofXJFgO.net
レイヤーがめちゃくちゃな話しとるな。
OSみたいなハードウェアに直触るものとkubernetesみたいな分散管理のソフトじゃ
全然話が違う。
実際kubernetesはGC付きのgolangが実装だろ。

512:500
21/05/08 01:02:28.51 P6P/nG6A.net
ノンストップシステムでは常に複数動く。
デュアルシステムとか
東証・富士通製のarrowhead は、3重だったかな?
それでも、ラックか何かの接続部分が落ちて、システムダウンした
ネットワークが集中している部分の故障が、最も怖い

513:デフォルトの名無しさん
21/05/08 08:40:46.17 e+sagIsH.net
>>492
なんでじゃ
割り込みルーチンに入るときの退避と出るときの復旧をきちんとやっていれば
割り込みルーチン以外の処理は割り込みルーチンが呼び出されることに対して透過的に動作できる
一部のハードなリアルタイムOSみたいに(多重割り込み前提で)割り込みルーチンから
通常コンテキストに直接「ジャンプ」してタスクをたたき起こすみたいなケースでもなければ割り込みの存在は
通常コンテキストで何をやろうと一切影響は無い
(もちろん割り込み禁止、みたいな直接割り込みに影響する命令を実行したら話は別だがそれは普通特権命令でOS以外は実行できな
 い
カーネルでの例外が問題なのは、
例外機構を持たないCならスタックポインタの調整で済むところを
デストラクタがある高級な言語だと例外が通過する際に自動変数として構築されていたオブジェクトを
例外が通過する関数全てについて解放してやらねばならない
(それでいて一方、自動変数として構築される可能性はあっても
 例外発生時に構築されていないオブジェクトに対しては何もしてはいけない
という点
これは例外を飛ばすだけでその経路全部が同一のコンパイラで書かれなければならないことを意味する
途中に手で書いたアセンブラのルーチンなどあろうものならスタックをぶち壊してハードウェアの例外でいきなり
落ちるということになってそんなことがOS内で起きたら計算機上の資源の安全が担保されない。
OSとしては失格である

514:デフォルトの名無しさん
21/05/08 08:53:39.11 e+sagIsH.net
、と思ったが
よく考えたら「手で書いたアセンブラのルーチン」があったらコンパイラはそれを知らない関数としてスタックポインタの調整以外のことを
しなかったら良いのかorz、
ここは「例外通過時にC++や異なるベンダーのRustコンパイラみたいな例外を捕捉する関数をコンパイルいたRustコンパイラが預かり知らない
巻き戻し処理が必要なルーチン」があったら、ということに訂正


515:デフォルトの名無しさん
21/05/08 09:44:38.32 9PfSgf27.net
なんだこいつ
IQ64だな

516:デフォルトの名無しさん
21/05/08 10:15:07.28 e+sagIsH.net
IQは関係無いやろうがギギギギギ、

517:デフォルトの名無しさん
21/05/08 11:11:59.29 52U5aUmg.net
JAVAみたいな言語があるからnewしたまま放ったらかしでメモリ管理もろくに出来ない馬鹿で溢れかえって居るんだよな

518:デフォルトの名無しさん
21/05/08 11:36:05.31 jLEsHVNz.net
ついさっき知ったけど、new() はT だけじゃなく Result<T> を返していいんだな

519:デフォルトの名無しさん
21/05/08 12:01:48.48 9PfSgf27.net
newはシンタックスじゃなくてただの慣例だからね
慣例ではResultを返すのはお作法に反するはず

520:デフォルトの名無しさん
21/05/08 12:03:38.57 OofXJFgO.net
別にjavaがない頃からそういうバカはいたけどね

521:デフォルトの名無しさん
21/05/08 12:09:19.46 rOsHiSsL.net
メモリ管理もろくに出来ない馬鹿
・Linuxカーネルにカーネルスタックメモリ内の情報を読み取られる脆弱性
・「WebKit」にゼロデイ脆弱性 ~「macOS Big Sur 11.3.1」や「iOS/iPadOS 14.5.1」などが公開
・BIND9に脆弱性、アップデートや回避策を

522:デフォルトの名無しさん
21/05/08 12:14:25.93 lGQPC/Vw.net
>>509
因果関係が逆で、
頭が悪くてその程度ももともと出来ない人は昔はCやC++でプログラムできなかった
がVBやJavaやC#やJSやPythonやRubyではできた。

523:デフォルトの名無しさん
21/05/08 13:11:23.63 RJ95z4qm.net
>>511
newとかfromでResult返すのたまに見かけるけど
どうするのがおすすめなの?
try_newとかtry_fromにするのが良いのかな

524:デフォルトの名無しさん
21/05/08 13:37:14.67 jLEsHVNz.net
>>511
ただの慣例じゃなくて、clippy先生の指導対象らしい
URLリンク(rust-lang.github.io)
Checks for new not returning a type that contains Self.

525:デフォルトの名無しさん
21/05/08 14:30:50.83 yMDwHl+j.net
手動でスタックポインタの調整ってバグや脆弱性の温床


526:じゃね?



527:デフォルトの名無しさん
21/05/08 17:15:39.08 3vrEhaHR.net
医療機器や原発の制御システムとかが不意にリセットしないとか思っている時点で
組み込みとか高信頼性システムとかを全く知らないんだなって思う
ああいうのは最悪暴走したらリセットして最低限の機能は提供出来るように
作るのが基本だからね。そうしないと想定外の事態がおきた時に詰む

528:デフォルトの名無しさん
21/05/08 17:18:46.34 jLEsHVNz.net
そんなコーナーケースの為に俺たちの使い心地が悪くなるようなら耐えられないな

529:はちみつ餃子
21/05/08 17:23:48.71 //zoyCL6.net
暴走した場合にでもうてる手札を用意しておくってのと、
暴走しないように細部まで検証しておくってのは両立する話

530:デフォルトの名無しさん
21/05/08 17:27:07.74 QshNNe4V.net
いうほどコーナーケースってほどでもないだろ。
割と考慮されて当然のケースだわ。
まあlinux単体がその品質を担保できてるとも思わんけど。

531:デフォルトの名無しさん
21/05/08 17:33:15.67 3vrEhaHR.net
原子力関係だけでなく航空機や宇宙機もだが制御不能になるのが一番ヤバイんで
バグ出しは常識的な範囲で行って、あとはリカバリ系に注力した方がシステムの信頼性は向上する
歴史的に見ても事故るシステムの多くはこの辺をガバっている事が多いし

532:デフォルトの名無しさん
21/05/08 17:57:46.72 e+sagIsH.net
別に
ハイテク旅客機が落ちるのは自動制御と手動操縦のモード切替仕様を
パイロットが熟知しておらず緊急時に操縦桿を奪い合う格闘になったから
であってソフトは仕様通りだった
『ハイテク飛行機はなぜ落ちるか』(ブルーバックス)のインシデントの数々を見たらワカル
原子炉の制御系はそもそも暴走させないように金かけて形式検証する
人間が本気になったらどんだけバグをなくすために金と手間を掛けられるかというと
スペースシャトルのSSMEの制御装置のソフトがどんだけ徹底したデバッグが行われたかを見たらワカル

533:デフォルトの名無しさん
21/05/08 18:17:53.56 57+jEKOs.net
>>523
人間が使う物であればUIも当然システムに含まれる
判りにくいUIは良いシステムとは言えない
ソユーズや神舟はADA使ったりしていないけど
スペースシャトルより死人は少ない。米式が唯一の正解とは限らない
むしろスペースシャトルはシステム設計に失敗した例だろ

534:デフォルトの名無しさん
21/05/08 18:22:37.13 e+sagIsH.net
UIの仕様バグと>>518が言っている暴走する系のバグは話がちげう

535:デフォルトの名無しさん
21/05/08 18:36:29.80 57+jEKOs.net
組み込み機器でも多くのケースで不測の事態に備えてウォッチドックタイマを使うよね
トリガを何にするかやリセット時に何をするかは設計手腕が問われるところだけど

536:デフォルトの名無しさん
21/05/08 19:38:20.73 RJ95z4qm.net
>>516
fn new() -> Result<Self, T> は警告出ないよ

537:デフォルトの名無しさん
21/05/08 19:42:36.17 PnHrKWCk.net
newでResult返すのはいいけどfromは駄目だろ
というかFrom trait実装しろ

538:デフォルトの名無しさん
21/05/08 19:46:07.47 RJ95z4qm.net
>>528
そもそも impl From<T> Result<Foo, E> はcoherenceの関係でエラーになるよね
Intoはできるけど
FromStr なり TryFrom を使うべきというのはそう

539:デフォルトの名無しさん
21/05/08 20:23:33.19 jLEsHVNz.net
>>527
そりゃ Result はそこに書いてある a type that contains Self だからね

540:デフォルトの名無しさん
21/05/08 21:10:37.46 vIQ3GRO1.net
cのコードをrustに変換してくれるライブラリってありませんか?

541:デフォルトの名無しさん
21/05/08 22:23:50.74 8Oybw0Jl.net
>>531
c2rust

542:デフォルトの名無しさん
21/05/09 12:16:13.70 RMo+m9mc.net
その場合誰がRustコンパイラと戦うんじゃ……

543:デフォルトの名無しさん
21/05/09 13:34:11.17 DdW1Qm5g.net
1.52来てたのね

544:デフォルトの名無しさん
21/05/09 23:13:05.64 T2j6cCMq.net
例外処理って何が有難いの?Cでプログラム書いてて例外がなくて困ったことないんだけど
もしかしてただのシンタックスシュガー?

545:デフォルトの名無しさん
21/05/09 23:31:00.87 LUIc58fP.net
戻り値の設定に近いものを一箇所にまとめられる。

546:デフォルトの名無しさん
21/05/10 00:03:43.87 sciUqTyU.net
どのレベルの話?
初心者の質問だとすると、関数の失敗を成功と区別するため。
戻り値で区別するんでなくて仕組みで。

547:デフォルトの名無しさん
21/05/10 00:10:05.03 EWDopcLj.net
例外の存在意義が分からない
戻り値で判別する方が可読性も高いし何も不足を感じない

548:デフォルトの名無しさん
21/05/10 00:21:25.87 giJ6lOgz.net
>>538
スレチ

549:デフォルトの名無しさん
21/05/10 07:17:37.24 aMiH/GVN.net
fileへのwriteとか毎行エラーチェック入るのしんどい

550:デフォルトの名無しさん
21/05/10 10:07:49.01 ro06Xyvc.net
>>538
開いた後、必ず閉じる処理が必要な場合があるが、それをxとすると、
関数のある場所でエラーを発見した時、呼び出し元へ返りたくても、
xを閉じてからでなくてはならない。xが複数有ったり、今後もxの
量が増えていくような場合、エラーが起きる場所全てでxを正確に全て
閉じてからreturnするのは難しい。なので、昔から、xを閉じる処理は
関数の最後の方に書いておいて、その直前にラベル lab_ex:; のような
ものを書いておいて、エラーが起きたときにはlab_exにgoto文
で飛ばすようなことが行われることが多かった。
でも、goto文は好まれ無い事があって、
try, catch 構文を使うと、goto文を使わなくてもそれが出来るようになる
ことが例外処理の一つのメリット。

551:デフォルトの名無しさん
21/05/10 10:12:49.59 ro06Xyvc.net
>>541
BOOL func()
{
 BOOL rc = TRUE;
 open_some(x);
 if ( !func2() ) {
  printf( "エラーだよ\n" );
  rc = FALSE;
  goto lab_ex;
 }
 ・・・
lab_ex:;
 close_some(x)
 return rc;
}
↑のようなものが、例外処理を使えばgoto文を使わなくても書けるようになる。
ただし、goto文が何でそんなに嫌われるかは謎と言えば謎ぞの一つではあり、
lab_ex:; が見た目的に「浮く」からではないか、という説がある。
しかし、論理構造的にはgoto分がそんなに分かりにくいわけではない。

552:デフォルトの名無しさん
21/05/10 10:13:54.77 Pi5UB1M6.net
そういやCで bail: ラベルが多用されてたなーっていうのを
anyhowクレートの bail! マクロで思い出した

553:デフォルトの名無しさん
21/05/10 10:16:15.81 pIvV80n0.net
>>541,542
クソスレチ

554:デフォルトの名無しさん
21/05/10 10:23:18.20 ro06Xyvc.net
>>542
例外処理を使った場合、goto文が要らない:
BOOL func()
{
 BOOL rc = TRUE;
 open_some(x);
 try {
  func2() ; // 例外発生の可能性有り
  func3() ; // 例外発生の可能性有り
 }
 catch(...) {
  printf( "エラーだよ\n" );
  rc = FALSE;
 }
 close_some(x)
 return rc;
}

555:デフォルトの名無しさん
21/05/10 10:23:53.36 ro06Xyvc.net
>>545
ただし、この場合、x をクラスのオブジェクトで、x がデストラクトされる
時に自動的に close_some()を呼び出すようになっていれば、そもそも
goto文は不要なので、例外処理でやらなくても最初からgoto文が現れない。
しかし、すべてがクラスオブジェクトになっているわけではない。
典型的な例は、
BOOL last_flags = g_flags;
g_flags = 一時的なフラグ設定;
・・・
if ( xxx ) {
 // エラー発生:
 rc = FALSE;
 goto lab_ex;
}
lab_ex:;
g_flags = last_flags;
return rc;
のようなもの。

556:デフォルトの名無しさん
21/05/10 10:40:58.67 u82ImyiI.net
後藤さんいい加減にしてくださいよ…

557:デフォルトの名無しさん
21/05/10 13:07:54.71 H09R880S.net
Linuxや*BSDなどのカーネルはgoto文が誰に遠慮することもなく堂々と使われてますよ
そして可読性は何も損なわれていない
言語屋さんだけじゃないの?構造化でgotoがどうたらとかそれに代わる言語機構が
必要だとか言ってるのは
そして新たに言語を学ぶ人が無批判にそれらを盲信することが代々続いてる
ようにしか見えない

558:デフォルトの名無しさん
21/05/10 13:38:27.10 FH4+0Y9S.net
多くの言語はハードウェアとしてCPU例外や、I/Oに対する入出力の(ハードウェア的)例外と、多くは
復帰可能なエラー分岐処理にて、プログラミング言語で「包括的に捕捉して後処理」するためにある。
例外の反対者はResult/Option/(Either)のようなものがあるのに、なぜ言語に例外を取り入れて、信頼性を
低下させるような隠された制御フローを導入するのかと主張します。
しかし例えばファイルへの出力で"fwrite"ではOSの上層では実際に書き込まれず、"fclose"で書き込まれたり
あるいは"fflush"でメモリー上とディスクが同期されるなどは、同期的な、従来の戻り値を確認しただけでは
正確な判断ができない。(これは言語のライブリーがBufferを使用しているとは別の話、たとえばディスク
容量が足りなくなった場合など、意図するプログラムは失敗する可能性があります。)
またResultなどが使用できるの場合は、ハードウェアやIOに依存しない場合にできるだけです。他にも、不正な
ゼロ除算などの発生は、カーネルでも、組み込みでも、CPU例外に対しては特定の例外の種類によりあらかじめ
決められたアドレスに強制的にジャンプします。C言語自身はCPUの挙動を定義していませんので、この制御の
フローの移動はCプログラミング言語の機能ではなくCPUメーカーの実装です。
つまり、標準のC自体だけでは、統一的にエラー処理を記述するということ自体が出来ていませんし、実行制御
フロー記述し完全掌握してコントロールするという事自体があやふやです。
(ゼロ除算でジャンプしなくてHALTするようなCPUがあるかもしれませんが知りません)

559:デフォルトの名無しさん
21/05/10 13:43:11.18 FH4+0Y9S.net
多くの例外がある言語(RustやGoのpanicも含む)では、上記の例ではファイル出力とは無関係な処理でも
即座に後処理へ移動します。ですが、ここに1つの問題があり、多くは捕捉した後にほぼ「自動的に」
ディストラクタに記述された処理をスレッド毎に存在するスタックを遡って巻き戻しを行います。
(例外の反対者はこれを隠された制御フローというが、決して信頼性が低下するわけではないです、
カーネルの例外ハンドラを例に挙げれば、ただ挙動が合わない事と、多くの例外がある言語でのCPU例外の
捕捉はリカバリが不可能に近く、挙動が保証できない事でディストラクタ実行させて意味があるのかという
矛盾もあります)
それ以外の例外処理は概念的にはスレッドローカルグローバル変数とifとgoto/returnの組み合わせにしか
ならないので信頼性が低下したりはしません�


560:Bまた、C言語や昔の言語でgotoが嫌われていたのは、ラベルが 存在しないgotoだったりループ中のgotoだったり、プログラムのモジュール化を壊す制御であったためなども あります。try-catch-finallyとは無関係ですが、同様に可読性が悪いように見えてしまうため、冤罪にされます。 そもそもアセンブラであればJMP命令にしかならない事をいつまでもグチグチ言うのは悪い癖です



561:デフォルトの名無しさん
21/05/10 15:15:38.71 ro06Xyvc.net
>>550
後半、BASIC言語を振り返ってみると、ラベルの無いgoto文はむしろラベルありより綺麗に書けていた。
gosubはラベル方式の方が良かったが。
Cのgotoはラベルが必須なのでラベルが浮いてしまって嫌われているという説がある位。

562:デフォルトの名無しさん
21/05/10 15:18:53.59 ro06Xyvc.net
例外処理の問題点は、
try {
 f1();
 ・・・
 f2();
 ・・・
 f3();
 ・・・
 f4();
 ・・・
}
とtryブロックの中に沢山の関数呼び出しが有った場合、コード上ではどこでも例外が
起きる可能性を捨てきれないため逆に危険な可能性を排除しにくいことがある。
例えば、fputc()やfwrite()などで例外が起きることが分かっているならそれはそれで
良いが、全く関係のないf1, f2, f3, f4でもどれかは例外が起きる可能性があるなら
非常にプログラミングしにくい。

563:デフォルトの名無しさん
21/05/10 15:21:55.24 ro06Xyvc.net
>>551
例えば、BASICでは以下の様な感じになるので、ラベルが無い事でむしろすっきり
見易かった。gosub文はまた別でいまの関数の様な感じで名前が付いている方が
分かり易かった。これは経験を積まないと理解しにくいかも知れない。
100 if xxx = yyy goto 120
110 ・・・
120 ・・・

564:デフォルトの名無しさん
21/05/10 18:35:05.49 mFjZyrFq.net
>>548
構造化の無い暗黒時代に戻りたくないわ。
制御構文と構造化設計を破壊するぐらいならgoto使わないほうがマシ。破壊しない程度だったら許容できるかね。

565:デフォルトの名無しさん
21/05/10 18:45:12.97 QB4+qLHE.net
Rustは学習コスト高いって言われてるけど
Scala辺りと比べても難しいですか?

566:デフォルトの名無しさん
21/05/10 19:40:11.34 RQLzh3xR.net
>>555
別に特別難しいわけではないと思う
いろんな言語からパクってきてる要素が多くて、これまで一つの言語しか使ったことない人は学ぶべきことが多いってだけで
ScalaとC++くらい経験あれば余裕だろう

567:デフォルトの名無しさん
21/05/10 21:15:30.50 aMiH/GVN.net
コンパイラの文脈解析がこんだけ普及したのだから
safe gotoが存在するべきだ

568:デフォルトの名無しさん
21/05/10 21:21:46.54 10iSv1/R.net
言語自体よりも、情報技術の基礎が要求されるんじゃないの

569:デフォルトの名無しさん
21/05/10 21:38:27.66 +CGjcQmG.net
>>555
やってみるのが一番早いよ
URLリンク(ideone.com)
こーいうところを使うとPC側にコンパイラとか用意せずに試せる

570:デフォルトの名無しさん
21/05/10 23:10:53.18 Ai0jiWQm.net
>>559
>>1にもあるけどURLリンク(play.rust-lang.org)のほうがいろいろ充実してる
てかideoneは1.33.0とかなのか、結構古いね

571:デフォルトの名無しさん
21/05/10 23:22:34.42 rt96Jr4B.net
playground、いつのまにか以前書いたコードが残るようになっててなんかうざったいんだけど、
初期のhello worldの状態に戻すのってどうやるの?(クッキー削除とかはなしで

572:デフォルトの名無しさん
21/05/10 23:29:40.57 4UvCiOpM.net
んな面倒なことするくらいならrustupインストールすりゃええやん

573:デフォルトの名無しさん
21/05/11 00:01:56.34 bFiGc/cl.net
>>549
ファイルへの書き込みは返り値promise等でもらっておいて他の作業を進めて
どうしても書き込み完了していないと作業を先へ進めてはいけないところでようやくawait等することで
例外処理も遅延(手続き的な後ろ化と多段時の上位化)ができますよね
あとOSカーネル内の話は
例外と割り込みをごっちゃにしているように見えます
いずれにせよカーネル内ではtry例外使わずとも多段にエラー返り値を返していけばいいだけでしょう
エラー割り込み時もメモリ不足もシステムコールならエラー値返すわけですし

574:はちみつ餃子
21/05/11 02:56:09.45 sf6ddr3r.net
>>555
Rust はそれほど難しいというわけでもないと思う。
C に ML 風の型システムを付けたって程度。
普通のプログラマにとって目新しいと言えるのはライフタイムの概念くらい。
でもそのひとつが馴染み無さ過ぎるというか、
他の言語では意識せずに済まさせようとしてきたところを
あえて露骨に管理しようとしてるところがしんどいとは感じるかもね。

575:デフォルトの名無しさん
21/05/11 03:24:21.67 BXZYJdJz.net
>>564
Rustのライフタイムは、鶏と卵の関係の様な部分で言語の動作が分からない。
どっちがどっちに影響を与えているのかの部分が。
自動判定の仕組みも一部だけ説明されていて一般法則が書いておらず、その場しのぎ的な言語仕様なのかもしれない。

576:デフォルトの名無しさん
21/05/11 04:47:35.34 +XHXxVLE.net
non lexical lifetimeでググれば詳細な仕様出てくるだろ

577:デフォルトの名無しさん
21/05/11 05:08:47.84 BXZYJdJz.net
>>566
出てこないと思うが。

578:デフォルトの名無しさん
21/05/11 08:24:36.99 hJ8vQWaq.net
>>561
通りすがりですが、保存せずにただ試すだけなら
1.シークレットモードで新規タブ
2.playgroundのサイトを開く(ブックマーク登録からとか)
3.コード入力かコピペ作業
でどうでしょうか?

579:デフォルトの名無しさん
21/05/11 10:55:34.68 nxCZKmfr.net
>>567
nll rfcで検索したら出てくるよ

580:デフォルトの名無しさん
21/05/11 12:37:05.27 BXZYJdJz.net
>>569
そこには例が書かれてるだけで、数学みたいな意味でのちゃんとした厳密仕様は書いてないと思うんだよ。
Rustのライフタイムは数学規則のように機械的にパターンで処理できるような一般化された規則にはなってないという意味において。

581:デフォルトの名無しさん
21/05/11 12:42:48.49 yczyG8TY.net
厳密な仕様があるのは理想だけど、規格化された言語ですら数学的に厳密な仕様なんて存在しないしな
最終的にはCoqのソースコードで示される、とかはあるかもしれないが

582:デフォルトの名無しさん
21/05/11 12:47:18.80 BXZYJdJz.net
>>571
CやC++は数学的なパターンで処理できるようになってる。
そこにヒューリスティックなものは入ってない。

583:デフォルトの名無しさん
21/05/11 12:55:41.33 r1e7nJBc.net
the abstract syntax tree でのライフタイムの解析から
the control-flow graph でのライフタイムの解析にしたって言ってるから
かなりマシン語に近いとこで判定してるってことだわな。
ここにいる奴に聞くだけ無駄w

584:デフォルトの名無しさん
21/05/11 18:36:37.89 efUOVNNI.net
>>571
純lispくらいかね。
あるいはBrainfuckとか。

585:デフォルトの名無しさん
21/05/11 18:56:14.78 jWdOrz94.net
issue #25860って未だに解決されてないんだよね?
行きあたりばったりでライフタイム仕様決めてきた結果w

586:デフォルトの名無しさん
21/05/11 19:03:56.93 wl2jzTgT.net
Rustと原子力発電は人類には早すぎたんや…

587:デフォルトの名無しさん
21/05/11 19:52:59.74 8+nUEbRM.net
Rust嫌う人ってなんでみんな #25860 の話するのって言われてんぞ

588:デフォルトの名無しさん
21/05/11 22:03:42.47 1AWmjfgF.net
>>576
太陽光発電は、ある意味原子力発電と言えるのではないだろうか。

589:デフォルトの名無しさん
21/05/12 08:51:30.06 1N4enQMj.net
Rust 2021 Editionは10月リリース予定
URLリンク(blog.rust-lang.org)

590:デフォルトの名無しさん
21/05/12 10:38:41.98 qFi3vx5o.net
1.56.0からか

591:デフォルトの名無しさん
21/05/12 10:40:17.60 1N4enQMj.net
2021 Edition ざっと読んでみたけど、次の2点以外は些末な変更だな
for e in [1, 2, 3] {}
がエラーにならなくなる
(IntoIterator for arrays)
クロージャーが構造体をフィールド単位でキャプチャーするようになる
(Disjoint capture in closures)

592:デフォルトの名無しさん
21/05/12 21:45:20.66 rLfxFtSp.net
2018で勉強してますが仕様変わりますか?

593:デフォルトの名無しさん
21/05/12 22:08:40.92 fyx4mRuh.net
URLリンク(www.google.com)
「Windows用Rust」のバージョン0.9がリリース
何か誤解を与えそうな記事タイトルだ

594:デフォルトの名無しさん
21/05/13 00:09:46.25 JmJXN960.net
リポジトリ名的にwindows-rsのが適語か?

595:デフォルトの名無しさん
21/05/13 00:34:31.53 hcgdol/O.net
>>582
マイナーチェンジだし2018も継続して使えるし特に問題ないよ

596:デフォルトの名無しさん
21/05/13 00:46:54.51 oO6nJ4P1.net
何年か前なら喜んでたんだけどな、どうしよ何の興味も沸かない
Docker触り始めた辺りからWindows用は趣味でも書かなくなってしまった…

597:デフォルトの名無しさん
21/05/13 07:59:13.00 OSZsGS3x.net
>>583 多分windowsクレートの説明文のRust for Windowsの直訳だとは思うけどこれは誤解するわ

598:デフォルトの名無しさん
21/05/13 11:06:57.34 mHvpW2NY.net
Rust for Windowsという名前がミスリーディング
(A) Rust (crate) for Windows (development)をRust for Windowsに略したら誰でも誤解する
狙ってるのかもしれないが
Windows API bindgen for Rustあたりが適当

599:デフォルトの名無しさん
21/05/13 12:50:12.69 OSZsGS3x.net
このクレート普通にソフト作るのに使ったら移植性無くなるからライブラリ用かな?

600:デフォルトの名無しさん
21/05/13 14:22:28.44 p1C3K64x.net
防衛省が中国のハッカーとやり合える人材を募集中 年収最高2000万円
スレリンク(poverty板)

601:デフォルトの名無しさん
21/05/13 14:34:12.09 EmFUnxGS.net
クラッカーにうってつけじゃないか

602:デフォルトの名無しさん
21/05/13 15:04:14.32 67slJFqF.net
年収最低はいくらからですかね

603:デフォルトの名無しさん
21/05/13 15:10:36.53 ENK4De8l.net
最高が2000万円ってだけね。。
こういうので平気で300万円とかいい出すのが今の日本やで。

604:デフォルトの名無しさん
21/05/13 18:36:08.63 hcgdol/O.net
>>589
Windows専用のアプリを作る用途もあるのでは
一般的ではないかもだけど

605:デフォルトの名無しさん
21/05/13 18:39:15.84 oBGJ4/nI.net
Rust for Windowsを欲しがったのはMicrosoft自身だろう
既にVSのインストーラー内部などでRust使用中なので

606:デフォルトの名無しさん
21/05/13 19:27:59.33 4YggBXb4.net
rust for windowsで作る本作ってくださいお願いします

607:デフォルトの名無しさん
21/05/13 19:29:13.29 vZYCxDQa.net
>>594 Windows専用のアプリが作りたいならC#でも使えばいいと思うけど...

608:デフォルトの名無しさん
21/05/13 19:3


609:0:20.99 ID:vZYCxDQa.net



610:デフォルトの名無しさん
21/05/13 19:30:58.76 vZYCxDQa.net
おっとミスって2回書き込んでしまった
失礼

611:デフォルトの名無しさん
21/05/13 20:59:04.54 vzWwtH6K.net
>>590
そういう技術者にも射撃練習とかやらせるのだろうか?

612:デフォルトの名無しさん
21/05/13 21:40:48.09 NNemQTGQ.net
>>595
もうメジャーな用途で使われてんのか

613:デフォルトの名無しさん
21/05/13 21:45:54.80 vzWwtH6K.net
windowsもそろそろNTカーネルを捨てる時期が来るだろうし色々模索はしてるんだろうな

614:デフォルトの名無しさん
21/05/13 21:57:03.92 WjgS+eLl.net
もし仮にNTカーネル捨てたとしてLinuxカーネル一択だと思うがな

615:デフォルトの名無しさん
21/05/13 22:08:50.47 vzWwtH6K.net
Linuxへの接近はここ数年目立ってるし無くはない話だな
独占市場と過去の互換性を捨てきれるか
仮想環境で過去の互換性を維持することも考えられる

616:デフォルトの名無しさん
21/05/14 08:10:59.62 FBkeGRqg.net
>>604
NTカーネル捨てるのはビジネスとして有り得ない。
せいぜいwsl路線を強化してlinuxカーネルを取り込んでいく方向だろ。

617:デフォルトの名無しさん
21/05/14 08:37:43.19 BI4FO4HO.net
カーネルを捨てて切り替えるとか出来るわけないだろ

618:デフォルトの名無しさん
21/05/14 08:52:11.24 9b8NT0Ot.net
3才児が「ぼくはうちゅうひこうしになるんだ!」って言ってるようなもんだから生暖かく見守ってやれ

619:デフォルトの名無しさん
21/05/14 10:22:28.00 6SQ932Rj.net
OSカーネルに対するコンプレックスがすごい人がいるんだろ。
この前のlinuxドライバに関する議論でもそういうの感じるわ

620:デフォルトの名無しさん
21/05/14 11:10:24.23 bMDjGf5Y.net
rustがgolangより人気が出ると思っていいですか?

621:デフォルトの名無しさん
21/05/14 11:14:13.19 5xLewDJ4.net
>>609
Goはガーベッジコレクションがあるから?

622:デフォルトの名無しさん
21/05/14 11:29:33.68 6SQ932Rj.net
GCとランタイム速度に困ったことのある奴だけ気にすればええ。

623:デフォルトの名無しさん
21/05/14 13:23:04.93 TMXA3cLH.net
goとrustどっちが良いか迷うならgoやっといた方が潰しが効くと思う
自分はrust好きだからrust使うが

624:デフォルトの名無しさん
21/05/14 14:57:53.07 85G96vHL.net
両方やっとけ

625:デフォルトの名無しさん
21/05/14 15:16:48.50 678S/iU6.net
なんでマイナー言語のはずのgoがよく言及されるようになったのかと思っていたら、AWSで使える言語の一つになっていた。
Azureでも使えるようだ。

626:デフォルトの名無しさん
21/05/14 15:45:19.02 WB7bczPS.net
goがマイナー。。。..

627:デフォルトの名無しさん
21/05/14 15:46:03.80 BI4FO4HO.net
サーバープログラムみたいな閉じた環境で、出来るここまでと決まってて
要らないこと考えたくないなら制約された言語選んだほうが良いかもな

628:デフォルトの名無しさん
21/05/14 15:47:17.23 6SQ932Rj.net
goでほとんど問題ないんだが、それだとrustの出番なくなっちゃうからね。

629:デフォルトの名無しさん
21/05/14 16:15:48.73 1T0ViQH9.net
Go言語がマイナーならこの言語はどんだけマイナーになっちゃうのよ

630:デフォルトの名無しさん
21/05/14 16:25:56.91 Z0ePaP6y.net
goとrustの違いが分からないような知識量ならgoやった方が不幸にならないかと

631:デフォルトの名無しさん
21/05/14 16:48:29.92 678S/iU6.net
参照型はローカル変数にだけ入れて一時的な目的だけに使うことに徹してスクリプト言語の様な書き方だけに専念すればRustはスクリプト言語であるかのように使えて、習得は難しくないかも。
参照型を構造体の中に入れようとしたとたんCやC++では考える必要の無かった難しい問題が生じる。

632:デフォルトの名無しさん
21/05/14 17:00:31.58 dvkZe6EK.net
メジャー言語
c java vba

633:デフォルトの名無しさん
21/05/14 17:40:01.47 N2rlLeCr.net
Rustを勉強したら低レベルが理解出来る!!!わけねえだろ
URLリンク(www.akiradeveloper.com)

634:デフォルトの名無しさん
21/05/14 19:36:04.21 5xLewDJ4.net
例えばWeb系ならばRustがベスト
WasmでGC抱える言語をわざわざ選ぶメリットないからね

635:デフォルトの名無しさん
21/05/14 19:44:16.91 6SQ932Rj.net
こういう詐欺師が普通におるからrustは信用できんわ

636:デフォルトの名無しさん
21/05/14 19:51:45.41 WB7bczPS.net
rustに対するコンプレックスすごい人いるね

637:デフォルトの名無しさん
21/05/14 20:26:02.54 0Bqgd+6M.net
詐欺師はどこにでもいるからな
とはいえ、webならwasmは正しくないとは思うがwasmならrustは結構正しいと思う

638:デフォルトの名無しさん
21/05/14 20:32:01.67 6SQ932Rj.net
wasm,rustでまともに開発してたら絶対そんなこと思わんわ。。どいつもこいつも馬鹿すぎる

639:デフォルトの名無しさん
21/05/14 20:40:33.59 WB7bczPS.net
それで、どんなまともなものを作っているんですか

640:デフォルトの名無しさん
21/05/14 20:46:14.11 5xLewDJ4.net
>>624
とこが詐欺?
あなたはWebブラウザ上のWasmでRustではなくGoを用いているのですか?

641:デフォルトの名無しさん
21/05/14 21:18:15.11 TMXA3cLH.net
>>627
それはあなたがまともにrust使えてないだけなんじゃないですかねぇ

642:デフォルトの名無しさん
21/05/14 21:22:56.09 yxEaYkUD.net
話が具体的で説得力がある

643:デフォルトの名無しさん
21/05/14 21:38:43.40 2w1FBHD8.net
>>572
形式的に書けているのは構文規則だけで
意味規則は自然言語で書かれているやんけ

644:デフォルトの名無しさん
21/05/14 22:59:38.34 R2Ezzb7N.net
「Rustはスクリプト的に書ける」とかいう謎の言葉言う奴沢山いるけどなんぞ?
同一人物か?

645:デフォルトの名無しさん
21/05/14 23:07:50.74 TMXA3cLH.net
我々が知らないところでevcxrが流行ってるのかもしれない

646:デフォルトの名無しさん
21/05/14 23:23:46.43 72ZodHJE.net
google謹製のREPLね
エベクサ?

647:デフォルトの名無しさん
21/05/15 02:09:59.05 BphhllcO.net
>>633
Rubyと同じようなメソッドチェーンを使ったコードを見かけたから。

648:デフォルトの名無しさん
21/05/15 03:17:16.69 vuo6fbRn.net
ドットでメソッド呼び出しする言語は大概そういうライブラリ設計あるでしょ

649:デフォルトの名無しさん
21/05/15 11:05:39.24 DTE+piln.net
>>637
C++やJavaでは見たこと無い。
JSでも余り見かけない。

650:デフォルトの名無しさん
21/05/15 11:12:58.76 Y+SvMVkX.net
そもそもメソッドチェーンって「スクリプト的」なのか?

651:デフォルトの名無しさん
21/05/15 11:24:14.14 C+CtGbiq.net
前々からヤベェやつだとは思ってたが
レベルの低さが想像をはるかに超えてた

652:デフォルトの名無しさん
21/05/15 11:27:04.30 MS0dCBGJ.net
c言語みたいにcsvパーサーも自前で用意するような環境だとそらスクリプト的だろうね。

653:デフォルトの名無しさん
21/05/15 12:00:43.05 A3vQNOxR.net
unityとかUEがrustに対応しないかなあ

654:デフォルトの名無しさん
21/05/15 12:00:58.11 ZgJC7yuF.net
cargoみたいなパッケージマネージャがあるのもスクリプト的な要素のうちなのか?

655:デフォルトの名無しさん
21/05/15 12:10:16.46 MS0dCBGJ.net
cargoは低レイヤー慣れてる人からすれば邪魔でしかないけどね。

656:デフォルトの名無しさん
21/05/15 12:20:50.35 DTE+piln.net
SourceforgeなどでRustが好きといっている人の大部分はレベルが低いだろう。
そもそもこの世の中、大多数から受けるものにレベルが高いものがあったためしがない。
好きな言語ランキング上位のJS、Pythonも初心者向け言語であることは誰もが認めることだし。

657:デフォルトの名無しさん
21/05/15 12:40:11.21 UqP25wMI.net
sourceforge???
stackoverflowの調査かなんかと勘違いしたの?

658:デフォルトの名無しさん
21/05/15 12:41:57.93 ZgJC7yuF.net
>>644
どういうこと?ベアメタル向けでもcargo使うのが主流だと思っていた

659:デフォルトの名無しさん
21/05/15 12:47:56.99 ZgJC7yuF.net
>>645
使用者のレベルの高低と言語のレベル(?)の高低は一致するという主張かな?
言語のレベルが高いというのが最先端のテクノロジーを取り込むという意味ならrustの目指すところではないと思う
他の言語で実証されたコンセプトを取り込むと宣言してる(た?)はず
高レベルな言語が必要な人はこんな普及言語じゃなくてもっと尖った言語を使うか自分で作るべきなのでは

660:デフォルトの名無しさん
21/05/15 12:49:38.36 DTE+piln.net
>>646
ああ、そっちだった。
Stackoverflowも来てる人の頭の良さは一般大衆と同じくらいだから同じ。

661:デフォルトの名無しさん
21/05/15 12:53:14.42 DTE+piln.net
>>648
そういうことじゃなくて、
・Rustをほとんど使っても見てないのに勝手に「好き」と言っていることが分かってる。
・Stackoverflowのような沢山の人が集まる場所の調査では、必ずJSやPythonのような初心者向けの言語が人気となるわけだから、そこの人々が好きだと思う言語は、JSやPythonのような感覚で使えると勝手に思い込んである蓋然性が高い。
 ただし、現実はRustは実際には使ってないのに勝手に言っている。
ということ。

662:デフォルトの名無しさん
21/05/15 13:20:44.67 YOv93GRR.net
stackoverflowの調査の話なら、調査内容を勘違いしている
あれは「今Rustを使っている人が、今後もRustを使い続けたいかどうか」のアンケート結果をmost lovedと言ってるだけ
だからJSやPythonユーザの意見は入ってない
そもそもloveって言葉に語弊があるし、日本語にしたときに「人気の」とかなって余計訳がわからなくなってる

663:デフォルトの名無しさん
21/05/15 13:25:20.53 YOv93GRR.net
たぶん「最も嫌嫌使っている人が少ない言語」みたいなのが正確な気がするな

664:デフォルトの名無しさん
21/05/15 14:15:44.60 MW7lNw7H.net
「今使ってる人が次も使いたいと思うか?」ってJetBrainsの調査でも毎回入れてくる項目だな
海外のアンケートではよく見るやつ

665:デフォルトの名無しさん
21/05/15 14:17:03.39 DTE+piln.net
>>651
もし前半の通りなら、今Rustを使ってる人なんて極一握りの物好きだけだから
「love」なのは当たり前で調査結果が意味が無い。

666:デフォルトの名無しさん
21/05/15 14:19:45.06 eXXN4CKf.net
一生でどれか一つのプログラミング言語しか覚えられないとして
Rust選ぶ人いますか?
選択したとして別にその言語がいきなりマスターできるわけでなく
ただその言語しか覚えられないというだけですが

667:デフォルトの名無しさん
21/05/15 14:23:36.58 DTE+piln.net
今rustを使ってる人って、自ら進んで使おうとした人に限られるから
嫌いな人がほとんどいないのは当たり前だから、調査結果にバイアスが
掛かりすぎていることになるな。

668:はちみつ餃子
21/05/15 15:05:35.65 pVi51x8H.net
そういえば C++ でメンバ関数の評価順序に関して設計者も気づいてなかった考慮漏れが見つかった
(よくあるパターンが実際には未定義だった) って話があったな。
URLリンク(www.open-std.org)
C++17 で修正されているはずだけど。
宣言的な表現や関数的な表現をプログラミング言語に取り込む試みは数多いが
現実は順序からは逃れられぬのだ……。

669:デフォルトの名無しさん
21/05/15 15:16:25.44 HcoKJY+/.net
Rustがスクリプト的に書けるかどうかはおいといて、
個人用のツール書く言語をPythonからRustに乗り換えたっつー話は一応あるな
URLリンク(hayatoito.github.io)

670:デフォルトの名無しさん
21/05/15 15:20:52.26 DTE+piln.net
>>658
Googleがnode.jsで書いていたものをRustにしたと聞いたぞ。

671:デフォルトの名無しさん
21/05/15 15:23:50.02 TrqVEcq2.net
全部書き直すのは逆に効率悪そう
速度的にキツイ場合のみでいいんじゃないか


672:?



673:デフォルトの名無しさん
21/05/15 15:32:34.68 H/3gPTTR.net
どちらかといえば速度よりも変更頻度が動機になると思う
静的チェックツールも増えてはいるけどコンパイル型はいじる時の安心感が違う

674:はちみつ餃子
21/05/15 15:37:59.52 pVi51x8H.net
>>660
言語を跨いで呼出すときはその境界で色々な処理が挟まったりもするので、
まだらに入り乱れるような形になるとそれはそれで実行性能の足を引っ張ることもある。
状況次第なので一概には言えないけど、言語を変更すると決めたなら
そこそこ大きい単位で乗り換えるのが妥当な場合は結構あると思うよ。

675:デフォルトの名無しさん
21/05/15 17:32:17.46 jwQMP5Oj.net
>>661
それはあるね
個人用のツールだとそんなに真面目にテストも書かないから
動的型だと忘れた頃に改修したくなって詰む

676:デフォルトの名無しさん
21/05/15 18:53:39.15 IpomZGOJ.net
>>642
MSがdotnet対応のRust#出したらUnityワンチャンあるんやない?

677:デフォルトの名無しさん
21/05/15 19:10:58.08 Y+SvMVkX.net
そこはRust/CLIで。

678:デフォルトの名無しさん
21/05/15 21:52:45.98 TrqVEcq2.net
GCのあるrustに存在意義などない

679:デフォルトの名無しさん
21/05/15 22:13:28.16 Y+SvMVkX.net
GCとデストラクタが共存するC++/CLIはなかなか興味深い言語だった。

680:デフォルトの名無しさん
21/05/16 11:00:47.47 9EXRd3vl.net
RustのGCって初期はまた復活されるかもーみたいなノリじゃなかったっけ?

681:デフォルトの名無しさん
21/05/16 11:12:01.38 SPtqbmz9.net
RC関連についてはやるとか?

682:デフォルトの名無しさん
21/05/16 12:07:45.66 MDYO1Tug.net
@ pointerとか ~ pointerとかあった頃の話?

683:デフォルトの名無しさん
21/05/16 15:06:48.66 JH7fFMWR.net
>>665
確かにそっちか
>>666
GCがあるRustって言うよりはunsafeを外部リンクで呼び出してるようなもんだろ

684:デフォルトの名無しさん
21/05/17 10:53:44.01 ZSkTvtbm.net
rustが覇権を取るにはPHPみたいにドキュメントの翻訳をたくさん作ること
そしてサンプルコードを盛り込むこと

685:デフォルトの名無しさん
21/05/18 19:40:20.00 A1yOEMnk.net
>2021 Editionは2021年10月にリリースされる。今回のエディションは「Rustの使用感を大きく改善する」ものになるという
あんまり前にこんな発表しないでほしい
やる気なくなる

686:デフォルトの名無しさん
21/05/18 19:44:35.79 Gj41gD2H.net
>>673
ちゃんと発表資料見れば分かるけど、大して使用感変わらんよ
クロージャー使いまくりの人が一番恩恵を受けるかな

687:デフォルトの名無しさん
21/05/18 20:19:55.73 Z0RWJbQc.net
所有権は移動するときのほうにマークが出るべきなんじゃあ

688:デフォルトの名無しさん
21/05/19 07:47:56.56 X700JkCT.net
まぁコストかかるのはコピーだし

689:デフォルトの名無しさん
21/05/19 08:05:05.13 o3bqBTNO.net
Rustの真似をしようとする言語がないのがふしぎだ

690:デフォルトの名無しさん
21/05/19 12:30:25.52 HmkTJiD6.net
URLリンク(en.m.wikipedia.org)(programming_language)
wikipedia見ただけだけど Crystal, Elm

691:デフォルトの名無しさん
21/05/19 12:30:46.25 HmkTJiD6.net
など影響を与えた言語は列挙されてた

692:デフォルトの名無しさん
21/05/19 12:42:47.10 9T1L9lvJ.net
>>678
Elmのどこが?と思ってソースを読んだら
関数型言語なら大体持ってるEither型の名前を Result, Ok, Error にしたところがRust由来とな
うーむ持ってきたのは名前だけなのにInfluencedか

693:デフォルトの名無しさん
21/05/19 12:59:40.27 u9Tr9lyP.net
Gleam
URLリンク(gleam.run)
OwnershipやLifetimeの考え方を採用した言語はまだ聞いたことがない

694:デフォルトの名無しさん
21/05/19 13:11:21.07 bDX8SBSl.net
所有権の考え方を採用している言語としてはC++などがあります

695:デフォルトの名無しさん
21/05/19 14:00:04.90 NOe9g/vN.net
まあインスタンスの共有については何らかの言語サポートが入ってもおかしくないかもね

696:デフォルトの名無しさん
21/05/20 01:09:22.49 WwVMFHF+.net
DにもOwnership入ったとか小耳に挟んだだけなら

697:デフォルトの名無しさん
21/05/20 17:03:02.09 VKAk8Olu.net
URLリンク(forest.watch.impress.co.jp)
凄いね

698:デフォルトの名無しさん
21/05/20 17:06:31.55 13olK3Lw.net
>>685
UIがReactというのが残念

699:デフォルトの名無しさん
21/05/20 18:20:18.69 PiC1UW/o.net
逆に何ならいいんだよ

700:デフォルトの名無しさん
21/05/20 18:33:43.55 UXe9/StR.net
GUIフレームワークをRustで作るうまみあまりなさそう

701:デフォルトの名無しさん
21/05/20 19:39:25.12 QrP75Wi1.net
Rustで作ってあるなら絶対大丈夫だな!

702:デフォルトの名無しさん
21/05/20 22:57:01.82 HbCDuKW4.net
設計がクソだとダメ
ダメなヤツはなにやってもダメ

703:デフォルトの名無しさん
21/05/21 11:45:49.77 r1IBz1vL.net
>>538
(1)もちろん例外を使わずとも関数呼び出し等がエラー値を返すことで全て実現できます
(2)ところがエラー値が返ってくると毎回if文やmatch等でエラー時はそこですぐreturnする等の処理を書く必要があって面倒かつコードが醜いため例外の使用が好まれました
(3)Rustでは関数の返り値型をResult<T,E>とすることに加えて「?」オペレーター(旧try!マクロ)を使うことで(2)の処理を自動化しました
つまり関数等呼び出し毎にifやmatch等で返り値エラーチェック&returnの記述をしなくても末尾に「?」を記述するだけで済みます
これでチェーンも出来て具体的には
b = a.hage()?.hige()?.hoge()?
と書くだけでhage()でエラーが返れば早期エラーreturnしますしhige()やhoge()でエラーでも同様です
関数の返り値型がResult<T,E>であることが使用条件です
これはもちろん正常値の<T>型とエラー<E>型のenumです
これらにより関数を多段に深く呼び出していても深い所でのエラーがすぐにreturnを多段にしてエラーが戻って来ます
したがってRustでは例外を使わなくても困らないのです

704:デフォルトの名無しさん
21/05/21 13:37:02.96 J6y23PLS.net
すまんrust新参者なんだが、Rust By Exampleのコードいじって勉強してて、以下のコードが疑問に感じられた。
以下のプログラムはmain関数内のif文は実行されないとは明らかなんやが、それでもsubの行でいわゆるuse-after-freeのコンパイルエラーが出る。
これはif文が実行されなくてもdropは実行されるということなんですか?
下のコードみたいにuse-after-freeになるかならないかがif文の条件満たすかどうかによって決まるようなプログラムでも
rustでは一緒くたにuse-after-freeになるとみなされるってことなんですね?
そう考えればそこまで賢くないコンパイラですね
struct Droppable {
id: &'static i8,
}
impl Drop for Droppable {
fn drop(&mut self) {
println!("> Dropping {}", self.id);
}
}
fn sub(d: &Droppable) {
if *d.id == 0 {
drop(d);
println!("> Test {}", d.id);
}
}
fn main() {
let _a = Droppable { id: &0 };
if *_a.id == 1 {
drop(_a);
}
sub(&_a);
}

705:デフォルトの名無しさん
21/05/21 13:4


706:0:53.52 ID:J6y23PLS.net



707:デフォルトの名無しさん
21/05/21 13:44:28.52 J6y23PLS.net
Compiling playground v0.0.1 (/playground)
error[E0382]: borrow of moved value: `_a`
--> src/main.rs:22:9
|
| let _a = Droppable { id: &0 };
| -- move occurs because `_a` has type `Droppable`, which does not implement the `Copy` trait
| if *_a.id == 1 {
| drop(_a);
| -- value moved here
| }
| sub(&_a);
| ^^^ value borrowed here after move //ここでuse-after-free errorが発生!
error: aborting due to previous error
For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground`
To learn more, run the command again with --verbose.
見やすくした

708:デフォルトの名無しさん
21/05/21 14:49:33.29 vx/ErwhM.net
意味のないコードだよ

709:デフォルトの名無しさん
21/05/21 14:53:16.15 PNtD97K1.net
コンパイラは別に値まで見ないからな
clippyが意味のない分岐だよと指摘してくれるのかどうかは知らんが

710:デフォルトの名無しさん
21/05/21 14:55:24.20 HgMuIEwp.net
>>692
基本的に条件分岐はpredがコンパイル時に評価できる場合でも true/false 両方あり得るものとして扱われるよ
その後の最適化フェーズであり得ないルートは除去されるだろうけど最適化の結果でコンパイルエラー差異が出ないようにする考え方なんだと思われる
無限ループ専用の構文であるloopが導入された背景もたぶんこのあたりにある

711:デフォルトの名無しさん
21/05/21 15:52:58.09 J6y23PLS.net
>>697
trueのときもdrop、falseのときもdropされるとみなされるということは、
if文によってheap領域で確保しているメモリを解放するかしないか場合分けできないってことじゃん
それって不便では?

712:デフォルトの名無しさん
21/05/21 16:14:23.61 qRzkKAr2.net
>>698 これ元のコード見てみ
これifの条件がtrueだろうがfalseだろうがsub(&_a);は実行されるやん
ifの条件がfalseのときには問題なく実行できるけど、もしifの条件がtrueになって_aがdropされてしまった後にsub(&_a);が実行されてしまうと開放された値を使うことになる
だからRustコンパイラはエラーを吐くんだよ

713:デフォルトの名無しさん
21/05/21 16:15:51.92 91Y2FzX3.net
いや、普通に場合分けはできるが…
どちらかというとifの条件を変えるたびにコンパイルが通ったり通らなかったりするほうが不便では?
そこにifがあるってことは(将来的にとか何らかの条件で)実行される可能性があるからあるんでしょ
もし絶対に実行されないことが確定してるなら書く意味ないし

714:デフォルトの名無しさん
21/05/21 16:19:22.28 91Y2FzX3.net
場合分けしたいならこんな感じで
if *_a.id == 1 {
drop(_a);
} else {
sub(&_a);
}

715:デフォルトの名無しさん
21/05/21 17:42:19.92 J6y23PLS.net
>>700
言ってる意味がさっぱりわからん
>>692のプログラムにあるとおり
現実問題、将来的に決して実行されるわけがないif文というものは存在するし
if文があるというのは実行される可能性のあるの十分条件でもなければ必要条件でもなわけでもないんやが。
ワイが言いたいのは仮にrustの型システムを無視して>>692のコードをそのままコンパイルしたとしても
if文は実行されないわけだから安全なはずなものまでを省いているというところが不思議だってことや
つまりuse-after-freeバグが現実には起きないコードまでもif文の他の条件でUAFバグが起きるがために
ひとまとめにUAFが起きる�


716:ニみなすrustコンパイラの姿勢がif文である条件のときだけfreeするコードを書くのを認めないようにみえるという ワイの感想に繋がってるわけでして



717:デフォルトの名無しさん
21/05/21 17:53:39.45 IHGXJo1X.net
use of moved valueやborrow of moved valueを
use-after-freeとして理解してるのがそもそも間違ってる
The Bookを読んでLifetimeとOwnershipを復習してくれ

718:デフォルトの名無しさん
21/05/21 18:00:55.07 J6y23PLS.net
>>692のコードをcに書き直してみたらこうなる
} Droppable;
void drop(Droppable* d) {
printf("> Dropping %d", d->id);
free(d);
}
void sub(Droppable* d) {
if (d->id == 0) {
//free(d);
printf("> Test %d", d->id);
}
}
int main() {
Droppable* _a;
_a = malloc(sizeof(Droppable));
_a->id = 0;
if (_a->id == 1) {
drop(_a);
}
sub(_a);
}

719:デフォルトの名無しさん
21/05/21 18:01:46.42 J6y23PLS.net
これはrustでは弾かれるはずの「if文のある条件のときだけヒープのある部分をfree」というコードのはずだが
安全なCのプログラムや コンパイルは通るしランタイムエラーも起こさない。
メモリ安全なプログラムの中では、cで書けるプログラムのほうがrustで書けるプログラムより広いんだね
rustはメモリ安全なcのプログラムと同等な処理を書けない部分もあって不便じゃないかっていうのが結局のところワイの疑問になるんや
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや?
メモリ安全性を損なってるわけでもない処理ではないはずなんやがrustのコンパイラははじくぞ?

720:デフォルトの名無しさん
21/05/21 18:03:27.13 J6y23PLS.net
#include <stdio.h>
#include <stdlib.h>
typedef struct {
int id;
} Droppable;
void drop(Droppable* d) {
printf("> Dropping %d", d->id);
free(d);
}
void sub(Droppable* d) {
if (d->id == 0) {
//free(d);
printf("> Test %d", d->id);
}
}
int main() {
Droppable* _a;
_a = malloc(sizeof(Droppable));
_a->id = 0;
if (_a->id == 1) {
drop(_a);
}
sub(_a);
}
ほい完全版

721:デフォルトの名無しさん
21/05/21 18:06:23.36 p9FphGnI.net
>>705
unsafe使え、というかもうちょっと具体的な例じゃないと困る
今まで出された例だと「最初から絶対通らないの分かってるならif文消せばいい」としか思えないので

722:デフォルトの名無しさん
21/05/21 18:12:17.78 91Y2FzX3.net
別にわざわざCで書いてもらわなくても安全なのは分かるよ
今のRustコンパイラで通らないのはボローチェッカーが最適化前にあるからなんで
部分的にでも先に最適化すれば通るようにはできるだろう
ただそれをしたい動機が分からない
本当にifが実行される可能性が一切ないなら単に消せばいい、といしか言いようがないので

723:デフォルトの名無しさん
21/05/21 18:14:06.78 J6y23PLS.net
>>703
それただの論点そらしだよね
UAFってrustの独特なメモリ管理手法と相反する用語ではないし
use of moved valueやborrow of moved valueもUAFを阻止するためのものだよね
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや?

724:デフォルトの名無しさん
21/05/21 18:18:59.35 p9FphGnI.net
>>709
DroppableのメンバにBox<i8>持たせろ
仮に"drop"された後でもsubが正常に動くことが期待されているなら、そこで使うべきなのはdropではない

725:デフォルトの名無しさん
21/05/21 18:22:54.40 91Y2FzX3.net
というか >>701 で書いたif/elseの例はちゃんと「if文のある条件のときだけヒープのある部分をfree」になっているのに何か不満なのか

726:デフォルトの名無しさん
21/05/21 18:24:13.35 IHGXJo1X.net
>>709
UAFを阻止するためだけにあるものじゃないから
やり方は>>701で教えてくれてるやろ
とりあえずThe Book読んでね

727:デフォルトの名無しさん
21/05/21 18:31:38.95 p9FphGnI.net
>>709
これでどうですか?
URLリンク(play.rust-lang.org)

728:デフォルトの名無しさん
21/05/21 18:38:40.69 J6y23PLS.net
>>711
そうやん
rustって不思議やね

729:デフォルトの名無しさん
21/05/21 18:44:49.25 J6y23PLS.net
解決しました。
なにはともあれありがとうございました。>>701の方に救われました。
ここまで関わってくださった皆様まことに協力ありがとうございました。感謝いたします。

730:デフォルトの名無しさん
21/05/21 19:24:50.36 91Y2FzX3.net
「理論的に安全な任意のコードは通るべき」ってイメージだったのかな
実際にはそんなことはなくて、上の例のようなコードを通すためには色々なトレードオフがあるから
単に「理論的に安全」ってだけで無条件に実装されることはない
もっと具体的なユースケースがあって、みんなが「これは通らないと不便だよね」ってなったものが実装される
数年前に実装されたnon lexical lifetimesなんかはまさにその例だね

731:デフォルトの名無しさん
21/05/21 19:31:11.66 bfSFy0HM.net
はぎゃーん

732:デフォルトの名無しさん
21/05/21 21:43:48.32 HgMuIEwp.net
クロージャの disjoint capture が破壊的変更になるのは分かるんだけど最初からこうなってなかったのはなぜ?

733:デフォルトの名無しさん
21/05/21 22:34:26.09 vpqVq/KA.net
iter()とinto_iter()の使い分けが分からない
iter()じゃないといけない場合があるのは分かるんだが

734:デフォルトの名無しさん
21/05/21 22:49:37.59 +ok17UuV.net
into_iterは所有権を奪いItemを得ることができる
iterは&Itemを得る
他のintoで始まるものは所有権を奪うことになってる

735:デフォルトの名無しさん
21/05/21 23:22:44.96 qRzkKAr2.net
>>711 Rustコンパイラが問題視してるのは開放された値を使ってしまう可能性があることで、それが修正された >>701 のコードは問題ないから通る

736:デフォルトの名無しさん
21/05/22 00:04:28.82 yRhz4OAW.net
>>719
Rustでの変数の受け渡し方は
by (shared) reference、by mutable reference、by valueの3つなので
それに対応していろいろなものが3種類1セットになってる
イテレータならiter(), iter_mut(), into_iter()
クロージャならFn, FnMut, FnOnce
コンバージョンならAsRef, AsMut, From/Into

737:デフォルトの名無しさん
21/05/22 00:34:10.91 RuplHzwP.net
as_foo(), to_foo(), into_foo() の違いも覚えておくとよいかもね

738:デフォルトの名無しさん
21/05/22 00:45:11.88 yRhz4OAW.net
覚えておくとはいいのはそうだけど、そのセットは少し観点違うよね
URLリンク(rust-lang.github.io)

739:デフォルトの名無しさん
21/05/22 16:34:10.81 ma8sDMzI.net
Rustややこしいわぁ

740:デフォルトの名無しさん
21/05/22 20:26:18.21 UuUK8ShD.net
Rust慣れたあと他の言語行くと
良い作法が身についてて歓迎される、とかありますか?

741:デフォルトの名無しさん
21/05/22 20:30:50.12 18meLr+O.net
>>726
言語が異なれば同じことをするにも良い作法とされる方法は異なるだろうし、そんなに役に立たないかもよ。
むしろRustでは~と言い出すとかえってうるさがられる可能性も。

742:デフォルトの名無しさん
21/05/22 20:34:58.75 RuplHzwP.net
rustでは変数のshadowing当たり前のように使うけど他の言語では嫌がられそう

743:デフォルトの名無しさん
21/05/22 21:08:16.57 9BHHuuQy.net
let value = value;
とか他言語で書いたらアホだと思われるし

744:デフォルトの名無しさん
21/05/22 21:10:13.17 61y793Zl.net
Rustはメイン関数かその次の関数のローカル変数にリソースを保持する形にしがちじゃない?
他の言語だとあんまりやらない

745:デフォルトの名無しさん
21/05/23 03:12:09.36 1TnUlIAl.net
>>730
他の言語でも同じだよ
それとも禁断のグローバル変数を使う駄目パターンをRustでもしたいということ?

746:デフォルトの名無しさん
21/05/23 06:28:03.88 ApnxiBa8.net
pythonみたいな動的型付け言語ではよう見るけどさ
Rustではこんなん要らなくしてほしいわ

747:デフォルトの名無しさん
21/05/23 13:14:57.61 viOBOYhY.net
ライブラリによってはデータを持ち運ぶということが不可能だったりするからグローバル変数必須だったりするんだよな
(具体例: serenity)

748:デフォルトの名無しさん
21/05/23 13:33:01.51 1FznZ2H5.net
いや別に必須ではないだろ。

749:デフォルトの名無しさん
21/05/23 13:39:52.69 p3SEnqzU.net
log!() みたいなプログラムの各所から呼び出されるマクロや関数の実装の為には rust でも普通にグローバル変数使われているのでは
static 変数にするためには Sync が要求されたり mut にするために Mutex 使う必要があるから他の言語ほど気楽に使えないというだけで
グローバル変数そのものが禁断扱いされることはないかと
グローバル変数の濫用は他の言語同様嫌われるけどね

750:デフォルトの名無しさん
21/05/23 13:43:31.31 1TnUlIAl.net
一般的にどんな言語においても何らかの外部のライブラリを取り込む時には
何か一つのクラスとかオブジェクトとか構造体とかに閉じ込めてしまって
それ一つだけ持ち運ぶからグローバル変数を使うことは無いでしょう

751:デフォルトの名無しさん
21/05/23 16:18:03.34 ljEJPp90.net
>>735
static変数とglobal変数はスコープが違うだろ
global変数が悪とされるのは、そのスコープの広さだからね
いつどこで誰が変更するのか、また参照するのか、スコープが広ければ広いほど把握が困難になる
把握が困難になればなるほど、それだけバグを生む温床になる

752:デフォルトの名無しさん
21/05/23 18:34:32.71 1FznZ2H5.net
io周りは極論すればどう管理してもグローバルだからな。
プロジェクト毎に規約設ける以外にまともに管理する方法なんてない。

753:デフォルトの名無しさん
21/05/23 20:09:32.32 wHpcVS8W.net
>>735
そういやロガーの設定ってどこに保存されてるの?
debug!() 呼ぶたびにMutexロックしてるのかな?

754:デフォルトの名無しさん
21/05/24 12:11:21.84 1Toh/2dP.net
>>736
クラスの中に入れても、グローバル変数であることは避けられないし
どんな言語においてもグローバル変数は必要。

755:デフォルトの名無しさん
21/05/24 12:28:02.03 wwlvG9VZ.net
「:?」ってなんなんですか?
URLリンク(tourofrust.com)

756:デフォルトの名無しさん
21/05/24 12:49:55.25 KKN49LSI.net
>>741
デバッグ用のフォーマットで出力するという意味
詳しくは以下参照
URLリンク(doc.rust-lang.org)

757:デフォルトの名無しさん
21/05/24 13:24:07.35 JJaZh5wC.net
>>740
そんなことはないだろう。
確かにグローバルでも大して変わらんてものはあるけど、
loggerを引数で渡していくっていうような実装方法もある。

758:デフォルトの名無しさん
21/05/24 13:33:20.21 u2umy7DV.net
>>739
logクレートのstatic mut変数だね
ロックするのは初期化とレベル設定時だけ
出力時にロックするかどうかは実装次第

759:デフォルトの名無しさん
21/05/24 15:43:10.46 dukpbHqg.net
>>740
そのクラスの存在そのものがグローバル変数(相当)だという話?
それともそのクラスもしくはそのインスタンスをグローバル変数に入れて使うということ?
後者の意味ならば必要な範囲で引数として持ち歩けばグローバル変数を普通は使わないですよね。

760:はちみつ餃子
21/05/24 16:59:24.57 tdQ8iTTE.net
大事なのは抽象化がきちんとしているかどうか。
各部品が妥当な意味に分離されているかどうか。
グローバル変数がよくないのは色んなパーツから横断的に使われる可能性があって
部品が不必要に密結合していることの表れだからであって、
そのグローバル変数のアクセス範囲が妥当な範囲に制御されているなら問題じゃないよ。
過剰な密結合を解消せずにグローバル変数を引数に置き換えてたら
影響範囲が見えにくくなってもっと悪くなることだってありうる。
まあどういう場合なら妥当なのかってのは色々と意見はあると思うけど。

761:デフォルトの名無しさん
21/05/24 17:17:23.03 qqtJSk72.net
$_POSTはセーフ

762:デフォルトの名無しさん
21/05/24 17:21:32.94 Ig527IlE.net
>>746
まずは長くて区別しやすい名前に変えるのがスタートかね。

763:デフォルトの名無しさん
21/05/24 17:31:54.98 wwlvG9VZ.net
>>742
ありがとう!


764:なんか独特なのね



765:デフォルトの名無しさん
21/05/24 23:12:37.25 rI3Y4Uqa.net
関数型言語やったことないけど、Rustいけるかな
JavaとC++はそこそこ経験あり

766:デフォルトの名無しさん
21/05/24 23:17:37.88 zk4LoLUU.net
Java 8とかC++ 14以降くらいなら結構似たような機能も入ってるし
そこまで大変じゃない気がする

767:デフォルトの名無しさん
21/05/24 23:36:00.17 JJaZh5wC.net
c++はともかく、cくらいはやっぱ理解してた方が早道な気はする。

768:デフォルトの名無しさん
21/05/25 01:36:21.07 5vUI50kp.net
以下のような関数を作ったんですがmatchが多くてどうしようか考えていました
fn foo(x: Option<u32>, y: Option<&str>) { //実際はOptionが5個とか
let x = match x {
Some(x) => x,
None => return,
};
let y = match y {
Some(y) => y,
None => return,
};
println!("{} {}", x, y);
}
考えついたのが、次のようにする方法なのですが、
fn foo(x: Option<u32>, y: Option<&str>) -> Option<()> {
let x = x?;
let y = y?;
println!("{} {}", x, y);
Some(())
}
記載の省略のためだけに返値の型をOption<()>にして最後にSome(())つけるのがすごく気持ち悪いんですが、
返値なしのままどうにかする方法はないでしょうか

769:デフォルトの名無しさん
21/05/25 02:11:48.11 QcInQ0e9.net
if_chain使って
if_chain!{
if let Some(x) = x;
...
then { println!("{}", x); } }

770:デフォルトの名無しさん
21/05/25 02:16:51.35 Ygc8ZzR1.net
>>753
fooの型変えられないなら、戻り値Optionはクロージャないしローカル関数に留めるといいと思う
URLリンク(play.rust-lang.org)

771:デフォルトの名無しさん
21/05/25 03:00:10.05 nrKC74iS.net
Ok(())はよく使うがSome(())はないな
普通にif-letでパターンマッチするのでよくない?
if let (Some(x), Some(y)) = (x, y) {
println!("{} {}", x, y);
}

772:デフォルトの名無しさん
21/05/25 05:18:39.47 gz717nup.net
loggerを引数で渡すためには
ロギングを行うクラスFooがどこかしら(コンストラクタか個々のメソッドで)loggerを受け取る引数を持たねばならない
これ、ロギングみたいな裏方の仕事がFooのインターフェース仕様に影響しているということで、
抽象度が下がってるやんけ;;;
引き換えに得られるメリットは、Fooのインスタンスごとにloggerを切り替えられるというおおよそ現実的にありがたみが無い機能だけ

773:デフォルトの名無しさん
21/05/25 06:08:48.35 FYPKUk3M.net
>>756
それをmachでやるのがよくない?

774:デフォルトの名無しさん
21/05/25 06:23:40.79 gz717nup.net
つか機能の分離と記述の分離はトレードオフがある
1+1=2の形式的証明がどんだけの糞みたいな分量のに成り得るかを見たらワカル
どっかの抽象度をつきつめれば別のところにしわ寄せが逝く
それで良いジャマイカ人間の言語だもの、

775:デフォルトの名無しさん
21/05/25 09:01:56.56 5vUI50kp.net
皆様ありがとうございます
どうもSomeをある程度書くのは避けられない感じですね

776:デフォルトの名無しさん
21/05/25 10:09:28.07 4oEEOZjA.net
まさかstatic変数使ってるなんて、logクレートには失望したわ

777:デフォルトの名無しさん
21/05/25 10:33:41.89 bGIV0Xp5.net
>>757
ログを裏方と考えるのも偏ってるし、ログ切り替えはデバッグ目的で普通にあるわ。
別にグローバルにするという選択が間違いとも思わんがこういう決めつけ野郎は邪魔だな。

778:デフォルトの名無しさん
21/05/25 10:59:01.14 /nQyXsn+.net
サーバ側だとログを取るのが基本だし取り方も変えたくなるからlogger渡しは結構やるな
CLIとかなら雑にstaticでいいけど

779:デフォルトの名無しさん
21/05/25 13:12:03.88 CssgwvqL.net
>>761
stdも使えないじゃん

780:デフォルトの名無しさん
21/05/25 18:48:30.58 4oEEOZjA.net
>>764
なんで?

781:デフォルトの名無しさん
21/05/25 19:25:41.69 CssgwvqL.net
>>765
URLリンク(github.com)

782:デフォルトの名無しさん
21/05/25 19:39:28.48 4oEEOZjA.net
>>766
えー
これからは write() システムコールでプリントするわ

783:デフォルトの名無しさん
21/05/25 21:02:03.28 p1A5R6d8.net
stdが嫌ならcoreを使え

784:デフォルトの名無しさん
21/05/25 22:59:34.15 gz717nup.net
>>762
近代的なログシステムならタグが使えるから
記録時に分っける理由がさらさらない
だいたい並列な事象を並列なまま記録したのでは時系列の解析ができないし、
そもそも>>762がいくら「ログは裏方じゃない」と叫んだところで基準が無い
アプリケーションロジックを汚してまでか?!という議論はいつまでもつきまとう

785:デフォルトの名無しさん
21/05/26 00:00:47.75 S2nFrW0F.net
別に仕事で使ったことないならそういえばいいと思うよ。悪いことしてるわけじゃないんだから。

786:デフォルトの名無しさん
21/05/26 00:04:47.15 PLorGv/T.net
そういやLog4JでいうMDCみたいなやつはあるのかしら?

787:デフォルトの名無しさん
21/05/26 00:07:56.89 rwxZHBm1.net
お前らslog
>>760
ただのzipやん。
URLリンク(play.rust-lang.org)

788:デフォルトの名無しさん
21/05/26 08:19:13.92 AN5OxrIl.net
まあloggingオブジェクトを複数作る仕事なんなら仕方が無いな

789:デフォルトの名無しさん
21/05/26 08:29:19.07 vJAmL6Qi.net
slog見たけど、クソややこしいな

790:デフォルトの名無しさん
21/05/28 09:51:25.19 jQHjx/Sg.net
シンタックスで判断しづらいもので性的分析するって、そのうち破綻しそうだな。

791:デフォルトの名無しさん
21/05/28 09:54:11.42 S8Iz9SRl.net
エロい分析か

792:デフォルトの名無しさん
21/05/28 10:45:17.68 EKMYAKDR.net
やらC

793:デフォルトの名無しさん
21/05/29 20:28:41.06 sKXDX7XX.net
JPEG-XLのリファレンス実装作ってるチームがRustで再実装も始めてて驚いた
URLリンク(github.com)
FirefoxにJPEG-XL対応を入れるかどうか議論するチケットで
今更大量のunsafeなC++コードを入れるのはちょっと……みたいな反応をされてた事と関係あるのかもしれない

794:デフォルトの名無しさん
21/05/30 15:56:56.42 HupJBx7X.net
URLリンク(4e6.github.io)
URLリンク(www.openhub.net)
Firefox、かなりの割合でC++のコード入ってるけどこれでも減らそうとしてるのか

795:デフォルトの名無しさん
21/05/30 16:00:13.57 P46Jh5T1.net
もう9.5%も行ってるのか
と言うかfirefoxからrustは始まったから当然か

796:デフォルトの名無しさん
21/05/30 16:15:38.02 ds+xAsBi.net
でも、大量の有名なWebサービスが一時的にRubyで書いていたのに、
しばらくすると他言語に書き直した歴史がある。
アメリカ人はなぜか言語を書き直すのが好きなようだ。
Rustで書いてもまた別言語に直すかも知れない。
なお、Googleドライブなどの各社のストレージサービスを統一的なAPIで制御できる
ライブラリも何故かGoで書かれている。
メンドクサイ。

797:デフォルトの名無しさん
21/05/30 17:11:41.17 cF4puvJq.net
>>781
遅い方から速い方へ書き直すのよ
特にスクリプト言語からC++/Rustへ書き換えるとサーバー数を1/10にできるケースもあり規模によっては経費激減ね
GoもGCあるから場合によっては他へ書き換えられる対象になりうるかも
Rustが他へ書き換えられる可能性がもしあるとしたら今はまだ存在しない新たに出現する言語へ

798:デフォルトの名無しさん
21/05/31 00:35:54.04 7s+MSAY0.net
なんでClippy大先生がcargoでインストールできるクレートから外されるの?

799:デフォルトの名無しさん
21/05/31 01:50:13.82 u1BqTaEs.net
rustupでインストールできるからでは
rustcとバージョン合わせないといけないから他のcrateと同じ扱いはしづらいのでは

800:デフォルトの名無しさん
21/05/31 08:44:19.92 etoumxTf.net
Ruby on Rails の時価総額は、
Shopify が15兆円、
民泊のAirbnb が、大手ホテル3社の合計以上の10兆円、
Github が8千億円
これぐらい巨大でも、Rails で出来る。
時価総額が千億円以上になったら、Go, Elixir を考えてもよい
食べチョクは売上50億円らしいけど、
若い文系女が1人で起業したような会社は、Rails で十分
売上が千億円を超えたら、考えてもよい


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch