Rust Part6
■ このスレッドは過去ログ倉庫に格納されています
タブ幅小さくして、その分変数名を分かりやすく長くするんだよ >タブ2で見ずらくなるようなネストの深さと関数の長さになるのが悪いと
2派と4派の対立は4が深すぎるか、2が浅すぎるかなのに「2で見ずらくなる深さ」って想定おかしくね?
3派は間とって3だよ。こっちは普及してないのが問題。 Scalaみたくスタイルガイド作っちゃえばいいのに
そうすれば「スタイルは公式に従うように」の一言で済む ハードタブなら各自好きな幅にすればいいから揉めないのにね。 回りの多数派にあわせるだけの話
こういうのにこだわるやつは大抵バカ
可読性w なんてここでタブ・スペース論争してんだ
どうせ一人でしか書かねえくせによ〜 >>489
ほんこれ
見やすさとか人によって違うしどうでもいい エディタファシストなのでエディタを開発したことないやつは駆除されるべきなのではと考え始めて来た。やばい 昔々学生の頃に学校のワークステーション使ってXlibでドット編集してXPMファイルで出力するなんてものを作った覚えがある。
あらから29年。時の経つのは早いものぢゃ。 読み込んで表示するより出力の方がはるかに簡単だしな >>494
xlib ダイレクト記述、とは猛者ですね…
私も最近になって xlib をバシバシ触ろうと思っていますが、いい参考書はありませんか? XlibってCの悪いところを煮詰めたような設計だったな
Rustとの相性は最悪だろう 日本語の参考書はX11R5の大昔に出た本ぐらいじゃないかな うん。新しいXlibの本は知らないなあ。
探す気も起きないから知らないだけかも知れないが。 >>498
なんというか、オブジェクトを作って操作するような感じなので今時の言語用のオブジェクト指向に合わせたラッパーは作れると思うが、需要はほとんどないような気がする。 xlibの使いやすいラッパーとしてはgtk+などなどがあるんわけで… >>465です
スタックにpopを実装しました
pop自体はうまく動いているようですが…
popした時の対象の物がどのタイミングで破棄されているのかを調べようと思いstd::ops::Dropを実装しようとしましたがうまくいきません。
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f1a2a2a35c3dc424f3814557afa5974c
何がいけないのでしょう haskellでの、文字列[Char]を切り貼りみたいな事をするには、
Vec<char>を操作するので合っているのかな? >>505 Dropを実装した型の値がdropされるとき、フィールドは全てvalidじゃないといけない。
そのままメモリ解放するだけ=Drop未実装ならいいんだけど、drop中にinvalidなフィールドにアクセスできちゃうのがダメだというのが問題
解決案は、ここでもOption::takeかmem::replaceでNoneにすげ替える
けど、まずはLearning Rust With Entirely Too Many Linked Listsを写経してみた方が良いよ
今のListの定義だと無駄なメモリを食うし、パターンマッチとstructは相性があんま良くないし、これから先も似たような穴にハマると思われる Rustいいらしいですよって話を会社でしたら、
テックリードが「RustでできることはCやC++でもテストとツールで十分やってけるからイラネ」って言ってたけどマ? &str で関数に渡すと解放されてしまって使い回すこどができないのですが
使い回す方法ありませんか >>510
コンピュータでできることは人の手と頭でできるよ >>512
じゃあうちにはたしかに要らんなあ
そんな統制がいるほどの人数でもないし
回答サンクス >>510
そのリードが C++でauto_ptrがdeprecatedになった理由とMove Semanticsと右辺値参照の関係をちゃんと説明できる人なら C++ でいい 人間が信用できないからこそCよりRustだろ
気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
コンパイラ先生に怒られながら厳しい指導の下にやっとコンパイルしていただくのがRust
この記事とか参考になるかも
https://tomo-wait-for-it-yuki.hatenablog.com/entry/2019/02/05/210746 プログラミングは製造業だからな
厳格なチェックは本来あって当然 >人間が信用できないからこそCよりRustだろ
>気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
ぴんとこないな。
rustの場合、お役所とおせばテストなど自前でしなくともokっていう
変な信用を生んでるだけだろ。そっちのがよっぽど日本的だと思うがね。 >>519
今時の言語なので、ユニットテストは標準で整備されてるよね
コンパイラは計算ミスや仕様間違いまではチェックしないので 考え得る全パターンをいつもテストできるならいいんじゃないの メモリ破壊はユニットテストで検出されないケースも多い 注意力ってのは慣れると省力できるようになるけど、有限リソースだし個人の習熟度と体力に依存するんで、目に見えない負債になる
新しい言語を理解するコストは償却できるけど、注意深さってのはソースコードを触る限りはコストを発生し続ける
機械がチェックできることは機械にやらせた方が絶対に良い 製品にするコードってどうせMISRA C辺りの静的解析噛ますし
今時ならvalgrindもテスト項目に入ってるだろうし
Rustなら全部コンパイラがやってくれる!と言われても、
いやCにも外部ツール入れれば同じことできるし……としか思わんのだよな
個人的にはクラスよりトレイトの方がしっくりくるからそれだけでもRustは意味があると思うが >>523
枯れてないコンパイラの癖に合わせる方がよっぽど注意力を削ぐと思う。
コンパイラになんでも機能ぶっこむより524のように構成した方がどのツールが文句言ってるのか
よっぽどわかりやすい。
機械にチェックさせるのはいいがシステムとしてモジュラリティーが高いツールの組み合わせのが
結局使いやすいし、ロバストになる。 どうでもいいけど言語の持つ表現力とかは完全に無視なん? >>526
C++の方がノイズが多いくらいで表現力自体は大差ないわ
もちろん、そのノイズによる可読性や生産性の低下は決して無視できるものではないが >>525
Cだって作成当初よりコンパイラでチェックする範囲広げてるけど
全否定? >>526
CやC++との比較でそこ(表現力)に触れずに
「Rustは安全!C/C++はfree/delete忘れがーアクセス違反がー領域の破壊がー」ばっか言ってる人が多いのが疑問って話な
俺はトレイトに可能性感じてるから期待してるよ
C++のテンプレートとか関数オブジェクトとか書きたくねえし
あとチェッカーとコンパイラ分けるべきか合体させるべきかについては、
どっちにも善し悪しあるからCとRustどっちが優れてるとかはないと思ってる Cじゃ確かに無理かもわからんが、C++のstd::vectorならatメソッドで同じことできるぞ
毎回アクセス範囲が適切か確認するから結局オーバーヘッドになってほぼ使われんがな 基本はIndex::indexを呼んで必要なとき(オーバーヘッドが気になるとき)にunsafeで囲む
C++は全関数がunsafeで意識せずVec::get_uncheckedを使うようなもの
オーバーヘッドの問題でunsafeで囲んだらRustだってツールじゃムリ五十歩百歩って言われるかもしれないけど、五十歩の方がいい MozillaやRust作者の人達が、valgrindやチェックツールの使い方を知らない
アホ揃いだと思ってるの? >>533
MozillaやRust作者の人達の過激な信者が
valgrindやチェックツールの存在を知らないか軽視してるせいで
Rustの宣伝に対して過剰にC/C++をディスってるアホ揃いだと思ってる
もちろんそうじゃないRust推しもいることは承知の上だ
逆に、「そういうツール使えばC/C++だけで十分Rustなんてイラネ」って意見も
ベクトル違うだけで同じくらいアホだと思ってるがな
だからこそトレイトの使い方だとかモジュールの仕組みだとか
外部ライブラリ(crate)の扱い方の方向での他言語との比較が
あんまり見えないことが問題だと思うんだが
そういう意味で話題提供すると、cargoって結構disられてるけど
どの変がクソなのかいまいち分からん
キャッシュサーバ持てないって話ならnpmとかbundleとかgo getも大概では? みんな同じ話題について話してるのか?
好き勝手独り言言ってるようにしかみえない。 そりゃーRust信者とRustアンチしかいねえからな
話が噛み合うわけない Rustだと(unsafeなし、コンパイラのバグなしなら)プログラムの全実行パスでメモリリークや破壊がないことが保証できると思うけど、
C/C++で同等のチェックができるツールってある?
valgrindは単にvalgrindで実行したパスで問題なかったことが分かるだけって理解なんだけど。
もしあるならそれはそれで使ってみたい。 >>539
俺もその認識なんだけどvalgrindナメてたかな
Firefoxのcssのバグはテスト書いて発覚した感じなんだけど その手の静的解析ツールはたいてい商用製品だね。一番手頃なのはVSで使えるSALかな。 顔本のinferがオープンソースで全パス調べてくれるやつだな
企業ならcoverity課金してるだろ inferは知らなかった。ちょっと試してみる。
まぁ商用含めても原理的に検出率100%とはいかないだろうけど、
Rustだって標準ライブラリ内のunsafeバグとかあるからいい勝負なのかな。 全パスチェックしてもRustのコンパイル時のチェックには及ばない
全パスチェック程度で済むものならば、Rustにあんなややこしい概念を持ち込む必要はないんだよ 言語として縛りを強制するってとこに旨みがあるよね
静的チェックを過大評価云々は的を外した無意味な議論 Rcなりunsafeなりあるわけでなんだかね。
rustを意識してプログラムをすることに意味はあるがrustの実装系を使うことに
そこまで意味はない。 俺はweb屋さんだけどサーバ書くならrustが最高とおもってる
これって過激な信者? 信者だアンチだディスったディスってないでrustを語れよ coverityとかの静的解析って誤検出が結構ある
で誤検出かどうかの人力解析も超めんどくさい
かつ1度の解析にめっちゃ時間かかる
これがあるからC/C++でもRust同等とかないわ >>547
web屋さんはもともとC++なんて使ってないし使う人が順調に増えていってる印象
問題はweb屋さん以外にどうアピールするか どうせ一時の流行で終わるんだから被害は少ないほうがいい
Scalaとかも中途半端に業務系が乗っかってきはじめた矢先に梯子外されて死屍累々の惨状だったし >>551
なんか梯子外された事件あったっけ?
Java8の登場でScalaがただの難解なJava8になった話? Javaは今でもクソ言語なのでScalaとは比べるべくもない
単に日本の人月制度とマッチしなかっただけ
Rustもそうなる
学習コストの高い良い言語より学習コストの低い低単価で人を集められる言語 色んな業界があるのに一緒くたにして評価できなくない? >>555
JavaやPHPはともかく、そういう意味でCやC++がコスト低い言語とは思えんが 個人的な経験だけど、Rustのコンパイラを単純に黙らせるようにソース修正していくと物凄く汚くなることが良くある
ので、そもそもの設計を見直すようになったり、かくあるべしって仮設を明確にするクセが身についた気がするよ >>557
低学歴のC/C++職人様はつぶしが利かないからスキルの割に高くないイメージ 資源の共有状態を見直すってのはrustは置いといてもプログラムをに置いてやっぱ本質だなと思う。 ArcとかMutexとかRwRockが気に入ってる
最初めんどくさかったけどよく考えたら当たり前に必要なんだよね
そこを隠蔽しないことでコストのトレードオフをプログラマに意識させるのがよい 練習で他言語のプログラムを移植してみたらコンパイラに
ガンガン怒られて本人が壊れるような使い方しないからと手抜きしていた部分が
洗い出されてなるほどなあと思った rustに限らず他の言語でもgtkぐらいしかないでしょう orbtk?
redoxのguiだけど、windowsでも動いたよ。 >>561
当たり前じゃねえから
PythonとかPerlとかRubyで書かれたプログラムにはないけどちゃんと動く
それともこれらの言語で書かれたものはプログラムじゃないとか言っちゃう系? RwRockが自然に必要ってのは言い過ぎだわな。
必要なところは必要だろうがそれがあまりに多いのは多分設計ミスってる。 ですから必要なところは必要と言ってるだけじゃないですか
当たり前にってのは原理的に必要と言ってるだけだよ >>569
Rustの設計思想理解してないのか
単にアホなのか まぁ自分の書いている範囲内しか見えない人は普通にいるだろう。
どの言語だってライブラリや処理系レベルでは排他制御はあるし、
逆にどこにもなかったら単に間違ってる。 Perlは知らんがRubyやPythonには
GILっていう排他制御が言語処理系に含まれてることを考えると
非常に味がある >>576
他の言語が息できない分野でエラ呼吸してるよ >>575
GILは複数スレッドの競合によってインタプリタがぶっ壊れるのを防ぐために必要な、インタプリタ自身の内部的な排他制御
アプリケーションコードで行う排他制御の代わりにはならないよ
インタプリタがスレッドセーフでない糞実装であるための苦肉の策で、
Rust含め元々スレッドセーフな「まともな処理系」なら全く必要のないもの そういや Perl でマルチスレッドのプログラムは作ったことないなあ。fork してマルチプロセスにするのはよくやるが。 そうか、今時の人はみんなLock-freeアルゴリズム使いこなすんだな
Mutexなんて見たことないんだ OSかそれに近いコア領域とかトランザクション必要なデータベースでも書かん限り
MutexとかLockとかが必要だとは思わんなー
Web系にもてはやされてるらしいけど君らそもそもそれオーバーキルどころか逆に足枷ならん?って思う >>583
そもそもそんなに並行処理をOSやミドルウェア頼りじゃなくて自分で書くが必要な場面て例えばどこ?
と質問に質問で返してみる ■ このスレッドは過去ログ倉庫に格納されています