Rust part10
レス数が1000を超えています。これ以上書き込みはできません。
前スレ：
「まともにrustでc++並の開発速度で製品作ってから言えや」
って深い言葉だ。 積極的に使えば欠点が良く理解できるようになるからね。とても有効だよ。 費用対効果を見積もるにも実際のプロジェクトで使ってみるのが一番。
まあ俺は巻き込まれたくはないが。 C++使ったこと無いけど趣味開発だしrust使うわ 秀和システムのキンドル本って、あれはセールで半額になったりするもんなの？ C/C++は適当に動かすだけなら簡単だろうけどさ
ヘッダーファイルの作法、makeファイルの作法、古いコンパイラやリンカへの配慮・・・・みたいな独学困難な領域が多くあるからな そういう人は低レイヤーを触るのがそもそも間違ってる。 cmakeやmesonやIDEの支援があると言ってもやはり敷居は高いわな
だがrust使うにせよC/C++のライブラリ使ったりドキュメント読む羽目になるのでやはりある程度相互運用の知識は必要 オープンソースの makefile は無意味なごみが集まってるから読みにくいだけ。
特に gnu makeがおかしい。
gnu 系はヘッダファイルもソース本体も汚い事が多い。 その類のmakefileはautoconfとautomakeで自動生成されるもので、人間が読むものじゃないでしょ Rust の世界だけを考えるならビルドプロセスは Cargo に書いておけばそれで OK だけどね。
全て Rust だけでは書けない場合には従来のツールチェインに更に Cargo が加わって余計にややこしくなってるとも言える。
https://xkcd.com/927/
ツールが汚いのは現実が汚いからだよ。
汚い現実から目をそらして綺麗なルールの中に閉じこもっても、
汚い現実が消えてなくなるわけじゃない。
Makefile が不愉快なら Makefile を使わないプロジェクトを増やすのを頑張るこったな。 rustだけのプロジェクトでもcargo-xtaskを使ってたりするからcargoだけですべてOKかというと微妙だけどね
タスクランナーやビルドのポストプロセスなんかのサポートって予定されてるの？ そういうのあるの知ってるけどcargo本体に取り込む予定があるかが気になってる
グローバルにその手のツールインストールするとバージョン固定が難しいので
npmみたいにlocal installできるならそれでも良いけど 対応は結構してるわな。ただここの連中はこれくらいもできなさげ。
ttps://qiita.com/mutuya/items/f00a5b99a3f047dc3cb3 >>30
マルチプラットフォームで単純なmakeより複雑なことをしたいときには使っている。ただ大抵の場合makeでいいんじゃないかとも思う。 >>22
ところがそのautoconf系そのものがそもそも汚い。
そして、autoというのは真っ赤な嘘であることが知られている。 たまにCMakeが無いとcargo installがこけるツールがあってげんなりするわ m4マクロで書くというのはそろそろやめにしてもらいたい >>30
既定のタスクをそのまま使う分には便利だけど、ちょっとアレンジしようとするとめんどくさかったという感想。
単に慣れの問題かもだが、gnu makeのMakefile中でcargo叩く方がやりやすかった。 Rustバイナリにユーザー名が埋め込まれる脆弱性が発見された ユーザー名といかコンパイル時のソースのフルパスね
ホームディレクトリ配下にソースがあるならログインユーザー名が含まれる
あと発見されたのは最近ではなかったはず それを消すためのオプションは数年前から付いてて
そのオプションがうまく効かないケースがあるってバグが修正中なはず
最近あったのは単にその話を記事に書いた人がいるってだけ ディレクトリ名にマイナンバーを入れてる人がいたらどうすんだまったく ディレクトリ名につい「クソプロジェクト」とか入れてるやつはいるだろ ていうかログインユーザー名に実名いれるとかバカなんじゃないか fuck_you_cplusplus とか普通にありそう Linusが吠えた! ─中指立てて「NVIDIAは世界最悪の企業」
https://gihyo.jp/admin/clip/01/linux_dt/201206/18
それはそうとして、Rustの（Goもだが）「..」が
begin〜lastの意味ではなくて
begin〜last+1なのは
コメントに「arr[0..3]」とか書きたい場合に地味に困る >>42
ネタにマジレスするけどマイナンバーはただの概念で
国民識別番号は国のサーバーに有る。
>>50
last+1って何？ ..は[begin, last)だぞ。
左閉右開半開区間はPLじゃ一般的だけど。 >>51
begin〜last すわなち [begin, last] をRustで書いたら
begin..last+1
になる、という意味やったｻｰｾﾝ、
しかしコメント内に現れた「a..b」は、Rust式に[a, b)と解釈すべきなのか、
それとも伝統的な[a, b]解釈とすべきなのか
というのがそこはかとなく疑問が…… 同じことは「=」と「==」（代入と等値）の使い分けを
コメント内にまで持ち込むべきかどうかという意味で
昔から迷う感じだったものがRust（やGo）の「..」のせいで悩みの種が増えたは！ >>52
Rustコード中ではbegin..=lastって書いたほうがいい（>=rust-1.26.0）
知ってたらすまん
>>53
Rubyもそうだぞ pythonもじゃないか？
C系のfor(int i=0;i<5;i++)の終了条件に合わせてあるのかと思う 最後の要素を意味するときは last で、
最後の要素のひとつ後を指すときは end を使う習慣があると
どこかで見た覚えがあるんだけど、
別の言語だったかもしれないしどこかの数学分野だったかもしれない。
うろおぼえでスマソ 既存の言語でも a..b が [a,b] になるもの、[a,b) になるものが混在してたこと、
また、見た目で意味が明確にわかることから a..b と a..=b を採用したという経緯だった気がする エラーそのまま貼らないとわからないわ
と言うか頭からやりなよ あ、すいません
randのバージョンを最新版のものにしてました
チュートリアルで指定されているバージョンにしたら動きました
失礼しました 乱数なんて超基本的なライブラリが
コンパイル通らないぐらいのAPI変更を簡単にやってしまうなんて大丈夫なのかこの言語 この場合は言語の責任でもないしそのためのcargoだし でもせっかくこういう体験したのであればソースの方を直すのも正しき甲殻類な気がするな 最近使ってないけど
randってなんか使いにくいAPIだった気がする マシにする為だろうが一度決めたAPIは変えない
それがC/C++界の掟じゃないのか？ 絶対に変えないようにした結果かえってひどいことになってるイメージ 普通は破壊的仕様変更のときはメジャーバージョン変えそうなもんだがバージョン0だからな バージョン0のうちは破壊的な変更もし放題ということか >>74
deprecatedアトリビュートで出せるよ Microsoftがプログラミング言語「Rust」への支援を強化
https://news.yahoo.co.jp/articles/d9e8b5acb96920789bb4364951481f074bfd93d8
visual rustとか出さないでよね…
>>75
だよねえ
どのバージョンで変えるか警告はするよねえ んでバージョン指定変えてみたら
get_rangeの引数が最小、最大+1の２つから最小..最大+1の範囲リテラルに変わったのね
カンマを..に一ヵ所変えるだけだったから修正自体は対したことなかったけどオーバロードがあればもっと緩やかな改変が出来るのだろうか？
ゼロコスト抽象化の方針上仕方ないのだろうか？ >>77
そんなしょうもない変更の為に互換性破壊したのか >>78
..= が使えるようになったとあるのでインターフェースの改善ではあるのでは
あと破壊的変更はこれだけではない
https://rust-random.github.io/book/update-0.8.html マイナーバージョンが上がるのでも結構変わると言うことか 誰かも言ってたけどこう言うのは標準ライブラリで整備してほしい所だあな 乱数は用途によってアルゴリズム使い分けにゃならんからなぁ
Cのrandはまぁ使えないとしてC++のrandomまで行くと重い randの設計が安定しない現状でstdに入れるにしても
かなり限定されたサブセットしか入れられないのでは それで十分だろ。
メルセンヌツイスターとか必要な場合は各々入れたら良い。
手軽な乱数を必要とする場面は割とある。 メルセンヌ・ツイスタ、MT19937 を使っているのは、Ruby ぐらい
他の言語は、低品質 一瞬信じかけたけど、pythonもboostもmtだったわ >>85
直近でThreadRngやRngも破壊的変更されてて
乱数生成器の種類を充実させるとかそういうレベルにすら達してないのよ 一部のプログラミング言語では、デフォルトの疑似乱数生成器としてメルセンヌ・ツイスタが
標準ライブラリに取り入れられている。そのような言語の例として、 Python,[2][3] Ruby,[4]
R,[5] PHP,[6] MATLAB, C++[7]（C++11から） がある。 オライリー調査で明らかに--Go、Rust、Ruby、Dartに関心高まる - ZDNet Japan
https://japan.zdnet.com/article/35169143/ 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です すいません
とほほのRust入門見て解決しました
type_ofを関数として定義しないとダメなんですね
https://docs.rs/typed/1.0.0/typed/fn.type_of.html
にページがあったので組み込み関数があるものだと思いこんでたら
そういうものは存在しなくて,type_ofの関数を定義しないとダメだったようです
kindleで入門書を購入したのですがそこが省略されておりはまりました
失礼しました 乱数ってxorshiftとかxoroshiroもあるわけで
まぁアルゴリズム固定は難しいでしょう no_std環境も考えるともし一つ選ぶならMTよりxorshiftかなぁ。Rustの方針に合わないから入ることはないだろうけど。 APIをどうするかどこまでリッチにするかとかも難しいんだろ xoroshiro1024がないんだよね。
>>95
```shell
rustup doc --std
``` JavaScript／TypeScriptランタイム環境「Deno 1.9」がリリース、パフォーマンス向上に寄与する機能追加など
https://codezine.jp/article/detail/13970 >>100
メモリの確保に失敗したくらいでpanicはしないが
alloc::alloc::Allocatorの一部メソッドはpanicするから
no_core上にpanicしないアロケータ実装すればよさそう。
コンパイル遅いのはキャッシュするしかない。 結局kernelやるならunsafeつけまくりにしかならんだろ。
そうするとなぜrustで？という事になる。 >>102
その「panicしないアロケータ」を使った Vec やらなんやら全部実装しなおさないといけなくならない？ >>104
といっても変えるのはnewとかくらいで大半の実装はそのままもってくればいいんじゃない？
まあパッチ投げてる人もそこは作業量多いとは言ってるけど。 >>104
Vec等のコンテナにはtry_reserveとかのメモリ割り当て失敗でエラーにする関数用意されているから
メモリ割り当ての失敗だけが問題ならliballocの使い方を変えるだけでよいのでは
他にpanic要因あるならだめだけど
ちなみにnewはメモリ割り当てしないから変更不要 ある種の「コンテキストに対するunsafe」をつけて回らなきゃ無理。
でもってそれはmoonshotだって言ってるわな。
https://lkml.org/lkml/2021/4/14/1140 特定の関数が割り込みのコンテキストから呼び出されたときにコンパイルエラーにすることは
今の言語機能では不可能という話か >>107
role orientedな言語でコンパイラが特別扱いする
コンテキストを指定できれば実現できる、
ここまで考えてだからmoonshotなのかと。 知らんがな。どうしてもrustでkernel作りたいってやつに言えや。 Linux のカーネルはカーネルとは言ってもかなり巨大なので
現状の Rust でも採用可能な箇所もあるんでないの。
知らんけど。 >>112
だからその考えでドライバーならということで始めたら上記の問題が出てきたってところだよ。
何周遅れてんだよ。 グーグル、Linuxカーネル開発における「Rust」採用の動きをサポートする考え
https://japan.zdnet.com/article/35169455/
利用が進めば問題点も見えてくるし何らかの対策は追加されるだろうな linusすごいな
Rust関わってる人全員子供扱いかよ いや、これrustでkernelに関わろうとした人たちが低レイヤーのこと、あまりにわかってなさすぎだろ。。
これ、ほぼ素人の俺でも気づくような内容だぞ C++でもコンテナに値を追加しようとすると、メモリー不足で追加に失敗
する可能性があるが、それをいちいちチェックする人はまず居ないだろうな。
デスクトップマシンでそれに失敗する可能性はとても低いけども。 例えば、
std::vector<int> v; // 空の動的配列を生成
for ( unsigned int i = 0; i < 100000000; i++ ) {
v.push_back(i + 100); // 末尾に i + 100 という値を追加
}
とした場合、環境やマシンの状態によってはメモリー不足で失敗することは
あるだろうが、これをいちいちエラーチェックする人は少ないだろう。 >>116
https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html
歴史的背景はこことか見ると書いてあるけど、処理系の初期開発で想定されていたほとんどの開発者はallocation errorから回復する必要がないから、あえてそういうAPIデザインにしたと
カーネルはその「ほとんど」から外れる用途だからlinusは当然今のAPIじゃダメだと釘を刺す
だからallocator_apiその他の安定化が急がれる、それだけの話じゃないの？ linusへのレスポンス読んだ？
allocについては問題なのは認識してるけど
開発スピード上げるために今はliballoc使っていて
そのうち独自の物に置き換えると言っている pure rustでカーネル作ってる人いるんだから
原理的に不可能ってわけでもないだろ allocまで全部作り切ってからパッチ投げてLinusに却下って言われたら目も当てられんしな。プロトタイプの段階でこまめに出すのはいいと思う。 >>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)で失敗する可能性はとても低い。 N88-BASICでは、読み込みモードでファイルを開く時、
open "ファイル名" for input as #1
と書いていたが、ファイルが存在しないとここでエラーになって
アプリが終了していたことを思い出した。
Perl、Ruby、Pythonなんかは、全て基本的に同じ方針だと思う。
その流儀とRustでのメモリー不足時のpanicの方針も同じと考えていいだろうな。 >>121
そう、それだけの話。でもそれだけの話がここでは恐ろしく通じない。 >>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デザインに問題があるみたいな話出てるの？ >>125
> if ( (ptr = new char [サイズ]) == NULL ) { // (2)
C++ は new も vector::push_back も bad_alloc が飛ぶ。ふつうの new は nullptr 返さない。 てかアロケータの動作がどうのってLinux Kernel関係あるの？
ベアメタル用途全般が該当すると思うけど >>129
そういえば、言葉は忘れたけど、関数宣言の行に、その関数の中でどういう
例外が起きる可能性があるかについてのthrows を書くかどうか、書くべきか、
省略しても良いか、などの違いが色々あって、どういう言語仕様にすべきかが
結構問題になっていると聞いた。
すべてを書くと多くなりすぎるし、全く書かないのも問題だとか、そんな話。
なんという言葉だったかな。 allocatorがエラーを返さずに例外を上げる挙動にRustの標準ライブラリ的なもの(コレクションとかスマートポインタとか？)が依存していて、
それはLinuxカーネル的には許容できないからそういうコードをそのまま持ち込むなよ？ということでしょ
Linuxカーネル上のC言語はそもそも標準ライブラリとか使わないし
メモリ確保もmallocじゃなくてkmallocというカーネル内独自関数使うし
ここ見ると
https://medium.com/nttlabs/linux-kernel-module-with-rust-d5363c2f9085
array: vec![0;32] で kmalloc が呼ばれるみたいだね
でもこれLinuxのカーネルモジュールのコードとしてはそこでエラーチェックが必要になるのかね？
もしくはkmallocに失敗したらそのモジュール自体が自動でアンロードされるとか
でもアンロードされるときに後処理とかしたいかなとかいろいろ考える必要はありそう >>131
動的例外仕様 (dynamic exception specification) のことか？
https://timsong-cpp.github.io/cppwp/n3337/except.spec
送出される可能性のある例外を記述する仕組みだったが、役に立ってなかったので C++17 で廃止された。
(例外を送出するかしないかだけを指定する方式が残された。)
C++ の仕様では例外を送出しないという指定を付けたところを例外が通過しようとしたら
std::terminate が呼ばれて異常終了扱いになるという、実質的な assert なんだわ。
静的な検査をカッチリやってくれるわけではないんで、
カーネル記述みたいな文脈では使い物にならんな。 linuxだろうとwindowsだろうと普通のカーネルはそうだろ。
よっぽど特殊用途のOSならどうかは知らんが。 >>133
なんか、Javaにおいて、throwsに創出するすべての例外を書く仕様にしてみたら、
地獄のように沢山書かなくてはならなくなって困り、
関数プロトタイプ宣言の直後の throws()の中に
「書く必要のある例外」と「書かなくても良い例外」
の違いを設けることにした、この板で聞いた。 >>135
「OutOfMemoryError」例外は、throws に明示しなくて良いことになった
とWikipediaで見た記憶が有る。 >>135
検査例外と非検査例外のことだな。
例外の便利なところは大域脱出が出来るところで、例外を捕捉する箇所と発生する箇所の間では例外のことを忘れられる点。
発生しうる例外の伝播を明示しないといけないのだと返却値で返す形にするのと差がない。
例外を使っていると異常系だということが見た目に分かり易いってくらいのもの。
Java が明示しなくてよい例外という分類を設けたのは明示しなくてよいというだけでなく捕捉もしなくてよいということでもあって、
どのように使い分けるのがよいかは諸説あるけども、非検査例外は
・ 捕捉したところで回復できないもの
・ そもそもその例外を発生させないようにすべきもの (実質的には assert)
というのがおおよその共通認識になっている。
メモリ不足は回復不可能なので非検査例外に分類されているが、
「Java のレイヤでは」回復不可能という話であって、
Java では低レイヤを書かないという前提があるからこういう決め打ちが出来る。
低レイヤと高レイヤでは前提が違ってくるから同じようにはいかんのだ。 >>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」なのでプログラマが対処することが難しい例外に分類される。 低レイヤでも高レイヤでも使うことを考えたらやっぱ例外という仕組みは使いにくいっつーことだな。
カーネルを書くにあたって Rust が (現状では) ベストというわけでもないだろうけど、
比較的可能性がある選択のひとつではあると思う。
どうせ標準ライブラリのフルセットを使えるわけではないのは C でも同じことだし。 Rubyなんかでファイルオープンする時にはエラー発生チェックをしなくてもよくて
エラーが発生するとpanicする。これは簡単なプログラムでは便利。
そしてbegin,rescue,endではさめば、panicせずにエラー処理することも
出来る様になっている。これはtry,catch構文と発想は同じ。
でも、読み書き用の2つのファイルをオープンして読んで加工して書き込む
ような時、catch文でどっちのエラーか区別したりするのは面倒といえば面倒かな。
C風だと、fopen の行で処理できて分かり易かったのに。 >>139
でも、リストに追加したときにメモリ不足になっても、例外機構でしか
エラーを補足出来ないのは面倒だな。 ttps://github.com/rust-lang/rust-bindgen/commit/0e25962c4e69aef647e7275fa7bc7545dbb8cd0b#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759
コロコロ変わってその度に置換するスクリプト書いてるんだけど、
二ヶ月くらい音沙汰ないからそろそろ名前くらい安定してほしい。 rustってそんなにいいか？
任意の場所でfreeできるcとは違って
ブロック抜けるタイミングでしかメモリ開放されないんだろ？
rustっていらなくなってもブロック抜けるまではヒープメモリ保持しないといけないってことなの？ そんなに良くないからキミはもっとcを頑張ったほうがいい
cを頑張ってc++にも手を出して頑張って
気が狂いそうになるのを覚えてからもう一度来たらいい >>144
lifetime内であれば手動で早期開放できるんですね
お世話になりました vectorにpushしながらその要素の可変参照を返すようなメソッドってあったりしますか？ お前らの用途だったらgoで十分だろと思うことが多いわ。
ファッションでやるってのも悪くはないが。 rustではunsafeを多用するのは良いことですか？ >>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に触れないからご注意を >>152
>蛇足だけどyが生きてる間はvに触れないからご注意を
蛇足ではない気がする
push時にその要素のmut refを必要とするような書き方は避けたほうがいい Rustに比べたC++の良さは雑に書けるところだって気付いた
やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ >>155
いいところに気付いたな
Rustは一般プログラマーには無用の長物だ 段階的に直していく方法と最初から設計で硬くしておく方法があると思うが
rustが念頭に置いてるのは明らかに後者。これがいいのか悪いのかは議論の余地がある。 型が強いからリファクタリングしやすいという意味では段々直していく方法に適しているとも言えると思うが >>158
型の強さがある意味で強すぎて、メモリ解放のタイミングまでキッチリあってないと無理なんだが。
ちょっとしたリファクタリングするにもかなり大域的変更になる。 >>155
雑に書いた脆弱性のあるバイナリを世に出さなきゃそれでもいいんじゃね >>160
何言ってんだこの馬鹿
Rust謹製なら脆弱性が無いとでも思ってんのか？ つーかRust以前はどうしてたんだよって話ｗ
流行りのもんに飛びついてそれ以外見えなくなってる典型 いつものレイヤーとかスコープを
ごちゃまぜにする思考が乱雑な人でしょ まあ、C/C++が危なかろうが、自分のやりたい計算をするだけみたいな用途には向いてるよな
どうみても簡単で早いし・・・・ >>155
C/C++は雑に書けるというより、Rustが想定してないでけで
本当は安全なプログラムも思った通りに書くことが出来る。
RustはRustが想定している範囲内でしか書けないので面倒なことになる。 >>167
職人さんはさまざまな危険な道具を、十分安全に使う。
Rustは、「危険だ危険だ」と言って、危ない道具を使わせず
予め「刃(やいば)を抜かれた」道具の使用を強制する。 AIの機械学習は計算が重いのに言語としては遅いところのPythonのAIは遅くはない。
なぜなら計算部分はC/C++で書かれたライブラリを呼び出して使ってるだけだから。
同様にRustがベンチマークで遅くないのは、実はunsafeモードで書かれたライブラリ
を使ってるせいもある。だからそのベンチマークだけでC/C++と同程度の速さ
であることの証明にはならない。 >>169
具体的に何のベンチマークのことを言っているの？ unsafeがライブラリに隠蔽されていてかつ性能が出ることはRustのコンセプトが正しかったことの証明になるのでは？ 今月のWEB+DB PRESSに載ってる簡易的なRDBMSをRustで実装する記事結構いいぞ
RDBMSの仕組みを学ぶことが主眼でRustの解説は最低限なんだけど
Rustでよく使うパターンが 「じゃあC++使えばいいよ」で済む質問を何度投下すれば気が済むのか >>173
リトマス試験紙なんよ
C++で苦労した奴は文句は言わない。Rustが何をしてくれようとしてるのか分かるから。
C++ニワカは文句を言う。Rustが何をしてくれようとしてるのか分からないから。 大半の人は、C/C++で苦労も何もしてないだろう
何が危ないのかも理解しないまま、危険なコードや穴の空きやすいコードを書いてるだけだ C/C++でメモリをぶっ壊して数日絶望するところまでがチュートリアル >>178-179
この人たち未だにC++でnewとかdelete多用してるかそれを通過儀礼のように捉えてる人たちだよね
こえ〜
よくある職場の老害像そのものじゃん さすがに日常ではないかな……
構造体の初期化にmemset使うようなC言語上がりのやつはどうだか知らんけど 毎日のようにRustスレで繰り返し同じ事をグチグチ言ってる自称C++使い達はよっぽど暇なんだなぁって思う c/c++でそんだけ壊れるならrustでもunsafe使ってぶっ壊れまくるだろ。。
エアプ丸出しすぎるわ 引数チェックのないライブラリ等で引数を誤ったりすると
パッと見正しく見えるのでかなり面倒なことになる AddressSanitizerを使ったことのないものだけが石を投げよ 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言語は全く流行ってないようだ。 Python>Java>=JS>C++>>>>Rust >>190
逆にそんなマイナーな言語なのに書籍が出たりtwitterでRustとWasmが
対になって出たりしてたのか。
Rustを試してる人は書籍や雑誌記事を書いて食っていくかか、難しくて新しい言語
を知ることで自分の社会的評価(?)を上げようとしているのか。 >>191
なんかかっこいい嫌味を言いたいみたいだけど
意味不明ですべってるぞ >>161
雑に書いたコードだって自分で言ってんだろボケが なんか無駄なところに手を出しちゃったみたいになってる若い人が発狂してんのかね。
別にrustで学んだことは無駄にはならんよ。
現場でrust強要するのはクソだが。 C++ニワカのLinusはpanicは認めないと言う話をしてるのにアロケーターだけの問題だ
「それだけでしょ、分かってるやつ居なすぎ」とまとめる
範囲外のインデックスアクセスでもpanicするし、Debugなら整数のオーバーフローでも
panicする（なぜかReleaseだとpanicしない）とんでもないアホの勘違いはJavaを持って
きて検査例外と非検査例外の話をし出す。せっかくResult/OptionがあるのにRustの文化と
なっているpanicを通常は捕捉しないと言うものをKernelに持ち込むなと言う話。
範囲外アクセスで即座に既存のC/Kernelならレジスタを保存してダンプするような
Segment fault例外トラップなどが働くのに、panicでスタック巻き戻し実行が起こるのは
絶対的に受け入れられない言うとる
Cの悪名高きsetjmpや、C++のRTL/動的例外テーブルの議論を見てるようだ
検査例外と非検査例外の話をし出すアホはもう来るな ++うんこ華麗にスルーして、やっぱリーナス見る目有るわ神だろ 別にそこまで褒めることでもないんだけどね。。
ttps://lkml.org/
の他の議論に比べて明らかに議論のレベルが低いわけで。。 >>199
なんか何言ってるのか分からない部分が有るな。 js-sys見てたらJavaScript側の型の継承関係をDerefで表現しててびびった
こういうの普通なん？ >>201
歴史があってどう実装すべきかという指針ができあがっているCと
手探りで指針を作りつつあるRustで議論のレベルが同じにならないのは自然なのでは >>204
問題はそういう言語の問題まで行かず、カーネルが備えるべきところってな議論で止まってるって部分だけどね。
歴史という意味ではそもそもカーネルに対する歴史観が不足してる連中しかrustにはいないということになる。 プロセスがスローし、誰も補足しなかった例外を
最終的に捕捉してそのプロセスを終了させるのはOS（ことによったらカーネル）の仕事である
一方、カーネルが仮に例外をスローしてしまったら誰が最終的な捕捉の任を負うのか
について今今のOS論には目下定説が無い
Linux（リーナス）は「カーネルは何があっても例外をスローすんなﾊｹﾞ、」という
古典的な立場
のやつ、 機械語に例外なんてねーよ
いい加減なこと言ってんじゃねーや >>206 CPUの例外と言語上の例外との区別が付いてないみたいね。 >>203
javascriptでメソッドとか探すときにプロトタイプを遡っていく動きがあるけど
それをRustのドット演算子（.）がメソッド使える型になるまで自動で参照解決する仕様で
模倣したんだと思う
演算子の特殊な拡張は正規表現とか構文解析のライブラリでたまに見かけるけど
どちらかと言えばトリッキーな手法 panic上等のredox！
セキュリティホール開けるよりマシという理由だった。
>>203
アンチパターンだから通常のコードでは使うな。
トレイトメソッド呼べないからクソって所まではすでに
githubのissuesやrust internalsで合意が有る。
js-sysはffi（バインダ）だから仕方ない。 例外の最終的な捕捉をOSの仕事、と書いたのは語弊があったｽﾏﾝｶｯﾀ、
正確に言えば言語のランタイムが最終的に捕捉してプロセスを自発的に終了する
（スタックのアンワインドは言語依存性が強いのでそうなっている
しかしプロセスが自発的にexit()したら誰がそれを処理するのかというとOSやんけ；；；
カーネルの中で例外を生じられたら誰が終了を担保するのかについて
OS論的に定説が無いのは真
>>208
いじょ で、別の観点の話をする、
OSがpanic上等というのはそれはそれでも良いが、
とにかくスタックのアンワインド処理は言語依存性が強いので
例外が通過する関数（ゼロコストの奴も含む）の巻き戻しのためには
関数のアドレスとスタックのアンワインド方法の対応表をランタイムが把握せねばならない
というわけでカーネル内の例外を認めると、その例外を最終的に捕捉する奴より
上の関数を全部同一言語・同一コンパイラで書かねばならないという縛りが生じる
現実にはそれで問題など生じないかしらんが、とにかくレイヤー分けに縛りが生じる
Redoxの一部をC++（等）で書くことは事実上不可能に、 >>212,213
なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
>>213
Linusがカーネル書くのに信用してないだけで
C++でもフリースタンディング書けるだろ。
C++のフリースタンディングは最低限の標準ライブラリは持つからrustのcoreクレートと同じ。
C++ならexception、abort,exitがある。
>>213がホストとベアメタルの区別がついてないだけじゃないか？
あと、redoxのpanicはスタックトレース吐いてx86のhltループするだけだから。
そもそもカーネルで標準のexitなんか呼ぶか。 Linux界隈といえばちょうど｢マージしたパッチが研究目的にわざと脆弱性を含んだものだったことが発覚して激おこで送ってきた奴らの大学出禁にする｣みたいな面白いことが起こってる模様 どうせお前らはOS書かないんだからどっちでもいいじゃん 研究目的だろうがそうでなかろうがわざと脆弱性を含むパッチを簡単にマージできている、という状況が問題なんであって
腹たつから大学出禁にしたった、とやったところで根本的な問題は何も解決しないんだけどlinuxのメンテナンスしてる連中とか
linusを筆頭にとか老害頭ばっかりだから自分がスッとすれはそれでいいんだろうな 1) 善意でやってくれてる連中にケチつけんな
2) じゃあお前が根本的な解決とやらをやれ
3) もしくはその根本的な解決方法を彼らに教えてやれ しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
らすとすぱぁとをきめるスレ その脆弱性もUAFとかぬるぽデリファレンスとか未初期化領域の使用とか2重開放とか最近の言語じゃ明らかに意図してやらなきゃ起きないようなもんばっかだもんなぁ
そりゃC/C++にしがみついてる大先輩方にとっちゃ逆鱗だわな そんなもんunsafeしまくれば同じだろ。。
そういう問題じゃないことくらいわかるだろうに、本当の馬鹿だな。 rustでOSかける->linus、panicある限り載せねーよ->rust信者発狂 発狂？むしろ歓迎
個人で使うようなアプリは好きなだけパニくれ
使われるアプリはパニくんなカス、これ常識だろ 言語実装的にもそうなってないよねって話なんだけど、なんだか通じてなさげ。 rustにもgoのマスコットキャラみたいなのいないんですか？ >>214
>なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
カーネル内での例外を許すみたいな立場で話す人が居るから
例外メカニズムが言語ランタイムと不可分な理由は
>スタックのアンワインドは言語依存性が強いのでそうなっている (>>212
C言語みたいにそもそも例外メカニズムを持たない言語を使った場合のみ
言語ランタイムと切り離したカーネル設計ができてｽｷｰﾘ >>219
だから、脆弱性を簡単に盛り込めないように危険な団体を排除しただけだろ。
普通の対応だと思うけど？ >>231
> >なんでカーネルの話してるのに言語ランタイムとプラットフォーム依存の話してるんだ？
> カーネル内での例外を許すみたいな立場で話す人が居るから
いません
この話はおわり 「注意すればC/C++でも問題ない」って意見は日本的だよな
人間はミスしないことが前提になっている
Rust Foundationのメンバーに言わせればそういう問題ではない
人間はミスするものだってなるんだろうけど そのミスの取り除き方のアプローチの違いだっていうことにさえ気づかない馬鹿。 c++でミスするような無能はrustでも使ってろと怒鳴り散らす
これが正しいアプローチ >>229-230
なんで蟹なんだろうな。
PythonユーザーのことPythonistaって言うみたいに
RustユーザーのことRustaceanって言うけど、
これCrustacean（甲殻類）からCを取り除いたものなんだな。 エビにしろよな
カニだとRealtekと被るじゃん 大半の人は、C/C++の文法がわかる程度でプログラムを書いているのが現状だろう
何がミスなのかそもそもわかっておらず、Rustを勉強している人と話も噛み合わない c++とrustの部分入れ替えてもなんの違和感もない文章だね C++ドロップアウターが希望を求めてやって来るスレ スレでグチグチ言うよりプログラム書いた方がよっぽど理解できるよ C/C++で穴のあるコードを書いてもしょうがないし、それも難しいんじゃないのかな
逆にC/C++の人らがRustコンパイラをすり抜けるヤバいコードを提示してくれたら、一発で口だけじゃなく出来る人だったと示せるだろうが >>155
> Rustに比べたC++の良さは雑に書けるところだって気付いた
> やっぱ雑が許されない巨大プロジェクトはRustで、小規模な自分用ツールの類はC++で書いてくことになりそうだ
これが何気に的を得てるでしょ
コンパイラが安全な方に導いてくれるのはもちろん良いとして、それよりも雑に (あるいは短く親しんだ方法で) 書きたい思惑が優先されるときは C/C++ でやれば良い話で いや、Rustでラクに書けない時点で勉強が不足してる
そのことに自分で気付けるような人だけRust使えばいい
「当を得る」か「的を射る」ことが出来るような人になってほしい いや、単にコード長が C/C++ の方が短く書ける可能性高いでしょ
どんなイディオムを駆使しても あと近年では「的を得る」は必ずしも誤用じゃないという見方が主流でしょ C++ vs Rustスレでも作ってそっちでやってくれマジで
不毛すぎる Rustのコンパイラと戦って勝ったコードは
シンプルでエレガントで簡潔なことが多い
らしい
mjk、 linusはやっぱすげーな
洞察力が違うわ
もちろんその道の神的な存在とはいえ
たいして知らない言語の弱点を一瞬にして暴いて
論破できるのは凄い どんなときもどんなときもRustがRustらしくある〜ために〜 >>258
お前ずっと一人で「他所でやれ」連呼してる奴だろ
C++との対立構造はRustにとって無視できないテーマでしょ
正直C++とどう住み分けたら良いのかわかってない奴がほとんどなんだから C++とRustは対立なんてしてない
Rustが怖いC++お爺ちゃんがRustに噛みつているだけでしょ > C++との対立構造はRustにとって無視できないテーマでしょ
お前のテーマなんてどうでもいいんだよ
よそでやってくれ 一般的なテーマだってこともわからんのか。馬鹿だな。 リナス「やっぱCが至高、C++もRustもクソ！」 rustもpanicをコアから外せればいけると思うのだが
もろ言語のコアなんだよな
痛いところ突かれた >>259
仮にその対立構造を認めるにしても
「雑に書くならC++のほうが楽」なんて、曖昧で基準も何も示されない話に真面目に付き合う奴はいないよ
そういう奴らのための隔離スレとして用意したから好き放題書き散らせばいい コード長の話でしょ？
どー考えてもC++の方が短いよ
んなとこで張り合ってもしゃーない 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 Rustしかまじめに勉強したことないけどいい言語だと思うよ >>272
C/C++で一度ひどい目にあわないとRustの良さは分からんよ
今はまだ分かった気になってるだけ Rustはコンパイルでひどい目にあうから問題無い
同じことだ Rustのコンパイラに怒られまくる奴は三流プログラマ Rustの文字列変数って、
str1 = str2;
のように書いた時、copyではなくmoveでしたっけ？ String型ならmove、&str型ならcopy
文字列リテラルなら後者 >>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 が使えなくなるのでちょっと違う。 >>278
無駄なことに時間使ってないでthe bookくらい読みなよ >>
C# は、「b.」の系統で、JavaとRubyと似た動作だね。 >>279
いろんな言語をかじってしまうと、どれがどれだか分からなくなってしまうんだよ。
文字列の s2 = s1 の動作は：
a. BASIC、JS、MFC、STL(C++)は似た動作。中身をコピーする。
b. Java、Ruby、C# が似た動作。参照を代入するだけ。コピーしたければ明示する。
c. Rustは、b の系統に似ているが、s1 が使えなくなる。 >>281
Javaの場合、Stringは参照しか出来ないが、Rustの場合は、「String型」だけでなく、
「Stringへの参照型」も使えるんだっけ (let s3:&String ??) ？ >>281
C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、
moveで、それ以外の時は copy。
一方、Rustだと、「デフォルト move」なので、基本的には move 動作。
cooy したければ、x = y.clone; と書くのかな。
色々ややこしい。 >>283
> C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、moveで、それ以外の時は copy。
そんな親切け？？？
左辺値同士だと明示しないとmoveしてくれないだろ
最適化次第ではしてくれるの？ >>284
えっと、関数の戻り値が構造体型(or クラス型)の場合、右辺値と解釈されるので、
s2 = func(xxx);
見たいにした場合は自動的に move代入されたと思う。
それ以外だと、たいていは、s2 = std::move(s1); のように書かなければ
copy代入になるんじゃないかな。
s2 = func(xxx).s;
のようにした場合も move代入になるはず。
自信は無い。 >>285
RVOは全然違うぞ
s2の構築にコピーコンストラクタを使わなくなって早くなるというだけ
ムーヴコンストラクタはそもそも出てこない >>285
自分の記憶だと、一時オブジェクトも右辺値だから、
s2 = std::string("xxx");
ともし書いたとしたら、右辺は右辺値になるのでmove代入になるはず。
s2 = s3 + s4;
みたいにしても、右辺は関数の戻り地と解釈されるので右辺値になるので
move代入になるはず。 Rustってコードをフォーマットしてくれる機能があるからいいね
これこそモダンな言語だと思う しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
rustすぱぁとをきめるスレ 非Syncなデータに複数スレッドからアクセスするコードに警告だしてくれるlintある？ 質問です
let a = 10;
let b = &a;
let &c = b;
としたときに変数cは数値の10になるのですが
cの前にある&は参照外しの効果があるということなのでしょうか？ >>295
pattern matchとdestructuringでそうなる
3行目でbの型が&Tの場合に`&c`にマッチさせたらcの型はTになる
dereferenceの意味で「参照外し」と言ってるなら意味は違うかも >>296
横から失礼するけど、なるほど。
let &c = b;
は、C++の
int &c = b;
とはかなり違った解釈をされてしまうんだね。後者の場合、&は参照型の
記号で、cの型は、intへの参照型になる。Rustで似たことをしたいなら、
let c:&i32 = &b;
だったっけ？ String::fromとString::newの使い分けを教えてください >>297
cも参照にしたいなら単純に
let c = b;
でいいはず
let &c = b;
は
let (x, y) = (1, 2);
と似たような代入式だからbが参照型（かつ被参照型がCopy可能）じゃないと
コンパイルできない
>>298
String::newは引数取らないで空文字列を作る
String::fromは引数に文字とか文字列を取って同じ内容の文字列を作る
リファレンス（↓）読みなさいと言いたいけどRustのリファレンスって
traitとか理解しないとなかなか読みこなせないよね
_ttps://doc.rust-lang.org/std/string/struct.String.html >>297
>let c:&i32 = &b;
>>295の続きならbがすでに&i32なので
let c = b; か
let c: &i32 = b;
C++でもStroustrupに従ってint& c = b;と書いとけば同じ意味にとれなくもない 意図もわからずなんとなく動くからそのメソッドを使い、借用をつければなんとなく動くから
借用し、変更する予定はないけどmutし、ここはエラーだからとpanic!し、補足するなと言われているのに
catch_unwind/recoverして、血の涙で泣きながら渡されたソースをシコシコ直すおまいら・・・ >>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での参照型」の変数に出来るわけね？ >>302
C++で書き直すと、
int a = 10;
int *b = &a;
の状態だと、
int *c = b; か
int *c = &a;
で c を b と同じような「C++のポインタ型」の変数になる。
ということだね。 >>301
割とこの未来はもう始まってるんだよな。。rust書き逃げは結構ある。。 構造体があるじゃん
a.b.cの更新参照もってて
同時に
a.b.dの更新参照とって
両方更新しようしたら
aの更新参照が２箇所にあることになるからできないの？
使い物にならんくない？ >>296
なるほど
match式と同じ様に振る舞うのね >>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 を返す関数にするってことね 文字列についてなんかわかりにくいのだけど
C++に例えると
strはchar a[len]
Stringはstruct String { long len; char* str;}
&strはchar* str=&a[2]
このイメージで問題なし？ >>308
細かいけど関数の例はRefMut返すより&RefCellで返す方が安全な気がする
RefCell本体の参照をシェアするだけなら二重で呼んでも大丈夫だし
RefMut作るのは変更が必要な瞬間だけに限定したい >>309
&strはlenも持ってる
fat pointerでぐぐれ RefCellについての良いドキュメントや、本などがあれば教えて。 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が変換不可だから？ >>314
‘aが’bをoutliveするかどうかわからないからじゃない？
fn f3<'a: 'b, 'b, T>(x: &'a &'b mut T) -> &'b T { x } リーナスのRustのパニックがどうのはCを前提としたプロジェクトとRustの流儀がマッチしないって話に見える
逆にRustの流儀に沿ってデザインされたシステムなら問題は起きない可能性もある
てかそういう研究はされていないのかな？ 全部rustで書けばいいってか。馬鹿すぎる発想だな。 パニックってFFI Boundaryさえ越えなければベアメタルだろうが使っても問題ない認識なんだけど間違ってる？ >>316
そのシステムの基礎を作るのがOSで、Rustの流儀に従うようにする
基礎の部分を作るために Rust の流儀を前提とした言語で書くのは出来ない。
C言語は素朴なマシン語に直るために基礎を作ることが出来る。 >>318
別に使って問題ないし、ベアメタル用のパニックハンドラなんかもいろいろあるよ。 >>317
いきなりLinuxやWindows級のOSを作るのは現実的ではないが
組み込み用のOS程度なら馬鹿げてはないだろう >>315
回答ありがとうございます
確かに'a: 'bを付けるとコンパイル通りますね
xの変換については
&'a (&'b mut T)
→ &'a T
→ &'b T ('a: 'b指定により可能)
という考え方で良いのでしょうか >>323
いや自分で書いてて全然理解できてないです
下記変換は無しですかね。。
&'a (&'b mut T)
→ &'a T >>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 型の値が作れないため) >>322
じゃあ自分で作ってみりゃいいじゃん。
linuxなんかにいちゃもんつけてないでさ。 >>301
自分で書いてて全然理解できてない奴らが量産されて、キーボードを叩く拳に血が混じりながら
意味不明なコードを誰かが直す。なんというおそろしい未来かw linuxにいちゃもんつけてる人はいないが
rustユーザーがlinuxにいちゃもんつけてると主張する人はいる不思議 panicのせいで実質組み込みでも死んじゃったな
linusやりすぎだぞ >>332
Linux カーネルで受け入れられないからと言って組み込みで panic が使えないわけじゃないでしょ。 >>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難しい。。 >>326
だから作るにあたって参考になる資料とか実装例はあるのかって話なんだが
OSを作るみたいな資料はあってもその多くはCとアセンブラを前提としているし
それを参考にしたらC流になってしまうだろ 実用的なOSとしてはこの辺かな。
https://github.com/tock/tock
あとは研究論文レベルでは、Rustの所有権システムをOSの権限管理周りに使って堅牢なシステムを作ろう、みたいなのもある。 >>337
インラインアセンブリでもRustを使うとコンパイル時に強力なチェックが！
あるわけないよな…Cでいいと思います OS 全体の中でも低レイヤ寄りの部分はしょうがないでしょ。
どうせほとんどインラインアセンブリなら C でもいいが Rust で駄目という理由にもならんし。 >>339
Rustは書き辛いし、生成されるコードや意味解釈に闇がある。 言語の設計思想をOS全体に広げて実用的に成功した例ってあるの？
LispOSみたいなのは全部失敗してるじゃん
Cはもともとアセンブラで書かれてたOSを高級言語で書き直せるように
言語自体を後から設計したものだからね
Rustがシステム記述言語として使われたいなら、Linusに意向に100%従って
言語仕様をどんどん書き換えていかないとダメ絶対 FORTH作者「FORTHには申し訳ないことをした…」
ホントだよ！
FORTHがきちんとケアされ続けた世界線を見てみたい 昔はＢＩＯＳ とか forth で書かれてたけど今はどうかなー Rustは配列に添え字アクセスする時、必ず境界チェックされるよね？ 言語設計とOSが一体ていうのがどのくらいまでを指すかにもよるけど
Smalltalk は元々は言語=OSみたいなシステムだったな >>349
言語仕様的にチェックされるかという意味ならYes >>351
ライブラリの実装ではチェックされるようなコードになっているが
最適化で消えるかも知れないので実行時に必ずしもチェックされるとは限らないという意味？ コンパイル時に境界チェックを外せると確定してない限り最適化しようが境界チェックはやる 例のLKML見直してて思ったけど
unsafeなコードetcが不変条件を破壊した場合に対する安全な対処法って今なんかあるのかな 二重投稿になるかも知れませんが、[0; n] で、n要素のi32 型の配列という
意味になるようですが、n が実行時にしか決まらない変数でも大丈夫ですか？
その場合、データ領域はスタック領域から確保するのでしょうか。 >>354
不変条件の種類によるけど最悪 undefined behavior になるから対処は無理じゃないかな
コンパイラの最適化レベル落とすとかで振る舞いを予測可能にすることは出来るのかも >>357
でも、Box::new([0; n])と書いた場合には、nはコンパイル時に決まらない値
でもいいの？ うまくいかなかったとしてほかに問題がないか状況を切り分け周辺を調査
誤りのない環境を整備
学習内容を保存し整理
単純な文法ひとつでも最低３０分 Rustの場合
｢2秒で試せる｣ || ｢試すしたら2秒でわかる｣
error: 意図が曖昧です
Cの場合
｢2秒で試せる｣
｢2秒で試してみろやカス｣ Golangが難しかったのでRustにきました
よろしくおねがいします Animal から、C++ の継承のようなことをした構造体(?)を Dog とした時、
Box<T> a; で T を Animalのようなものにして、a には、実際には Dog
への参照を入れるようなことは出来ますか？ >>368
dyn かな？
完全に一致する機能というわけではないけど、
Rust ではトレイトに dyn キーワードを付けると (C++ で言うところの) 抽象クラスのように機能する。 >>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));
}
} C++でis-a関係の継承使うデータはRustだとenum使う方が単純になるケースもある
struct AnimalData { ... }
struct DogData { ... }
struct CatData { ... }
#[non_exhaustive]
enum Animal {
Dog (AnimalData, DogData),
Cat (AnimalData, CatData),
}
この方法にも色々欠点はあるけど（クレートの外で新しいAnimalを追加できないとか）
trait使う抽象化が大袈裟だと思ったら考えてみて >>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));
} >>372
簡単な例として書いただけで、同じ表示結果を得ることが目的ではないので
そういうこととは趣旨が違う。
さまざまな種類の多態なオブジェクトを1つのリストの中に入れるということは
オブジェクト指向に置いて基本的な概念の一つで、Polymorphismの基本なので、
継承的なものを使わずに同じ結果を書けたとしてもそれは違う。 ポリモーフィズムを理解してないようなやつでもRustをはじめるようになったんだな c++と同じで難しくてランタイム速度最強てなところが厨を呼び寄せてる C++やってたら配列のインデックスアクセスが安全かどうかや
ディスパッチがスタティックかどうかを普通気にするよね グーグルやMSが「Rust」言語でOS開発、背景に国家による諜報活動の影＝日経 xTECH中田敦
背景に国家による諜報活動の影っていう根拠が１つも示されてないんだけど、こいつの言ってることマジなん？
それとも日経新聞のおなじみの「飛ばし」によるクリック集め？ マイクロソフトがwindows書くのにc++使って後悔した話も知らん層が今も同じようなことやろうとしてんだろ。。
バカは歴史に学ばない。 これ見てたら、いきなり日本語で「ネコ」って出てきてびっくりした
https://www.programming-idioms.org/cheatsheet/Rust
実は、お前らの中の誰かが書いてんのか？ >>379
>マイクロソフトがwindows書くのにc++使って後悔した話
興味有るので詳しく : >>379
流出したソースを見る限り、MS は C で Windows を書いていたようですよ‥‥ そういえば初期WindowsのWindow管理のサンプルコード見た記憶がある
ツリーリンクリストが構造体に埋め込む形で自作されてた まあLinuxもCと一部アセンブラだから似たようなものか 当時の言語状況からして他に選択肢なんかなかったと思うがねぇ。
他の言語選択してたら駆逐されてた可能性すらある。 NT kernelが開発されたのが1990年代か
C++も既にあったがまだ浸透してなかったかな チュートリアルやってたらトレートオブジェクトってのの説明が意味不明級だったぜ
https://tourofrust.com/82_ja.html
なんじゃこりゃ >>392
Javaの知識があれば
trait object： interfaceとして渡されたオブジェクト
という感じで説明できるけど何か使い慣れた言語はあるかね >>393
もしかしてExistential Container(和訳不明)が独立のオブジェクトとして括り出さている感じですか？
なおC#が一番使い慣れているのですが、この範囲ではJavaと大きく違わなさそうでしょうか・・・・ >>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>のようにポインタの形になる
そのチュートリアルは前後のページとどう関係があるのかについて説明がほぼないのでわかりにくいかもね 他の言語の概念と対応付けるよりはそれ自体として理解したほうがいいのは確かだと思う。
(理解できずに行き詰まるくらいなら雑な理解でも一旦前に進んだほうがいいかもしれんけど。)
言語機能ってひとつだけを取り出して使えるものじゃなくて、他の言語機能との連携の中で活きてくるものだから
個別の言語機能を他言語の言語機能と対応付けて理解しても綺麗に繋がらない感じがする。 https://doc.rust-lang.org/reference/types/trait-object.html
こっちじゃ`dyn Trait`のことをtrait objectと呼んでいるようだけど
というか俺はこれだと思ってた
Traitを実装する具体型の値のアドレスと、その型に対するTrait実装のvtableの組 >>394
C#はあまり詳しくないけど、例えばListのAddRange関数の引数の(IEnumerable collection)が近いかな
AddRangeにはIEnumerableを実装してればどんな型でも渡せるはず（ArrayList、HashSet, etc）
これをAddRangeの視点で見ると、渡されたcollectionが実際に何の型かは分からないけど
IEnumerable（interface≒trait）を実装してることは分かってるから
そのGetEnumeratorを呼んでIEnumeratorを受け取ってそこから取り出せる要素を全部追加すれば
目的の動作は果たせることになる
このAddRangeの引数のcollectionがIEnumerableトレイトを実装したtrait objectって感じ >>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や他の解説書でも区別してないのが多い 囲い込んでブラックボックス強要するあたりはMSと相性いいかもな facebookも財団に参加したのか
appleも時間の問題かな
intelとかのCPUメーカーにも参加して欲しい所だが CPUメーカーが参加するとどういうことが嬉しいの？
LLVMなら分かるんだけど まあ元intelのエンジニアも開発に参加しとるけどね え？脆弱で有名なあのインテル？
ヤバいじゃないですかぁ rustが低レイヤーの開発言語としては覇権取りそうね
今から勉強しとくのが良さそう 低レイヤーの仕事をしたことないってのがよくわかるわ。 >>405
エンジニア個々人が参加するのは普通にあると思うんだけど
企業として支援することにどんなうまみがあるのかなと思って
ただ改めて思うとintelもソフトウェアたくさん出しててrust使う旨みはあるから支援する意味はありそうだね SHやArmのRustコンパイラをメーカーが出たらｶﾞﾁ うまみっていうか、それが上手くいくかどうかなんて事前にはわからん。
ほどほどに有用そうなものに支援してたらどれかひとつくらいはいい感じって程度の話だろ。 協力し合うと同時にあまり勝手しないように牽制するのも目的なので どうも頭の悪い輩が多いなと思ってたけど、
この言語、ある程度まではスクリプト的に書けるからなんだな。。
なんとなくおかしなこと言ってる奴の感覚がわかってきたわ。 >>413
> この言語、ある程度まではスクリプト的に書けるからなんだな。。
短く簡単に書けるようにするのはRustの課題の一つだと思ってるので、どういう観点から「スクリプト的に書ける」とおっしゃるのか伺いたいです
よく比較に上がるC++よりはよっぽど記述量多くなるよね？ そりゃautoなんかを使いまくった最近のスクリプト厨のc++ならそうだろうけれど、
普通に仕事で読むc++コードはそういう感じではないからね。
てかc++と一口に言っても年代で全く別言語だわ。
そういうスクリプト的な書き方をした場合、rustのがc++より快適に感じるのはまあわかるよ。
問題もrustのが少なく感じる。そういう書き方だけしてる場合はね。 炎上学習法かってくらい何も理解してない感じでワロス 型再構築なんてむしろ厳格に型付けされた言語から生まれたんだが C#でvarキーワードが導入された時も
基本型の変数にvar使うのやめましょうみたいな規約を
意味不明な根拠で良い規約と信じて導入しようとする
おかしな人達がそこら中に居た
後にEffective C#かそこらの書籍で
ローカル変数はvar使えと明確に書かれるようになって
老害ザマァと思ったものだ ローカル変数の場合は型がすぐ隣に書いてあるような状況だろうからな。 ほらね。
好き勝手な自分流でコード書いてるだけで人のコードを読んでないのが丸わかりなコメントしてても
全く気づかないバカしかいない。 >>421
ようするに型情報を二重に書いてるようなものだよな
情報の多重化であり
小さなDRY原則違反
こんな簡単な理屈を理解出来ない奴が不思議 書かれておらずメソッドで戻り値を取得するような場合
C#もJavaも型で呼び出し先が変わる仕組みなので
意図せずに処理の流れまで変わってしまう >>424
お前は日本語勉強しろよ
普通に読解不能なんだよ
必要な所には型を書く
当たり前
不要な所に書いてると
「何故書いてるのだろうか？
何か理由を見落としてるだろうか？」
と注意深いプログラマを考えさせるのでエネルギーの無駄 >>425
varにするようになったら全部varにするだろ？ >>416
相手してるお前も同罪やぞ
すぐ見分けつくだろ VSCode + rust-analyzer だとletやメソッドチェーンのところに型が表示されるし
今時の開発環境使っていればローカル変数の型がぱっと見で分からなくて苦労することは少ないのでは >>427
何を言っとるんだお前は？
右辺値と同じ型で「困る」時は型を書くに決まってるだろ
下手するとvarの仕様も理解せずに混乱した事を書いてんじゃないだろうな ゲェーQZ居着いてんのかよこのスレ
バカなくせに出しゃばりでウザいからC++スレから出てくんなよ >>430
後から右辺値の型が変わったら気が付かないうちに影響が波及するじゃん var xの型が何であるかはxの初期化のときただ一度きりの右辺の型で決まるんｼﾞｬﾈｰﾉ
だとしたら後から右辺値の型が変わることに関して
varの導入で傷口が広がったことにはならない 二回目以降の右辺値はxに対する代入でしかありえない
それらはxに対して（暗黙の型変換等を経て）代入可能ならコンパイルが通るし、
代入不可能ならエラーになる。
xの初期化時にvarを使おうが使うまいが（明示的に型を書こうが）変わらない話 RustのletはJS由来？ それともHaskell？ JavaScriptにもletあるけど語源調べたら普通に英単語のletで短縮形ってわけじゃないらしい 最初のrustcはocamlで書かれてたくらいだしML系の影響は色濃そう デイブ・ハーマン（Dave Herman）というECMAScript委員会のMozillaの代表者の人がいました。
リポジトリ上のコミットログでは目立ちませんが、彼の好みがRustチームの好みを作り、チームの組織と維持に重要な役割を果たしていました。
彼はチームの決定をほとんど穏やかに受け入れていましたが、let mut と var のどちらにするかについては var を使うというチームの決定に同意しませんでした。 >>421
でも、
BYTE c = 'a';
と
let c = 'a';
では間違い易さが違う。後者は、int か BYTE か SBYTE か分からない。 Rustだと、明示するには、
let c:i8 = 'a';
とキータイプが多くなってしまうな。 例えばの話、演算子も優先順位が決まっているので、
if ( (a >= 5 && a <= 10) || (b>=10 && b <=20) ) {・・・}
見たいな条件も、優先順位の括弧を省略できるかも知れないが、勘違いや
記憶違いを防ぐために書いた方がいいと言われている。
int c = 'a';
char c ='a';
auto c = 'a';
ではやはり、autoはバグの原因になりそう。 それと、型を明示した方が後から見たときにプログラマの脳内の想定もわかり易い。
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 型に変えたときに
右辺を訂正する必要がないメリットもある。 >>446
rustの文字リテラルはu8でもi8でもなくてcharな
それはそれとして型やら括弧やらを明示的に書くことは禁じられてないんだから書けばよいのでは
言語の問題というよりはコーディング規約でなんとかすべき領域かと
タイプ数が多くなるとかはデフォルトをどちらに倒すかの問題で世間の嗜好とずれてるなら多少手間がかかるのは諦めるしかない 誤解を招きそうだから補足しておくとrustのcharはユニコードのコードポイントが格納される32bit符号なし整数型な >>445
var使おうとしてたってマジかー
let (mut a, b) = get_foo_tuple();
みたいなやつとかvarじゃ困るから必然だと思ってたのに >>445の要約の最後たぶん間違ってる
デイブ氏はキーワードを重ねるとmutableな変数の使用を躊躇させる効果が生じて
プログラマのコーディング方式の選択を咎めることになるから反対だったらしい
チームの決定は初めからlet mutで彼は（珍しく）反対したけど最終的には受け入れた varでいいじゃん
あとはideが勝手に型直してくれるよ >>454
すまん、指示代名詞の指してる先を読み違えた
デイブ氏はvar押しだったんだな タイプ数で優劣を決めようとするアホとは次元が違うな fn, ret, cont, break の時代に回帰するか タイプ数は少ない
って基本型が少ない言語が好みなのかと思った <?rust
println!("hello rust!!");
?> >>448
型を明示したってバグるくせによく言うのぜ タイプ数が少ないようが絶対良いんなら
むかしGAMEとかいうすべてのキーワードが1文字の言語があったからそれでも使え >>464
型明示はバグの軽減に繋がる。
>>465
絶対的に良いわけではないが、let a:i32 = 5; と int a = 5; だと後者の方が楽。 >>467
intが32bitだといつから錯覚していた？ let a = 5_i32;
型は右側だけで決めるのじゃ
両側で合わせるのは無駄、変更するときも面倒じゃろ
・・なに？
aがi32だと明示してバグを軽減したいじゃと？
それなら行を分けるのじゃ
１行にまとめるとせっかくの明示が埋もれてしまうからの
let a: i32; // この行の存在は大きいぞい
a = 5_i32; >>468
そこまでいうなら、int32 a = 5; や i32 a = 5; と書けばいい。
なお、Rustではこの書き方が出来ない。 >>468
ちなみに、組み込み以外のほとんどのC/C++コンパイラでは、intは32BIT型。
デスクトップマシン用のC/C++では、32BIT/64BIT のどちらでも、intは、
32BIT型のはずで、少なくとも VC++では必ず int は 32BIT。 >>474
typedef int int32;
typedef int i32;
とすればよいだけ。 >>475
それintが32bitじゃない環境でアホみたいにミスリーディングになるけど？
いい加減スレチだし「int32_t 標準ライブラリ」でググって理解したらこの話終わりにして？ >>476
そんな基本的なことは当たり前で、そのような環境では、
typedef __int32 int32;
typedef __int32 i32;
とする。 どういうバグを作る可能性があるかという点が共有されてないから議論空回りしている感 というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
だと思ったんだ。もし、int32_t が使える環境で賢く使いたい人は、
typedef int32_t int32;
typedef int32_t i32;
typedef int32_t Int32;
などとすればいいという話。
前提とする知識が低すぎる人がいるから困る。 1レス目で即NG
相手してるやつも同じカテゴリなので即NG >>479
>というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
>だと思ったんだ。
誰がどこでそんな話をしたのか
ログ辿っても全然分からない件
ついでに言えば
グローバル名前空間の中に標準ライブラリがブチ込む型名として
_tサフィックス以外あり得んので
何も馬鹿なことなんか無い
つーか本当に誰もそんな話してないな
これ突っ込んだら
どんなガイジレスを返すのか興味津々
>>480
論点不明のドッジボールだからな
今はどこでも似たようなやり取りが見られて
5ch終わってる感がハンパない
俺は句点付きが特に頭おかしいと思うけど
レスバ相手はEQがヤバイ感じだが
句点付きはIQがヤバイ メジャーなGUIアプリで使われているrust製GUIライブラリってなにがありますか？
GUI使いたいんですが長いものにまかれたいので >>484
プラットフォーム (OS) によって違うんじゃない？
その中ではある程度に淘汰されてると思うけど、
あらゆる環境で万能な決定版は無いと思う。 >>483
>句点付きはIQがヤバイ
実際にIQ150越えてるので、ノーマル一般人が理解できないだけではないか。 >>486
証拠うpしてくれ
ID付き画像とかなら最高だ
IQ150超えでもこんなガイジレスするのか
マジで興味あるわ メモリ不足でカーネルパニックが起きることの問題がわからない
普通のパソコン用途に使われてたらユーザーランドのソフトがOOM Killerに殺されようがOS丸ごとクラッシュしようが作業内容が失われるのは変わらん
サーバー用途でも一部のプロセスが殺されて中途半端の状態で動き続けるよりいっその事OSまるごとクラッシュしたほうがいいと思う >>488
rustでLinuxのドライバー書く話？
メモリ不足時にどうハンドリングされるべきかは使い方によって違うので一律パニックするのは良くない
例えば例に挙げてるOOM Killerだってカーネルがパニックしたら実行されないわけで >>488
何かあった時止まればいいシステムばかりじゃないだろ
ペースメーカーとか原子炉とか
細かいことは知らんけど
昔、組み込み屋のおっさんが最初から1Mぐらい確保して
何かあったらそれを解放してどうにかするみたいなこと言ってた
知らんけど >>488
システムは単独で動いているわけではない。
カーネルがパニックすることがあって良いという前提で設計して、パニックしうる前提で運用できるならそれでも構わんのだが、
Linux のカーネルでパニックを許すなら今 Linux を基礎にしているあらゆるシステムの運用体制を見直さざるを得ない。
カーネルパニックが絶対に駄目というわけじゃないんだ。
(もちろん発生しないに越したことは無いが。)
Linux では起こさないという前提に皆が従っているので変えられないという話なんだよ。 割り込みが飛んでくる環境で例外なんか扱おうとしたら普通に死ぬだろ >>488
失われる作業内容の範囲があるだろ。
クライアントOSのWindowsですらBSODで切れる奴が多かったんだから、サーバーOSでそんな考えが許されるはずがない。 差し当たりRustの言語を広く浅く学習したいのですが、「実践Rustプログラミング入門」の言語部分(100ページ程度)が分量が少なめで気になっています
この本で大きく抜けている文法や機能ってありますか？ >>493
サーバーOSのほうがクライアントOSよりクラッシュには寛容だぞ
サーバー側の開発したことないのかな？ >>496
最近は仮想化＆分散で寛容になっているの？ >>494
最近の本だからasyncまであるし、そんなに大きな抜けはないかな
広く浅くならまぁいいんじゃないかと
もし細かい部分が気になったらthe bookで補完すればいい >>497
むしろchaos engineeringで積極的に落とす ペースメーカーとか原子炉とか、ノンストップシステムでは常に複数動いている
Kubernetes などでは、ネットワーク分断に備えて、
正常な状態を多数決で決めるから、3, 5, 7 みたいな奇数を動かす
2対2とか偶数だと、どちらが正常か判断できないから Netflix などは常に、システムを攻撃して落としたりして、テストしてる。
サイボウズのkintone は、毎日システムを破棄して、作り直しているとか
Kubernetes を使っているのかな？ 非常時の処理はカーネルの中心部が決めることで
枝葉のモジュールに決定権はないという話なんじゃないの？ レイヤーがめちゃくちゃな話しとるな。
OSみたいなハードウェアに直触るものとkubernetesみたいな分散管理のソフトじゃ
全然話が違う。
実際kubernetesはGC付きのgolangが実装だろ。 ノンストップシステムでは常に複数動く。
デュアルシステムとか
東証・富士通製のarrowhead は、3重だったかな？
それでも、ラックか何かの接続部分が落ちて、システムダウンした
ネットワークが集中している部分の故障が、最も怖い >>492
なんでじゃ
割り込みルーチンに入るときの退避と出るときの復旧をきちんとやっていれば
割り込みルーチン以外の処理は割り込みルーチンが呼び出されることに対して透過的に動作できる
一部のハードなリアルタイムOSみたいに（多重割り込み前提で）割り込みルーチンから
通常コンテキストに直接「ジャンプ」してタスクをたたき起こすみたいなケースでもなければ割り込みの存在は
通常コンテキストで何をやろうと一切影響は無い
（もちろん割り込み禁止、みたいな直接割り込みに影響する命令を実行したら話は別だがそれは普通特権命令でOS以外は実行できな
い
カーネルでの例外が問題なのは、
例外機構を持たないCならスタックポインタの調整で済むところを
デストラクタがある高級な言語だと例外が通過する際に自動変数として構築されていたオブジェクトを
例外が通過する関数全てについて解放してやらねばならない
（それでいて一方、自動変数として構築される可能性はあっても
例外発生時に構築されていないオブジェクトに対しては何もしてはいけない
という点
これは例外を飛ばすだけでその経路全部が同一のコンパイラで書かれなければならないことを意味する
途中に手で書いたアセンブラのルーチンなどあろうものならスタックをぶち壊してハードウェアの例外でいきなり
落ちるということになってそんなことがOS内で起きたら計算機上の資源の安全が担保されない。
OSとしては失格である 、と思ったが
よく考えたら「手で書いたアセンブラのルーチン」があったらコンパイラはそれを知らない関数としてスタックポインタの調整以外のことを
しなかったら良いのかorz、
ここは「例外通過時にC++や異なるベンダーのRustコンパイラみたいな例外を捕捉する関数をコンパイルいたRustコンパイラが預かり知らない
巻き戻し処理が必要なルーチン」があったら、ということに訂正
、 JAVAみたいな言語があるからnewしたまま放ったらかしでメモリ管理もろくに出来ない馬鹿で溢れかえって居るんだよな ついさっき知ったけど、new() はT だけじゃなく Result<T> を返していいんだな newはシンタックスじゃなくてただの慣例だからね
慣例ではResultを返すのはお作法に反するはず メモリ管理もろくに出来ない馬鹿
・Linuxカーネルにカーネルスタックメモリ内の情報を読み取られる脆弱性
・「WebKit」にゼロデイ脆弱性 〜「macOS Big Sur 11.3.1」や「iOS/iPadOS 14.5.1」などが公開
・BIND9に脆弱性、アップデートや回避策を >>509
因果関係が逆で、
頭が悪くてその程度ももともと出来ない人は昔はCやC++でプログラムできなかった
がVBやJavaやC#やJSやPythonやRubyではできた。 >>511
newとかfromでResult返すのたまに見かけるけど
どうするのがおすすめなの？
try_newとかtry_fromにするのが良いのかな >>511
ただの慣例じゃなくて、clippy先生の指導対象らしい
https://rust-lang.github.io/rust-clippy/master/#new_ret_no_self
Checks for new not returning a type that contains Self. 手動でスタックポインタの調整ってバグや脆弱性の温床じゃね？ 医療機器や原発の制御システムとかが不意にリセットしないとか思っている時点で
組み込みとか高信頼性システムとかを全く知らないんだなって思う
ああいうのは最悪暴走したらリセットして最低限の機能は提供出来るように
作るのが基本だからね。そうしないと想定外の事態がおきた時に詰む そんなコーナーケースの為に俺たちの使い心地が悪くなるようなら耐えられないな 暴走した場合にでもうてる手札を用意しておくってのと、
暴走しないように細部まで検証しておくってのは両立する話 いうほどコーナーケースってほどでもないだろ。
割と考慮されて当然のケースだわ。
まあlinux単体がその品質を担保できてるとも思わんけど。 原子力関係だけでなく航空機や宇宙機もだが制御不能になるのが一番ヤバイんで
バグ出しは常識的な範囲で行って、あとはリカバリ系に注力した方がシステムの信頼性は向上する
歴史的に見ても事故るシステムの多くはこの辺をガバっている事が多いし 別に
ハイテク旅客機が落ちるのは自動制御と手動操縦のモード切替仕様を
パイロットが熟知しておらず緊急時に操縦桿を奪い合う格闘になったから
であってソフトは仕様通りだった
『ハイテク飛行機はなぜ落ちるか』（ブルーバックス）のｲﾝｼﾃﾞﾝﾄの数々を見たらﾜｶﾙ
原子炉の制御系はそもそも暴走させないように金かけて形式検証する
人間が本気になったらどんだけバグをなくすために金と手間を掛けられるかというと
スペースシャトルのSSMEの制御装置のソフトがどんだけ徹底したデバッグが行われたかを見たらﾜｶﾙ >>523
人間が使う物であればUIも当然システムに含まれる
判りにくいUIは良いシステムとは言えない
ソユーズや神舟はADA使ったりしていないけど
スペースシャトルより死人は少ない。米式が唯一の正解とは限らない
むしろスペースシャトルはシステム設計に失敗した例だろ UIの仕様バグと>>518が言っている暴走する系のバグは話がちげう 組み込み機器でも多くのケースで不測の事態に備えてウォッチドックタイマを使うよね
トリガを何にするかやリセット時に何をするかは設計手腕が問われるところだけど >>516
fn new() -> Result<Self, T> は警告出ないよ newでResult返すのはいいけどfromは駄目だろ
というかFrom trait実装しろ >>528
そもそも impl From<T> Result<Foo, E> はcoherenceの関係でエラーになるよね
Intoはできるけど
FromStr なり TryFrom を使うべきというのはそう >>527
そりゃ Result はそこに書いてある a type that contains Self だからね cのコードをrustに変換してくれるライブラリってありませんか？ 例外処理って何が有難いの？Cでプログラム書いてて例外がなくて困ったことないんだけど
もしかしてただのシンタックスシュガー？ どのレベルの話？
初心者の質問だとすると、関数の失敗を成功と区別するため。
戻り値で区別するんでなくて仕組みで。 例外の存在意義が分からない
戻り値で判別する方が可読性も高いし何も不足を感じない fileへのwriteとか毎行エラーチェック入るのしんどい >>538
開いた後、必ず閉じる処理が必要な場合があるが、それをxとすると、
関数のある場所でエラーを発見した時、呼び出し元へ返りたくても、
xを閉じてからでなくてはならない。xが複数有ったり、今後もxの
量が増えていくような場合、エラーが起きる場所全てでxを正確に全て
閉じてからreturnするのは難しい。なので、昔から、xを閉じる処理は
関数の最後の方に書いておいて、その直前にラベル lab_ex:; のような
ものを書いておいて、エラーが起きたときにはlab_exにgoto文
で飛ばすようなことが行われることが多かった。
でも、goto文は好まれ無い事があって、
try, catch 構文を使うと、goto文を使わなくてもそれが出来るようになる
ことが例外処理の一つのメリット。 >>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分がそんなに分かりにくいわけではない。 そういやCで bail: ラベルが多用されてたなーっていうのを
anyhowクレートの bail! マクロで思い出した >>542
例外処理を使った場合、goto文が要らない：
BOOL func()
{
BOOL rc = TRUE;
open_some(x);
try {
func2() ; // 例外発生の可能性有り
func3() ; // 例外発生の可能性有り
}
catch(...) {
printf( "エラーだよ\n" );
rc = FALSE;
}
close_some(x)
return rc;
} >>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;
のようなもの。 Linuxや*BSDなどのカーネルはgoto文が誰に遠慮することもなく堂々と使われてますよ
そして可読性は何も損なわれていない
言語屋さんだけじゃないの？構造化でgotoがどうたらとかそれに代わる言語機構が
必要だとか言ってるのは
そして新たに言語を学ぶ人が無批判にそれらを盲信することが代々続いてる
ようにしか見えない 多くの言語はハードウェアとしてCPU例外や、I/Oに対する入出力の（ハードウェア的）例外と、多くは
復帰可能なエラー分岐処理にて、プログラミング言語で「包括的に捕捉して後処理」するためにある。
例外の反対者はResult/Option/(Either)のようなものがあるのに、なぜ言語に例外を取り入れて、信頼性を
低下させるような隠された制御フローを導入するのかと主張します。
しかし例えばファイルへの出力で"fwrite"ではOSの上層では実際に書き込まれず、"fclose"で書き込まれたり
あるいは"fflush"でメモリー上とディスクが同期されるなどは、同期的な、従来の戻り値を確認しただけでは
正確な判断ができない。（これは言語のライブリーがBufferを使用しているとは別の話、たとえばディスク
容量が足りなくなった場合など、意図するプログラムは失敗する可能性があります。）
またResultなどが使用できるの場合は、ハードウェアやIOに依存しない場合にできるだけです。他にも、不正な
ゼロ除算などの発生は、カーネルでも、組み込みでも、CPU例外に対しては特定の例外の種類によりあらかじめ
決められたアドレスに強制的にジャンプします。C言語自身はCPUの挙動を定義していませんので、この制御の
フローの移動はCプログラミング言語の機能ではなくCPUメーカーの実装です。
つまり、標準のC自体だけでは、統一的にエラー処理を記述するということ自体が出来ていませんし、実行制御
フロー記述し完全掌握してコントロールするという事自体があやふやです。
（ゼロ除算でジャンプしなくてHALTするようなCPUがあるかもしれませんが知りません） 多くの例外がある言語(RustやGoのpanicも含む)では、上記の例ではファイル出力とは無関係な処理でも
即座に後処理へ移動します。ですが、ここに1つの問題があり、多くは捕捉した後にほぼ「自動的に」
ディストラクタに記述された処理をスレッド毎に存在するスタックを遡って巻き戻しを行います。
（例外の反対者はこれを隠された制御フローというが、決して信頼性が低下するわけではないです、
カーネルの例外ハンドラを例に挙げれば、ただ挙動が合わない事と、多くの例外がある言語でのCPU例外の
捕捉はリカバリが不可能に近く、挙動が保証できない事でディストラクタ実行させて意味があるのかという
矛盾もあります）
それ以外の例外処理は概念的にはスレッドローカルグローバル変数とifとgoto/returnの組み合わせにしか
ならないので信頼性が低下したりはしません。また、C言語や昔の言語でgotoが嫌われていたのは、ラベルが
存在しないgotoだったりループ中のgotoだったり、プログラムのモジュール化を壊す制御であったためなども
あります。try-catch-finallyとは無関係ですが、同様に可読性が悪いように見えてしまうため、冤罪にされます。
そもそもアセンブラであればJMP命令にしかならない事をいつまでもグチグチ言うのは悪い癖です >>550
後半、BASIC言語を振り返ってみると、ラベルの無いgoto文はむしろラベルありより綺麗に書けていた。
gosubはラベル方式の方が良かったが。
Cのgotoはラベルが必須なのでラベルが浮いてしまって嫌われているという説がある位。 例外処理の問題点は、
try {
f1();
・・・
f2();
・・・
f3();
・・・
f4();
・・・
}
とtryブロックの中に沢山の関数呼び出しが有った場合、コード上ではどこでも例外が
起きる可能性を捨てきれないため逆に危険な可能性を排除しにくいことがある。
例えば、fputc()やfwrite()などで例外が起きることが分かっているならそれはそれで
良いが、全く関係のないf1, f2, f3, f4でもどれかは例外が起きる可能性があるなら
非常にプログラミングしにくい。 >>551
例えば、BASICでは以下の様な感じになるので、ラベルが無い事でむしろすっきり
見易かった。gosub文はまた別でいまの関数の様な感じで名前が付いている方が
分かり易かった。これは経験を積まないと理解しにくいかも知れない。
100 if xxx = yyy goto 120
110 ・・・
120 ・・・ >>548
構造化の無い暗黒時代に戻りたくないわ。
制御構文と構造化設計を破壊するぐらいならgoto使わないほうがマシ。破壊しない程度だったら許容できるかね。 Rustは学習コスト高いって言われてるけど
Scala辺りと比べても難しいですか？ >>555
別に特別難しいわけではないと思う
いろんな言語からパクってきてる要素が多くて、これまで一つの言語しか使ったことない人は学ぶべきことが多いってだけで
ScalaとC++くらい経験あれば余裕だろう コンパイラの文脈解析がこんだけ普及したのだから
safe gotoが存在するべきだ 言語自体よりも、情報技術の基礎が要求されるんじゃないの >>555
やってみるのが一番早いよ
https://ideone.com/
こーいうところを使うとPC側にコンパイラとか用意せずに試せる >>559
>>1にもあるけどhttps://play.rust-lang.orgのほうがいろいろ充実してる
てかideoneは1.33.0とかなのか、結構古いね playground、いつのまにか以前書いたコードが残るようになっててなんかうざったいんだけど、
初期のhello worldの状態に戻すのってどうやるの？（クッキー削除とかはなしで んな面倒なことするくらいならrustupインストールすりゃええやん >>549
ファイルへの書き込みは返り値promise等でもらっておいて他の作業を進めて
どうしても書き込み完了していないと作業を先へ進めてはいけないところでようやくawait等することで
例外処理も遅延(手続き的な後ろ化と多段時の上位化)ができますよね
あとOSカーネル内の話は
例外と割り込みをごっちゃにしているように見えます
いずれにせよカーネル内ではtry例外使わずとも多段にエラー返り値を返していけばいいだけでしょう
エラー割り込み時もメモリ不足もシステムコールならエラー値返すわけですし >>555
Rust はそれほど難しいというわけでもないと思う。
C に ML 風の型システムを付けたって程度。
普通のプログラマにとって目新しいと言えるのはライフタイムの概念くらい。
でもそのひとつが馴染み無さ過ぎるというか、
他の言語では意識せずに済まさせようとしてきたところを
あえて露骨に管理しようとしてるところがしんどいとは感じるかもね。 >>564
Rustのライフタイムは、鶏と卵の関係の様な部分で言語の動作が分からない。
どっちがどっちに影響を与えているのかの部分が。
自動判定の仕組みも一部だけ説明されていて一般法則が書いておらず、その場しのぎ的な言語仕様なのかもしれない。 non lexical lifetimeでググれば詳細な仕様出てくるだろ >>561
通りすがりですが、保存せずにただ試すだけなら
1.シークレットモードで新規タブ
2.playgroundのサイトを開く（ブックマーク登録からとか）
3.コード入力かコピペ作業
でどうでしょうか? >>569
そこには例が書かれてるだけで、数学みたいな意味でのちゃんとした厳密仕様は書いてないと思うんだよ。
Rustのライフタイムは数学規則のように機械的にパターンで処理できるような一般化された規則にはなってないという意味において。 厳密な仕様があるのは理想だけど、規格化された言語ですら数学的に厳密な仕様なんて存在しないしな
最終的にはCoqのソースコードで示される、とかはあるかもしれないが >>571
CやC++は数学的なパターンで処理できるようになってる。
そこにヒューリスティックなものは入ってない。 the abstract syntax tree でのライフタイムの解析から
the control-flow graph でのライフタイムの解析にしたって言ってるから
かなりマシン語に近いとこで判定してるってことだわな。
ここにいる奴に聞くだけ無駄w >>571
純lispくらいかね。
あるいはBrainfuckとか。 issue #25860って未だに解決されてないんだよね？
行きあたりばったりでライフタイム仕様決めてきた結果w Rust嫌う人ってなんでみんな #25860 の話するのって言われてんぞ >>576
太陽光発電は、ある意味原子力発電と言えるのではないだろうか。 2021 Edition ざっと読んでみたけど、次の2点以外は些末な変更だな
for e in [1, 2, 3] {}
がエラーにならなくなる
(IntoIterator for arrays)
クロージャーが構造体をフィールド単位でキャプチャーするようになる
(Disjoint capture in closures) >>582
マイナーチェンジだし2018も継続して使えるし特に問題ないよ 何年か前なら喜んでたんだけどな、どうしよ何の興味も沸かない
Docker触り始めた辺りからWindows用は趣味でも書かなくなってしまった… >>583 多分windowsクレートの説明文のRust for Windowsの直訳だとは思うけどこれは誤解するわ Rust for Windowsという名前がミスリーディング
(A) Rust (crate) for Windows (development)をRust for Windowsに略したら誰でも誤解する
狙ってるのかもしれないが
Windows API bindgen for Rustあたりが適当 このクレート普通にソフト作るのに使ったら移植性無くなるからライブラリ用かな? 最高が2000万円ってだけね。。
こういうので平気で300万円とかいい出すのが今の日本やで。 >>589
Windows専用のアプリを作る用途もあるのでは
一般的ではないかもだけど Rust for Windowsを欲しがったのはMicrosoft自身だろう
既にVSのインストーラー内部などでRust使用中なので rust for windowsで作る本作ってくださいお願いします >>594 Windows専用のアプリが作りたいならC#でも使えばいいと思うけど... >>594 Windows専用のアプリが作りたいならC#でも使えばいいと思うけど... >>590
そういう技術者にも射撃練習とかやらせるのだろうか？ windowsもそろそろNTカーネルを捨てる時期が来るだろうし色々模索はしてるんだろうな もし仮にNTカーネル捨てたとしてLinuxカーネル一択だと思うがな Linuxへの接近はここ数年目立ってるし無くはない話だな
独占市場と過去の互換性を捨てきれるか
仮想環境で過去の互換性を維持することも考えられる >>604
NTカーネル捨てるのはビジネスとして有り得ない。
せいぜいwsl路線を強化してlinuxカーネルを取り込んでいく方向だろ。 3才児が｢ぼくはうちゅうひこうしになるんだ！｣って言ってるようなもんだから生暖かく見守ってやれ OSカーネルに対するコンプレックスがすごい人がいるんだろ。
この前のlinuxドライバに関する議論でもそういうの感じるわ rustがgolangより人気が出ると思っていいですか？ >>609
Goはガーベッジコレクションがあるから？ GCとランタイム速度に困ったことのある奴だけ気にすればええ。 goとrustどっちが良いか迷うならgoやっといた方が潰しが効くと思う
自分はrust好きだからrust使うが なんでマイナー言語のはずのgoがよく言及されるようになったのかと思っていたら、AWSで使える言語の一つになっていた。
Azureでも使えるようだ。 サーバープログラムみたいな閉じた環境で、出来るここまでと決まってて
要らないこと考えたくないなら制約された言語選んだほうが良いかもな goでほとんど問題ないんだが、それだとrustの出番なくなっちゃうからね。 Go言語がマイナーならこの言語はどんだけマイナーになっちゃうのよ goとrustの違いが分からないような知識量ならgoやった方が不幸にならないかと 参照型はローカル変数にだけ入れて一時的な目的だけに使うことに徹してスクリプト言語の様な書き方だけに専念すればRustはスクリプト言語であるかのように使えて、習得は難しくないかも。
参照型を構造体の中に入れようとしたとたんCやC++では考える必要の無かった難しい問題が生じる。 例えばWeb系ならばRustがベスト
WasmでGC抱える言語をわざわざ選ぶメリットないからね こういう詐欺師が普通におるからrustは信用できんわ 詐欺師はどこにでもいるからな
とはいえ、webならwasmは正しくないとは思うがwasmならrustは結構正しいと思う wasm,rustでまともに開発してたら絶対そんなこと思わんわ。。どいつもこいつも馬鹿すぎる >>624
とこが詐欺？
あなたはWebブラウザ上のWasmでRustではなくGoを用いているのですか？ >>627
それはあなたがまともにrust使えてないだけなんじゃないですかねぇ >>572
形式的に書けているのは構文規則だけで
意味規則は自然言語で書かれているやんけ 「Rustはスクリプト的に書ける」とかいう謎の言葉言う奴沢山いるけどなんぞ？
同一人物か？ 我々が知らないところでevcxrが流行ってるのかもしれない >>633
Rubyと同じようなメソッドチェーンを使ったコードを見かけたから。 ドットでメソッド呼び出しする言語は大概そういうライブラリ設計あるでしょ >>637
C++やJavaでは見たこと無い。
JSでも余り見かけない。 そもそもメソッドチェーンって「スクリプト的」なのか？ 前々からヤベェやつだとは思ってたが
レベルの低さが想像をはるかに超えてた c言語みたいにcsvパーサーも自前で用意するような環境だとそらスクリプト的だろうね。 cargoみたいなパッケージマネージャがあるのもスクリプト的な要素のうちなのか？ cargoは低レイヤー慣れてる人からすれば邪魔でしかないけどね。 SourceforgeなどでRustが好きといっている人の大部分はレベルが低いだろう。
そもそもこの世の中、大多数から受けるものにレベルが高いものがあったためしがない。
好きな言語ランキング上位のJS、Pythonも初心者向け言語であることは誰もが認めることだし。 sourceforge？？？
stackoverflowの調査かなんかと勘違いしたの？ >>644
どういうこと？ベアメタル向けでもcargo使うのが主流だと思っていた >>645
使用者のレベルの高低と言語のレベル(?)の高低は一致するという主張かな？
言語のレベルが高いというのが最先端のテクノロジーを取り込むという意味ならrustの目指すところではないと思う
他の言語で実証されたコンセプトを取り込むと宣言してる(た?)はず
高レベルな言語が必要な人はこんな普及言語じゃなくてもっと尖った言語を使うか自分で作るべきなのでは >>646
ああ、そっちだった。
Stackoverflowも来てる人の頭の良さは一般大衆と同じくらいだから同じ。 >>648
そういうことじゃなくて、
・Rustをほとんど使っても見てないのに勝手に「好き」と言っていることが分かってる。
・Stackoverflowのような沢山の人が集まる場所の調査では、必ずJSやPythonのような初心者向けの言語が人気となるわけだから、そこの人々が好きだと思う言語は、JSやPythonのような感覚で使えると勝手に思い込んである蓋然性が高い。
ただし、現実はRustは実際には使ってないのに勝手に言っている。
ということ。 stackoverflowの調査の話なら、調査内容を勘違いしている
あれは「今Rustを使っている人が、今後もRustを使い続けたいかどうか」のアンケート結果をmost lovedと言ってるだけ
だからJSやPythonユーザの意見は入ってない
そもそもloveって言葉に語弊があるし、日本語にしたときに「人気の」とかなって余計訳がわからなくなってる たぶん「最も嫌嫌使っている人が少ない言語」みたいなのが正確な気がするな 「今使ってる人が次も使いたいと思うか？」ってJetBrainsの調査でも毎回入れてくる項目だな
海外のアンケートではよく見るやつ >>651
もし前半の通りなら、今Rustを使ってる人なんて極一握りの物好きだけだから
「love」なのは当たり前で調査結果が意味が無い。 一生でどれか一つのプログラミング言語しか覚えられないとして
Rust選ぶ人いますか？
選択したとして別にその言語がいきなりマスターできるわけでなく
ただその言語しか覚えられないというだけですが 今rustを使ってる人って、自ら進んで使おうとした人に限られるから
嫌いな人がほとんどいないのは当たり前だから、調査結果にバイアスが
掛かりすぎていることになるな。 そういえば C++ でメンバ関数の評価順序に関して設計者も気づいてなかった考慮漏れが見つかった
(よくあるパターンが実際には未定義だった) って話があったな。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
C++17 で修正されているはずだけど。
宣言的な表現や関数的な表現をプログラミング言語に取り込む試みは数多いが
現実は順序からは逃れられぬのだ……。 Rustがスクリプト的に書けるかどうかはおいといて、
個人用のツール書く言語をPythonからRustに乗り換えたっつー話は一応あるな
https://hayatoito.github.io/2017/faq/#programming-language >>658
Googleがnode.jsで書いていたものをRustにしたと聞いたぞ。 全部書き直すのは逆に効率悪そう
速度的にキツイ場合のみでいいんじゃないか？ どちらかといえば速度よりも変更頻度が動機になると思う
静的チェックツールも増えてはいるけどコンパイル型はいじる時の安心感が違う >>660
言語を跨いで呼出すときはその境界で色々な処理が挟まったりもするので、
まだらに入り乱れるような形になるとそれはそれで実行性能の足を引っ張ることもある。
状況次第なので一概には言えないけど、言語を変更すると決めたなら
そこそこ大きい単位で乗り換えるのが妥当な場合は結構あると思うよ。 >>661
それはあるね
個人用のツールだとそんなに真面目にテストも書かないから
動的型だと忘れた頃に改修したくなって詰む >>642
MSがdotnet対応のRust#出したらUnityワンチャンあるんやない？ GCとデストラクタが共存するC++/CLIはなかなか興味深い言語だった。 RustのGCって初期はまた復活されるかもーみたいなノリじゃなかったっけ？ @ pointerとか ~ pointerとかあった頃の話？ >>665
確かにそっちか
>>666
GCがあるRustって言うよりはunsafeを外部リンクで呼び出してるようなもんだろ rustが覇権を取るにはPHPみたいにドキュメントの翻訳をたくさん作ること
そしてサンプルコードを盛り込むこと >2021 Editionは2021年10月にリリースされる。今回のエディションは「Rustの使用感を大きく改善する」ものになるという
あんまり前にこんな発表しないでほしい
やる気なくなる >>673
ちゃんと発表資料見れば分かるけど、大して使用感変わらんよ
クロージャー使いまくりの人が一番恩恵を受けるかな 所有権は移動するときのほうにマークが出るべきなんじゃあ Rustの真似をしようとする言語がないのがふしぎだ https://en.m.wikipedia.org/wiki/Rust_(programming_language)
wikipedia見ただけだけど Crystal, Elm >>678
Elmのどこが？と思ってソースを読んだら
関数型言語なら大体持ってるEither型の名前を Result, Ok, Error にしたところがRust由来とな
うーむ持ってきたのは名前だけなのにInfluencedか Gleam
https://gleam.run/book/tour/index.html
OwnershipやLifetimeの考え方を採用した言語はまだ聞いたことがない 所有権の考え方を採用している言語としてはC++などがあります まあインスタンスの共有については何らかの言語サポートが入ってもおかしくないかもね DにもOwnership入ったとか小耳に挟んだだけなら GUIフレームワークをRustで作るうまみあまりなさそう >>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では例外を使わなくても困らないのです すまん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);
} ちなみにコンパイルエラーも貼っておく
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. 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.
見やすくした コンパイラは別に値まで見ないからな
clippyが意味のない分岐だよと指摘してくれるのかどうかは知らんが >>692
基本的に条件分岐はpredがコンパイル時に評価できる場合でも true/false 両方あり得るものとして扱われるよ
その後の最適化フェーズであり得ないルートは除去されるだろうけど最適化の結果でコンパイルエラー差異が出ないようにする考え方なんだと思われる
無限ループ専用の構文であるloopが導入された背景もたぶんこのあたりにある >>697
trueのときもdrop、falseのときもdropされるとみなされるということは、
if文によってheap領域で確保しているメモリを解放するかしないか場合分けできないってことじゃん
それって不便では？ >>698 これ元のコード見てみ
これifの条件がtrueだろうがfalseだろうがsub(&_a);は実行されるやん
ifの条件がfalseのときには問題なく実行できるけど､もしifの条件がtrueになって_aがdropされてしまった後にsub(&_a);が実行されてしまうと開放された値を使うことになる
だからRustコンパイラはエラーを吐くんだよ いや、普通に場合分けはできるが…
どちらかというとifの条件を変えるたびにコンパイルが通ったり通らなかったりするほうが不便では？
そこにifがあるってことは（将来的にとか何らかの条件で）実行される可能性があるからあるんでしょ
もし絶対に実行されないことが確定してるなら書く意味ないし 場合分けしたいならこんな感じで
if *_a.id == 1 {
drop(_a);
} else {
sub(&_a);
} >>700
言ってる意味がさっぱりわからん
>>692のプログラムにあるとおり
現実問題、将来的に決して実行されるわけがないif文というものは存在するし
if文があるというのは実行される可能性のあるの十分条件でもなければ必要条件でもなわけでもないんやが。
ワイが言いたいのは仮にrustの型システムを無視して>>692のコードをそのままコンパイルしたとしても
if文は実行されないわけだから安全なはずなものまでを省いているというところが不思議だってことや
つまりuse-after-freeバグが現実には起きないコードまでもif文の他の条件でUAFバグが起きるがために
ひとまとめにUAFが起きるとみなすrustコンパイラの姿勢がif文である条件のときだけfreeするコードを書くのを認めないようにみえるという
ワイの感想に繋がってるわけでして use of moved valueやborrow of moved valueを
use-after-freeとして理解してるのがそもそも間違ってる
The Bookを読んでLifetimeとOwnershipを復習してくれ >>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);
} これはrustでは弾かれるはずの「if文のある条件のときだけヒープのある部分をfree」というコードのはずだが
安全なCのプログラムや コンパイルは通るしランタイムエラーも起こさない。
メモリ安全なプログラムの中では、cで書けるプログラムのほうがrustで書けるプログラムより広いんだね
rustはメモリ安全なcのプログラムと同等な処理を書けない部分もあって不便じゃないかっていうのが結局のところワイの疑問になるんや
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや？
メモリ安全性を損なってるわけでもない処理ではないはずなんやがrustのコンパイラははじくぞ？ #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);
}
ほい完全版 >>705
unsafe使え、というかもうちょっと具体的な例じゃないと困る
今まで出された例だと「最初から絶対通らないの分かってるならif文消せばいい」としか思えないので 別にわざわざCで書いてもらわなくても安全なのは分かるよ
今のRustコンパイラで通らないのはボローチェッカーが最適化前にあるからなんで
部分的にでも先に最適化すれば通るようにはできるだろう
ただそれをしたい動機が分からない
本当にifが実行される可能性が一切ないなら単に消せばいい、といしか言いようがないので >>703
それただの論点そらしだよね
UAFってrustの独特なメモリ管理手法と相反する用語ではないし
use of moved valueやborrow of moved valueもUAFを阻止するためのものだよね
じゃあrustでは「if文のある条件のときだけヒープのある部分をfree」のコードをどう書くんや？ >>709
DroppableのメンバにBox<i8>持たせろ
仮に"drop"された後でもsubが正常に動くことが期待されているなら、そこで使うべきなのはdropではない というか >>701 で書いたif/elseの例はちゃんと「if文のある条件のときだけヒープのある部分をfree」になっているのに何か不満なのか >>709
UAFを阻止するためだけにあるものじゃないから
やり方は>>701で教えてくれてるやろ
とりあえずThe Book読んでね >>709
これでどうですか？
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=9b05ca192ab0fd529b6de05dcc64a8c9 解決しました。
なにはともあれありがとうございました。>>701の方に救われました。
ここまで関わってくださった皆様まことに協力ありがとうございました。感謝いたします。 「理論的に安全な任意のコードは通るべき」ってイメージだったのかな
実際にはそんなことはなくて、上の例のようなコードを通すためには色々なトレードオフがあるから
単に「理論的に安全」ってだけで無条件に実装されることはない
もっと具体的なユースケースがあって、みんなが「これは通らないと不便だよね」ってなったものが実装される
数年前に実装されたnon lexical lifetimesなんかはまさにその例だね クロージャの disjoint capture が破壊的変更になるのは分かるんだけど最初からこうなってなかったのはなぜ？ iter()とinto_iter()の使い分けが分からない
iter()じゃないといけない場合があるのは分かるんだが into_iterは所有権を奪いItemを得ることができる
iterは&Itemを得る
他のintoで始まるものは所有権を奪うことになってる >>711 Rustコンパイラが問題視してるのは開放された値を使ってしまう可能性があることで､それが修正された >>701 のコードは問題ないから通る >>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 as_foo(), to_foo(), into_foo() の違いも覚えておくとよいかもね Rust慣れたあと他の言語行くと
良い作法が身についてて歓迎される、とかありますか？ >>726
言語が異なれば同じことをするにも良い作法とされる方法は異なるだろうし、そんなに役に立たないかもよ。
むしろRustでは〜と言い出すとかえってうるさがられる可能性も。 rustでは変数のshadowing当たり前のように使うけど他の言語では嫌がられそう let value = value;
とか他言語で書いたらアホだと思われるし Rustはメイン関数かその次の関数のローカル変数にリソースを保持する形にしがちじゃない？
他の言語だとあんまりやらない >>730
他の言語でも同じだよ
それとも禁断のグローバル変数を使う駄目パターンをRustでもしたいということ？ pythonみたいな動的型付け言語ではよう見るけどさ
Rustではこんなん要らなくしてほしいわ ライブラリによってはデータを持ち運ぶということが不可能だったりするからグローバル変数必須だったりするんだよな
(具体例: serenity) log!() みたいなプログラムの各所から呼び出されるマクロや関数の実装の為には rust でも普通にグローバル変数使われているのでは
static 変数にするためには Sync が要求されたり mut にするために Mutex 使う必要があるから他の言語ほど気楽に使えないというだけで
グローバル変数そのものが禁断扱いされることはないかと
グローバル変数の濫用は他の言語同様嫌われるけどね 一般的にどんな言語においても何らかの外部のライブラリを取り込む時には
何か一つのクラスとかオブジェクトとか構造体とかに閉じ込めてしまって
それ一つだけ持ち運ぶからグローバル変数を使うことは無いでしょう >>735
static変数とglobal変数はスコープが違うだろ
global変数が悪とされるのは、そのスコープの広さだからね
いつどこで誰が変更するのか、また参照するのか、スコープが広ければ広いほど把握が困難になる
把握が困難になればなるほど、それだけバグを生む温床になる io周りは極論すればどう管理してもグローバルだからな。
プロジェクト毎に規約設ける以外にまともに管理する方法なんてない。 >>735
そういやロガーの設定ってどこに保存されてるの？
debug!() 呼ぶたびにMutexロックしてるのかな？ >>736
クラスの中に入れても、グローバル変数であることは避けられないし
どんな言語においてもグローバル変数は必要。 >>740
そんなことはないだろう。
確かにグローバルでも大して変わらんてものはあるけど、
loggerを引数で渡していくっていうような実装方法もある。 >>739
logクレートのstatic mut変数だね
ロックするのは初期化とレベル設定時だけ
出力時にロックするかどうかは実装次第 >>740
そのクラスの存在そのものがグローバル変数(相当)だという話？
それともそのクラスもしくはそのインスタンスをグローバル変数に入れて使うということ？
後者の意味ならば必要な範囲で引数として持ち歩けばグローバル変数を普通は使わないですよね。 大事なのは抽象化がきちんとしているかどうか。
各部品が妥当な意味に分離されているかどうか。
グローバル変数がよくないのは色んなパーツから横断的に使われる可能性があって
部品が不必要に密結合していることの表れだからであって、
そのグローバル変数のアクセス範囲が妥当な範囲に制御されているなら問題じゃないよ。
過剰な密結合を解消せずにグローバル変数を引数に置き換えてたら
影響範囲が見えにくくなってもっと悪くなることだってありうる。
まあどういう場合なら妥当なのかってのは色々と意見はあると思うけど。 >>746
まずは長くて区別しやすい名前に変えるのがスタートかね。 関数型言語やったことないけど、Rustいけるかな
JavaとC++はそこそこ経験あり Java 8とかC++ 14以降くらいなら結構似たような機能も入ってるし
そこまで大変じゃない気がする c++はともかく、cくらいはやっぱ理解してた方が早道な気はする。 以下のような関数を作ったんですが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(())つけるのがすごく気持ち悪いんですが、
返値なしのままどうにかする方法はないでしょうか if_chain使って
if_chain!{
if let Some(x) = x;
...
then { println!("{}", x); } } >>753
fooの型変えられないなら、戻り値Optionはクロージャないしローカル関数に留めるといいと思う
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=aa2bc019e7329f1b6bece2597b59ee8a Ok(())はよく使うがSome(())はないな
普通にif-letでパターンマッチするのでよくない？
if let (Some(x), Some(y)) = (x, y) {
println!("{} {}", x, y);
} loggerを引数で渡すためには
ロギングを行うクラスFooがどこかしら（コンストラクタか個々のメソッドで）loggerを受け取る引数を持たねばならない
これ、ロギングみたいな裏方の仕事がFooのインターフェース仕様に影響しているということで、
抽象度が下がってるやんけ；；；
引き換えに得られるメリットは、Fooのインスタンスごとにloggerを切り替えられるというおおよそ現実的にありがたみが無い機能だけ つか機能の分離と記述の分離はトレードオフがある
1+1=2の形式的証明がどんだけの糞みたいな分量のに成り得るかを見たらﾜｶﾙ
どっかの抽象度をつきつめれば別のところにしわ寄せが逝く
それで良いｼﾞｬﾏｲｶ人間の言語だもの、 皆様ありがとうございます
どうもSomeをある程度書くのは避けられない感じですね まさかstatic変数使ってるなんて、logクレートには失望したわ >>757
ログを裏方と考えるのも偏ってるし、ログ切り替えはデバッグ目的で普通にあるわ。
別にグローバルにするという選択が間違いとも思わんがこういう決めつけ野郎は邪魔だな。 サーバ側だとログを取るのが基本だし取り方も変えたくなるからlogger渡しは結構やるな
CLIとかなら雑にstaticでいいけど >>766
えー
これからは write() システムコールでプリントするわ >>762
近代的なログシステムならタグが使えるから
記録時に分っける理由がさらさらない
だいたい並列な事象を並列なまま記録したのでは時系列の解析ができないし、
そもそも>>762がいくら「ログは裏方じゃない」と叫んだところで基準が無い
アプリケーションロジックを汚してまでか？！という議論はいつまでもつきまとう 別に仕事で使ったことないならそういえばいいと思うよ。悪いことしてるわけじゃないんだから。 そういやLog4JでいうMDCみたいなやつはあるのかしら？ お前らslog
>>760
ただのzipやん。
ttps://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=01c2f30ff2a49dc57c917ec16947aadb まあloggingオブジェクトを複数作る仕事なんなら仕方が無いな シンタックスで判断しづらいもので性的分析するって、そのうち破綻しそうだな。 JPEG-XLのリファレンス実装作ってるチームがRustで再実装も始めてて驚いた
https://github.com/libjxl/jxl-rs
FirefoxにJPEG-XL対応を入れるかどうか議論するチケットで
今更大量のunsafeなC++コードを入れるのはちょっと……みたいな反応をされてた事と関係あるのかもしれない もう9.5%も行ってるのか
と言うかfirefoxからrustは始まったから当然か でも、大量の有名なWebサービスが一時的にRubyで書いていたのに、
しばらくすると他言語に書き直した歴史がある。
アメリカ人はなぜか言語を書き直すのが好きなようだ。
Rustで書いてもまた別言語に直すかも知れない。
なお、Googleドライブなどの各社のストレージサービスを統一的なAPIで制御できる
ライブラリも何故かGoで書かれている。
メンドクサイ。 >>781
遅い方から速い方へ書き直すのよ
特にスクリプト言語からC++/Rustへ書き換えるとサーバー数を1/10にできるケースもあり規模によっては経費激減ね
GoもGCあるから場合によっては他へ書き換えられる対象になりうるかも
Rustが他へ書き換えられる可能性がもしあるとしたら今はまだ存在しない新たに出現する言語へ なんでClippy大先生がcargoでインストールできるクレートから外されるの？ rustupでインストールできるからでは
rustcとバージョン合わせないといけないから他のcrateと同じ扱いはしづらいのでは Ruby on Rails の時価総額は、
Shopify が15兆円、
民泊のAirbnb が、大手ホテル3社の合計以上の10兆円、
Github が8千億円
これぐらい巨大でも、Rails で出来る。
時価総額が千億円以上になったら、Go, Elixir を考えてもよい
食べチョクは売上50億円らしいけど、
若い文系女が1人で起業したような会社は、Rails で十分
売上が千億円を超えたら、考えてもよい ウェブシステム全体の実行コストはネットワークや IO にボトルネックが有るので
システム構成やらなんやらで工夫するのがまずやることで、
言語の速度が少しばかり速いのはそんなに効いてこないよ。
という話もよく聞くんだけど、実際のところどんなもんやろね？ そりゃそうね
でも実行速度だけで選ぶわけじゃないからね 今まではハードにぶん投げても大丈夫だったのが
ハードの進化の鈍化でソフト側が工夫しないと駄目になりつつあるって話ってマジ？ いやそこでソフトで頑張ってもほぼダメだろ。。アーキテクチャで分散化考えないとって話じゃないかね >>788
ハードウェアがもう伸びないってことではなくて、 CPU の速度が単純に速くなるという方向ではもう伸びにくいって話。
電子の大きさは変えられないから際限なく微細化できるわけではない。
わかりやすい例で言えば今のパソコンはマルチコアが当たり前になってて複数の CPU を載せる方向で性能を上げているが、
マルチコアを想定してないソフトをマルチコアパソコンで動かしてもひとつのコアしか使わないので性能が出ない。
高価な GPU を乗せても GPU を使うプログラムになってなきゃ意味がない。
ハードウェアの総合的な性能を上げるには色んな工夫があり得て、それらを実現すると同時に
ソフトウェアは「ハードウェアに合わせて」「ハードウェアの性能を引き出すように」工夫がいる。
これは今までにも普通にやってたことで、今になって必要になったわけじゃない。
小さな変化の積み重ねなこともあれば大きな変革を迫られることもあるってだけ。 後藤弘茂のWeekly海外ニュース■ Prescott/Tejasは5GHz台、65nmのNehalemは10GHz以上に
ttps://pc.watch.impress.co.jp/docs/2003/0227/kaigai01.htm
当時は景気よかったっすね。すぐ後に爆熱で日和ったけど
そして今、300Wの時代・・・
てか並列化によるスループットの向上はこのあたりから検討されるようになっていた気が >>784 でも何故かcargoだけはcargo install cargo --forceとすれば自分でコンパイルしたもので上書きができる謎 よくわからないんだけどこれ、C言語のポインタ渡しが諸悪の根源で、そこを断ちさえすればC言語も所有権概念を取り入れられるの？ >>793
C言語において、ポインタは大発明で、それによってリンクリストやツリー構造
が簡単に実装に出来る様になった、大変重要なもの。
C言語からポインタを絶てば何も残らない。 Javaキチガイはポインタ使いこなせない
日本のMSの社員がソレだった
破棄忘れてやんのw RAIIなしで良いなら多少の拡張で所有権の概念取り込めるかも知れないけど
絶対スマートポインタ欲しくなるしCの表現力だと使いづらい物になりそうな気がする >>794
>C言語において、ポインタは大発明
笑笑 Cと比較するのは流石に乱暴だろ
C++と比較するべき
で、C++でできなくてRustでできるものというのは現状存在しない (今後その差も埋まっていくだろうが)
C++とRustの違いはひとえにスタンスの違いだよ
自由奔放なC++か良いコードにカッチリ導いてくれるRustか
意欲的に新機能取り込んで発展してるのは両者とも同じ >>798
>C++でできなくてRustでできるものというのは現状存在しない
こういう比べ方はアホ
チューリング完全ならなんでもできるじゃんみたいなことになる
できるできないの線引きが恣意的 >>799
バカアホじゃなくて、Rustでしかできないものの例を挙げてください
そうすれば一単語で反論の余地なく終わるんで >>800
C++でできなくてRustでできるもの
から
Rustでしかできないもの
への華麗な転身www C++はMemory Safetyをコンパイル時に担保できない
Rustを使う一番の動機 >>802 C++とRustの比較において｢C++でできなくてRustでできるもの｣と｢Rustでしかできないもの｣は同じ意味だから転身でもなんでもない
https://i.imgur.com/3svkdus.png Cloudflareの画像処理責任者を名乗る人も、これ以上C++ライブラリを増やすのはイヤでござると発言してるな >>804
C++とRust以外にも言語はたくさんある Rustのモジュール（ファイル分割）の仕組みはC++のヘッダー＋ソース（＋名前空間）より扱いやすいと思う
C++は分割コンパイルが主流だった歴史的経緯があるから仕方ないけど事前の宣言が必要なのは地味に面倒くさい >>806 この会話の流れではC++とRustの比較をしていたから ライフタイムによるメモリ管理はRustオンリーだろ マイナーな環境だとC++プログラムは様々な理由でコンパイルが通らないことがよくある
Rustは基本的にはそういう事ないし、コンパイラ実装が一つしかないというのも利点に働く C++との比較を議論したいなら専用の隔離スレでどうぞ >>793は言語レベルのサポートがほしいんだろ？
substructural type systemがないと無理。
>>809
MLkit,RTSJ,cyclone,ATS/ATS2。学術的にはとっくの昔に廃れたぞ。 WinUIとRustやってる人いる？
同じネイティブのMFCとかと比べて、やっぱり生産性は高いんかな メモリ関連って原因不明のバグ引き起こしやすいしトータルな目で見れば上がるんじゃないだろうか >>810
gcc-rsとかのプロジェクト始まってるけどそれはネガティブなことなのかね >>810
そういえば、C++のSTLは、VSでは動くが、BSD系のLLVM用のlibc++は、
なかなか上手く動いてくれない。理由は、libc++が、その
基礎関数として滅多に使われないようなMB・WC文字変換関連や、
NAN、INFINITYなどのfloat/double調査関数など、昔ながらのC環境では
定義されて無いような(新しい)Cの関数を大量に必要としているため。
その意味で、WasmのWASIなんかは、たとえCUIだけであっても
世界共通の関数群を整備してくれるのだとしたら有りがたいかも知れない。
でもWASI自体の移植作業が必要になるから一緒か。 >>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はなかなかそうではないようだ。 C++ライブラリがisalpha_lなどを用いてしまったら、速度面でC#やJavaなど
に比べた優位性が少なくなってしまうからかも知れない。
つまり高速化のためにやたらと移植性の低い方法を使っているから、
スムーズに移植が進まない。
それか単純にC++ライブラリを作る人の技術力が低いからだろうか？ >>801
すまんが、Rustはもっと出来ない気がする。 RustスレでC++の話題が出てしまうのはもはや運命なのか >>820
そりゃ better C++言語として作られたんだから当たり前でしょう あおられてもダメな理由がわかりまそん
びっくりはするけど c++との比較はガファムが結論出してくれたからもう話すことなどない 依存するクレートの依存するクレートの依存するクレートの以下無限ループまで全部チェックしないと駄目ー？(´・ω・｀) チェックするツールとか誰か作っていそうだね
バイナリを診断するよりは簡単だろうし >>826
念のためマジレスすると公開した人がいつでもlocalhostを〇国サーバーのアドレスに書き換えられるってこと
githubのオープンソースでそれやったらすぐにばれそうだけど
ビルド時ならともかくエディタ起動直後のコード解析でデータが送信されるのは盲点やね ビルドしなくてもファイルを開いたらコードが実行されるというのはよろしくないね
ファイルやネットワークならアクセスされる側でブロック可能だけど
メモリはサンドボックス内のみで展開・実行されるようにしないとブロックできない気がする
サンドボックス化できなければ
cargo auditやcargo crevを通して怪しいcrateだけ自分でチェックするとかかな 見た感じVSCode以外でもマクロが実行されるようなことをすると駄目っぽいが MS自身がやりたい放題だからメンタルも伝播するだろうな そもそもこれ本質はライブラリの信頼性って問題だと思うんだよな
Rustだけじゃなく他の言語にも言える話 中国のipアドレスは全部ブロックしておくのが正解だな IntelliJ/CLion でもproc_macro実行されちゃうの？ >>844
LSP はエディタとの連携を前提として明文化された規格にしたってだけで、
処理系にコンパイルさせた結果をエディタの表示に反映させるというのは昔から有ったんだぞ。 >>847
> 処理系にコンパイルさせた結果をエディタの表示に反映させるというのは昔から有ったんだぞ。
いやそりゃそうだろ
その説明じゃ flycheck 等と差がない >>848
Rust のコードをビルドしないときでもエディタ経由で勝手にビルドする
(そのときに悪意のあるコードも走らせられるかもしれない)
という文脈の中で >>844 の発言があったので、
それは LSP が作られる前から同じような危険性はあっただろうという反論を私はしたつもり。
LSP のせいじゃなくてコンパイル時に出来ることが多い Rust のせいって話。 はあ話になんね
こいつといいQZといい「何か物申したい」という気持ちだけで生きてるから常に空回ってんだよな proc-macroがwasm化されてサンドボックスで動くようになればマシになるのかね
そもそも怪しいコードが依存関係に混入しちゃう時点でcargo runなりtestなりしたらなにされるかわからん訳でproc-macroの件自体にどれくらいの影響度があるのかは分からんが crossでx86_64-unknown-linux-gnuをtargetにクロスコンパイルしたらいいんじゃないか?
あれ確かDockerで動いてたはず 自分のPC向けにクロスコンパイル用ツールを使ってコンパイルするのがクロスコンパイルというかどうかは知らんけど >>823
特定のエディターの問題ではなく
特定のプログラミング言語の問題ではなく
自分が意図していない自動マクロ(プラグイン)を使えば自分が意図していない動作をするだけの話
大昔からあらゆる環境で起きていること コーディング時、ビルド時になんでもやらせようって発想が間違ってんだよ。 マクロはやっぱ悪よな、無いと辛みが増すから仕方ないじゃなくて無くても何とか出来る仕様にすべき 今回の>>823の問題に限っていえば
そもそもLSPを使う人のためのプラグインなのだからLSPのlocalhost:8080に接続に行くことは何の問題もないよね
問題としているのはSSHの秘密鍵をそこへ自動送付していること
LSPそこまで詳しくないのだけどそれはどうしても必要なことなの？ 快適なエディタと快適なIDEの区別がつかなくなったバカどもがゴリ押しで流行らせてる >>857
>LSPのlocalhost:8080に接続に行くことは何の問題もないよね
localhost:8080はLanguage Serverじゃないよ >>860
それはすまなんだ
じゃあ何が問題になってるのかな >>861
LSPをセットアップした状態だと「VSCodeを起動しただけで」自動ビルドが走ってしまって悪意あるprocedural macroが実行されてしまうこと
手動でビルドすれば同じことになるのでそこは問題の本質じゃなくね？とは思う LSPというよりrust-analyzerやrls、cargo/rustcの問題と言った方が正確かな では>>823で指摘されている問題点「自分のSSHの秘密鍵が勝手に読み出されて送信される」はどの部分がその動作を要求しているの？
本当に必要な動作なの？ 手続きマクロの展開なのでcargo checkでも起こり得る
言ってしまえばRustの言語仕様そのもの
解決策は>>851の言うようにサンドボックス化するみたいな方法しかなさそう >>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 このコード例はめちゃくちゃわかりやすい。問題は置いといてgoodなコードだ。 crate-typeがproc-macroのときはffiを禁止して使用可能なextern crateを
安全性が保証されたものだけに制限するのがRustっぽいかな
proc-macro専用のstdが必要になるけどno_stdと同じ感覚でmacro_safe属性をつければいい そもそも普通はproc-macroなんか必要ないだろ
特殊用途以外では一律禁止してよいのでは？ >>843
マクロ展開すればどんな環境でもできるよ。
>>823はmulti-root workspaceの構成間違ってるから
IntelliJRustだとマクロ展開されないけど。
>>869
custom derive全部禁止だから当然thiserrorもserdeもdelegation系も禁止な。
ボイラープレート全部手書きしろよ。 頭悪い奴らばかりで議論にならぬ
趣旨と仕組みはreadme書いてあるのに。。 今勉強中なんだけど、Rustと合わせた時のgdbの使い方を教えてくれんかな
行指定でb main.rs:10みたいにブレイクポイントを指定するのってどうやるの？
＞No source file named main.rs.
みたいに言われてしまって、どうやって行指定でブレイクポイントを設定するのかよくわからん
ソースのあるディレクトリがわからないのかと思って指定しても結果は変わらず・・・・
あと、ソースを表示しながらステップ実行したりってどうやるの？ ああ、デフォルトで-gつかないのか・・・・
でもlldbが主流っぽいし、それ使うかな iPhone開発でMac必須になったことで強気に出すぎたか。
Macは滅びると思っていたらx86系になってからなぜかしぶとく生き残ってきたけど、
もうだめかもな。 lldbを試しに使ってみてるんだけどさ
これって、ステップ実行するたびに自動で毎回「memory read --size 8 --format x $sp」をやってもらうことってできないの？
gdb-pedaを使っていたときはスタックの中身が自動で見れてたんだけど、なんか似たようなのないのかな？ >>878
iphoneアプリ開発のためにmacが生き残ってるのは面白いと思ってる
元マカーだからほんと言うと寂しいし悲しいんだけど rustのlinux kernel対応の話ってどうなってゆの？なんだかずいぶんと作業が難航しているうだけど
それってrustのどのあたりの言語機能が悪さをしているのかね >>873
シンボリックデバッガはまだ有名どころのフロントエンドが
ステップ実行できる程度しか対応してないから、アブソリュートデバッガ併用になる。
シンボルでブレークポイント設定できないとか実行に問題あるとかまだ普通。
msvcツールチェインは特に。
>>877
ねねっち死んだなって思ってたけど現実もか。
>>878
世界シェア15%切ったし頼みの日本シェアすら50%切ったからもう
iPhone専用開発機も持たないだろう。
rustだとandroidほどバインディングが充実してないから開発やりずらいだろうし。 >>881 大部分がRustで書かれたRedox OSっていうOSがあるからRustでカーネルやドライバが書けないというわけではないと思う
恐らくCで書かれた過去の遺産との連携で手こずってそう >>883
日本でのiPhoneのシェアは、どんどん減っているはずなのに、ググると、
増えているデータになっていて、増えているのに50%を切っているというわけの
わからなさ。
記憶では、70%くらいまでいって、下がった結果、49%くらいになったはずなのに。 実際の開発状況はこっち見たほうがいいかな
https://github.com/Rust-for-Linux/linux
ざっと見た感じ難航してるっていうより単にやること多いってだけに見えるけど >>885
出荷ベースだと二三年前に65%超えてて2020Q4に約49%だからそれであってるよ。
>>888
OS作ってる人らって開発環境はなんだろ？
intellijrustはデバッガ使えるIDEとツールチェインが限られるし
matklad.rust-analyzerは環境変数の扱いがめちゃくちゃで
環境変数見に行くとまともに動かないし。issueばっか増える。
お前らどうしてる？ツールチェインと環境は？ rustでOSてもう何回目の話だよ。。過去レスでもあされや >>889
cargoが-Zbuild-std対応したからビルドに特別なツールは使ってない
rust-analyzerもno_std対応してて特に支障なく動いている
(補完候補にstdが出てくることはたまにあるけど)
環境変数がおかしいというのはどういうこと？
build.rsが環境変数に依存している？
それとも env!() を使っている？ >>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% 元々の話はMacがM1になって開発環境として終わったという流れから
残るMacの存在価値としてiOSアプリ開発環境がありそのシェアがまだ高い(?)という話だと思うけど
多くのサービスがスマホ専用アプリを作らずにウェブアプリ(PWA)化してる状況ではシェアだけの問題ではないと思うな >>893
最後の行、flutterなどのマルチプラットフォームライブラリの登場によって、
ウェブアプリからnativeアプリ型への流れが出来ているという説もあるが。 >>894
後継のSwiftが出来たのでObjective-Cの人気低下はともかく、そのSwiftも人気低下。
その理由が、AndroidとiOSでソースを共通化したい人が増えたからだそうだ。
SwiftはApple専用だから。 lldbでpedaみたいな表示するのってこれが良いかな
便利そうだけど保守されてんのかなこれ？誰かしらん？
https://github.com/snare/voltron 来週ついにRocket v0.5が出るぞ
安定版Rustで動くようになる RUSTってORM、Dieselとかいうやつしかねえの？
SQLを明記したいのでJavaでいうMybatisみたいなのをさがしているんだけど、中華の変なものしかない。 サーバー側はネイティブコードでクライアント側がwebassemblyで動くとかあるの？ VSCodeアップデートしたら急にDo you trust the authors of the files in this folderとか聞かれてどうしたのかと思ったけど>>823みたいな奴の対策かね >>898
Dieselに人が集中してる。
クレートのall-time downloadは200万超だし、
リポジトリのコミットは約4000、closed issueは約1200。 >>898
rust-postgres 直接使えばええやん wasmはあらゆる環境で使える汎用コンテナとしてすごい将来性あるみたいだね >>905
目的外利用だし、そういうこと言っている人がいることは知ってるが、実際にそんなに将来性があるとは思えんが。 wasmはもともとウェブにC++を持ち込みたいというEmscriptenの情熱から
始まったものであって、そんな汎用目的のためではない。 そのウェブにC++を持ち込むという夢はその後どうなったの？ zoomみたいなビデオ会議アプリでwasm使ってるってっ聞いた
あとカメラを使った運転免許証認識とか 当初の目的とかどうでもいいだろ
Linuxだって当初の目的は趣味のおもちゃだぞ
>>907 もしもWebAssemblyとWASIが2008年に存在していたら、Dockerを開発する必要はなかった
ってDocketの開発者が言ってた件だな >>911
どうもブラウザ外使用を盛んにアピールする人は胡散臭い。 いや、M$の寡占を阻止し正しき未来を創るため立ち上がったとエリックレイモンドが言ってた。 >>914
そいつ人類の中で2番目に嫌いなやつだわ。
一番目はストールマン。 >>915
ソフトウェア著作権を否定するあんたと同類だよ。違うのは現行の法律を尊重するかしないかだけ。 >>912
んなこたない。
2008年にあっても今と扱いは変わらんと思うわ。
結局何らかのコンテナを使うことになる。
OSの件でもそうだが、この界隈は大袈裟にアピールしすぎだわ。 Jail、OpenVZ、Solarisコンテナ、LXCみんな早すぎたのだ Istioでの使われ方みたいな事例が増えると思う
luaの代替 JVM自体がローカルのシステムでグローバルだったからだろ。
低レイヤーをラップするための上位レイヤーのが互換性効かないものになってるとか、よくある話だわ。 >>916
俺は著作権は尊重する。
尊重してないのはFSFの方。 じゃあOSSを利用する場合はちゃんとライセンスに従わなきゃな。GPLだろうとなんだろうと。 別に俺はGPLは嫌いだから自作プログラムに紛れ込ましたことは無いが、
GPL自体が自ら著作権を放棄してるな。
「COPYLEFT」 の LEFT = 放棄、左。左翼、共産主義。
「COPYRIGHT」の RIGHT = 権利、右。右翼、資本主義。権利=著作権。 GPL は著作権の放棄ではない。
その上で自由な利用を保証するという契約をするの。
著作権を放棄してしまったら自由な利用を強制する根拠を失ってしまう。 アメリカ人はめちゃくちゃで、ライセンスと契約を区別したり訳分からんこと
言って、煙に巻こうとしてるだけ。
GPLは、その名の通り、「ライセンス」といっている。
COPYLEFT と自ら名乗っているし、著作権で無いだろう、あんなもの。 >>928
GPL は著作権ではない。
著作権は作者が持っていて、契約 (の内容) が GPL なの。
なんでそんな簡単なことがわからんのだ。 著作者は作者として強制できる権利。
強制する内容が「自由に利用すること、自由に利用させること」であることが
一般的に作者が求める強制力ではないよねということを茶化して Copyleft と言っているのであって、
強制力の根拠はあくまでも著作権だよ。 あれが、本気で自由と思ってるのか。
頭大丈夫か？
自由じゃないからこそ、言葉だけ自由と名乗ってるに決まってるじゃん。
ようは、不自由なことをやることも、自由といや自由、みたいに皮肉みたいな感じで
言ってるんだろ、彼らは。
それか頭がおかしいかだ。 ハァ〜〜〜〜〜また固定ハンドルが物申したさベースでデタラメ言ってる
まずライセンスと契約は別物ね
ライセンスと契約を混同するのはよくある誤謬
GPLにおいても、これは契約かライセンスかといった議論は昔からあるから勝手に勉強しとけ
勉強したところでここで発表はするなよ邪魔だから
> 自由な利用を強制する
これも、なんでそうなるのだってくらい愚かしい解釈
「自由」の定義をストールマンとか江添の言ってるそれに委ね過ぎて支離滅裂になってるって気付け？
辞書通りの「自由」ならライセンスも警察も裁判所も要らないから
GPL のポイントは二次的な生産物も GPL であれと要請してるところ
「だからそれを私は自由と呼んでいるんです！」と叫ぶのかな？
日本語勉強しろバァ〜〜〜カ
あと著作権著作権って簡単に言うがこれは国にもよる
たんじゅんなアタマのつくりしてるね
俺なら恥ずかし過ぎて固定ハンドル外してるわ
今に始まったことではないが >>932
この程度のバカは見飽きたのでもうちょっと
変わったこと言ってくれ 即レスで
恥ずかし過ぎて固定ハンドルを外して
何ら具体的な反論をしないことで完全服従の意を表明しつつ
一方でタダで敗北アクメを晒すわけにはいかないので「バカ。陳腐」という当たり障りのない罵倒も置いておく完璧なレス
のように思えてしまうが、なんの用事もないのにわざわざ安価付けてきたコイツが当人じゃない可能性ってナンボほどあるんだろうか >>932
GPL ほどの広く使われているライセンス形態がその程度の理屈の建付けがちゃんとできてないわけないだろ。
詭弁と言えば詭弁なのかもしれんが、お前ごときに突き崩せるほどの安普請ではないわ。
GPL1 のリリース日の時点ではアメリカがベルヌ条約に加盟して無かったから
それでも国際的に通用するように方式主義にも配慮されておる。
中国に対してさえ (実態はわからんが少なくとも法的な理屈の上では) 通用する GPL が「国による」とかいう雑な
理屈で回避できると思ってるのか？ >>935
GPL の建付け (？) の話なんか全くしてないし、回避 (？？) する話なんかもっとしてないんだが、一体何に猛反論してるつもりなのだキミは
関係ない話ベラベラし始めることこそ典型的な詭弁だよ（この場合目的が全くわからんが）
>>932に書いた内容といえば
・ライセンスと契約を同じもののように語ってるのが典型的な誤謬であると指摘して
・「自由」という語の使い方が自由過ぎることを糾弾して
・諸々の根拠を著作権に委ねるならその運用は国による要素を多分に含むと示唆している
というこれだけで、これらには返す言葉もないというのが本音でしょう
> GPL1 のリリース日の時点では
これはお前が今突然言い出したことなので元々の話とは全く関係ないが、GPL が当時と同じように理解されて運用されてるのと思ってるならやっぱ単純なアタマのつくりしてるね >>936
ライセンスは契約だし、 GPL が言うところの「自由」は定義されている。
その「自由」が辞書的な意味とは異なるかもしれんが、 (この場合の) 意味は明白で解釈の幅はない。
「自由」という言葉をあてるのがクソというのがあなたの主張？
著作権の運用が国ごとに違うのは仕方がないが、
GPL の考え方に法的根拠を与えるには他に方法がないのも事実だ。
クソみたいに著作権意識のない国では通用しないから GPL は無力だということが言いたいの？ >>922
Goにホストされるって敗北感
そもそもホストはGC言語なのにわざわざそれを封じて縛りプレイしてるんだからアホくせえわ アホくせえが手段が目的化する奴が多いのよ。言語にこだわるやつってのは。 >>938
>その「自由」が辞書的な意味とは異なるかもしれんが、 (この場合の) 意味は明白で解釈の幅はない。
ええ？？？ >>933,937,939,943
これは恥ずかしいw こんだけ言われてなんでまだ「ライセンス＝契約」で行きたいんだ？
そこが覆ると自分の主張も破綻するから？
まあ難しいところではあるだろうと思うが、「ライセンスと契約は等価じゃない」ってのはあらゆるレイヤで真でしょ
ことOSSにおいては「契約はしてないけどライセンスはされている」という状況が山程あるし、そこ混同するのはやっぱ問題かと ライセンスの定義についてはどこで合意が取れてんの？
それともそういうもんは存在しなくて
定義については毎回言い争ってるの？ GPLについては、ソース公開しなければならないことについては大量に述べられて
いるが、非公開で良いケースは僅かしか語られず、その場合でも沢山の例外が
述べられていて結局、非公開にするのは茨の道になるようなライセンス。 GPLの例外条項は結構曖昧で解釈の幅がある
オレオレ解釈は散見されるが最悪争う覚悟は要りそう
あとライセンスとは全く関係無い次元で製品に使うのみで
プロジェクトの開発に貢献していないと晒されたり GPLと聞いて。
自由については「誰の」自由かを明確化しないと混乱するから省略するな。GPLの自由はユーザーの自由で、それを実現するためにプログラマの自由を制限している。
ライセンスは文字通り「許諾」で、相手の同意を必要としない。契約は相手と自分の同意を必須とするから、GPLみたいに相手の同意を前提としていない仕組みを「契約」とするのは弱い（と思う）。
だからGPLでは著作権を使って、違反者にプログラムを使わせないことを強制する枠組みを用意している。 ソースコードを公開してもかまわないプログラマの自由を最大化するために作られているんだよ。
逆に言えばソースを隠したがるプログラマのことは考えていない。 >>951
ソースを公開しても構わない連中の意図に背いて
ソースを公開しないプログラムで金儲けしてる連中が
ソースが公開されてる物に独自の拡張を加えて独占する事が往々に起きてるぞ >>949
実際、めちゃくちゃややこしい。
結局、なるべくソース公開させたいんだと悟った。 rustなんだからせめてMITかApacheの話しろよ RustでGPLなクレートはほとんどないけどあったらまず使わないな >>956 ワイは別にGPLは気にしないな
どうせGPLなクレート使おうが使わまいがソースコードは公開するから ライブラリにLGPL採用する場合はcrate_type=dylibにすべき？ >ライセンスは文字通り「許諾」で、相手の同意を必要としない。契約は相手と自分の同意を必須とするから、GPLみたいに相手の同意を前提としていない仕組みを「契約」とするのは弱い（と思う）。
>だからGPLでは著作権を使って、違反者にプログラムを使わせないことを強制する枠組みを用意している。
論理が逆転してる。
許諾しない限り著作権により他者はそのソフトウェアを利用できないんであって、その許諾を行うのが許諾契約なわけ。
契約が成立していなければ単に利用できないだけ。 >>961
原著2版は来月発売では？
Safariか何かで電子書籍版が早期リリースされてんのかね GPL(LGPL含む)の問題は関連する全てのコードに干渉すること
GPLと干渉しないコードで固められるなら良いが、現実的には難しい事も多い
この場合例外条項の適用を検討することになるけど一般的な解釈はほぼなく自己責任となる
自分がGPLなコードを使いたくない理由は大抵これ
>type foo.bat
GPLなコマンド -i a.wav -o b.wav
プロプラなコマンド b.wav
>
がGPL違反とか言われててもどうしようも無いじゃない
Linux環境でも実用性を考えるとプロプラレスは難しい。nVidiaがらみとかwineとか >>966
https://www.gnu.org/licenses/gpl-faq.ja.html#NFUseGPLPlugins
> それはプログラムがどのようにプラグインを呼び出すかによります。たとえば、プログラムが単純なforkとexecでプラグインを起動し、通信するだけならば、プラグインは別のプログラムであり、プラグインのライセンスはメインプログラムになんの要求もしません。 >>968
それはプラグインとして解釈できるかがポイント
>>966の例だとGPLなコマンドとしてffmpegにプリプロセスさせるようなケースで
「GPLなコマンドが無かったら機能しないのだからメインの一部でありプラグインではない」
などと主張されたら自分では反論できない >>969
そんな主張はFSFもしてないけど誰がしてるの？ >>970
GPL警察・・・はともかくとしてもライセンス文やFSFの主張と矛盾が生じない実装であることを証明できないとリスクが高い
>>968の
>「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか? (#MereAggregation)
には
>逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離したプログラムの間で使われるコミュニケーションメカニズムです。
>ですからそれらがコミュニケーションのために使われるときには、モジュールは通常別々のプログラムです。
>しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、
>それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
とも書かれている。別プロセスとして利用しているからGPLの影響を受けないとは限らないと読める
あとGPLにもかかわらずプロプラのライブラリ等を利用する機能があるアプリはプロジェクト自体は問題なくても
運用時にGPL違反になる可能性は非常に高い 前にも同じような流れになった事あるよな
同じバカかな >>964が示されてもまだここで続けようとするからな
続きはあっちに書きそのURLをこのスレに書けば
続きに興味がある人はそれを見るのにこのスレで続けようとする
このスレでマウントをとること自体が目的なんだろう ライセンススレを知っている人なら判るけど論理的な議論にならないからな
条文には「〜〜」と書いてありFSFの解釈は「○○」だから××と考えるのが妥当
みたいな流れは見たことないし。ソース無しで俺解釈を唱える人はいるけど ,r"´⌒｀ﾞ`ヽ
／ , -‐- !､
／ {,}f -‐- ,,,__､)
／ / .r'~"''‐--､)
,r''"´⌒ヽ{ ヽ (・)ﾊ(・)}､
/ ＼ （⊂｀-'つ）i-､
`}. （__,,ノヽ_ﾉ,ﾉ ＼
l ｀-" ,ﾉ ヽ 頼む、どうか彼らを許してやってくれ彼らはゴリラなんだ
} ､､___,j'' l >>970
俺は、このスレに書いた人とは別人だが、俺もそういう主張を読んだことがある。
例え別プロセス、別コマンドであっても、そのコマンドがなければそのアプリ自体
が全く成り立たない場合には、GPL感染すると。
プラグインや拡張機能ならセーフだが、GPLなプログラム無しには基本機能さえ
成り立たないようなアプリやOSは、GPL感染してアプリやOSもソース公開しなく
てはならないと主張されていた。 >>979
ライセンススレでやれって >>964
そんな主張を誰がしてるのかと問われてるのに
誰が言ってるのか不明な話をしてもしかたないだろ GPLなクレートがかなり排除されてるRustはライセンス談義に最も向かない言語だろう twitter見ていて分かって来たことだが、GPLを支持している人は、大体、
ほぼ全くプログラムしないか、理系でもなければ、物づくりとは全く接点が
無い人が多いようだ。プログラムしてもちょろっとだけ。
俺が知る範囲内では哲学科出身の人がやたらとGPLを推進しようとしていた。
2ch/5chだとそれが見えてこないので話がややこしくなる。 >>983
GPL/LGPLと無縁のマルチメディアデータ処理関連のクレートを教えてくれ。それ使うから
歴史的事情もあってlibavcodecをはじめとする実績のあるコードはGPL/LGPLばかりなんだよな
特に動画は特許とGPL/LGPLで板挟み >>986
プログラムを配布しなければGPLだろうがなんだろうが関係ないだろ。 >>986
動画も音声もどうせ特許で真っ黒なんだからどうでもいいじゃん GPLを推進してるほとんどの人はプログラムほとんど書いたことない人。
これは本当の話。プログラミングがどういうものか分かってない。
大量の資料を見て沢山実験してやっと方法を見つけてコードに直している
という苦労や努力、時間が理解できてないからGPLが社会を良くすると
勘違いしている。 結果のコードは30行とかでも、それを見出すのに非常に大量の時間を
かけて、googleで検索し、StackOverflowのQ&Aを10個以上読み、
書いてある通りにやっても大部分が失敗し、JavaScriptの公式HPに書いてあるとおり
にやっても出来ず(書き間違いがあることが多い)、実際に動いている例を調べたり
して、公式HPの間違いを発見しても面倒だから報告せずに、やっとの思いで
何日もかけて見出した30行のコードが、GPL感染して世界中に広まっていき、
金持ちのボンボンがそれを我が物顔で使う。そんな社会になってきている。 >>992
エッセイ書きたいならTwitterでやれ ,r"´⌒｀ﾞ`ヽ
／ , -‐- !､
／ {,}f -‐- ,,,__､)
／ / .r'~"''‐--､)
,r''"´⌒ヽ{ ヽ (・)ﾊ(・)}､
/ ＼ （⊂｀-'つ）i-､
`}. （__,,ノヽ_ﾉ,ﾉ ＼
l ｀-" ,ﾉ ヽ 頼む、どうか>>992を許してやってくれ彼はゴリラなんだ
} ､､___,j'' l Rust 1.53きたけど、非ascii識別子って前から使えなかったっけ？？？ 前はunstableでnightlyでしか使えなかった このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 77日 3時間 30分 32秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
