ビルドエラーが出るのですが、なにか解決策はありますか？
Compiling backtrace-sys v0.1.30
error: failed to run custom build command for `backtrace-sys v0.1.30`
process didn't exit successfully: `C:\Programming\Rust_project\socket_programming\target\debug\build\backtrace-sys-159a954e4a82ac78\build-script-build` (exit code: 1)
--- stdout
cargo:rustc-cfg=rbt
TARGET = Some("x86_64-pc-windows-gnu")
OPT_LEVEL = Some("0")
HOST = Some("x86_64-pc-windows-gnu")
CC_x86_64-pc-windows-gnu = None
CC_x86_64_pc_windows_gnu = None
HOST_CC = None
CC = None
CFLAGS_x86_64-pc-windows-gnu = None
CFLAGS_x86_64_pc_windows_gnu = None
HOST_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
running: "gcc.exe" "-O0" "-ffunction-sections" "-fdata-sections" "-m64" "-I" "src/libbacktrace" "-I"
"C:\\Programming\\Rust_project\\socket_programming\\target\\debug\\build\\backtrace-sys-361946668d7e8f79\\out"
cargo:warning=cc1.exe: sorry, unimplemented: 64-bit mode not compiled in
exit code: 1
--- stderr
error occurred: Command "gcc.exe" "-O0" "-ffunction-sections" "-fdata-sections" "-m64" "-I" "src/libbacktrace" "-I"
"C:\\Programming\\Rust_project\\socket_programming\\target\\debug\\build\\backtrace-sys-361946668d7e8f79\\out" with args "gcc.exe" did not execute successfully (status code exit code: 1).
>cargo:warning=cc1.exe: sorry, unimplemented: 64-bit mode not compiled in
「rust unimplemented: 64-bit mode」で検索すれば？
32bit mingwで64bitのコンパイルしようとした時のエラーの話だからrust付けると出てこないだろうな。
*-pc-windows-gnuはツールチェーン含んでるから余計な環境でビルドせずに含んでるもの使えばいいんだよ。
Rustで
port0.od = 0; // 0b00000000
port0.od.b0 = 1; // 0b00000001
port0.od.b5 = 1; // 0b00100001
port0.od.b0 = 0; // 0b00100000
みたいな実装って出来るんだっけ？
port0.od = 0; // 0b00000000
port0.od.b1(1); // 0b00000010
とか
port0.od = 0; // 0b00000000
port0.od.bitset(6); // 0b01000000
みたいに関数を介せば出来ると思うけど
サンキュ。やっぱ無理か
こういう記法が出来る処理系って少ないですよね。言語レベルで対応しているか=の上書きと括弧無し関数呼び出しが出来るとかじゃないと難しい
どうやって実装しよう
１．読み出し：b0()、書き込み：b0set([0|1])
２．読み出し：bit(n)、書き込み：bitset(n)、bitclear(n)
どちらもスマートじゃないな。Rustだと引数の初期値を取れないから一つの関数で読み書き兼用というのも出来ないし
>>7
機能上はマスクで足りるのですが名前でビットを指定できた方が読みやすいので
>>9
読み出し：bit、書き込み：set_bitと実装されているみたいですね。こんな書き方しかないのかな bitmapで良くない？外部クレートなかったっけ？
マクロ使えば見た目は似せられるかも？
bit! {
od = 0;
od.b0 = 1;
}
みたいにしてASTいじって関数呼び出し形式に変換する感じの。
すみません。誤爆しました。１４は無視してください。
Rustって、なんでRustっていう名前なんですか
>>12
一応no_std予定なので・・・
>>13
スマン。マクロ書いたことないんで理解できないです
>>16
あ、そうか。Index、IndexMutを書けば[]と[]=で読み書きできるようになりそう。やってみよう Cみたいに
port0 = BIT5
port0 = BIT2 | BIT4
val = port0 & BIT4
じゃあかんの？
>>19
enum Bit { On, Off }
let byte = [Bit::Off; 8]
こんなんじゃダメけ？ VSCodeにrustupとrlsとC++のツールチェーンを入れてcargo new hello --bin
をShift+Ctrl+Bでビルドしてデバッグ実行もできるようにしたのですが、
できたファイルのうちのどれとどれをGitにコミットすれば一番幸せになれるの？
(1) .gitignore
(2) Cargo.toml
(3) Cargo.lock
(4) main.rs
(5) main.exe
(6) main.pdb
(7) ./vscode/task.json
>>25
普通はmake不要でcargoのみ。そのサイトはどこかから持ってきたアセンブラをnasmするのにmakeつかってるだけっぽいのでrust関係ない。 Microsoft、安全で高効率のプログラミング言語として「Rust」を高く評価：メモリ破壊
バグを避けるには 2019年07月18日 19時00分 公開
https://www.atmarkit.co.jp/ait/articles/1907/18/news122.html
Microsoft Security Response Center（MSRC）は2019年7月16日（米国時間）、ソフト
ウェアのセキュリティを確保しつつ、効率性も保ちたい場合、利用可能なシステムプロ
グラミング言語として、「Rust」を高く評価した。
MSRCによれば、Microsoftが「CVE（共通脆弱性識別子）」を割り当て、修正してきた同社
ソフトウェアのセキュリティ脆弱（ぜいじゃく）性の大部分は1つの要因から起こっている。
開発者がC／C++コードにうっかりメモリ破壊バグを作り込んでしまったことだ。(中略)
C#とC++のメリットを兼ね備えるのは
C#のような言語が提供するメモリ関連のセキュリティと、C++の効率性を兼ね備えた言語
があれば、開発者にとって理想的だ。MSRCは、両方の要件を満たす最も有望なシステムプロ
グラミング言語として、Mozillaの公式プロジェクトとして進化してきた「Rust」を挙げて
いる。
さらにMSRCは、業界として真のセキュリティ対策を進めるには、脆弱性に対処するための
ツールやガイダンスを提供するよりもむしろ、「開発者にそもそも脆弱性を発生させない
ための取り組みを行わなければならない」との見解を示した。
MSRCは、安全性の低いレガシー言語から、モダンで安全なシステムプログラミング言語
への移行を促進するという観点から、Rustをはじめとする安全なシステムプログラミング
言語の活用に向けて、Microsoftが行ってきた取り組みを今後も紹介していくという。 ああついにMicrosoftまでMozillaのステマの犠牲に…
参照しか返せない状態で計算結果を返すって方法ってあるんだっけ。通常なら値を返すように宣言すればすむ話ですが
Indexは参照しか返せないようです。たとえば*addr >> idx & 1の結果を返したいです
>>21
それだとセットとクリアでAND or ORと値の両方を変更せねばならずどちらかを忘れてバグを産む可能性があります
>>22
ググるとそのような例が出てきますね。Rust的に正論だと思いますが元となるハードウェアのマニュアルでは
0：○○になる
1：××になる
みたいな表記が主流に見えます。ここから外れた表現の強制は言語の安全性とは別なところでリスクを抱えるように思います >>29
ほんなら0と1でプログラム書けやタコスケ
プログラミング言語ってのはハードウェアを抽象化するためにあるんだぞ >>29
and or orと値の両方を変更せねばならずってどういうこと？ >>31
port0.od = 0b00000000 // 右端を0ビット目とする
port0.od |= 0b00000100 // 2ビット目を1に → 0b00000100
port0.od |= 0b00100000 // 5ビット目を1に → 0b00100100
port0.od &= 0b11111011 // 2ビット目を0に → 0b00100000
ビット列は抽象化できるけどANDとORは一連の処理をラップできない限り手動で変更する必要があります
Cやアセンブラで低レベルの処理をする場合は多用される書き方だと思いますが結構危なっかしいと思います 義務教育受けてたらwhy rustの訳だろうなってすぐ分かるよなたとえ翻訳かけてたとしても
Index、IndexMutが何でこんな仕様なのかと思ったらC++の[]に合わせたのか
C++ぽく使えるがそれ以外の使い方は想定されていないと
結局普通の関数で妥協するしかないのかな。抽象度はCに毛が生えた程度、C++未満？か
どのみち組み込み用に拡張された処理系相当には出来そうにないっぽい
>>37
Rustは構文的な自由度あんまりないからね。Scalaが自由度ありすぎて混乱してた反省を踏まえてるのかな、って思ってる。どうしてもやりたいならマクロがあるし、妥当な落とし所では。 groovyと同じast変換するマクロもあるしcompiler pluginもあるし拡張は簡単。
rayonでzipイテレータを並列処理できますか？
rust未経験者がwebプログラミングをrustで始めるのってどう思う？
俺の背景としてはocamlを1年ぐらいやってて「Real World OCaml」みたいな定番書を読んで簡単なコンパイラとかVMを作ったっていうレベル
rustでやるモチベーションとしては
・OCaml誰もやってなくて未来が見えない
・最低でもバリアントとパターンマッチが欲しい
・ネイティブが良いからscala/F#は嫌だ
こういう理由
web自体が初心者だからrailsとかのチュートリアルぐらいは先にやっておくつもり
どうも何もWebアプリは言語の選定は大した問題じゃなくて、Webアプリの基礎がわかってるかどうかだぞ
セッション管理、Rest、クライアントスクリプト、見た目とロジックの分離等々
そうは言っても情報量の多さとかで挫折しにくい言語ってのはあるでしょ
Rustは明らかにきついほうだろうけど...
>ocamlを1年ぐらいやってて
>コンパイラとかVMを作った
能力的にはRustでWebするのも余裕なんじゃね；
もっとも、SQLインジェクションみたいな文字列解釈やセッション絡みの脆弱性を
思わず作りこんでしまうことはRustでも避けられないから>>42のは真実だと思うが 最低でもヴァリアントとレコードとパターンマッチがあって全体的に式指向な言語が良い
ocamlがマルチスレッドに対応しててもっと流行ってれば...
scala/f#がネイティブであれば...
haskellが正格評価でもっとパフォーマンスが良ければ...
皆さんc/c++の置き換えとしてrustやってるの？
自分は関数型言語由来の機能が多くてネイティブで動く言語が欲しい
そういう理由でrustに手を出す人って少ないのかな
rust製のcliツールとかめっちゃ多いし、低レイヤのためだけにrustやってる人のほうが少ないんじゃないかな
難しいからなんなんだよってかんじ
勉強すればそのうち使えるようになるんだからどうでもいいことじゃん
俺はPHPの置き換えで使ってるけど
rust, c++より少しはマシくらいの言語だわな。
実装系含めたらまだc++のがマシになるが。
C++がましってどのへん？学習コストはどうしようもないとして、学習してしまった今となってはC++に戻る気とか一切しないんだけど。
>>46
pony。cliツールっていうかcoreutilsとbusyboxの代替実装とかならあるけど。 >>52
cとかより低いレイヤーの言語をバインドしようとした時、より素直。 お前らが本当に必要としてるのはRustじゃなくて
ziglangなのでは？
流行ってる言語じゃないとしんどいってocamlで学んだ
rustがリアルタイムで使われてるの聞いたこと無いんだけど
どうせgcあるから駄目とか言ってるやつはメモリの開放タイミングが
予測不能でも致命的にならない事しかしてないんだろ？
Option<char>とStringを結合させたいんですけど、どうすればいいんですか？
>>63
Option<char>はList<char>の特殊な例と考えて良い
これ、関数型言語の常識 let x: String = "Hello World!".toString();
s += Some(x)?;
いや知らんけど
リアルタイムでってなに？
目の前でrust書いてくれるってこと？
>>63
>>64
unwrapしてformat!で結合できましたm(_ _)m GCは結局メモリ以外のリソースはまともに管理できなくて、自分でデストラクタ呼ぶはめになるのがつらい
rustでc++のtemplate<class T, size_t N>struct array{T elm[N];}みたいな事可能なの？
抜け道はあるかも知れんがジェネリクスでは型しか取れない
まだ実装終わってないけどnightlyなら一応使えるっぽいよ
#![feature(const_generics)]
高機能なマクロもクロージャも使えるのだから値パラメータなジェネリクスは冗長
なｷﾓｽ
C++から機能取り入れるとクソ言語化するからやめてほしい
んまー値パラメータなクラステンプレートを実現しようとしたらマクロでは済まないのか
そうか
>>70
GCは全く関係ないがな。
try使うとかwith使うとかgoならdefer使うとかそういう話だろ。
オーバーヘッドガー言い出すやつって
ただまともにメトリックとるスキルがないってだけだろ。 >>78
RustやC++のスマートポインタならスコープ抜けたときのデストラクタできれいにリソース解放できるけどGCだとできないね、って話なんだが。
それを部分的に解決する方法としてC#のusingとかがあるけど、関数を跨ぐような寿命の長いリソースには使えない。
try-finallyやGoのdeferなんて、絶対書き忘れてリソースリークするパターンだろ。 現状静的配列が使い物にならないから const generics は必要だと思う
ゼロコスト抽象化を標榜してる以上は行列計算をVecでやれとは言えんだろ
>try-finallyやGoのdeferなんて、絶対書き忘れてリソースリークするパターンだろ。
一理あるが、資源を正しく管理するデストラクタ書くのそんなに楽じゃねーぞ。
舐めすぎだわ。
>>86
他言語でもさんざん書いたからデストラクタの難しさは知ってるつもりだけど、
ライブラリ作成者が注意深く書いたデストラクタをみんなで使うのと、各自finallyやdeferを正しく実装しましょう、なら前者がましでは？ ちょっデストラクタで開放処理を書けない資源とかもはやプロセスをkillするしか、
Vecはただのfat pointerのnewtype patternだからアラインが合えば自動ベクトル化できるんじゃないの？
>>80
gcあるならref objectあるだろ。今どき。 ていうかデストラクタ自体は問答無用に資源を開放するように作ればよいのであって
そうならないのは上位の設計がおかしい
例外のスローが許されないなどただでさえ制約が厳しいところに小難しいロジックを押し込んでどうするんじゃ…
資源の開放に一定の手順が必要ならそれはデストラクタの中ではなくデストラクタが呼ばれる前にすませるべきだし、
必要な手順が抜かされたみたいなバグのケースの救済までデストラクタの任に負わせるのはおかしい
資源の開放自体にエラーの危険性があるならインスタンスの製造元（ファクトリ）にエラー通知してから死ぬ等の
パターンに従うべき
>>89
ref objectがなんなのかよく分からないが、GCにリソース解放させる場合の問題はタイミングを制御できないことだと思ってる。
スコープを抜けて回収可能になったからといってすぐ回収されるわけではないから次の確保が早すぎると死ぬ。
まぁたいていの場合問題ないってのはあるけど、本質的にはGCに合ってないと思う。 すぐに開放されないだけの問題なら開放されるまで待てば良いではありませんか、
さすがに今日日のGCは開放可能な資源の発生と資源の獲得要求がmeetした場合に何もしないほど馬鹿ではないと思われ
（meetのトリガタイミングがなんと2回もある
致命的に問題なのはGCには資源に空きがあるように見えるが、GCが知りようがない上位のロジックで循環依存が生じる場合
ファイルをN個まで同時に複数開けるシステムで、a、bの2個しかファイルが開かれていないんだけど
スレッドAがファイルaを出力し終えた後ファイルbのクローズを待っており、スレッドBはファイルaのクローズを待ってからbを出力せんとしている場合等、
>>87
俺は後者のがマシだと思うけどね。
資源解放のパターンをオブジェクトで判断するとか自然な設計だと思えんよ。
解放ルーチンなりをシチュエーションごとに用意する方が明らかに自然だわ。 >>92
実際問題例えばC#のGCはそれくらい馬鹿ではある。
というかファイルハンドルの中身と次のリソース要求を見て、適切に回収してくれるGCってあるの？
メモリ解放のタイミングでたまたまその他のリソースも解放されてるだけでは？ 効率的なTreeの書き方どこかに書いてあったはずなんだけど忘れてしまった
どこにかいてあるかわかるひといますか？
enumをつかっていたような気がするんですが・・・
効率的なTreeってなに？
代数的データ型なら普通はsum type(rustのenum)で書くけど。
???@???
Rustとの戦いにつかれたのでDを触った次第
↑RustでコンパイラとかVM作ってる人のツイート
Rustってそんなに難しい？
配列で親ノードIDや子ノードのID持たせるとかじゃなかったか。
所有権引っかからんようにするとそんな感じになる。
他言語でもGUIのグラフとかは結局そうなるんだけどな。
今日知って驚愕したのだがJavaは構造体の参照を返すということができず、
どうしても参照返ししたいときは構造体のメンバを書き換えて返すという歪な手段を使う
↓こんなやつ
class CWDPath {
String mPath = "";
}
boolean getCWD(CWDPath result) {
result.mPath = "SomeDir";
return true; // 性交ステータス
}
これはresultの寿命がmPathに代入するデータの寿命を下回らないケースでしかRustでは書けないﾊｽﾞ
つまりJavaはRustのアンチパターンで大々的に書くことを余儀なくされる危険な言語
Javaすら理解できてないのにRustを使おうとするとは勇ましい
javaに構造体はないってことくらい突っ込んでやれ。
value typeは当分先だ。
いや正しいていうかこの話にvalue typeは関係無い（返そうとしているStringは参照型
間違っているというならreturn mPath以外の方法でgetCWD()からStringを返してみると良い
んまー不用意に構造体と書いてしまったのは陳謝するのですよ
組み込みの値型以外は全て参照型で管理されてる事が理解できてないって事？
Javaにおける参照はオブジェクトへのポインタのことで、RustやC++の参照とは違う概念なのだよ
だから参照を返すという言葉の意味も Java と Rust では違う
何言いたいのかさっぱりわからん
コンパイルエラーになるがやりたいことを書いてくれ
皮肉や冗句を言うにも一定のセンスと知能が必要と言う証左
>>115
C#の例（これは動く
void Main() { string str = new string(); bool bResult = getCWD(ref str); Console.WriteLn(str); // "some_dir"が表示される }
bool getCWD(ref string str) { str = "some_dir"; return true; // 性交ステータスとしてのtrue }
Javaで同じ事をしようとすると>>105になって、Stringを返すためだけのためにCWDPathみたいなクラスを作らねばならない
>>117
藻前は顔だけは賢そうだな 脳がC言語で止まってると色々気苦労が多くて大変だな
で、Javaでは何で>>105みたいな変なことになるかというと、参照の参照をとることができないため
ここで参照とは何かというと>>113の前半部で良い
参照自体はレジスタに代入したりスタックに1語で積める値型の一種とみなせる
C#ではrefキーワードにより、参照の参照をgetCWD()に渡すことができる
Javaは参照しかgetCWD()に渡せない。よって、CWDPathみたいなクラスの参照を渡してやって、
そのクラスがメンバとして所有する参照を上書きするという手段で返さざるおえない >>119
参照型を引数として関数に渡すしくみはCで完成しているのだから>>119の言い様では批判になんね
Cではポインタやんけというのは本質ではない
参照自体はレジスタに代入したりスタックに1語で積める値型の一種とみなせる(>>120)
なのであって機械語レベルでみたらオブジェクトを指すポインタに他ならない
で、Java、C#、C++、Go、Rustいずれも参照型の関数渡しは参照をスタックに積んで渡すモデルであることは変わりない 調べてなお問題があると言うなら>>122の理解にこそ問題がある >>118
最初説明したこととまるで違うじゃないか。用語は正しく使えよ。
結論は、戻り値で成功不成功を返そうとしたお前が全部悪い。>>119が正しい ・カレントディレクトリを取得する
・取得の失敗を検出したい
というのが要求だとして
Javaでそんな変なことせずに
もっとまともな書き方あるから批判する前に
勉強しろや
>>118
Javaの場合は普通 >>105 みたいなことをせずに、getCWD() の返り値を CWDPath にして、失敗の場合には null を返す
CWDPathみたいなものを二つ返したいなら Pair を使うし、たくさん返したい場合に初めてクラスを作る
Java の進化系である Kotlin はこの辺を確実簡易に行うために nullable とか data class とかがある optional型とかnullable型みたいなヤツは色んな言語であるわな
CWDてなんなんそもそもｗ
pwdコマンドにあるようにワーキングディレクトリってことでいいの？
それが失敗する時があるってのが想像できない
想像力が足りない
Unix だと実行中のプロセスのカレントディレクトリを消すことができるので、
そこでそのプロセスが getcwd すると No such file or directory のエラーになる
Cの知識しか無いけどJava語っちゃう痛い人が、参照渡しだの値渡しだのを問題にしたがる
Cを使えるからってプログラミングの技術全てが語れるわけじゃないのにね
go9nzBX4が最初から間違ってるのは置いといてFTUf1Nuqは結局なんだったの？
>>124
一連のレスの中で漏れが一度も「参照渡し」という用語を使っていない件について：
参照型の参照渡しする、という状況は比較的新しい話で、
Javaはあえてかなんだか知らんが古来からある値型の参照渡しに類似の動作に対応していない
つまり呼び出し先で引数として渡された参照型自体を交換したり出力したりできない
JavaScriptやC#は対応している（呼び出し先で参照型自体を交換できいる。C#の例は>>118。refよりoutキーワードを使ったほうが良かったかもしれん…）
>>126
それで十分使いやすいと思われたのならそれで良いが、後発言語が参照型の参照渡しに対応しているという事実、
>>133
C++脳に汚染されていたのでclassとstructの区別がなかったんじゃ すまんまつがえたorz
JavaScriptの参照の渡し方はJavaと同じやった、
なんか今ｸﾞｸﾞると参照渡しの説明に真っ先にJavaScriptが出てくるが
世の中では参照型については参照型が保持するデータを呼び出し先が書き換えられることをもって参照渡しと言っているのかそうか、
しかしそれでは渡された参照型を呼び出し先が交換したり出力したりできず、
そうしたい場合に>>105や>>126（Pairの使用、ただし2個まで）みたいな技巧を要する 書き込むスレをいつまで経っても間違ったまま
そのことにすら無自覚で気付けないやつは
何してもだめ
Cのときからある混乱だよな
単にポインタ渡してるだけなのに
ポインタを値渡してるだけなのに
「ポインタ渡し」だとか「参照渡し」だとか言っちゃう
そーいうブログや個人サイトが今もいっぱいある
そもそもこんな状況だから
これについての議論はスタート地点からもうやる気ほぼ出ない
>ポインタを値渡してるだけ
フォートランスレにでもしてほしいのけ？
>>141
> 単にポインタ渡してるだけなのに
> ポインタを値渡してるだけなのに
> 「ポインタ渡し」だとか「参照渡し」だとか言っちゃう
お前がまず混乱してね？ ×単にポインタ渡してるだけなのに
○単にポインタを渡してるだけなのに
失礼、こう書いたほうが良かったねこの場合
×ポインタを値渡してるだけなのに
○ポインタを値渡ししてるだけなのに
こっちは完全なるタイプミス
佐渡さんと書いて、サドさんと読む人と、サワタリさんと読む人がいるから、紛らわしい！
結局、JITがあるからRustよりJavaの方が速いんじゃないんの？
RustとかC/C++は機械語までコンパイルするから速いんじゃなくて無駄なことをしないから速いのでJITとかそういう問題ではない
JITコンパイルで性的コンパイル結果より速くなるというのは都市伝説
JITのしくみを考えたらﾜｶﾙ
理論上は分岐の実行時統計をとって最適化することによりローカルループがありえないぐらい爆速になって
JITコンパイラ大勝利！と言うことも考えられないではないが統計をとるオーバーヘッドが生じるし
そこまでやっているJITコンパイラは商用のにはないはず
Rust学び始めたけど難しすぎる...
慣れるのにどれくらいかかるだろうか
ちなc/c++経験ほとんどなし
関数型言語は少しだけ分かるっていう程度
手を出すのは無謀？
なにを作ろうとしてるのかによるよ
わたしは二ヶ月くらいかかったかな
async/await、勉強するのに良いものある？
まだstableじゃないからなんとも
tokio::netとかはasync/awaitでサンプル出してたりするけどどうかな
>>159
substructural type systemとregionの前提知識がないならコンパイラに怒られるだけ時間の無駄。
先に必要な知識つけてから。
>>161
stable待つよろし。 cくらいはやっとらんとなんでこんな事してるんだって思うだけだろ。
メモリイメージがないならrustなんか使う意味がない。
そんなに大仰なことかなあ？
書いてればそのうち分かるっしょ
>>159
C/C++やってからでも遅くない
っていうかC/C++を先にやった方が近道かも知れん 寧ろ関数型プログラミングに慣れ親しんだ人ならimmutableなオブジェクトだけでプログラミングしてしまい、
Rustが何も言わなかったりして…
>>160
2ヶ月ですかー
用途としてはとりあえず簡単なCLIツールを考えています
>>168
c++はともかくcはちゃんとやっておいたほうがいいですかね
「低レイヤを知りたい人のためのCコンパイラ作成入門」を読んだのでメモリイメージ的なことは最低限は分かるかも
rubyとかpythonとかからrust始めた人もいるみたいだし気合入れて頑張ってみますか なんでこんなめんどくさいことやってんだ
というのを理解するにはC/C++の知識があると早い
苦しめられたほうがラクなんよね
一見苦しい縛りの結果、整理された構造という一粒の宝石を残してくれる
-use lib as minigrep
+use lib::Config;
ごめんなんか勘違いしてた
vscodeで普通に通るよ
トレイト境界をトレイト拘束に置換する拡張機能を書いた
RustのArcとかBoxとか複数組み合わせてちゃんと動くってイメージが湧かないんだけどそんなもん？
バグを見たことがあるからちゃんと動くというイメージが沸かないのか？
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8c44bed658726ada0deff031799664b7
1. std::env::current_exe()で実行ファイルのフルパスを得る
2. file_name()でファイル名だけにする
3. to_str()で&strにする
4. 途中でErrやNoneが返ってきた場合はデフォルトの値"foo"を使う
ということをやりたいのですが、エラーでビルドできません。
どのように書けばいいでしょうか？ std::env::current_exe() は PathBuf の"値"を返す
PathBuf::file_name() は PathBuf の中身の部分的な参照を返す
PathBuf::file_name() で生成される &OsStr を参照から値に変換するか、
std::env::current_exe() で生成されるPathBufを変数に束縛して所有権取らせてから、改めて参照を取得するかしないとダメ
>>188
ありがとうございます、所有権を意識してto_ownedを使ったらいけました。 合理的ね。。
「戦うプログラマー」読む限りはそうは思えんが。
都合のいいとこだけ切り取ってるな。
むしろ無理やり言語使わせるとかもろSIerのやり口だろ。ばかすぎる。
闘うプログラマーと言えば当時からC++は魔境過ぎてヤベェみたいな記載があって笑った記憶ある。
無理矢理使わせてるということは今後出てくるMSプロダクトは全部Rust製になるのか？
>>193
C++で作るようなものを全部Rustにする
ってなったらすごいことになるな JavaScript → TypeScript(型チェック) とか C++ → Rust(借用チェック) みたいな
用途・特性が似通った言語でより安全な方を使わせるってのは、単なるリスクマネジメントであって
SIerのナンデモJava事案とは違うと思う
ポストC/C++の座にRustを据えるかどうかはともかくC/C+お払い箱は確定事項じゃね
つーかMSRCの記事の何処にも無理矢理使わせているなんて書いていないぞ？
Rust学び始めたけど噂通りむずい...
やりたいのはcli/tuiとかwebなので習得が無理そうだったら大人しくGoを使うことにする...(´・ω・｀)
>>199
CでOS書いた事あんの？
C意外でOS書いたことあんの？
それとも想像だけ？ >>200
OS書かなくても自家製メモリ管理作ってみれば想像できるだろ。 ちゃんとしたmallocを作ること自体が難しいのであってCかRustかは難しさへは影響しない
GCはクソ！だからRust最高！
とイキがってた奴がボローチェッカにボコボコにされてGCの良さを体感するまでが通過儀礼
どっかにドリルないですかね。>187みたいな問題がサラッと解けるようになりたい
GCがクソだと思ったからRust使うという意識なかったな
