◎正当な理由による書き込みの削除について:      生島英之とみられる方へ:

Rust part10 ->画像>2枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/tech/1617367084/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1デフォルトの名無しさん
2021/04/02(金) 21:38:04.11ID:L7IeSfpL
Mozilla発のRust言語のスレ

公式
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 part9
http://2chb.net/r/tech/1598112455/
2デフォルトの名無しさん
2021/04/02(金) 23:38:41.76ID:fjFXuKAx
立て乙>>1
3デフォルトの名無しさん
2021/04/03(土) 14:21:28.71ID:/AAJGIzP
前スレ:
「まともにrustでc++並の開発速度で製品作ってから言えや」
って深い言葉だ。
4デフォルトの名無しさん
2021/04/03(土) 14:26:31.17ID:SyvybhgS
自分で書いたのに?
5デフォルトの名無しさん
2021/04/03(土) 14:53:21.44ID:/AAJGIzP
>>4
書いてない。
6デフォルトの名無しさん
2021/04/03(土) 18:20:50.26ID:FsaMqi3u
書いてないことは取り上げるまでもない
7デフォルトの名無しさん
2021/04/03(土) 19:30:37.63ID:SyvybhgS
まあrustを積極的に使えと言うことらしい
8デフォルトの名無しさん
2021/04/03(土) 20:35:13.31ID:AKsD3jpb
積極的に使えば欠点が良く理解できるようになるからね。とても有効だよ。
9デフォルトの名無しさん
2021/04/03(土) 21:46:35.78ID:FsaMqi3u
費用対効果はしばらくは注意深く見守る必要が
10デフォルトの名無しさん
2021/04/03(土) 22:01:52.54ID:RYKBObRk
費用対効果を見積もるにも実際のプロジェクトで使ってみるのが一番。
まあ俺は巻き込まれたくはないが。
11デフォルトの名無しさん
2021/04/04(日) 00:05:12.47ID:EgnLn3Yg
C++使ったこと無いけど趣味開発だしrust使うわ
12デフォルトの名無しさん
2021/04/04(日) 01:07:15.87ID:qybbKpH3
>>11
勝手に使えばいいよ。
13デフォルトの名無しさん
2021/04/04(日) 14:56:23.48ID:cWc/MaHx
秀和システムのキンドル本って、あれはセールで半額になったりするもんなの?
14デフォルトの名無しさん
2021/04/05(月) 08:07:37.55ID:0j1wJjru
日本はランニングコストが軽視されやすいからね
15デフォルトの名無しさん
2021/04/06(火) 01:06:18.21ID:Ftkx6t//
C/C++は適当に動かすだけなら簡単だろうけどさ
ヘッダーファイルの作法、makeファイルの作法、古いコンパイラやリンカへの配慮・・・・みたいな独学困難な領域が多くあるからな
16デフォルトの名無しさん
2021/04/06(火) 02:13:12.02ID:/NFP4YRd
そういう人は低レイヤーを触るのがそもそも間違ってる。
17デフォルトの名無しさん
2021/04/06(火) 02:33:17.68ID:G1ho10ZT
まともなマニュアルすらないからな。魔境
18デフォルトの名無しさん
2021/04/06(火) 04:24:25.20ID:BW0cQchg
>>15
独学するしかないと思ってた
19デフォルトの名無しさん
2021/04/06(火) 09:55:26.42ID:Jj+MMoYg
cmakeやmesonやIDEの支援があると言ってもやはり敷居は高いわな

だがrust使うにせよC/C++のライブラリ使ったりドキュメント読む羽目になるのでやはりある程度相互運用の知識は必要
20デフォルトの名無しさん
2021/04/06(火) 11:13:42.73ID:gf2H4NQV
オープンソースの makefile は無意味なごみが集まってるから読みにくいだけ。
特に gnu makeがおかしい。
gnu 系はヘッダファイルもソース本体も汚い事が多い。
21デフォルトの名無しさん
2021/04/06(火) 12:13:30.74ID:cPUJlmRG
ここにはC++使いしかいないのか
22デフォルトの名無しさん
2021/04/06(火) 12:16:43.42ID:jsUZfCa/
その類のmakefileはautoconfとautomakeで自動生成されるもので、人間が読むものじゃないでしょ
23デフォルトの名無しさん
2021/04/06(火) 12:28:15.32ID:wB2vBd3T
C++03の地獄を見てきた者達だ
面構えが違う
24デフォルトの名無しさん
2021/04/06(火) 16:42:56.60ID:23z+dMzq
Rust の世界だけを考えるならビルドプロセスは Cargo に書いておけばそれで OK だけどね。
全て Rust だけでは書けない場合には従来のツールチェインに更に Cargo が加わって余計にややこしくなってるとも言える。
https://xkcd.com/927/

ツールが汚いのは現実が汚いからだよ。
汚い現実から目をそらして綺麗なルールの中に閉じこもっても、
汚い現実が消えてなくなるわけじゃない。

Makefile が不愉快なら Makefile を使わないプロジェクトを増やすのを頑張るこったな。
25デフォルトの名無しさん
2021/04/06(火) 17:35:44.74ID:EMKAWWjR
rustだけのプロジェクトでもcargo-xtaskを使ってたりするからcargoだけですべてOKかというと微妙だけどね
タスクランナーやビルドのポストプロセスなんかのサポートって予定されてるの?
26デフォルトの名無しさん
2021/04/06(火) 18:23:14.98ID:dIxoLwXV
Rust版makeみたいなツール見かけた気がする
27デフォルトの名無しさん
2021/04/06(火) 19:12:35.86ID:i3cN7eS9
>>26
https://github.com/sagiegurari/cargo-make
28デフォルトの名無しさん
2021/04/06(火) 23:23:49.86ID:cPUJlmRG
そういうのあるの知ってるけどcargo本体に取り込む予定があるかが気になってる
グローバルにその手のツールインストールするとバージョン固定が難しいので
npmみたいにlocal installできるならそれでも良いけど
29デフォルトの名無しさん
2021/04/07(水) 09:04:42.45ID:rL66qkG6
対応は結構してるわな。ただここの連中はこれくらいもできなさげ。
https://qiita.com/mutuya/items/f00a5b99a3f047dc3cb3
30デフォルトの名無しさん
2021/04/07(水) 13:04:30.43ID:zl6LVrRO
>>27
使ってる人いる?
31デフォルトの名無しさん
2021/04/07(水) 13:14:18.37ID:nIst5pc0
>>30
マルチプラットフォームで単純なmakeより複雑なことをしたいときには使っている。ただ大抵の場合makeでいいんじゃないかとも思う。
32デフォルトの名無しさん
2021/04/07(水) 13:18:48.25ID:uzth3iNv
Rust in the Android platform
https://security.googleblog.com/2021/04/rust-in-android-platform.html
33デフォルトの名無しさん
2021/04/07(水) 14:06:22.69ID:g0cTo5ct
>>22
ところがそのautoconf系そのものがそもそも汚い。
そして、autoというのは真っ赤な嘘であることが知られている。
34デフォルトの名無しさん
2021/04/07(水) 14:24:24.61ID:zl6LVrRO
たまにCMakeが無いとcargo installがこけるツールがあってげんなりするわ
35デフォルトの名無しさん
2021/04/07(水) 15:05:49.86ID:JRewXnwY
m4マクロで書くというのはそろそろやめにしてもらいたい
36デフォルトの名無しさん
2021/04/07(水) 18:53:05.80ID:4oC9i5VP
>>30
既定のタスクをそのまま使う分には便利だけど、ちょっとアレンジしようとするとめんどくさかったという感想。
単に慣れの問題かもだが、gnu makeのMakefile中でcargo叩く方がやりやすかった。
37デフォルトの名無しさん
2021/04/08(木) 16:35:24.79ID:1ecqYbtl
>>32

Rust言語でAndroidはより強固・安全に ~GoogleがOS開発への導入を進める
https://forest.watch.impress.co.jp/docs/news/1317183.html
38デフォルトの名無しさん
2021/04/08(木) 16:40:19.95ID:dggq93E7
Rustバイナリにユーザー名が埋め込まれる脆弱性が発見された
39デフォルトの名無しさん
2021/04/08(木) 19:01:45.52ID:gM5Az3ay
スーパーでよく見かける生産者表示だ、気にするな
40デフォルトの名無しさん
2021/04/08(木) 19:25:11.32ID:Y7HoyqEo
ユーザー名といかコンパイル時のソースのフルパスね
ホームディレクトリ配下にソースがあるならログインユーザー名が含まれる
あと発見されたのは最近ではなかったはず
41デフォルトの名無しさん
2021/04/08(木) 20:20:07.26ID:mAsGX/mS
それを消すためのオプションは数年前から付いてて
そのオプションがうまく効かないケースがあるってバグが修正中なはず
最近あったのは単にその話を記事に書いた人がいるってだけ
42デフォルトの名無しさん
2021/04/08(木) 20:20:24.34ID:bT2+gYi+
ディレクトリ名にマイナンバーを入れてる人がいたらどうすんだまったく
43デフォルトの名無しさん
2021/04/08(木) 20:46:41.37ID:KJ+7YtJl
どんな間抜けだよ
44デフォルトの名無しさん
2021/04/08(木) 21:41:22.53ID:2f4Y47iQ
ディレクトリ名につい「クソプロジェクト」とか入れてるやつはいるだろ
45デフォルトの名無しさん
2021/04/09(金) 01:29:12.23ID:q4HnPycb
ていうかログインユーザー名に実名いれるとかバカなんじゃないか
46デフォルトの名無しさん
2021/04/09(金) 01:29:59.12ID:q4HnPycb
>>44
たしかに・・それに近いことは・・ある。
47デフォルトの名無しさん
2021/04/09(金) 11:49:57.87ID:GRSPIdCN
fuck_you_cplusplus とか普通にありそう
48デフォルトの名無しさん
2021/04/09(金) 15:11:34.90ID:6eEbkgDq
どこのモジラだよ。
49デフォルトの名無しさん
2021/04/09(金) 20:07:51.03ID:+qIWqkLA
Linusじゃないの
50デフォルトの名無しさん
2021/04/10(土) 00:22:28.46ID:mUxV1BIo
Linusが吠えた! ─中指立てて「NVIDIAは世界最悪の企業」
https://gihyo.jp/admin/clip/01/linux_dt/201206/18

それはそうとして、Rustの(Goもだが)「..」が
begin~lastの意味ではなくて
begin~last+1なのは
コメントに「arr[0..3]」とか書きたい場合に地味に困る
51デフォルトの名無しさん
2021/04/10(土) 02:24:29.60ID:0NXaZP8I
>>42
ネタにマジレスするけどマイナンバーはただの概念で
国民識別番号は国のサーバーに有る。

>>50
last+1って何? ..は[begin, last)だぞ。
左閉右開半開区間はPLじゃ一般的だけど。
52デフォルトの名無しさん
2021/04/10(土) 03:35:58.01ID:mUxV1BIo
>>51
begin~last すわなち [begin, last] をRustで書いたら
begin..last+1
になる、という意味やったサーセン、

しかしコメント内に現れた「a..b」は、Rust式に[a, b)と解釈すべきなのか、
それとも伝統的な[a, b]解釈とすべきなのか
というのがそこはかとなく疑問が……
53デフォルトの名無しさん
2021/04/10(土) 03:38:59.03ID:mUxV1BIo
同じことは「=」と「==」(代入と等値)の使い分けを
コメント内にまで持ち込むべきかどうかという意味で
昔から迷う感じだったものがRust(やGo)の「..」のせいで悩みの種が増えたは!
54デフォルトの名無しさん
2021/04/10(土) 10:43:41.15ID:+2v3HD7B
>>52
Rustコード中ではbegin..=lastって書いたほうがいい(>=rust-1.26.0)
知ってたらすまん

>>53
Rubyもそうだぞ
55デフォルトの名無しさん
2021/04/10(土) 10:51:20.63ID:gEDOL+ak
pythonもじゃないか?
C系のfor(int i=0;i<5;i++)の終了条件に合わせてあるのかと思う
56はちみつ餃子 ◆8X2XSCHEME
2021/04/10(土) 11:33:17.54ID:0qKWjqEq
最後の要素を意味するときは last で、
最後の要素のひとつ後を指すときは end を使う習慣があると
どこかで見た覚えがあるんだけど、
別の言語だったかもしれないしどこかの数学分野だったかもしれない。
うろおぼえでスマソ
57デフォルトの名無しさん
2021/04/10(土) 11:52:10.96ID:K51XBEHT
既存の言語でも a..b が [a,b] になるもの、[a,b) になるものが混在してたこと、
また、見た目で意味が明確にわかることから a..b と a..=b を採用したという経緯だった気がする
58デフォルトの名無しさん
2021/04/10(土) 16:42:23.36ID:l4RzKTvO
https://doc.rust-lang.org/book/ch02-00-guessing-game-tutorial.html
の一番最後のコードをコピペしてもエラーで動かないのですが
どこをなおしたらいいのでしょうか?
59デフォルトの名無しさん
2021/04/10(土) 17:11:01.23ID:gEDOL+ak
cargo. tomlそのままってオチかな?
60デフォルトの名無しさん
2021/04/10(土) 17:13:25.76ID:l4RzKTvO
randの追加はしております
61デフォルトの名無しさん
2021/04/10(土) 17:23:47.25ID:+2v3HD7B
エラーメッセージを
62デフォルトの名無しさん
2021/04/10(土) 17:24:38.49ID:gEDOL+ak
エラーそのまま貼らないとわからないわ
と言うか頭からやりなよ
63デフォルトの名無しさん
2021/04/10(土) 17:50:35.32ID:gEDOL+ak
せっかく日本語訳だってあるわけだし
https://doc.rust-jp.rs/book-ja/ch02-00-guessing-game-tutorial.html
64デフォルトの名無しさん
2021/04/10(土) 21:25:06.44ID:l4RzKTvO
あ、すいません
randのバージョンを最新版のものにしてました
チュートリアルで指定されているバージョンにしたら動きました
失礼しました
65デフォルトの名無しさん
2021/04/10(土) 21:28:15.45ID:ugs90wL2
乱数なんて超基本的なライブラリが
コンパイル通らないぐらいのAPI変更を簡単にやってしまうなんて大丈夫なのかこの言語
66デフォルトの名無しさん
2021/04/10(土) 21:58:15.68ID:gEDOL+ak
この場合は言語の責任でもないしそのためのcargoだし
67デフォルトの名無しさん
2021/04/10(土) 22:07:11.12ID:gEDOL+ak
でもせっかくこういう体験したのであればソースの方を直すのも正しき甲殻類な気がするな
68デフォルトの名無しさん
2021/04/10(土) 22:55:00.58ID:DbIYjEaQ
最近使ってないけど
randってなんか使いにくいAPIだった気がする
69デフォルトの名無しさん
2021/04/11(日) 01:46:09.52ID:+yU+1pdE
最近マシになってきた
70デフォルトの名無しさん
2021/04/11(日) 03:28:20.09ID:FNN81f5r
マシにする為だろうが一度決めたAPIは変えない
それがC/C++界の掟じゃないのか?
71デフォルトの名無しさん
2021/04/11(日) 08:22:28.91ID:/Boh3f8b
絶対に変えないようにした結果かえってひどいことになってるイメージ
72デフォルトの名無しさん
2021/04/11(日) 08:57:50.42ID:SN158GXT
普通は破壊的仕様変更のときはメジャーバージョン変えそうなもんだがバージョン0だからな
73デフォルトの名無しさん
2021/04/11(日) 09:07:58.37ID:QZzlCmlR
バージョン0のうちは破壊的な変更もし放題ということか
74デフォルトの名無しさん
2021/04/11(日) 09:12:29.26ID:SN158GXT
そいや非推奨や廃止の警告出せたっけ?
75デフォルトの名無しさん
2021/04/11(日) 10:02:11.52ID:8BAcJ5Wr
>>74
deprecatedアトリビュートで出せるよ
76デフォルトの名無しさん
2021/04/11(日) 10:25:10.63ID:SN158GXT
Microsoftがプログラミング言語「Rust」への支援を強化
https://news.yahoo.co.jp/articles/d9e8b5acb96920789bb4364951481f074bfd93d8

visual rustとか出さないでよね…

>>75
だよねえ
どのバージョンで変えるか警告はするよねえ
77デフォルトの名無しさん
2021/04/11(日) 10:47:22.32ID:SN158GXT
んでバージョン指定変えてみたら

get_rangeの引数が最小、最大+1の2つから最小..最大+1の範囲リテラルに変わったのね

カンマを..に一ヵ所変えるだけだったから修正自体は対したことなかったけどオーバロードがあればもっと緩やかな改変が出来るのだろうか?
ゼロコスト抽象化の方針上仕方ないのだろうか?
78デフォルトの名無しさん
2021/04/11(日) 11:24:02.64ID:FNN81f5r
>>77
そんなしょうもない変更の為に互換性破壊したのか
79デフォルトの名無しさん
2021/04/11(日) 11:29:55.74ID:duIaxYyg
>>78
..= が使えるようになったとあるのでインターフェースの改善ではあるのでは
あと破壊的変更はこれだけではない
https://rust-random.github.io/book/update-0.8.html
80デフォルトの名無しさん
2021/04/11(日) 12:27:09.74ID:SN158GXT
マイナーバージョンが上がるのでも結構変わると言うことか
81デフォルトの名無しさん
2021/04/11(日) 13:05:02.83ID:/JadX22/
バージョン0のうちはね
82デフォルトの名無しさん
2021/04/11(日) 13:15:29.70ID:SN158GXT
誰かも言ってたけどこう言うのは標準ライブラリで整備してほしい所だあな
83デフォルトの名無しさん
2021/04/11(日) 13:43:12.49ID:4rSwKpry
乱数は用途によってアルゴリズム使い分けにゃならんからなぁ
Cのrandはまぁ使えないとしてC++のrandomまで行くと重い
84デフォルトの名無しさん
2021/04/11(日) 14:40:26.89ID:duIaxYyg
randの設計が安定しない現状でstdに入れるにしても
かなり限定されたサブセットしか入れられないのでは
85デフォルトの名無しさん
2021/04/11(日) 17:41:37.63ID:aRgjPq06
それで十分だろ。
メルセンヌツイスターとか必要な場合は各々入れたら良い。
手軽な乱数を必要とする場面は割とある。
86デフォルトの名無しさん
2021/04/11(日) 21:41:09.50ID:LXnW0jT4
メルセンヌ・ツイスタ、MT19937 を使っているのは、Ruby ぐらい

他の言語は、低品質
87デフォルトの名無しさん
2021/04/11(日) 22:30:00.44ID:2GAqbccY
一瞬信じかけたけど、pythonもboostもmtだったわ
88デフォルトの名無しさん
2021/04/11(日) 22:41:39.90ID:FNN81f5r
何でそんなとこで嘘つくん?
89デフォルトの名無しさん
2021/04/11(日) 23:24:19.82ID:REr5r+Uo
>>85
直近でThreadRngやRngも破壊的変更されてて
乱数生成器の種類を充実させるとかそういうレベルにすら達してないのよ
90デフォルトの名無しさん
2021/04/12(月) 16:58:50.31ID:JNYj24al
一部のプログラミング言語では、デフォルトの疑似乱数生成器としてメルセンヌ・ツイスタが
標準ライブラリに取り入れられている。そのような言語の例として、 Python,[2][3] Ruby,[4]
R,[5] PHP,[6] MATLAB, C++[7](C++11から) がある。
91デフォルトの名無しさん
2021/04/12(月) 19:41:31.46ID:bbHno7r0
よそはよそ!うちはうち!
92デフォルトの名無しさん
2021/04/12(月) 21:18:15.82ID:z80SpJNy
線形合同が、あまりに低品質
93デフォルトの名無しさん
2021/04/12(月) 21:49:55.90ID:b3c5oHjh
オライリー調査で明らかに--Go、Rust、Ruby、Dartに関心高まる - ZDNet Japan

https://japan.zdnet.com/article/35169143/
94デフォルトの名無しさん
2021/04/12(月) 22:02:51.56ID:mno1Imjq
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です
95デフォルトの名無しさん
2021/04/12(月) 22:08:31.70ID:mno1Imjq
すいません
とほほのRust入門見て解決しました
type_ofを関数として定義しないとダメなんですね

https://docs.rs/typed/1.0.0/typed/fn.type_of.html
にページがあったので組み込み関数があるものだと思いこんでたら
そういうものは存在しなくて,type_ofの関数を定義しないとダメだったようです

kindleで入門書を購入したのですがそこが省略されておりはまりました
失礼しました
96デフォルトの名無しさん
2021/04/12(月) 22:40:04.94ID:J2Rjxost
乱数ってxorshiftとかxoroshiroもあるわけで
まぁアルゴリズム固定は難しいでしょう
97デフォルトの名無しさん
2021/04/12(月) 23:08:15.49ID:/+zeTQQu
no_std環境も考えるともし一つ選ぶならMTよりxorshiftかなぁ。Rustの方針に合わないから入ることはないだろうけど。
98デフォルトの名無しさん
2021/04/13(火) 00:51:04.66ID:zVaLotRH
APIをどうするかどこまでリッチにするかとかも難しいんだろ
99デフォルトの名無しさん
2021/04/13(火) 01:57:46.80ID:dtk27dGR
xoroshiro1024がないんだよね。

>>95
```shell
rustup doc --std
```
100デフォルトの名無しさん
2021/04/15(木) 21:01:10.98ID:aIjUzI+d
パニックお断り―Linus,"Rust for Linux"の盛り上がりに釘を刺す
https://gihyo.jp/admin/clip/01/linux_dt/202104/15
101デフォルトの名無しさん
2021/04/15(木) 21:13:33.74ID:aIjUzI+d
JavaScript/TypeScriptランタイム環境「Deno 1.9」がリリース、パフォーマンス向上に寄与する機能追加など
https://codezine.jp/article/detail/13970
102デフォルトの名無しさん
2021/04/16(金) 04:30:01.56ID:h4psCBcA
>>100
メモリの確保に失敗したくらいでpanicはしないが
alloc::alloc::Allocatorの一部メソッドはpanicするから
no_core上にpanicしないアロケータ実装すればよさそう。

コンパイル遅いのはキャッシュするしかない。
103デフォルトの名無しさん
2021/04/16(金) 09:28:25.44ID:eEnfPPGg
結局kernelやるならunsafeつけまくりにしかならんだろ。
そうするとなぜrustで?という事になる。
104デフォルトの名無しさん
2021/04/16(金) 09:50:50.04ID:MkjaOpjL
>>102
その「panicしないアロケータ」を使った Vec やらなんやら全部実装しなおさないといけなくならない?
105デフォルトの名無しさん
2021/04/16(金) 18:31:00.46ID:7IMcJQmu
>>104
といっても変えるのはnewとかくらいで大半の実装はそのままもってくればいいんじゃない?
まあパッチ投げてる人もそこは作業量多いとは言ってるけど。
106デフォルトの名無しさん
2021/04/16(金) 18:54:38.72ID:GwffY4ld
>>104
Vec等のコンテナにはtry_reserveとかのメモリ割り当て失敗でエラーにする関数用意されているから
メモリ割り当ての失敗だけが問題ならliballocの使い方を変えるだけでよいのでは
他にpanic要因あるならだめだけど
ちなみにnewはメモリ割り当てしないから変更不要
107デフォルトの名無しさん
2021/04/16(金) 21:12:31.63ID:eEnfPPGg
ある種の「コンテキストに対するunsafe」をつけて回らなきゃ無理。
でもってそれはmoonshotだって言ってるわな。
https://lkml.org/lkml/2021/4/14/1140
108デフォルトの名無しさん
2021/04/16(金) 21:47:54.90ID:GwffY4ld
特定の関数が割り込みのコンテキストから呼び出されたときにコンパイルエラーにすることは
今の言語機能では不可能という話か
109デフォルトの名無しさん
2021/04/16(金) 23:21:39.03ID:Xc/jdFUF
>>107
role orientedな言語でコンパイラが特別扱いする
コンテキストを指定できれば実現できる、
ここまで考えてだからmoonshotなのかと。
110デフォルトの名無しさん
2021/04/16(金) 23:46:26.48ID:Kk/3g/Ul
Cでも出来てないことを要求してどうすんの
111デフォルトの名無しさん
2021/04/17(土) 00:54:40.80ID:r+Flv24K
知らんがな。どうしてもrustでkernel作りたいってやつに言えや。
112はちみつ餃子 ◆8X2XSCHEME
2021/04/17(土) 02:30:05.79ID:V2rXjiTW
Linux のカーネルはカーネルとは言ってもかなり巨大なので
現状の Rust でも採用可能な箇所もあるんでないの。
知らんけど。
113デフォルトの名無しさん
2021/04/17(土) 08:49:33.19ID:r+Flv24K
>>112
だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。
何周遅れてんだよ。
114デフォルトの名無しさん
2021/04/17(土) 09:05:35.37ID:dMPv+0ET
グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え
https://japan.zdnet.com/article/35169455/

利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな
115デフォルトの名無しさん
2021/04/17(土) 09:33:32.53ID:tTsG+vVF
linusすごいな
Rust関わってる人全員子供扱いかよ
116デフォルトの名無しさん
2021/04/17(土) 10:42:23.64ID:r+Flv24K
いや、これrustでkernelに関わろうとした人たちが低レイヤーのこと、あまりにわかってなさすぎだろ。。
これ、ほぼ素人の俺でも気づくような内容だぞ
117デフォルトの名無しさん
2021/04/17(土) 10:53:16.85ID:ttx9Ve6D
へぇ、すごいんですねぇー^^
118デフォルトの名無しさん
2021/04/17(土) 10:55:23.76ID:r+Flv24K
冷笑系気取りのバカって本当に救いようがないよな。
119デフォルトの名無しさん
2021/04/17(土) 11:09:22.71ID:h7zOlTtk
C++でもコンテナに値を追加しようとすると、メモリー不足で追加に失敗
する可能性があるが、それをいちいちチェックする人はまず居ないだろうな。
デスクトップマシンでそれに失敗する可能性はとても低いけども。
120デフォルトの名無しさん
2021/04/17(土) 11:14:10.31ID:h7zOlTtk
例えば、
std::vector<int> v; // 空の動的配列を生成
for ( unsigned int i = 0; i < 100000000; i++ ) {
v.push_back(i + 100); // 末尾に i + 100 という値を追加
}
とした場合、環境やマシンの状態によってはメモリー不足で失敗することは
あるだろうが、これをいちいちエラーチェックする人は少ないだろう。
121デフォルトの名無しさん
2021/04/17(土) 11:22:45.09ID:3/shspJz
>>116
https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html

歴史的背景はこことか見ると書いてあるけど、処理系の初期開発で想定されていたほとんどの開発者はallocation errorから回復する必要がないから、あえてそういうAPIデザインにしたと
カーネルはその「ほとんど」から外れる用途だからlinusは当然今のAPIじゃダメだと釘を刺す

だからallocator_apiその他の安定化が急がれる、それだけの話じゃないの?
122デフォルトの名無しさん
2021/04/17(土) 11:25:00.56ID:/69X/cno
linusへのレスポンス読んだ?
allocについては問題なのは認識してるけど
開発スピード上げるために今はliballoc使っていて
そのうち独自の物に置き換えると言っている
123デフォルトの名無しさん
2021/04/17(土) 11:27:24.53ID:t/1FzfAW
pure rustでカーネル作ってる人いるんだから
原理的に不可能ってわけでもないだろ
124デフォルトの名無しさん
2021/04/17(土) 11:29:13.13ID:LJqBKM+D
allocまで全部作り切ってからパッチ投げてLinusに却下って言われたら目も当てられんしな。プロトタイプの段階でこまめに出すのはいいと思う。
125デフォルトの名無しさん
2021/04/17(土) 11:37:37.77ID:h7zOlTtk
>>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)で失敗する可能性はとても低い。
126デフォルトの名無しさん
2021/04/17(土) 11:41:51.20ID:h7zOlTtk
N88-BASICでは、読み込みモードでファイルを開く時、
open "ファイル名" for input as #1
と書いていたが、ファイルが存在しないとここでエラーになって
アプリが終了していたことを思い出した。
Perl、Ruby、Pythonなんかは、全て基本的に同じ方針だと思う。
その流儀とRustでのメモリー不足時のpanicの方針も同じと考えていいだろうな。
127デフォルトの名無しさん
2021/04/17(土) 11:48:23.17ID:r+Flv24K
>>121
そう、それだけの話。でもそれだけの話がここでは恐ろしく通じない。
128デフォルトの名無しさん
2021/04/17(土) 12:20:31.25ID:3/shspJz
>>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デザインに問題があるみたいな話出てるの?
129デフォルトの名無しさん
2021/04/17(土) 13:30:05.64ID:5SUmF/jF
>>125
> if ( (ptr = new char [サイズ]) == NULL ) { // (2)
C++ は new も vector::push_back も bad_alloc が飛ぶ。ふつうの new は nullptr 返さない。
130デフォルトの名無しさん
2021/04/17(土) 13:35:37.75ID:YGcs/48d
てかアロケータの動作がどうのってLinux Kernel関係あるの?
ベアメタル用途全般が該当すると思うけど
131デフォルトの名無しさん
2021/04/17(土) 14:08:16.83ID:h7zOlTtk
>>129
そういえば、言葉は忘れたけど、関数宣言の行に、その関数の中でどういう
例外が起きる可能性があるかについてのthrows を書くかどうか、書くべきか、
省略しても良いか、などの違いが色々あって、どういう言語仕様にすべきかが
結構問題になっていると聞いた。
すべてを書くと多くなりすぎるし、全く書かないのも問題だとか、そんな話。
なんという言葉だったかな。
132デフォルトの名無しさん
2021/04/17(土) 14:30:50.99ID:ahfNUrst
allocatorがエラーを返さずに例外を上げる挙動にRustの標準ライブラリ的なもの(コレクションとかスマートポインタとか?)が依存していて、
それはLinuxカーネル的には許容できないからそういうコードをそのまま持ち込むなよ?ということでしょ

Linuxカーネル上のC言語はそもそも標準ライブラリとか使わないし
メモリ確保もmallocじゃなくてkmallocというカーネル内独自関数使うし

ここ見ると
https://medium.com/nttlabs/linux-kernel-module-with-rust-d5363c2f9085
array: vec![0;32] で kmalloc が呼ばれるみたいだね
でもこれLinuxのカーネルモジュールのコードとしてはそこでエラーチェックが必要になるのかね?
もしくはkmallocに失敗したらそのモジュール自体が自動でアンロードされるとか
でもアンロードされるときに後処理とかしたいかなとかいろいろ考える必要はありそう
133はちみつ餃子 ◆8X2XSCHEME
2021/04/17(土) 14:48:08.80ID:V2rXjiTW
>>131
動的例外仕様 (dynamic exception specification) のことか?
https://timsong-cpp.github.io/cppwp/n3337/except.spec
送出される可能性のある例外を記述する仕組みだったが、役に立ってなかったので C++17 で廃止された。
(例外を送出するかしないかだけを指定する方式が残された。)

C++ の仕様では例外を送出しないという指定を付けたところを例外が通過しようとしたら
std::terminate が呼ばれて異常終了扱いになるという、実質的な assert なんだわ。
静的な検査をカッチリやってくれるわけではないんで、
カーネル記述みたいな文脈では使い物にならんな。
134デフォルトの名無しさん
2021/04/17(土) 14:49:51.36ID:ohP60UMx
linuxだろうとwindowsだろうと普通のカーネルはそうだろ。
よっぽど特殊用途のOSならどうかは知らんが。
135デフォルトの名無しさん
2021/04/17(土) 15:49:17.42ID:h7zOlTtk
>>133
なんか、Javaにおいて、throwsに創出するすべての例外を書く仕様にしてみたら、
地獄のように沢山書かなくてはならなくなって困り、
関数プロトタイプ宣言の直後の throws()の中に
「書く必要のある例外」と「書かなくても良い例外」
の違いを設けることにした、この板で聞いた。
136デフォルトの名無しさん
2021/04/17(土) 15:56:30.53ID:h7zOlTtk
>>135
「OutOfMemoryError」例外は、throws に明示しなくて良いことになった
とWikipediaで見た記憶が有る。
137はちみつ餃子 ◆8X2XSCHEME
2021/04/17(土) 16:29:38.34ID:V2rXjiTW
>>135
検査例外と非検査例外のことだな。

例外の便利なところは大域脱出が出来るところで、例外を捕捉する箇所と発生する箇所の間では例外のことを忘れられる点。
発生しうる例外の伝播を明示しないといけないのだと返却値で返す形にするのと差がない。
例外を使っていると異常系だということが見た目に分かり易いってくらいのもの。

Java が明示しなくてよい例外という分類を設けたのは明示しなくてよいというだけでなく捕捉もしなくてよいということでもあって、
どのように使い分けるのがよいかは諸説あるけども、非検査例外は

・ 捕捉したところで回復できないもの
・ そもそもその例外を発生させないようにすべきもの (実質的には assert)

というのがおおよその共通認識になっている。
メモリ不足は回復不可能なので非検査例外に分類されているが、
「Java のレイヤでは」回復不可能という話であって、
Java では低レイヤを書かないという前提があるからこういう決め打ちが出来る。

低レイヤと高レイヤでは前提が違ってくるから同じようにはいかんのだ。
138デフォルトの名無しさん
2021/04/17(土) 16:34:30.24ID:h7zOlTtk
>>136
https://www.w3resource.com/java-tutorial/types-of-exception.php

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」なのでプログラマが対処することが難しい例外に分類される。
139はちみつ餃子 ◆8X2XSCHEME
2021/04/17(土) 16:46:23.23ID:V2rXjiTW
低レイヤでも高レイヤでも使うことを考えたらやっぱ例外という仕組みは使いにくいっつーことだな。
カーネルを書くにあたって Rust が (現状では) ベストというわけでもないだろうけど、
比較的可能性がある選択のひとつではあると思う。
どうせ標準ライブラリのフルセットを使えるわけではないのは C でも同じことだし。
140デフォルトの名無しさん
2021/04/17(土) 17:10:18.35ID:h7zOlTtk
Rubyなんかでファイルオープンする時にはエラー発生チェックをしなくてもよくて
エラーが発生するとpanicする。これは簡単なプログラムでは便利。
そしてbegin,rescue,endではさめば、panicせずにエラー処理することも
出来る様になっている。これはtry,catch構文と発想は同じ。
でも、読み書き用の2つのファイルをオープンして読んで加工して書き込む
ような時、catch文でどっちのエラーか区別したりするのは面倒といえば面倒かな。
C風だと、fopen の行で処理できて分かり易かったのに。
141デフォルトの名無しさん
2021/04/17(土) 17:12:33.63ID:h7zOlTtk
>>139
でも、リストに追加したときにメモリ不足になっても、例外機構でしか
エラーを補足出来ないのは面倒だな。
142デフォルトの名無しさん
2021/04/18(日) 02:29:17.84ID:xL1TJJG/
https://github.com/rust-lang/rust-bindgen/commit/0e25962c4e69aef647e7275fa7bc7545dbb8cd0b#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759
コロコロ変わってその度に置換するスクリプト書いてるんだけど、
二ヶ月くらい音沙汰ないからそろそろ名前くらい安定してほしい。
143デフォルトの名無しさん
2021/04/18(日) 09:49:21.11ID:vWwiRDOG
rustってそんなにいいか?
任意の場所でfreeできるcとは違って
ブロック抜けるタイミングでしかメモリ開放されないんだろ?
rustっていらなくなってもブロック抜けるまではヒープメモリ保持しないといけないってことなの?
144デフォルトの名無しさん
2021/04/18(日) 10:08:02.12ID:UN4umXE6
>>143
dropじゃだめなの?
145デフォルトの名無しさん
2021/04/18(日) 10:09:10.01ID:732wPalE
そんなに良くないからキミはもっとcを頑張ったほうがいい
cを頑張ってc++にも手を出して頑張って
気が狂いそうになるのを覚えてからもう一度来たらいい
146デフォルトの名無しさん
2021/04/18(日) 10:34:02.72ID:vWwiRDOG
>>144
lifetime内であれば手動で早期開放できるんですね
お世話になりました
147デフォルトの名無しさん
2021/04/18(日) 12:33:31.22ID:gA/cagL6
ワロタw
148デフォルトの名無しさん
2021/04/18(日) 12:57:11.20ID:UN4umXE6
vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか?
149デフォルトの名無しさん
2021/04/18(日) 13:12:40.26ID:/yrt+WGh
お前らの用途だったらgoで十分だろと思うことが多いわ。
ファッションでやるってのも悪くはないが。
150デフォルトの名無しさん
2021/04/18(日) 13:30:23.57ID:8MLIImZW
rustではunsafeを多用するのは良いことですか?
151デフォルトの名無しさん
2021/04/18(日) 13:39:58.68ID:a3mPgn8/
必要なら使えばいい
152デフォルトの名無しさん
2021/04/18(日) 16:52:32.86ID:dOXZMSKq
>>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に触れないからご注意を
153デフォルトの名無しさん
2021/04/18(日) 17:30:23.89ID:qHYw4Dd3
>>152
>蛇足だけどyが生きてる間はvに触れないからご注意を

蛇足ではない気がする
push時にその要素のmut refを必要とするような書き方は避けたほうがいい
154デフォルトの名無しさん
2021/04/18(日) 17:38:05.52ID:/DBGFH0C
entry APIみたいなことしたいのかな
155デフォルトの名無しさん
2021/04/19(月) 03:50:11.66ID:cH3u5yp0
Rustに比べたC++の良さは雑に書けるところだって気付いた
やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ
156デフォルトの名無しさん
2021/04/19(月) 08:44:54.89ID:4a/aZ6Q1
>>155
いいところに気付いたな
Rustは一般プログラマーには無用の長物だ
157デフォルトの名無しさん
2021/04/19(月) 10:48:10.96ID:7a+3hK+O
段階的に直していく方法と最初から設計で硬くしておく方法があると思うが
rustが念頭に置いてるのは明らかに後者。これがいいのか悪いのかは議論の余地がある。
158デフォルトの名無しさん
2021/04/19(月) 11:19:16.28ID:QqvLWpkW
型が強いからリファクタリングしやすいという意味では段々直していく方法に適しているとも言えると思うが
159デフォルトの名無しさん
2021/04/19(月) 11:21:50.23ID:7a+3hK+O
>>158
型の強さがある意味で強すぎて、メモリ解放のタイミングまでキッチリあってないと無理なんだが。
ちょっとしたリファクタリングするにもかなり大域的変更になる。
160デフォルトの名無しさん
2021/04/19(月) 11:34:35.17ID:VqBzpR75
>>155
雑に書いた脆弱性のあるバイナリを世に出さなきゃそれでもいいんじゃね
161デフォルトの名無しさん
2021/04/19(月) 13:02:55.04ID:sZaag2LS
>>160
何言ってんだこの馬鹿
Rust謹製なら脆弱性が無いとでも思ってんのか?
162デフォルトの名無しさん
2021/04/19(月) 13:06:52.92ID:hAOdtYDs
つーかRust以前はどうしてたんだよって話w
流行りのもんに飛びついてそれ以外見えなくなってる典型
163デフォルトの名無しさん
2021/04/19(月) 13:26:32.62ID:I7sE/fYQ
どうしてたって脆弱性を秘めたまま出回ってただろ
164デフォルトの名無しさん
2021/04/19(月) 13:27:33.53ID:k4Vsf7V5
いつものレイヤーとかスコープを
ごちゃまぜにする思考が乱雑な人でしょ
165デフォルトの名無しさん
2021/04/19(月) 14:27:55.78ID:7a+3hK+O
それお前だろ
166デフォルトの名無しさん
2021/04/19(月) 16:41:05.18ID:OqiIdPZa
まあ、C/C++が危なかろうが、自分のやりたい計算をするだけみたいな用途には向いてるよな
どうみても簡単で早いし・・・・
167デフォルトの名無しさん
2021/04/19(月) 16:57:54.64ID:QZprAv/b
>>155
C/C++は雑に書けるというより、Rustが想定してないでけで
本当は安全なプログラムも思った通りに書くことが出来る。
RustはRustが想定している範囲内でしか書けないので面倒なことになる。
168デフォルトの名無しさん
2021/04/19(月) 17:00:14.68ID:QZprAv/b
>>167
職人さんはさまざまな危険な道具を、十分安全に使う。
Rustは、「危険だ危険だ」と言って、危ない道具を使わせず
予め「刃(やいば)を抜かれた」道具の使用を強制する。
169デフォルトの名無しさん
2021/04/19(月) 17:08:36.65ID:QZprAv/b
AIの機械学習は計算が重いのに言語としては遅いところのPythonのAIは遅くはない。
なぜなら計算部分はC/C++で書かれたライブラリを呼び出して使ってるだけだから。
同様にRustがベンチマークで遅くないのは、実はunsafeモードで書かれたライブラリ
を使ってるせいもある。だからそのベンチマークだけでC/C++と同程度の速さ
であることの証明にはならない。
170デフォルトの名無しさん
2021/04/19(月) 17:33:10.17ID:QqvLWpkW
>>169
具体的に何のベンチマークのことを言っているの?
171デフォルトの名無しさん
2021/04/19(月) 17:37:07.25ID:QqvLWpkW
unsafeがライブラリに隠蔽されていてかつ性能が出ることはRustのコンセプトが正しかったことの証明になるのでは?
172デフォルトの名無しさん
2021/04/19(月) 17:58:35.97ID:eG8AP0Ht
今月のWEB+DB PRESSに載ってる簡易的なRDBMSをRustで実装する記事結構いいぞ

RDBMSの仕組みを学ぶことが主眼でRustの解説は最低限なんだけど
Rustでよく使うパターンが
173デフォルトの名無しさん
2021/04/19(月) 17:59:44.87ID:cPEAzkUm
「じゃあC++使えばいいよ」で済む質問を何度投下すれば気が済むのか
174デフォルトの名無しさん
2021/04/19(月) 18:02:01.96ID:Nl1mmVW4
だって入れ食いなんだもん…
175デフォルトの名無しさん
2021/04/19(月) 18:15:13.40ID:zaOVVmA+
>>173
リトマス試験紙なんよ
C++で苦労した奴は文句は言わない。Rustが何をしてくれようとしてるのか分かるから。
C++ニワカは文句を言う。Rustが何をしてくれようとしてるのか分からないから。
176デフォルトの名無しさん
2021/04/19(月) 18:56:00.14ID:7a+3hK+O
>>171
言ってる意味がまるでわからんのだが。
177デフォルトの名無しさん
2021/04/19(月) 19:29:57.41ID:OqiIdPZa
大半の人は、C/C++で苦労も何もしてないだろう
何が危ないのかも理解しないまま、危険なコードや穴の空きやすいコードを書いてるだけだ
178デフォルトの名無しさん
2021/04/19(月) 19:51:48.28ID:iY2hw6vD
C/C++でメモリをぶっ壊して数日絶望するところまでがチュートリアル
179デフォルトの名無しさん
2021/04/19(月) 19:59:51.22ID:sjEpEGTN
メモリぶっ壊すのは絶望ではない、C++の日常だ
180デフォルトの名無しさん
2021/04/19(月) 20:10:50.91ID:hAOdtYDs
>>178-179
この人たち未だにC++でnewとかdelete多用してるかそれを通過儀礼のように捉えてる人たちだよね
こえ~
よくある職場の老害像そのものじゃん
181デフォルトの名無しさん
2021/04/19(月) 20:11:49.67ID:sjEpEGTN
アマチュア君にはそう見えるんだね
182デフォルトの名無しさん
2021/04/19(月) 20:13:49.42ID:cPEAzkUm
さすがに日常ではないかな……
構造体の初期化にmemset使うようなC言語上がりのやつはどうだか知らんけど
183デフォルトの名無しさん
2021/04/19(月) 20:16:58.02ID:swd16GZO
毎日のようにRustスレで繰り返し同じ事をグチグチ言ってる自称C++使い達はよっぽど暇なんだなぁって思う
184デフォルトの名無しさん
2021/04/19(月) 20:21:28.79ID:7a+3hK+O
c/c++でそんだけ壊れるならrustでもunsafe使ってぶっ壊れまくるだろ。。
エアプ丸出しすぎるわ
185デフォルトの名無しさん
2021/04/19(月) 20:21:54.23ID:iY2hw6vD
引数チェックのないライブラリ等で引数を誤ったりすると
パッと見正しく見えるのでかなり面倒なことになる
186デフォルトの名無しさん
2021/04/19(月) 21:31:37.98ID:LNECVJtJ
AddressSanitizerを使ったことのないものだけが石を投げよ
187デフォルトの名無しさん
2021/04/19(月) 22:14:40.51ID:w0HdGBDs
伸びてると思ったら。次からワッチョイ付けろよ。
188デフォルトの名無しさん
2021/04/20(火) 00:56:58.25ID:h4Yrn7zO
https://trends.google.com/trends/explore?date=today%205-y&;geo=US&q=%2Fm%2F0dsbpg6,%2Fm%2F02p97,Python,Java,%2Fm%2F0jgqg

Google Trends での Rustと他の言語とのトレンド比較。
これを見る限り、Rust言語は全く流行ってないようだ。
189デフォルトの名無しさん
2021/04/20(火) 00:59:14.52ID:h4Yrn7zO
Python>Java>=JS>C++>>>>Rust
190デフォルトの名無しさん
2021/04/20(火) 01:00:58.56ID:P7hWVPU6
そんな超メジャー言語と比較されるようになったのか
191デフォルトの名無しさん
2021/04/20(火) 01:04:41.62ID:h4Yrn7zO
>>190
逆にそんなマイナーな言語なのに書籍が出たりtwitterでRustとWasmが
対になって出たりしてたのか。
Rustを試してる人は書籍や雑誌記事を書いて食っていくかか、難しくて新しい言語
を知ることで自分の社会的評価(?)を上げようとしているのか。
192デフォルトの名無しさん
2021/04/20(火) 01:11:58.24ID:P7hWVPU6
>>191
なんかかっこいい嫌味を言いたいみたいだけど
意味不明ですべってるぞ
193デフォルトの名無しさん
2021/04/20(火) 02:00:40.62ID:1YS4Hj5E
>>161
雑に書いたコードだって自分で言ってんだろボケが
194デフォルトの名無しさん
2021/04/20(火) 08:34:25.33ID:A+mNu4wy
https://m.slashdot.org/story/384324
195デフォルトの名無しさん
2021/04/20(火) 10:41:16.90ID:MbK31k7w
なんか無駄なところに手を出しちゃったみたいになってる若い人が発狂してんのかね。
別にrustで学んだことは無駄にはならんよ。
現場でrust強要するのはクソだが。
196デフォルトの名無しさん
2021/04/20(火) 11:46:33.55ID:UmXg6L/G
5chに若い人なんかいないよ
197デフォルトの名無しさん
2021/04/20(火) 19:43:34.07ID:jXnHABO7
なるほどそれで皆C++の話ばかりするのか
198デフォルトの名無しさん
2021/04/20(火) 21:08:17.70ID:i+94ZV2W
C++もそれだけ枯れたか
199デフォルトの名無しさん
2021/04/21(水) 11:52:12.19ID:/JxRHm/B
C++ニワカのLinusはpanicは認めないと言う話をしてるのにアロケーターだけの問題だ
「それだけでしょ、分かってるやつ居なすぎ」とまとめる
範囲外のインデックスアクセスでもpanicするし、Debugなら整数のオーバーフローでも
panicする(なぜかReleaseだとpanicしない)とんでもないアホの勘違いはJavaを持って
きて検査例外と非検査例外の話をし出す。せっかくResult/OptionがあるのにRustの文化と
なっているpanicを通常は捕捉しないと言うものをKernelに持ち込むなと言う話。
範囲外アクセスで即座に既存のC/Kernelならレジスタを保存してダンプするような
Segment fault例外トラップなどが働くのに、panicでスタック巻き戻し実行が起こるのは
絶対的に受け入れられない言うとる
Cの悪名高きsetjmpや、C++のRTL/動的例外テーブルの議論を見てるようだ
検査例外と非検査例外の話をし出すアホはもう来るな
200デフォルトの名無しさん
2021/04/21(水) 12:24:14.02ID:dj6DJThv
++うんこ華麗にスルーして、やっぱリーナス見る目有るわ神だろ
201デフォルトの名無しさん
2021/04/21(水) 12:54:12.00ID:KSNXGwT5
別にそこまで褒めることでもないんだけどね。。
https://lkml.org/
の他の議論に比べて明らかに議論のレベルが低いわけで。。
202デフォルトの名無しさん
2021/04/21(水) 13:38:37.86ID:T0Zi2n6U
>>199
なんか何言ってるのか分からない部分が有るな。
203デフォルトの名無しさん
2021/04/21(水) 17:38:16.65ID:l2lL4TPp
js-sys見てたらJavaScript側の型の継承関係をDerefで表現しててびびった
こういうの普通なん?
204デフォルトの名無しさん
2021/04/21(水) 17:58:04.79ID:tLndpRqR
>>201
歴史があってどう実装すべきかという指針ができあがっているCと
手探りで指針を作りつつあるRustで議論のレベルが同じにならないのは自然なのでは
205デフォルトの名無しさん
2021/04/21(水) 18:42:16.83ID:KSNXGwT5
>>204
問題はそういう言語の問題まで行かず、カーネルが備えるべきところってな議論で止まってるって部分だけどね。
歴史という意味ではそもそもカーネルに対する歴史観が不足してる連中しかrustにはいないということになる。
206デフォルトの名無しさん
2021/04/21(水) 22:06:45.67ID:2oKQsBoE
プロセスがスローし、誰も補足しなかった例外を
最終的に捕捉してそのプロセスを終了させるのはOS(ことによったらカーネル)の仕事である

一方、カーネルが仮に例外をスローしてしまったら誰が最終的な捕捉の任を負うのか
について今今のOS論には目下定説が無い

Linux(リーナス)は「カーネルは何があっても例外をスローすんなハゲ、」という
古典的な立場
のやつ、
207デフォルトの名無しさん
2021/04/21(水) 23:10:54.58ID:/dktUqXg
機械語に例外なんてねーよ
いい加減なこと言ってんじゃねーや
208デフォルトの名無しさん
2021/04/21(水) 23:43:21.15ID:NQ0xHQya
>>206 CPUの例外と言語上の例外との区別が付いてないみたいね。
209デフォルトの名無しさん
2021/04/22(木) 00:18:18.68ID:41g4gqqa
>>203
javascriptでメソッドとか探すときにプロトタイプを遡っていく動きがあるけど
それをRustのドット演算子(.)がメソッド使える型になるまで自動で参照解決する仕様で
模倣したんだと思う

演算子の特殊な拡張は正規表現とか構文解析のライブラリでたまに見かけるけど
どちらかと言えばトリッキーな手法
210デフォルトの名無しさん
2021/04/22(木) 02:40:36.34ID:hZdbeIl+
panic上等のredox!
セキュリティホール開けるよりマシという理由だった。

>>203
アンチパターンだから通常のコードでは使うな。
トレイトメソッド呼べないからクソって所まではすでに
githubのissuesやrust internalsで合意が有る。
js-sysはffi(バインダ)だから仕方ない。
211はちみつ餃子 ◆8X2XSCHEME
2021/04/22(木) 02:53:02.19ID:3zTCC3Br
>>203
ガイドライン的には Deref はスマートポインタだけにしとけってことになってる。
https://rust-lang.github.io/api-guidelines/predictability.html#only-smart-pointers-implement-deref-and-derefmut-c-deref
212デフォルトの名無しさん
2021/04/22(木) 05:58:54.39ID:WQGVMWvQ
例外の最終的な捕捉をOSの仕事、と書いたのは語弊があったスマンカッタ、
正確に言えば言語のランタイムが最終的に捕捉してプロセスを自発的に終了する
(スタックのアンワインドは言語依存性が強いのでそうなっている

しかしプロセスが自発的にexit()したら誰がそれを処理するのかというとOSやんけ;;;
カーネルの中で例外を生じられたら誰が終了を担保するのかについて
OS論的に定説が無いのは真

>>208
いじょ
213デフォルトの名無しさん
2021/04/22(木) 06:34:32.34ID:WQGVMWvQ
で、別の観点の話をする、

OSがpanic上等というのはそれはそれでも良いが、
とにかくスタックのアンワインド処理は言語依存性が強いので
例外が通過する関数(ゼロコストの奴も含む)の巻き戻しのためには
関数のアドレスとスタックのアンワインド方法の対応表をランタイムが把握せねばならない
というわけでカーネル内の例外を認めると、その例外を最終的に捕捉する奴より
上の関数を全部同一言語・同一コンパイラで書かねばならないという縛りが生じる
現実にはそれで問題など生じないかしらんが、とにかくレイヤー分けに縛りが生じる
Redoxの一部をC++(等)で書くことは事実上不可能に、
214デフォルトの名無しさん
2021/04/22(木) 13:01:11.46ID:hZdbeIl+
>>212,213
なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ?

>>213
Linusがカーネル書くのに信用してないだけで
C++でもフリースタンディング書けるだろ。
C++のフリースタンディングは最低限の標準ライブラリは持つからrustのcoreクレートと同じ。
C++ならexception、abort,exitがある。
>>213がホストとベアメタルの区別がついてないだけじゃないか?
あと、redoxのpanicはスタックトレース吐いてx86のhltループするだけだから。

そもそもカーネルで標準のexitなんか呼ぶか。
215デフォルトの名無しさん
2021/04/22(木) 13:21:02.53ID:EDkBlaoV
Linux界隈といえばちょうど「マージしたパッチが研究目的にわざと脆弱性を含んだものだったことが発覚して激おこで送ってきた奴らの大学出禁にする」みたいな面白いことが起こってる模様
216デフォルトの名無しさん
2021/04/22(木) 13:49:41.54ID:I9diyMZ1
どうせお前らはOS書かないんだからどっちでもいいじゃん
217デフォルトの名無しさん
2021/04/22(木) 15:39:04.46ID:VwSZJGdV
linuxの騒動の話はさすがにスレチ
218デフォルトの名無しさん
2021/04/22(木) 21:04:10.86ID:ndVhN6HU
Cコンパイラゼミ消失問題を思い出した
https://twitter.com/rui314/status/1384422532363657221
https://twitter.com/5chan_nel (5ch newer account)
219デフォルトの名無しさん
2021/04/22(木) 23:08:37.40ID:y/lG5X/l
研究目的だろうがそうでなかろうがわざと脆弱性を含むパッチを簡単にマージできている、という状況が問題なんであって
腹たつから大学出禁にしたった、とやったところで根本的な問題は何も解決しないんだけどlinuxのメンテナンスしてる連中とか
linusを筆頭にとか老害頭ばっかりだから自分がスッとすれはそれでいいんだろうな
220デフォルトの名無しさん
2021/04/22(木) 23:21:38.67ID:5b2Tg2Qr
1) 善意でやってくれてる連中にケチつけんな
2) じゃあお前が根本的な解決とやらをやれ
3) もしくはその根本的な解決方法を彼らに教えてやれ
221デフォルトの名無しさん
2021/04/22(木) 23:33:32.83ID:Bg0clzlT
しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
らすとすぱぁとをきめるスレ
222デフォルトの名無しさん
2021/04/22(木) 23:52:38.76ID:KHhdvM96
rust厨八つ当たりw
223デフォルトの名無しさん
2021/04/23(金) 08:31:32.27ID:yuX3+THA
その脆弱性もUAFとかぬるぽデリファレンスとか未初期化領域の使用とか2重開放とか最近の言語じゃ明らかに意図してやらなきゃ起きないようなもんばっかだもんなぁ
そりゃC/C++にしがみついてる大先輩方にとっちゃ逆鱗だわな
224デフォルトの名無しさん
2021/04/23(金) 08:34:12.76ID:Lj3XxxY0
そんなもんunsafeしまくれば同じだろ。。
そういう問題じゃないことくらいわかるだろうに、本当の馬鹿だな。
225デフォルトの名無しさん
2021/04/23(金) 08:36:52.46ID:+YpcBxgU
C++とlinuxの話禁止な
226デフォルトの名無しさん
2021/04/23(金) 08:52:11.81ID:Lj3XxxY0
rustでOSかける->linus、panicある限り載せねーよ->rust信者発狂
227デフォルトの名無しさん
2021/04/23(金) 09:00:00.40ID:5QBVXmI/
発狂?むしろ歓迎
個人で使うようなアプリは好きなだけパニくれ
使われるアプリはパニくんなカス、これ常識だろ
228デフォルトの名無しさん
2021/04/23(金) 10:42:10.47ID:Lj3XxxY0
言語実装的にもそうなってないよねって話なんだけど、なんだか通じてなさげ。
229デフォルトの名無しさん
2021/04/23(金) 11:59:33.30ID:bX8BaI1F
rustにもgoのマスコットキャラみたいなのいないんですか?
230あめ ◆P0jSlC5fJs
2021/04/23(金) 12:13:46.74ID:hS4CVJbd
かにさん
231デフォルトの名無しさん
2021/04/23(金) 12:17:43.73ID:E6ocica9
>>214
>なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ?
カーネル内での例外を許すみたいな立場で話す人が居るから

例外メカニズムが言語ランタイムと不可分な理由は
>スタックのアンワインドは言語依存性が強いのでそうなっている (>>212

C言語みたいにそもそも例外メカニズムを持たない言語を使った場合のみ
言語ランタイムと切り離したカーネル設計ができてスキーリ
232デフォルトの名無しさん
2021/04/23(金) 12:23:39.46ID:Xbep6LJc
>>219
だから、脆弱性を簡単に盛り込めないように危険な団体を排除しただけだろ。
普通の対応だと思うけど?
233デフォルトの名無しさん
2021/04/23(金) 12:31:21.77ID:+YpcBxgU
>>231
> >なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ?
> カーネル内での例外を許すみたいな立場で話す人が居るから

いません
この話はおわり
234デフォルトの名無しさん
2021/04/23(金) 12:56:09.67ID:1/JMNo8Q
「注意すればC/C++でも問題ない」って意見は日本的だよな
人間はミスしないことが前提になっている
Rust Foundationのメンバーに言わせればそういう問題ではない
人間はミスするものだってなるんだろうけど
235デフォルトの名無しさん
2021/04/23(金) 13:00:34.48ID:Lj3XxxY0
そのミスの取り除き方のアプローチの違いだっていうことにさえ気づかない馬鹿。
236デフォルトの名無しさん
2021/04/23(金) 13:33:15.21ID:AZKiGQoD
c++でミスするような無能はrustでも使ってろと怒鳴り散らす
これが正しいアプローチ
237デフォルトの名無しさん
2021/04/23(金) 13:43:27.45ID:M88Kc634
>>229-230
なんで蟹なんだろうな。
PythonユーザーのことPythonistaって言うみたいに
RustユーザーのことRustaceanって言うけど、
これCrustacean(甲殻類)からCを取り除いたものなんだな。
238デフォルトの名無しさん
2021/04/23(金) 14:28:40.04ID:9+zMAQDa
エビにしろよな
カニだとRealtekと被るじゃん
239デフォルトの名無しさん
2021/04/23(金) 14:58:40.99ID:ntrIv3TW
大半の人は、C/C++の文法がわかる程度でプログラムを書いているのが現状だろう
何がミスなのかそもそもわかっておらず、Rustを勉強している人と話も噛み合わない
240デフォルトの名無しさん
2021/04/23(金) 15:01:12.26ID:Lj3XxxY0
c++とrustの部分入れ替えてもなんの違和感もない文章だね
241デフォルトの名無しさん
2021/04/23(金) 15:03:21.83ID:ntrIv3TW
君にはそう見えるだろうね
242デフォルトの名無しさん
2021/04/23(金) 15:05:01.62ID:Lj3XxxY0
君にはそう見えないんだろうね
243デフォルトの名無しさん
2021/04/23(金) 15:05:59.83ID:ntrIv3TW
とりあえず、話が噛み合わないのはわかったでしょ
244デフォルトの名無しさん
2021/04/23(金) 15:07:53.22ID:9+zMAQDa
C++ドロップアウターが希望を求めてやって来るスレ
245デフォルトの名無しさん
2021/04/23(金) 15:13:29.93ID:ECpnCXVF
スレでグチグチ言うよりプログラム書いた方がよっぽど理解できるよ
246デフォルトの名無しさん
2021/04/23(金) 15:20:14.54ID:ntrIv3TW
C/C++で穴のあるコードを書いてもしょうがないし、それも難しいんじゃないのかな
逆にC/C++の人らがRustコンパイラをすり抜けるヤバいコードを提示してくれたら、一発で口だけじゃなく出来る人だったと示せるだろうが
247デフォルトの名無しさん
2021/04/23(金) 15:28:23.22ID:mq69qBnk
>>155
> Rustに比べたC++の良さは雑に書けるところだって気付いた
> やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ


これが何気に的を得てるでしょ
コンパイラが安全な方に導いてくれるのはもちろん良いとして、それよりも雑に (あるいは短く親しんだ方法で) 書きたい思惑が優先されるときは C/C++ でやれば良い話で
248デフォルトの名無しさん
2021/04/23(金) 15:38:53.83ID:CjhKTAAP
いや、Rustでラクに書けない時点で勉強が不足してる
そのことに自分で気付けるような人だけRust使えばいい

「当を得る」か「的を射る」ことが出来るような人になってほしい
249デフォルトの名無しさん
2021/04/23(金) 15:56:22.07ID:mq69qBnk
いや、単にコード長が C/C++ の方が短く書ける可能性高いでしょ
どんなイディオムを駆使しても
250デフォルトの名無しさん
2021/04/23(金) 15:59:55.49ID:mq69qBnk
あと近年では「的を得る」は必ずしも誤用じゃないという見方が主流でしょ
251デフォルトの名無しさん
2021/04/23(金) 19:45:46.49ID:ECpnCXVF
Rustの方が雑に書ける局面多いと思うけどなぁ
252デフォルトの名無しさん
2021/04/23(金) 20:51:53.23ID:+YpcBxgU
C++ vs Rustスレでも作ってそっちでやってくれマジで
不毛すぎる
253デフォルトの名無しさん
2021/04/23(金) 21:04:58.31ID:g6tU54WL
>>249
そうだね、記述量の多い言語だと思う
254デフォルトの名無しさん
2021/04/23(金) 22:37:03.61ID:E6ocica9
Rustのコンパイラと戦って勝ったコードは
シンプルでエレガントで簡潔なことが多い
らしい
mjk、
255デフォルトの名無しさん
2021/04/23(金) 23:34:43.49ID:KS/Kkucz
linusはやっぱすげーな
洞察力が違うわ
もちろんその道の神的な存在とはいえ
たいして知らない言語の弱点を一瞬にして暴いて
論破できるのは凄い
256デフォルトの名無しさん
2021/04/24(土) 01:08:35.83ID:h5KFlu4v
>>251
例えばどんなとき?
257デフォルトの名無しさん
2021/04/24(土) 01:20:53.45ID:vtdgUVMq
どんなときもどんなときもRustがRustらしくある~ために~
258デフォルトの名無しさん
2021/04/24(土) 08:06:24.96ID:nPKzA798
C++ vs Rust
http://2chb.net/r/tech/1619219089/

立てましたので以降そういうのはこっちでお願いします
259デフォルトの名無しさん
2021/04/24(土) 08:33:43.03ID:AUtfiExa
>>258
お前ずっと一人で「他所でやれ」連呼してる奴だろ
C++との対立構造はRustにとって無視できないテーマでしょ
正直C++とどう住み分けたら良いのかわかってない奴がほとんどなんだから
260デフォルトの名無しさん
2021/04/24(土) 08:39:09.80ID:/opj2hnT
C++とRustは対立なんてしてない
Rustが怖いC++お爺ちゃんがRustに噛みつているだけでしょ
261デフォルトの名無しさん
2021/04/24(土) 08:48:20.99ID:MAG7Rri7
カーネルの件で完全に拗らせとるな
262デフォルトの名無しさん
2021/04/24(土) 08:54:35.43ID:8O98k7om
> C++との対立構造はRustにとって無視できないテーマでしょ

お前のテーマなんてどうでもいいんだよ
よそでやってくれ
263デフォルトの名無しさん
2021/04/24(土) 08:59:24.96ID:MAG7Rri7
一般的なテーマだってこともわからんのか。馬鹿だな。
264デフォルトの名無しさん
2021/04/24(土) 09:02:59.11ID:CqGuC/ho
リナス「やっぱCが至高、C++もRustもクソ!」
265デフォルトの名無しさん
2021/04/24(土) 09:13:04.98ID:IM8zU0Pj
rustもpanicをコアから外せればいけると思うのだが
もろ言語のコアなんだよな
痛いところ突かれた
266デフォルトの名無しさん
2021/04/24(土) 10:06:12.73ID:yJd/gJxx
言語の問題じゃなくてライブラリの問題では
267デフォルトの名無しさん
2021/04/24(土) 10:11:32.69ID:vtdgUVMq
へーpanicってライブラリなんだ
268デフォルトの名無しさん
2021/04/24(土) 10:29:13.61ID:nPKzA798
>>259
仮にその対立構造を認めるにしても
「雑に書くならC++のほうが楽」なんて、曖昧で基準も何も示されない話に真面目に付き合う奴はいないよ
そういう奴らのための隔離スレとして用意したから好き放題書き散らせばいい
269デフォルトの名無しさん
2021/04/24(土) 10:42:59.04ID:2MdujosH
コード長の話でしょ?
どー考えてもC++の方が短いよ
んなとこで張り合ってもしゃーない
270デフォルトの名無しさん
2021/04/24(土) 11:44:33.91ID:8fCyRscb
3割ぐらいは長いな
https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html

median source code gzip (July 2018)
Ruby 568
Python 672
C++ 1044
C 1115
Rust 1319
271デフォルトの名無しさん
2021/04/24(土) 12:07:10.57ID:RPGHdVOi
>>258
乙。次からテンプレ入りで

>>980
スレ立てよろ

==========
公式
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/

※C++との比較は専用スレへ
C++ vs Rust
http://2chb.net/r/tech/1619219089/

前スレ
Rust part10
http://2chb.net/r/tech/1617367084/
==========
272デフォルトの名無しさん
2021/04/24(土) 12:17:31.75ID:HBFF7y2e
Rustしかまじめに勉強したことないけどいい言語だと思うよ
273デフォルトの名無しさん
2021/04/24(土) 12:21:15.48ID:8fCyRscb
>>272
C/C++で一度ひどい目にあわないとRustの良さは分からんよ
今はまだ分かった気になってるだけ
274デフォルトの名無しさん
2021/04/24(土) 12:39:27.31ID:aNHhbYgZ
Rustはコンパイルでひどい目にあうから問題無い
同じことだ
275デフォルトの名無しさん
2021/04/24(土) 12:56:02.52ID:1Wwd5OE1
Rustのコンパイラに怒られまくる奴は三流プログラマ
276デフォルトの名無しさん
2021/04/24(土) 12:59:06.14ID:hc4SaSPr
Rustの文字列変数って、
str1 = str2;
のように書いた時、copyではなくmoveでしたっけ?
277デフォルトの名無しさん
2021/04/24(土) 13:03:33.00ID:kYV5ExS+
String型ならmove、&str型ならcopy
文字列リテラルなら後者
278デフォルトの名無しさん
2021/04/24(土) 13:09:43.73ID:hc4SaSPr
>>276
調べてみたら、やっぱり、
let s1 = String::from("hello");
let s2 = s1;
とすると、以後、s1は使用できなくなり、使用しようとするとコンパイルエラー
になるんだね。こうなるのは珍しいと言えば珍しい言語。
1. Javaだと、参照を入れるだけで同じ実体を指しているため、s2経由で変更してもs1が
 指しているものも変更される。
2. JS の 文字列は primitive 型なので「コピー動作」となり、s2とs1は別の実体を
 指すことになり、一方を変更しても他方には変更の影響は及ばない。
3. MFCのCStringも意味的にはコピー動作なのでJSと似ているが、高速化のため、
 代入後に一度も書き換えなければ、文字列を入れているメモリブロックは複製
 されないし、コピーもされない。
4. STL(C++) の std::striingもMFCと意味的には似た動作。
5. BASIC言語でも、文字列はコピー動作。
6. Rubyの場合、Javaと同じで同じ実体を参照しているだけなので、一方を書き換えると
 他方も全く同じように書き換わる。コピーするためには、s2 = s1.dup; と書く。

つまり、
a. BASIC、JS、MFC、STL(C++)は似た動作。
b. JavaとRubyも似た動作。
c. Rustは、b の系統に似ているが、s1 が使えなくなるのでちょっと違う。
279デフォルトの名無しさん
2021/04/24(土) 13:13:27.35ID:vtdgUVMq
>>278
無駄なことに時間使ってないでthe bookくらい読みなよ
280デフォルトの名無しさん
2021/04/24(土) 13:20:12.76ID:hc4SaSPr
>>
C# は、「b.」の系統で、JavaとRubyと似た動作だね。
281デフォルトの名無しさん
2021/04/24(土) 13:23:38.54ID:hc4SaSPr
>>279
いろんな言語をかじってしまうと、どれがどれだか分からなくなってしまうんだよ。
文字列の s2 = s1 の動作は:
a. BASIC、JS、MFC、STL(C++)は似た動作。中身をコピーする。
b. Java、Ruby、C# が似た動作。参照を代入するだけ。コピーしたければ明示する。
c. Rustは、b の系統に似ているが、s1 が使えなくなる。
282デフォルトの名無しさん
2021/04/24(土) 13:27:17.48ID:hc4SaSPr
>>281
Javaの場合、Stringは参照しか出来ないが、Rustの場合は、「String型」だけでなく、
「Stringへの参照型」も使えるんだっけ (let s3:&String ??) ?
283デフォルトの名無しさん
2021/04/24(土) 13:36:44.63ID:hc4SaSPr
>>281
C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、
moveで、それ以外の時は copy。
一方、Rustだと、「デフォルト move」なので、基本的には move 動作。
cooy したければ、x = y.clone; と書くのかな。
色々ややこしい。
284デフォルトの名無しさん
2021/04/24(土) 13:39:26.22ID:glcm53ed
>>283
> C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、moveで、それ以外の時は copy。

そんな親切け???
左辺値同士だと明示しないとmoveしてくれないだろ
最適化次第ではしてくれるの?
285デフォルトの名無しさん
2021/04/24(土) 13:43:36.80ID:hc4SaSPr
>>284
えっと、関数の戻り値が構造体型(or クラス型)の場合、右辺値と解釈されるので、
s2 = func(xxx);
見たいにした場合は自動的に move代入されたと思う。
それ以外だと、たいていは、s2 = std::move(s1); のように書かなければ
copy代入になるんじゃないかな。
s2 = func(xxx).s;
のようにした場合も move代入になるはず。
自信は無い。
286デフォルトの名無しさん
2021/04/24(土) 13:47:10.36ID:Kvw1J2lw
>>285
RVOは全然違うぞ
s2の構築にコピーコンストラクタを使わなくなって早くなるというだけ
ムーヴコンストラクタはそもそも出てこない
287デフォルトの名無しさん
2021/04/24(土) 13:47:25.73ID:hc4SaSPr
>>285
自分の記憶だと、一時オブジェクトも右辺値だから、
s2 = std::string("xxx");
ともし書いたとしたら、右辺は右辺値になるのでmove代入になるはず。
s2 = s3 + s4;
みたいにしても、右辺は関数の戻り地と解釈されるので右辺値になるので
move代入になるはず。
288デフォルトの名無しさん
Rustってコードをフォーマットしてくれる機能があるからいいね
これこそモダンな言語だと思う
289デフォルトの名無しさん
2021/04/24(土) 16:01:24.29ID:93XQhLV9
C++と比べりゃ大抵の言語はモダンだろうよ
290デフォルトの名無しさん
2021/04/24(土) 16:18:04.79ID:rGfKetgv
しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
rustすぱぁとをきめるスレ
291デフォルトの名無しさん
2021/04/24(土) 16:38:27.41ID:MAG7Rri7
lintツールも満足に使えない人が喜んでるのかね
292デフォルトの名無しさん
2021/04/24(土) 17:14:02.73ID:yJd/gJxx
非Syncなデータに複数スレッドからアクセスするコードに警告だしてくれるlintある?
293デフォルトの名無しさん
2021/04/24(土) 18:12:05.46ID:6780eEd1
へーそれコードをフォーマットしてくれる機能なんだ
294デフォルトの名無しさん
2021/04/24(土) 22:25:57.79ID:EY30SvcB
>>293
君は、松永の論文を読んだのかい?
295デフォルトの名無しさん
2021/04/25(日) 11:06:21.68ID:M4WxeD2J
質問です

let a = 10;
let b = &a;
let &c = b;

としたときに変数cは数値の10になるのですが
cの前にある&は参照外しの効果があるということなのでしょうか?
296デフォルトの名無しさん
2021/04/25(日) 12:30:46.33ID:yYRREqIx
>>295
pattern matchとdestructuringでそうなる
3行目でbの型が&Tの場合に`&c`にマッチさせたらcの型はTになる
dereferenceの意味で「参照外し」と言ってるなら意味は違うかも
297デフォルトの名無しさん
2021/04/25(日) 13:38:30.57ID:rtrHqrCb
>>296
横から失礼するけど、なるほど。
let &c = b;
は、C++の
int &c = b;
とはかなり違った解釈をされてしまうんだね。後者の場合、&は参照型の
記号で、cの型は、intへの参照型になる。Rustで似たことをしたいなら、
let c:&i32 = &b;
だったっけ?
298デフォルトの名無しさん
2021/04/25(日) 13:41:33.98ID:C031ZmfT
String::fromとString::newの使い分けを教えてください
299デフォルトの名無しさん
2021/04/25(日) 15:13:55.60ID:3Jdhcm8q
>>297
cも参照にしたいなら単純に
let c = b;
でいいはず

let &c = b;

let (x, y) = (1, 2);
と似たような代入式だからbが参照型(かつ被参照型がCopy可能)じゃないと
コンパイルできない

>>298
String::newは引数取らないで空文字列を作る
String::fromは引数に文字とか文字列を取って同じ内容の文字列を作る

リファレンス(↓)読みなさいと言いたいけどRustのリファレンスって
traitとか理解しないとなかなか読みこなせないよね
_https://doc.rust-lang.org/std/string/struct.String.html
300デフォルトの名無しさん
2021/04/25(日) 15:19:02.60ID:yYRREqIx
>>297
>let c:&i32 = &b;

>>295の続きならbがすでに&i32なので
let c = b; か
let c: &i32 = b;

C++でもStroustrupに従ってint& c = b;と書いとけば同じ意味にとれなくもない
301デフォルトの名無しさん
2021/04/25(日) 15:31:18.79ID:2bakgkUg
意図もわからずなんとなく動くからそのメソッドを使い、借用をつければなんとなく動くから
借用し、変更する予定はないけどmutし、ここはエラーだからとpanic!し、補足するなと言われているのに
catch_unwind/recoverして、血の涙で泣きながら渡されたソースをシコシコ直すおまいら・・・
302デフォルトの名無しさん
2021/04/25(日) 16:19:28.48ID:S2tV53BX
>>299 >>300
なるほど、Rustでの b は、C++で言えば「参照」ではなく「ポインタ」の「ようなもの」に
なっているので、
let a = 10;
let b = &a;
の状態だと、
let c = b; か
let c: &i32 = b; か
let c: &i32 = &a;
で c を b と同じような「Rustでの参照型」の変数に出来るわけね?
303デフォルトの名無しさん
2021/04/25(日) 16:55:56.06ID:S2tV53BX
>>302
C++で書き直すと、
int a = 10;
int *b = &a;
の状態だと、
int *c = b; か
int *c = &a;
で c を b と同じような「C++のポインタ型」の変数になる。
ということだね。
304デフォルトの名無しさん
2021/04/25(日) 17:24:01.78ID:Ef2Yns/P
>>301
割とこの未来はもう始まってるんだよな。。rust書き逃げは結構ある。。
305デフォルトの名無しさん
2021/04/25(日) 17:25:49.32ID:vrxr0D/D
悪用できない道具など無い
306デフォルトの名無しさん
2021/04/25(日) 17:30:22.71ID:VydP0zWV
構造体があるじゃん
a.b.cの更新参照もってて
同時に
a.b.dの更新参照とって
両方更新しようしたら
aの更新参照が2箇所にあることになるからできないの?

使い物にならんくない?
307デフォルトの名無しさん
2021/04/25(日) 17:40:32.44ID:M4WxeD2J
>>296
なるほど

match式と同じ様に振る舞うのね
308デフォルトの名無しさん
2021/04/25(日) 17:58:15.33ID:In1fvQYU
>>306
更新参照ってのが&mutのことならできる時とできない時がある

同じ関数内で &mut a.b.c と&mut a.b.d を取ることはできるけど
&mut a.b をとって &mut a.b.d を返す関数を呼び出した後は a.b.d にアクセスできない
これは関数呼び出し時点で a.b が borrow されると判断されるため

このあたりを何とかしようとする 議論は昔からあるけど特に進展なし
https://github.com/rust-lang/rfcs/issues/1215

実用的にはデータ構造の設計を見直すか、RefCell でくるむのが良いと思う
後者は &a.b をとって RefMut を返す関数にするってことね
309デフォルトの名無しさん
2021/04/25(日) 18:57:01.34ID:1PPsEJ27
文字列についてなんかわかりにくいのだけど
C++に例えると
strはchar a[len]
Stringはstruct String { long len; char* str;}
&strはchar* str=&a[2]
このイメージで問題なし?
310デフォルトの名無しさん
2021/04/25(日) 18:59:07.81ID:2bakgkUg
悪用できない道具など無いキリッwwwwwwww
311デフォルトの名無しさん
2021/04/25(日) 19:04:09.95ID:3Jdhcm8q
>>308
細かいけど関数の例はRefMut返すより&RefCellで返す方が安全な気がする
RefCell本体の参照をシェアするだけなら二重で呼んでも大丈夫だし
RefMut作るのは変更が必要な瞬間だけに限定したい
312デフォルトの名無しさん
2021/04/25(日) 19:28:29.93ID:gk8/Gpze
>>309
&strはlenも持ってる
fat pointerでぐぐれ
313デフォルトの名無しさん
2021/04/25(日) 19:34:37.74ID:bkWFj8iO
RefCellについての良いドキュメントや、本などがあれば教えて。
314デフォルトの名無しさん
2021/04/26(月) 10:05:04.39ID:HMswZhLH
f3がコンパイルエラーになる理由がわかる方います?

fn f2<'a, 'b, T>(x: &'a &'b mut T) -> &'a T { x }
fn f3<'a, 'b, T>(x: &'a &'b mut T) -> &'b T { x }


&'b mut TがTに変換可能で
&'a Tから&'b Tが変換不可だから?
315デフォルトの名無しさん
2021/04/26(月) 12:08:58.70ID:DOIDJi7O
>>314
‘aが’bをoutliveするかどうかわからないからじゃない?

fn f3<'a: 'b, 'b, T>(x: &'a &'b mut T) -> &'b T { x }
316デフォルトの名無しさん
2021/04/26(月) 12:53:56.61ID:SHVW/hag
リーナスのRustのパニックがどうのはCを前提としたプロジェクトとRustの流儀がマッチしないって話に見える
逆にRustの流儀に沿ってデザインされたシステムなら問題は起きない可能性もある
てかそういう研究はされていないのかな?
317デフォルトの名無しさん
2021/04/26(月) 12:57:40.62ID:cN+lbm0F
全部rustで書けばいいってか。馬鹿すぎる発想だな。
318デフォルトの名無しさん
2021/04/26(月) 13:02:47.63ID:+85I2LX6
パニックってFFI Boundaryさえ越えなければベアメタルだろうが使っても問題ない認識なんだけど間違ってる?
319デフォルトの名無しさん
2021/04/26(月) 14:09:26.26ID:u7NjNSbC
>>316
そのシステムの基礎を作るのがOSで、Rustの流儀に従うようにする
基礎の部分を作るために Rust の流儀を前提とした言語で書くのは出来ない。
C言語は素朴なマシン語に直るために基礎を作ることが出来る。
320デフォルトの名無しさん
2021/04/26(月) 14:16:19.84ID:ie84aLaE
>>318
別に使って問題ないし、ベアメタル用のパニックハンドラなんかもいろいろあるよ。
321デフォルトの名無しさん
2021/04/26(月) 14:33:09.14ID:DOIDJi7O
>>313
https://doc.rust-lang.org/book/ch15-05-interior-mutability.html
https://ricardomartins.cc/2016/06/08/interior-mutability
https://stackoverflow.com/questions/30831037/
322デフォルトの名無しさん
2021/04/26(月) 15:35:40.97ID:EKg1PdAE
>>317
いきなりLinuxやWindows級のOSを作るのは現実的ではないが
組み込み用のOS程度なら馬鹿げてはないだろう
323デフォルトの名無しさん
2021/04/26(月) 18:30:20.34ID:ONuspOvn
>>315
回答ありがとうございます
確かに'a: 'bを付けるとコンパイル通りますね
xの変換については
&'a (&'b mut T)
→ &'a T
→ &'b T ('a: 'b指定により可能)
という考え方で良いのでしょうか
324デフォルトの名無しさん
2021/04/26(月) 18:39:37.14ID:ONuspOvn
>>323
いや自分で書いてて全然理解できてないです
下記変換は無しですかね。。
&'a (&'b mut T)
→ &'a T
325デフォルトの名無しさん
2021/04/26(月) 20:00:38.89ID:+85I2LX6
>>324
&'a &'b T の lifetime は 'a と 'b の短い方になるから
むりやり書こうとすると min('a, 'b) みたいになる

'a: 'b というのは 'a が 'b より長生きするという意味で
この場合 min('a, 'b) = 'b になるので f3 が valid になる

なお、&'a &'b T については暗黙的に 'b: 'a とみなされてるからコンパイルが通る
('b: 'a の時しか &'a &'b T 型の値が作れないため)
326デフォルトの名無しさん
2021/04/26(月) 20:05:03.48ID:cN+lbm0F
>>322
じゃあ自分で作ってみりゃいいじゃん。
linuxなんかにいちゃもんつけてないでさ。
327デフォルトの名無しさん
2021/04/26(月) 23:42:53.23ID:y3Z2xzaE
>>301
自分で書いてて全然理解できてない奴らが量産されて、キーボードを叩く拳に血が混じりながら
意味不明なコードを誰かが直す。なんというおそろしい未来かw
328デフォルトの名無しさん
2021/04/26(月) 23:56:56.13ID:MHmHz52r
linuxにいちゃもんつけてる人はいないが
rustユーザーがlinuxにいちゃもんつけてると主張する人はいる不思議
329デフォルトの名無しさん
2021/04/27(火) 01:41:47.11ID:Wan/QADt
来年は組み込みRust元年になるやで
330デフォルトの名無しさん
2021/04/27(火) 02:20:03.39ID:+/hUQLiN
あわしろ氏もそう言ってますね。
331デフォルトの名無しさん
2021/04/27(火) 02:20:38.76ID:GJuK6dTy
何で今年じゃないの?
332デフォルトの名無しさん
2021/04/27(火) 02:36:39.16ID:lIgwswD1
panicのせいで実質組み込みでも死んじゃったな
linusやりすぎだぞ
333デフォルトの名無しさん
2021/04/27(火) 02:51:16.77ID:53lThlBD
>>332
Linux カーネルで受け入れられないからと言って組み込みで panic が使えないわけじゃないでしょ。
334デフォルトの名無しさん
2021/04/27(火) 08:06:21.79ID:C32SFGMy
>>325
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=4f6ac5931e40d5e3dcf41712634e9390
元ネタこれなんですが
min('a,'b)的な考え方だと確かにf3について納得できる気がしますが、今度はf1が通るのがわからなくなります

f1を&'a &'b Tの参照がひとつ外せて&'b Tと考え
f0は'b:'aなので&'b Tから&'a Tに変換可能と考えると
f2が通ってf3が通らないことが理解できない
rust難しい。。
335デフォルトの名無しさん
2021/04/27(火) 08:11:26.79ID:Xxuu6Rq/
>>326
だから作るにあたって参考になる資料とか実装例はあるのかって話なんだが
OSを作るみたいな資料はあってもその多くはCとアセンブラを前提としているし
それを参考にしたらC流になってしまうだろ
336デフォルトの名無しさん
2021/04/27(火) 08:43:32.76ID:W9X9APV9
実用的なOSとしてはこの辺かな。
https://github.com/tock/tock

あとは研究論文レベルでは、Rustの所有権システムをOSの権限管理周りに使って堅牢なシステムを作ろう、みたいなのもある。
337デフォルトの名無しさん
2021/04/27(火) 12:44:22.23ID:/+bIFNU8
こんなんCで書いてるのと変わらんだろ。。
https://github.com/tock/tock/blob/master/arch/cortex-m/src/lib.rs
338デフォルトの名無しさん
2021/04/27(火) 13:52:57.49ID:B18ZzSzj
>>337
インラインアセンブリでもRustを使うとコンパイル時に強力なチェックが!
あるわけないよな…Cでいいと思います
339はちみつ餃子 ◆8X2XSCHEME
2021/04/27(火) 14:21:05.00ID:gsHoUi4w
OS 全体の中でも低レイヤ寄りの部分はしょうがないでしょ。
どうせほとんどインラインアセンブリなら C でもいいが Rust で駄目という理由にもならんし。
340デフォルトの名無しさん
2021/04/27(火) 15:07:33.38ID:V9b4VlmB
>>339
Rustは書き辛いし、生成されるコードや意味解釈に闇がある。
341デフォルトの名無しさん
2021/04/27(火) 15:26:51.13ID:+CyfYLC3
言語の設計思想をOS全体に広げて実用的に成功した例ってあるの?
LispOSみたいなのは全部失敗してるじゃん
Cはもともとアセンブラで書かれてたOSを高級言語で書き直せるように
言語自体を後から設計したものだからね
Rustがシステム記述言語として使われたいなら、Linusに意向に100%従って
言語仕様をどんどん書き換えていかないとダメ絶対
342デフォルトの名無しさん
2021/04/27(火) 16:09:23.12ID:sPb/VVK7
ここまでRedoxの話を避けているのはなぜ
343デフォルトの名無しさん
2021/04/27(火) 17:15:40.85ID:MBTyAJrN
Redoxとか使ったことないし……
344デフォルトの名無しさん
2021/04/27(火) 19:00:31.49ID:UNWScvKY
>>341
forth?
345デフォルトの名無しさん
2021/04/27(火) 19:17:36.18ID:SeQzLHjb
forthとかなつかしいなオイ
346デフォルトの名無しさん
2021/04/27(火) 20:00:34.98ID:B18ZzSzj
FORTH作者「FORTHには申し訳ないことをした…」
ホントだよ!
FORTHがきちんとケアされ続けた世界線を見てみたい
347デフォルトの名無しさん
2021/04/28(水) 00:25:46.13ID:zZPOP3tR
forthって今も使われとるのだろか。。
348デフォルトの名無しさん
2021/04/28(水) 01:56:40.25ID:RzWjm9zz
昔はBIOS とか forth で書かれてたけど今はどうかなー
349デフォルトの名無しさん
2021/04/28(水) 03:06:12.66ID:k8H8q1SE
Rustは配列に添え字アクセスする時、必ず境界チェックされるよね?
350デフォルトの名無しさん
2021/04/28(水) 06:10:01.83ID:Er4sy6AA
言語設計とOSが一体ていうのがどのくらいまでを指すかにもよるけど
Smalltalk は元々は言語=OSみたいなシステムだったな
351デフォルトの名無しさん
2021/04/28(水) 10:12:57.76ID:HN4XQcog
>>349
言語仕様的にチェックされるかという意味ならYes
352デフォルトの名無しさん
2021/04/28(水) 10:51:18.82ID:EDIdYwla
>>351
ライブラリの実装ではチェックされるようなコードになっているが
最適化で消えるかも知れないので実行時に必ずしもチェックされるとは限らないという意味?
353デフォルトの名無しさん
2021/04/28(水) 11:29:39.09ID:1OyY1L+6
コンパイル時に境界チェックを外せると確定してない限り最適化しようが境界チェックはやる
354デフォルトの名無しさん
2021/04/28(水) 13:16:17.19ID:BfdKSrwu
例のLKML見直してて思ったけど
unsafeなコードetcが不変条件を破壊した場合に対する安全な対処法って今なんかあるのかな
355デフォルトの名無しさん
2021/04/28(水) 13:47:19.78ID:3EuQZ3Ew
こんなとこじゃね
https://doc.rust-lang.org/edition-guide/rust-2018/error-handling-and-panics/controlling-panics-with-std-panic.html
356デフォルトの名無しさん
2021/04/28(水) 15:27:12.87ID:jQpDsyge
二重投稿になるかも知れませんが、[0; n] で、n要素のi32 型の配列という
意味になるようですが、n が実行時にしか決まらない変数でも大丈夫ですか?
その場合、データ領域はスタック領域から確保するのでしょうか。
357デフォルトの名無しさん
2021/04/28(水) 18:08:50.70ID:HN4XQcog
>>356
まずはリファレンスを
https://doc.rust-lang.org/std/primitive.array.html
358デフォルトの名無しさん
2021/04/28(水) 18:22:21.07ID:t+PzYqgO
>>354
不変条件の種類によるけど最悪 undefined behavior になるから対処は無理じゃないかな
コンパイラの最適化レベル落とすとかで振る舞いを予測可能にすることは出来るのかも
359デフォルトの名無しさん
2021/04/28(水) 19:36:40.90ID:jQpDsyge
>>357
でも、Box::new([0; n])と書いた場合には、nはコンパイル時に決まらない値
でもいいの?
360デフォルトの名無しさん
2021/04/28(水) 20:41:55.42ID:m2UbhZH5
いいに決まってんだろハゲ!
361デフォルトの名無しさん
2021/04/28(水) 20:43:40.06ID:XWuZH88T
Vec::with_capacity使えよ
362デフォルトの名無しさん
2021/04/28(水) 21:18:06.47ID:EDIdYwla
試せば2秒で分かるんだから試しなよ
363デフォルトの名無しさん
2021/04/28(水) 21:32:36.01ID:lX6x7Umv
2秒で試してみろや
364デフォルトの名無しさん
2021/04/28(水) 21:34:25.75ID:lX6x7Umv
うまくいかなかったとしてほかに問題がないか状況を切り分け周辺を調査
誤りのない環境を整備
学習内容を保存し整理
単純な文法ひとつでも最低30分
365デフォルトの名無しさん
2021/04/28(水) 22:27:00.95ID:GVcFAhra
Rustの場合
「2秒で試せる」 || 「試すしたら2秒でわかる」
error: 意図が曖昧です

Cの場合
「2秒で試せる」
「2秒で試してみろやカス」
366デフォルトの名無しさん
2021/04/29(木) 00:40:38.91ID:xah6OenV
Golangが難しかったのでRustにきました
よろしくおねがいします
367デフォルトの名無しさん
2021/04/29(木) 00:53:02.27ID:90w9Shfm
ゴールデンウィークに釣りですか
368デフォルトの名無しさん
2021/04/29(木) 12:40:02.43ID:K/HFYMcp
Animal から、C++ の継承のようなことをした構造体(?)を Dog とした時、
Box<T> a; で T を Animalのようなものにして、a には、実際には Dog
への参照を入れるようなことは出来ますか?
369はちみつ餃子 ◆8X2XSCHEME
2021/04/29(木) 13:12:17.47ID:x0Vd7BP9
>>368
dyn かな?
完全に一致する機能というわけではないけど、
Rust ではトレイトに dyn キーワードを付けると (C++ で言うところの) 抽象クラスのように機能する。
370デフォルトの名無しさん
2021/04/29(木) 13:33:28.09ID:K/HFYMcp
>>369
https://stackoverflow.com/questions/53897315/rust-polymorphic-calls-for-structs-in-a-vector
↑には、Questionの人の書いたのももしかしたら動作するかも知れないけど
Answerの人に従えば、以下のようにするのが正しいのかな?

trait Function {
fn value(&self, arg: &[f64]) -> f64;
}
struct Add {}
struct Multiply {}
impl Function for Add {
fn value(&self, arg: &[f64]) -> f64 { arg[0] + arg[1] }
}
impl Function for Multiply {
fn value(&self, arg: &[f64]) -> f64 { arg[0] * arg[1] }
}

impl Add {
fn new() -> Add { Add {} }
fn new_boxed() -> Box<Add> { Box::new(Add::new()) }
}
impl Multiply {
fn new() -> Multiply { Multiply {} }
fn new_boxed() -> Box<Multiply> { Box::new(Multiply::new()) }
}
fn main() {
let x = vec![1.0, 2.0];
let funcs: Vec<Box<dyn Function>> = vec![Add::new_boxed(), Multiply::new_boxed())];
for f in funcs {
println!("{}", f.value(&x));
}
}
371デフォルトの名無しさん
2021/04/29(木) 17:34:51.47ID:HuHtKfqb
C++でis-a関係の継承使うデータはRustだとenum使う方が単純になるケースもある

struct AnimalData { ... }
struct DogData { ... }
struct CatData { ... }

#[non_exhaustive]
enum Animal {
Dog (AnimalData, DogData),
Cat (AnimalData, CatData),
}

この方法にも色々欠点はあるけど(クレートの外で新しいAnimalを追加できないとか)
trait使う抽象化が大袈裟だと思ったら考えてみて
372デフォルトの名無しさん
2021/04/29(木) 17:51:11.31ID:GXfM8nV1
>>370
継承とは違うけど
そのユースケースはfnかFn使えば十分じゃないの?

let functions: Vec<fn(f64, f64) -> f64> = vec![|x, y| x + y, |x, y| x * y];
for f in &functions {
println!("{}", f(1.0, 2.0));
}
373デフォルトの名無しさん
2021/04/30(金) 01:35:27.25ID:7VhEvZ/Q
>>372
簡単な例として書いただけで、同じ表示結果を得ることが目的ではないので
そういうこととは趣旨が違う。
さまざまな種類の多態なオブジェクトを1つのリストの中に入れるということは
オブジェクト指向に置いて基本的な概念の一つで、Polymorphismの基本なので、
継承的なものを使わずに同じ結果を書けたとしてもそれは違う。
374デフォルトの名無しさん
2021/04/30(金) 15:35:29.77ID:dTeJW22U
ポリモーフィズムを理解してないようなやつでもRustをはじめるようになったんだな
375デフォルトの名無しさん
2021/04/30(金) 17:06:26.25ID:8uDUVNfy
c++と同じで難しくてランタイム速度最強てなところが厨を呼び寄せてる
376デフォルトの名無しさん
2021/04/30(金) 18:24:08.88ID:K785SuXO
C++やってたら配列のインデックスアクセスが安全かどうかや
ディスパッチがスタティックかどうかを普通気にするよね
377デフォルトの名無しさん
2021/04/30(金) 20:47:52.42ID:eR/nI2gV
グーグルやMSが「Rust」言語でOS開発、背景に国家による諜報活動の影=日経 xTECH中田敦

背景に国家による諜報活動の影っていう根拠が1つも示されてないんだけど、こいつの言ってることマジなん?
それとも日経新聞のおなじみの「飛ばし」によるクリック集め?
378デフォルトの名無しさん
2021/04/30(金) 21:05:00.75ID:MgEdsK0p
GAFAMって言いたいだけ
379デフォルトの名無しさん
2021/04/30(金) 21:27:01.84ID:8uDUVNfy
マイクロソフトがwindows書くのにc++使って後悔した話も知らん層が今も同じようなことやろうとしてんだろ。。
バカは歴史に学ばない。
380デフォルトの名無しさん
2021/05/01(土) 00:25:31.33ID:6VZJr73m
これ見てたら、いきなり日本語で「ネコ」って出てきてびっくりした
https://www.programming-idioms.org/cheatsheet/Rust
実は、お前らの中の誰かが書いてんのか?
381デフォルトの名無しさん
2021/05/01(土) 05:47:22.98ID:5xLRGYfU
>>380
https://www.publickey1.jp/blog/21/http35firefoxmozillaquicrustneqo.html
今、プログラムやる若い層じゃアニメとアニメに出てくる簡単な日本語は基礎教養だぞ
github見たらアニメキャラアイコンだらけだ
382デフォルトの名無しさん
2021/05/01(土) 08:00:51.92ID:GEnkdmRT
NANI
383デフォルトの名無しさん
2021/05/01(土) 17:02:13.98ID:1WejqaZh
>>379
>マイクロソフトがwindows書くのにc++使って後悔した話
興味有るので詳しく :
384◆QZaw55cn4c
2021/05/01(土) 17:21:37.61ID:m+tkSw04
>>379
流出したソースを見る限り、MS は C で Windows を書いていたようですよ‥‥
385デフォルトの名無しさん
2021/05/01(土) 17:53:57.44ID:/Wzn7OVr
そういえば初期WindowsのWindow管理のサンプルコード見た記憶がある
ツリーリンクリストが構造体に埋め込む形で自作されてた
386デフォルトの名無しさん
2021/05/01(土) 17:54:25.77ID:/Wzn7OVr
コードの8割方コメントだった
387デフォルトの名無しさん
2021/05/02(日) 09:31:00.53ID:/RYlgP4n
The Windows Research Kernel AKA WRK
https://github.com/zhuhuibeishadiao/ntoskrnl
388デフォルトの名無しさん
2021/05/02(日) 09:42:02.70ID:3kB7D+rP
9割がCか
389デフォルトの名無しさん
2021/05/02(日) 09:51:42.31ID:3kB7D+rP
まあLinuxもCと一部アセンブラだから似たようなものか
390デフォルトの名無しさん
2021/05/02(日) 12:27:53.91ID:Jc9e5ibu
当時の言語状況からして他に選択肢なんかなかったと思うがねぇ。
他の言語選択してたら駆逐されてた可能性すらある。
391デフォルトの名無しさん
2021/05/02(日) 12:37:35.62ID:anCj3LhS
NT kernelが開発されたのが1990年代か
C++も既にあったがまだ浸透してなかったかな
392デフォルトの名無しさん
2021/05/02(日) 13:45:15.23ID:c1rmI49h
チュートリアルやってたらトレートオブジェクトってのの説明が意味不明級だったぜ
https://tourofrust.com/82_ja.html
なんじゃこりゃ
393デフォルトの名無しさん
2021/05/02(日) 14:35:17.11ID:n4dQrb8u
>>392
Javaの知識があれば
 trait object: interfaceとして渡されたオブジェクト
という感じで説明できるけど何か使い慣れた言語はあるかね
394デフォルトの名無しさん
2021/05/02(日) 15:05:16.82ID:c1rmI49h
>>393
もしかしてExistential Container(和訳不明)が独立のオブジェクトとして括り出さている感じですか?
なおC#が一番使い慣れているのですが、この範囲ではJavaと大きく違わなさそうでしょうか・・・・
395デフォルトの名無しさん
2021/05/02(日) 15:36:14.52ID:hSgvj4Ff
>>392
The Bookの該当箇所を読むのを勧める
Java/C#のインターフェースと基本的には同じだけど違う部分もある
https://doc.rust-lang.org/book/ch17-02-trait-objects.html

その少し後に出てくるBoxのコードに出てくる
`animals: Vec<Box<dyn NoiseMaker>>`の
Box<dyn NoiseMaker>がTrait Object

Trait Objectは動的サイズの型なので&NoiseMakerやBox<dyn NoiseMaker>のようにポインタの形になる
そのチュートリアルは前後のページとどう関係があるのかについて説明がほぼないのでわかりにくいかもね
396はちみつ餃子 ◆8X2XSCHEME
2021/05/02(日) 15:50:22.98ID:VAfyzxcR
他の言語の概念と対応付けるよりはそれ自体として理解したほうがいいのは確かだと思う。
(理解できずに行き詰まるくらいなら雑な理解でも一旦前に進んだほうがいいかもしれんけど。)

言語機能ってひとつだけを取り出して使えるものじゃなくて、他の言語機能との連携の中で活きてくるものだから
個別の言語機能を他言語の言語機能と対応付けて理解しても綺麗に繋がらない感じがする。
397デフォルトの名無しさん
2021/05/02(日) 15:58:09.22ID:TmCNx2ML
https://doc.rust-lang.org/reference/types/trait-object.html

こっちじゃ`dyn Trait`のことをtrait objectと呼んでいるようだけど
というか俺はこれだと思ってた
Traitを実装する具体型の値のアドレスと、その型に対するTrait実装のvtableの組
398デフォルトの名無しさん
2021/05/02(日) 16:04:49.31ID:n4dQrb8u
>>394
C#はあまり詳しくないけど、例えばListのAddRange関数の引数の(IEnumerable collection)が近いかな
AddRangeにはIEnumerableを実装してればどんな型でも渡せるはず(ArrayList、HashSet, etc)

これをAddRangeの視点で見ると、渡されたcollectionが実際に何の型かは分からないけど
IEnumerable(interface≒trait)を実装してることは分かってるから
そのGetEnumeratorを呼んでIEnumeratorを受け取ってそこから取り出せる要素を全部追加すれば
目的の動作は果たせることになる

このAddRangeの引数のcollectionがIEnumerableトレイトを実装したtrait objectって感じ
399デフォルトの名無しさん
2021/05/02(日) 17:25:27.83ID:hSgvj4Ff
>>397
正確に言うとリファレンスに書いてる通りdyn Trait型のオブジェクトがTrait Object
&dyn TraitやBox<dyn Trait>はTrait Objectを指してるfat pointer

でも実用上は&dyn TraitやBox<dyn Trait>のfat pointerのこと自体を
Trait Objectというものとして理解したほうがわかりやすいので
The Bookや他の解説書でも区別してないのが多い
400デフォルトの名無しさん
2021/05/03(月) 09:09:00.34ID:AyvebyYK
>>76
Visual Rust#やろ
401デフォルトの名無しさん
2021/05/03(月) 11:04:52.91ID:L2uysNOu
https://marketplace.visualstudio.com/items?itemName=vosen.VisualRust
402デフォルトの名無しさん
2021/05/03(月) 15:28:19.67ID:lWPqbdGD
囲い込んでブラックボックス強要するあたりはMSと相性いいかもな
403デフォルトの名無しさん
2021/05/04(火) 15:41:01.40ID:6lvPuDrb
facebookも財団に参加したのか
appleも時間の問題かな

intelとかのCPUメーカーにも参加して欲しい所だが
404デフォルトの名無しさん
2021/05/04(火) 17:15:37.01ID:lMvsmKDJ
CPUメーカーが参加するとどういうことが嬉しいの?
LLVMなら分かるんだけど
405デフォルトの名無しさん
2021/05/04(火) 20:03:06.80ID:6lvPuDrb
まあ元intelのエンジニアも開発に参加しとるけどね
406デフォルトの名無しさん
2021/05/04(火) 20:33:44.63ID:PCq3WtR4
え?脆弱で有名なあのインテル?
ヤバいじゃないですかぁ
407デフォルトの名無しさん
2021/05/04(火) 21:04:23.81ID:mgj/rIpW
rustが低レイヤーの開発言語としては覇権取りそうね
今から勉強しとくのが良さそう
408デフォルトの名無しさん
2021/05/04(火) 22:09:05.61ID:mvlmOZ0b
低レイヤーの仕事をしたことないってのがよくわかるわ。
409デフォルトの名無しさん
2021/05/05(水) 00:03:56.29ID:UOumGkwv
>>405
エンジニア個々人が参加するのは普通にあると思うんだけど
企業として支援することにどんなうまみがあるのかなと思って

ただ改めて思うとintelもソフトウェアたくさん出しててrust使う旨みはあるから支援する意味はありそうだね
410デフォルトの名無しさん
2021/05/05(水) 01:46:02.42ID:E1emjEBd
SHやArmのRustコンパイラをメーカーが出たらガチ
411はちみつ餃子 ◆8X2XSCHEME
2021/05/05(水) 03:09:13.31ID:o0iQ7lyN
うまみっていうか、それが上手くいくかどうかなんて事前にはわからん。
ほどほどに有用そうなものに支援してたらどれかひとつくらいはいい感じって程度の話だろ。
412デフォルトの名無しさん
2021/05/05(水) 05:31:11.89ID:rumk0idO
協力し合うと同時にあまり勝手しないように牽制するのも目的なので
413デフォルトの名無しさん
2021/05/05(水) 12:35:13.44ID:UNdhfIGe
どうも頭の悪い輩が多いなと思ってたけど、
この言語、ある程度まではスクリプト的に書けるからなんだな。。
なんとなくおかしなこと言ってる奴の感覚がわかってきたわ。
414デフォルトの名無しさん
2021/05/05(水) 13:37:38.31ID:ZpSbA1Y5
>>413
> この言語、ある程度まではスクリプト的に書けるからなんだな。。
短く簡単に書けるようにするのはRustの課題の一つだと思ってるので、どういう観点から「スクリプト的に書ける」とおっしゃるのか伺いたいです
よく比較に上がるC++よりはよっぽど記述量多くなるよね?
415デフォルトの名無しさん
2021/05/05(水) 14:30:15.37ID:UNdhfIGe
そりゃautoなんかを使いまくった最近のスクリプト厨のc++ならそうだろうけれど、
普通に仕事で読むc++コードはそういう感じではないからね。
てかc++と一口に言っても年代で全く別言語だわ。
そういうスクリプト的な書き方をした場合、rustのがc++より快適に感じるのはまあわかるよ。
問題もrustのが少なく感じる。そういう書き方だけしてる場合はね。
416デフォルトの名無しさん
2021/05/05(水) 14:59:14.54ID:ZpSbA1Y5
炎上学習法かってくらい何も理解してない感じでワロス
417デフォルトの名無しさん
2021/05/05(水) 15:13:12.13ID:UOumGkwv
autoと動的型付けの区別が付いていない...?
418デフォルトの名無しさん
2021/05/05(水) 15:19:43.76ID:nBZStdai
型再構築なんてむしろ厳格に型付けされた言語から生まれたんだが
419デフォルトの名無しさん
2021/05/05(水) 15:21:51.15ID:2WIXJ/st
C#でvarキーワードが導入された時も
基本型の変数にvar使うのやめましょうみたいな規約を
意味不明な根拠で良い規約と信じて導入しようとする
おかしな人達がそこら中に居た
後にEffective C#かそこらの書籍で
ローカル変数はvar使えと明確に書かれるようになって
老害ザマァと思ったものだ
420デフォルトの名無しさん
2021/05/05(水) 15:46:10.02ID:sMGymnD4
正義が世俗の愚劣さに屈した
421はちみつ餃子 ◆8X2XSCHEME
2021/05/05(水) 15:47:19.58ID:o0iQ7lyN
ローカル変数の場合は型がすぐ隣に書いてあるような状況だろうからな。
422デフォルトの名無しさん
2021/05/05(水) 16:17:27.41ID:UNdhfIGe
ほらね。
好き勝手な自分流でコード書いてるだけで人のコードを読んでないのが丸わかりなコメントしてても
全く気づかないバカしかいない。
423デフォルトの名無しさん
2021/05/05(水) 16:25:26.72ID:GNJam4rN
>>421
ようするに型情報を二重に書いてるようなものだよな
情報の多重化であり
小さなDRY原則違反
こんな簡単な理屈を理解出来ない奴が不思議
424デフォルトの名無しさん
2021/05/05(水) 16:30:24.49ID:sMGymnD4
書かれておらずメソッドで戻り値を取得するような場合
C#もJavaも型で呼び出し先が変わる仕組みなので
意図せずに処理の流れまで変わってしまう
425デフォルトの名無しさん
2021/05/05(水) 16:44:03.35ID:GNJam4rN
>>424
お前は日本語勉強しろよ
普通に読解不能なんだよ

必要な所には型を書く
当たり前
不要な所に書いてると
「何故書いてるのだろうか?
何か理由を見落としてるだろうか?」
と注意深いプログラマを考えさせるのでエネルギーの無駄
426◆QZaw55cn4c
2021/05/05(水) 16:50:12.99ID:tRoHSHAj
>>416
>炎上学習法

懐かしい言葉ですね‥‥
427デフォルトの名無しさん
2021/05/05(水) 16:59:13.24ID:sMGymnD4
>>425
varにするようになったら全部varにするだろ?
428デフォルトの名無しさん
2021/05/05(水) 17:40:56.63ID:iUhohRzs
>>416
相手してるお前も同罪やぞ
すぐ見分けつくだろ
429デフォルトの名無しさん
2021/05/05(水) 18:09:53.05ID:UOumGkwv
VSCode + rust-analyzer だとletやメソッドチェーンのところに型が表示されるし
今時の開発環境使っていればローカル変数の型がぱっと見で分からなくて苦労することは少ないのでは
430デフォルトの名無しさん
2021/05/05(水) 18:14:24.50ID:GNJam4rN
>>427
何を言っとるんだお前は?
右辺値と同じ型で「困る」時は型を書くに決まってるだろ
下手するとvarの仕様も理解せずに混乱した事を書いてんじゃないだろうな
431デフォルトの名無しさん
2021/05/05(水) 18:51:20.46ID:cJbqSzge
ゲェーQZ居着いてんのかよこのスレ
バカなくせに出しゃばりでウザいからC++スレから出てくんなよ
432デフォルトの名無しさん
2021/05/05(水) 19:01:51.22ID:sMGymnD4
>>430
後から右辺値の型が変わったら気が付かないうちに影響が波及するじゃん
433デフォルトの名無しさん
2021/05/05(水) 19:41:05.57ID:E1emjEBd
var xの型が何であるかはxの初期化のときただ一度きりの右辺の型で決まるんジャネーノ
だとしたら後から右辺値の型が変わることに関して
varの導入で傷口が広がったことにはならない
434デフォルトの名無しさん
2021/05/05(水) 19:44:32.97ID:E1emjEBd
二回目以降の右辺値はxに対する代入でしかありえない
それらはxに対して(暗黙の型変換等を経て)代入可能ならコンパイルが通るし、
代入不可能ならエラーになる。
xの初期化時にvarを使おうが使うまいが(明示的に型を書こうが)変わらない話
435デフォルトの名無しさん
2021/05/05(水) 20:38:12.35ID:UOumGkwv
せめてletの話をしろよ
436デフォルトの名無しさん
2021/05/05(水) 20:48:36.67ID:vgXZGrp9
RustのletはJS由来? それともHaskell?
437デフォルトの名無しさん
2021/05/05(水) 21:09:59.09ID:1EwqoC8k
JavaScriptにもletあるけど語源調べたら普通に英単語のletで短縮形ってわけじゃないらしい
438デフォルトの名無しさん
2021/05/05(水) 21:24:20.68ID:ra+BilqN
BASICの時代からletはあったけどな
439デフォルトの名無しさん
2021/05/05(水) 21:31:43.51ID:ZsCzZm1J
letはlisp系から始まったイメージ。
440デフォルトの名無しさん
2021/05/05(水) 22:26:24.94ID:vWJ975z5
RustのletはML系由来だろ
441デフォルトの名無しさん
2021/05/05(水) 22:44:48.04ID:UOumGkwv
最初のrustcはocamlで書かれてたくらいだしML系の影響は色濃そう
442◆QZaw55cn4c
2021/05/05(水) 22:49:49.94ID:tRoHSHAj
>>431
http://2chb.net/r/tech/1610096040/839
443デフォルトの名無しさん
2021/05/06(木) 01:02:12.67ID:SpjdL+PT
let mut にするか var にするかの決定で、
目立たないけどRustに貢献した人という記事が最近書かれたので貼っとく
https://brson.github.io/2021/05/02/rusts-most-unrecognized-contributor
444デフォルトの名無しさん
2021/05/06(木) 01:05:25.16ID:ut0g6JOd
>>443
3行でまとめて
445デフォルトの名無しさん
2021/05/06(木) 01:35:02.38ID:SpjdL+PT
デイブ・ハーマン(Dave Herman)というECMAScript委員会のMozillaの代表者の人がいました。
リポジトリ上のコミットログでは目立ちませんが、彼の好みがRustチームの好みを作り、チームの組織と維持に重要な役割を果たしていました。
彼はチームの決定をほとんど穏やかに受け入れていましたが、let mut と var のどちらにするかについては var を使うというチームの決定に同意しませんでした。
446デフォルトの名無しさん
2021/05/06(木) 01:36:11.91ID:V2I8vwdu
>>421
でも、
BYTE c = 'a';

let c = 'a';
では間違い易さが違う。後者は、int か BYTE か SBYTE か分からない。
447デフォルトの名無しさん
2021/05/06(木) 01:37:37.69ID:V2I8vwdu
Rustだと、明示するには、
let c:i8 = 'a';
とキータイプが多くなってしまうな。
448デフォルトの名無しさん
2021/05/06(木) 01:40:47.77ID:V2I8vwdu
例えばの話、演算子も優先順位が決まっているので、
if ( (a >= 5 && a <= 10) || (b>=10 && b <=20) ) {・・・}
見たいな条件も、優先順位の括弧を省略できるかも知れないが、勘違いや
記憶違いを防ぐために書いた方がいいと言われている。
int c = 'a';
char c ='a';
auto c = 'a';
ではやはり、autoはバグの原因になりそう。
449デフォルトの名無しさん
2021/05/06(木) 01:47:50.96ID:V2I8vwdu
それと、型を明示した方が後から見たときにプログラマの脳内の想定もわかり易い。
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 型に変えたときに
右辺を訂正する必要がないメリットもある。
450デフォルトの名無しさん
2021/05/06(木) 03:19:29.71ID:EVf7RH7G
>>446
rustの文字リテラルはu8でもi8でもなくてcharな

それはそれとして型やら括弧やらを明示的に書くことは禁じられてないんだから書けばよいのでは
言語の問題というよりはコーディング規約でなんとかすべき領域かと

タイプ数が多くなるとかはデフォルトをどちらに倒すかの問題で世間の嗜好とずれてるなら多少手間がかかるのは諦めるしかない
451デフォルトの名無しさん
2021/05/06(木) 03:21:51.36ID:EVf7RH7G
誤解を招きそうだから補足しておくとrustのcharはユニコードのコードポイントが格納される32bit符号なし整数型な
452デフォルトの名無しさん
2021/05/06(木) 06:46:11.97ID:AMAuzv83
>>443
こういうのいいな
453デフォルトの名無しさん
2021/05/06(木) 10:08:34.61ID:VcsxCBNr
>>445
var使おうとしてたってマジかー
let (mut a, b) = get_foo_tuple();
みたいなやつとかvarじゃ困るから必然だと思ってたのに
454デフォルトの名無しさん
2021/05/06(木) 10:15:22.90ID:lmEaR3VD
>>445の要約の最後たぶん間違ってる
デイブ氏はキーワードを重ねるとmutableな変数の使用を躊躇させる効果が生じて
プログラマのコーディング方式の選択を咎めることになるから反対だったらしい
チームの決定は初めからlet mutで彼は(珍しく)反対したけど最終的には受け入れた
455デフォルトの名無しさん
2021/05/06(木) 11:35:13.23ID:hCHdFqbq
つまり暗黙の型変換は癌
456デフォルトの名無しさん
2021/05/06(木) 11:48:56.26ID:fowE0ZYM
varでいいじゃん
あとはideが勝手に型直してくれるよ
457デフォルトの名無しさん
2021/05/06(木) 11:52:26.38ID:a37uwZNi
いないいない
458デフォルトの名無しさん
2021/05/06(木) 14:35:25.59ID:SpjdL+PT
>>454
すまん、指示代名詞の指してる先を読み違えた
デイブ氏はvar押しだったんだな
459デフォルトの名無しさん
2021/05/06(木) 16:00:35.75ID:acc3YL8w
タイプ数で優劣を決めようとするアホとは次元が違うな
460デフォルトの名無しさん
2021/05/06(木) 16:31:20.99ID:q/dBsf9f
タイプ数は少ない方が問答無用で良い
461デフォルトの名無しさん
2021/05/06(木) 17:13:47.97ID:EVf7RH7G
fn, ret, cont, break の時代に回帰するか
462デフォルトの名無しさん
2021/05/06(木) 17:27:07.40ID:ut0g6JOd
タイプ数は少ない
って基本型が少ない言語が好みなのかと思った
463デフォルトの名無しさん
2021/05/06(木) 19:28:16.24ID:fowE0ZYM
<?rust
println!("hello rust!!");
?>
464デフォルトの名無しさん
2021/05/06(木) 21:17:13.93ID:O03dxxkK
>>448
型を明示したってバグるくせによく言うのぜ
465デフォルトの名無しさん
2021/05/06(木) 22:42:35.79ID:pupGSg3O
タイプ数が少ないようが絶対良いんなら
むかしGAMEとかいうすべてのキーワードが1文字の言語があったからそれでも使え
466デフォルトの名無しさん
2021/05/06(木) 23:22:18.38ID:fowE0ZYM
Rust ~地図にない場所~
467デフォルトの名無しさん
2021/05/07(金) 03:50:05.38ID:vAByX/Kb
>>464
型明示はバグの軽減に繋がる。
>>465
絶対的に良いわけではないが、let a:i32 = 5; と int a = 5; だと後者の方が楽。
468デフォルトの名無しさん
2021/05/07(金) 07:04:16.43ID:aU3MjDw9
>>467
intが32bitだといつから錯覚していた?
469デフォルトの名無しさん
2021/05/07(金) 08:21:08.42ID:Dsa6ajo4
Announcing Rust for Windows v0.9
https://blogs.windows.com/windowsdeveloper/2021/05/06/announcing-rust-for-windows-v0-9/
470デフォルトの名無しさん
2021/05/07(金) 09:19:02.07ID:iG4irUX1
言ってる側から落とし穴に嵌っててワロタ
471デフォルトの名無しさん
2021/05/07(金) 10:35:21.40ID:8IfDDxiK
let a = 5_i32;

型は右側だけで決めるのじゃ
両側で合わせるのは無駄、変更するときも面倒じゃろ

・・なに?
aがi32だと明示してバグを軽減したいじゃと?

それなら行を分けるのじゃ
1行にまとめるとせっかくの明示が埋もれてしまうからの

let a: i32; // この行の存在は大きいぞい
a = 5_i32;
472デフォルトの名無しさん
2021/05/07(金) 12:08:53.04ID:B2UdQUpV
>>468
そこまでいうなら、int32 a = 5; や i32 a = 5; と書けばいい。
なお、Rustではこの書き方が出来ない。
473デフォルトの名無しさん
2021/05/07(金) 12:20:12.52ID:B2UdQUpV
>>468
ちなみに、組み込み以外のほとんどのC/C++コンパイラでは、intは32BIT型。
デスクトップマシン用のC/C++では、32BIT/64BIT のどちらでも、intは、
32BIT型のはずで、少なくとも VC++では必ず int は 32BIT。
474デフォルトの名無しさん
2021/05/07(金) 12:24:00.34ID:w+YL5YRG
>>472
int32_tな
475デフォルトの名無しさん
2021/05/07(金) 12:51:05.27ID:B2UdQUpV
>>474
typedef int int32;
typedef int i32;
とすればよいだけ。
476デフォルトの名無しさん
2021/05/07(金) 12:57:04.52ID:w+YL5YRG
>>475
それintが32bitじゃない環境でアホみたいにミスリーディングになるけど?
いい加減スレチだし「int32_t 標準ライブラリ」でググって理解したらこの話終わりにして?
477デフォルトの名無しさん
2021/05/07(金) 13:31:50.44ID:B2UdQUpV
>>476
そんな基本的なことは当たり前で、そのような環境では、
typedef __int32 int32;
typedef __int32 i32;
とする。
478デフォルトの名無しさん
2021/05/07(金) 13:40:18.27ID:8gopO5Ce
どういうバグを作る可能性があるかという点が共有されてないから議論空回りしている感
479デフォルトの名無しさん
2021/05/07(金) 13:42:32.36ID:B2UdQUpV
というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
だと思ったんだ。もし、int32_t が使える環境で賢く使いたい人は、
typedef int32_t int32;
typedef int32_t i32;
typedef int32_t Int32;
などとすればいいという話。
前提とする知識が低すぎる人がいるから困る。
480デフォルトの名無しさん
2021/05/07(金) 13:45:35.27ID:eN8Lkrsa
何を議論してるのか全然分からん
481デフォルトの名無しさん
2021/05/07(金) 14:02:25.02ID:SIz+0gIF
1レス目で即NG
相手してるやつも同じカテゴリなので即NG
482はちみつ餃子 ◆8X2XSCHEME
2021/05/07(金) 14:03:01.68ID:xLSEaA6V
議論なんかするつもりがないんだろう。
483デフォルトの名無しさん
2021/05/07(金) 14:40:46.39ID:r6L15P9a
>>479
>というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
>だと思ったんだ。

誰がどこでそんな話をしたのか
ログ辿っても全然分からない件

ついでに言えば
グローバル名前空間の中に標準ライブラリがブチ込む型名として
_tサフィックス以外あり得んので
何も馬鹿なことなんか無い
つーか本当に誰もそんな話してないな

これ突っ込んだら
どんなガイジレスを返すのか興味津々

>>480
論点不明のドッジボールだからな
今はどこでも似たようなやり取りが見られて
5ch終わってる感がハンパない
俺は句点付きが特に頭おかしいと思うけど
レスバ相手はEQがヤバイ感じだが
句点付きはIQがヤバイ
484デフォルトの名無しさん
2021/05/07(金) 14:57:30.94ID:DUMB7Vls
メジャーなGUIアプリで使われているrust製GUIライブラリってなにがありますか?
GUI使いたいんですが長いものにまかれたいので
485はちみつ餃子 ◆8X2XSCHEME
2021/05/07(金) 15:02:55.52ID:xLSEaA6V
>>484
プラットフォーム (OS) によって違うんじゃない?
その中ではある程度に淘汰されてると思うけど、
あらゆる環境で万能な決定版は無いと思う。
486デフォルトの名無しさん
2021/05/07(金) 15:53:14.60ID:B2UdQUpV
>>483
>句点付きはIQがヤバイ
実際にIQ150越えてるので、ノーマル一般人が理解できないだけではないか。
487デフォルトの名無しさん
2021/05/07(金) 16:08:00.06ID:r6L15P9a
>>486
証拠うpしてくれ
ID付き画像とかなら最高だ
IQ150超えでもこんなガイジレスするのか
マジで興味あるわ
488デフォルトの名無しさん
2021/05/07(金) 17:04:02.49ID:+x2jPaur
メモリ不足でカーネルパニックが起きることの問題がわからない
普通のパソコン用途に使われてたらユーザーランドのソフトがOOM Killerに殺されようがOS丸ごとクラッシュしようが作業内容が失われるのは変わらん
サーバー用途でも一部のプロセスが殺されて中途半端の状態で動き続けるよりいっその事OSまるごとクラッシュしたほうがいいと思う
489デフォルトの名無しさん
2021/05/07(金) 17:16:13.01ID:8gopO5Ce
>>488
rustでLinuxのドライバー書く話?
メモリ不足時にどうハンドリングされるべきかは使い方によって違うので一律パニックするのは良くない
例えば例に挙げてるOOM Killerだってカーネルがパニックしたら実行されないわけで
490デフォルトの名無しさん
2021/05/07(金) 17:22:12.18ID:r6L15P9a
>>488
何かあった時止まればいいシステムばかりじゃないだろ
ペースメーカーとか原子炉とか
細かいことは知らんけど
昔、組み込み屋のおっさんが最初から1Mぐらい確保して
何かあったらそれを解放してどうにかするみたいなこと言ってた
知らんけど
491はちみつ餃子 ◆8X2XSCHEME
2021/05/07(金) 18:25:34.58ID:xLSEaA6V
>>488
システムは単独で動いているわけではない。
カーネルがパニックすることがあって良いという前提で設計して、パニックしうる前提で運用できるならそれでも構わんのだが、
Linux のカーネルでパニックを許すなら今 Linux を基礎にしているあらゆるシステムの運用体制を見直さざるを得ない。

カーネルパニックが絶対に駄目というわけじゃないんだ。
(もちろん発生しないに越したことは無いが。)
Linux では起こさないという前提に皆が従っているので変えられないという話なんだよ。
492デフォルトの名無しさん
2021/05/07(金) 18:53:57.67ID:XbWp/RIC
割り込みが飛んでくる環境で例外なんか扱おうとしたら普通に死ぬだろ
493デフォルトの名無しさん
2021/05/07(金) 19:12:04.63ID:RYgnWswQ
>>488
失われる作業内容の範囲があるだろ。
クライアントOSのWindowsですらBSODで切れる奴が多かったんだから、サーバーOSでそんな考えが許されるはずがない。
494デフォルトの名無しさん
2021/05/07(金) 19:35:24.51ID:FlZ9PpDj
差し当たりRustの言語を広く浅く学習したいのですが、「実践Rustプログラミング入門」の言語部分(100ページ程度)が分量が少なめで気になっています
この本で大きく抜けている文法や機能ってありますか?
495デフォルトの名無しさん
2021/05/07(金) 20:06:32.24ID:xz5IWUMT
>>494
The Bookと比べれば一目瞭然
496デフォルトの名無しさん
2021/05/07(金) 20:11:06.98ID:8H8V34/d
>>493
サーバーOSのほうがクライアントOSよりクラッシュには寛容だぞ
サーバー側の開発したことないのかな?
497デフォルトの名無しさん
2021/05/07(金) 20:22:58.56ID:fmyiQrUP
>>496
最近は仮想化&分散で寛容になっているの?
498デフォルトの名無しさん
2021/05/07(金) 21:23:40.41ID:EDSX1EuR
>>494
最近の本だからasyncまであるし、そんなに大きな抜けはないかな
広く浅くならまぁいいんじゃないかと
もし細かい部分が気になったらthe bookで補完すればいい
499デフォルトの名無しさん
2021/05/07(金) 21:36:25.19ID:7aFGtcIv
>>497
むしろchaos engineeringで積極的に落とす
500デフォルトの名無しさん
2021/05/07(金) 21:52:45.82ID:Z7WMK8Ny
ペースメーカーとか原子炉とか、ノンストップシステムでは常に複数動いている

Kubernetes などでは、ネットワーク分断に備えて、
正常な状態を多数決で決めるから、3, 5, 7 みたいな奇数を動かす

2対2とか偶数だと、どちらが正常か判断できないから
501500
2021/05/07(金) 22:00:09.91ID:Z7WMK8Ny
Netflix などは常に、システムを攻撃して落としたりして、テストしてる。
サイボウズのkintone は、毎日システムを破棄して、作り直しているとか

Kubernetes を使っているのかな?
502デフォルトの名無しさん
2021/05/08(土) 00:03:29.89ID:4agfhhA1
非常時の処理はカーネルの中心部が決めることで
枝葉のモジュールに決定権はないという話なんじゃないの?
503デフォルトの名無しさん
2021/05/08(土) 00:07:56.54ID:OofXJFgO
レイヤーがめちゃくちゃな話しとるな。
OSみたいなハードウェアに直触るものとkubernetesみたいな分散管理のソフトじゃ
全然話が違う。
実際kubernetesはGC付きのgolangが実装だろ。
504500
2021/05/08(土) 01:02:28.51ID:P6P/nG6A
ノンストップシステムでは常に複数動く。
デュアルシステムとか

東証・富士通製のarrowhead は、3重だったかな?
それでも、ラックか何かの接続部分が落ちて、システムダウンした

ネットワークが集中している部分の故障が、最も怖い
505デフォルトの名無しさん
2021/05/08(土) 08:40:46.17ID:e+sagIsH
>>492
なんでじゃ
割り込みルーチンに入るときの退避と出るときの復旧をきちんとやっていれば
割り込みルーチン以外の処理は割り込みルーチンが呼び出されることに対して透過的に動作できる
一部のハードなリアルタイムOSみたいに(多重割り込み前提で)割り込みルーチンから
通常コンテキストに直接「ジャンプ」してタスクをたたき起こすみたいなケースでもなければ割り込みの存在は
通常コンテキストで何をやろうと一切影響は無い
(もちろん割り込み禁止、みたいな直接割り込みに影響する命令を実行したら話は別だがそれは普通特権命令でOS以外は実行できな
 い

カーネルでの例外が問題なのは、
例外機構を持たないCならスタックポインタの調整で済むところを
デストラクタがある高級な言語だと例外が通過する際に自動変数として構築されていたオブジェクトを
例外が通過する関数全てについて解放してやらねばならない
(それでいて一方、自動変数として構築される可能性はあっても
 例外発生時に構築されていないオブジェクトに対しては何もしてはいけない
という点
これは例外を飛ばすだけでその経路全部が同一のコンパイラで書かれなければならないことを意味する
途中に手で書いたアセンブラのルーチンなどあろうものならスタックをぶち壊してハードウェアの例外でいきなり
落ちるということになってそんなことがOS内で起きたら計算機上の資源の安全が担保されない。
OSとしては失格である
506デフォルトの名無しさん
2021/05/08(土) 08:53:39.11ID:e+sagIsH
、と思ったが
よく考えたら「手で書いたアセンブラのルーチン」があったらコンパイラはそれを知らない関数としてスタックポインタの調整以外のことを
しなかったら良いのかorz、
ここは「例外通過時にC++や異なるベンダーのRustコンパイラみたいな例外を捕捉する関数をコンパイルいたRustコンパイラが預かり知らない
巻き戻し処理が必要なルーチン」があったら、ということに訂正
507デフォルトの名無しさん
2021/05/08(土) 09:44:38.32ID:9PfSgf27
なんだこいつ
IQ64だな
508デフォルトの名無しさん
2021/05/08(土) 10:15:07.28ID:e+sagIsH
IQは関係無いやろうがギギギギギ、
509デフォルトの名無しさん
2021/05/08(土) 11:11:59.29ID:52U5aUmg
JAVAみたいな言語があるからnewしたまま放ったらかしでメモリ管理もろくに出来ない馬鹿で溢れかえって居るんだよな
510デフォルトの名無しさん
2021/05/08(土) 11:36:05.31ID:jLEsHVNz
ついさっき知ったけど、new() はT だけじゃなく Result<T> を返していいんだな
511デフォルトの名無しさん
2021/05/08(土) 12:01:48.48ID:9PfSgf27
newはシンタックスじゃなくてただの慣例だからね
慣例ではResultを返すのはお作法に反するはず
512デフォルトの名無しさん
2021/05/08(土) 12:03:38.57ID:OofXJFgO
別にjavaがない頃からそういうバカはいたけどね
513デフォルトの名無しさん
2021/05/08(土) 12:09:19.46ID:rOsHiSsL
メモリ管理もろくに出来ない馬鹿
・Linuxカーネルにカーネルスタックメモリ内の情報を読み取られる脆弱性
・「WebKit」にゼロデイ脆弱性 ~「macOS Big Sur 11.3.1」や「iOS/iPadOS 14.5.1」などが公開
・BIND9に脆弱性、アップデートや回避策を
514デフォルトの名無しさん
2021/05/08(土) 12:14:25.93ID:lGQPC/Vw
>>509
因果関係が逆で、
頭が悪くてその程度ももともと出来ない人は昔はCやC++でプログラムできなかった
がVBやJavaやC#やJSやPythonやRubyではできた。
515デフォルトの名無しさん
2021/05/08(土) 13:11:23.63ID:RJ95z4qm
>>511
newとかfromでResult返すのたまに見かけるけど
どうするのがおすすめなの?
try_newとかtry_fromにするのが良いのかな
516デフォルトの名無しさん
2021/05/08(土) 13:37:14.67ID:jLEsHVNz
>>511
ただの慣例じゃなくて、clippy先生の指導対象らしい
https://rust-lang.github.io/rust-clippy/master/#new_ret_no_self

Checks for new not returning a type that contains Self.
517デフォルトの名無しさん
2021/05/08(土) 14:30:50.83ID:yMDwHl+j
手動でスタックポインタの調整ってバグや脆弱性の温床じゃね?
518デフォルトの名無しさん
2021/05/08(土) 17:15:39.08ID:3vrEhaHR
医療機器や原発の制御システムとかが不意にリセットしないとか思っている時点で
組み込みとか高信頼性システムとかを全く知らないんだなって思う
ああいうのは最悪暴走したらリセットして最低限の機能は提供出来るように
作るのが基本だからね。そうしないと想定外の事態がおきた時に詰む
519デフォルトの名無しさん
2021/05/08(土) 17:18:46.34ID:jLEsHVNz
そんなコーナーケースの為に俺たちの使い心地が悪くなるようなら耐えられないな
520はちみつ餃子 ◆8X2XSCHEME
2021/05/08(土) 17:23:48.71ID://zoyCL6
暴走した場合にでもうてる手札を用意しておくってのと、
暴走しないように細部まで検証しておくってのは両立する話
521デフォルトの名無しさん
2021/05/08(土) 17:27:07.74ID:QshNNe4V
いうほどコーナーケースってほどでもないだろ。
割と考慮されて当然のケースだわ。
まあlinux単体がその品質を担保できてるとも思わんけど。
522デフォルトの名無しさん
2021/05/08(土) 17:33:15.67ID:3vrEhaHR
原子力関係だけでなく航空機や宇宙機もだが制御不能になるのが一番ヤバイんで
バグ出しは常識的な範囲で行って、あとはリカバリ系に注力した方がシステムの信頼性は向上する
歴史的に見ても事故るシステムの多くはこの辺をガバっている事が多いし
523デフォルトの名無しさん
2021/05/08(土) 17:57:46.72ID:e+sagIsH
別に
ハイテク旅客機が落ちるのは自動制御と手動操縦のモード切替仕様を
パイロットが熟知しておらず緊急時に操縦桿を奪い合う格闘になったから
であってソフトは仕様通りだった
『ハイテク飛行機はなぜ落ちるか』(ブルーバックス)のインシデントの数々を見たらワカル

原子炉の制御系はそもそも暴走させないように金かけて形式検証する

人間が本気になったらどんだけバグをなくすために金と手間を掛けられるかというと
スペースシャトルのSSMEの制御装置のソフトがどんだけ徹底したデバッグが行われたかを見たらワカル
524デフォルトの名無しさん
2021/05/08(土) 18:17:53.56ID:57+jEKOs
>>523
人間が使う物であればUIも当然システムに含まれる
判りにくいUIは良いシステムとは言えない

ソユーズや神舟はADA使ったりしていないけど
スペースシャトルより死人は少ない。米式が唯一の正解とは限らない
むしろスペースシャトルはシステム設計に失敗した例だろ
525デフォルトの名無しさん
2021/05/08(土) 18:22:37.13ID:e+sagIsH
UIの仕様バグと>>518が言っている暴走する系のバグは話がちげう
526デフォルトの名無しさん
2021/05/08(土) 18:36:29.80ID:57+jEKOs
組み込み機器でも多くのケースで不測の事態に備えてウォッチドックタイマを使うよね
トリガを何にするかやリセット時に何をするかは設計手腕が問われるところだけど
527デフォルトの名無しさん
2021/05/08(土) 19:38:20.73ID:RJ95z4qm
>>516
fn new() -> Result<Self, T> は警告出ないよ
528デフォルトの名無しさん
2021/05/08(土) 19:42:36.17ID:PnHrKWCk
newでResult返すのはいいけどfromは駄目だろ
というかFrom trait実装しろ
529デフォルトの名無しさん
2021/05/08(土) 19:46:07.47ID:RJ95z4qm
>>528
そもそも impl From<T> Result<Foo, E> はcoherenceの関係でエラーになるよね
Intoはできるけど

FromStr なり TryFrom を使うべきというのはそう
530デフォルトの名無しさん
2021/05/08(土) 20:23:33.19ID:jLEsHVNz
>>527
そりゃ Result はそこに書いてある a type that contains Self だからね
531デフォルトの名無しさん
2021/05/08(土) 21:10:37.46ID:vIQ3GRO1
cのコードをrustに変換してくれるライブラリってありませんか?
532デフォルトの名無しさん
2021/05/08(土) 22:23:50.74ID:8Oybw0Jl
>>531
c2rust
533デフォルトの名無しさん
2021/05/09(日) 12:16:13.70ID:RMo+m9mc
その場合誰がRustコンパイラと戦うんじゃ……
534デフォルトの名無しさん
2021/05/09(日) 13:34:11.17ID:DdW1Qm5g
1.52来てたのね
535デフォルトの名無しさん
2021/05/09(日) 23:13:05.64ID:T2j6cCMq
例外処理って何が有難いの?Cでプログラム書いてて例外がなくて困ったことないんだけど
もしかしてただのシンタックスシュガー?
536デフォルトの名無しさん
2021/05/09(日) 23:31:00.87ID:LUIc58fP
戻り値の設定に近いものを一箇所にまとめられる。
537デフォルトの名無しさん
2021/05/10(月) 00:03:43.87ID:sciUqTyU
どのレベルの話?
初心者の質問だとすると、関数の失敗を成功と区別するため。
戻り値で区別するんでなくて仕組みで。
538デフォルトの名無しさん
2021/05/10(月) 00:10:05.03ID:EWDopcLj
例外の存在意義が分からない
戻り値で判別する方が可読性も高いし何も不足を感じない
539デフォルトの名無しさん
2021/05/10(月) 00:21:25.87ID:giJ6lOgz
>>538
スレチ
540デフォルトの名無しさん
2021/05/10(月) 07:17:37.24ID:aMiH/GVN
fileへのwriteとか毎行エラーチェック入るのしんどい
541デフォルトの名無しさん
2021/05/10(月) 10:07:49.01ID:ro06Xyvc
>>538
開いた後、必ず閉じる処理が必要な場合があるが、それをxとすると、
関数のある場所でエラーを発見した時、呼び出し元へ返りたくても、
xを閉じてからでなくてはならない。xが複数有ったり、今後もxの
量が増えていくような場合、エラーが起きる場所全てでxを正確に全て
閉じてからreturnするのは難しい。なので、昔から、xを閉じる処理は
関数の最後の方に書いておいて、その直前にラベル lab_ex:; のような
ものを書いておいて、エラーが起きたときにはlab_exにgoto文
で飛ばすようなことが行われることが多かった。
でも、goto文は好まれ無い事があって、
try, catch 構文を使うと、goto文を使わなくてもそれが出来るようになる
ことが例外処理の一つのメリット。
542デフォルトの名無しさん
2021/05/10(月) 10:12:49.59ID:ro06Xyvc
>>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分がそんなに分かりにくいわけではない。
543デフォルトの名無しさん
2021/05/10(月) 10:13:54.77ID:Pi5UB1M6
そういやCで bail: ラベルが多用されてたなーっていうのを
anyhowクレートの bail! マクロで思い出した
544デフォルトの名無しさん
2021/05/10(月) 10:16:15.81ID:pIvV80n0
>>541,542
クソスレチ
545デフォルトの名無しさん
2021/05/10(月) 10:23:18.20ID:ro06Xyvc
>>542
例外処理を使った場合、goto文が要らない:
BOOL func()
{
 BOOL rc = TRUE;
 open_some(x);
 try {
  func2() ; // 例外発生の可能性有り
  func3() ; // 例外発生の可能性有り
 }
 catch(...) {
  printf( "エラーだよ\n" );
  rc = FALSE;
 }
 close_some(x)
 return rc;
}
546デフォルトの名無しさん
2021/05/10(月) 10:23:53.36ID:ro06Xyvc
>>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;
のようなもの。
547デフォルトの名無しさん
2021/05/10(月) 10:40:58.67ID:u82ImyiI
後藤さんいい加減にしてくださいよ…
548デフォルトの名無しさん
2021/05/10(月) 13:07:54.71ID:H09R880S
Linuxや*BSDなどのカーネルはgoto文が誰に遠慮することもなく堂々と使われてますよ
そして可読性は何も損なわれていない
言語屋さんだけじゃないの?構造化でgotoがどうたらとかそれに代わる言語機構が
必要だとか言ってるのは
そして新たに言語を学ぶ人が無批判にそれらを盲信することが代々続いてる
ようにしか見えない
549デフォルトの名無しさん
2021/05/10(月) 13:38:27.10ID:FH4+0Y9S
多くの言語はハードウェアとしてCPU例外や、I/Oに対する入出力の(ハードウェア的)例外と、多くは
復帰可能なエラー分岐処理にて、プログラミング言語で「包括的に捕捉して後処理」するためにある。
例外の反対者はResult/Option/(Either)のようなものがあるのに、なぜ言語に例外を取り入れて、信頼性を
低下させるような隠された制御フローを導入するのかと主張します。

しかし例えばファイルへの出力で"fwrite"ではOSの上層では実際に書き込まれず、"fclose"で書き込まれたり
あるいは"fflush"でメモリー上とディスクが同期されるなどは、同期的な、従来の戻り値を確認しただけでは
正確な判断ができない。(これは言語のライブリーがBufferを使用しているとは別の話、たとえばディスク
容量が足りなくなった場合など、意図するプログラムは失敗する可能性があります。)
またResultなどが使用できるの場合は、ハードウェアやIOに依存しない場合にできるだけです。他にも、不正な
ゼロ除算などの発生は、カーネルでも、組み込みでも、CPU例外に対しては特定の例外の種類によりあらかじめ
決められたアドレスに強制的にジャンプします。C言語自身はCPUの挙動を定義していませんので、この制御の
フローの移動はCプログラミング言語の機能ではなくCPUメーカーの実装です。
つまり、標準のC自体だけでは、統一的にエラー処理を記述するということ自体が出来ていませんし、実行制御
フロー記述し完全掌握してコントロールするという事自体があやふやです。
(ゼロ除算でジャンプしなくてHALTするようなCPUがあるかもしれませんが知りません)
550デフォルトの名無しさん
2021/05/10(月) 13:43:11.18ID:FH4+0Y9S
多くの例外がある言語(RustやGoのpanicも含む)では、上記の例ではファイル出力とは無関係な処理でも
即座に後処理へ移動します。ですが、ここに1つの問題があり、多くは捕捉した後にほぼ「自動的に」
ディストラクタに記述された処理をスレッド毎に存在するスタックを遡って巻き戻しを行います。
(例外の反対者はこれを隠された制御フローというが、決して信頼性が低下するわけではないです、
カーネルの例外ハンドラを例に挙げれば、ただ挙動が合わない事と、多くの例外がある言語でのCPU例外の
捕捉はリカバリが不可能に近く、挙動が保証できない事でディストラクタ実行させて意味があるのかという
矛盾もあります)

それ以外の例外処理は概念的にはスレッドローカルグローバル変数とifとgoto/returnの組み合わせにしか
ならないので信頼性が低下したりはしません。また、C言語や昔の言語でgotoが嫌われていたのは、ラベルが
存在しないgotoだったりループ中のgotoだったり、プログラムのモジュール化を壊す制御であったためなども
あります。try-catch-finallyとは無関係ですが、同様に可読性が悪いように見えてしまうため、冤罪にされます。
そもそもアセンブラであればJMP命令にしかならない事をいつまでもグチグチ言うのは悪い癖です
551デフォルトの名無しさん
2021/05/10(月) 15:15:38.71ID:ro06Xyvc
>>550
後半、BASIC言語を振り返ってみると、ラベルの無いgoto文はむしろラベルありより綺麗に書けていた。
gosubはラベル方式の方が良かったが。
Cのgotoはラベルが必須なのでラベルが浮いてしまって嫌われているという説がある位。
552デフォルトの名無しさん
2021/05/10(月) 15:18:53.59ID:ro06Xyvc
例外処理の問題点は、
try {
 f1();
 ・・・
 f2();
 ・・・
 f3();
 ・・・
 f4();
 ・・・
}
とtryブロックの中に沢山の関数呼び出しが有った場合、コード上ではどこでも例外が
起きる可能性を捨てきれないため逆に危険な可能性を排除しにくいことがある。
例えば、fputc()やfwrite()などで例外が起きることが分かっているならそれはそれで
良いが、全く関係のないf1, f2, f3, f4でもどれかは例外が起きる可能性があるなら
非常にプログラミングしにくい。
553デフォルトの名無しさん
2021/05/10(月) 15:21:55.24ID:ro06Xyvc
>>551
例えば、BASICでは以下の様な感じになるので、ラベルが無い事でむしろすっきり
見易かった。gosub文はまた別でいまの関数の様な感じで名前が付いている方が
分かり易かった。これは経験を積まないと理解しにくいかも知れない。
100 if xxx = yyy goto 120
110 ・・・
120 ・・・
554デフォルトの名無しさん
2021/05/10(月) 18:35:05.49ID:mFjZyrFq
>>548
構造化の無い暗黒時代に戻りたくないわ。

制御構文と構造化設計を破壊するぐらいならgoto使わないほうがマシ。破壊しない程度だったら許容できるかね。
555デフォルトの名無しさん
2021/05/10(月) 18:45:12.97ID:QB4+qLHE
Rustは学習コスト高いって言われてるけど
Scala辺りと比べても難しいですか?
556デフォルトの名無しさん
2021/05/10(月) 19:40:11.34ID:RQLzh3xR
>>555
別に特別難しいわけではないと思う
いろんな言語からパクってきてる要素が多くて、これまで一つの言語しか使ったことない人は学ぶべきことが多いってだけで
ScalaとC++くらい経験あれば余裕だろう
557デフォルトの名無しさん
2021/05/10(月) 21:15:30.50ID:aMiH/GVN
コンパイラの文脈解析がこんだけ普及したのだから
safe gotoが存在するべきだ
558デフォルトの名無しさん
2021/05/10(月) 21:21:46.54ID:10iSv1/R
言語自体よりも、情報技術の基礎が要求されるんじゃないの
559デフォルトの名無しさん
2021/05/10(月) 21:38:27.66ID:+CGjcQmG
>>555
やってみるのが一番早いよ
https://ideone.com/
こーいうところを使うとPC側にコンパイラとか用意せずに試せる
560デフォルトの名無しさん
2021/05/10(月) 23:10:53.18ID:Ai0jiWQm
>>559
>>1にもあるけどhttps://play.rust-lang.orgのほうがいろいろ充実してる
てかideoneは1.33.0とかなのか、結構古いね
561デフォルトの名無しさん
2021/05/10(月) 23:22:34.42ID:rt96Jr4B
playground、いつのまにか以前書いたコードが残るようになっててなんかうざったいんだけど、
初期のhello worldの状態に戻すのってどうやるの?(クッキー削除とかはなしで
562デフォルトの名無しさん
2021/05/10(月) 23:29:40.57ID:4UvCiOpM
んな面倒なことするくらいならrustupインストールすりゃええやん
563デフォルトの名無しさん
2021/05/11(火) 00:01:56.34ID:bFiGc/cl
>>549
ファイルへの書き込みは返り値promise等でもらっておいて他の作業を進めて
どうしても書き込み完了していないと作業を先へ進めてはいけないところでようやくawait等することで
例外処理も遅延(手続き的な後ろ化と多段時の上位化)ができますよね

あとOSカーネル内の話は
例外と割り込みをごっちゃにしているように見えます
いずれにせよカーネル内ではtry例外使わずとも多段にエラー返り値を返していけばいいだけでしょう
エラー割り込み時もメモリ不足もシステムコールならエラー値返すわけですし
564はちみつ餃子 ◆8X2XSCHEME
2021/05/11(火) 02:56:09.45ID:sf6ddr3r
>>555
Rust はそれほど難しいというわけでもないと思う。
C に ML 風の型システムを付けたって程度。

普通のプログラマにとって目新しいと言えるのはライフタイムの概念くらい。
でもそのひとつが馴染み無さ過ぎるというか、
他の言語では意識せずに済まさせようとしてきたところを
あえて露骨に管理しようとしてるところがしんどいとは感じるかもね。
565デフォルトの名無しさん
2021/05/11(火) 03:24:21.67ID:BXZYJdJz
>>564
Rustのライフタイムは、鶏と卵の関係の様な部分で言語の動作が分からない。
どっちがどっちに影響を与えているのかの部分が。
自動判定の仕組みも一部だけ説明されていて一般法則が書いておらず、その場しのぎ的な言語仕様なのかもしれない。
566デフォルトの名無しさん
2021/05/11(火) 04:47:35.34ID:+XHXxVLE
non lexical lifetimeでググれば詳細な仕様出てくるだろ
567デフォルトの名無しさん
2021/05/11(火) 05:08:47.84ID:BXZYJdJz
>>566
出てこないと思うが。
568デフォルトの名無しさん
2021/05/11(火) 08:24:36.99ID:hJ8vQWaq
>>561

通りすがりですが、保存せずにただ試すだけなら

1.シークレットモードで新規タブ
2.playgroundのサイトを開く(ブックマーク登録からとか)
3.コード入力かコピペ作業

でどうでしょうか?
569デフォルトの名無しさん
2021/05/11(火) 10:55:34.68ID:nxCZKmfr
>>567
nll rfcで検索したら出てくるよ
570デフォルトの名無しさん
2021/05/11(火) 12:37:05.27ID:BXZYJdJz
>>569
そこには例が書かれてるだけで、数学みたいな意味でのちゃんとした厳密仕様は書いてないと思うんだよ。
Rustのライフタイムは数学規則のように機械的にパターンで処理できるような一般化された規則にはなってないという意味において。
571デフォルトの名無しさん
2021/05/11(火) 12:42:48.49ID:yczyG8TY
厳密な仕様があるのは理想だけど、規格化された言語ですら数学的に厳密な仕様なんて存在しないしな
最終的にはCoqのソースコードで示される、とかはあるかもしれないが
572デフォルトの名無しさん
2021/05/11(火) 12:47:18.80ID:BXZYJdJz
>>571
CやC++は数学的なパターンで処理できるようになってる。
そこにヒューリスティックなものは入ってない。
573デフォルトの名無しさん
2021/05/11(火) 12:55:41.33ID:r1e7nJBc
the abstract syntax tree でのライフタイムの解析から
the control-flow graph でのライフタイムの解析にしたって言ってるから
かなりマシン語に近いとこで判定してるってことだわな。
ここにいる奴に聞くだけ無駄w
574デフォルトの名無しさん
2021/05/11(火) 18:36:37.89ID:efUOVNNI
>>571
純lispくらいかね。
あるいはBrainfuckとか。
575デフォルトの名無しさん
2021/05/11(火) 18:56:14.78ID:jWdOrz94
issue #25860って未だに解決されてないんだよね?
行きあたりばったりでライフタイム仕様決めてきた結果w
576デフォルトの名無しさん
2021/05/11(火) 19:03:56.93ID:wl2jzTgT
Rustと原子力発電は人類には早すぎたんや…
577デフォルトの名無しさん
2021/05/11(火) 19:52:59.74ID:8+nUEbRM
Rust嫌う人ってなんでみんな #25860 の話するのって言われてんぞ
578デフォルトの名無しさん
2021/05/11(火) 22:03:42.47ID:1AWmjfgF
>>576
太陽光発電は、ある意味原子力発電と言えるのではないだろうか。
579デフォルトの名無しさん
2021/05/12(水) 08:51:30.06ID:1N4enQMj
Rust 2021 Editionは10月リリース予定

https://blog.rust-lang.org/2021/05/11/edition-2021.html
580デフォルトの名無しさん
2021/05/12(水) 10:38:41.98ID:qFi3vx5o
1.56.0からか
581デフォルトの名無しさん
2021/05/12(水) 10:40:17.60ID:1N4enQMj
2021 Edition ざっと読んでみたけど、次の2点以外は些末な変更だな

for e in [1, 2, 3] {}
がエラーにならなくなる
(IntoIterator for arrays)

クロージャーが構造体をフィールド単位でキャプチャーするようになる
(Disjoint capture in closures)
582デフォルトの名無しさん
2021/05/12(水) 21:45:20.66ID:rLfxFtSp
2018で勉強してますが仕様変わりますか?
583デフォルトの名無しさん
2021/05/12(水) 22:08:40.92ID:fyx4mRuh
https://www.google.com/amp/s/japan.zdnet.com/amp/article/35170513/

「Windows用Rust」のバージョン0.9がリリース

何か誤解を与えそうな記事タイトルだ
584デフォルトの名無しさん
2021/05/13(木) 00:09:46.25ID:JmJXN960
リポジトリ名的にwindows-rsのが適語か?
585デフォルトの名無しさん
2021/05/13(木) 00:34:31.53ID:hcgdol/O
>>582
マイナーチェンジだし2018も継続して使えるし特に問題ないよ
586デフォルトの名無しさん
2021/05/13(木) 00:46:54.51ID:oO6nJ4P1
何年か前なら喜んでたんだけどな、どうしよ何の興味も沸かない
Docker触り始めた辺りからWindows用は趣味でも書かなくなってしまった…
587デフォルトの名無しさん
2021/05/13(木) 07:59:13.00ID:OSZsGS3x
>>583 多分windowsクレートの説明文のRust for Windowsの直訳だとは思うけどこれは誤解するわ
588デフォルトの名無しさん
2021/05/13(木) 11:06:57.34ID:mHvpW2NY
Rust for Windowsという名前がミスリーディング
(A) Rust (crate) for Windows (development)をRust for Windowsに略したら誰でも誤解する
狙ってるのかもしれないが

Windows API bindgen for Rustあたりが適当
589デフォルトの名無しさん
2021/05/13(木) 12:50:12.69ID:OSZsGS3x
このクレート普通にソフト作るのに使ったら移植性無くなるからライブラリ用かな?
590デフォルトの名無しさん
2021/05/13(木) 14:22:28.44ID:p1C3K64x
防衛省が中国のハッカーとやり合える人材を募集中 年収最高2000万円
http://2chb.net/r/poverty/1620874048/
591デフォルトの名無しさん
2021/05/13(木) 14:34:12.09ID:EmFUnxGS
クラッカーにうってつけじゃないか
592デフォルトの名無しさん
2021/05/13(木) 15:04:14.32ID:67slJFqF
年収最低はいくらからですかね
593デフォルトの名無しさん
2021/05/13(木) 15:10:36.53ID:ENK4De8l
最高が2000万円ってだけね。。
こういうので平気で300万円とかいい出すのが今の日本やで。
594デフォルトの名無しさん
2021/05/13(木) 18:36:08.63ID:hcgdol/O
>>589
Windows専用のアプリを作る用途もあるのでは
一般的ではないかもだけど
595デフォルトの名無しさん
2021/05/13(木) 18:39:15.84ID:oBGJ4/nI
Rust for Windowsを欲しがったのはMicrosoft自身だろう
既にVSのインストーラー内部などでRust使用中なので
596デフォルトの名無しさん
2021/05/13(木) 19:27:59.33ID:4YggBXb4
rust for windowsで作る本作ってくださいお願いします
597デフォルトの名無しさん
2021/05/13(木) 19:29:13.29ID:vZYCxDQa
>>594 Windows専用のアプリが作りたいならC#でも使えばいいと思うけど...
598デフォルトの名無しさん
2021/05/13(木) 19:30:20.99ID:vZYCxDQa
>>594 Windows専用のアプリが作りたいならC#でも使えばいいと思うけど...
599デフォルトの名無しさん
2021/05/13(木) 19:30:58.76ID:vZYCxDQa
おっとミスって2回書き込んでしまった
失礼
600デフォルトの名無しさん
2021/05/13(木) 20:59:04.54ID:vzWwtH6K
>>590
そういう技術者にも射撃練習とかやらせるのだろうか?
601デフォルトの名無しさん
2021/05/13(木) 21:40:48.09ID:NNemQTGQ
>>595
もうメジャーな用途で使われてんのか
602デフォルトの名無しさん
2021/05/13(木) 21:45:54.80ID:vzWwtH6K
windowsもそろそろNTカーネルを捨てる時期が来るだろうし色々模索はしてるんだろうな
603デフォルトの名無しさん
2021/05/13(木) 21:57:03.92ID:WjgS+eLl
もし仮にNTカーネル捨てたとしてLinuxカーネル一択だと思うがな
604デフォルトの名無しさん
2021/05/13(木) 22:08:50.47ID:vzWwtH6K
Linuxへの接近はここ数年目立ってるし無くはない話だな

独占市場と過去の互換性を捨てきれるか
仮想環境で過去の互換性を維持することも考えられる
605デフォルトの名無しさん
2021/05/14(金) 08:10:59.62ID:FBkeGRqg
>>604
NTカーネル捨てるのはビジネスとして有り得ない。
せいぜいwsl路線を強化してlinuxカーネルを取り込んでいく方向だろ。
606デフォルトの名無しさん
2021/05/14(金) 08:37:43.19ID:BI4FO4HO
カーネルを捨てて切り替えるとか出来るわけないだろ
607デフォルトの名無しさん
2021/05/14(金) 08:52:11.24ID:9b8NT0Ot
3才児が「ぼくはうちゅうひこうしになるんだ!」って言ってるようなもんだから生暖かく見守ってやれ
608デフォルトの名無しさん
2021/05/14(金) 10:22:28.00ID:6SQ932Rj
OSカーネルに対するコンプレックスがすごい人がいるんだろ。
この前のlinuxドライバに関する議論でもそういうの感じるわ
609デフォルトの名無しさん
2021/05/14(金) 11:10:24.23ID:bMDjGf5Y
rustがgolangより人気が出ると思っていいですか?
610デフォルトの名無しさん
2021/05/14(金) 11:14:13.19ID:5xLewDJ4
>>609
Goはガーベッジコレクションがあるから?
611デフォルトの名無しさん
2021/05/14(金) 11:29:33.68ID:6SQ932Rj
GCとランタイム速度に困ったことのある奴だけ気にすればええ。
612デフォルトの名無しさん
2021/05/14(金) 13:23:04.93ID:TMXA3cLH
goとrustどっちが良いか迷うならgoやっといた方が潰しが効くと思う
自分はrust好きだからrust使うが
613デフォルトの名無しさん
2021/05/14(金) 14:57:53.07ID:85G96vHL
両方やっとけ
614デフォルトの名無しさん
2021/05/14(金) 15:16:48.50ID:678S/iU6
なんでマイナー言語のはずのgoがよく言及されるようになったのかと思っていたら、AWSで使える言語の一つになっていた。
Azureでも使えるようだ。
615デフォルトの名無しさん
2021/05/14(金) 15:45:19.02ID:WB7bczPS
goがマイナー。。。..
616デフォルトの名無しさん
2021/05/14(金) 15:46:03.80ID:BI4FO4HO
サーバープログラムみたいな閉じた環境で、出来るここまでと決まってて
要らないこと考えたくないなら制約された言語選んだほうが良いかもな
617デフォルトの名無しさん
2021/05/14(金) 15:47:17.23ID:6SQ932Rj
goでほとんど問題ないんだが、それだとrustの出番なくなっちゃうからね。
618デフォルトの名無しさん
2021/05/14(金) 16:15:48.73ID:1T0ViQH9
Go言語がマイナーならこの言語はどんだけマイナーになっちゃうのよ
619デフォルトの名無しさん
2021/05/14(金) 16:25:56.91ID:Z0ePaP6y
goとrustの違いが分からないような知識量ならgoやった方が不幸にならないかと
620デフォルトの名無しさん
2021/05/14(金) 16:48:29.92ID:678S/iU6
参照型はローカル変数にだけ入れて一時的な目的だけに使うことに徹してスクリプト言語の様な書き方だけに専念すればRustはスクリプト言語であるかのように使えて、習得は難しくないかも。
参照型を構造体の中に入れようとしたとたんCやC++では考える必要の無かった難しい問題が生じる。
621デフォルトの名無しさん
2021/05/14(金) 17:00:31.58ID:dvkZe6EK
メジャー言語
c java vba
622デフォルトの名無しさん
2021/05/14(金) 17:40:01.47ID:N2rlLeCr
Rustを勉強したら低レベルが理解出来る!!!わけねえだろ
https://www.akiradeveloper.com/post/learn-rust-and-low-level/
623デフォルトの名無しさん
2021/05/14(金) 19:36:04.21ID:5xLewDJ4
例えばWeb系ならばRustがベスト
WasmでGC抱える言語をわざわざ選ぶメリットないからね
624デフォルトの名無しさん
2021/05/14(金) 19:44:16.91ID:6SQ932Rj
こういう詐欺師が普通におるからrustは信用できんわ
625デフォルトの名無しさん
2021/05/14(金) 19:51:45.41ID:WB7bczPS
rustに対するコンプレックスすごい人いるね
626デフォルトの名無しさん
2021/05/14(金) 20:26:02.54ID:0Bqgd+6M
詐欺師はどこにでもいるからな
とはいえ、webならwasmは正しくないとは思うがwasmならrustは結構正しいと思う
627デフォルトの名無しさん
2021/05/14(金) 20:32:01.67ID:6SQ932Rj
wasm,rustでまともに開発してたら絶対そんなこと思わんわ。。どいつもこいつも馬鹿すぎる
628デフォルトの名無しさん
2021/05/14(金) 20:40:33.59ID:WB7bczPS
それで、どんなまともなものを作っているんですか
629デフォルトの名無しさん
2021/05/14(金) 20:46:14.11ID:5xLewDJ4
>>624
とこが詐欺?
あなたはWebブラウザ上のWasmでRustではなくGoを用いているのですか?
630デフォルトの名無しさん
2021/05/14(金) 21:18:15.11ID:TMXA3cLH
>>627
それはあなたがまともにrust使えてないだけなんじゃないですかねぇ
631デフォルトの名無しさん
2021/05/14(金) 21:22:56.09ID:yxEaYkUD
話が具体的で説得力がある
632デフォルトの名無しさん
2021/05/14(金) 21:38:43.40ID:2w1FBHD8
>>572
形式的に書けているのは構文規則だけで
意味規則は自然言語で書かれているやんけ
633デフォルトの名無しさん
2021/05/14(金) 22:59:38.34ID:R2Ezzb7N
「Rustはスクリプト的に書ける」とかいう謎の言葉言う奴沢山いるけどなんぞ?
同一人物か?
634デフォルトの名無しさん
2021/05/14(金) 23:07:50.74ID:TMXA3cLH
我々が知らないところでevcxrが流行ってるのかもしれない
635デフォルトの名無しさん
2021/05/14(金) 23:23:46.43ID:72ZodHJE
google謹製のREPLね
エベクサ?
636デフォルトの名無しさん
2021/05/15(土) 02:09:59.05ID:BphhllcO
>>633
Rubyと同じようなメソッドチェーンを使ったコードを見かけたから。
637デフォルトの名無しさん
2021/05/15(土) 03:17:16.69ID:vuo6fbRn
ドットでメソッド呼び出しする言語は大概そういうライブラリ設計あるでしょ
638デフォルトの名無しさん
2021/05/15(土) 11:05:39.24ID:DTE+piln
>>637
C++やJavaでは見たこと無い。
JSでも余り見かけない。
639デフォルトの名無しさん
2021/05/15(土) 11:12:58.76ID:Y+SvMVkX
そもそもメソッドチェーンって「スクリプト的」なのか?
640デフォルトの名無しさん
2021/05/15(土) 11:24:14.14ID:C+CtGbiq
前々からヤベェやつだとは思ってたが
レベルの低さが想像をはるかに超えてた
641デフォルトの名無しさん
2021/05/15(土) 11:27:04.30ID:MS0dCBGJ
c言語みたいにcsvパーサーも自前で用意するような環境だとそらスクリプト的だろうね。
642デフォルトの名無しさん
2021/05/15(土) 12:00:43.05ID:A3vQNOxR
unityとかUEがrustに対応しないかなあ
643デフォルトの名無しさん
2021/05/15(土) 12:00:58.11ID:ZgJC7yuF
cargoみたいなパッケージマネージャがあるのもスクリプト的な要素のうちなのか?
644デフォルトの名無しさん
2021/05/15(土) 12:10:16.46ID:MS0dCBGJ
cargoは低レイヤー慣れてる人からすれば邪魔でしかないけどね。
645デフォルトの名無しさん
2021/05/15(土) 12:20:50.35ID:DTE+piln
SourceforgeなどでRustが好きといっている人の大部分はレベルが低いだろう。
そもそもこの世の中、大多数から受けるものにレベルが高いものがあったためしがない。
好きな言語ランキング上位のJS、Pythonも初心者向け言語であることは誰もが認めることだし。
646デフォルトの名無しさん
2021/05/15(土) 12:40:11.21ID:UqP25wMI
sourceforge???
stackoverflowの調査かなんかと勘違いしたの?
647デフォルトの名無しさん
2021/05/15(土) 12:41:57.93ID:ZgJC7yuF
>>644
どういうこと?ベアメタル向けでもcargo使うのが主流だと思っていた
648デフォルトの名無しさん
2021/05/15(土) 12:47:56.99ID:ZgJC7yuF
>>645
使用者のレベルの高低と言語のレベル(?)の高低は一致するという主張かな?

言語のレベルが高いというのが最先端のテクノロジーを取り込むという意味ならrustの目指すところではないと思う
他の言語で実証されたコンセプトを取り込むと宣言してる(た?)はず
高レベルな言語が必要な人はこんな普及言語じゃなくてもっと尖った言語を使うか自分で作るべきなのでは
649デフォルトの名無しさん
2021/05/15(土) 12:49:38.36ID:DTE+piln
>>646
ああ、そっちだった。
Stackoverflowも来てる人の頭の良さは一般大衆と同じくらいだから同じ。
650デフォルトの名無しさん
2021/05/15(土) 12:53:14.42ID:DTE+piln
>>648
そういうことじゃなくて、
・Rustをほとんど使っても見てないのに勝手に「好き」と言っていることが分かってる。
・Stackoverflowのような沢山の人が集まる場所の調査では、必ずJSやPythonのような初心者向けの言語が人気となるわけだから、そこの人々が好きだと思う言語は、JSやPythonのような感覚で使えると勝手に思い込んである蓋然性が高い。
 ただし、現実はRustは実際には使ってないのに勝手に言っている。
ということ。
651デフォルトの名無しさん
2021/05/15(土) 13:20:44.67ID:YOv93GRR
stackoverflowの調査の話なら、調査内容を勘違いしている
あれは「今Rustを使っている人が、今後もRustを使い続けたいかどうか」のアンケート結果をmost lovedと言ってるだけ
だからJSやPythonユーザの意見は入ってない
そもそもloveって言葉に語弊があるし、日本語にしたときに「人気の」とかなって余計訳がわからなくなってる
652デフォルトの名無しさん
2021/05/15(土) 13:25:20.53ID:YOv93GRR
たぶん「最も嫌嫌使っている人が少ない言語」みたいなのが正確な気がするな
653デフォルトの名無しさん
2021/05/15(土) 14:15:44.60ID:MW7lNw7H
「今使ってる人が次も使いたいと思うか?」ってJetBrainsの調査でも毎回入れてくる項目だな
海外のアンケートではよく見るやつ
654デフォルトの名無しさん
2021/05/15(土) 14:17:03.39ID:DTE+piln
>>651
もし前半の通りなら、今Rustを使ってる人なんて極一握りの物好きだけだから
「love」なのは当たり前で調査結果が意味が無い。
655デフォルトの名無しさん
2021/05/15(土) 14:19:45.06ID:eXXN4CKf
一生でどれか一つのプログラミング言語しか覚えられないとして
Rust選ぶ人いますか?

選択したとして別にその言語がいきなりマスターできるわけでなく
ただその言語しか覚えられないというだけですが
656デフォルトの名無しさん
2021/05/15(土) 14:23:36.58ID:DTE+piln
今rustを使ってる人って、自ら進んで使おうとした人に限られるから
嫌いな人がほとんどいないのは当たり前だから、調査結果にバイアスが
掛かりすぎていることになるな。
657はちみつ餃子 ◆8X2XSCHEME
2021/05/15(土) 15:05:35.65ID:pVi51x8H
そういえば C++ でメンバ関数の評価順序に関して設計者も気づいてなかった考慮漏れが見つかった
(よくあるパターンが実際には未定義だった) って話があったな。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
C++17 で修正されているはずだけど。

宣言的な表現や関数的な表現をプログラミング言語に取り込む試みは数多いが
現実は順序からは逃れられぬのだ……。
658デフォルトの名無しさん
2021/05/15(土) 15:16:25.44ID:HcoKJY+/
Rustがスクリプト的に書けるかどうかはおいといて、
個人用のツール書く言語をPythonからRustに乗り換えたっつー話は一応あるな
https://hayatoito.github.io/2017/faq/#programming-language
659デフォルトの名無しさん
2021/05/15(土) 15:20:52.26ID:DTE+piln
>>658
Googleがnode.jsで書いていたものをRustにしたと聞いたぞ。
660デフォルトの名無しさん
2021/05/15(土) 15:23:50.02ID:TrqVEcq2
全部書き直すのは逆に効率悪そう
速度的にキツイ場合のみでいいんじゃないか?
661デフォルトの名無しさん
2021/05/15(土) 15:32:34.68ID:H/3gPTTR
どちらかといえば速度よりも変更頻度が動機になると思う
静的チェックツールも増えてはいるけどコンパイル型はいじる時の安心感が違う
662はちみつ餃子 ◆8X2XSCHEME
2021/05/15(土) 15:37:59.52ID:pVi51x8H
>>660
言語を跨いで呼出すときはその境界で色々な処理が挟まったりもするので、
まだらに入り乱れるような形になるとそれはそれで実行性能の足を引っ張ることもある。
状況次第なので一概には言えないけど、言語を変更すると決めたなら
そこそこ大きい単位で乗り換えるのが妥当な場合は結構あると思うよ。
663デフォルトの名無しさん
2021/05/15(土) 17:32:17.46ID:jwQMP5Oj
>>661
それはあるね
個人用のツールだとそんなに真面目にテストも書かないから
動的型だと忘れた頃に改修したくなって詰む
664デフォルトの名無しさん
2021/05/15(土) 18:53:39.15ID:IpomZGOJ
>>642
MSがdotnet対応のRust#出したらUnityワンチャンあるんやない?
665デフォルトの名無しさん
2021/05/15(土) 19:10:58.08ID:Y+SvMVkX
そこはRust/CLIで。
666デフォルトの名無しさん
2021/05/15(土) 21:52:45.98ID:TrqVEcq2
GCのあるrustに存在意義などない
667デフォルトの名無しさん
2021/05/15(土) 22:13:28.16ID:Y+SvMVkX
GCとデストラクタが共存するC++/CLIはなかなか興味深い言語だった。
668デフォルトの名無しさん
2021/05/16(日) 11:00:47.47ID:9EXRd3vl
RustのGCって初期はまた復活されるかもーみたいなノリじゃなかったっけ?
669デフォルトの名無しさん
2021/05/16(日) 11:12:01.38ID:SPtqbmz9
RC関連についてはやるとか?
670デフォルトの名無しさん
2021/05/16(日) 12:07:45.66ID:MDYO1Tug
@ pointerとか ~ pointerとかあった頃の話?
671デフォルトの名無しさん
2021/05/16(日) 15:06:48.66ID:JH7fFMWR
>>665
確かにそっちか
>>666
GCがあるRustって言うよりはunsafeを外部リンクで呼び出してるようなもんだろ
672デフォルトの名無しさん
2021/05/17(月) 10:53:44.01ID:ZSkTvtbm
rustが覇権を取るにはPHPみたいにドキュメントの翻訳をたくさん作ること
そしてサンプルコードを盛り込むこと
673デフォルトの名無しさん
2021/05/18(火) 19:40:20.00ID:A1yOEMnk
>2021 Editionは2021年10月にリリースされる。今回のエディションは「Rustの使用感を大きく改善する」ものになるという

あんまり前にこんな発表しないでほしい
やる気なくなる
674デフォルトの名無しさん
2021/05/18(火) 19:44:35.79ID:Gj41gD2H
>>673
ちゃんと発表資料見れば分かるけど、大して使用感変わらんよ
クロージャー使いまくりの人が一番恩恵を受けるかな
675デフォルトの名無しさん
2021/05/18(火) 20:19:55.73ID:Z0RWJbQc
所有権は移動するときのほうにマークが出るべきなんじゃあ
676デフォルトの名無しさん
2021/05/19(水) 07:47:56.56ID:X700JkCT
まぁコストかかるのはコピーだし
677デフォルトの名無しさん
2021/05/19(水) 08:05:05.13ID:o3bqBTNO
Rustの真似をしようとする言語がないのがふしぎだ
678デフォルトの名無しさん
2021/05/19(水) 12:30:25.52ID:HmkTJiD6
https://en.m.wikipedia.org/wiki/Rust_(programming_language)
wikipedia見ただけだけど Crystal, Elm
679デフォルトの名無しさん
2021/05/19(水) 12:30:46.25ID:HmkTJiD6
など影響を与えた言語は列挙されてた
680デフォルトの名無しさん
2021/05/19(水) 12:42:47.10ID:9T1L9lvJ
>>678
Elmのどこが?と思ってソースを読んだら
関数型言語なら大体持ってるEither型の名前を Result, Ok, Error にしたところがRust由来とな

うーむ持ってきたのは名前だけなのにInfluencedか
681デフォルトの名無しさん
2021/05/19(水) 12:59:40.27ID:u9Tr9lyP
Gleam
https://gleam.run/book/tour/index.html

OwnershipやLifetimeの考え方を採用した言語はまだ聞いたことがない
682デフォルトの名無しさん
2021/05/19(水) 13:11:21.07ID:bDX8SBSl
所有権の考え方を採用している言語としてはC++などがあります
683デフォルトの名無しさん
2021/05/19(水) 14:00:04.90ID:NOe9g/vN
まあインスタンスの共有については何らかの言語サポートが入ってもおかしくないかもね
684デフォルトの名無しさん
2021/05/20(木) 01:09:22.49ID:WwVMFHF+
DにもOwnership入ったとか小耳に挟んだだけなら
685デフォルトの名無しさん
2021/05/20(木) 17:03:02.09ID:VKAk8Olu
https://forest.watch.impress.co.jp/docs/news/1325564.html
凄いね
686デフォルトの名無しさん
2021/05/20(木) 17:06:31.55ID:13olK3Lw
>>685
UIがReactというのが残念
687デフォルトの名無しさん
2021/05/20(木) 18:20:18.69ID:PiC1UW/o
逆に何ならいいんだよ
688デフォルトの名無しさん
2021/05/20(木) 18:33:43.55ID:UXe9/StR
GUIフレームワークをRustで作るうまみあまりなさそう
689デフォルトの名無しさん
2021/05/20(木) 19:39:25.12ID:QrP75Wi1
Rustで作ってあるなら絶対大丈夫だな!
690デフォルトの名無しさん
2021/05/20(木) 22:57:01.82ID:HbCDuKW4
設計がクソだとダメ
ダメなヤツはなにやってもダメ
691デフォルトの名無しさん
2021/05/21(金) 11:45:49.77ID:r1IBz1vL
>>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では例外を使わなくても困らないのです
692デフォルトの名無しさん
2021/05/21(金) 13:37:02.96ID:J6y23PLS
すまん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);
}
693デフォルトの名無しさん
2021/05/21(金) 13:40:53.52ID:J6y23PLS
ちなみにコンパイルエラーも貼っておく

Compiling playground v0.0.1 (/playground)
error[E0382]: borrow of moved value: `_a`
--> src/main.rs:22:9
|
18 | let _a = Droppable { id: &0 };
| -- move occurs because `_a` has type `Droppable`, which does not implement the `Copy` trait
19 | if *_a.id == 1 {
20 | drop(_a);
| -- value moved here
21 | }
22 | 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.
694デフォルトの名無しさん
2021/05/21(金) 13:44:28.52ID:J6y23PLS
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.

見やすくした
695デフォルトの名無しさん
2021/05/21(金) 14:49:33.29ID:vx/ErwhM
意味のないコードだよ
696デフォルトの名無しさん
2021/05/21(金) 14:53:16.15ID:PNtD97K1
コンパイラは別に値まで見ないからな
clippyが意味のない分岐だよと指摘してくれるのかどうかは知らんが
697デフォルトの名無しさん
2021/05/21(金) 14:55:24.20ID:HgMuIEwp
>>692
基本的に条件分岐はpredがコンパイル時に評価できる場合でも true/false 両方あり得るものとして扱われるよ
その後の最適化フェーズであり得ないルートは除去されるだろうけど最適化の結果でコンパイルエラー差異が出ないようにする考え方なんだと思われる
無限ループ専用の構文であるloopが導入された背景もたぶんこのあたりにある
698デフォルトの名無しさん
2021/05/21(金) 15:52:58.09ID:J6y23PLS
>>697
trueのときもdrop、falseのときもdropされるとみなされるということは、
if文によってheap領域で確保しているメモリを解放するかしないか場合分けできないってことじゃん
それって不便では?
699デフォルトの名無しさん
2021/05/21(金) 16:14:23.61ID:qRzkKAr2
>>698 これ元のコード見てみ
これifの条件がtrueだろうがfalseだろうがsub(&_a);は実行されるやん
ifの条件がfalseのときには問題なく実行できるけど、もしifの条件がtrueになって_aがdropされてしまった後にsub(&_a);が実行されてしまうと開放された値を使うことになる
だからRustコンパイラはエラーを吐くんだよ
700デフォルトの名無しさん
2021/05/21(金) 16:15:51.92ID:91Y2FzX3
いや、普通に場合分けはできるが…

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

if *_a.id == 1 {
drop(_a);
} else {
sub(&_a);
}
702デフォルトの名無しさん
2021/05/21(金) 17:42:19.92ID:J6y23PLS
>>700
言ってる意味がさっぱりわからん
>>692のプログラムにあるとおり
現実問題、将来的に決して実行されるわけがないif文というものは存在するし
if文があるというのは実行される可能性のあるの十分条件でもなければ必要条件でもなわけでもないんやが。
ワイが言いたいのは仮にrustの型システムを無視して>>692のコードをそのままコンパイルしたとしても
if文は実行されないわけだから安全なはずなものまでを省いているというところが不思議だってことや
つまりuse-after-freeバグが現実には起きないコードまでもif文の他の条件でUAFバグが起きるがために
ひとまとめにUAFが起きるとみなすrustコンパイラの姿勢がif文である条件のときだけfreeするコードを書くのを認めないようにみえるという
ワイの感想に繋がってるわけでして
703デフォルトの名無しさん
2021/05/21(金) 17:53:39.45ID:IHGXJo1X
use of moved valueやborrow of moved valueを
use-after-freeとして理解してるのがそもそも間違ってる

The Bookを読んでLifetimeとOwnershipを復習してくれ
704デフォルトの名無しさん
2021/05/21(金) 18:00:55.07ID:J6y23PLS
>>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);
}
705デフォルトの名無しさん
2021/05/21(金) 18:01:46.42ID:J6y23PLS
これはrustでは弾かれるはずの「if文のある条件のときだけヒープのある部分をfree」というコードのはずだが
安全なCのプログラムや コンパイルは通るしランタイムエラーも起こさない。
メモリ安全なプログラムの中では、cで書けるプログラムのほうがrustで書けるプログラムより広いんだね
rustはメモリ安全なcのプログラムと同等な処理を書けない部分もあって不便じゃないかっていうのが結局のところワイの疑問になるんや
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや?
メモリ安全性を損なってるわけでもない処理ではないはずなんやがrustのコンパイラははじくぞ?
706デフォルトの名無しさん
2021/05/21(金) 18:03:27.13ID:J6y23PLS
#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);
}

ほい完全版
707デフォルトの名無しさん
2021/05/21(金) 18:06:23.36ID:p9FphGnI
>>705
unsafe使え、というかもうちょっと具体的な例じゃないと困る
今まで出された例だと「最初から絶対通らないの分かってるならif文消せばいい」としか思えないので
708デフォルトの名無しさん
2021/05/21(金) 18:12:17.78ID:91Y2FzX3
別にわざわざCで書いてもらわなくても安全なのは分かるよ
今のRustコンパイラで通らないのはボローチェッカーが最適化前にあるからなんで
部分的にでも先に最適化すれば通るようにはできるだろう
ただそれをしたい動機が分からない
本当にifが実行される可能性が一切ないなら単に消せばいい、といしか言いようがないので
709デフォルトの名無しさん
2021/05/21(金) 18:14:06.78ID:J6y23PLS
>>703
それただの論点そらしだよね
UAFってrustの独特なメモリ管理手法と相反する用語ではないし
use of moved valueやborrow of moved valueもUAFを阻止するためのものだよね
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや?
710デフォルトの名無しさん
2021/05/21(金) 18:18:59.35ID:p9FphGnI
>>709
DroppableのメンバにBox<i8>持たせろ
仮に"drop"された後でもsubが正常に動くことが期待されているなら、そこで使うべきなのはdropではない
711デフォルトの名無しさん
2021/05/21(金) 18:22:54.40ID:91Y2FzX3
というか >>701 で書いたif/elseの例はちゃんと「if文のある条件のときだけヒープのある部分をfree」になっているのに何か不満なのか
712デフォルトの名無しさん
2021/05/21(金) 18:24:13.35ID:IHGXJo1X
>>709
UAFを阻止するためだけにあるものじゃないから
やり方は>>701で教えてくれてるやろ

とりあえずThe Book読んでね
713デフォルトの名無しさん
2021/05/21(金) 18:31:38.95ID:p9FphGnI
>>709
これでどうですか?
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=9b05ca192ab0fd529b6de05dcc64a8c9
714デフォルトの名無しさん
2021/05/21(金) 18:38:40.69ID:J6y23PLS
>>711
そうやん
rustって不思議やね
715デフォルトの名無しさん
2021/05/21(金) 18:44:49.25ID:J6y23PLS
解決しました。
なにはともあれありがとうございました。>>701の方に救われました。
ここまで関わってくださった皆様まことに協力ありがとうございました。感謝いたします。
716デフォルトの名無しさん
2021/05/21(金) 19:24:50.36ID:91Y2FzX3
「理論的に安全な任意のコードは通るべき」ってイメージだったのかな
実際にはそんなことはなくて、上の例のようなコードを通すためには色々なトレードオフがあるから
単に「理論的に安全」ってだけで無条件に実装されることはない
もっと具体的なユースケースがあって、みんなが「これは通らないと不便だよね」ってなったものが実装される
数年前に実装されたnon lexical lifetimesなんかはまさにその例だね
717デフォルトの名無しさん
2021/05/21(金) 19:31:11.66ID:bfSFy0HM
はぎゃーん
718デフォルトの名無しさん
2021/05/21(金) 21:43:48.32ID:HgMuIEwp
クロージャの disjoint capture が破壊的変更になるのは分かるんだけど最初からこうなってなかったのはなぜ?
719デフォルトの名無しさん
2021/05/21(金) 22:34:26.09ID:vpqVq/KA
iter()とinto_iter()の使い分けが分からない

iter()じゃないといけない場合があるのは分かるんだが
720デフォルトの名無しさん
2021/05/21(金) 22:49:37.59ID:+ok17UuV
into_iterは所有権を奪いItemを得ることができる
iterは&Itemを得る
他のintoで始まるものは所有権を奪うことになってる
721デフォルトの名無しさん
2021/05/21(金) 23:22:44.96ID:qRzkKAr2
>>711 Rustコンパイラが問題視してるのは開放された値を使ってしまう可能性があることで、それが修正された >>701 のコードは問題ないから通る
722デフォルトの名無しさん
2021/05/22(土) 00:04:28.82ID:yRhz4OAW
>>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
723デフォルトの名無しさん
2021/05/22(土) 00:34:10.91ID:RuplHzwP
as_foo(), to_foo(), into_foo() の違いも覚えておくとよいかもね
724デフォルトの名無しさん
2021/05/22(土) 00:45:11.88ID:yRhz4OAW
覚えておくとはいいのはそうだけど、そのセットは少し観点違うよね
https://rust-lang.github.io/api-guidelines/naming.html#ad-hoc-conversions-follow-as_-to_-into_-conventions-c-conv
725デフォルトの名無しさん
2021/05/22(土) 16:34:10.81ID:ma8sDMzI
Rustややこしいわぁ
726デフォルトの名無しさん
2021/05/22(土) 20:26:18.21ID:UuUK8ShD
Rust慣れたあと他の言語行くと
良い作法が身についてて歓迎される、とかありますか?
727デフォルトの名無しさん
2021/05/22(土) 20:30:50.12ID:18meLr+O
>>726
言語が異なれば同じことをするにも良い作法とされる方法は異なるだろうし、そんなに役に立たないかもよ。
むしろRustでは~と言い出すとかえってうるさがられる可能性も。
728デフォルトの名無しさん
2021/05/22(土) 20:34:58.75ID:RuplHzwP
rustでは変数のshadowing当たり前のように使うけど他の言語では嫌がられそう
729デフォルトの名無しさん
2021/05/22(土) 21:08:16.57ID:9BHHuuQy
let value = value;
とか他言語で書いたらアホだと思われるし
730デフォルトの名無しさん
2021/05/22(土) 21:10:13.17ID:61y793Zl
Rustはメイン関数かその次の関数のローカル変数にリソースを保持する形にしがちじゃない?
他の言語だとあんまりやらない
731デフォルトの名無しさん
2021/05/23(日) 03:12:09.36ID:1TnUlIAl
>>730
他の言語でも同じだよ
それとも禁断のグローバル変数を使う駄目パターンをRustでもしたいということ?
732デフォルトの名無しさん
2021/05/23(日) 06:28:03.88ID:ApnxiBa8
pythonみたいな動的型付け言語ではよう見るけどさ
Rustではこんなん要らなくしてほしいわ
733デフォルトの名無しさん
2021/05/23(日) 13:14:57.61ID:viOBOYhY
ライブラリによってはデータを持ち運ぶということが不可能だったりするからグローバル変数必須だったりするんだよな
(具体例: serenity)
734デフォルトの名無しさん
2021/05/23(日) 13:33:01.51ID:1FznZ2H5
いや別に必須ではないだろ。
735デフォルトの名無しさん
2021/05/23(日) 13:39:52.69ID:p3SEnqzU
log!() みたいなプログラムの各所から呼び出されるマクロや関数の実装の為には rust でも普通にグローバル変数使われているのでは

static 変数にするためには Sync が要求されたり mut にするために Mutex 使う必要があるから他の言語ほど気楽に使えないというだけで
グローバル変数そのものが禁断扱いされることはないかと

グローバル変数の濫用は他の言語同様嫌われるけどね
736デフォルトの名無しさん
2021/05/23(日) 13:43:31.31ID:1TnUlIAl
一般的にどんな言語においても何らかの外部のライブラリを取り込む時には
何か一つのクラスとかオブジェクトとか構造体とかに閉じ込めてしまって
それ一つだけ持ち運ぶからグローバル変数を使うことは無いでしょう
737デフォルトの名無しさん
2021/05/23(日) 16:18:03.34ID:ljEJPp90
>>735
static変数とglobal変数はスコープが違うだろ
global変数が悪とされるのは、そのスコープの広さだからね

いつどこで誰が変更するのか、また参照するのか、スコープが広ければ広いほど把握が困難になる
把握が困難になればなるほど、それだけバグを生む温床になる
738デフォルトの名無しさん
2021/05/23(日) 18:34:32.71ID:1FznZ2H5
io周りは極論すればどう管理してもグローバルだからな。
プロジェクト毎に規約設ける以外にまともに管理する方法なんてない。
739デフォルトの名無しさん
2021/05/23(日) 20:09:32.32ID:wHpcVS8W
>>735
そういやロガーの設定ってどこに保存されてるの?
debug!() 呼ぶたびにMutexロックしてるのかな?
740デフォルトの名無しさん
2021/05/24(月) 12:11:21.84ID:1Toh/2dP
>>736
クラスの中に入れても、グローバル変数であることは避けられないし
どんな言語においてもグローバル変数は必要。
741デフォルトの名無しさん
2021/05/24(月) 12:28:02.03ID:wwlvG9VZ
「:?」ってなんなんですか?
https://tourofrust.com/08_ja.html
742デフォルトの名無しさん
2021/05/24(月) 12:49:55.25ID:KKN49LSI
>>741
デバッグ用のフォーマットで出力するという意味
詳しくは以下参照
https://doc.rust-lang.org/std/fmt/
743デフォルトの名無しさん
2021/05/24(月) 13:24:07.35ID:JJaZh5wC
>>740
そんなことはないだろう。
確かにグローバルでも大して変わらんてものはあるけど、
loggerを引数で渡していくっていうような実装方法もある。
744デフォルトの名無しさん
2021/05/24(月) 13:33:20.21ID:u2umy7DV
>>739
logクレートのstatic mut変数だね
ロックするのは初期化とレベル設定時だけ
出力時にロックするかどうかは実装次第
745デフォルトの名無しさん
2021/05/24(月) 15:43:10.46ID:dukpbHqg
>>740
そのクラスの存在そのものがグローバル変数(相当)だという話?
それともそのクラスもしくはそのインスタンスをグローバル変数に入れて使うということ?
後者の意味ならば必要な範囲で引数として持ち歩けばグローバル変数を普通は使わないですよね。
746はちみつ餃子 ◆8X2XSCHEME
2021/05/24(月) 16:59:24.57ID:tdQ8iTTE
大事なのは抽象化がきちんとしているかどうか。
各部品が妥当な意味に分離されているかどうか。

グローバル変数がよくないのは色んなパーツから横断的に使われる可能性があって
部品が不必要に密結合していることの表れだからであって、
そのグローバル変数のアクセス範囲が妥当な範囲に制御されているなら問題じゃないよ。

過剰な密結合を解消せずにグローバル変数を引数に置き換えてたら
影響範囲が見えにくくなってもっと悪くなることだってありうる。

まあどういう場合なら妥当なのかってのは色々と意見はあると思うけど。
747デフォルトの名無しさん
2021/05/24(月) 17:17:23.03ID:qqtJSk72
$_POSTはセーフ
748デフォルトの名無しさん
2021/05/24(月) 17:21:32.94ID:Ig527IlE
>>746
まずは長くて区別しやすい名前に変えるのがスタートかね。
749デフォルトの名無しさん
2021/05/24(月) 17:31:54.98ID:wwlvG9VZ
>>742
ありがとう!なんか独特なのね
750デフォルトの名無しさん
2021/05/24(月) 23:12:37.25ID:rI3Y4Uqa
関数型言語やったことないけど、Rustいけるかな
JavaとC++はそこそこ経験あり
751デフォルトの名無しさん
2021/05/24(月) 23:17:37.88ID:zk4LoLUU
Java 8とかC++ 14以降くらいなら結構似たような機能も入ってるし
そこまで大変じゃない気がする
752デフォルトの名無しさん
2021/05/24(月) 23:36:00.17ID:JJaZh5wC
c++はともかく、cくらいはやっぱ理解してた方が早道な気はする。
753デフォルトの名無しさん
2021/05/25(火) 01:36:21.07ID:5vUI50kp
以下のような関数を作ったんですが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(())つけるのがすごく気持ち悪いんですが、
返値なしのままどうにかする方法はないでしょうか
754デフォルトの名無しさん
2021/05/25(火) 02:11:48.11ID:QcInQ0e9
if_chain使って
if_chain!{
if let Some(x) = x;
...
then { println!("{}", x); } }
755デフォルトの名無しさん
2021/05/25(火) 02:16:51.35ID:Ygc8ZzR1
>>753
fooの型変えられないなら、戻り値Optionはクロージャないしローカル関数に留めるといいと思う
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=aa2bc019e7329f1b6bece2597b59ee8a
756デフォルトの名無しさん
2021/05/25(火) 03:00:10.05ID:nrKC74iS
Ok(())はよく使うがSome(())はないな

普通にif-letでパターンマッチするのでよくない?
if let (Some(x), Some(y)) = (x, y) {
println!("{} {}", x, y);
}
757デフォルトの名無しさん
2021/05/25(火) 05:18:39.47ID:gz717nup
loggerを引数で渡すためには
ロギングを行うクラスFooがどこかしら(コンストラクタか個々のメソッドで)loggerを受け取る引数を持たねばならない
これ、ロギングみたいな裏方の仕事がFooのインターフェース仕様に影響しているということで、
抽象度が下がってるやんけ;;;

引き換えに得られるメリットは、Fooのインスタンスごとにloggerを切り替えられるというおおよそ現実的にありがたみが無い機能だけ
758デフォルトの名無しさん
2021/05/25(火) 06:08:48.35ID:FYPKUk3M
>>756
それをmachでやるのがよくない?
759デフォルトの名無しさん
2021/05/25(火) 06:23:40.79ID:gz717nup
つか機能の分離と記述の分離はトレードオフがある
1+1=2の形式的証明がどんだけの糞みたいな分量のに成り得るかを見たらワカル
どっかの抽象度をつきつめれば別のところにしわ寄せが逝く
それで良いジャマイカ人間の言語だもの、
760デフォルトの名無しさん
2021/05/25(火) 09:01:56.56ID:5vUI50kp
皆様ありがとうございます
どうもSomeをある程度書くのは避けられない感じですね
761デフォルトの名無しさん
2021/05/25(火) 10:09:28.07ID:4oEEOZjA
まさかstatic変数使ってるなんて、logクレートには失望したわ
762デフォルトの名無しさん
2021/05/25(火) 10:33:41.89ID:bGIV0Xp5
>>757
ログを裏方と考えるのも偏ってるし、ログ切り替えはデバッグ目的で普通にあるわ。
別にグローバルにするという選択が間違いとも思わんがこういう決めつけ野郎は邪魔だな。
763デフォルトの名無しさん
2021/05/25(火) 10:59:01.14ID:/nQyXsn+
サーバ側だとログを取るのが基本だし取り方も変えたくなるからlogger渡しは結構やるな
CLIとかなら雑にstaticでいいけど
764デフォルトの名無しさん
2021/05/25(火) 13:12:03.88ID:CssgwvqL
>>761
stdも使えないじゃん
765デフォルトの名無しさん
2021/05/25(火) 18:48:30.58ID:4oEEOZjA
>>764
なんで?
766デフォルトの名無しさん
2021/05/25(火) 19:25:41.69ID:CssgwvqL
>>765
https://github.com/rust-lang/rust/blob/a7890c7952bdc9445eb6c63dc671fa7a1ab0260d/library/std/src/io/stdio.rs#L553
767デフォルトの名無しさん
2021/05/25(火) 19:39:28.48ID:4oEEOZjA
>>766
えー
これからは write() システムコールでプリントするわ
768デフォルトの名無しさん
2021/05/25(火) 21:02:03.28ID:p1A5R6d8
stdが嫌ならcoreを使え
769デフォルトの名無しさん
2021/05/25(火) 22:59:34.15ID:gz717nup
>>762
近代的なログシステムならタグが使えるから
記録時に分っける理由がさらさらない
だいたい並列な事象を並列なまま記録したのでは時系列の解析ができないし、

そもそも>>762がいくら「ログは裏方じゃない」と叫んだところで基準が無い
アプリケーションロジックを汚してまでか?!という議論はいつまでもつきまとう
770デフォルトの名無しさん
2021/05/26(水) 00:00:47.75ID:S2nFrW0F
別に仕事で使ったことないならそういえばいいと思うよ。悪いことしてるわけじゃないんだから。
771デフォルトの名無しさん
2021/05/26(水) 00:04:47.15ID:PLorGv/T
そういやLog4JでいうMDCみたいなやつはあるのかしら?
772デフォルトの名無しさん
2021/05/26(水) 00:07:56.89ID:rwxZHBm1
お前らslog

>>760
ただのzipやん。
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=01c2f30ff2a49dc57c917ec16947aadb
773デフォルトの名無しさん
2021/05/26(水) 08:19:13.92ID:AN5OxrIl
まあloggingオブジェクトを複数作る仕事なんなら仕方が無いな
774デフォルトの名無しさん
2021/05/26(水) 08:29:19.07ID:vJAmL6Qi
slog見たけど、クソややこしいな
775デフォルトの名無しさん
2021/05/28(金) 09:51:25.19ID:jQHjx/Sg
シンタックスで判断しづらいもので性的分析するって、そのうち破綻しそうだな。
776デフォルトの名無しさん
2021/05/28(金) 09:54:11.42ID:S8Iz9SRl
エロい分析か
777デフォルトの名無しさん
2021/05/28(金) 10:45:17.68ID:EKMYAKDR
やらC
778デフォルトの名無しさん
2021/05/29(土) 20:28:41.06ID:sKXDX7XX
JPEG-XLのリファレンス実装作ってるチームがRustで再実装も始めてて驚いた
https://github.com/libjxl/jxl-rs

FirefoxにJPEG-XL対応を入れるかどうか議論するチケットで
今更大量のunsafeなC++コードを入れるのはちょっと……みたいな反応をされてた事と関係あるのかもしれない
779デフォルトの名無しさん
2021/05/30(日) 15:56:56.42ID:HupJBx7X
https://4e6.github.io/firefox-lang-stats/
https://www.openhub.net/p/firefox/analyses/latest/languages_summary
Firefox、かなりの割合でC++のコード入ってるけどこれでも減らそうとしてるのか
780デフォルトの名無しさん
2021/05/30(日) 16:00:13.57ID:P46Jh5T1
もう9.5%も行ってるのか

と言うかfirefoxからrustは始まったから当然か
781デフォルトの名無しさん
2021/05/30(日) 16:15:38.02ID:ds+xAsBi
でも、大量の有名なWebサービスが一時的にRubyで書いていたのに、
しばらくすると他言語に書き直した歴史がある。
アメリカ人はなぜか言語を書き直すのが好きなようだ。
Rustで書いてもまた別言語に直すかも知れない。
なお、Googleドライブなどの各社のストレージサービスを統一的なAPIで制御できる
ライブラリも何故かGoで書かれている。
メンドクサイ。
782デフォルトの名無しさん
2021/05/30(日) 17:11:41.17ID:cF4puvJq
>>781
遅い方から速い方へ書き直すのよ
特にスクリプト言語からC++/Rustへ書き換えるとサーバー数を1/10にできるケースもあり規模によっては経費激減ね
GoもGCあるから場合によっては他へ書き換えられる対象になりうるかも
Rustが他へ書き換えられる可能性がもしあるとしたら今はまだ存在しない新たに出現する言語へ
783デフォルトの名無しさん
2021/05/31(月) 00:35:54.04ID:7s+MSAY0
なんでClippy大先生がcargoでインストールできるクレートから外されるの?
784デフォルトの名無しさん
2021/05/31(月) 01:50:13.82ID:u1BqTaEs
rustupでインストールできるからでは
rustcとバージョン合わせないといけないから他のcrateと同じ扱いはしづらいのでは
785デフォルトの名無しさん
2021/05/31(月) 08:44:19.92ID:etoumxTf
Ruby on Rails の時価総額は、

Shopify が15兆円、
民泊のAirbnb が、大手ホテル3社の合計以上の10兆円、
Github が8千億円

これぐらい巨大でも、Rails で出来る。
時価総額が千億円以上になったら、Go, Elixir を考えてもよい

食べチョクは売上50億円らしいけど、
若い文系女が1人で起業したような会社は、Rails で十分

売上が千億円を超えたら、考えてもよい
786はちみつ餃子 ◆8X2XSCHEME
2021/05/31(月) 15:24:48.93ID:hqkxpUd6
ウェブシステム全体の実行コストはネットワークや IO にボトルネックが有るので
システム構成やらなんやらで工夫するのがまずやることで、
言語の速度が少しばかり速いのはそんなに効いてこないよ。

という話もよく聞くんだけど、実際のところどんなもんやろね?
787デフォルトの名無しさん
2021/05/31(月) 16:31:16.04ID:slsuSMsk
そりゃそうね
でも実行速度だけで選ぶわけじゃないからね
788デフォルトの名無しさん
2021/05/31(月) 19:40:04.29ID:mBUAbPrR
今まではハードにぶん投げても大丈夫だったのが
ハードの進化の鈍化でソフト側が工夫しないと駄目になりつつあるって話ってマジ?
789デフォルトの名無しさん
2021/05/31(月) 21:37:16.00ID:M7WLmn8V
いやそこでソフトで頑張ってもほぼダメだろ。。アーキテクチャで分散化考えないとって話じゃないかね
790はちみつ餃子 ◆8X2XSCHEME
2021/06/01(火) 01:05:37.48ID:69wa4c/Y
>>788
ハードウェアがもう伸びないってことではなくて、 CPU の速度が単純に速くなるという方向ではもう伸びにくいって話。
電子の大きさは変えられないから際限なく微細化できるわけではない。

わかりやすい例で言えば今のパソコンはマルチコアが当たり前になってて複数の CPU を載せる方向で性能を上げているが、
マルチコアを想定してないソフトをマルチコアパソコンで動かしてもひとつのコアしか使わないので性能が出ない。
高価な GPU を乗せても GPU を使うプログラムになってなきゃ意味がない。

ハードウェアの総合的な性能を上げるには色んな工夫があり得て、それらを実現すると同時に
ソフトウェアは「ハードウェアに合わせて」「ハードウェアの性能を引き出すように」工夫がいる。

これは今までにも普通にやってたことで、今になって必要になったわけじゃない。
小さな変化の積み重ねなこともあれば大きな変革を迫られることもあるってだけ。
791デフォルトの名無しさん
2021/06/01(火) 07:44:50.11ID:DWqq5xbS
後藤弘茂のWeekly海外ニュース■ Prescott/Tejasは5GHz台、65nmのNehalemは10GHz以上に
https://pc.watch.impress.co.jp/docs/2003/0227/kaigai01.htm
当時は景気よかったっすね。すぐ後に爆熱で日和ったけど
そして今、300Wの時代・・・

てか並列化によるスループットの向上はこのあたりから検討されるようになっていた気が
792デフォルトの名無しさん
2021/06/01(火) 19:29:09.48ID:a3oi+h5L
>>784 でも何故かcargoだけはcargo install cargo --forceとすれば自分でコンパイルしたもので上書きができる謎
793デフォルトの名無しさん
2021/06/04(金) 15:33:30.83ID:kJqxa98Z
よくわからないんだけどこれ、C言語のポインタ渡しが諸悪の根源で、そこを断ちさえすればC言語も所有権概念を取り入れられるの?
794デフォルトの名無しさん
2021/06/04(金) 15:42:09.57ID:03MQShFS
>>793
C言語において、ポインタは大発明で、それによってリンクリストやツリー構造
が簡単に実装に出来る様になった、大変重要なもの。
C言語からポインタを絶てば何も残らない。
795デフォルトの名無しさん
2021/06/04(金) 15:48:43.92ID:1/rRer4v
Javaキチガイはポインタ使いこなせない
日本のMSの社員がソレだった
破棄忘れてやんのw
796デフォルトの名無しさん
2021/06/04(金) 15:55:06.60ID:JfDLBnT5
RAIIなしで良いなら多少の拡張で所有権の概念取り込めるかも知れないけど
絶対スマートポインタ欲しくなるしCの表現力だと使いづらい物になりそうな気がする
797デフォルトの名無しさん
2021/06/04(金) 16:03:03.62ID:KjgiO9jk
>>794
>C言語において、ポインタは大発明
笑笑
798デフォルトの名無しさん
2021/06/04(金) 17:24:32.39ID:Lunsq3fv
Cと比較するのは流石に乱暴だろ
C++と比較するべき
で、C++でできなくてRustでできるものというのは現状存在しない (今後その差も埋まっていくだろうが)

C++とRustの違いはひとえにスタンスの違いだよ
自由奔放なC++か良いコードにカッチリ導いてくれるRustか
意欲的に新機能取り込んで発展してるのは両者とも同じ
799デフォルトの名無しさん
2021/06/04(金) 17:31:18.17ID:AGlHvwIO
>>798
>C++でできなくてRustでできるものというのは現状存在しない
こういう比べ方はアホ
チューリング完全ならなんでもできるじゃんみたいなことになる
できるできないの線引きが恣意的
800デフォルトの名無しさん
2021/06/04(金) 17:54:18.33ID:7u0nl5aT
>>799
バカアホじゃなくて、Rustでしかできないものの例を挙げてください
そうすれば一単語で反論の余地なく終わるんで
801デフォルトの名無しさん
2021/06/04(金) 17:58:01.49ID:UUHTR6cx
C++は奇麗に描くと言うのが出来ない
802デフォルトの名無しさん
2021/06/04(金) 18:03:48.84ID:Pwqe5Yy7
>>800
C++でできなくてRustでできるもの
から
Rustでしかできないもの
への華麗な転身www
803デフォルトの名無しさん
2021/06/04(金) 18:16:57.72ID:hlBLv8XD
C++はMemory Safetyをコンパイル時に担保できない
Rustを使う一番の動機
804デフォルトの名無しさん
2021/06/04(金) 18:53:59.58ID:nHzCWsfU
>>802 C++とRustの比較において「C++でできなくてRustでできるもの」と「Rustでしかできないもの」は同じ意味だから転身でもなんでもない
Rust part10 ->画像>2枚
805デフォルトの名無しさん
2021/06/04(金) 19:11:16.95ID:s8nyhwnD
Cloudflareの画像処理責任者を名乗る人も、これ以上C++ライブラリを増やすのはイヤでござると発言してるな
806デフォルトの名無しさん
2021/06/04(金) 19:23:30.63ID:4pNcWBF2
>>804
C++とRust以外にも言語はたくさんある
807デフォルトの名無しさん
2021/06/04(金) 19:29:23.53ID:nsxzushh
Rustのモジュール(ファイル分割)の仕組みはC++のヘッダー+ソース(+名前空間)より扱いやすいと思う
C++は分割コンパイルが主流だった歴史的経緯があるから仕方ないけど事前の宣言が必要なのは地味に面倒くさい
808デフォルトの名無しさん
2021/06/04(金) 19:43:15.38ID:nHzCWsfU
>>806 この会話の流れではC++とRustの比較をしていたから
809デフォルトの名無しさん
2021/06/04(金) 19:58:10.76ID:4pNcWBF2
ライフタイムによるメモリ管理はRustオンリーだろ
810デフォルトの名無しさん
2021/06/04(金) 20:12:39.71ID:s8nyhwnD
マイナーな環境だとC++プログラムは様々な理由でコンパイルが通らないことがよくある
Rustは基本的にはそういう事ないし、コンパイラ実装が一つしかないというのも利点に働く
811デフォルトの名無しさん
2021/06/04(金) 20:40:42.82ID:CpdoeubZ
C++との比較を議論したいなら専用の隔離スレでどうぞ
812デフォルトの名無しさん
2021/06/04(金) 22:02:04.46ID:ivUqItUs
>>793は言語レベルのサポートがほしいんだろ?
substructural type systemがないと無理。

>>809
MLkit,RTSJ,cyclone,ATS/ATS2。学術的にはとっくの昔に廃れたぞ。
813デフォルトの名無しさん
2021/06/04(金) 22:04:58.58ID:yXI/MC9G
WinUIとRustやってる人いる?
同じネイティブのMFCとかと比べて、やっぱり生産性は高いんかな
814デフォルトの名無しさん
2021/06/04(金) 22:26:52.09ID:I1RVdPKQ
メモリ関連って原因不明のバグ引き起こしやすいしトータルな目で見れば上がるんじゃないだろうか
815デフォルトの名無しさん
2021/06/04(金) 23:27:29.47ID:JfDLBnT5
>>810
gcc-rsとかのプロジェクト始まってるけどそれはネガティブなことなのかね
816デフォルトの名無しさん
2021/06/05(土) 06:04:54.16ID:uC9Joojh
>>810
そういえば、C++のSTLは、VSでは動くが、BSD系のLLVM用のlibc++は、
なかなか上手く動いてくれない。理由は、libc++が、その
基礎関数として滅多に使われないようなMB・WC文字変換関連や、
NAN、INFINITYなどのfloat/double調査関数など、昔ながらのC環境では
定義されて無いような(新しい)Cの関数を大量に必要としているため。
その意味で、WasmのWASIなんかは、たとえCUIだけであっても
世界共通の関数群を整備してくれるのだとしたら有りがたいかも知れない。
でもWASI自体の移植作業が必要になるから一緒か。
817デフォルトの名無しさん
2021/06/05(土) 06:14:19.54ID:uC9Joojh
>>816
昔からCには文字種判別として、isalphaやisdigitなどがあるが、
libc++は、isalpha_l()などのlocale指定タイプを必要としていたりして
locale関連がやたらと複雑。また、その
isalpha_lなどを基礎にしてくれているならまだしも、isalpha_lが内部で使っている
文字種テーブル unsigned short _ctype[256]; も仮定していたりする。
このテーブルは、_CONTROL、_SPACE、_DIGIT、_ALPHAなどの
BIT定数とandを取ってBITが立っているかどうかで文字種を判定する。
それは環境依存なのだが、高速化のためか何故かそれを必要としている。
(C++のライブラリが欲しいのに、そのライブラリが、なぜか一般的ではない
大量のC関数や特殊なデータテーブルを必要としてしまっている。)
だから移植が進まない。
plain Cは、標準ライブラリが多くの環境である程度の互換性を持って整備されているが、
結果的にC++のSTLはなかなかそうではないようだ。
818デフォルトの名無しさん
2021/06/05(土) 06:17:47.83ID:uC9Joojh
C++ライブラリがisalpha_lなどを用いてしまったら、速度面でC#やJavaなど
に比べた優位性が少なくなってしまうからかも知れない。
つまり高速化のためにやたらと移植性の低い方法を使っているから、
スムーズに移植が進まない。
それか単純にC++ライブラリを作る人の技術力が低いからだろうか?
819デフォルトの名無しさん
2021/06/05(土) 06:20:08.28ID:uC9Joojh
>>801
すまんが、Rustはもっと出来ない気がする。
820デフォルトの名無しさん
2021/06/05(土) 09:02:04.60ID:KdS0cXcP
RustスレでC++の話題が出てしまうのはもはや運命なのか
821デフォルトの名無しさん
2021/06/05(土) 09:20:03.77ID:3ILRB2eH
>>820
そりゃ better C++言語として作られたんだから当たり前でしょう
822デフォルトの名無しさん
2021/06/05(土) 09:32:35.80ID:4o2YwJP1
ライフラインの書き方がとにかく見づらい
823デフォルトの名無しさん
2021/06/05(土) 09:45:07.09ID:3ILRB2eH
これヤバくない?
どうやって防いだらいいんだろう?

https://github.com/lucky/bad_actor_poc
824デフォルトの名無しさん
2021/06/05(土) 09:46:58.65ID:4o2YwJP1
localhostに送るだけならいくないん?
825デフォルトの名無しさん
2021/06/05(土) 09:53:33.78ID:3ILRB2eH
え、マジで言ってるの?
826デフォルトの名無しさん
2021/06/05(土) 10:04:24.16ID:4o2YwJP1
あおられてもダメな理由がわかりまそん
びっくりはするけど
827デフォルトの名無しさん
2021/06/05(土) 11:21:46.59ID:KdS0cXcP
悪意を持ったコードをビルドしない
828デフォルトの名無しさん
2021/06/05(土) 12:04:01.08ID:bvIfRQLF
c++との比較はガファムが結論出してくれたからもう話すことなどない
829デフォルトの名無しさん
2021/06/05(土) 12:08:54.56ID:85+uBK5B
何をみて結論だと思ってんだか。短絡的だな。
830デフォルトの名無しさん
2021/06/05(土) 12:26:06.61ID:YTe/4gPS
依存するクレートの依存するクレートの依存するクレートの以下無限ループまで全部チェックしないと駄目ー?(´・ω・`)
831デフォルトの名無しさん
2021/06/05(土) 12:58:14.11ID:KdS0cXcP
チェックするツールとか誰か作っていそうだね
バイナリを診断するよりは簡単だろうし
832デフォルトの名無しさん
2021/06/05(土) 13:57:18.40ID:IMH8ctkE
>>826
念のためマジレスすると公開した人がいつでもlocalhostを〇国サーバーのアドレスに書き換えられるってこと
githubのオープンソースでそれやったらすぐにばれそうだけど

ビルド時ならともかくエディタ起動直後のコード解析でデータが送信されるのは盲点やね
833デフォルトの名無しさん
2021/06/05(土) 14:01:47.49ID:f5S9H8yw
ビルドしなくてもファイルを開いたらコードが実行されるというのはよろしくないね

ファイルやネットワークならアクセスされる側でブロック可能だけど
メモリはサンドボックス内のみで展開・実行されるようにしないとブロックできない気がする

サンドボックス化できなければ
cargo auditやcargo crevを通して怪しいcrateだけ自分でチェックするとかかな
834デフォルトの名無しさん
2021/06/05(土) 14:06:05.14ID:KdS0cXcP
vscodeやlspヤバイな
835デフォルトの名無しさん
2021/06/05(土) 14:13:31.58ID:8YO6sBC6
解決方: vscode を使わない
836デフォルトの名無しさん
2021/06/05(土) 14:27:34.92ID:4o2YwJP1
まったくだ
837デフォルトの名無しさん
2021/06/05(土) 14:48:29.61ID:uV7DnhUL
見た感じVSCode以外でもマクロが実行されるようなことをすると駄目っぽいが
838デフォルトの名無しさん
2021/06/05(土) 14:52:35.33ID:4o2YwJP1
MS自身がやりたい放題だからメンタルも伝播するだろうな
839デフォルトの名無しさん
2021/06/05(土) 15:03:58.08ID:85+uBK5B
>>835
それrust使わなけりゃでも良くね?
840デフォルトの名無しさん
2021/06/05(土) 15:09:20.73ID:uV7DnhUL
そもそもこれ本質はライブラリの信頼性って問題だと思うんだよな
Rustだけじゃなく他の言語にも言える話
841デフォルトの名無しさん
2021/06/05(土) 15:22:11.73ID:85+uBK5B
お得意の静的チェックでなんとかしたら?
842デフォルトの名無しさん
2021/06/05(土) 15:29:47.09ID:KdS0cXcP
中国のipアドレスは全部ブロックしておくのが正解だな
843デフォルトの名無しさん
2021/06/05(土) 15:51:07.65ID:3ILRB2eH
IntelliJ/CLion でもproc_macro実行されちゃうの?
844デフォルトの名無しさん
2021/06/05(土) 16:11:56.77ID:Fi/fLauk
LSPはクソ
vscodeありきの思想
845デフォルトの名無しさん
2021/06/05(土) 16:32:08.49ID:6EguRj/L
LSPってHSPの親戚ですか?
846デフォルトの名無しさん
2021/06/05(土) 16:43:48.73ID:KdS0cXcP
long short play モードだよ
847はちみつ餃子 ◆8X2XSCHEME
2021/06/05(土) 16:56:48.31ID:G0EcoOQC
>>844
LSP はエディタとの連携を前提として明文化された規格にしたってだけで、
処理系にコンパイルさせた結果をエディタの表示に反映させるというのは昔から有ったんだぞ。
848デフォルトの名無しさん
2021/06/05(土) 17:38:04.49ID:ftrSVS/I
>>847
> 処理系にコンパイルさせた結果をエディタの表示に反映させるというのは昔から有ったんだぞ。

いやそりゃそうだろ
その説明じゃ flycheck 等と差がない
849はちみつ餃子 ◆8X2XSCHEME
2021/06/05(土) 18:00:21.39ID:G0EcoOQC
>>848
Rust のコードをビルドしないときでもエディタ経由で勝手にビルドする
(そのときに悪意のあるコードも走らせられるかもしれない)
という文脈の中で >>844 の発言があったので、
それは LSP が作られる前から同じような危険性はあっただろうという反論を私はしたつもり。

LSP のせいじゃなくてコンパイル時に出来ることが多い Rust のせいって話。
850デフォルトの名無しさん
2021/06/05(土) 18:09:21.84ID:Fi/fLauk
はあ話になんね
こいつといいQZといい「何か物申したい」という気持ちだけで生きてるから常に空回ってんだよな
851デフォルトの名無しさん
2021/06/05(土) 18:52:13.97ID:ZTm581Ue
proc-macroがwasm化されてサンドボックスで動くようになればマシになるのかね
そもそも怪しいコードが依存関係に混入しちゃう時点でcargo runなりtestなりしたらなにされるかわからん訳でproc-macroの件自体にどれくらいの影響度があるのかは分からんが
852デフォルトの名無しさん
2021/06/05(土) 19:44:30.63ID:uV7DnhUL
crossでx86_64-unknown-linux-gnuをtargetにクロスコンパイルしたらいいんじゃないか?
あれ確かDockerで動いてたはず
853デフォルトの名無しさん
2021/06/05(土) 19:45:33.78ID:uV7DnhUL
自分のPC向けにクロスコンパイル用ツールを使ってコンパイルするのがクロスコンパイルというかどうかは知らんけど
854デフォルトの名無しさん
2021/06/06(日) 08:03:37.51ID:W7azs2BY
>>823
特定のエディターの問題ではなく
特定のプログラミング言語の問題ではなく
自分が意図していない自動マクロ(プラグイン)を使えば自分が意図していない動作をするだけの話
大昔からあらゆる環境で起きていること
855デフォルトの名無しさん
2021/06/06(日) 09:39:11.50ID:3IIg9tuB
コーディング時、ビルド時になんでもやらせようって発想が間違ってんだよ。
856デフォルトの名無しさん
2021/06/06(日) 10:03:07.57ID:mKFU6ep6
マクロはやっぱ悪よな、無いと辛みが増すから仕方ないじゃなくて無くても何とか出来る仕様にすべき
857デフォルトの名無しさん
2021/06/06(日) 10:25:40.41ID:W7azs2BY
今回の>>823の問題に限っていえば
そもそもLSPを使う人のためのプラグインなのだからLSPのlocalhost:8080に接続に行くことは何の問題もないよね
問題としているのはSSHの秘密鍵をそこへ自動送付していること
LSPそこまで詳しくないのだけどそれはどうしても必要なことなの?
858デフォルトの名無しさん
2021/06/06(日) 10:32:40.20ID:MV541K/D
LSPは、この騒動(?)と関係なくクソ
859デフォルトの名無しさん
2021/06/06(日) 10:33:23.63ID:MV541K/D
快適なエディタと快適なIDEの区別がつかなくなったバカどもがゴリ押しで流行らせてる
860デフォルトの名無しさん
2021/06/06(日) 11:08:51.30ID:n+sQSuEO
>>857
>LSPのlocalhost:8080に接続に行くことは何の問題もないよね

localhost:8080はLanguage Serverじゃないよ
861デフォルトの名無しさん
2021/06/06(日) 11:16:22.93ID:W7azs2BY
>>860
それはすまなんだ
じゃあ何が問題になってるのかな
862デフォルトの名無しさん
2021/06/06(日) 12:13:20.98ID:xB3z9vbi
>>861
LSPをセットアップした状態だと「VSCodeを起動しただけで」自動ビルドが走ってしまって悪意あるprocedural macroが実行されてしまうこと
手動でビルドすれば同じことになるのでそこは問題の本質じゃなくね?とは思う
863デフォルトの名無しさん
2021/06/06(日) 12:48:13.98ID:V+UU2WI7
LSPというよりrust-analyzerやrls、cargo/rustcの問題と言った方が正確かな
864デフォルトの名無しさん
2021/06/06(日) 14:24:19.60ID:W7azs2BY
では>>823で指摘されている問題点「自分のSSHの秘密鍵が勝手に読み出されて送信される」はどの部分がその動作を要求しているの?
本当に必要な動作なの?
865デフォルトの名無しさん
2021/06/06(日) 14:29:37.79ID:LOfpkHxA
手続きマクロの展開なのでcargo checkでも起こり得る
言ってしまえばRustの言語仕様そのもの
解決策は>>851の言うようにサンドボックス化するみたいな方法しかなさそう
866デフォルトの名無しさん
2021/06/06(日) 14:35:16.58ID:n+sQSuEO
>>861
macroをexpandする時に
macroの定義に書かれてる任意のコードを実行することができるって話

任意のコードの例としてSSHのキーをサーバーに送信する例が書かれてて
試す人に無害なように送信先サーバーはlocalhostになってるだけ

コード見たほうが早いかも
make_answer!がexpandされるときにread_ssh_keyが実行される
https://github.com/lucky/bad_actor_poc/blob/master/bad_actor/src/lib.rs
867デフォルトの名無しさん
2021/06/06(日) 14:40:17.63ID:3IIg9tuB
このコード例はめちゃくちゃわかりやすい。問題は置いといてgoodなコードだ。
868デフォルトの名無しさん
2021/06/06(日) 15:22:49.77ID:fghVy2Pw
crate-typeがproc-macroのときはffiを禁止して使用可能なextern crateを
安全性が保証されたものだけに制限するのがRustっぽいかな
proc-macro専用のstdが必要になるけどno_stdと同じ感覚でmacro_safe属性をつければいい
869デフォルトの名無しさん
2021/06/06(日) 16:06:34.14ID:xR3kS6+v
そもそも普通はproc-macroなんか必要ないだろ
特殊用途以外では一律禁止してよいのでは?
870デフォルトの名無しさん
2021/06/06(日) 16:20:07.52ID:V+UU2WI7
derive が使えなくなるのは結構困る
871デフォルトの名無しさん
2021/06/06(日) 23:45:39.31ID:xQoKsnFB
>>843
マクロ展開すればどんな環境でもできるよ。
>>823はmulti-root workspaceの構成間違ってるから
IntelliJRustだとマクロ展開されないけど。

>>869
custom derive全部禁止だから当然thiserrorもserdeもdelegation系も禁止な。
ボイラープレート全部手書きしろよ。
872デフォルトの名無しさん
2021/06/07(月) 06:02:10.08ID:k/PpyTws
頭悪い奴らばかりで議論にならぬ
趣旨と仕組みはreadme書いてあるのに。。
873デフォルトの名無しさん
2021/06/07(月) 13:37:53.63ID:BQ22AOvo
今勉強中なんだけど、Rustと合わせた時のgdbの使い方を教えてくれんかな
行指定でb main.rs:10みたいにブレイクポイントを指定するのってどうやるの?
>No source file named main.rs.
みたいに言われてしまって、どうやって行指定でブレイクポイントを設定するのかよくわからん
ソースのあるディレクトリがわからないのかと思って指定しても結果は変わらず・・・・
あと、ソースを表示しながらステップ実行したりってどうやるの?
874デフォルトの名無しさん
2021/06/07(月) 13:52:39.17ID:C46sPHOc
vscodeでcodelldb使おう
875デフォルトの名無しさん
2021/06/07(月) 14:06:08.51ID:BQ22AOvo
ああ、デフォルトで-gつかないのか・・・・
でもlldbが主流っぽいし、それ使うかな
876デフォルトの名無しさん
2021/06/07(月) 14:34:12.65ID:VGLcnon2
macのgdbだと今はまともに動かんぞ。
877デフォルトの名無しさん
2021/06/07(月) 14:45:09.07ID:OvPzoGrd
M1になってmacの開発環境死んだ
878デフォルトの名無しさん
2021/06/07(月) 15:56:52.66ID:D0MWfzjy
iPhone開発でMac必須になったことで強気に出すぎたか。
Macは滅びると思っていたらx86系になってからなぜかしぶとく生き残ってきたけど、
もうだめかもな。
879デフォルトの名無しさん
2021/06/07(月) 16:08:45.47ID:BQ22AOvo
lldbを試しに使ってみてるんだけどさ
これって、ステップ実行するたびに自動で毎回「memory read --size 8 --format x $sp」をやってもらうことってできないの?
gdb-pedaを使っていたときはスタックの中身が自動で見れてたんだけど、なんか似たようなのないのかな?
880デフォルトの名無しさん
2021/06/07(月) 20:20:51.05ID:RuDnuZ5b
>>878
iphoneアプリ開発のためにmacが生き残ってるのは面白いと思ってる
元マカーだからほんと言うと寂しいし悲しいんだけど
881デフォルトの名無しさん
2021/06/07(月) 21:33:04.68ID:l0c3FfTp
rustのlinux kernel対応の話ってどうなってゆの?なんだかずいぶんと作業が難航しているうだけど
それってrustのどのあたりの言語機能が悪さをしているのかね
882デフォルトの名無しさん
2021/06/07(月) 21:34:18.90ID:l0c3FfTp
難航しているよう
883デフォルトの名無しさん
2021/06/07(月) 23:22:49.68ID:TtFMbk6H
>>873
シンボリックデバッガはまだ有名どころのフロントエンドが
ステップ実行できる程度しか対応してないから、アブソリュートデバッガ併用になる。
シンボルでブレークポイント設定できないとか実行に問題あるとかまだ普通。
msvcツールチェインは特に。

>>877
ねねっち死んだなって思ってたけど現実もか。

>>878
世界シェア15%切ったし頼みの日本シェアすら50%切ったからもう
iPhone専用開発機も持たないだろう。
rustだとandroidほどバインディングが充実してないから開発やりずらいだろうし。
884デフォルトの名無しさん
2021/06/08(火) 13:22:42.82ID:NxfO+lQp
>>881 大部分がRustで書かれたRedox OSっていうOSがあるからRustでカーネルやドライバが書けないというわけではないと思う
恐らくCで書かれた過去の遺産との連携で手こずってそう
885デフォルトの名無しさん
2021/06/08(火) 16:32:33.53ID:XAjWEwKV
>>883
日本でのiPhoneのシェアは、どんどん減っているはずなのに、ググると、
増えているデータになっていて、増えているのに50%を切っているというわけの
わからなさ。
記憶では、70%くらいまでいって、下がった結果、49%くらいになったはずなのに。
886デフォルトの名無しさん
2021/06/08(火) 17:33:30.46ID:0HakL4nG
>>884
具体的には?
887デフォルトの名無しさん
2021/06/08(火) 20:08:36.67ID:3DogIzpc
いやメーリスみにいけよ。。。
888デフォルトの名無しさん
2021/06/08(火) 20:44:34.79ID:iJOvL9Jr
実際の開発状況はこっち見たほうがいいかな
https://github.com/Rust-for-Linux/linux
ざっと見た感じ難航してるっていうより単にやること多いってだけに見えるけど
889デフォルトの名無しさん
2021/06/08(火) 22:36:25.74ID:onwST/YK
>>885
出荷ベースだと二三年前に65%超えてて2020Q4に約49%だからそれであってるよ。

>>888
OS作ってる人らって開発環境はなんだろ?
intellijrustはデバッガ使えるIDEとツールチェインが限られるし
matklad.rust-analyzerは環境変数の扱いがめちゃくちゃで
環境変数見に行くとまともに動かないし。issueばっか増える。

お前らどうしてる?ツールチェインと環境は?
890デフォルトの名無しさん
2021/06/08(火) 23:20:14.38ID:x/Of6Ttl
rustでOSてもう何回目の話だよ。。過去レスでもあされや
891デフォルトの名無しさん
2021/06/09(水) 00:55:43.69ID:KzEq3JVg
>>889
cargoが-Zbuild-std対応したからビルドに特別なツールは使ってない
rust-analyzerもno_std対応してて特に支障なく動いている
(補完候補にstdが出てくることはたまにあるけど)

環境変数がおかしいというのはどういうこと?
build.rsが環境変数に依存している?
それとも env!() を使っている?
892デフォルトの名無しさん
2021/06/09(水) 01:43:04.13ID:oLsQ5RHC
>>889
https://simchange.jp/post-164095/
ところが、↑のサイトも含めていくつかのサイトでは、日本ではiOSがシェアを
伸ばしていると書いてある。
2020/06 : Android:50.2%, iOS:49.7%
2019/06 : Android:60.5%, iOS:38.8%
2018/06 : Android:60.8%, iOS:37.6%
893デフォルトの名無しさん
2021/06/09(水) 08:17:02.86ID:k36yeEDS
元々の話はMacがM1になって開発環境として終わったという流れから
残るMacの存在価値としてiOSアプリ開発環境がありそのシェアがまだ高い(?)という話だと思うけど
多くのサービスがスマホ専用アプリを作らずにウェブアプリ(PWA)化してる状況ではシェアだけの問題ではないと思うな
894デフォルトの名無しさん
2021/06/09(水) 11:25:52.58ID:oLsQ5RHC
>>893
最後の行、flutterなどのマルチプラットフォームライブラリの登場によって、
ウェブアプリからnativeアプリ型への流れが出来ているという説もあるが。
895デフォルトの名無しさん
2021/06/09(水) 11:27:44.28ID:oLsQ5RHC
>>894
後継のSwiftが出来たのでObjective-Cの人気低下はともかく、そのSwiftも人気低下。
その理由が、AndroidとiOSでソースを共通化したい人が増えたからだそうだ。
SwiftはApple専用だから。
896デフォルトの名無しさん
2021/06/09(水) 12:30:04.46ID:eGaY+zic
lldbでpedaみたいな表示するのってこれが良いかな
便利そうだけど保守されてんのかなこれ?誰かしらん?
https://github.com/snare/voltron
897デフォルトの名無しさん
2021/06/10(木) 06:56:29.59ID:A6ZEEOGF
来週ついにRocket v0.5が出るぞ
安定版Rustで動くようになる
898デフォルトの名無しさん
2021/06/10(木) 09:11:05.37ID:hslWe/Xh
RUSTってORM、Dieselとかいうやつしかねえの?
SQLを明記したいのでJavaでいうMybatisみたいなのをさがしているんだけど、中華の変なものしかない。
899デフォルトの名無しさん
2021/06/10(木) 11:19:36.78ID:vqPt4/VO
Sqlx
900デフォルトの名無しさん
2021/06/11(金) 04:26:27.44ID:tVW+Rdfi
>>897
待ってた!
901デフォルトの名無しさん
2021/06/11(金) 05:32:32.03ID:O0YtPkZC
サーバー側はネイティブコードでクライアント側がwebassemblyで動くとかあるの?
902デフォルトの名無しさん
2021/06/11(金) 15:51:17.70ID:ThZwz5mq
VSCodeアップデートしたら急にDo you trust the authors of the files in this folderとか聞かれてどうしたのかと思ったけど>>823みたいな奴の対策かね
903デフォルトの名無しさん
2021/06/11(金) 23:04:56.42ID:gr7UCFZ6
>>898
Dieselに人が集中してる。
クレートのall-time downloadは200万超だし、
リポジトリのコミットは約4000、closed issueは約1200。
904デフォルトの名無しさん
2021/06/11(金) 23:44:59.89ID:791JEOt2
>>898
rust-postgres 直接使えばええやん
905デフォルトの名無しさん
2021/06/12(土) 05:08:22.45ID:0lbP+PJD
wasmはあらゆる環境で使える汎用コンテナとしてすごい将来性あるみたいだね
906デフォルトの名無しさん
2021/06/12(土) 15:34:21.86ID:jmn9nDiv
>>905
目的外利用だし、そういうこと言っている人がいることは知ってるが、実際にそんなに将来性があるとは思えんが。
907デフォルトの名無しさん
2021/06/12(土) 15:35:41.09ID:jmn9nDiv
wasmはもともとウェブにC++を持ち込みたいというEmscriptenの情熱から
始まったものであって、そんな汎用目的のためではない。
908デフォルトの名無しさん
2021/06/12(土) 15:53:35.18ID:1HODARj2
そのウェブにC++を持ち込むという夢はその後どうなったの?
909デフォルトの名無しさん
2021/06/12(土) 16:29:39.50ID:wX98kbow
ブラウザでDOOMが動いた
910デフォルトの名無しさん
2021/06/12(土) 16:48:34.58ID:L7rjL3/+
zoomみたいなビデオ会議アプリでwasm使ってるってっ聞いた
あとカメラを使った運転免許証認識とか
911デフォルトの名無しさん
2021/06/12(土) 17:34:23.71ID:6kRi062U
当初の目的とかどうでもいいだろ
Linuxだって当初の目的は趣味のおもちゃだぞ
>>907
912デフォルトの名無しさん
2021/06/12(土) 17:38:04.08ID:4jXDkOdS
もしもWebAssemblyとWASIが2008年に存在していたら、Dockerを開発する必要はなかった
ってDocketの開発者が言ってた件だな
913デフォルトの名無しさん
2021/06/12(土) 17:54:20.79ID:jmn9nDiv
>>911
どうもブラウザ外使用を盛んにアピールする人は胡散臭い。
914デフォルトの名無しさん
2021/06/12(土) 18:32:25.93ID:l5AvwX9O
いや、M$の寡占を阻止し正しき未来を創るため立ち上がったとエリックレイモンドが言ってた。
915デフォルトの名無しさん
2021/06/12(土) 20:16:21.66ID:jmn9nDiv
>>914
そいつ人類の中で2番目に嫌いなやつだわ。
一番目はストールマン。
916デフォルトの名無しさん
2021/06/12(土) 20:33:14.57ID:7X99TIl2
>>915
ソフトウェア著作権を否定するあんたと同類だよ。違うのは現行の法律を尊重するかしないかだけ。
917デフォルトの名無しさん
2021/06/12(土) 21:31:34.25ID:Ap+0oKF5
>>912
んなこたない。
2008年にあっても今と扱いは変わらんと思うわ。
結局何らかのコンテナを使うことになる。
OSの件でもそうだが、この界隈は大袈裟にアピールしすぎだわ。
918デフォルトの名無しさん
2021/06/12(土) 21:39:22.31ID:07O/QVIU
>>917
ここでいうコンテナってなんのこと?
919デフォルトの名無しさん
2021/06/12(土) 21:55:04.24ID:LAH8Z0de
Jail、OpenVZ、Solarisコンテナ、LXCみんな早すぎたのだ
920はちみつ餃子 ◆8X2XSCHEME
2021/06/13(日) 03:28:54.62ID:tRZIM+Qs
Java (JVM) で駄目だったのはなんで?
921デフォルトの名無しさん
2021/06/13(日) 03:38:03.93ID:8vbdM5AU
>>915
3番目が気になる
922デフォルトの名無しさん
2021/06/13(日) 10:57:47.53ID:ACaSQ+aI
Istioでの使われ方みたいな事例が増えると思う
luaの代替
923デフォルトの名無しさん
2021/06/13(日) 12:14:09.77ID:CEo6Ln9Y
JVM自体がローカルのシステムでグローバルだったからだろ。
低レイヤーをラップするための上位レイヤーのが互換性効かないものになってるとか、よくある話だわ。
924デフォルトの名無しさん
2021/06/13(日) 22:19:56.20ID:wyOEFD1W
>>916
俺は著作権は尊重する。
尊重してないのはFSFの方。
925デフォルトの名無しさん
2021/06/13(日) 22:54:27.20ID:exUpBE38
じゃあOSSを利用する場合はちゃんとライセンスに従わなきゃな。GPLだろうとなんだろうと。
926デフォルトの名無しさん
2021/06/14(月) 01:49:13.38ID:1vkdQjmk
別に俺はGPLは嫌いだから自作プログラムに紛れ込ましたことは無いが、
GPL自体が自ら著作権を放棄してるな。
「COPYLEFT」 の LEFT = 放棄、左。左翼、共産主義。
「COPYRIGHT」の RIGHT = 権利、右。右翼、資本主義。権利=著作権。
927はちみつ餃子 ◆8X2XSCHEME
2021/06/14(月) 02:06:08.10ID:fvxG9/iR
GPL は著作権の放棄ではない。
その上で自由な利用を保証するという契約をするの。
著作権を放棄してしまったら自由な利用を強制する根拠を失ってしまう。
928デフォルトの名無しさん
2021/06/14(月) 02:54:46.97ID:1vkdQjmk
アメリカ人はめちゃくちゃで、ライセンスと契約を区別したり訳分からんこと
言って、煙に巻こうとしてるだけ。
GPLは、その名の通り、「ライセンス」といっている。
COPYLEFT と自ら名乗っているし、著作権で無いだろう、あんなもの。
929はちみつ餃子 ◆8X2XSCHEME
2021/06/14(月) 02:57:23.52ID:fvxG9/iR
>>928
GPL は著作権ではない。
著作権は作者が持っていて、契約 (の内容) が GPL なの。
なんでそんな簡単なことがわからんのだ。
930はちみつ餃子 ◆8X2XSCHEME
2021/06/14(月) 03:06:36.37ID:fvxG9/iR
著作者は作者として強制できる権利。
強制する内容が「自由に利用すること、自由に利用させること」であることが
一般的に作者が求める強制力ではないよねということを茶化して Copyleft と言っているのであって、
強制力の根拠はあくまでも著作権だよ。
931デフォルトの名無しさん
2021/06/14(月) 03:16:22.76ID:Gk7ZUjpc
あれが、本気で自由と思ってるのか。
頭大丈夫か?
自由じゃないからこそ、言葉だけ自由と名乗ってるに決まってるじゃん。
ようは、不自由なことをやることも、自由といや自由、みたいに皮肉みたいな感じで
言ってるんだろ、彼らは。
それか頭がおかしいかだ。
932デフォルトの名無しさん
2021/06/14(月) 03:41:09.12ID:lTAIWsCW
ハァ~~~~~また固定ハンドルが物申したさベースでデタラメ言ってる


まずライセンスと契約は別物ね
ライセンスと契約を混同するのはよくある誤謬
GPLにおいても、これは契約かライセンスかといった議論は昔からあるから勝手に勉強しとけ
勉強したところでここで発表はするなよ邪魔だから


> 自由な利用を強制する
これも、なんでそうなるのだってくらい愚かしい解釈
「自由」の定義をストールマンとか江添の言ってるそれに委ね過ぎて支離滅裂になってるって気付け?
辞書通りの「自由」ならライセンスも警察も裁判所も要らないから
GPL のポイントは二次的な生産物も GPL であれと要請してるところ
「だからそれを私は自由と呼んでいるんです!」と叫ぶのかな?
日本語勉強しろバァ~~~カ


あと著作権著作権って簡単に言うがこれは国にもよる
たんじゅんなアタマのつくりしてるね


俺なら恥ずかし過ぎて固定ハンドル外してるわ
今に始まったことではないが
933デフォルトの名無しさん
2021/06/14(月) 03:45:31.62ID:A3PFUDNY
>>932
この程度のバカは見飽きたのでもうちょっと
変わったこと言ってくれ
934デフォルトの名無しさん
2021/06/14(月) 04:23:31.00ID:lTAIWsCW
即レスで
恥ずかし過ぎて固定ハンドルを外して
何ら具体的な反論をしないことで完全服従の意を表明しつつ
一方でタダで敗北アクメを晒すわけにはいかないので「バカ。陳腐」という当たり障りのない罵倒も置いておく完璧なレス

のように思えてしまうが、なんの用事もないのにわざわざ安価付けてきたコイツが当人じゃない可能性ってナンボほどあるんだろうか
935はちみつ餃子 ◆8X2XSCHEME
2021/06/14(月) 04:35:49.09ID:fvxG9/iR
>>932
GPL ほどの広く使われているライセンス形態がその程度の理屈の建付けがちゃんとできてないわけないだろ。
詭弁と言えば詭弁なのかもしれんが、お前ごときに突き崩せるほどの安普請ではないわ。
GPL1 のリリース日の時点ではアメリカがベルヌ条約に加盟して無かったから
それでも国際的に通用するように方式主義にも配慮されておる。

中国に対してさえ (実態はわからんが少なくとも法的な理屈の上では) 通用する GPL が「国による」とかいう雑な
理屈で回避できると思ってるのか?
936デフォルトの名無しさん
2021/06/14(月) 05:16:55.41ID:lTAIWsCW
>>935
GPL の建付け (?) の話なんか全くしてないし、回避 (??) する話なんかもっとしてないんだが、一体何に猛反論してるつもりなのだキミは
関係ない話ベラベラし始めることこそ典型的な詭弁だよ(この場合目的が全くわからんが)


>>932に書いた内容といえば
・ライセンスと契約を同じもののように語ってるのが典型的な誤謬であると指摘して
・「自由」という語の使い方が自由過ぎることを糾弾して
・諸々の根拠を著作権に委ねるならその運用は国による要素を多分に含むと示唆している
というこれだけで、これらには返す言葉もないというのが本音でしょう


> GPL1 のリリース日の時点では
これはお前が今突然言い出したことなので元々の話とは全く関係ないが、GPL が当時と同じように理解されて運用されてるのと思ってるならやっぱ単純なアタマのつくりしてるね
937デフォルトの名無しさん
2021/06/14(月) 05:19:57.80ID:LaJq0QyW
GPLスレでやれ、バカ
938はちみつ餃子 ◆8X2XSCHEME
2021/06/14(月) 05:30:15.75ID:fvxG9/iR
>>936
ライセンスは契約だし、 GPL が言うところの「自由」は定義されている。
その「自由」が辞書的な意味とは異なるかもしれんが、 (この場合の) 意味は明白で解釈の幅はない。
「自由」という言葉をあてるのがクソというのがあなたの主張?

著作権の運用が国ごとに違うのは仕方がないが、
GPL の考え方に法的根拠を与えるには他に方法がないのも事実だ。
クソみたいに著作権意識のない国では通用しないから GPL は無力だということが言いたいの?
939デフォルトの名無しさん
2021/06/14(月) 05:45:15.60ID:EO405yGC
スレチ。。。
940デフォルトの名無しさん
2021/06/14(月) 09:29:08.36ID:57P3hnrE
>>922
Goにホストされるって敗北感
そもそもホストはGC言語なのにわざわざそれを封じて縛りプレイしてるんだからアホくせえわ
941デフォルトの名無しさん
2021/06/14(月) 11:54:20.91ID:xr9L9qN8
アホくせえが手段が目的化する奴が多いのよ。言語にこだわるやつってのは。
942デフォルトの名無しさん
2021/06/14(月) 12:02:54.57ID:Gk7ZUjpc
>>938
>その「自由」が辞書的な意味とは異なるかもしれんが、 (この場合の) 意味は明白で解釈の幅はない。
ええ???
943デフォルトの名無しさん
2021/06/14(月) 13:26:47.78ID:7yJrxgpO
スレチせめてプログラミングのこと話せ
944デフォルトの名無しさん
2021/06/14(月) 14:32:30.77ID:ETfeAHFb
>>933,937,939,943
これは恥ずかしいw
945デフォルトの名無しさん
2021/06/14(月) 16:01:14.18ID:aWTkZB4f
こんだけ言われてなんでまだ「ライセンス=契約」で行きたいんだ?
そこが覆ると自分の主張も破綻するから?
まあ難しいところではあるだろうと思うが、「ライセンスと契約は等価じゃない」ってのはあらゆるレイヤで真でしょ
ことOSSにおいては「契約はしてないけどライセンスはされている」という状況が山程あるし、そこ混同するのはやっぱ問題かと
946デフォルトの名無しさん
2021/06/14(月) 16:36:10.82ID:o7Wm2rLl
ライセンスの定義についてはどこで合意が取れてんの?
それともそういうもんは存在しなくて
定義については毎回言い争ってるの?
947デフォルトの名無しさん
2021/06/14(月) 18:32:12.91ID:Gk7ZUjpc
GPLについては、ソース公開しなければならないことについては大量に述べられて
いるが、非公開で良いケースは僅かしか語られず、その場合でも沢山の例外が
述べられていて結局、非公開にするのは茨の道になるようなライセンス。
948デフォルトの名無しさん
2021/06/14(月) 18:48:42.01ID:A3PFUDNY
>>945
じゃあライセンスって法的に何物なの?
949デフォルトの名無しさん
2021/06/14(月) 19:09:41.02ID:WvbRDa7B
GPLの例外条項は結構曖昧で解釈の幅がある
オレオレ解釈は散見されるが最悪争う覚悟は要りそう

あとライセンスとは全く関係無い次元で製品に使うのみで
プロジェクトの開発に貢献していないと晒されたり
950デフォルトの名無しさん
2021/06/14(月) 19:36:33.34ID:BGpTyvuR
GPLと聞いて。
自由については「誰の」自由かを明確化しないと混乱するから省略するな。GPLの自由はユーザーの自由で、それを実現するためにプログラマの自由を制限している。

ライセンスは文字通り「許諾」で、相手の同意を必要としない。契約は相手と自分の同意を必須とするから、GPLみたいに相手の同意を前提としていない仕組みを「契約」とするのは弱い(と思う)。
だからGPLでは著作権を使って、違反者にプログラムを使わせないことを強制する枠組みを用意している。
951デフォルトの名無しさん
2021/06/14(月) 20:31:13.38ID:6p9bp5Dj
ソースコードを公開してもかまわないプログラマの自由を最大化するために作られているんだよ。
逆に言えばソースを隠したがるプログラマのことは考えていない。
952デフォルトの名無しさん
2021/06/14(月) 21:42:01.68ID:OzvaLd6A
>>951

ソースを公開しても構わない連中の意図に背いて
ソースを公開しないプログラムで金儲けしてる連中が
ソースが公開されてる物に独自の拡張を加えて独占する事が往々に起きてるぞ
953デフォルトの名無しさん
2021/06/14(月) 22:24:45.24ID:Gk7ZUjpc
>>949
実際、めちゃくちゃややこしい。
結局、なるべくソース公開させたいんだと悟った。
954デフォルトの名無しさん
2021/06/14(月) 22:41:56.21ID:G5MB7uUL
おまえらrust書けないんだろ
955デフォルトの名無しさん
2021/06/15(火) 01:20:19.29ID:2aICmAxH
rustなんだからせめてMITかApacheの話しろよ
956デフォルトの名無しさん
2021/06/15(火) 12:54:55.77ID:AFCY8yJO
RustでGPLなクレートはほとんどないけどあったらまず使わないな
957デフォルトの名無しさん
2021/06/15(火) 17:22:37.44ID:goBsDW0I
>>956 ワイは別にGPLは気にしないな
どうせGPLなクレート使おうが使わまいがソースコードは公開するから
958デフォルトの名無しさん
2021/06/15(火) 18:41:20.99ID:/MaPmtJg
Rust入門でオススメ書籍ありますか定期
959デフォルトの名無しさん
2021/06/15(火) 19:52:22.79ID:CPCRgALA
ライブラリならLGPLだろ
960デフォルトの名無しさん
2021/06/15(火) 20:51:36.90ID:2aICmAxH
ライブラリにLGPL採用する場合はcrate_type=dylibにすべき?
961デフォルトの名無しさん
2021/06/15(火) 20:59:03.39ID:ic6VniVo
>>958
オライリー本
第2版出てるよ
962デフォルトの名無しさん
2021/06/15(火) 21:24:12.34ID:5dh+WKsO
>ライセンスは文字通り「許諾」で、相手の同意を必要としない。契約は相手と自分の同意を必須とするから、GPLみたいに相手の同意を前提としていない仕組みを「契約」とするのは弱い(と思う)。
>だからGPLでは著作権を使って、違反者にプログラムを使わせないことを強制する枠組みを用意している。

論理が逆転してる。
許諾しない限り著作権により他者はそのソフトウェアを利用できないんであって、その許諾を行うのが許諾契約なわけ。
契約が成立していなければ単に利用できないだけ。
963デフォルトの名無しさん
2021/06/15(火) 22:11:42.99ID:cZWoJhTA
mylibって何のためにあるのでしょうか?
964デフォルトの名無しさん
2021/06/15(火) 22:26:23.96ID:4eHWI+wO
【License】ライセンス総合【利用許諾】
http://2chb.net/r/tech/1266247461/l50
965デフォルトの名無しさん
2021/06/16(水) 07:16:27.91ID:CcbUbI22
>>961
原著2版は来月発売では?
Safariか何かで電子書籍版が早期リリースされてんのかね
966デフォルトの名無しさん
2021/06/16(水) 08:08:02.13ID:FBnPGJqE
GPL(LGPL含む)の問題は関連する全てのコードに干渉すること
GPLと干渉しないコードで固められるなら良いが、現実的には難しい事も多い
この場合例外条項の適用を検討することになるけど一般的な解釈はほぼなく自己責任となる

自分がGPLなコードを使いたくない理由は大抵これ
>type foo.bat
GPLなコマンド -i a.wav -o b.wav
プロプラなコマンド b.wav
>
がGPL違反とか言われててもどうしようも無いじゃない
Linux環境でも実用性を考えるとプロプラレスは難しい。nVidiaがらみとかwineとか
967デフォルトの名無しさん
2021/06/16(水) 09:17:59.87ID:jDDfyj6K
>>966
その例がGPL違反ってどういう意味?
968デフォルトの名無しさん
2021/06/16(水) 10:07:22.47ID:iOI8vAiO
>>966
https://www.gnu.org/licenses/gpl-faq.ja.html#NFUseGPLPlugins

> それはプログラムがどのようにプラグインを呼び出すかによります。たとえば、プログラムが単純なforkとexecでプラグインを起動し、通信するだけならば、プラグインは別のプログラムであり、プラグインのライセンスはメインプログラムになんの要求もしません。
969デフォルトの名無しさん
2021/06/16(水) 11:05:57.56ID:51hxO3pa
>>968
それはプラグインとして解釈できるかがポイント
>>966の例だとGPLなコマンドとしてffmpegにプリプロセスさせるようなケースで
「GPLなコマンドが無かったら機能しないのだからメインの一部でありプラグインではない」
などと主張されたら自分では反論できない
970デフォルトの名無しさん
2021/06/16(水) 11:54:54.60ID:jDDfyj6K
>>969
そんな主張はFSFもしてないけど誰がしてるの?
971デフォルトの名無しさん
2021/06/16(水) 11:56:22.89ID:0OhzW8Bw
ぼく
972デフォルトの名無しさん
2021/06/16(水) 13:02:13.05ID:ZyaCpIhY
>>970
GPL警察・・・はともかくとしてもライセンス文やFSFの主張と矛盾が生じない実装であることを証明できないとリスクが高い

>>968
>「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか? (#MereAggregation)
には
>逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズムです。
>ですからそれらがコミュニケーションのために使われるときには、モジュールは通常別々のプログラムです。
>しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、
>それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
とも書かれている。別プロセスとして利用しているからGPLの影響を受けないとは限らないと読める

あとGPLにもかかわらずプロプラのライブラリ等を利用する機能があるアプリはプロジェクト自体は問題なくても
運用時にGPL違反になる可能性は非常に高い
973デフォルトの名無しさん
2021/06/16(水) 13:17:01.96ID:5odmAoP3
ここがライセンススレですか
974デフォルトの名無しさん
2021/06/16(水) 13:26:13.58ID:bmvqoYgA
前にも同じような流れになった事あるよな
同じバカかな
975デフォルトの名無しさん
2021/06/16(水) 13:44:16.01ID:afK0Tn+I
>>964が示されてもまだここで続けようとするからな
続きはあっちに書きそのURLをこのスレに書けば
続きに興味がある人はそれを見るのにこのスレで続けようとする
このスレでマウントをとること自体が目的なんだろう
976デフォルトの名無しさん
2021/06/16(水) 15:32:36.57ID:HrXzCrOv
ライセンススレを知っている人なら判るけど論理的な議論にならないからな
条文には「~~」と書いてありFSFの解釈は「○○」だから××と考えるのが妥当
みたいな流れは見たことないし。ソース無しで俺解釈を唱える人はいるけど
977デフォルトの名無しさん
2021/06/16(水) 16:40:31.58ID:XWzkMsh/
まさに彼にふさわしいスレじゃん。
978デフォルトの名無しさん
2021/06/16(水) 17:11:11.66ID:QlN27RbC
        ,r"´⌒`゙`ヽ
       / ,   -‐- !、
      / {,}f  -‐- ,,,__、)
    /   /  .r'~"''‐--、)
  ,r''"´⌒ヽ{   ヽ (・)ハ(・)}、
 /      \  (⊂`-'つ)i-、
          `}. (__,,ノヽ_ノ,ノ  \  
           l   `-" ,ノ    ヽ   頼む、どうか彼らを許してやってくれ彼らはゴリラなんだ
           } 、、___,j''      l
979デフォルトの名無しさん
2021/06/16(水) 23:04:16.59ID:2zUKvOQT
>>970
俺は、このスレに書いた人とは別人だが、俺もそういう主張を読んだことがある。
例え別プロセス、別コマンドであっても、そのコマンドがなければそのアプリ自体
が全く成り立たない場合には、GPL感染すると。
プラグインや拡張機能ならセーフだが、GPLなプログラム無しには基本機能さえ
成り立たないようなアプリやOSは、GPL感染してアプリやOSもソース公開しなく
てはならないと主張されていた。
980デフォルトの名無しさん
2021/06/16(水) 23:12:41.99ID:cIjelt3H
1.53.0 pre-release testing | Inside Rust Blog
https://blog.rust-lang.org/inside-rust/2021/06/15/1.53.0-prelease.html
981980
2021/06/17(木) 00:25:15.75ID:NvYoNP9C
たてまいた
Rust part11
http://2chb.net/r/tech/1623857052/
982デフォルトの名無しさん
2021/06/17(木) 00:58:03.03ID:Rm7vvv8R
>>979
ライセンススレでやれって >>964
そんな主張を誰がしてるのかと問われてるのに
誰が言ってるのか不明な話をしてもしかたないだろ
983デフォルトの名無しさん
2021/06/17(木) 01:16:14.81ID:ZHO1SOin
GPLなクレートがかなり排除されてるRustはライセンス談義に最も向かない言語だろう
984デフォルトの名無しさん
2021/06/17(木) 03:00:35.86ID:hZA4Axz4
twitter見ていて分かって来たことだが、GPLを支持している人は、大体、
ほぼ全くプログラムしないか、理系でもなければ、物づくりとは全く接点が
無い人が多いようだ。プログラムしてもちょろっとだけ。
俺が知る範囲内では哲学科出身の人がやたらとGPLを推進しようとしていた。
2ch/5chだとそれが見えてこないので話がややこしくなる。
985デフォルトの名無しさん
2021/06/17(木) 07:53:01.41ID:Bp52a2Ld
どこを見てもそんなの見えてこない
986デフォルトの名無しさん
2021/06/17(木) 08:00:10.18ID:ukuNCHw3
>>983
GPL/LGPLと無縁のマルチメディアデータ処理関連のクレートを教えてくれ。それ使うから
歴史的事情もあってlibavcodecをはじめとする実績のあるコードはGPL/LGPLばかりなんだよな
特に動画は特許とGPL/LGPLで板挟み
987デフォルトの名無しさん
2021/06/17(木) 08:08:54.07ID:q1AaV+h7
>>986
プログラムを配布しなければGPLだろうがなんだろうが関係ないだろ。
988デフォルトの名無しさん
2021/06/17(木) 09:36:20.47ID:ZHO1SOin
>>986
動画も音声もどうせ特許で真っ黒なんだからどうでもいいじゃん
989デフォルトの名無しさん
2021/06/17(木) 13:04:16.09ID:vro6SqnC
所有権を確認するためのデバッガ教えてください
990デフォルトの名無しさん
2021/06/17(木) 13:25:32.13ID:zdBr0PGw
>>989 rustc
991デフォルトの名無しさん
2021/06/17(木) 14:12:56.21ID:hZA4Axz4
GPLを推進してるほとんどの人はプログラムほとんど書いたことない人。
これは本当の話。プログラミングがどういうものか分かってない。
大量の資料を見て沢山実験してやっと方法を見つけてコードに直している
という苦労や努力、時間が理解できてないからGPLが社会を良くすると
勘違いしている。
992デフォルトの名無しさん
2021/06/17(木) 14:17:07.72ID:hZA4Axz4
結果のコードは30行とかでも、それを見出すのに非常に大量の時間を
かけて、googleで検索し、StackOverflowのQ&Aを10個以上読み、
書いてある通りにやっても大部分が失敗し、JavaScriptの公式HPに書いてあるとおり
にやっても出来ず(書き間違いがあることが多い)、実際に動いている例を調べたり
して、公式HPの間違いを発見しても面倒だから報告せずに、やっとの思いで
何日もかけて見出した30行のコードが、GPL感染して世界中に広まっていき、
金持ちのボンボンがそれを我が物顔で使う。そんな社会になってきている。
993デフォルトの名無しさん
2021/06/17(木) 14:25:35.66ID:ZHO1SOin
>>992
エッセイ書きたいならTwitterでやれ
994デフォルトの名無しさん
2021/06/17(木) 19:47:14.00ID:9b5fCkeQ
        ,r"´⌒`゙`ヽ
       / ,   -‐- !、
      / {,}f  -‐- ,,,__、)
    /   /  .r'~"''‐--、)
  ,r''"´⌒ヽ{   ヽ (・)ハ(・)}、
 /      \  (⊂`-'つ)i-、
          `}. (__,,ノヽ_ノ,ノ  \  
           l   `-" ,ノ    ヽ   頼む、どうか>>992を許してやってくれ彼はゴリラなんだ
           } 、、___,j''      l
995デフォルトの名無しさん
2021/06/17(木) 19:59:14.59ID:Jy0yNCu6
サウイフゴリラニ
ワタシハナリタイ
996デフォルトの名無しさん
2021/06/18(金) 09:59:32.45ID:ZlIKBEDk
>>981
おつでーす
997デフォルトの名無しさん
2021/06/18(金) 10:07:49.32ID:bpKpz6fn
Rust 1.53きたけど、非ascii識別子って前から使えなかったっけ???
998デフォルトの名無しさん
2021/06/18(金) 11:41:40.97ID:qNJOvBlW
前はunstableでnightlyでしか使えなかった
999デフォルトの名無しさん
2021/06/19(土) 01:08:26.25ID:3FFA7ImF
埋め
1000デフォルトの名無しさん
2021/06/19(土) 01:08:36.16ID:3FFA7ImF
埋め
10011001
Over 1000Thread
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 77日 3時間 30分 32秒
10021002
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php

ニューススポーツなんでも実況



lud20250721093605ca
このスレへの固定リンク: http://5chb.net/r/tech/1617367084/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「Rust part10 ->画像>2枚 」を見た人も見ています:
なんUSTR部
なんUSTR部
なんUSTR部
なんUSTR部
RYUTist解散
SUPER GT+
catch surf
TRAP MUSIC
SUPER GT+
なんUSTR部 ★2
SUPER GT+
SUPER GT+
Rust part26
初心者Vtuber
NUMBER SHOT
sui part1
Rust part27
Rust part22
Sproutsスレ
Rust part28
Rust part15
Rust part29
Volto Oscuro
Nexus 9 Part19
汁@Shirutaro_
Music Thread
SUMCOとサムコ2
DONGURI QUEST
Uber Eats 邪魔
Castle Burn
Duelyst Part7
Nexus 5X Part7
GWやしRUSTやろうや!
OnePlus Part93
LuckyFes part1
OnePlus Part88
Rustスレ #3478
Supreme Part.2
Oneplus Part.8
GWやしRUSTやろうや!
VOI SQUARE CAT
Supreme Part.2
berghaus Part.1
24bit RISC CPU
nudist junior
UberEatsを哲学する
OnePlus Part81
GWやしRUSTやろうや!
OnePlus Part86
OnePlus Part92
ZOZOUSED part4
OnePlus Part25
OnePlus Part15
FRUITS ZIPPER専用
OnePlus Part121
Nisus Writerを使おう
Suchmos part 39
zatudan e sure
Nexus 6P Part22
OnePlus Part32
OnePlus Part41
OnePlus Part16
Superfly part85
Nexus 5X Part28
OnePlus Part68
20:35:13 up 118 days, 21:34, 0 users, load average: 19.73, 20.35, 28.27

in 2.2657539844513 sec @2.2657539844513@0b7 on 081409