Rust part10 - 暇つぶし2ch

Rust part10 ..

1:デフォルトの名無しさん
21/04/02 21:38:04.11 L7IeSfpL.net
Mozilla発のRust言語のスレ
公式
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(blog.rust-lang.org)
URLﾘﾝｸ(github.com)
Web上の実行環境
URLﾘﾝｸ(play.rust-lang.org)<)
前スレ
Rust part9
ｽﾚﾘﾝｸ(tech板)

2:デフォルトの名無しさん
21/04/02 23:38:41.76 fjFXuKAx.net
立て乙 >>1

3:デフォルトの名無しさん
21/04/03 14:21:28.71 /AAJGIzP.net
前スレ：
「まともにrustでc++並の開発速度で製品作ってから言えや」
って深い言葉だ。

4:デフォルトの名無しさん
21/04/03 14:26:31.17 SyvybhgS.net
自分で書いたのに？

5:デフォルトの名無しさん
21/04/03 14:53:21.44 /AAJGIzP.net
>>4
書いてない。

6:デフォルトの名無しさん
21/04/03 18:20:50.26 FsaMqi3u.net
書いてないことは取り上げるまでもない

7:デフォルトの名無しさん
21/04/03 19:30:37.63 SyvybhgS.net
まあrustを積極的に使えと言うことらしい

8:デフォルトの名無しさん
21/04/03 20:35:13.31 AKsD3jpb.net
積極的に使えば欠点が良く理解できるようになるからね。とても有効だよ。

9:デフォルトの名無しさん
21/04/03 21:46:35.78 FsaMqi3u.net
費用対効果はしばらくは注意深く見守る必要が

10:デフォルトの名無しさん
21/04/03 22:01:52.54 RYKBObRk.net
費用対効果を見積もるにも実際のプロジェクトで使ってみるのが一番。
まあ俺は巻き込まれたくはないが。

11:デフォルトの名無しさん
21/04/04 00:05:12.47 EgnLn3Yg.net
C++使ったこと無いけど趣味開発だしrust使うわ

12:デフォルトの名無しさん
21/04/04 01:07:15.87 qybbKpH3.net
>>11
勝手に使えばいいよ。

13:デフォルトの名無しさん
21/04/04 14:56:23.48 cWc/MaHx.net
秀和システムのキンドル本って、あれはセールで半額になったりするもんなの？

14:デフォルトの名無しさん
21/04/05 08:07:37.55 0j1wJjru.net
日本はランニングコストが軽視されやすいからね

15:デフォルトの名無しさん
21/04/06 01:06:18.21 Ftkx6t//.net
C/C++は適当に動かすだけなら簡単だろうけどさ
ヘッダーファイルの作法、makeファイルの作法、古いコンパイラやリンカへの配慮・・・・みたいな独学困難な領域が多くあるからな

16:デフォルトの名無しさん
21/04/06 02:13:12.02 /NFP4YRd.net
そういう人は低レイヤーを触るのがそもそも間違ってる。

17:デフォルトの名無しさん
21/04/06 02:33:17.68 G1ho10ZT.net
まともなマニュアルすらないからな。魔境

18:デフォルトの名無しさん
21/04/06 04:24:25.20 BW0cQchg.net
>>15
独学するしかないと思ってた

19:デフォルトの名無しさん
21/04/06 09:55:26.42 Jj+MMoYg.net
cmakeやmesonやIDEの支援があると言ってもやはり敷居は高いわな
だがrust使うにせよC/C++のライブラリ使ったりドキュメント読む羽目になるのでやはりある程度相互運用の知識は必要

20:デフォルトの名無しさん
21/04/06 11:13:42.73 gf2H4NQV.net
オープンソースの makefile は無意味なごみが集まってるから読みにくいだけ。
特に gnu makeがおかしい。
gnu 系はヘッダファイルもソース本体も汚い事が多い。

21:デフォルトの名無しさん
21/04/06 12:13:30.74 cPUJlmRG.net
ここにはC++使いしかいないのか

22:デフォルトの名無しさん
21/04/06 12:16:43.42 jsUZfCa/.net
その類のmakefileはautoconfとautomakeで自動生成されるもので、人間が読むものじゃないでしょ

23:デフォルトの名無しさん
21/04/06 12:28:15.32 wB2vBd3T.net
C++03の地獄を見てきた者達だ
面構えが違う

24:デフォルトの名無しさん
21/04/06 16:42:56.60 23z+dMzq.net
Rust の世界だけを考えるならビルドプロセスは Cargo に書いておけばそれで OK だけどね。
全て Rust だけでは書けない場合には従来のツールチェインに更に Cargo が加わって余計にややこしくなってるとも言える。
URLﾘﾝｸ(xkcd.com)
ツールが汚いのは現実が汚いからだよ。
汚い現実から目をそらして綺麗なルールの中に閉じこもっても、
汚い現実が消えてなくなるわけじゃない。
Makefile が不愉快なら Makefile を使わないプロジェクトを増やすのを頑張るこったな。

25:デフォルトの名無しさん
21/04/06 17:35:44.74 EMKAWWjR.net
rustだけのプロジェクトでもcargo-xtaskを使ってたりするからcargoだけですべてOKかというと微妙だけどね
タスクランナーやビルドのポストプロセスなんかのサポートって予定されてるの？

26:デフォルトの名無しさん
21/04/06 18:23:14.98 dIxoLwXV.net
Rust版makeみたいなツール見かけた気がする

27:デフォルトの名無しさん
21/04/06 19:12:35.86 i3cN7eS9.net
>>26
つ URLﾘﾝｸ(github.com)

28:デフォルトの名無しさん
21/04/06 23:23:49.86 cPUJlmRG.net
そういうのあるの知ってるけどcargo本体に取り込む予定があるかが気になってる
グローバルにその手のツールインストールするとバージョン固定が難しいので
npmみたいにlocal installできるならそれでも良いけど

29:デフォルトの名無しさん
21/04/07 09:04:42.45 rL66qkG6.net
対応は結構してるわな。ただここの連中はこれくらいもできなさげ。
URLﾘﾝｸ(qiita.com)

30:デフォルトの名無しさん
21/04/07 13:04:30.43 zl6LVrRO.net
>>27
使ってる人いる？

31:デフォルトの名無しさん
21/04/07 13:14:18.37 nIst5pc0.net
>>30
マルチプラットフォームで単純なmakeより複雑なことをしたいときには使っている。ただ大抵の場合makeでいいんじゃないかとも思う。

32:デフォルトの名無しさん
21/04/07 13:18:48.25 uzth3iNv.net
Rust in the Android platform
URLﾘﾝｸ(security.googleblog.com)

33:デフォルトの名無しさん
21/04/07 14:06:22.69 g0cTo5ct.net
>>22
ところがそのautoconf系そのものがそもそも汚い。
そして、autoというのは真っ赤な嘘であることが知られている。

34:デフォルトの名無しさん
21/04/07 14:24:24.61 zl6LVrRO.net
たまにCMakeが無いとcargo installがこけるツールがあってげんなりするわ

35:デフォルトの名無しさん
21/04/07 15:05:49.86 JRewXnwY.net
m4マクロで書くというのはそろそろやめにしてもらいたい

36:デフォルトの名無しさん
21/04/07 18:53:05.80 4oC9i5VP.net
>>30
既定のタスクをそのまま使う分には便利だけど、ちょっとアレンジしようとするとめんどくさかったという感想。
単に慣れの問題かもだが、gnu makeのMakefile中でcargo叩く方がやりやすかった。

37:デフォルトの名無しさん
21/04/08 16:35:24.79 1ecqYbtl.net
>>32
訳
Rust言語でAndroidはより強固・安全に～GoogleがOS開発への導入を進める
URLﾘﾝｸ(forest.watch.impress.co.jp)

38:デフォルトの名無しさん
21/04/08 16:40:19.95 dggq93E7.net
Rustバイナリにユーザー名が埋め込まれる脆弱性が発見された

39:デフォルトの名無しさん
21/04/08 19:01:45.52 gM5Az3ay.net
スーパーでよく見かける生産者表示だ、気にするな

40:デフォルトの名無しさん
21/04/08 19:25:11.32 Y7HoyqEo.net
ユーザー名といかコンパイル時のソースのフルパスね
ホームディレクトリ配下にソースがあるならログインユーザー名が含まれる
あと発見されたのは最近ではなかったはず

41:デフォルトの名無しさん
21/04/08 20:20:07.26 mAsGX/mS.net
それを消すためのオプションは数年前から付いてて
そのオプションがうまく効かないケースがあるってバグが修正中なはず
最近あったのは単にその話を記事に書いた人がいるってだけ

42:デフォルトの名無しさん
21/04/08 20:20:24.34 bT2+gYi+.net
ディレクトリ名にマイナンバーを入れてる人がいたらどうすんだまったく

43:デフォルトの名無しさん
21/04/08 20:46:41.37 KJ+7YtJl.net
どんな間抜けだよ

44:デフォルトの名無しさん
21/04/08 21:41:22.53 2f4Y47iQ.net
ディレクトリ名につい「クソプロジェクト」とか入れてるやつはいるだろ

45:デフォルトの名無しさん
21/04/09 01:29:12.23 q4HnPycb.net
ていうかログインユーザー名に実名いれるとかバカなんじゃないか

46:デフォルトの名無しさん
21/04/09 01:29:59.12 q4HnPycb.net
>>44
たしかに・・それに近いことは・・ある。

47:デフォルトの名無しさん
21/04/09 11:49:57.87 GRSPIdCN.net
fuck_you_cplusplus とか普通にありそう

48:デフォルトの名無しさん
21/04/09 15:11:34.90 6eEbkgDq.net
どこのモジラだよ。

49:デフォルトの名無しさん
21/04/09 20:07:51.03 +qIWqkLA.net
Linusじゃないの

50:デフォルトの名無しさん
21/04/10 00:22:28.46 mUxV1BIo.net
Linusが吠えた! ─中指立てて「NVIDIAは世界最悪の企業」
URLﾘﾝｸ(gihyo.jp)
それはそうとして、Rustの（Goもだが）「..」が
begin～lastの意味ではなくて
begin～last+1なのは
コメントに「arr[0..3]」とか書きたい場合に地味に困る

51:デフォルトの名無しさん
21/04/10 02:24:29.60 0NXaZP8I.net
>>42
ネタにマジレスするけどマイナンバーはただの概念で
国民識別番号は国のサーバーに有る。
>>50
last+1って何？　..は[begin, last)だぞ。
左閉右開半開区間はPLじゃ一般的だけど。

52:デフォルトの名無しさん
21/04/10 03:35:58.01 mUxV1BIo.net
>>51
begin～last すわなち [begin, last]　をRustで書いたら
begin..last+1
になる、という意味やったｻｰｾﾝ、
しかしコメント内に現れた「a..b」は、Rust式に[a, b)と解釈すべきなのか、
それとも伝統的な[a, b]解釈とすべきなのか
というのがそこはかとなく疑問が……

53:デフォルトの名無しさん
21/04/10 03:38:59.03 mUxV1BIo.net
同じことは「=」と「==」（代入と等値）の使い分けを
コメント内にまで持ち込むべきかどうかという意味で
昔から迷う感じだったものがRust（やGo）の「..」のせいで悩みの種が増えたは！

54:デフォルトの名無しさん
21/04/10 10:43:41.15 +2v3HD7B.net
>>52
Rustコード中ではbegin..=lastって書いたほうがいい（>=rust-1.26.0）
知ってたらすまん
 >>53
Rubyもそうだぞ

55:デフォルトの名無しさん
21/04/10 10:51:20.63 gEDOL+ak.net
pythonもじゃないか？
C系のfor(int i=0;i<5;i++)の終了条件に合わせてあるのかと思う

56:はちみつ餃子
21/04/10 11:33:17.54 0qKWjqEq.net
最後の要素を意味するときは last で、
最後の要素のひとつ後を指すときは end を使う習慣があると
どこかで見た覚えがあるんだけど、
別の言語だったかもしれないしどこかの数学分野だったかもしれない。
うろおぼえでスマソ

57:デフォルトの名無しさん
21/04/10 11:52:10.96 K51XBEHT.net
既存の言語でも a..b が [a,b] になるもの、[a,b) になるものが混在してたこと、
また、見た目で意味が明確にわかることから a..b と a..=b を採用したという経緯だった気がする

58:デフォルトの名無しさん
21/04/10 16:42:23.36 l4RzKTvO.net
URLﾘﾝｸ(doc.rust-lang.org)
の一番最後のコードをコピペしてもエラーで動かないのですが
どこをなおしたらいいのでしょうか？

59:デフォルトの名無しさん
21/04/10 17:11:01.23 gEDOL+ak.net
cargo. tomlそのままってオチかな？

60:デフォルトの名無しさん
21/04/10 17:13:25.76 l4RzKTvO.net
randの追加はしております

61:デフォルトの名無しさん
21/04/10 17:23:47.25 +2v3HD7B.net
エラーメッセージを

62:デフォルトの名無しさん
21/04/10 17:24:38.49 gEDOL+ak.net
エラーそのまま貼らないとわからないわ
と言うか頭からやりなよ

63:デフォルトの名無しさん
21/04/10 17:

64:50:35.32 ID:gEDOL+ak.net

65:デフォルトの名無しさん
21/04/10 21:25:06.44 l4RzKTvO.net
あ、すいません
randのバージョンを最新版のものにしてました
チュートリアルで指定されているバージョンにしたら動きました
失礼しました

66:デフォルトの名無しさん
21/04/10 21:28:15.45 ugs90wL2.net
乱数なんて超基本的なライブラリが
コンパイル通らないぐらいのAPI変更を簡単にやってしまうなんて大丈夫なのかこの言語

67:デフォルトの名無しさん
21/04/10 21:58:15.68 gEDOL+ak.net
この場合は言語の責任でもないしそのためのcargoだし

68:デフォルトの名無しさん
21/04/10 22:07:11.12 gEDOL+ak.net
でもせっかくこういう体験したのであればソースの方を直すのも正しき甲殻類な気がするな

69:デフォルトの名無しさん
21/04/10 22:55:00.58 DbIYjEaQ.net
最近使ってないけど
randってなんか使いにくいAPIだった気がする

70:デフォルトの名無しさん
21/04/11 01:46:09.52 +yU+1pdE.net
最近マシになってきた

71:デフォルトの名無しさん
21/04/11 03:28:20.09 FNN81f5r.net
マシにする為だろうが一度決めたAPIは変えない
それがC/C++界の掟じゃないのか？

72:デフォルトの名無しさん
21/04/11 08:22:28.91 /Boh3f8b.net
絶対に変えないようにした結果かえってひどいことになってるイメージ

73:デフォルトの名無しさん
21/04/11 08:57:50.42 SN158GXT.net
普通は破壊的仕様変更のときはメジャーバージョン変えそうなもんだがバージョン0だからな

74:デフォルトの名無しさん
21/04/11 09:07:58.37 QZzlCmlR.net
バージョン0のうちは破壊的な変更もし放題ということか

75:デフォルトの名無しさん
21/04/11 09:12:29.26 SN158GXT.net
そいや非推奨や廃止の警告出せたっけ？

76:デフォルトの名無しさん
21/04/11 10:02:11.52 8BAcJ5Wr.net
>>74
deprecatedアトリビュートで出せるよ

77:デフォルトの名無しさん
21/04/11 10:25:10.63 SN158GXT.net
Microsoftがプログラミング言語「Rust」への支援を強化
URLﾘﾝｸ(news.yahoo.co.jp)
visual rustとか出さないでよね…
>>75
だよねえ
どのバージョンで変えるか警告はするよねえ

78:デフォルトの名無しさん
21/04/11 10:47:22.32 SN158GXT.net
んでバージョン指定変えてみたら
get_rangeの引数が最小、最大+1の２つから最小..最大+1の範囲リテラルに変わったのね
カンマを..に一ヵ所変えるだけだったから修正自体は対したことなかったけどオーバロードがあればもっと緩やかな改変が出来るのだろうか？
ゼロコスト抽象化の方針上仕方ないのだろうか？

79:デフォルトの名無しさん
21/04/11 11:24:02.64 FNN81f5r.net
>>77
そんなしょうもない変更の為に互換性破壊したのか

80:デフォルトの名無しさん
21/04/11 11:29:55.74 duIaxYyg.net
>>78
..= が使えるようになったとあるのでインターフェースの改善ではあるのでは
あと破壊的変更はこれだけではない
URLﾘﾝｸ(rust-random.github.io)

81:デフォルトの名無しさん
21/04/11 12:27:09.74 SN158GXT.net
マイナーバージョンが上がるのでも結構変わると言うことか

82:デフォルトの名無しさん
21/04/11 13:05:02.83 /JadX22/.net
バージョン0のうちはね

83:デフォルトの名無しさん
21/04/11 13:15:29.70 SN158GXT.net
誰かも言ってたけどこう言うのは標準ライブラリで整備してほしい所だあな

84:デフォルトの名無しさん
21/04/11 13:43:12.49 4rSwKpry.net
乱数は用途によってアルゴリズム使い分けにゃならんからなぁ
Cのrandはまぁ使えないとしてC++のrandomまで行くと重い

85:デフォルトの名無しさん
21/04/11 14:40:26.89 duIaxYyg.net
randの設計が安定しない現状でstdに入れるにしても
かなり限定されたサブセットしか入れられないのでは

86:デフォルトの名無しさん
21/04/11 17:41:37.63 aRgjPq06.net
それで十分だろ。
メルセンヌツイスターとか必要な場合は各々入れたら良い。
手軽な乱数を必要とする場面は割とある。

87:デフォルトの名無しさん
21/04/11 21:41:09.50 LXnW0jT4.net
メルセンヌ・ツイスタ、MT19937 を使っているのは、Ruby ぐらい
他の言語は、低品質

88:デフォルトの名無しさん
21/04/11 22:30:00.44 2GAqbccY.net
一瞬信じかけたけど、pythonもboostもmtだったわ

89:デフォルトの名無しさん
21/04/11 22:41:39.90 FNN81f5r.net
何でそんなとこで嘘つくん？

90:デフォルトの名無しさん
21/04/11 23:24:19.82 REr5r+Uo.net
>>85
直近でThreadRngやRngも破壊的変更されてて
乱数生成器の種類を充実させるとかそういうレベルにすら達してないのよ

91:デフォルトの名無しさん
21/04/12 16:58:50.31 JNYj24al.net
一部のプログラミング言語では、デフォルトの疑似乱数生成器としてメルセンヌ・ツイスタが
標準ライブラリに取り入れられている。そのような言語の例として、 Python,[2][3] Ruby,[4]
R,[5] PHP,[6] MATLAB, C++[7]（C++11から）がある。

92:デフォルトの名無しさん
21/04/12 19:41:31.46 bbHno7r0.net
よそはよそ！うちはうち！

93:デフォルトの名無しさん
21/04/12 21:18:15.82 z80SpJNy.net
線形合同が、あまりに低品質

94:デフォルトの名無しさん
21/04/12 21:49:55.90 b3c5oHjh.net
オライリー調査で明らかに--Go、Rust、Ruby、Dartに関心高まる - ZDNet Japan
URLﾘﾝｸ(japan.zdnet.com)

95:デフォルトの名無しさん
21/04/12 22:02:51.56 mno1Imjq.net
fn main() {
let n = 100;
println!("{}", type_of(n));
}
これを実行すると
E0425: cannot find function `type_of` in this scope not found in this scope
になるのですがtype_ofは使えないのでしょうか？
rustc -V
1.51.0です

96:デフォルトの名無しさん
21/04/12 22:08:31.70 mno1Imjq.net
すいません
とほほのRust入門見て解決しました
type_ofを関数として定義しないとダメなんですね
URLﾘﾝｸ(docs.rs)
にページがあったので組み込み関数があるものだと思いこんでたら
そういうものは存在しなくて,type_ofの関数を定義しないとダメだったようです
kindleで入門書を購入したのですがそこが省略されておりはまりました
失礼しました

97:デフォルトの名無しさん
21/04/12 22:40:04.94 J2Rjxost.net
乱数ってxorshiftとかxoroshiroもあるわけで
まぁアルゴリズム固定は難しいでしょう

98:デフォルトの名無しさん
21/04/12 23:08:15.49 /+zeTQQu.net
no_std環境も考えるともし一つ選ぶならMTよりxorshiftかなぁ。Rustの方針に合わないから入ることはないだろうけど。

99:デフォルトの名無しさん
21/04/13 00:51:04.66 zVaLotRH.net
APIをどうするかどこまでリッチにするかとかも難しいんだろ

100:デフォルトの名無しさん
21/04/13 01:57:46.80 dtk27dGR.net
xoroshiro1024がないんだよね。
>>95
```shell
rustup doc --std
```

101:デフォルトの名無しさん
21/04/15 21:01:10.98 aIjUzI+d.net
パニックお断り―Linus，"Rust for Linux"の盛り上がりに釘を刺す
URLﾘﾝｸ(gihyo.jp)

102:デフォルトの名無しさん
21/04/15 21:13:33.74 aIjUzI+d.net
JavaScript／TypeScriptランタイム環境「Deno 1.9」がリリース、パフォーマンス向上に寄与する機能追加など
URLﾘﾝｸ(codezine.jp)

103:デフォルトの名無しさん
21/04/16 04:30:01.56 h4psCBcA.net
>>100
メモリの確保に失敗したくらいでpanicはしないが
alloc::alloc::Allocatorの一部メソッドはpanicするから
no_core上にpanicしないアロケータ実装すればよさそう。
コンパイル遅いのはキャッシュするしかない。

104:デフォルトの名無しさん
21/04/16 09:28:25.44 eEnfPPGg.net
結局kernelやるならunsafeつけまくりにしかならんだろ。
そうするとなぜrustで？という事になる。

105:デフォルトの名無しさん
21/04/16 09:50:50.04 MkjaOpjL.net
>>102
その「panicしないアロケータ」を使った Vec やらなんやら全部実装しなおさないといけなくならない？

106:デフォルトの名無しさん
21/04/16 18:31:00.46 7IMcJQmu.net
>>104
といっても変えるのはnewとかくらいで大半の実装はそのままもってくればいいんじゃない？
まあパッチ投げてる人もそこは作業量多いとは言ってるけど。

107:デフォルトの名無しさん
21/04/16 18:54:38.72 GwffY4ld.net
>>104
Vec等のコンテナにはtry_reserveとかのメモリ割り当て失敗でエラーにする関数用意されているから
メモリ割り当ての失敗だけが問題ならliballocの使い方を変えるだけでよいのでは
他にpanic要因あるならだめだけど
ちなみにnewはメモリ割り当てしないから変更不要

108:デフォルトの名無しさん
21/04/16 21:12:31.63 eEnfPPGg.net
ある種の「コンテキストに対するunsafe」をつけて回らなきゃ無理。
でもってそれはmoonshotだって言ってるわな。
URLﾘﾝｸ(lkml.org)

109:デフォルトの名無しさん
21/04/16 21:47:54.90 GwffY4ld.net
特定の関数が割り込みのコンテキストから呼び出されたときにコンパイルエラーにすることは
今の言語機能では不可能という話か

110:デフォルトの名無しさん
21/04/16 23:21:39.03 Xc/jdFUF.net
>>107
role orientedな言語でコンパイラが特別扱いする
コンテキストを指定できれば実現できる、
ここまで考えてだからmoonshotなのかと。

111:デフォルトの名無しさん
21/04/16 23:46:26.48 Kk/3g/Ul.net
Cでも出来てないことを要求してどうすんの

112:デフォルトの名無しさん
21/04/17 00:54:40.80 r+Flv24K.net
知らんがな。どうしてもrustでkernel作りたいってやつに言えや。

113:はちみつ餃子
21/04/17 02:30:05.79 V2rXjiTW.net
Linux のカーネルはカーネルとは言ってもかなり巨大なので
現状の Rust でも採用可能な箇所もあるんでないの。
知らんけど。

114:デフォルトの名無しさん
21/04/17 08:49:33.19 r+Flv24K.net
>>112
だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。
何周遅れてんだよ。

115:デフォルトの名無しさん
21/04/17 09:05:35.37 dMPv+0ET.net
グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え
URLﾘﾝｸ(japan.zdnet.com)
利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな

116:デフォルトの名無しさん
21/04/17 09:33:32.53 tTsG+vVF.net
linusすごいな
Rust関わってる人全員子供扱いかよ

117:デフォルトの名無しさん
21/04/17 10:42:23.64 r+Flv24K.net
いや、これrustでkernelに関わろうとした人たちが低レイヤーのこと、あまりにわかってなさすぎだろ。。
これ、ほぼ素人の俺でも気づくような内容だぞ

118:デフォルトの名無しさん
21/04/17 10:53:16.85 ttx9Ve6D.net
へぇ、すごいんですねぇー^^

119:デフォルトの名無しさん
21/04/17 10:55:23.76 r+Flv24K.net
冷笑系気取りのバカって本当に救いようがないよな。

120:デフォルトの名無しさん
21/04/17 11:09:22.71 h7zOlTtk.net
C++でもコンテナに値を追加しようとすると、メモリー不足で追加に失敗
する可能性があるが、それをいちいちチェックする人はまず居ないだろうな。
デスクトップマシンでそれに失敗する可能性はとても低いけども。

121:デフォルトの名無しさん
21/04/17 11:14:10.31 h7zOlTtk.net
例えば、
std::vector<int> v; // 空の動的配列を生成
for ( unsigned int i = 0; i < 100000000; i++ ) {
v.push_back(i + 100); // 末尾に i + 100 という値を追加
}
とした場合、環境やマシンの状態によってはメモリー不足で失敗することは
あるだろうが、これをいちいちエラーチェックする人は少ないだろう。

122:デフォルトの名無しさん
21/04/17 11:22:45.09 3/shspJz.net
>>116
URLﾘﾝｸ(rust-lang.github.io)
歴史的背景はこことか見ると書いてあるけど、処理系の初期開発で想定されていたほとんどの開発者はallocation errorから回復する必要がないから、あえてそういうAPIデザインにしたと
カーネルはその「ほとんど」から外れる用途だからlinusは当然今のAPIじゃダメだと釘を刺す
だからallocator_apiその他の安定化が急がれる、それだけの話じゃないの？

123:デフォルトの名無しさん
21/04/17 11:25:00.56 /69X/cno.net
linusへのレスポンス読んだ？
allocについては問題なのは認識してるけど
開発スピード上げるために今はliballoc使っていて
そのうち独自の物に置き換えると言っている

124:デフォルトの名無しさん
21/04/17 11:27:24.53 t/1FzfAW.net
pure rustでカーネル作ってる人いるんだから
原理的に不可能ってわけでもないだろ

125:デフォルトの名無しさん
21/04/17 11:29:13.13 LJqBKM+D.net
allocまで全部作り切ってからパッチ投げてLinusに却下って言われたら目も当てられんしな。プロトタイプの段階でこまめに出すのはいいと思う。

126:デフォルトの名無しさん
21/04/17 11:37:37.77 h7zOlTtk.net
>>120
伝統的なCでは、
char *ptr;
if ( (ptr = malloc(サイズ)) == NULL ) {　// (1)
　printf( "メモリ確保にしっぱいしたで～\n" );
}
それをC++で書くとすれば、
if ( (ptr = new char [サイズ]) == NULL ) {　// (2)
　printf( "メモリ確保にしっぱいしたで～\n" );
}
となるけれども、
v.push_back(i + 100);　// (3)
でメモリーエラーのエラーチェックしないのに(2)でしても余り意味はないという
考え方もあるわけでなので(2)と書かずにエラーチェック無しで
ptr = new char [サイズ];　// (4)
と書く方針もあっていいと思う。
なお、よっぽど大きなデータを扱わない限り、デスクトップマシンでは
(3)や(4)で失敗する可能性はとても低い。

127:デフォルトの名無しさん
21/04/17 11:41:51.20 h7zOlTtk.net
N88-BASICでは、読み込みモードでファイルを開く時、
open "ファイル名" for input as #1
と書いていたが、ファイルが存在しないとここでエラーになって
アプリが終了していたことを思い出した。
Perl、Ruby、Pythonなんかは、全て基本的に同じ方針だと思う。
その流儀とRustでのメモリー不足時のpanicの方針も同じと考えていいだろうな。

128:デフォルトの名無しさん
21/04/17 11:48:23.17 r+Flv24K.net
>>121
そう、それだけの話。でもそれだけの話がここでは恐ろしく通じない。

129:デフォルトの名無しさん
21/04/17 12:20:31.25 3/shspJz.net
>>122
On allocation: this is just our usage of `alloc` in order to speed
development up -- it will be replaced (or customized, we have to
decide how we will approach it) with our own allocation and data
structures.
これのことか？
itってour usage of `alloc`のことじゃねーのと思ったけど、alloc自体のAPIデザインに問題があるみたいな話出てるの？

130:デフォルトの名無しさん
21/04/17 13:30:05.64 5SUmF/jF.net
>>125
> if ( (ptr = new char [サイズ]) == NULL ) {　// (2)
C++ は new も vector::push_back も bad_alloc が飛ぶ。ふつうの new は nullptr 返さない。

131:デフォルトの名無しさん
21/04/17 13:35:37.75 YGcs/48d.net
てかアロケータの動作がどうのってLinux Kernel関係あるの？
ベアメタル用途全般が該当すると思うけど

132:デフォルトの名無しさん
21/04/17 14:08:16.83 h7zOlTtk.net
>>129
そういえば、言葉は忘れたけど、関数宣言の行に、その関数の中でどういう
例外が起きる可能性があるかについてのthrows を書くかどうか、書くべきか、
省略しても良いか、などの違いが色々あって、どういう言語仕様にすべきかが
結構問題になっていると聞いた。
すべてを書くと多くなりすぎるし、全く書かないのも問題だとか、そんな話。
なんという言葉だったかな。

133:デフォルトの名無しさん
21/04/17 14:30:50.99 ahfNUrst.net
allocatorがエラーを返さずに例外を上げる挙動にRustの標準ライブラリ的なもの(コレクションとかスマートポインタとか？)が依存していて、
それはLinuxカーネル的には許容できないからそういうコードをそのまま持ち込むなよ？ということでしょ
Linuxカーネル上のC言語はそもそも標準ライブラリとか使わないし
メモリ確保もmallocじゃなくてkmallocというカーネル内独自関数使うし
ここ見ると
URLﾘﾝｸ(medium.com)
array: vec![0;32] で kmalloc が呼ばれるみたいだね
でもこれLinuxのカーネルモジュールのコードとしてはそこでエラーチェックが必要になるのかね？
もしくはkmallocに失敗したらそのモジュール自体が自動でアンロードされるとか
でもアンロードされるときに後処理とかしたいかなとかいろいろ考える必要はありそう

134:はちみつ餃子
21/04/17 14:48:08.80 V2rXjiTW.net
>>131
動的例外仕様 (dynamic exception specification) のことか？
URLﾘﾝｸ(timsong-cpp.github.io)
送出される可能性のある例外を記述する仕組みだったが、役に立ってなかったので C++17 で廃止された。
(例外を送出するかしないかだけを指定する方式が残された。)
C++ の仕様では例外を送出しないという指定を付けたところを例外が通過しようとしたら
std::terminate が呼ばれて異常終了扱いになるという、実質的な assert なんだわ。
静的な検査をカッチリやってくれるわけではないんで、
カーネル記述みたいな文脈では使い物にならんな。

135:デフォルトの名無しさん
21/04/17 14:49:51.36 ohP60UMx.net
linuxだろうとwindowsだろうと普通のカーネルはそうだろ。
よっぽど特殊用途のOSならどうかは知らんが。

136:デフォルトの名無しさん
21/04/17 15:49:17.42 h7zOlTtk.net
>>133
なんか、Javaにおいて、throwsに創出するすべての例外を書く仕様にしてみたら、
地獄のように沢山書かなくてはならなくなって困り、
関数プロトタイプ宣言の直後の throws()の中に
「書く必要のある例外」と「書かなくても良い例外」
の違いを設けることにした、この板で聞いた。

137:デフォルトの名無しさん
21/04/17 15:56:30.53 h7zOlTtk.net
>>135
「OutOfMemoryError」例外は、throws に明示しなくて良いことになった
とWikipediaで見た記憶が有る。

138:はちみつ餃子
21/04/17 16:29:38.34 V2rXjiTW.net
>>135
検査例外と非検査例外のことだな。
例外の便利なところは大域脱出が出来るところで、例外を捕捉する箇所と発生する箇所の間では例外のことを忘れられる点。
発生しうる例外の伝播を明示しないといけないのだと返却値で返す形にするのと差がない。
例外を使っていると異常系だということが見た目に分かり易いってくらいのもの。
Java が明示しなくてよい例外という分類を設けたのは明示しなくてよいというだけでなく捕捉もしなくてよいということでもあって、
どのように使い分けるのがよいかは諸説あるけども、非検査例外は
・捕捉したところで回復できないもの
・そもそもその例外を発生させないようにすべきもの (実質的には assert)
というのがおおよその共通認識になっている。
メモリ不足は回復不可能なので非検査例外に分類されているが、
「Java のレイヤでは」回復不可能という話であって、
Java では低レイヤを書かないという前提があるからこういう決め打ちが出来る。
低レイヤと高レイヤでは前提が違ってくるから同じようにはいかんのだ。

139:デフォルトの名無しさん
21/04/17 16:34:30.24 h7zOlTtk.net
>>136
URLﾘﾝｸ(www.w3resource.com)
1. Checked exceptions
2. Unchecked exceptions
が有り、2. には、
2-1. Errors
2-2. Runtime exceptions
の2種類がある。
1はmethodシグネチャのthrowsの後に明示しなくてはならないが、
2は不要。1はプログラマが処理することが出来る場合が多いが、
2はとても難しいことが多い。
OutOfMemoryErrorは、2-1 に属し、throwsの後に明示する必要がないが
「2」なのでプログラマが対処することが難しい例外に分類される。

140:はちみつ餃子
21/04/17 16:46:23.23 V2rXjiTW.net
低レイヤでも高レイヤでも使うことを考えたらやっぱ例外という仕組みは使いにくいっつーことだな。
カーネルを書くにあたって Rust が (現状では) ベストというわけでもないだろうけど、
比較的可能性がある選択のひとつではあると思う。
どうせ標準ライブラリのフルセットを使えるわけではないのは C でも同じことだし。

141:デフォルトの名無しさん
21/04/17 17:10:18.35 h7zOlTtk.net
Rubyなんかでファイルオープンする時にはエラー発生チェックをしなくてもよくて
エラーが発生するとpanicする。これは簡単なプログラムでは便利。
そしてbegin,rescue,endではさめば、panicせずにエラー処理することも
出来る様になっている。これはtry,catch構文と発想は同じ。
でも、読み書き用の2つのファイルをオープンして読んで加工して書き込む
ような時、catch文でどっちのエラーか区別したりするのは面倒といえば面倒かな。
C風だと、fopen の行で処理できて分かり易かったのに。

142:デフォルトの名無しさん
21/04/17 17:12:33.63 h7zOlTtk.net
>>139
でも、リストに追加したときにメモリ不足になっても、例外機構でしか
エラーを補足出来ないのは面倒だな。

143:デフォルトの名無しさん
21/04/18 02:29:17.84 xL1TJJG/.net
URLﾘﾝｸ(github.com)
コロコロ変わってその度に置換するスクリプト書いてるんだけど、
二ヶ月くらい音沙汰ないからそろそろ名前くらい安定してほしい。

144:デフォルトの名無しさん
21/04/18 09:49:21.11 vWwiRD

145:OG.net

146:デフォルトの名無しさん
21/04/18 10:08:02.12 UN4umXE6.net
>>143
dropじゃだめなの？

147:デフォルトの名無しさん
21/04/18 10:09:10.01 732wPalE.net
そんなに良くないからキミはもっとcを頑張ったほうがいい
cを頑張ってc++にも手を出して頑張って
気が狂いそうになるのを覚えてからもう一度来たらいい

148:デフォルトの名無しさん
21/04/18 10:34:02.72 vWwiRDOG.net
>>144
lifetime内であれば手動で早期開放できるんですね
お世話になりました

149:デフォルトの名無しさん
21/04/18 12:33:31.22 gA/cagL6.net
ワロタw

150:デフォルトの名無しさん
21/04/18 12:57:11.20 UN4umXE6.net
vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか？

151:デフォルトの名無しさん
21/04/18 13:12:40.26 /yrt+WGh.net
お前らの用途だったらgoで十分だろと思うことが多いわ。
ファッションでやるってのも悪くはないが。

152:デフォルトの名無しさん
21/04/18 13:30:23.57 8MLIImZW.net
rustではunsafeを多用するのは良いことですか？

153:デフォルトの名無しさん
21/04/18 13:39:58.68 a3mPgn8/.net
必要なら使えばいい

154:デフォルトの名無しさん
21/04/18 16:52:32.86 dOXZMSKq.net
>>148
そういうメソッドはなさそう
特に理由がなければ分けて書いた方がいいけど、ブロック式を使って
let y = { v.push(x); v.last_mut().unwrap() }; // 変数に入れる場合
f({ v.push(x); v.last_mut().unwrap() }); // 関数に渡す場合
みたいな詰め方はできるかな
いっぱい使うならローカルなマクロ作ってもいい
macro_rules! push_and_mut_ref {
($v:expr, $x:expr) => {{ $v.push($x); $v.last_mut().unwrap() }};
}
let y = push_and_mut_ref!(v, x);
蛇足だけどyが生きてる間はvに触れないからご注意を

155:デフォルトの名無しさん
21/04/18 17:30:23.89 qHYw4Dd3.net
>>152
>蛇足だけどyが生きてる間はvに触れないからご注意を
蛇足ではない気がする
push時にその要素のmut refを必要とするような書き方は避けたほうがいい

156:デフォルトの名無しさん
21/04/18 17:38:05.52 /DBGFH0C.net
entry APIみたいなことしたいのかな

157:デフォルトの名無しさん
21/04/19 03:50:11.66 cH3u5yp0.net
Rustに比べたC++の良さは雑に書けるところだって気付いた
やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ

158:デフォルトの名無しさん
21/04/19 08:44:54.89 4a/aZ6Q1.net
>>155
いいところに気付いたな
Rustは一般プログラマーには無用の長物だ

159:デフォルトの名無しさん
21/04/19 10:48:10.96 7a+3hK+O.net
段階的に直していく方法と最初から設計で硬くしておく方法があると思うが
rustが念頭に置いてるのは明らかに後者。これがいいのか悪いのかは議論の余地がある。

160:デフォルトの名無しさん
21/04/19 11:19:16.28 QqvLWpkW.net
型が強いからリファクタリングしやすいという意味では段々直していく方法に適しているとも言えると思うが

161:デフォルトの名無しさん
21/04/19 11:21:50.23 7a+3hK+O.net
>>158
型の強さがある意味で強すぎて、メモリ解放のタイミングまでキッチリあってないと無理なんだが。
ちょっとしたリファクタリングするにもかなり大域的変更になる。

162:デフォルトの名無しさん
21/04/19 11:34:35.17 VqBzpR75.net
>>155
雑に書いた脆弱性のあるバイナリを世に出さなきゃそれでもいいんじゃね

163:デフォルトの名無しさん
21/04/19 13:02:55.04 sZaag2LS.net
>>160
何言ってんだこの馬鹿
Rust謹製なら脆弱性が無いとでも思ってんのか？

164:デフォルトの名無しさん
21/04/19 13:06:52.92 hAOdtYDs.net
つーかRust以前はどうしてたんだよって話ｗ
流行りのもんに飛びついてそれ以外見えなくなってる典型

165:デフォルトの名無しさん
21/04/19 13:26:32.62 I7sE/fYQ.net
どうしてたって脆弱性を秘めたまま出回ってただろ

166:デフォルトの名無しさん
21/04/19 13:27:33.53 k4Vsf7V5.net
いつものレイヤーとかスコープを
ごちゃまぜにする思考が乱雑な人でしょ

167:デフォルトの名無しさん
21/04/19 14:27:55.78 7a+3hK+O.net
それお前だろ

168:デフォルトの名無しさん
21/04/19 16:41:05.18 OqiIdPZa.net
まあ、C/C++が危なかろうが、自分のやりたい計算をするだけみたいな用途には向いてるよな
どうみても簡単で早いし・・・・

169:デフォルトの名無しさん
21/04/19 16:57:54.64 QZprAv/b.net
>>155
C/C++は雑に書けるというより、Rustが想定してないでけで
本当は安全なプログラムも思った通りに書くことが出来る。
RustはRustが想定している範囲内でしか書けないので面倒なことになる。

170:デフォルトの名無しさん
21/04/19 17:00:14.68 QZprAv/b.net
>>167
職人さんはさまざまな危険な道具を、十分安全に使う。
Rustは、「危険だ危険だ」と言って、危ない道具を使わせず
予め「刃(やいば)を抜かれた」道具の使用を強制する。

171:デフォルトの名無しさん
21/04/19 17:08:36.65 QZprAv/b.net
AIの機械学習は計算が重いのに言語としては遅いところのPythonのAIは遅くはない。
なぜなら計算部分はC/C++で書かれたライブラリを呼び出して使ってるだけだから。
同様にRustがベンチマークで遅くないのは、実はunsafeモードで書かれたライブラリ
を使ってるせいもある。だからそのベンチマークだけでC/C++と同程度の速さ
であることの証明にはならない。

172:デフォルトの名無しさん
21/04/19 17:33:10.17 QqvLWpkW.net
>>169
具体的に何のベンチマークのことを言っているの？

173:デフォルトの名無しさん
21/04/19 17:37:07.25 QqvLWpkW.net
unsafeがライブラリに隠蔽されていてかつ性能が出ることはRustのコンセプトが正しかったことの証明になるのでは？

174:デフォルトの名無しさん
21/04/19 17:58:35.97 eG8AP0Ht.net
今月のWEB+DB PRESSに載ってる簡易的なRDBMSをRustで実装する記事結構いいぞ
RDBMSの仕組みを学ぶことが主眼でRustの解説は最低限なんだけど
Rustでよく使うパターンが

175:デフォルトの名無しさん
21/04/19 17:59:44.87 cPEAzkUm.net
「じゃあC++使えばいいよ」で済む質問を何度投下すれば気が済むのか

176:デフォルトの名無しさん
21/04/19 18:02:01.96 Nl1mmVW4.net
だって入れ食いなんだもん…

177:デフォルトの名無しさん
21/04/19 18:15:13.40 zaOVVmA+.net
>>173
リトマス試験紙なんよ
C++で苦労した奴は文句は言わない。Rustが何をしてくれようとしてるのか分かるから。
C++ニワカは文句を言う。Rustが何をしてくれようとしてるのか分からないから。

178:デフォルトの名無しさん
21/04/19 18:56:00.14 7a+3hK+O.net
>>171
言ってる意味がまるでわからんのだが。

179:デフォルトの名無しさん
21/04/19 19:29:57.41 OqiIdPZa.net
大半の人は、C/C++で苦労も何もしてないだろう
何が危ないのかも理解しないまま、危険なコードや穴の空きやすいコードを書いてるだけだ

180:デフォルトの名無しさん
21/04/19 19:51:48.28 iY2hw6vD.net
C/C++でメモリをぶっ壊して数日絶望するところまでがチュートリアル

181:デフォルトの名無しさん
21/04/19 19:59:51.22 sjEpEGTN.net
メモリぶっ壊すのは絶望ではない、C++の日常だ

182:デフォルトの名無しさん
21/04/19 20:10:50.91 hAOdtYDs.net
>>178-179
この人たち未だにC++でnewとかdelete多用してるかそれを通過儀礼のように捉えてる人たちだよね
こえ～
よくある職

183:場の老害像そのものじゃん

184:デフォルトの名無しさん
21/04/19 20:11:49.67 sjEpEGTN.net
アマチュア君にはそう見えるんだね

185:デフォルトの名無しさん
21/04/19 20:13:49.42 cPEAzkUm.net
さすがに日常ではないかな……
構造体の初期化にmemset使うようなC言語上がりのやつはどうだか知らんけど

186:デフォルトの名無しさん
21/04/19 20:16:58.02 swd16GZO.net
毎日のようにRustスレで繰り返し同じ事をグチグチ言ってる自称C++使い達はよっぽど暇なんだなぁって思う

187:デフォルトの名無しさん
21/04/19 20:21:28.79 7a+3hK+O.net
c/c++でそんだけ壊れるならrustでもunsafe使ってぶっ壊れまくるだろ。。
エアプ丸出しすぎるわ

188:デフォルトの名無しさん
21/04/19 20:21:54.23 iY2hw6vD.net
引数チェックのないライブラリ等で引数を誤ったりすると
パッと見正しく見えるのでかなり面倒なことになる

189:デフォルトの名無しさん
21/04/19 21:31:37.98 LNECVJtJ.net
AddressSanitizerを使ったことのないものだけが石を投げよ

190:デフォルトの名無しさん
21/04/19 22:14:40.51 w0HdGBDs.net
伸びてると思ったら。次からﾜｯﾁｮｲ付けろよ。

191:デフォルトの名無しさん
21/04/20 00:56:58.25 h4Yrn7zO.net
URLﾘﾝｸ(trends.google.com)
Google Trends での Rustと他の言語とのトレンド比較。
これを見る限り、Rust言語は全く流行ってないようだ。

192:デフォルトの名無しさん
21/04/20 00:59:14.52 h4Yrn7zO.net
Python>Java>=JS>C++>>>>Rust

193:デフォルトの名無しさん
21/04/20 01:00:58.56 P7hWVPU6.net
そんな超メジャー言語と比較されるようになったのか

194:デフォルトの名無しさん
21/04/20 01:04:41.62 h4Yrn7zO.net
>>190
逆にそんなマイナーな言語なのに書籍が出たりtwitterでRustとWasmが
対になって出たりしてたのか。
Rustを試してる人は書籍や雑誌記事を書いて食っていくかか、難しくて新しい言語
を知ることで自分の社会的評価(?)を上げようとしているのか。

195:デフォルトの名無しさん
21/04/20 01:11:58.24 P7hWVPU6.net
>>191
なんかかっこいい嫌味を言いたいみたいだけど
意味不明ですべってるぞ

次ページ