21/06/19 01:15:49.18 3FFA7ImF.net
>>1 おつ
3:デフォルトの名無しさん
21/06/19 01:20:06.41 VXoz87sA.net
>>1
乙
4:デフォルトの名無しさん
21/06/19 02:14:18.53 tZhqlEYm.net
勉強中でいまいちよくわかってないんだけどさ
よくRsutでメモリの扱いが安全になるとか言われてるけど、これって解放忘れを防いでくれるだけであって、オーバーフローを防いでくれるものではないわけ？
それとも登場する全ての型がオーバーフローしないような仕組み(スタックプロテクター以上の何か)があるの？
5:デフォルトの名無しさん
21/06/19 03:26:44.04 5peZoltk.net
>>4
型のオーバーフローっていうのは算術オーバーフロー(桁あふれ)のことかな？
であればここを読むといいと思う
URLﾘﾝｸ(doc.rust-lang.org)
6:はちみつ餃子
21/06/19 04:22:00.60 /f53/cxR.net
7:スタックプロテクターの話題を出すってことは バッファオーバーフロー (バッファオーバーラン) のことじゃないかな。 配列は大きさの情報を持っているし、 配列の一部の範囲を受け渡すときはポインタでなくスライスで扱うのが Rust の基本的な設計になってる。 ポインタと違ってスライスは範囲の情報を持っているのでチェック可能で、チェックする仕様になってるよ。 溢れたら panic する。 (もちろん unsafe な操作をしたらいくらでも危険な操作は出来る。) 絶対に溢れないことがコンパイル時に見抜ける場合であれば チェックしないように最適化したりすることもあるし、 チェックする場合でも現代的な CPU ではほぼ確実に分岐予測が成功するから 処理速度が遅くなる分は十分に小さいとかいう話があったはず。
8:デフォルトの名無しさん
21/06/19 09:47:40.12 5peZoltk.net
バッファオーバーフローのことなのか
Safe Rustでは基本的に発生しないが仕組みというより
unsafeなコードを書く人が要求された安全性を保証するという約束の上に成り立ってる
Rustの要求するメモリ安全性を保証するためには
unsafeなコードでポインタをdereferenceする前にout-of-boundsかどうかのチェックが必要
9:デフォルトの名無しさん
21/06/19 14:15:48.54 lGsmv2n4.net
境界チェックなんて他の言語でもあるし、別にそこがRustの特別な強みではないんだよな
それよりは、
> これって解放忘れを防いでくれるだけであって
だけじゃなくて、use-after-freeとか、
思わぬ箇所でオブジェクトが変更されることによるデータ競合とか、
をコンパイル時にチェックできるのが強い
詳細はThe Book 4章に
URLﾘﾝｸ(doc.rust-lang.org)
日本語版はこっち
URLﾘﾝｸ(doc.rust-jp.rs)
10:デフォルトの名無しさん
21/06/19 15:41:11.20 7Y2aa0wT.net
解放忘れ（メモリーリーク）はRustは
保証してないのでは？
11:デフォルトの名無しさん
21/06/19 16:32:09.25 +A5T+Cz1.net
Rc/Arc以外でメモリリークって起こるの？
12:デフォルトの名無しさん
21/06/19 16:52:09.35 5/JSw/kX.net
Box::leakして返された参照を捨てるとメモリリーク起こせる
13:デフォルトの名無しさん
21/06/20 02:45:16.68 O2AvtKTb.net
最近勉強始めたんだが、正直ムズイ
特にwinapiのポインタ引数が(構造体のポインタではなく)DWORDで定義されてたりするので、
キャストするのが超絶面倒臭い
microsoftはcrate修正してほしい
まあ、rustというよりwinapiの問題なんだが……
14:はちみつ餃子
21/06/20 02:57:43.41 h62I7Iw3.net
わかる。
DWORD とポインタをカジュアルに同一視する API はまだマシなほうで、
Rust は文字列をスライスで扱うから単純にポインタに変換してもヌル終端されてないのがクソめんどい。
文字列を渡すとかすごく普通にあることなんで、それがこんなに面倒くさいの勘弁して欲しい。
15:デフォルトの名無しさん
21/06/20 06:34:35.27 9R7FlmLP.net
普通に書いててwinapiとか使う機会ないと思うけどOS機能を直接触る必要のあるライブラリでも書いてるのかな?
16:デフォルトの名無しさん
21/06/20 15:00:11.94 ZAMdhkls.net
OS層に近いAPI全く使わないならrustやc++とかデメリットの方が多いような。
17:デフォルトの名無しさん
21/06/20 16:38:08.85 K2CzG+CP.net
俺も最近Rust勉強してるんだけど、GC無しでのメモリ管理が最高に気持ちいい
何もかもRustで書きたくなる
18:デフォルトの名無しさん
21/06/20 17:33:03.51 D+WmuL2+.net
ワイは基本moveってところが気に入ってる
参照をもって回るんじゃなくて
実態をmoveで渡してmoveで返されるとき清々しいのを感じる
19:デフォルトの名無しさん
21/06/20 17:51:48.27 BAitg4NO.net
システムコールや低レベルなライブラリをいい感じに安全にラップしてくれるcrateが提供されてるのはrustの良いところ
20:デフォルトの名無しさん
21/06/20 19:32:30.59 5UZIMOEC.net
moveって最適化ビルドだと消えたりしてるのかな？
21:デフォルトの名無しさん
21/06/20 21:04:33.39 BAitg4NO.net
moveが消えるとは？
moveがコンパイルされた結果のmemcpyなどが消えることはある
22:デフォルトの名無しさん
21/06/20 22:37:40.54 X7PAuK/l.net
>>13
Rustのスライスは、ほぼPascal文字列だから、Cよりも古くから作法や
概念は存在している。
しかし、なぜCがPascal文字列ではなく0終端文字列にしたのかには
理由があって、文字列の途中(部分文字列)を扱わない場合においては効率が良いから。
0終端文字列の欠点は、部分文字列を扱おうとするととたんに面倒なことになること。
ただ、strcmpみたいなものを書いたり、字句解析を書いたりするときには、効率は良い。
字句解析では決定性オートマトンの理論がグラフ的(状態遷移図的)になっており、
Cの0終端文字列とはとても相性が良い。
そして、コンパイラの実行時間の大部分は、実測してみると、意外にも字句解析が占めている。
字句解析は単純ではあるが、量が多いので1クロックの差がものをいう世界である。
ただ、Pascal文字列(スライス)が字句解析でも有利に働く場面はあるにはあるが。
どちらの方式が一方的に優れているとはいえない。
23:デフォルトの名無しさん
21/06/20 22:45:58.47 X7PAuK/l.net
>>21
すまん。今調べたら、Pascal文字列は、配列の先頭に文字数が
入っている特殊な形式で、スライスとはまた違うものだった。
今まで誤解していたわ。
Pascal文字列はダメだわ、全く意味無し。
ただ、俺が言いたかったのは、Rustのスライス方式も古くから概念自体は存在し、
Win32APIでもGetTextExtentPoint32()なんかが、ポインタと、その後に続く
文字数の両方を指定する方式を取っている。
このやり方は、文字列の中に 0x00 を埋め込まなくても部分文字列を扱えて
便利は便利。もしこれを部分文字列の場所を少しずつ変えていくようなの場合に、
0終端文字列でやろうとすると、効率が悪くなる。
ただ、いつでもスライスの方が0終端文字列より効率が良いという訳ではない。
それが>>21で言いたかったこと。決定性や非決定性オートマトンの考え方で字句解析を
する際には、Cの0終端文字列はスライスより効率が良い。
24:デフォルトの名無しさん
21/06/20 22:54:46.58 D+WmuL2+.net
読む価値無い文章をダラダラ書いちゃうのって
なんらかの障害なんやろな
25:デフォルトの名無しさん
21/06/21 00:08:08.49 85An+spJ.net
>>22
そのせいでPascal文字列は長さ255文字までに制限されてたのよな。
26:デフォルトの名無しさん
21/06/21 00:46:14.79 PP3lMGGZ.net
結論は、Rustがそんなにすばらしい言語とは到底思えないということだ。
27:デフォルトの名無しさん
21/06/21 02:03:12.76 wnQSc3ge.net
ええんやで
28:デフォルトの名無しさん
21/06/21 03:36:25.54 JQDu6zSa.net
>>25 まぁ用途によるやろ
発展途上なところもあるし､そもそもRustが向いてないような用途もある
29:デフォルトの名無しさん
21/06/21 07:39:35.72 3uERIKtL.net
>>13
様々な文字列処理をしたことがある人になら自明ですが
文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です
例えば何段か深いディレクトリの絶対パスが与えられた時に各ディレクトリのリストを返す（つまりsprit）時
￥0終端方式だと元の文字列を書き換え破壊しない限りコピーが発生してしまいます
スライス方式だと書き換えもコピーも発生しません
これは正規表現によるパターンマッチングでも同じで￥0終端方式だと結果である部分文字列をコピーしなければ返せません
またHTMLやJSONなどの様々な構造データの解析結果でもそうです
JSON文字列を解析して内部構造化表現にする時もスライス方式ならば文字列のコピーが発生せずに済むわけです
30:デフォルトの名無しさん
21/06/21 08:53:58.31 xiUkcw19.net
>>28
>文字列を扱う場合は￥0終端よりもスライスのほうが圧倒的に有利です
有利だろうが何だろうが、APIや過去の資産を活用するのに面倒という事実は何も変わらないが
31:デフォルトの名無しさん
21/06/21 09:07:04.10 WbPJLyAM.net
そういやRustの std::ffi::OsString って￥0終端なんだっけ？
32:デフォルトの名無しさん
21/06/21 09:43:03.40 ILFJsIgR.net
>>30
違う
null terminatedはCString
33:デフォルトの名無しさん
21/06/21 11:29:12.30 +vRECSeH.net
>>29 FFIのことを考えつつスライスの恩恵(境界チェックなど)も受けるなら今のRustの文字列に最後に\0を入れるようにしたらいいと思ったけどなんでしないんやろ
\0分の1バイトぐらい今のPCじゃ問題にならないはず
34:デフォルトの名無しさん
21/06/21 11:49:33.30 hH2X9nxJ.net
>>32
従来の &str (部分文字列) とnul終端文字列を区別しないといけないけど
型で区別しようとすると結局今のCStr/CStringと同じになるのでは
文字列は部分文字列含め全部Stringみたいにヒープアロケーションするなら良いけどさすがに効率が悪すぎる
35:デフォルトの名無しさん
21/06/21 12:03:56.90 vy1X2bYf.net
これps5は60fpsでます？？
36:デフォルトの名無しさん
21/06/21 12:11:12.63 743v8uRC.net
Rust違いです
ってかゲームのほうのRustって個別スレ無いんだね
37:デフォルトの名無しさん
21/06/21 12:12:05.66 oYpDc35T.net
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'足す方が簡単かもしれない
38:デフォルトの名無しさん
21/06/21 12:43:27.64 UE5kS0Iw.net
>>28
気持ちは分かるし、実際、その例に挙がっているケースではそうなんだけど、
字句解析は、コンパイラ理論の状態遷移図に基いて行うと効率が良いが、
それは 0 終端文字列の方が効率が良い。
39:デフォルトの名無しさん
21/06/21 12:53:52.20 UE5kS0Iw.net
何度も言うが、全面的にスライスが良いなら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++; の部分が追加されて効率が落ちる。
40:デフォルトの名無しさん
21/06/21 13:02:34.21 WbPJLyAM.net
Linuxカーネル開発における「Rust」採用の動き、グーグルとISRGがさらなる後押し
URLﾘﾝｸ(japan.zdnet.com)
> Googleは、ウェブサーバーソフトウェアの「Apache HTTP Server」向けのモジュールをRustによるモジュールで置き換えるというISRGのプロジェクトも支援している。
41:デフォルトの名無しさん
21/06/21 13:11:18.52 +4cAknZI.net
windows apiを使ってメッセージダイアログボックスを表示するサンプルが載ってるサイト教えてください
42:デフォルトの名無しさん
21/06/21 13:25:05.28 hH2X9nxJ.net
>>38
今のcpuとコンパイラの最適化で両者にどれくらいの性能差があるか示したベンチマークなどある？
rustでも文字列末尾に0を差し込めば同じことはできるので、本当に速くなるなら最適化の手法として採用しても良いかもしれない
43:デフォルトの名無しさん
21/06/21 13:41:31.99 G7rEBmCP.net
>>41
試しに手元の環境で1GB分やってみたが1割くらい差があるね
コンパイラはgcc9
でもRustの文字列ってnull文字含むことができるんじゃなかったっけ？試したことないけど
44:デフォルトの名無しさん
21/06/21 13:52:57.02 xiUkcw19.net
>>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);
}
}
45:デフォルトの名無しさん
21/06/21 14:00:39.66 yyeRDQfZ.net
設計判断ってのは常にトードオフの選択だからな
ヌル終端にすることで得られるものと失うものを天秤にかける必要がある
得られるものしか見ないやつは設計からは手を引け
46:デフォルトの名無しさん
21/06/21 14:01:15.31 yyeRDQfZ.net
トレードオフね
あー恥ずかし
47:デフォルトの名無しさん
21/06/21 14:13:19.21 t12YpwM9.net
ああトードオフは重要だよな
48:デフォルトの名無しさん
21/06/21 14:31:05.42 ILFJsIgR.net
>>38
ptrとlenが分かってるなら別途カウントアップしていかなくても
どの位置のptrまで読めばいいか最初に分かるんじゃない？
49:デフォルトの名無しさん
21/06/21 14:45:15.77 6c6Y8dXA.net
Rustってなんでprintlnの後にビックリマークあるの？
50:デフォルトの名無しさん
21/06/21 14:51:45.48 G7rEBmCP.net
>>47
確かに。end_ptrとの比較で終了判定した場合は(1)と差はなかった
比較一個分くらいなら今どきのプロセッサの並列実行で
十分吸収できるということかな
51:デフォルトの名無しさん
21/06/21 14:58:01.41 oYpDc35T.net
>>48
printlnは関数じゃなくマクロだから
ちなみにマクロにしてる理由は引数の型と個数が不定だから
52:デフォルトの名無しさん
21/06/21 15:29:27.47 +4cAknZI.net
>>43
先輩ありがとうございます！
53:デフォルトの名無しさん
21/06/21 15:40:08.22 WbPJLyAM.net
そういや、可変長引数を直接書けないからRustはクソって言う人はまだ見た事ないな
あんまり使わないからかな？
54:デフォルトの名無しさん
21/06/21 16:23:01.35 hH2X9nxJ.net
>>42
文字列中にNULが含まれないことを前提とした最適化だから
NUL含む場合は使えないという制約はあるね
Cの文字列と同じ制約だから実用上あまり困らないんじゃないのかな知らんけど
55:デフォルトの名無しさん
21/06/21 16:29:47.09 hH2X9nxJ.net
>>52
Cで可変長引数使いたくなるのってprintf系関数以外なんかある？
56:デフォルトの名無しさん
21/06/21 16:52:01.19 xiUkcw19.net
>>54
ない
標準関数ではprintfとscanfだけ
57:デフォルトの名無しさん
21/06/21 17:01:59.90 UE5kS0Iw.net
>>47
なるほど、こういうことかな：
(2)' (ptr, len)でスライス文字列を表現している場合 :
int btm = ptr + len;
while ( ptr < btm && *ptr >= 'A' && *ptr <= 'Z' ) {ptr++;}
>>49
差は少なくはなるが、無くなるわけではない。
ptr < btm という部分が残るから。整数比較命令と 条件jmp命令の
合計2命令はまだ(1)より多い。
58:デフォルトの名無しさん
21/06/21 17:23:50.71 a6mPBEl9.net
>>56
そりゃ命令数に差があるのは当然だけど
現代的なプロセッサの並列発行や分岐予測を考慮して
なおパフォーマンス差があるかを見たかっただけなので
そちらは実際測定して差を確認できた？
59:デフォルトの名無しさん
21/06/21 17:32:00.25 xiUkcw19.net
議論するのそこ？
むしろセキュリティ(バッファオーバーランの危険性)とパフォーマンスを秤にかけて
rustはセキュリティの方を採用したってだけじゃない？
パスカル文字列なんて昔からあったわけだし
60:はちみつ餃子
21/06/21 17:54:38.56 5bV+3LP7.net
>>52
どうしてもやりたければビルダーパターンでまとめてから渡すイディオムが確立してるから
そんなに不満にもならないんじゃない？
61:デフォルトの名無しさん
21/06/21 18:00:00.24 W8eb/Sbg.net
>>58
いや安全な方を選んだってのはそのとおりだと思うけど
理論上遅いはずってのを実際測るとそうでもなかったってのはよくある話で
そこが気になっただけ
62:デフォルトの名無しさん
21/06/21 18:49:34.95 xiUkcw19.net
>>60
rustが組み込みも視野に入れている以上、現代的なプロセッサは当てにできないと思う
8bitマイコンとかでrustが動くのかどうかはわからないけど
63:デフォルトの名無しさん
21/06/21 19:12:19.82 Qd3Oxzyr.net
>>61
別にRustはあらゆるアーキテクチャでのパフォーマンスを保証するつもりはないと思うけどね
実際測定してるのはTier1環境だけだろうし
64:デフォルトの名無しさん
21/06/21 21:14:54.92 MXwcp+e6.net
winapiクレートを使うことってもうなくね？
Microsoft公式のwindiwsクレートの方がよっぽど使いやすいよ
65:デフォルトの名無しさん
21/06/21 21:47:08.31 L+7FW+LR.net
>>38
＞(1) ptrが0終端文字列を挿している場合:
＞while ( *ptr >= 'A' && *ptr <= 'Z' ) ptr++;
その場合でも、まず与えられたデータが0終端しているかどうかを確認する必要がありますよね。
データがどこから来るのかは、
ネット上の通信相手か
ディスク上のファイルか
メモリ上の他言語等APIかになりますが、
いずれも盲目的に信頼せずに処理する必要があります。
そして小さいデータならばどんな処理方法でも誤差になるのでしょうが、
大きなデータの場合は>>28のように元はJSONとかHTMLのように構造をもっており、
その解析結果である各一部分が対象文字列になります。
すると0終端させた方がわずかに速く扱える可能性があるからといって、元の大きなデータから毎回コピーして0終端文字列を作る場合と、
コピーをせずにスライスのまま部分文字列を扱う場合との、比較になるのでははいでしょうか？
66:デフォルトの名無しさん
21/06/21 22:00:11.19 xiUkcw19.net
>>64
>元の大きなデータから毎回コピーして0終端文字列を作る場合
どこからコピーの話が出た？
67:デフォルトの名無しさん
21/06/21 22:22:17.51 oYpDc35T.net
>>65
変更したくない文字列"あいうえおかきくけこ"から部分文字列"かき"を取り出す場合、
スライス式だと元の文字列の[5:7]の範囲という形で表現できるからコピー不要だけど
ナル終端式だと"く"が邪魔で"かき\0"にできないからどこかに"かき"のコピーが必要になる
って話が>>28に出てる
68:デフォルトの名無しさん
21/06/21 22:57:58.01 xiUkcw19.net
>>66
なるほど、理解した
69:デフォルトの名無しさん
21/06/21 22:58:56.43 ILFJsIgR.net
その比較は部分文字列をコピーするかスライスで表現するかの違いであって
0終端文字列のメリット・デメリットとは少し違うんじゃない？
0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要
70:デフォルトの名無しさん
21/06/21 23:46:42.70 oYpDc35T.net
>>68
> 0終端でも同じようにスライスを(ptr, len)で作ればコピーは不要
それをやってしまうとその部分文字列に対して0終端のメリットが効かなくなるわけで
コピーしないとメリットを得られないというのがデメリットになってる
71:デフォルトの名無しさん
21/06/22 02:10:06.59 JEO56Dr7.net
つまり部分文字列を扱う場合は、コピーが発生する0終端方式が不利になりますね。
具体的にファイルパスからディレクトリ部分を得るとか、URLからホスト名を得るとか、元データを破壊したくない時は0終端方式だとコピーするしかないです。
つまり一貫してRustのように始点＆長さ方式の方が、有利かつメモリ安全ではないでしょうか？
さらに文字列比較の場合も長さ方式よりも0終端方式が不利です。
これはCのmemcmpとstrcmpの比較に還元されますが、
memcmpは64bit比較やSIMD利用ができるからです。
72:デフォルトの名無しさん
21/06/22 02:44:25.97 fStlaCDg.net
&strって3つの意味があると思うんだよね
1: 文字列リテラル
2: Stringの参照
3: 部分文字列
文字列リテラルとStringは終端にNULLを付けるようにして(今まで通りlenやcapは残す)､部分文字列は部分文字列を意味する別の型を作ればいいと思った
こうすることでRust側ではlenやcapを使い､C側ではNULL終端を利用できるという状態になる(Stringや&strをRustで使ってもCで使ってもゼロコスト)
もしNULL終端ではない部分文字列をCで使いたければStringに変換すれば使えるようになる(これはコストがかかるけどCの文字列も同じ問題を抱えてるので問題なし)
73:デフォルトの名無しさん
21/06/22 08:19:32.37 7Ks2gqqv.net
>>70
それやるには文字列がimmutableでなければならないから、それによって生じるスペースコストとどっちをとるかって話だな。
それにimmutableな文字列って、部分変更に相当する処理をする場合に逆にコピーが必要になるし。
どっちにしても一概に、コピー不要だからこっちが有利、みたいな話にはならんかと。
74:デフォルトの名無しさん
21/06/22 12:15:08.38 UUxAOJV3.net
rustで初心者がハマるポイントを初心者が紹介します
・所有権の概念が難しい
・何をするにしても外部ライブラリが必要（乱数生成など）
・ポインタが難しい
75:デフォルトの名無しさん
21/06/22 12:16:52.83 hfO2UPRV.net
・検索すると同名のゲームの話ばかり出てくる
76:デフォルトの名無しさん
21/06/22 12:26:02.44 jOUHjhXv.net
・static変数の扱いが面倒臭い
77:デフォルトの名無しさん
21/06/22 12:52:20.13 P9tLBTwV.net
>>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終端されている。
78:デフォルトの名無しさん
21/06/22 13:23:35.92 D73AVe+6.net
>>76
ファイルから読んだデータをpszHogeに格納するときにゼロ終端の要件満たしてるか確認する必要あるよねって話だぞ
79:デフォルトの名無しさん
21/06/22 13:25:24.28 RVuteXyT.net
>>74がマジで深刻すぎる
ついでに加藤純一っていうゲーム実況者とかとじゅんっていうRust/Scala使いがいるのも紛らわしい
80:デフォルトの名無しさん
21/06/22 13:35:53.88 IhZgQU+B.net
>>76
>というのは、必ず0終端されている文字列の事なので確認は不要。
という考えで脆弱性を量産してきたC言語の負の歴史を顧みて
Rustを始めとした新しい言語は異なる文字列表現を採用してるわけだ
81:デフォルトの名無しさん
21/06/22 14:06:03.07 P9tLBTwV.net
>>77
コンピュータの世界で「確認」とは、データの中を検査するという意味で
使われるが、そういうことは不要。
自分で末尾に 0 を書き込む必要があるだけ。
82:デフォルトの名無しさん
21/06/22 14:15:33.98 3bNpX0tT.net
そこで確認不要とか言ってるからユーザにヌル文字含んだ文字列渡されて死ぬのでは
83:デフォルトの名無しさん
21/06/22 14:51:42.58 jOUHjhXv.net
セキュアプログラムは面倒だからなー
数値のオーバーフローチェックとかみんなやらないでしょ？
アップキャストして値に結果を放り込んでチェックした後、
ダウンキャストするとか面倒すぎる
84:デフォルトの名無しさん
21/06/22 15:18:09.96 YfWe7YWP.net
>>73
Cより面倒臭そうω
85:デフォルトの名無しさん
21/06/22 15:19:46.85 YfWe7YWP.net
>>76
そこまで出鱈目な話初めて聴いたわ
86:デフォルトの名無しさん
21/06/22 15:22:37.78 P9tLBTwV.net
>>81
そういう外部からの入力に対するエラーチェックはするのは当然だが、
0終端文字列でやる場合には、ファイルのバイト数だけ読み込んで、
一番最後に 0 を書き込んでおくとそれ以上まで進むことはない。
途中の 0 に関しては スライス方式でも同じ問題が残る。
途中に 0 が有っても大丈夫な様に作るだけ。
87:デフォルトの名無しさん
21/06/22 15:24:47.81 P9tLBTwV.net
>>84
ちなみに、リアルワールドでは俺は名プログラマだと評価されているぞ。
88:デフォルトの名無しさん
21/06/22 15:27:25.45 P9tLBTwV.net
良いプログラムを作るための基本ポリシー：
・外部データと内部データは明確に分ける。
・外部データを内部データに入れる場合は、エラーチェックを徹底的にする。
・内部データに関しては、原則的には完全に正しいことを前提にしてプログラム
して良い。ただし、プログラムのミスのための念のためのチェックはしても良い。
89:デフォルトの名無しさん
21/06/22 15:47:48.20 cJZ3y9Eg.net
>>87
３番目のチェックはアサーション（assert）だと思うけどあれはコードを読む人に背景の条件を明示する意味もあるね
逆にアサーション以外の余計なチェックはコードを読む人を混乱させる可能性がある
90:デフォルトの名無しさん
21/06/22 16:20:58.03 N/B8oZfx.net
ヌル終端はパンチカードが現役だった時代に数バイトケチった名残
互換性のためにサポートしなきゃいけないのは理解できるが
今の時代にヌル終端が優れてるとかそれをデフォルトにしろってのは控えめに言って頭おかしい
91:デフォルトの名無しさん
21/06/22 16:22:09.51 jOUHjhXv.net
>>87
外部と内部の定義プリーズ
92:デフォルトの名無しさん
21/06/22 16:30:14.48 P9tLBTwV.net
>>90
外部でーたとしては、他にも有ると思うが、一例としては、
1. 他人が自由に書けるファイルから読み取ったばかりのデータ。
(アプリケーション内部にリソースデータとして内蔵し、安全性が
テスト済みであるようなファイルは内部データとみなしても良い場合も有る。)
2. 安全対策を徹底したいライブラリの場合は、ライブラリを使う側が関数に
渡してきたテキストデータや引数の値。
ただし、このようなものまで徹底的にチェックするとなれば遅くなるので、
設計思想によっては、NO-CHECK、または、軽いチェックだけで済ましても良い。
3. OSの場合は、同様なものとして、APIを呼び出した側が渡してきたデータ。
これは、安全性チェックは徹底して行う必要がある。
4. データベースソフトなどの場合も、2や3に準ずる。どこまで安全チェックするかは、
使用目的や用途、設計思想による。
93:デフォルトの名無しさん
21/06/22 16:34:27.28 jOUHjhXv.net
ちょっと緩くないか？
94:デフォルトの名無しさん
21/06/22 16:48:00.98 FRtvqWA7.net
信頼境界線の引き方は諸説あるだろ。
95:デフォルトの名無しさん
21/06/22 19:06:39.53 R8WO8pxt.net
一般に、アプリの外に置いてあるファイルはチェックした方が良いが、
その中でも、テキストファイルは、信頼置け無い事が多いのでチェックは必要。
アプリの外に置いてあっても、バイナリデータだと人が手書きすることはないため、
設計思想にもよるが、安全チェックはある程度省略しても良いと考える流儀もありえる。
96:デフォルトの名無しさん
21/06/22 19:33:50.85 D73AVe+6.net
結局アプリケーションがどう使われるか次第でしょ
アプリケーション作成時の前提が利用シーンの増加により後から覆されるなんてことは良くあることだから
性能要件がない限り最初から安全側に倒しておくのが合理的
97:デフォルトの名無しさん
21/06/23 11:02:20.62 o/eJBU4s.net
constデフォルトあたりの話ってgoto禁止論みたいになっている気がする
理由を理解していないがとりあえずそうしておけみたいな人を少なからず見かけるような
>>94
パーサーがガバガバで細工したセーブデータで乗っ取られるゲームのことか
98:デフォルトの名無しさん
21/06/23 14:27:15.67 LIFxwhU8.net
>>95
MS製のリンカ(link.exe)の入力するlibraryファイル(*.lib)には、
ヘッダ部分にシンボルがアルファベット順にソートされたシンボルテーブル
が入っている。ソートされていることを前提にバイナリサーチが出来るので
シンボルを検索するのが高速になるとされる。バイナリサーチは、ソート
されているデータに対してのみ正しく検索できて、もしソートされていなければ
間違った結果になる。
しかし、link.exeが*.libを入力する時、ちゃんとシンボルテーブルのシンボル
がソートされたかどうかチェックしているかと言うと、定かではない。
だから、もし、サードパーティー製のツールが*.lib を作成した時、
ソートにミスがあったりすると、link.exeはundefined s
99:ymbolエラーを出すか、 リンクには成功するが、実行段階でアプリが起動できなかったり途中でダウン してしまうかも知れない。その様な場合、何が原因かは分からないであろうが、 多分、実際、検査はされてない。
100:デフォルトの名無しさん
21/06/23 14:30:46.54 LIFxwhU8.net
>>97
実際は、サードパーティー製ツールも、ちゃんと*.libのヘッダのシンボルテーブルの
シンボルはソートしており、その部分にはバグはないので、それがソートされてない
*.libは基本的には存在しない。
ただし、*.libをバイナリエディタで開いて手作業で間違って変更したりすると
ソートされていないものが出来上がる。
それをlink.exeに入力しても、link.exeは、そのことに関してのエラーは出さない
だろう。
101:デフォルトの名無しさん
21/06/23 16:29:36.30 6jEPjWCz.net
Rustのスレだよね？
102:デフォルトの名無しさん
21/06/23 17:44:15.71 rKa/khCP.net
小学生が大人に九九暗唱してみせれば微笑ましいが
大人が大人に九九暗唱してみせるなら不気味で滑稽である
103:デフォルトの名無しさん
21/06/23 18:25:31.65 mfn5LAEG.net
意図通りに動かないバグにつながるという話と
バッファオーバーフローみたいな脆弱性につながるという話は別だよね
104:デフォルトの名無しさん
21/06/23 19:58:13.96 smIE1EjE.net
再帰を使って1x1=1から9x9=81までの答えだけを書く場合
どうやって書けますか？
105:デフォルトの名無しさん
21/06/23 20:12:50.89 1lBkKsRv.net
fixコンビネータを使う
106:デフォルトの名無しさん
21/06/23 22:38:48.46 GhG+XcCm.net
>>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),
}
}
107:デフォルトの名無しさん
21/06/23 23:13:30.14 Cy7wfzk/.net
実践的な話をするとRustは末尾再帰最適化が出来ないからなるべく再帰は使わないほうがいいと思う
108:デフォルトの名無しさん
21/06/24 01:50:53.81 UNoTdpdl.net
宿題かなんかだろう。
Rustで宿題を課すなんて教官は変態にもほどがある。
109:デフォルトの名無しさん
21/06/24 23:17:10.64 zHNnGFYG.net
>>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
}
結局のところ関数分割→個別ループ化→関数統合で二重ループ化まで自動でしてくれる言語は無いから
再帰は使わずに自分でループ化すればいいよね、って結論
つまりアルゴリズムでは再帰で考えても実装はループにしてコメント残しておくのが正解
110:はちみつ餃子
21/06/25 00:17:11.72 /YhIejlL.net
>>107
プログラミング言語 Scheme の仕様だと >>104 のようなパターンは末尾文脈の定義にあてはまるし
末尾呼出し最適化が適用されることが保証されるから、
現代的な言語処理系で最適化できないとは信じられないんだけど、
実際にRust コンパイラに >>104 を与えたときにループに最適化はしないの？
Rust のコンパイラの使い方に不慣れでアセンブリコードの出力のさせかたがよくわからん……。
ほぼそのまま C のコードに書き換えてみたら
GCC ではジャンプに置き換えたコードが生成されるみたいだし……。
(ちなみに GCC では末尾呼出しになっていなくても一部の状況では再帰をループに変形できることがある。)
Clang だとループを全部 unroll しやがった！
111:デフォルトの名無しさん
21/06/25 11:49:33.37 UuPR+dCF.net
c言語だと再帰が末尾呼び出し最適化されるかどうかがオプティマイズレベルで変わるからややこしい。
リリース版だと動くがデバッグ版だとスタックオーバーフローみたいな事になる。
単純な再帰ならループに書き直してもいいけど、相互再帰みたいなのは末尾呼び出し最適化してくれないと困る。
112:デフォルトの名無しさん
21/06/25 11:58:36.77 CpYoiDkc.net
あの、Rustの勉強のために逆引きサンプルwiki作ろうと思うんですけど
テンプレ殿堂入りを目指して作ってもいいですか？
もちろん
113:広告は入れませんが、レンタルwikiが提供している広告は表示されるかもしれませんが。。。
114:はちみつ餃子
21/06/25 12:05:43.49 /YhIejlL.net
>>110
目指すことは自由じゃないの。
皆がどう判断するかも自由だけど。
115:デフォルトの名無しさん
21/06/25 12:18:21.65 CpYoiDkc.net
先輩ありがとうございます！
受け入れてもらえるようなコンテンツを作ります！
116:デフォルトの名無しさん
21/06/25 15:26:59.18 CCUOu52e.net
5chに閉じずに本家のコミュニティにも便利と思ってもらえるもの目指した方が良いのでは
117:デフォルトの名無しさん
21/06/26 00:57:24.13 QiaGJu0I.net
>>86
ただし石器時代のな
118:デフォルトの名無しさん
21/06/26 02:18:19.63 morUmgAo.net
>>114
ミンチメーカー、ではなくスパゲティメーカーとして恐れられてるかもな
119:デフォルトの名無しさん
21/06/26 03:08:39.74 ljqTs+jf.net
Rustと他の言語との違いについて興味深い観点で盛り上がってるスレ
特に後半
趣味でプログラミングの勉強するとしたら何言語がいい？
ｽﾚﾘﾝｸ(morningcoffee板)
120:デフォルトの名無しさん
21/06/26 12:15:14.01 jgmCFZtl.net
斜め読みしかしてないから見逃してるかも知れないけどさんざん言い尽くされた話ばかりだった気が
そもそもRust自体はC++を置き換えることを目的にはしていない
121:デフォルトの名無しさん
21/06/26 14:26:52.57 UK7NU6RE.net
やたらC++と比較されるのはどっちもbetter Cの側面があるからだろうか
個人的にRustはCとScheme（Lisp）のハーフという印象
SchemeよりMLの方が近いらしいけどMLは使ったことないからよく分からない
手続き型で関数型を疑似表現したり関数型で手続き型を疑似表現する試みがあるけど
Rustはその中間を上手く埋めてる感じ
122:デフォルトの名無しさん
21/06/26 14:33:02.82 S/dGZFG2.net
> better Cの側面がある
はぁ？
お前がcもc++もrustもニワカなのは分かった
あと五年間は、カキコ無前にROMに徹してみてほしい
123:デフォルトの名無しさん
21/06/26 15:07:09.40 UK7NU6RE.net
>>119
急にどうしたんだ
better Cの意味が分からなかった感じ？
124:デフォルトの名無しさん
21/06/26 15:16:37.21 zCIOA2Bt.net
実際にはRustはbetter D
125:デフォルトの名無しさん
21/06/26 15:47:21.36 vR4ZYNRj.net
急に発狂する奴はどこの掲示板にもいる 気にするな
126:デフォルトの名無しさん
21/06/26 16:24:43.50 MKHy+X82.net
わざわざ自演するようなことかね？
127:デフォルトの名無しさん
21/06/26 16:34:36.83 jgmCFZtl.net
mozillaのc++を安全に使う数多の取り組みに疲れ果てた結果出てきた新言語がrustなのでc++と比較されるのは当然
128:デフォルトの名無しさん
21/06/26 18:03:00.84 cKS/UcnU.net
この板全域に出没して何でもRubyと比較するガイジみたいなもんだろ
ここにはなぜかいないけど
129:デフォルトの名無しさん
21/06/26 18:06:17.50 uWTCkdSJ.net
>>116
Rust布教スレになってんじゃん
不健全
130:デフォルトの名無しさん
21/06/26 19:35:22.90 pNIxzUaQ.net
今から新規のプロジェクトをC++かRustで始めるとなったらRustの一択でしょう
つまりRustはbetter C++
131:デフォルトの名無しさん
21/06/26 21:22:24.72 yvLLLScj.net
まったく何も資産がない新規であればそうかもしれんが
132:デフォルトの名無しさん
21/06/26 21:36:19.59 js6oaYoM.net
>>118
どこらへんがschemeに近い？
よく知らんがschemeってカッコが一杯あって、再帰ばっかりしてるイメージなんだが
133:デフォルトの名無しさん
21/06/26 21:43:00.01 pNIxzUaQ.net
つまり過去のしがらみのある案件は時間がかかり遅れるが
いずれも徐々にC++はRustへ置き換えられていく
134:デフォルトの名無しさん
21/06/26 21:48:35.28 IGj3fs8T.net
逆に枯れてる分野でしか実装されんわ
135:デフォルトの名無しさん
21/06/26 21:51:34.18 uWTCkdSJ.net
emacsとあとなんだっけ？ SVGのライブラリ？が
オブジェクトファイル *.o 単位で少しずつCからRustに移植してたな
136:デフォルトの名無しさん
21/06/26 22:01:32.26 WPp8qNv5.net
librsvgだね
137:デフォルトの名無しさん
21/06/26 23:01:02.22 UK7NU6RE.net
>>129
ifとかmatchのブロックがそのまま値になるところが何となくS式っぽいんだよね
ブロックの最後の式が全体の値になるのも(begin ..)に近いし
138:デフォルトの名無しさん
21/06/27 00:09:44.66 hddKqCef.net
それは単に式指向という話なのでは
139:デフォルトの名無しさん
21/06/27 00:12:27.99 HvPCU4P8.net
MLの方が普通に近いな
パターンマッチとか束縛がletとかHMの型システムだとか
140:デフォルトの名無しさん
21/06/27 01:36:30.56 AjjhDlM0.net
一番近いのは Ocaml。なぜなら、かつてRustはOcamlで組まれていたから。
そして途中でコンパイラをRust自身に直したと聞いた。
141:はちみつ餃子
21/06/27 03:28:07.65 +5rTVQj/.net
Rust の Scheme っぽいところを探すとしたらマクロだろ。
伝統的な Lisp 系言語だと実行時の環境とマクロ展開時の環境を分けないが、
Scheme は分ける方針をとってる。
(実際には分けない実装をしている処理系もあるし、次の仕様の更新でどうなるか不透明だけど。)
142:デフォルトの名無しさん
21/06/27 12:22:30.08 HfXxTqRR.net
何に近いかでここまで盛り上がれるのだね
何も産まないのに
143:デフォルトの名無しさん
21/06/27 12:24:39.60 lZYiAKce.net
Parkinson's Law of Triviality
144:デフォルトの名無しさん
21/06/27 13:55:37.78 00z9rPIn.net
>>139
比較から何かを見出せる人もいるから何も産まないということはないよ
145:デフォルトの名無しさん
21/06/27 14:24:31.82 me9wSnu9.net
そんなセンスのある人がここにいると思うのｗｗ？
センスないねｗ
146:デフォルトの名無しさん
21/06/28 20:31:57.40 cQA8O+iD.net
ちょっと見ないうちに色々変わる＋自分の理解が浅いせいで追いつけない
147:デフォルトの名無しさん
21/06/29 16:25:09.28 W3FYE8ZM.net
RustのIDEでおすすめを教えて
148:デフォルトの名無しさん
21/06/29 19:29:01.37 EbM9PL2b.net
VSCode+rust-analyzerが定番
149:デフォルトの名無しさん
21/06/30 01:32:52.11 kSD4a98e.net
bindgenって複雑なヘッダーだと全然駄目なんだなあ
殆どそれ目的でRustやってたのに
150:デフォルトの名無しさん
21/06/30 09:59:01.57 2LaR0NZ5.net
>>146
実際に使ってみて初めて分かる問題点だね。
151:デフォルトの名無しさん
21/06/30 22:36:50.05 Nj/xCjQN.net
>>146
CXXはどうですか？
152:デフォルトの名無しさん
21/07/03 10:43:55.27 6NDcSyYc.net
rust始めました！
ってゲームの方を始めてたネタをやろうと思ったけど
想像以上にクソゲー過ぎてダメだった
やっぱり言語の方がいい
153:デフォルトの名無しさん
21/07/03 16:18:59.47 VnJT/Tz5.net
検索するとゲームの方と言語の方が出てきてややこしい
Rust(ゲーム)は名前変えてくれ...
154:デフォルトの名無しさん
21/07/03 16:30:28.41 lPTKqMkr.net
それな
go(一般動詞)も名前を変えてくれ
155:デフォルトの名無しさん
21/07/03 16:48:51.41 VnJT/Tz5.net
GoはGolangって別名があるから問題ないけどRustに関してはRustLangとはあまり言わないのがなぁ
156:デフォルトの名無しさん
21/07/03 17:18:42.64 HAk/Aizq.net
まあそれはRustの問題ではないですが、クロス環境に問題を感じているなら、Haskellがお勧めですよ。
あわしろ氏がいつも言ってることですがね。
157:デフォルトの名無しさん
21/07/03 18:23:28.50 yvqGZDdm.net
rustlang言わない？
158:デフォルトの名無しさん
21/07/03 19:07:06.86 3WlrzvVf.net
そもそもオフィシャルのレポジトリ名がrust-lang/rustだし普通に言うのでは
159:デフォルトの名無しさん
21/07/03 19:51:08.37 VnJT/Tz5.net
言わなくはないけどRustLangよりはRustと呼ばれることのが多い気がする
GoだったらGo(golang)とかGolangとか言われることが多いけど
160:デフォルトの名無しさん
21/07/03 22:13:02.85 yvqGZDdm.net
単にgoよりgooglabilityが高いことのあらわれじゃね
別にそんなに困ったこと無いけどな
161:デフォルトの名無しさん
21/07/03 23:01:24.13 5pcVeoYl.net
ていうかGoはもうgolangに改名したほうがいいと思う
Goではとにかく名前がクソすぎる
そもそもなんかダサいし
162:デフォルトの名無しさん
21/07/04 00:56:25.25 KTwjVJIR.net
goはogle（いやらしい目で見る）という名前のデバッガとセットで売り出す予定だったけど
ogleがこけたから残念な名前だけが残ってしまった
163:デフォルトの名無しさん
21/07/04 01:51:19.90 1GGCqeGW.net
Rustってゲームなかったっけ？
164:デフォルトの名無しさん
21/07/04 05:17:25.91 pNIAvX41.net
あるからこまってる
165:デフォルトの名無しさん
21/07/04 09:10:12.70 1GGCqeGW.net
JuliaでAV女優ばっか出てくるのと一緒やな
166:デフォルトの名無しさん
21/07/04 09:10:48.09 FDfsH90c.net
たいていは rust + 別の単語 でググるけどゲームの情報が出てきて困ったことはあまりないかな
167:デフォルトの名無しさん
21/07/04 09:12:10.94 Ik+vLhuV.net
pythonってそう考えるとなかなかいいネーミング
168:デフォルトの名無しさん
21/07/04 09:13:21.27 1GGCqeGW.net
そういやRustはツイッター検索だとかなり厄介だったな
169:デフォルトの名無しさん
21/07/04 09:25:35.54 FDfsH90c.net
既存の名詞使うときは perl みたいにスペルに一ひねり加えるのが良いんだろうね
rust でやるのは難しいけど
170:デフォルトの名無しさん
21/07/04 17:06:20.02 DVzGg7Pn.net
>>166
pearlとしなかったのは既存言語が存在した偶然みたいだけどね
phpは某雑誌がよく引っ掛かってたな
171:デフォルトの名無しさん
21/07/05 22:26:57.75 GYdy1bNH.net
Rust とかGoとか固有名詞やめてほしいよね。。。
172:デフォルトの名無しさん
21/07/06 00:14:23.09 cmRSsVyO.net
固有名詞でない言語名...
「名前を言ってはいけないあの言語」みたいな名付けかな
173:デフォルトの名無しさん
21/07/06 00:37:05.95 GFPrEw7Y.net
既存の固有名詞じゃない方が珍しい気がする
174:デフォルトの名無しさん
21/07/06 07:26:35.07 SYh5jqXt.net
そう言う意味だとCとか最悪だな
175:デフォルトの名無しさん
21/07/06 09:07:51.28 qxjbHNhG.net
langを付けると意味が変わるしCは本当に検索ワードに迷う
176:デフォルトの名無しさん
21/07/06 10:07:00.27 t2+Z62DR.net
C++もtwitterでは検索できない。C#もだけど。
それは、わざとなんらかかの意図を持ってされていることかも知れない。
twitteの社長や技術者がC++が嫌いだとか。
177:デフォルトの名無しさん
21/07/06 11:00:10.66 cmRSsVyO.net
/ も無視されるし単純に記号が無視されるだけでしょ
178:デフォルトの名無しさん
21/07/06 11:33:36.74 GDULTuH0.net
つまりまたもやlispが最強だと判明してしまったわけたな
179:デフォルトの名無しさん
21/07/06 12:33:05.02 paV/EiqB.net
ガイジ度でRubyには勝てんだろ
180:デフォルトの名無しさん
21/07/06 13:48:45.02 t2+Z62DR.net
>>174
技術的には簡単に直せるのに直さないところに意図を感じる。
181:デフォルトの名無しさん
21/07/06 15:47:25.27 qxjbHNhG.net
技術的に簡単だと思うなら外部サービスとして提供してみたら？
182:デフォルトの名無しさん
21/07/06 17:48:26.50 W6OOwnvK.net
外部から伺い知れない部分について簡単に違いないと断言する人とは議論しとうない
183:デフォルトの名無しさん
21/07/06 17:56:26.40 luG13vJj.net
全文検索とか形態素解析を少しでもかじってたら簡単とは思えないはずなんだけどね。
184:デフォルトの名無しさん
21/07/06 18:02:06.64 t2+Z62DR.net
>>178
外部サービスとは？
内部の人がやるのは簡単でも、外部の人がやるのはとても大変。
>>180
俺は字句解析系はよくやっているので簡単に感じるが。
185:デフォルトの名無しさん
21/07/06 18:08:31.76 8bcWgGBz.net
人は陰謀論が大好きなんですよ
186:デフォルトの名無しさん
21/07/06 18:15:25.48 nSctAZgU.net
字句解析と形態素解析や全文検索はまったくの別物だろう
187:デフォルトの名無しさん
21/07/06 18:16:09.96 t2+Z62DR.net
陰謀論とかじゃなくて、壊したい相手に不利なようにするのがアメリカ流なんだよ。
卑怯な手口だが、卑怯という概念にはあの国には無いのだろう。
あの国の連中は、ことごとくそういう手口で生き残っているから、そのうち
技術の進歩が遅れてある時、がさっと負けだすかも知れないな、GAFAMも含めて。
188:デフォルトの名無しさん
21/07/06 18:17:03.75 t2+Z62DR.net
>>183
形態素解析などに入る前に、例えば、C++をcppと同一視してしまえばいいんだ。
189:デフォルトの名無しさん
21/07/06 18:20:48.86 M25Qh6q2.net
簡単に直せる
(計算量が増えたり既存機能に影響を与えたりするかもしれないけど)
ってことでしょ
190:デフォルトの名無しさん
21/07/06 19:17:37.60 luG13vJj.net
>>186
それを簡単と呼ぶのは研究とかラボの人間よね。
191:デフォルトの名無しさん
21/07/06 20:35:47.80 5M+Sovmm.net
字句解析と形態素解析の違いもわからないのはちょっと…
192:デフォルトの名無しさん
21/07/06 23:19:32.02 cmRSsVyO.net
まーたrustと関係ない話してる
193:デフォルトの名無しさん
21/07/06 23:35:07.67 qUsPK4G4.net
「また」って言うけど「いつも」の間違いだろ？
194:デフォルトの名無しさん
21/07/07 08:37:56.63 ICcjc0w9.net
>>184
で、c++を壊してtwitterにどんなメリットが？アホなの？
195:デフォルトの名無しさん
21/07/07 10:14:36.36 ifayQQT8.net
アホだと分かってるなら構うなよ
196:デフォルトの名無しさん
21/07/07 10:38:37.05 fRD7zTM6.net
URLﾘﾝｸ(lore.kernel.org)
panic問題は大部分解決されたみたい
197:デフォルトの名無しさん
21/07/08 01:55:46.25 qbgAaMCH.net
そういうのは形態素解析したあと、同義語辞書(シソーラス)で単語を正規化する作業になる。
形態素解析の段階で記号は除去しないとややこしくなるから記号入りの単語を使うのが悪いわな。
198:デフォルトの名無しさん
21/07/09 19:08:10.80 XWrdIq9z.net
ハッカーが使わない言語は流行らない。メモリ安全だけじゃ一部需要のみ
楽しい言語も流行らない。いつも趣味レベルの言語で終わる
199:デフォルトの名無しさん
21/07/09 19:58:26.11 /dpK029q.net
ハッカーって言葉久々に聞いた
200:デフォルトの名無しさん
21/07/09 20:07:52.69 vKrZ9ebb.net
自分のこと賢いと思ってそう
201:デフォルトの名無しさん
21/07/09 21:36:56.44 6sMTa3MH.net
流行で選ぶってアフィチューバーやアフィブロガーかな？
202:デフォルトの名無しさん
21/07/10 06:29:54.67 XPpA1ojF.net
一通り学習したつもりになったから、WebAPIで情報取得するプログラムでもいざ書いてみようと思ったら・・・・
いきなりreqwestのクレートでasync/awaitの壁があったぜ
これThe Bookのキーワードの項目にはあるものの、本編で出てきたっけ？？？
URLﾘﾝｸ(doc.rust-lang.org)
ちょっと適当に書いてみた感じ、他言語と違ってawaitしたところでアンラップされないのかな・・・・・？全然わからん
これって何を見たら学習できるの？
203:デフォルトの名無しさん
21/07/10 07:10:52.64 hr5Pc4AR.net
これでいいんじゃない？
URLﾘﾝｸ(rust-lang.github.io)
204:g_started/01_chapter.html
205:デフォルトの名無しさん
21/07/10 08:40:15.75 FBIqRA7j.net
reqwest::blocking使えば？
206:デフォルトの名無しさん
21/07/10 09:30:24.80 GKhTMPF2.net
ぼこぼこDLしてウザ過ぎる
207:デフォルトの名無しさん
21/07/10 09:31:26.47 GKhTMPF2.net
x.py build したあと、x.py install したら、
また意味不明にボコボコビルドし始めたんだけど、
知恵遅れなの?
208:デフォルトの名無しさん
21/07/10 09:47:05.85 4hsXIyfP.net
そういう所は今後改善して欲しいわな
209:デフォルトの名無しさん
21/07/10 13:41:38.31 e+Cu97LZ.net
>>195
面白い観点だな。
楽しい言語も流行らないか・・・、なんか考えさせられる。
210:デフォルトの名無しさん
21/07/10 13:52:24.60 aG/WAOkt.net
>>199
ureq 使えよ
211:デフォルトの名無しさん
21/07/10 14:01:01.07 4hsXIyfP.net
ハッカー専用の言語ってあるの？
212:デフォルトの名無しさん
21/07/10 14:20:32.32 hyh546Qk.net
prolog
213:デフォルトの名無しさん
21/07/10 14:25:24.27 jayrPH8y.net
いつまで miri のトラブルを放置しておくの?
ゴミ言語
214:デフォルトの名無しさん
21/07/10 14:28:17.22 a84ckjUx.net
ハッカーって・・・なに？
215:デフォルトの名無しさん
21/07/10 14:44:49.05 e+Cu97LZ.net
unsafeモードが使えても、safeモードでのコード生成結果が予測できないのであれば
使うのは難しい。
216:デフォルトの名無しさん
21/07/10 14:53:04.04 SrgkCeWe.net
無駄な通信と監視と役立たずのゴミでツリーを汚すゴミ
217:デフォルトの名無しさん
21/07/10 16:15:47.34 9b6+aeFV.net
ハッカーは書くスピードと実行時間が重要だからnimとかが向いてそう
少なくともRustは絶対にハッカーの第一言語にならない
218:デフォルトの名無しさん
21/07/10 16:53:00.70 zdV39cNV.net
お前がそう思うんならそういうことでいいよ
219:デフォルトの名無しさん
21/07/10 17:38:05.35 nAGZi/ZP.net
ハッカーとか呼んでねえからキーボードでもしゃぶってろ
220:デフォルトの名無しさん
21/07/10 17:43:28.58 IKbPFXW0.net
最強言語議論スレでやれ
221:デフォルトの名無しさん
21/07/10 17:56:33.98 wJrCg/wx.net
犯罪者用言語とか使いたくないなあ
222:デフォルトの名無しさん
21/07/11 01:09:10.02 MzFRAytS.net
ハッカー != 犯罪者 がモダンな解釈だと思うんだが。
○にかけのお爺さんかな？
223:デフォルトの名無しさん
21/07/11 02:27:33.50 0Hcxwo3i.net
ロシア人ハッカーグループって言ったら
犯罪者っぽくね？
224:デフォルトの名無しさん
21/07/11 02:54:13.69 6/u0+cwV.net
イスラエル人ハッカーグループって言うと
なにか巨大な国際政治がらみの陰謀っぽい
225:デフォルトの名無しさん
21/07/11 03:33:22.44 PFbpUEa3.net
日本人ハッカーグループ
よわそう
226:デフォルトの名無しさん
21/07/11 03:47:16.72 OgOa7vqd.net
日本は、一人当りのGDPだと先進30カ国中最下位レベルだけど、純粋な頭脳線だと、
三位以内に入ることが良くある。
227:デフォルトの名無しさん
21/07/11 09:25:42.31 Z2zeAI0N.net
純粋な頭脳線
228:デフォルトの名無しさん
21/07/11 09:54:14.29 HGkeQify.net
>>199
Rustはasync/awaitを言語レベルでゼロコストでサポートする代わりに非同期ランタイムを別途用意する必要がある
これによりRustでは様々な非同期ランタイムを言語と独立に自由に作ることができる
例えば非同期ランタイムを自作することも当然できてfuturesクレイトをその部品として使うことができる
もちろん非同期ランタイムを自作せずとも既に様々なコミュニティから提供されているのでそれを使うこともできる
具体的には例えば最も使われているtokioなどのチュートリアルを見るのが良いかな
URLﾘﾝｸ(tokio.rs)
229:デフォルトの名無しさん
21/07/11 11:06:14.34 MzFRAytS.net
>>219-220
その考え方が古い。(というか最初から？)間違ってる。
ハッカー == 凄い奴 的な意図でしかないので
ロシアだろうがイスラエルだろうが某大陸だろうが
超エリートなんだろうなとしか思わない(事になってる)。
犯罪者はクラッカーと言って区別される(事になってる)。
区別しようと言い出したのは…(ry
230:デフォルトの名無しさん
21/07/11 12:38:13.92 8RaHq8wW.net
でも発端の>>195の「ハッカー」はホワイトかブラックかは知らんがセキュリティ関連の話ちゃうんか？
231:デフォルトの名無しさん
21/07/11 12:47:21.47 sDQUZcY3.net
>>225
モダンな解釈だと良いハッカー=ホワイトハッカー 悪いハッカー=ハッカーですね
あと老人ホームから抜け出してまで5chなんてしたら家族に迷惑かかりますよ
迷惑かけない内に尊厳死をおすすめします
232:デフォルトの名無しさん
21/07/11 12:48:22.75 BdwgI/w3.net
そんな高度な話だったんだ
小学生がうんこちんちんって罵倒してるようなものだと理解していた
233:デフォルトの名無しさん
21/07/11 15:23:07.49 MzFRAytS.net
>>227
> 悪いハッカー=ハッカー
では無いよ、と書いてる事が理解できないかな？
>>227 がどう思おうがどうでも良いけど
話が通じないことがある事くらいは理解しといた方が
身のためだぞ。
URLﾘﾝｸ(ja.m.wikipedia.org)ハッカー
迷惑かけない内に勉強し直す事お勧めておきます。
234:デフォルトの名無しさん
21/07/11 15:31:18.36 lbKLD5N+.net
相変わらずマウンター専用言語になっとるな
235:デフォルトの名無しさん
21/07/11 15:34:34.85 HtoAUPrm.net
正しい定義がどうだろうと>>195の意図なんかわからんのでどうでもいいうんこちんちん
236:デフォルトの名無しさん
21/07/11 16:25:58.47 SRU4khSo.net
仕様や実装のマイナーな機能を使って人を驚かせるのがハッカーだ、と思ってるのでは
Cのポインタ祭りとかLISPのマクロ生成マクロとかを好むのだ、と
237:デフォルトの名無しさん
21/07/11 16:31:55.44 rINaUnOH.net
クソどうでもいい
238:デフォルトの名無しさん
21/07/11 16:37:35.60 8jG+0fGV.net
ハッカーの定義はどうでも良いからせめてrustの何がダメかを語れよ
239:デフォルトの名無しさん
21/07/11 16:47:25.03 0Hcxwo3i.net
rustは文字列の扱いに難があるなあ
sjisのコンテンツとかマルチバイトのファイル名(WinだとUTF16?)の扱い方がよくわからん
240:デフォルトの名無しさん
21/07/11 16:48:48.06 lbKLD5N+.net
Non-Lexical Lifetimes が制御フローレベルなので実装をデバッグできるやつがほとんどいない。
c++と同じレベルの複雑さを有するようになってきている。
cargoのビルドシステムがあまりに強制的すぎる。
メモリを直接いじる必要のある効率的なアルゴリズムでは結局unsafeになる。
メモリ最適化の許す範囲があまりに非自明でcから呼ぶのは不安定すぎる。
241:デフォルトの名無しさん
21/07/11 17:06:54.98 vvFM5IKu.net
コンテナ類が実際にどのように格納されているかが分からないと言うのは、
それをunsafeで扱うのが難しくなってる。
どこでコピーが生じて、どこがmoveなのかも分かりにくいことがあるし。
242:デフォルトの名無しさん
21/07/11 17:08:44.89 vvFM5IKu.net
ライフタイムもちゃんと仕様が書いてないから、手探り状態で試さないといけないし
プログラムするのに時間が掛かる。
色々やっても結局、C/C++のような効率のよい方法を取ることは不可能な場合もあるし。
243:デフォルトの名無しさん
21/07/11 17:30:39.23 QonYN50D.net
素晴らしい言語ですね
カニかわいい
244:デフォルトの名無しさん
21/07/11 18:42:50.97 0Hcxwo3i.net
ときどき、Javaの検査例外みたいなやらかし感を感じる
厳密にしすぎると却って使いづらいみたいな
245:デフォルトの名無しさん
21/07/11 19:53:14.68 8jG+0fGV.net
Box<dyn Error>やanyhowやeyreを使えば良いのでは
246:デフォルトの名無しさん
21/07/11 21:00:56.13 lZiRxAj0.net
>>235
Windows 系以外のすべての言語は、UTF-8
だから、MSYS/MinGW でも、UTF-8以外でバグるので、
UTF-8以外を使っちゃいけない！
唯一バグらないのは、WSL。
Windows Terminal, VSCode のRemote WSL などで、
ls /mnt/c/Users/Owner/Documents/
と入力すると、日本語のフォルダ名も、正しく表示される
出力
あ
い
たぶん、Windowsが変換しているのだろう
247:242
21/07/11 21:05:19.71 lZiRxAj0.net
WSL は一種のチート
ハイパーバイザーでLinux を起動して、
Linux側から、Windows側のドライブを見た時に、
UTF-8 以外の言語をUTF-8に変換する
まあ、漏れの推測だけど
248:デフォルトの名無しさん
21/07/11 21:46:26.10 0Hcxwo3i.net
>>242
そこに文句言われてもねー
要件に文句を付けるのはフェアじゃない
現実にUTF16でネーミングされたファイルがあって、
それにどう対応するかって話なんだけど
249:242
21/07/11 22:51:28.82 lZiRxAj0.net
だから、プログラマーの基本は、Windows 系など、UTF-8 以外を使わない事！
この大原則を守っていない人は、システムを作れない
システムには、ascii しか使えない！
これが大原則
250:デフォルトの名無しさん
21/07/11 22:51:54.52 3favf/XH.net
>>244
WinならOsStringのエンコーディングは普通にUTF-16だから何の問題もないと思うが
sjis扱いたいならencoding-rsとか
結局何に困ってるのかわからないと何とも言いようがない
251:デフォルトの名無しさん
21/07/11 22:52:47.14 g6LNT/Hh.net
Ruby外耳に構うなよ
252:デフォルトの名無しさん
21/07/12 00:42:25.80 Hp3EIfPo.net
じつはわしはRustはやったことなかったのだが、
これまでの経験上おそらく >>236 みたいな感じだろうなと想像してたら
ほんとうにそのとおりでワロタw
アホみたいに「安全ドグマ」に縛られるとたいがいそうなる
253:デフォルトの名無しさん
21/07/12 01:08:52.63 hS+nIw/n.net
>>245
プログラマーの基本！ とか システムを作れない(ｷﾘｯ とか言われても
既存のシステムがそうなってるんだという話
「システムには、ascii しか使えない！」とか言ったら、客に帰れと言われるだけ
>>246
sjisファイルを読み込みたい
でもチュートリアルにあるようにBufReaderは使えない
そりゃ読み込んだ後、変換処理したら何でもありでしょ
でも、ネイティブに処理できん？と思う
むしろ安全性にこだわる割に文字に対するこの雑さは何なの？と
254:デフォルトの名無しさん
21/07/12 01:27:11.82 j3ZM+094.net
論理的な問題点以前に、言語として見た目的な美しさも無いし、記述が
簡潔でもなければ直感的でもなく、無駄に長くなる。
255:242
21/07/12 01:50:03.57 7a0iIKMk.net
システムには、ascii しか使わないのは、Linux の基本
AWS でも、そう。
半角空白もバグるから、使わない
必ず、客から注意される。
日本語のファイル名・半角空白を使わないでと。
バグるから
例えば、5ch は、sjis だからバグだらけ。
; を書いていないのに、文字列の後ろに、; が付いてるとか
sjisとか、Windows以外では、どうしようもない
256:デフォルトの名無しさん
21/07/12 02:01:17.96 uNcygyrG.net
encoding-rsつかいにくい
257:デフォルトの名無しさん
21/07/12 02:17:50.78 MXdX1Uu3.net
>>249
バイト列としてVec<u8>に読んじゃえば後はCと一緒じゃん
それともlocaleとwchar_tフル活用したいという話？
258:デフォルトの名無しさん
21/07/12 02:37:38.72 hS+nIw/n.net
>>253
それでcrlfでsplitしろって？
なんて原始的な…
259:デフォルトの名無しさん
21/07/12 0
260:3:41:51.48 ID:3p3WQ9hU.net
261:242
21/07/12 04:00:29.19 7a0iIKMk.net
>>242
に書いたみたいに、
sjis, UTF-16 などのWindows 用言語で、
唯一バグらないのは、WSL だけ
WSL でLinux側から、Windows側のドライブを見た時だけ、
日本語のファイル名を正常に変換できる
Windows Terminal, VSCode のRemote WSL などで使える
ひょっとして、Windows用言語を扱っていて、WSLを使っていないの？
262:デフォルトの名無しさん
21/07/12 09:20:21.53 fBGbiQ8q.net
>>249
変換せずに扱いたいのか？いまいちよくわからんが、既存の言語で理想的なやつってどれ？
Rustは文字列に関しては最もちゃんとしてる方だと思うけど
263:デフォルトの名無しさん
21/07/12 09:26:54.48 fBGbiQ8q.net
あ、あとascii/WSLおじさんは気にしなくていいと思うよ
少なくともRustにそんな制限はない
Cとかだとasciiに限定したい気持ちもわからなくはないけど
264:デフォルトの名無しさん
21/07/12 09:39:13.23 cIYVT4Ba.net
・ファイルシステム上のエンコーディング
・OSのAPIのエンコーディング
・言語のAPIのエンコーディング
・言語の文字列のエンコーディング
それぞれ独立だし変換しあってることをおじさんは理解していないと見える
265:デフォルトの名無しさん
21/07/12 09:40:16.32 cIYVT4Ba.net
最後2つは基本的に同じだけど
266:デフォルトの名無しさん
21/07/12 09:56:37.25 Jwa42/D9.net
>>255
でもUTF8は「ひらがな」ですら3バイトになるので困る。
267:デフォルトの名無しさん
21/07/12 11:12:15.24 k3eDnaJZ.net
>>256
へー WSL って言語だったんだωωω
268:デフォルトの名無しさん
21/07/12 11:13:38.78 k3eDnaJZ.net
>>260
違うよ
269:デフォルトの名無しさん
21/07/12 11:24:40.84 hS+nIw/n.net
>>257
どれが理想的というか、rustは特にめんどい気がした
fgetsが出来ればそれでいいんだが
270:デフォルトの名無しさん
21/07/12 12:42:05.71 4jaglyfV.net
>>261
最近だと何に困った？
271:デフォルトの名無しさん
21/07/12 12:58:50.09 Yne+2tk7.net
>>249
sjisを変換せずそのまま内部表現として標準的に扱うプログラミング言語って具体的に何？
もちろん全ての言語でバイト配列としては扱えるけどsjisにとってそれは無意味であり
先頭から全読みしないとsjisの1バイト目か2バイト目かすらわからない欠陥sjis仕様のためsjisそのまま使うことはないよね
仮に入力も出力もsjisなら内部表現もsjisのままにしてsjis処理関数いっぱい
書くのも見合うケースがあるかもしれないけど
入出力の片方がsjisでないならば他との変換必ず必要だから内部表現をsjisにこだわる意味はないよね
一方で内部表現として処理を無条件に簡単にしようとするとUTF32で1文字32bitにするしかないけど常にUTF32強制ではメモリが無駄すぎる
そこでメモリ上だけでなくファイルもネット通信も無駄を避けるためにUTF8を用いる
という当たり前の帰結になりRustもそうだけどこれの何が不満なの？
272:デフォルトの名無しさん
21/07/12 13:37:26.66 hS+nIw/n.net
>>266
いや、内部表現なんてどうだっていいんだって
utf8以外のテキストを使うとResult<Error>でぶっ飛ばされるのが面倒なの
273:デフォルトの名無しさん
21/07/12 13:41:52.17 Yne+2tk7.net
>>267
それはUTF8文字列として扱う関数を使うからそうなる
普通に生バイト列として扱う関数を呼べばよい
このへんは多くのプログラミング言語で同じ話
274:デフォルトの名無しさん
21/07/12 13:45:10.21 XKWfaP9x.net
>>264
fgetsで良いって言うなら単にVec<u8>で読むだけだと思うけど
エラー処理が面倒というならとりあえずunwrapしてればいいし
そういうので文字数がかさむのが嫌だというなら、Rustは合ってないんじゃないかな
Rustは基本的にソースコード上にいろいろ明記したい言語なので
275:デフォルトの名無しさん
21/07/12 14:07:37.33 hS+nIw/n.net
>>269
それって行の切り出し(改行までのsplit)って自分で書かなきゃだめ？
276:デフォルトの名無しさん
21/07/12 14:14:18.06 XKWfaP9x.net
>>270
それは書かないといけないね
たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
って人が多いんじゃないかな
実際Linux環境でCR改行のファイルをfgetsするとどうなるのかよく分からんし
そういうふうに処理系がうまくやってくれることを期待するならGoとかもほうが合っているかも
277:デフォルトの名無しさん
21/07/12 14:16:40.71 4WArcuIG.net
splitすればいいだけじゃなくて？
278:デフォルトの名無しさん
21/07/12 14:18:27.57 hS+nIw/n.net
うーん、Windowsでsjisファイル読み込むのってそんなにニッチなのか……
>>271
>たぶんRustが好きな人は「fgetsだと何が改行コードとして想定されてるのか分からなくて不安」
>って人が多いんじゃないかな
BufReaderがあるので、それはないかと
279:デフォルトの名無しさん
21/07/12 14:29:03.08 XKWfaP9x.net
>>273
read_lineはLF区切りって決まってるからそんなに気にならないけどな
fgetsはプラットフォーム依存じゃなかったっけ？
もう忘れてしまったけど
280:デフォルトの名無しさん
21/07/12 14:30:57.94 7o0jLcLl.net
これはRustの問題ではない
例えばスクリプト言語であるJavaScriptでもsjisファイルを読み込むにはNodeでも標準サポートはない
だから生バッファに読み込んで次にそのsjisを内部へ変換するという手順となる
いずれにせよ文字コード変換の一行が余分に入るだけでありどの言語でも大した問題ではない
281:デフォルトの名無しさん
21/07/12 14:31:19.34 hS+nIw/n.net
>>272
うん、それはそうなんだ>splitすればいい
でも、なんでこんなにしつこく聞いたかっていうと
最近の言語にこんな基本的な機能ないわけないだろ？と思ったからなんだ
確かに自分で書いたって大した処理じゃない
でも、一人ひとりがそんな原始的なコード書いてるの？
ありえない 標準で用意しとけやって
282:デフォルトの名無しさん
21/07/12 14:35:03.79 hS+nIw/n.net
>>275
文字コード変換だけなら文句は言わない
昔からMulitbyteToWideCharを噛ませるぐらいのことはやってたからね
283:デフォルトの名無しさん
21/07/12 14:40:47.93 XKWfaP9x.net
最近の言語としては標準ライブラリが小さいというのはあるね
代わりに外部ライブラリをたくさん使うという方針
今のケースならこれかな
URLﾘﾝｸ(crates.io)
284:デフォルトの名無しさん
21/07/12 14:48:08.10 hS+nIw/n.net
>>278
おおっ！ これ良さそうだね！
試してみる！ サンキュー
285:デフォルトの名無しさん
21/07/12 14:48:41.98 hUBiSSyU.net
要はバイナリのsplitがあればいいんだろ
まあニッチだし標準には入りにくいだろうな
286:デフォルトの名無しさん
21/07/12 14:56:20.42 OFdOdpfq.net
>>265
ログ的なものや、テキストファイルが大きくなる。
開発中にはソースやバイナリを高頻度に単純コピーでバックアップしたいが、
そのとき、毎回毎回大きくなるのでディスクの無駄使いになる。
287:デフォルトの名無しさん
21/07/12 15:01:47.66 hS+nIw/n.net
>>281
それはもうutf8の問題じゃないんじゃないか？
288:デフォルトの名無しさん
21/07/12 15:08:46.48 wU8EXWL2.net
>>281
今さら何を言ってるんだ？
UTF-8が長いとか短いとか論争してたのは20世紀の過去の話であり今は2021年だ
UTF-9のエイプリルフールRFCが出たのですら16年前の2005年だ
既に20世紀に今後は世界中全てUTF-8で行くと方向が決まった
289:デフォルトの名無しさん
21/07/12 15:25:03.01 OFdOdpfq.net
日本語処理が僅かに遅くなる。
290:デフォルトの名無しさん
21/07/12 16:15:05.27 rb4auT/4.net
>>242
No
291:. Linux やら BSD やらでファイル名を UTF-8 と保証しているものはたぶん少数派だ。 ロケール設定で UTF-8 を選ぶのが多数派になっているのは疑いがないが、 システムとして保証しない分だけ Windows よりつらい。
292:デフォルトの名無しさん
21/07/12 16:35:47.66 OFdOdpfq.net
>>282
日本人そっちのけで勝手にアメリカ人が作った文字コード。
日本(と中国)だけが不利になった。
293:デフォルトの名無しさん
21/07/12 16:36:54.04 OFdOdpfq.net
最近でもJSは日本語の文字イベントがサポートされてない。
アメリカ中心。
294:デフォルトの名無しさん
21/07/12 17:25:47.35 +TTC9E1P.net
UTF-8の規格制定の時にはアジア圏も割と口出しだんではなかった？
295:デフォルトの名無しさん
21/07/12 17:31:04.46 XXt8kyyQ.net
余り上手く行ってなかったと聞いている。
296:デフォルトの名無しさん
21/07/12 17:47:35.65 msgpc4nf.net
>>287
日本語の文字イベントという意味不明なものは何だ？
日本語じゃない文字イベントというのも聞いたことないぞ
297:デフォルトの名無しさん
21/07/12 19:18:49.33 Yne+2tk7.net
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(());
}
298:デフォルトの名無しさん
21/07/12 19:44:27.20 XXt8kyyQ.net
>>290
nativeのWin32やMFCだと、IMEで日本語入力した時、WM_CHARで
SJISやUnicodeの文字コードを取得できるが、ブラウザ上のJSだと、
英字の範囲でしかそれに該当するイベント、つまり、IMEで
漢字やひらがなを打った結果を取得する文字イベントが無い。
299:デフォルトの名無しさん
21/07/12 19:46:32.99 NCQjfvng.net
>>292
URLﾘﾝｸ(developer.mozilla.org)
はい次
300:デフォルトの名無しさん
21/07/12 20:38:52.08 hS+nIw/n.net
>>291
いいね！
取得した文字列をOsStringに変換しなくても
なぜかファイルパスとして正常に動作するし(UTF16じゃなくていいのか……)
encoding_rs標準になればいいのに
301:デフォルトの名無しさん
21/07/12 22:26:31.98 +ke1h7j2.net
encoding_rsが標準になって欲しい(stdに入って欲しい？)のはなぜ？
302:デフォルトの名無しさん
21/07/12 22:49:13.65 hS+nIw/n.net
>>295
・基本機能だから
・ロジックを標準化するため
・Cargo.tomlのdependancyに記述するのが面倒だから
特にバージョン指定
303:デフォルトの名無しさん
21/07/13 00:30:07.97 n/daahFD.net
>>296
stdに取り込む提案のRFC書いてみたら？
304:デフォルトの名無しさん
21/07/13 03:10:04.82 EtxXgsUj.net
>>293
中身を理解して無いくせに黙ってろ。
305:デフォルトの名無しさん
21/07/13 03:20:46.36 qEHxTKb1.net
ｗｗｗ
306:デフォルトの名無しさん
21/07/13 06:39:54.56 cTgR7KKr.net
UTF8（とASCII）以外の文字コードを扱うのが基本機能とは思えんが
307:デフォルトの名無しさん
21/07/13 07:23:42.37 b6J4OLfP.net
>>296
> 基本機能だから
UTF-8さえ標準で扱えれば問題ない､UTF-8は世界標準だから
よって基本機能ではない
なので標準化する必要もないし､cargo.tomlに依存ライブラリを書くのが面倒ならapt-getでライブラリをインストールして使うC言語でも使えばいい
308:デフォルトの名無しさん
21/07/13 0
309:8:54:58.88 ID:NU/mwW4g.net
310:デフォルトの名無しさん
21/07/13 09:10:42.11 lb+vVVj1.net
今は多少議論の余地があっても、数年したら
「なんでstdにSJIS扱うライブラリ入ってるの？ めったに使わないのにバカじゃねーの」
って言われるのが目に見えてる
311:デフォルトの名無しさん
21/07/13 09:14:58.89 n/daahFD.net
エンコーディング関連のコードは量が多いだろうから
あらゆるプログラムのコンパイル時間を増やしたりバイナリサイズを大きくしたりするだけの価値があるかという議論にはなりそう
312:デフォルトの名無しさん
21/07/13 09:17:07.48 NU/mwW4g.net
encoding_rsはSJISのためのライブラリじゃないでしょ
313:デフォルトの名無しさん
21/07/13 09:36:27.67 /A7/SyKa.net
Cとかだと依存ライブラリの導入が面倒すぎるから標準化してほしいというのもわかるが
Cargo.tomlに一行書くのが面倒と言われてもあまり共感は得られないんじゃないかな
314:デフォルトの名無しさん
21/07/13 11:03:30.55 pwZ9R0Fi.net
>>291
変換したくないって話じゃなかったの？
315:242
21/07/13 11:43:58.46 dtNqNBdW.net
>>285
その通り。だから、
>>251
に書いたように、ユーザー名・ファイル名などのシステムには、ascii しか使えない
システム内部で、UTF-8/16 のどちらを使っているか不明だから、
共通項のasciiしか使えない
ただ、Windows で日本語のファイル名を使っている人も多いから、その場合は、
>>242
に書いたように、WSL で、Linux, UTF-8 に変換できると言うだけ
Windows言語だけは特殊。
Windows言語以外のすべての言語は、Linux, UTF-8 が基本
316:デフォルトの名無しさん
21/07/13 11:50:05.93 WUJYnH4r.net
SJIS 死ね
\ 死ね
317:デフォルトの名無しさん
21/07/13 11:52:00.92 WUJYnH4r.net
>>308
うby厨 死ね
318:デフォルトの名無しさん
21/07/13 12:40:03.07 pH6df75p.net
>>302 UTF-8を使えというより､今の標準はUTF-8だから標準化する必要がないということを言いたかった
そんなものを標準化したところで使うのは英語圏以外だけだし､その英語圏以外でも滅多に使うことはないから必要に応じてcargo.tomlに書き加える今の方式で良い
319:デフォルトの名無しさん
21/07/13 13:23:53.20 EtxXgsUj.net
>>311
多数決で言えば漢字文化圏の方が人口が多い。
しかも母国語が漢字を使う。英語を母国語とする人口は三億人くらい。
漢字を母国語で使うのは15億人くらい。
漢字以外の多バイト文字を使う国まで入れたら70億人、つまり地球の95%異常
となる。英語の方が少数派。
320:デフォルトの名無しさん
21/07/13 13:23:53.20 EtxXgsUj.net
>>311
多数決で言えば漢字文化圏の方が人口が多い。
しかも母国語が漢字を使う。英語を母国語とする人口は三億人くらい。
漢字を母国語で使うのは15億人くらい。
漢字以外の多バイト文字を使う国まで入れたら70億人、つまり地球の95%異常
となる。英語の方が少数派。
321:デフォルトの名無しさん
21/07/13 13:40:25.49 NU/mwW4g.net
漢字とかもあるけど、例えばMIME64のデコードとか
エンコード・デコード処理の標準化と考えれば英語圏でもありかも
322:242
21/07/13 13:42:56.59 dtNqNBdW.net
日本語をユーザー名・ファイル名など、システムに使うのは、Windows の香具師だけ
Linux を使うプロは絶対に、ascii しか使わない。
せいぜい、ハイフン・アンダーバーぐらい
もし、半角空白でも使えば、あちこちから怒りの声が届く。
システムがバグるから使うな！
323:デフォルトの名無しさん
21/07/13 13:46:44.21 NU/mwW4g.net
>>315
ここにいる人間はそんなことわかってるから、まあ落ち着け
324:242
21/07/13 13:46:50.24 dtNqNBdW.net
Linux のテレビの録画システムで、
日本語のテレビ番組名を、そのままファイル名にしていた香具師がいたけど、
バグって使えない
325:デフォルトの名無しさん
21/07/13 13:48:05.76 qZprVsAK.net
なんか変なのが居着いたな
326:デフォルトの名無しさん
21/07/13 14:21:53.19 Ooc6RI1Q.net
Rubyボットの活動範囲がさらに広がってきたな
よほど暇なんだろう
327:デフォルトの名無しさん
21/07/13 15:12:06.73 QsXB5/qu.net
今日はRust in Actionが45%off
328:デフォルトの名無しさん
21/07/13 15:55:17.99 oaeUW36h.net
>>307
そこは実は本質的な要件ではないらしく
>>249
> sjisファイルを読み込みたい
> でもチュートリアルにあるようにBufReaderは使えない
が本質的な要件だから
utf8と全く同様にFile::openとBufReaderしてreader.lines()を使えれば良いと見て
>>291のコードを提案した
そして「いいね！」とレスしてるからこれでOKのようだ
329:デフォルトの名無しさん
21/07/13 16:00:31.83 WUJYnH4r.net
>>316
だよな
そして >>315 がいつものあいつだということもみんなしってる
330:デフォルトの名無しさん
21/07/13 16:16:17.73 QSkHhbzy.net
Windows ではプログラムをインストールするフォルダが Program Files となっているのは
パスが空白を含むくらいでおかしくなるようなカスなソフトを早めに発見するためなんよな。
パスが空白も漢字も含みうる仕様なのに対応してないソフトがあるならそのソフトがカスなだけじゃん。
今の時点で現実にそういうソフトがあるから仕方ないという論法だと
SJIS のデータがあるから仕方ないというのと言ってることは同じなわけで、
データが大事かソフトが大事かという点で軸が違うに過ぎない。
331:デフォルトの名無しさん
21/07/13 19:45:00.15 SMX4Ldwl.net
cmd「せやな」
332:デフォルトの名無しさん
21/07/14 11:14:54.14 eOdFkTAr.net
Windows 11は64-bitのみになるみたいだけど
Rustじゃ i686-pc-windows-gnu, i686-pc-windows-msvc はいつまでTier 1なんだろう？
333:デフォルトの名無しさん
21/07/14 11:43:09.28 eD4Wlw/y.net
>>325
32bit macがtier3落ちしたときはxcodeでコンパイルもできないし実行環境もないからって理由だったはず
同様にmsvcはMSがサポート切ってくればなくなるかもね
32bitアプリ自体が動かなくなるわけじゃなさそうだしgnuは大丈夫なんじゃないかな
334:デフォルトの名無しさん
21/07/14 13:27:24.91 BkkfMVAi.net
Win11はOSが32bitCPUでは動かないってだけで32ビットアプリはまだ動くのでは
335:デフォルトの名無しさん
21/07/14 13:35:34.15 FWHo5b9L.net
それであってる
336:デフォルトの名無しさん
21/07/14 16:08:27.83 bE2/aeQE.net
Win11は、16bitが公式では完全に動かなくなる
337:デフォルトの名無しさん
21/07/16 07:53:03.75 xJNtEE5m.net
>>329
マジ！？ ちょっと困るなぁ
338:ハノン
21/07/17 20:18:11.59 Blzyac97.net
>>329
え？今までも64ビット版Windowsでは 16 bit は NE フォーマットを含めて動かないと思っていました‥‥
だから emu を使っていましたが、今なら動くんですか？
339:デフォルトの名無しさん
21/07/17 22:06:07.73 u8FQMqKe.net
Win11は u16, i16 が使えなくなるのか
ま、使ったことないけど
340:デフォルトの名無しさん
21/07/17 23:18:45.26 H+CbDngl.net
どうしてそうなる
341:デフォルトの名無しさん
21/07/18 01:10:05.65 uA1uG+Zo.net
冗談と気付くまで時間かかっちゃったぞ
342:デフォルトの名無しさん
21/07/19 17:48:08.64 Ex9Tt6CE.net
Rustの文法を教えて欲しいんだけどさあ
URLﾘﾝｸ(github.com)
ここのExampleの中にある
＞.json::<HashMap<String, String>>()
の行って、渡されたデータをHashMapに変換してるようだけど・・・・()があるから関数を呼び出しているんだろうけど、なのに関数名が無いってどういう文法なの？
343:デフォルトの名無しさん
21/07/19 18:18:59.22 N5AD9uIb.net
>>335
関数名はjsonで::の後はjsonの型パラメーター
344:デフォルトの名無しさん
21/07/19 18:58:43.60 R+McuOkS.net
>>335
turbofishで検索してみると幸せになれるかもよ
345:デフォルトの名無しさん
21/07/20 08:52:59.51 m4QWlK0Z.net
そういうことだったのか
チュートリアルやったつもりが全然身についてなくて、まるで初見の文法に見えたよ
ありがとう！
346:デフォルトの名無しさん
21/07/20 11:37:04.97 bZGFynsp.net
async/awaitよく理解できないので質問です。
async fnを.awaitすることは、
thread::spawn(fn)で得られたJoinHandleをjoinすることと何が異なるのでしょうか
347:デフォルトの名無しさん
21/07/20 13:18:42.59 ZLL16lvF.net
>>339
URLﾘﾝｸ(rust-lang.github.io)
348:デフォルトの名無しさん
21/07/20 13:51:30.35 x1qprig3.net
日本語でOK
349:デフォルトの名無しさん
21/07/20 14:46:16.61 0ur63h8Z.net
URLﾘﾝｸ(async-book-ja.netlify.app)
古い版ベースっぽいが
350:デフォルトの名無しさん
21/07/20 17:53:25.45 poqzYj22.net
>>339
どのプログラミング言語でも同じ概念の話として
非同期プログラミングとスレッドプログラミングの違いをまず学ぶと良いでしょう
非同期プログラミングはスレッド使わないシングルスレッドでも成立するしよく使われます
スレッドは無駄にリソースを喰って重いのでスレッドを使わないシングルスレッドでプログラミング出来る事ならばそれが最も軽くて速いです
まずはシングルスレッドでの非同期プログラミングを経験しておきましょう
もちろん最初はasync/awaitを使わずに非同期プログラミングを体験したほうが良いでしょう
そうすることで初めてasync/awaitの意義と利便性を理解することができます
以上が通常のasync/awaitの初心者がたどるべき入門コースです