勉強中でいまいちよくわかってないんだけどさ
よくRsutでメモリの扱いが安全になるとか言われてるけど、これって解放忘れを防いでくれるだけであって、オーバーフローを防いでくれるものではないわけ？
それとも登場する全ての型がオーバーフローしないような仕組み(スタックプロテクター以上の何か)があるの？
スタックプロテクターの話題を出すってことは
バッファオーバーフロー (バッファオーバーラン) のことじゃないかな。
配列は大きさの情報を持っているし、
配列の一部の範囲を受け渡すときはポインタでなくスライスで扱うのが Rust の基本的な設計になってる。
ポインタと違ってスライスは範囲の情報を持っているのでチェック可能で、チェックする仕様になってるよ。
溢れたら panic する。
(もちろん unsafe な操作をしたらいくらでも危険な操作は出来る。)
絶対に溢れないことがコンパイル時に見抜ける場合であれば
チェックしないように最適化したりすることもあるし、
チェックする場合でも現代的な CPU ではほぼ確実に分岐予測が成功するから
処理速度が遅くなる分は十分に小さいとかいう話があったはず。
バッファオーバーフローのことなのか
Safe Rustでは基本的に発生しないが仕組みというより
unsafeなコードを書く人が要求された安全性を保証するという約束の上に成り立ってる
Rustの要求するメモリ安全性を保証するためには
unsafeなコードでポインタをdereferenceする前にout-of-boundsかどうかのチェックが必要
解放忘れ（メモリーリーク）はRustは
保証してないのでは？
Box::leakして返された参照を捨てるとメモリリーク起こせる
最近勉強始めたんだが、正直ムズイ
特にwinapiのポインタ引数が(構造体のポインタではなく)DWORDで定義されてたりするので、
キャストするのが超絶面倒臭い
microsoftはcrate修正してほしい
まあ、rustというよりwinapiの問題なんだが……
わかる。
DWORD とポインタをカジュアルに同一視する API はまだマシなほうで、
Rust は文字列をスライスで扱うから単純にポインタに変換してもヌル終端されてないのがクソめんどい。
文字列を渡すとかすごく普通にあることなんで、それがこんなに面倒くさいの勘弁して欲しい。
普通に書いててwinapiとか使う機会ないと思うけどOS機能を直接触る必要のあるライブラリでも書いてるのかな?
OS層に近いAPI全く使わないならrustやc++とかデメリットの方が多いような。
俺も最近Rust勉強してるんだけど、GC無しでのメモリ管理が最高に気持ちいい
何もかもRustで書きたくなる
ワイは基本moveってところが気に入ってる
参照をもって回るんじゃなくて
実態をmoveで渡してmoveで返されるとき清々しいのを感じる
システムコールや低レベルなライブラリをいい感じに安全にラップしてくれるcrateが提供されてるのはrustの良いところ
moveって最適化ビルドだと消えたりしてるのかな？
moveが消えるとは？
moveがコンパイルされた結果のmemcpyなどが消えることはある
>>13
Rustのスライスは、ほぼPascal文字列だから、Cよりも古くから作法や
概念は存在している。
しかし、なぜCがPascal文字列ではなく0終端文字列にしたのかには
理由があって、文字列の途中(部分文字列)を扱わない場合においては効率が良いから。
0終端文字列の欠点は、部分文字列を扱おうとするととたんに面倒なことになること。
ただ、strcmpみたいなものを書いたり、字句解析を書いたりするときには、効率は良い。
字句解析では決定性オートマトンの理論がグラフ的(状態遷移図的)になっており、
Cの0終端文字列とはとても相性が良い。
そして、コンパイラの実行時間の大部分は、実測してみると、意外にも字句解析が占めている。
字句解析は単純ではあるが、量が多いので1クロックの差がものをいう世界である。
ただ、Pascal文字列(スライス)が字句解析でも有利に働く場面はあるにはあるが。
どちらの方式が一方的に優れているとはいえない。 >>21
すまん。今調べたら、Pascal文字列は、配列の先頭に文字数が
入っている特殊な形式で、スライスとはまた違うものだった。
今まで誤解していたわ。
Pascal文字列はダメだわ、全く意味無し。
ただ、俺が言いたかったのは、Rustのスライス方式も古くから概念自体は存在し、
Win32APIでもGetTextExtentPoint32()なんかが、ポインタと、その後に続く
文字数の両方を指定する方式を取っている。
このやり方は、文字列の中に 0x00 を埋め込まなくても部分文字列を扱えて
便利は便利。もしこれを部分文字列の場所を少しずつ変えていくようなの場合に、
0終端文字列でやろうとすると、効率が悪くなる。
ただ、いつでもスライスの方が0終端文字列より効率が良いという訳ではない。
それが>>21で言いたかったこと。決定性や非決定性オートマトンの考え方で字句解析を
する際には、Cの0終端文字列はスライスより効率が良い。 読む価値無い文章をダラダラ書いちゃうのって
なんらかの障害なんやろな
>>22
そのせいでPascal文字列は長さ255文字までに制限されてたのよな。 結論は、Rustがそんなにすばらしい言語とは到底思えないということだ。
>>25 まぁ用途によるやろ
発展途上なところもあるし､そもそもRustが向いてないような用途もある >>13
様々な文字列処理をしたことがある人になら自明ですが
文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です
例えば何段か深いディレクトリの絶対パスが与えられた時に各ディレクトリのリストを返す（つまりsprit）時
￥0終端方式だと元の文字列を書き換え破壊しない限りコピーが発生してしまいます
スライス方式だと書き換えもコピーも発生しません
これは正規表現によるパターンマッチングでも同じで￥0終端方式だと結果である部分文字列をコピーしなければ返せません
またHTMLやJSONなどの様々な構造データの解析結果でもそうです
JSON文字列を解析して内部構造化表現にする時もスライス方式ならば文字列のコピーが発生せずに済むわけです >>28
>文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です
有利だろうが何だろうが、APIや過去の資産を活用するのに面倒という事実は何も変わらないが そういやRustの std::ffi::OsString って￥0終端なんだっけ？
>>30
違う
null terminatedはCString >>29 FFIのことを考えつつスライスの恩恵(境界チェックなど)も受けるなら今のRustの文字列に最後に\0を入れるようにしたらいいと思ったけどなんでしないんやろ
\0分の1バイトぐらい今のPCじゃ問題にならないはず >>32
従来の &str (部分文字列) とnul終端文字列を区別しないといけないけど
型で区別しようとすると結局今のCStr/CStringと同じになるのでは
文字列は部分文字列含め全部Stringみたいにヒープアロケーションするなら良いけどさすがに効率が悪すぎる Rust違いです
ってかゲームのほうのRustって個別スレ無いんだね
FFIが必要な箇所で
let cstr = std::ffi::CString::new(str);
すれば済む話だからね
Win32APIだと\0終端の2バイト文字も渡したりするからCStringでも使い勝手悪そう
let wcstr: Vec<u16> = std::ffi::CString::new(str).to_str().unwrap().encode_utf16().collect();
で動くかな（試してない）
こっちは自分で'\0'足す方が簡単かもしれない
>>28
気持ちは分かるし、実際、その例に挙がっているケースではそうなんだけど、
字句解析は、コンパイラ理論の状態遷移図に基いて行うと効率が良いが、
それは 0 終端文字列の方が効率が良い。 何度も言うが、全面的にスライスが良いならC言語でも0終端文字列をやめに
してしまえばいいのだが、そういう訳ではない。
>>28 に挙がっているようなケースで、自分も同じような気持ちになったことは有るが、
一方で 0終端文字列の方が効率が良い例も少なからず存在しているので全面的に
スライス方式に変えてしまうのは難しい。
一番単純な例を書けば、英大文字の部分だけを読み飛ばす場合、
(1) ptrが0終端文字列を挿している場合:
while ( *ptr >= 'A' && *ptr <= 'Z' ) ptr++;
(2) (ptr, len)でスライス文字列を表現している場合 :
int cnt = 0;
while ( cnt < len && *ptr >= 'A' && *ptr <= 'Z' ) {ptr++; cnt++;}
後者だと、cnt < len と cnt++; の部分が追加されて効率が落ちる。 windows apiを使ってメッセージダイアログボックスを表示するサンプルが載ってるサイト教えてください
>>38
今のcpuとコンパイラの最適化で両者にどれくらいの性能差があるか示したベンチマークなどある？
rustでも文字列末尾に0を差し込めば同じことはできるので、本当に速くなるなら最適化の手法として採用しても良いかもしれない >>41
試しに手元の環境で1GB分やってみたが1割くらい差があるね
コンパイラはgcc9
でもRustの文字列ってnull文字含むことができるんじゃなかったっけ？試したことないけど >>40
use winapi::um::winuser::*;
fn main() {
let str: Vec<u16> = "Hello, world!".encode_utf16().chain(Some(0)).collect();
unsafe{
MessageBoxW(std::ptr::null_mut(), str.as_ptr() , str.as_ptr(), MB_OK);
}
} 設計判断ってのは常にトードオフの選択だからな
ヌル終端にすることで得られるものと失うものを天秤にかける必要がある
得られるものしか見ないやつは設計からは手を引け
>>38
ptrとlenが分かってるなら別途カウントアップしていかなくても
どの位置のptrまで読めばいいか最初に分かるんじゃない？ Rustってなんでprintlnの後にビックリマークあるの？
>>47
確かに。end_ptrとの比較で終了判定した場合は(1)と差はなかった
比較一個分くらいなら今どきのプロセッサの並列実行で
十分吸収できるということかな >>48
printlnは関数じゃなくマクロだから
ちなみにマクロにしてる理由は引数の型と個数が不定だから そういや、可変長引数を直接書けないからRustはクソって言う人はまだ見た事ないな
あんまり使わないからかな？
>>42
文字列中にNULが含まれないことを前提とした最適化だから
NUL含む場合は使えないという制約はあるね
Cの文字列と同じ制約だから実用上あまり困らないんじゃないのかな知らんけど >>52
Cで可変長引数使いたくなるのってprintf系関数以外なんかある？ >>54
ない
標準関数ではprintfとscanfだけ >>47
なるほど、こういうことかな：
(2)' (ptr, len)でスライス文字列を表現している場合 :
int btm = ptr + len;
while ( ptr < btm && *ptr >= 'A' && *ptr <= 'Z' ) {ptr++;}
>>49
差は少なくはなるが、無くなるわけではない。
ptr < btm という部分が残るから。整数比較命令と 条件jmp命令の
合計2命令はまだ(1)より多い。 >>56
そりゃ命令数に差があるのは当然だけど
現代的なプロセッサの並列発行や分岐予測を考慮して
なおパフォーマンス差があるかを見たかっただけなので
そちらは実際測定して差を確認できた？ 議論するのそこ？
むしろセキュリティ(バッファオーバーランの危険性)とパフォーマンスを秤にかけて
rustはセキュリティの方を採用したってだけじゃない？
パスカル文字列なんて昔からあったわけだし
>>52
どうしてもやりたければビルダーパターンでまとめてから渡すイディオムが確立してるから
そんなに不満にもならないんじゃない？ >>58
いや安全な方を選んだってのはそのとおりだと思うけど
理論上遅いはずってのを実際測るとそうでもなかったってのはよくある話で
そこが気になっただけ >>60
rustが組み込みも視野に入れている以上、現代的なプロセッサは当てにできないと思う
8bitマイコンとかでrustが動くのかどうかはわからないけど >>61
別にRustはあらゆるアーキテクチャでのパフォーマンスを保証するつもりはないと思うけどね
実際測定してるのはTier1環境だけだろうし winapiクレートを使うことってもうなくね？
Microsoft公式のwindiwsクレートの方がよっぽど使いやすいよ
>>38
＞(1) ptrが0終端文字列を挿している場合:
＞while ( *ptr >= 'A' && *ptr <= 'Z' ) ptr++;
その場合でも、まず与えられたデータが0終端しているかどうかを確認する必要がありますよね。
データがどこから来るのかは、
ネット上の通信相手か
ディスク上のファイルか
メモリ上の他言語等APIかになりますが、
いずれも盲目的に信頼せずに処理する必要があります。
そして小さいデータならばどんな処理方法でも誤差になるのでしょうが、
大きなデータの場合は>>28のように元はJSONとかHTMLのように構造をもっており、
その解析結果である各一部分が対象文字列になります。
すると0終端させた方がわずかに速く扱える可能性があるからといって、元の大きなデータから毎回コピーして0終端文字列を作る場合と、
コピーをせずにスライスのまま部分文字列を扱う場合との、比較になるのでははいでしょうか？ >>64
>元の大きなデータから毎回コピーして0終端文字列を作る場合
どこからコピーの話が出た？ >>65
変更したくない文字列"あいうえおかきくけこ"から部分文字列"かき"を取り出す場合、
スライス式だと元の文字列の[5:7]の範囲という形で表現できるからコピー不要だけど
ナル終端式だと"く"が邪魔で"かき\0"にできないからどこかに"かき"のコピーが必要になる
って話が>>28に出てる その比較は部分文字列をコピーするかスライスで表現するかの違いであって
0終端文字列のメリット・デメリットとは少し違うんじゃない？
0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要
>>68
> 0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要
それをやってしまうとその部分文字列に対して0終端のメリットが効かなくなるわけで
コピーしないとメリットを得られないというのがデメリットになってる つまり部分文字列を扱う場合は、コピーが発生する0終端方式が不利になりますね。
具体的にファイルパスからディレクトリ部分を得るとか、URLからホスト名を得るとか、元データを破壊したくない時は0終端方式だとコピーするしかないです。
つまり一貫してRustのように始点＆長さ方式の方が、有利かつメモリ安全ではないでしょうか？
さらに文字列比較の場合も長さ方式よりも0終端方式が不利です。
これはCのmemcmpとstrcmpの比較に還元されますが、
memcmpは64bit比較やSIMD利用ができるからです。
&strって3つの意味があると思うんだよね
1: 文字列リテラル
2: Stringの参照
3: 部分文字列
文字列リテラルとStringは終端にNULLを付けるようにして(今まで通りlenやcapは残す)､部分文字列は部分文字列を意味する別の型を作ればいいと思った
こうすることでRust側ではlenやcapを使い､C側ではNULL終端を利用できるという状態になる(Stringや&strをRustで使ってもCで使ってもゼロコスト)
もしNULL終端ではない部分文字列をCで使いたければStringに変換すれば使えるようになる(これはコストがかかるけどCの文字列も同じ問題を抱えてるので問題なし)
>>70
それやるには文字列がimmutableでなければならないから、それによって生じるスペースコストとどっちをとるかって話だな。
それにimmutableな文字列って、部分変更に相当する処理をする場合に逆にコピーが必要になるし。
どっちにしても一概に、コピー不要だからこっちが有利、みたいな話にはならんかと。 rustで初心者がハマるポイントを初心者が紹介します
・所有権の概念が難しい
・何をするにしても外部ライブラリが必要（乱数生成など）
・ポインタが難しい
>>64
>その場合でも、まず与えられたデータが0終端しているかどうかを確認する必要がありますよね。
「0終端文字列」
というのは、必ず0終端されている文字列の事なので確認は不要。
それを明確にするために、C言語では、const char *pszText; のように、
psz という接頭辞をつける流儀がある。
psz = pointer to string ending with zero.
「0で終端している文字列へのポインタ」
という意味。これは、単なる const char *ptr; とは意味が異なる。
char c = 'A';
const char *ptr = &c; // 単なる文字へのポインタ。0終端されていない。
char szText[] = "Hello"; // 0終端文字列。0終端されている。
const char *pszText = szText; // 0終端文字列へのポインタ。0終端されている。 >>76
ファイルから読んだデータをpszHogeに格納するときにゼロ終端の要件満たしてるか確認する必要あるよねって話だぞ >>74がマジで深刻すぎる
ついでに加藤純一っていうゲーム実況者とかとじゅんっていうRust/Scala使いがいるのも紛らわしい >>76
>というのは、必ず0終端されている文字列の事なので確認は不要。
という考えで脆弱性を量産してきたC言語の負の歴史を顧みて
Rustを始めとした新しい言語は異なる文字列表現を採用してるわけだ >>77
コンピュータの世界で「確認」とは、データの中を検査するという意味で
使われるが、そういうことは不要。
自分で末尾に 0 を書き込む必要があるだけ。 そこで確認不要とか言ってるからユーザにヌル文字含んだ文字列渡されて死ぬのでは
セキュアプログラムは面倒だからなー
数値のオーバーフローチェックとかみんなやらないでしょ？
アップキャストして値に結果を放り込んでチェックした後、
ダウンキャストするとか面倒すぎる
>>81
そういう外部からの入力に対するエラーチェックはするのは当然だが、
0終端文字列でやる場合には、ファイルのバイト数だけ読み込んで、
一番最後に 0 を書き込んでおくとそれ以上まで進むことはない。
途中の 0 に関しては スライス方式でも同じ問題が残る。
途中に 0 が有っても大丈夫な様に作るだけ。 >>84
ちなみに、リアルワールドでは俺は名プログラマだと評価されているぞ。 良いプログラムを作るための基本ポリシー：
・外部データと内部データは明確に分ける。
・外部データを内部データに入れる場合は、エラーチェックを徹底的にする。
・内部データに関しては、原則的には完全に正しいことを前提にしてプログラム
して良い。ただし、プログラムのミスのための念のためのチェックはしても良い。
>>87
３番目のチェックはアサーション（assert）だと思うけどあれはコードを読む人に背景の条件を明示する意味もあるね
逆にアサーション以外の余計なチェックはコードを読む人を混乱させる可能性がある ヌル終端はパンチカードが現役だった時代に数バイトケチった名残
互換性のためにサポートしなきゃいけないのは理解できるが
今の時代にヌル終端が優れてるとかそれをデフォルトにしろってのは控えめに言って頭おかしい
>>90
外部でーたとしては、他にも有ると思うが、一例としては、
1. 他人が自由に書けるファイルから読み取ったばかりのデータ。
(アプリケーション内部にリソースデータとして内蔵し、安全性が
テスト済みであるようなファイルは内部データとみなしても良い場合も有る。)
2. 安全対策を徹底したいライブラリの場合は、ライブラリを使う側が関数に
渡してきたテキストデータや引数の値。
ただし、このようなものまで徹底的にチェックするとなれば遅くなるので、
設計思想によっては、NO-CHECK、または、軽いチェックだけで済ましても良い。
3. OSの場合は、同様なものとして、APIを呼び出した側が渡してきたデータ。
これは、安全性チェックは徹底して行う必要がある。
4. データベースソフトなどの場合も、2や3に準ずる。どこまで安全チェックするかは、
使用目的や用途、設計思想による。 一般に、アプリの外に置いてあるファイルはチェックした方が良いが、
その中でも、テキストファイルは、信頼置け無い事が多いのでチェックは必要。
アプリの外に置いてあっても、バイナリデータだと人が手書きすることはないため、
設計思想にもよるが、安全チェックはある程度省略しても良いと考える流儀もありえる。
結局アプリケーションがどう使われるか次第でしょ
アプリケーション作成時の前提が利用シーンの増加により後から覆されるなんてことは良くあることだから
性能要件がない限り最初から安全側に倒しておくのが合理的
constデフォルトあたりの話ってgoto禁止論みたいになっている気がする
理由を理解していないがとりあえずそうしておけみたいな人を少なからず見かけるような
>>94
パーサーがガバガバで細工したセーブデータで乗っ取られるゲームのことか >>95
MS製のリンカ(link.exe)の入力するlibraryファイル(*.lib)には、
ヘッダ部分にシンボルがアルファベット順にソートされたシンボルテーブル
が入っている。ソートされていることを前提にバイナリサーチが出来るので
シンボルを検索するのが高速になるとされる。バイナリサーチは、ソート
されているデータに対してのみ正しく検索できて、もしソートされていなければ
間違った結果になる。
しかし、link.exeが*.libを入力する時、ちゃんとシンボルテーブルのシンボル
がソートされたかどうかチェックしているかと言うと、定かではない。
だから、もし、サードパーティー製のツールが*.lib を作成した時、
ソートにミスがあったりすると、link.exeはundefined symbolエラーを出すか、
リンクには成功するが、実行段階でアプリが起動できなかったり途中でダウン
してしまうかも知れない。その様な場合、何が原因かは分からないであろうが、
多分、実際、検査はされてない。 >>97
実際は、サードパーティー製ツールも、ちゃんと*.libのヘッダのシンボルテーブルの
シンボルはソートしており、その部分にはバグはないので、それがソートされてない
*.libは基本的には存在しない。
ただし、*.libをバイナリエディタで開いて手作業で間違って変更したりすると
ソートされていないものが出来上がる。
それをlink.exeに入力しても、link.exeは、そのことに関してのエラーは出さない
だろう。 小学生が大人に九九暗唱してみせれば微笑ましいが
大人が大人に九九暗唱してみせるなら不気味で滑稽である
意図通りに動かないバグにつながるという話と
バッファオーバーフローみたいな脆弱性につながるという話は別だよね
再帰を使って1x1=1から9x9=81までの答えだけを書く場合
どうやって書けますか？
>>102
題意に沿ってるか分からんけど
fn main() {
f(1, 1);
}
fn f(a: u32, b: u32) {
//println!("{}x{}={}", a, b, a * b);
println!("{}", a * b);
match (a, b) {
(9, 9) => return,
(_, 9) => f(a+1, 1),
(_, _) => f(a, b+1),
}
} 実践的な話をするとRustは末尾再帰最適化が出来ないからなるべく再帰は使わないほうがいいと思う
宿題かなんかだろう。
Rustで宿題を課すなんて教官は変態にもほどがある。
>>104の例だとtail recursionになっていないから
内部でloop化できる仮言語で書いてもこのように分解するしかなくて
f(1)
fn f(a) {
f2(a, 1)
f(a+1) if a != 9
}
fn f2(a, b) {
print `${a}x${b}=${a*b}`
f2(a, b + 1) if b != 9
}
結局のところ関数分割→個別ループ化→関数統合で二重ループ化まで自動でしてくれる言語は無いから
再帰は使わずに自分でループ化すればいいよね、って結論
つまりアルゴリズムでは再帰で考えても実装はループにしてコメント残しておくのが正解 >>107
プログラミング言語 Scheme の仕様だと >>104 のようなパターンは末尾文脈の定義にあてはまるし
末尾呼出し最適化が適用されることが保証されるから、
現代的な言語処理系で最適化できないとは信じられないんだけど、
実際にRust コンパイラに >>104 を与えたときにループに最適化はしないの？
Rust のコンパイラの使い方に不慣れでアセンブリコードの出力のさせかたがよくわからん……。
ほぼそのまま C のコードに書き換えてみたら
GCC ではジャンプに置き換えたコードが生成されるみたいだし……。
(ちなみに GCC では末尾呼出しになっていなくても一部の状況では再帰をループに変形できることがある。)
Clang だとループを全部 unroll しやがった！ c言語だと再帰が末尾呼び出し最適化されるかどうかがオプティマイズレベルで変わるからややこしい。
リリース版だと動くがデバッグ版だとスタックオーバーフローみたいな事になる。
単純な再帰ならループに書き直してもいいけど、相互再帰みたいなのは末尾呼び出し最適化してくれないと困る。
あの、Rustの勉強のために逆引きサンプルwiki作ろうと思うんですけど
テンプレ殿堂入りを目指して作ってもいいですか？
もちろん広告は入れませんが、レンタルwikiが提供している広告は表示されるかもしれませんが。。。
>>110
目指すことは自由じゃないの。
皆がどう判断するかも自由だけど。 先輩ありがとうございます！
受け入れてもらえるようなコンテンツを作ります！
5chに閉じずに本家のコミュニティにも便利と思ってもらえるもの目指した方が良いのでは
>>114
ミンチメーカー、ではなくスパゲティメーカーとして恐れられてるかもな 斜め読みしかしてないから見逃してるかも知れないけどさんざん言い尽くされた話ばかりだった気が
そもそもRust自体はC++を置き換えることを目的にはしていない
やたらC++と比較されるのはどっちもbetter Cの側面があるからだろうか
個人的にRustはCとScheme（Lisp）のハーフという印象
SchemeよりMLの方が近いらしいけどMLは使ったことないからよく分からない
手続き型で関数型を疑似表現したり関数型で手続き型を疑似表現する試みがあるけど
Rustはその中間を上手く埋めてる感じ
> better Cの側面がある
はぁ？
お前がcもc++もrustもニワカなのは分かった
あと五年間は、カキコ無前にROMに徹してみてほしい
>>119
急にどうしたんだ
better Cの意味が分からなかった感じ？ mozillaのc++を安全に使う数多の取り組みに疲れ果てた結果出てきた新言語がrustなのでc++と比較されるのは当然
この板全域に出没して何でもRubyと比較するガイジみたいなもんだろ
ここにはなぜかいないけど
>>116
Rust布教スレになってんじゃん
不健全 今から新規のプロジェクトをC++かRustで始めるとなったらRustの一択でしょう
つまりRustはbetter C++
まったく何も資産がない新規であればそうかもしれんが
>>118
どこらへんがschemeに近い？
よく知らんがschemeってカッコが一杯あって、再帰ばっかりしてるイメージなんだが つまり過去のしがらみのある案件は時間がかかり遅れるが
いずれも徐々にC++はRustへ置き換えられていく
emacsとあとなんだっけ？ SVGのライブラリ？が
オブジェクトファイル *.o 単位で少しずつCからRustに移植してたな
>>129
ifとかmatchのブロックがそのまま値になるところが何となくS式っぽいんだよね
ブロックの最後の式が全体の値になるのも(begin ..)に近いし MLの方が普通に近いな
パターンマッチとか束縛がletとかHMの型システムだとか
一番近いのは Ocaml。なぜなら、かつてRustはOcamlで組まれていたから。
そして途中でコンパイラをRust自身に直したと聞いた。
Rust の Scheme っぽいところを探すとしたらマクロだろ。
伝統的な Lisp 系言語だと実行時の環境とマクロ展開時の環境を分けないが、
Scheme は分ける方針をとってる。
(実際には分けない実装をしている処理系もあるし、次の仕様の更新でどうなるか不透明だけど。)
何に近いかでここまで盛り上がれるのだね
何も産まないのに
Parkinson's Law of Triviality
>>139
比較から何かを見出せる人もいるから何も産まないということはないよ そんなセンスのある人がここにいると思うのｗｗ？
センスないねｗ
ちょっと見ないうちに色々変わる＋自分の理解が浅いせいで追いつけない
bindgenって複雑なヘッダーだと全然駄目なんだなあ
殆どそれ目的でRustやってたのに
>>146
実際に使ってみて初めて分かる問題点だね。 rust始めました！
ってゲームの方を始めてたネタをやろうと思ったけど
想像以上にクソゲー過ぎてダメだった
やっぱり言語の方がいい
検索するとゲームの方と言語の方が出てきてややこしい
Rust(ゲーム)は名前変えてくれ...
GoはGolangって別名があるから問題ないけどRustに関してはRustLangとはあまり言わないのがなぁ
まあそれはRustの問題ではないですが、クロス環境に問題を感じているなら、Haskellがお勧めですよ。
あわしろ氏がいつも言ってることですがね。
そもそもオフィシャルのレポジトリ名がrust-lang/rustだし普通に言うのでは
言わなくはないけどRustLangよりはRustと呼ばれることのが多い気がする
GoだったらGo(golang)とかGolangとか言われることが多いけど
単にgoよりgooglabilityが高いことのあらわれじゃね
別にそんなに困ったこと無いけどな
ていうかGoはもうgolangに改名したほうがいいと思う
Goではとにかく名前がクソすぎる
そもそもなんかダサいし
goはogle（いやらしい目で見る）という名前のデバッガとセットで売り出す予定だったけど
ogleがこけたから残念な名前だけが残ってしまった
たいていは rust + 別の単語 でググるけどゲームの情報が出てきて困ったことはあまりないかな
pythonってそう考えるとなかなかいいネーミング
そういやRustはツイッター検索だとかなり厄介だったな
既存の名詞使うときは perl みたいにスペルに一ひねり加えるのが良いんだろうね
rust でやるのは難しいけど
>>166
pearlとしなかったのは既存言語が存在した偶然みたいだけどね
phpは某雑誌がよく引っ掛かってたな Rust とかGoとか固有名詞やめてほしいよね。。。
固有名詞でない言語名...
「名前を言ってはいけないあの言語」みたいな名付けかな
langを付けると意味が変わるしCは本当に検索ワードに迷う
C++もtwitterでは検索できない。C#もだけど。
それは、わざとなんらかかの意図を持ってされていることかも知れない。
twitteの社長や技術者がC++が嫌いだとか。
/ も無視されるし単純に記号が無視されるだけでしょ
つまりまたもやlispが最強だと判明してしまったわけたな
>>174
技術的には簡単に直せるのに直さないところに意図を感じる。 技術的に簡単だと思うなら外部サービスとして提供してみたら？
外部から伺い知れない部分について簡単に違いないと断言する人とは議論しとうない
全文検索とか形態素解析を少しでもかじってたら簡単とは思えないはずなんだけどね。
>>178
外部サービスとは？
内部の人がやるのは簡単でも、外部の人がやるのはとても大変。
>>180
俺は字句解析系はよくやっているので簡単に感じるが。 字句解析と形態素解析や全文検索はまったくの別物だろう
陰謀論とかじゃなくて、壊したい相手に不利なようにするのがアメリカ流なんだよ。
卑怯な手口だが、卑怯という概念にはあの国には無いのだろう。
あの国の連中は、ことごとくそういう手口で生き残っているから、そのうち
技術の進歩が遅れてある時、がさっと負けだすかも知れないな、GAFAMも含めて。
>>183
形態素解析などに入る前に、例えば、C++をcppと同一視してしまえばいいんだ。 簡単に直せる
(計算量が増えたり既存機能に影響を与えたりするかもしれないけど)
ってことでしょ
>>186
それを簡単と呼ぶのは研究とかラボの人間よね。 字句解析と形態素解析の違いもわからないのはちょっと…
>>184
で、c++を壊してtwitterにどんなメリットが？アホなの？ そういうのは形態素解析したあと、同義語辞書(シソーラス)で単語を正規化する作業になる。
形態素解析の段階で記号は除去しないとややこしくなるから記号入りの単語を使うのが悪いわな。
ハッカーが使わない言語は流行らない。メモリ安全だけじゃ一部需要のみ
楽しい言語も流行らない。いつも趣味レベルの言語で終わる
流行で選ぶってアフィチューバーやアフィブロガーかな？
x.py build したあと、x.py install したら、
また意味不明にボコボコビルドし始めたんだけど、
知恵遅れなの?
>>195
面白い観点だな。
楽しい言語も流行らないか・・・、なんか考えさせられる。 いつまで miri のトラブルを放置しておくの?
ゴミ言語
unsafeモードが使えても、safeモードでのコード生成結果が予測できないのであれば
使うのは難しい。
無駄な通信と監視と役立たずのゴミでツリーを汚すゴミ
ハッカーは書くスピードと実行時間が重要だからnimとかが向いてそう
少なくともRustは絶対にハッカーの第一言語にならない
ハッカーとか呼んでねえからキーボードでもしゃぶってろ
ハッカー != 犯罪者 がモダンな解釈だと思うんだが。
○にかけのお爺さんかな？
ロシア人ハッカーグループって言ったら
犯罪者っぽくね？
イスラエル人ハッカーグループって言うと
なにか巨大な国際政治がらみの陰謀っぽい
日本は、一人当りのGDPだと先進30カ国中最下位レベルだけど、純粋な頭脳線だと、
三位以内に入ることが良くある。
>>199
Rustはasync/awaitを言語レベルでゼロコストでサポートする代わりに非同期ランタイムを別途用意する必要がある
これによりRustでは様々な非同期ランタイムを言語と独立に自由に作ることができる
例えば非同期ランタイムを自作することも当然できてfuturesクレイトをその部品として使うことができる
もちろん非同期ランタイムを自作せずとも既に様々なコミュニティから提供されているのでそれを使うこともできる
具体的には例えば最も使われているtokioなどのチュートリアルを見るのが良いかな
https://tokio.rs/tokio/tutorial >>219-220
その考え方が古い。(というか最初から？)間違ってる。
ハッカー == 凄い奴 的な意図でしかないので
ロシアだろうがイスラエルだろうが某大陸だろうが
超エリートなんだろうなとしか思わない(事になってる)。
犯罪者はクラッカーと言って区別される(事になってる)。
区別しようと言い出したのは…(ry でも発端の>>195の「ハッカー」はホワイトかブラックかは知らんがセキュリティ関連の話ちゃうんか？ >>225
モダンな解釈だと良いハッカー=ホワイトハッカー 悪いハッカー=ハッカーですね
あと老人ホームから抜け出してまで5chなんてしたら家族に迷惑かかりますよ
迷惑かけない内に尊厳死をおすすめします そんな高度な話だったんだ
小学生がうんこちんちんって罵倒してるようなものだと理解していた
正しい定義がどうだろうと>>195の意図なんかわからんのでどうでもいいうんこちんちん 仕様や実装のマイナーな機能を使って人を驚かせるのがハッカーだ、と思ってるのでは
Cのポインタ祭りとかLISPのマクロ生成マクロとかを好むのだ、と
ハッカーの定義はどうでも良いからせめてrustの何がダメかを語れよ
rustは文字列の扱いに難があるなあ
sjisのコンテンツとかマルチバイトのファイル名(WinだとUTF16?)の扱い方がよくわからん
Non-Lexical Lifetimes が制御フローレベルなので実装をデバッグできるやつがほとんどいない。
c++と同じレベルの複雑さを有するようになってきている。
cargoのビルドシステムがあまりに強制的すぎる。
メモリを直接いじる必要のある効率的なアルゴリズムでは結局unsafeになる。
メモリ最適化の許す範囲があまりに非自明でcから呼ぶのは不安定すぎる。
コンテナ類が実際にどのように格納されているかが分からないと言うのは、
それをunsafeで扱うのが難しくなってる。
どこでコピーが生じて、どこがmoveなのかも分かりにくいことがあるし。
ライフタイムもちゃんと仕様が書いてないから、手探り状態で試さないといけないし
プログラムするのに時間が掛かる。
色々やっても結局、C/C++のような効率のよい方法を取ることは不可能な場合もあるし。
ときどき、Javaの検査例外みたいなやらかし感を感じる
厳密にしすぎると却って使いづらいみたいな
Box<dyn Error>やanyhowやeyreを使えば良いのでは
>>235
Windows 系以外のすべての言語は、UTF-8
だから、MSYS/MinGW でも、UTF-8以外でバグるので、
UTF-8以外を使っちゃいけない！
唯一バグらないのは、WSL。
Windows Terminal, VSCode のRemote WSL などで、
ls /mnt/c/Users/Owner/Documents/
と入力すると、日本語のフォルダ名も、正しく表示される
出力
あ
い
たぶん、Windowsが変換しているのだろう WSL は一種のチート
ハイパーバイザーでLinux を起動して、
Linux側から、Windows側のドライブを見た時に、
UTF-8 以外の言語をUTF-8に変換する
まあ、漏れの推測だけど
>>242
そこに文句言われてもねー
要件に文句を付けるのはフェアじゃない
現実にUTF16でネーミングされたファイルがあって、
それにどう対応するかって話なんだけど だから、プログラマーの基本は、Windows 系など、UTF-8 以外を使わない事！
この大原則を守っていない人は、システムを作れない
システムには、ascii しか使えない！
これが大原則
>>244
WinならOsStringのエンコーディングは普通にUTF-16だから何の問題もないと思うが
sjis扱いたいならencoding-rsとか
結局何に困ってるのかわからないと何とも言いようがない じつはわしはRustはやったことなかったのだが、
これまでの経験上おそらく >>236 みたいな感じだろうなと想像してたら
ほんとうにそのとおりでワロタw
アホみたいに「安全ドグマ」に縛られるとたいがいそうなる >>245
プログラマーの基本！ とか システムを作れない(ｷﾘｯ とか言われても
既存のシステムがそうなってるんだという話
「システムには、ascii しか使えない！」とか言ったら、客に帰れと言われるだけ
>>246
sjisファイルを読み込みたい
でもチュートリアルにあるようにBufReaderは使えない
そりゃ読み込んだ後、変換処理したら何でもありでしょ
でも、ネイティブに処理できん？と思う
むしろ安全性にこだわる割に文字に対するこの雑さは何なの？と 論理的な問題点以前に、言語として見た目的な美しさも無いし、記述が
簡潔でもなければ直感的でもなく、無駄に長くなる。
システムには、ascii しか使わないのは、Linux の基本
AWS でも、そう。
半角空白もバグるから、使わない
必ず、客から注意される。
日本語のファイル名・半角空白を使わないでと。
バグるから
例えば、5ch は、sjis だからバグだらけ。
; を書いていないのに、文字列の後ろに、; が付いてるとか
sjisとか、Windows以外では、どうしようもない
>>249
バイト列としてVec<u8>に読んじゃえば後はCと一緒じゃん
それともlocaleとwchar_tフル活用したいという話？ >>253
それでcrlfでsplitしろって？
なんて原始的な… UTF-8(とchar用のUTF-32)以外滅んでほしいが､過去の遺産がそれに対応してないという現実的な問題...
まぁencoding_rsってクレート使って変換してやればヨシ
>>242
に書いたみたいに、
sjis, UTF-16 などのWindows 用言語で、
唯一バグらないのは、WSL だけ
WSL でLinux側から、Windows側のドライブを見た時だけ、
日本語のファイル名を正常に変換できる
Windows Terminal, VSCode のRemote WSL などで使える
ひょっとして、Windows用言語を扱っていて、WSLを使っていないの？ >>249
変換せずに扱いたいのか？いまいちよくわからんが、既存の言語で理想的なやつってどれ？
Rustは文字列に関しては最もちゃんとしてる方だと思うけど あ、あとascii/WSLおじさんは気にしなくていいと思うよ
少なくともRustにそんな制限はない
Cとかだとasciiに限定したい気持ちもわからなくはないけど
・ファイルシステム上のエンコーディング
・OSのAPIのエンコーディング
・言語のAPIのエンコーディング
・言語の文字列のエンコーディング
それぞれ独立だし変換しあってることをおじさんは理解していないと見える
>>255
でもUTF8は「ひらがな」ですら3バイトになるので困る。 >>256
へー WSL って言語だったんだωωω >>257
どれが理想的というか、rustは特にめんどい気がした
fgetsが出来ればそれでいいんだが >>249
sjisを変換せずそのまま内部表現として標準的に扱うプログラミング言語って具体的に何？
もちろん全ての言語でバイト配列としては扱えるけどsjisにとってそれは無意味であり
先頭から全読みしないとsjisの1バイト目か2バイト目かすらわからない欠陥sjis仕様のためsjisそのまま使うことはないよね
仮に入力も出力もsjisなら内部表現もsjisのままにしてsjis処理関数いっぱい
書くのも見合うケースがあるかもしれないけど
入出力の片方がsjisでないならば他との変換必ず必要だから内部表現をsjisにこだわる意味はないよね
一方で内部表現として処理を無条件に簡単にしようとするとUTF32で1文字32bitにするしかないけど常にUTF32強制ではメモリが無駄すぎる
そこでメモリ上だけでなくファイルもネット通信も無駄を避けるためにUTF8を用いる
という当たり前の帰結になりRustもそうだけどこれの何が不満なの？ >>266
いや、内部表現なんてどうだっていいんだって
utf8以外のテキストを使うとResult<Error>でぶっ飛ばされるのが面倒なの >>267
それはUTF8文字列として扱う関数を使うからそうなる
普通に生バイト列として扱う関数を呼べばよい
このへんは多くのプログラミング言語で同じ話 >>264
fgetsで良いって言うなら単にVec<u8>で読むだけだと思うけど
エラー処理が面倒というならとりあえずunwrapしてればいいし
そういうので文字数がかさむのが嫌だというなら、Rustは合ってないんじゃないかな
Rustは基本的にソースコード上にいろいろ明記したい言語なので >>269
それって行の切り出し(改行までのsplit)って自分で書かなきゃだめ？ >>270
それは書かないといけないね
たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
って人が多いんじゃないかな
実際Linux環境でCR改行のファイルをfgetsするとどうなるのかよく分からんし
そういうふうに処理系がうまくやってくれることを期待するならGoとかもほうが合っているかも うーん、Windowsでsjisファイル読み込むのってそんなにニッチなのか……
>>271
>たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
>って人が多いんじゃないかな
BufReaderがあるので、それはないかと >>273
read_lineはLF区切りって決まってるからそんなに気にならないけどな
fgetsはプラットフォーム依存じゃなかったっけ？
もう忘れてしまったけど これはRustの問題ではない
例えばスクリプト言語であるJavaScriptでもsjisファイルを読み込むにはNodeでも標準サポートはない
だから生バッファに読み込んで次にそのsjisを内部へ変換するという手順となる
いずれにせよ文字コード変換の一行が余分に入るだけでありどの言語でも大した問題ではない
>>272
うん、それはそうなんだ>splitすればいい
でも、なんでこんなにしつこく聞いたかっていうと
最近の言語にこんな基本的な機能ないわけないだろ？と思ったからなんだ
確かに自分で書いたって大した処理じゃない
でも、一人ひとりがそんな原始的なコード書いてるの？
ありえない 標準で用意しとけやって >>275
文字コード変換だけなら文句は言わない
昔からMulitbyteToWideCharを噛ませるぐらいのことはやってたからね >>278
おおっ！ これ良さそうだね！
試してみる！ サンキュー 要はバイナリのsplitがあればいいんだろ
まあニッチだし標準には入りにくいだろうな
>>265
ログ的なものや、テキストファイルが大きくなる。
開発中にはソースやバイナリを高頻度に単純コピーでバックアップしたいが、
そのとき、毎回毎回大きくなるのでディスクの無駄使いになる。 >>281
それはもうutf8の問題じゃないんじゃないか？ >>281
今さら何を言ってるんだ？
UTF-8が長いとか短いとか論争してたのは20世紀の過去の話であり今は2021年だ
UTF-9のエイプリルフールRFCが出たのですら16年前の2005年だ
既に20世紀に今後は世界中全てUTF-8で行くと方向が決まった >>242
No.
Linux やら BSD やらでファイル名を UTF-8 と保証しているものはたぶん少数派だ。
ロケール設定で UTF-8 を選ぶのが多数派になっているのは疑いがないが、
システムとして保証しない分だけ Windows よりつらい。 >>282
日本人そっちのけで勝手にアメリカ人が作った文字コード。
日本(と中国)だけが不利になった。 最近でもJSは日本語の文字イベントがサポートされてない。
アメリカ中心。
UTF-8の規格制定の時にはアジア圏も割と口出しだんではなかった？
>>287
日本語の文字イベントという意味不明なものは何だ？
日本語じゃない文字イベントというのも聞いたことないぞ sjisのfgets()相当の件だけど
標準のBufReaderのlines()で回すのは何が不満なんだっけ？
use std::error::Error;
use std::fs::File;
use std::io::{BufReader, BufRead};
use encoding_rs::SHIFT_JIS;
use encoding_rs_io::DecodeReaderBytesBuilder;
fn main() -> Result<(), Box<dyn Error>> {
let file = File::open("sjis.txt")?;
let reader = BufReader::new(DecodeReaderBytesBuilder::new().encoding(Some(SHIFT_JIS)).build(file));
for line in reader.lines() {
println!("utf8: {}", line?);
}
return Ok(());
}
>>290
nativeのWin32やMFCだと、IMEで日本語入力した時、WM_CHARで
SJISやUnicodeの文字コードを取得できるが、ブラウザ上のJSだと、
英字の範囲でしかそれに該当するイベント、つまり、IMEで
漢字やひらがなを打った結果を取得する文字イベントが無い。 >>291
いいね！
取得した文字列をOsStringに変換しなくても
なぜかファイルパスとして正常に動作するし(UTF16じゃなくていいのか……)
encoding_rs標準になればいいのに encoding_rsが標準になって欲しい(stdに入って欲しい？)のはなぜ？
>>295
・基本機能だから
・ロジックを標準化するため
・Cargo.tomlのdependancyに記述するのが面倒だから
特にバージョン指定 >>296
stdに取り込む提案のRFC書いてみたら？ UTF8（とASCII）以外の文字コードを扱うのが基本機能とは思えんが
>>296
> 基本機能だから
UTF-8さえ標準で扱えれば問題ない､UTF-8は世界標準だから
よって基本機能ではない
なので標準化する必要もないし､cargo.tomlに依存ライブラリを書くのが面倒ならapt-getでライブラリをインストールして使うC言語でも使えばいい >>301
「utf8以外を使う場合のやり方を標準化してほしい」って要望に対して
「utf8を使え」ってのは答えになってない 今は多少議論の余地があっても、数年したら
「なんでstdにSJIS扱うライブラリ入ってるの？ めったに使わないのにバカじゃねーの」
って言われるのが目に見えてる
エンコーディング関連のコードは量が多いだろうから
あらゆるプログラムのコンパイル時間を増やしたりバイナリサイズを大きくしたりするだけの価値があるかという議論にはなりそう
encoding_rsはSJISのためのライブラリじゃないでしょ
Cとかだと依存ライブラリの導入が面倒すぎるから標準化してほしいというのもわかるが
Cargo.tomlに一行書くのが面倒と言われてもあまり共感は得られないんじゃないかな
>>285
その通り。だから、
>>251
に書いたように、ユーザー名・ファイル名などのシステムには、ascii しか使えない
システム内部で、UTF-8/16 のどちらを使っているか不明だから、
共通項のasciiしか使えない
ただ、Windows で日本語のファイル名を使っている人も多いから、その場合は、
>>242
に書いたように、WSL で、Linux, UTF-8 に変換できると言うだけ
Windows言語だけは特殊。
Windows言語以外のすべての言語は、Linux, UTF-8 が基本 >>302 UTF-8を使えというより､今の標準はUTF-8だから標準化する必要がないということを言いたかった
そんなものを標準化したところで使うのは英語圏以外だけだし､その英語圏以外でも滅多に使うことはないから必要に応じてcargo.tomlに書き加える今の方式で良い >>311
多数決で言えば漢字文化圏の方が人口が多い。
しかも母国語が漢字を使う。英語を母国語とする人口は三億人くらい。
漢字を母国語で使うのは15億人くらい。
漢字以外の多バイト文字を使う国まで入れたら70億人、つまり地球の95%異常
となる。英語の方が少数派。 >>311
多数決で言えば漢字文化圏の方が人口が多い。
しかも母国語が漢字を使う。英語を母国語とする人口は三億人くらい。
漢字を母国語で使うのは15億人くらい。
漢字以外の多バイト文字を使う国まで入れたら70億人、つまり地球の95%異常
となる。英語の方が少数派。 漢字とかもあるけど、例えばMIME64のデコードとか
エンコード・デコード処理の標準化と考えれば英語圏でもありかも
日本語をユーザー名・ファイル名など、システムに使うのは、Windows の香具師だけ
Linux を使うプロは絶対に、ascii しか使わない。
せいぜい、ハイフン・アンダーバーぐらい
もし、半角空白でも使えば、あちこちから怒りの声が届く。
システムがバグるから使うな！
>>315
ここにいる人間はそんなことわかってるから、まあ落ち着け Linux のテレビの録画システムで、
日本語のテレビ番組名を、そのままファイル名にしていた香具師がいたけど、
バグって使えない
Rubyボットの活動範囲がさらに広がってきたな
よほど暇なんだろう
>>307
そこは実は本質的な要件ではないらしく
>>249
> sjisファイルを読み込みたい
> でもチュートリアルにあるようにBufReaderは使えない
が本質的な要件だから
utf8と全く同様にFile::openとBufReaderしてreader.lines()を使えれば良いと見て
>>291のコードを提案した
そして「いいね！」とレスしてるからこれでOKのようだ Windows ではプログラムをインストールするフォルダが Program Files となっているのは
パスが空白を含むくらいでおかしくなるようなカスなソフトを早めに発見するためなんよな。
パスが空白も漢字も含みうる仕様なのに対応してないソフトがあるならそのソフトがカスなだけじゃん。
今の時点で現実にそういうソフトがあるから仕方ないという論法だと
SJIS のデータがあるから仕方ないというのと言ってることは同じなわけで、
データが大事かソフトが大事かという点で軸が違うに過ぎない。
Windows 11は64-bitのみになるみたいだけど
Rustじゃ i686-pc-windows-gnu, i686-pc-windows-msvc はいつまでTier 1なんだろう？
>>325
32bit macがtier3落ちしたときはxcodeでコンパイルもできないし実行環境もないからって理由だったはず
同様にmsvcはMSがサポート切ってくればなくなるかもね
32bitアプリ自体が動かなくなるわけじゃなさそうだしgnuは大丈夫なんじゃないかな Win11はOSが32bitCPUでは動かないってだけで32ビットアプリはまだ動くのでは
Win11は、16bitが公式では完全に動かなくなる
