Rust part16
レス数が1000を超えています。これ以上書き込みはできません。
☆WebAssembly(WASM) https://webassembly.org/ https://ja.m.wikipedia.org/wiki/WebAssembly
・Wasmer - The Universal WebAssembly Runtime https://wasmer.io/
-> WASI(WebAssembly System Interface)とEmscriptenに準拠したWASMを実行できるランタイム
・WAPM - WebAssembly Package Manager https://wapm.io/
-> WebAssembly製ツール/ライブラリのパッケージマネージャー
☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
https://github.com/rustwasm/wasm-pack
-> WebAssemblyのrustcコンパイルサポート
・Yew - Rust / Wasm framework for building client web apps https://yew.rs/ja/
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク
☆最近のWebAssemblyのニュース
・Publickey - Enterprise IT × Cloud Computing × Web Technology / Blog より https://www.publickey1.jp/programming-lang/webassembly/
・WebAssembly活用プロジェクト https://madewithwebassembly.com/
・WebAssemblyが気になるので調べてみた - Qiita https://qiita.com/t_katsumura/items/ff379aaaba6931aad1c4
・WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史 https://zenn.dev/koduki/articles/c07db4179bb7b86086a1
・Typescriptの次はRustかもしれない https://zenn.dev/akfm/articles/81713d4c1275ac64a75c
・WebAssemblyはJVMやeBPFのリバイバルではない WasmがWeb以外でもアツい理由 - ログミーTech https://logmi.jp/tech/articles/324956
・Rust GUI の決定版! Tauri を使ってクロスプラットフォームなデスクトップアプリを作ろう https://zenn.dev/kumassy/books/6e518fe09a86b2
類似スレ
【wasm】ブラウザでC++。Emscriptenを語ろう https://mevius.5ch.net/test/read.cgi/tech/1547549448/ 前スレにあったrustupのnamingの話だけど
もともとはサブコマンドのないシェルスクリプトでrustをupdateするからrustup
元の意味からするとrustup updateは重複表現なんだけど
rustupを動詞として捉えずツール名の名詞として捉えればrustup updateは違和感ない rustupにサブコマンドがない時代なんてあったっけ?
rustupの前身のmultirustの頃からupdateサブコマンドはあったような updateのupじゃなくてsetupのupじゃないの?
意味的に >>6
コード的には主にmultirust.sh -> multirust.rs -> rustup.rsなんだけど
名前はrustup.shから引き継がれてる
rustup.shはサブコマンドがなかった
rustup.rsは最初からサブコマンドがあったけどrustupと叩くと今のrustup update相当の処理(update_all_channels)をしてた >>987
Stringを自己trimするtrim_in_place()を対称的に短く書くなら
fn trim_in_place(s: &mut String, mut f: impl FnMut(char) -> bool) {
if let Some(end) = s.rfind(|c| !f(c)) {
let end = s.ceil_char_boundary(end + 1);
s.truncate(end);
}
if let Some(start) = s.find(|c| !f(c)) {
s.drain(..start);
}
}
たとえわずかでも先にendを処理
fは char::is_whitespace など
ただし目的外使用なので長くなるけど置き換え
s.drain(..start);
↓
s.replace_range(..start, "");
こちらはunstableなので長くなるけど置き換え
let end = s.ceil_char_boundary(end + 1);
↓
let end = ((end + 1)..).filter(|&i| s.is_char_boundary(i)).next().unwrap();
ここでendはrfind()で発見済なのでend + 1でunwrap()可能 drainとかsinkとかRustはわかりやすい絶妙なネーミングが多いな WebAssembly に一番適した言語と聞いて来ました
お世話になります どの道だって希望なんてないよ。
比較的マシな道を探すだけ >>14
やめとけ
Linuxの話題は
あわしろを召喚しちまうぞ Rust is coming to Linux, says Torvalds
https://cloud7.news/linux/rust-is-coming-to-linux-says-torvalds/
Linus Torvalds also announced some changes he plans to implement into Linux soon.
Most significantly, the open-source programming language, Rust might be included in the next release.
Torvalds stated that Rust will be introduced in a limited way.
Torvalds reminded the attempt to introduce the C++ programming language 25 years ago, which didn’t go as expected.
Compared to C, Rust is better at utilizing and protecting resources. >>19
当面は新規開発のドライバぐらいにしか使わないって話だっけ? 既に安定して動いているカーネル本体からスタートするのは非効率たから
新たに増えていくデバドラなどからRust導入
そしてRust>C>C++と評価されたことも大きい ドライバだとunsafe祭りになると思うけど、それでもRust活かせるのかな Rustは標準ライブラリからしてunsafeだらけ
Rustのメリットはunsafe部分を局所的に閉じ込めることができること (他言語は全てがunsafe状態)
そして局所的に閉じ込めた部分の健全性を人間が確保すればプログラム全体の健全性がコンパイラにより保証されること C だとどこが「安全ではない」のかわからん。
unsafe がはっきりと切り離せる分だけ多少はマシ。 >>19
やめとけ
Linuxの話題は
あわしろを召喚しちまうぞ Cたけでなくほとんとのプログラミング言語がデータ競合を見過ごす、あるいは、対応しても実行時にようやく気付いてエラー
Rustのようにコンパイル時エラーとしてくれるのはレア 結局allocを用意して、Resultを返すような別方言のRustを作っただけじゃん。こんなんでええのかよ、糞言語 mallocに失敗してパニックするかどうかは最終的にどうやって切り替える仕様になるわけ?
Cargo.tomlに書くとか? >>32
全体が一気に切り替わるようなのは多分想定されてない
Resultを返すAPIが追加される感じ
例えばtry_reserveなんかはnightlyでは実装済み 話としては二段階あるんだよね
一つは昔からのcore::つまりいわゆるno std::環境
つまりヒープは標準ライブラリとして提供しない
BoxやVecやStringなどのヒープ利用以外はイテレータ含めて全て使える
ヒープは自分で管理するかそういうクレイトを使う
もう一つがstd::からのalloc::の分離
BoxやVecやStringは現在ここにある
Box::try_new()やVec::try_reserve()やString::try_reserve()を使ってアロケーション時のエラーを得ることも可能
この理解でよい? >>33
try_reserveは1.57でstabilizeされてる
>>34
core::もalloc::もno_std用
一部コレクションのtry系メソッド以外はどういう形にするか明確な方針は決まってないんじゃないかな
Allocatorトレイトをstabilizeしていく方向は決まってるだろうけど
それを使った上位のAPIがどういう風になるかはわからない >>35
no_std用と言うのは言い過ぎかも
stdにてcoreやallocからuseしているため >>31みたいなレスしちゃった時点で負けなんだが本人が歳だけ食ってメンタル10代のこどおじだから面倒臭いんだよな
>>29
何と戦ってるの?
こんなのよくある問い詰められて二の句が告げなくて『なにが?』とか『なんのこと?』ってはぐらかしてる馬鹿なおっさんそのものなんだが本人気付いてないんだろうなw いずれにせよ
ベアメタルなどの組み込みやOS開発向けがほとんどの用途
それ以外の影響なし普通の人々にとっては今まで通り 質問失礼します。
初心者なので当たり前の事質問してたらすみません。
風化対策でTCを置くのは理解してTCを拠点内においてそのすぐ1マス開けて横にもう一個建築物を建てたのですが
そっちだけ風化してしまって崩れてました。これは何が原因なのでしょうか。 Rustってそういうゲームだったんだな
微妙に興味わいた なるほど…どおりで皆が何いってるかがまったく理解できなかったわけですね。
自分が初心者だからだと思ってました。凄い恥ずかしいです。リンクまでありがとうございます! redditでもゲームの方のrustの質問が来るのは珍しくない模様 Twitterで
ゲームのRustと紛らわしいからググラビリティがどうこう、いうツイートがかなりあるけど
それらのツイートがなければかなり検索楽になるから止めてほしい redditは確かあまりにゲームの書き込み多いからスクリプトでそれっぽいキーワード弾いてるんじゃなかったっけ?
今でもときどき書かれてはいるけど Rustは、JS上がりの人や、女性に人気が有る印象。 >>53
Web系は時期にWebAssemblyが超使われるようになるだろう。
そうなるとWeb系の人はRustできないとWeb系の仕事ができないとなるから
嫌でも覚えるしかないだろうな。
そんな状況になるとRustはWebAssemblyのためのものって感じなるだろう ないないウェブはどんどん移り変わるツールチェインのトレンド追い続けるだけだからwasmやrustが大人気になってメインになることは100%ない かと言って組み込みも今動いているCコードをわざわざ書き換えることはないと思うからかなり先かな そのまま新しい言語が来てRustは忘れ去られるのであった(終) そりゃMSですらRustに可能性を感じてWindowsのコアコンポーネントをRustで書き換えたりしてるけどだからと言ってC++がお役御免になるなんて考えちゃう奴はどうかしてるというかにわかの馬鹿かポジショントークのどちらかだよ まぁこの20〜25年ずっとウェブはJS、デスクトップ・モバイルはJAVAだから何も変わってないんだよ現実はそんなものさ どこでも同じシンプルな結論が出ている
・既存のものを書き換えるのは無意味
・新たに作るものはRust 一択 USの状況見るとRustが広く使われるようになるのはもう疑う余地ないと思ってるけど
ここまで世の中の現実を知らない人がRustを推してるのを見ると悲しくなる C は使われる範囲が広すぎた。
JavaScript は使われる範囲が広すぎた。
必ずしもベストではない場面でも使われ過ぎた。
そういった「過剰に使われている状況」が改善されていくってだけだろう。
現状がベストならあえて変更する必要はない。 5chに限らずネットだと言語だなんだドヤ顔で蘊蓄垂れてイキリ散らかしてる奴ばかりだがGoogleに腐るほど日本人、まともなアプリの開発できないとネタにされるくらいソフトウェア後進国のIT土人国家なのオチが綺麗過ぎて爆笑してしまう
このスレでも結局オチはエロゲっていうクソみたいなセンスのキチガイしかいないからなお前らがRust推すほどこりゃダメだって思うわ C/C++よりコンパクトに機能が高く書きやすいからRustを使っている
他の言語は遅くて論外 JSをサーバーサイドに使うのはどうなんかね?
速さは性能やらCDNでごまかせるけど、RUSTやC++とかで出来るならそっちのほうが良さそうな気がする
まあPHP使ってる雑魚だから現状関係ないけど 用途や状況に合わせて言語は使い分ければいい
ひとくちにWebと言っても用途も状況も様々 RustRust言うけどこのスレの人間たちもRustでは一日1000行もコード書いてないだろ >>66
ウェブの表層のほとんどは「ビジネスロジックの記述」をやりたい。
Rust や C++ は良くも悪くも機械に対する指示としての側面が大きい。
ビジネスと機械の間を埋めるのがエンジニアの役割ではあるんだが、
ビジネス寄りのエンジニアとガチ技術寄りのエンジニアで棲み分けが有る。
もちろん何だって速いに越したことは無いが、
ソフトウェアをガチガチにチューニングしたって限界があるからなぁ。
頑張ってソフトウェアをチューニングしてもせいぜい二倍とか三倍とか程度にしか伸びん。
ビジネスが拡大すれば再現なく高い性能が要る (可能性が有る) わけで、
必要なときに機械の数を倍にすれば倍の性能になるデザインのほうが重要なんだよ。 俺は楽だからwebも含めて大抵はrustで書いてるな こちらはまずはバックエンドとスクレーパー方面だけRust化した
フロントエンドはこれから お前らは日本人あるあるで手段と目的を履き違えてる奴ばかりなんだよ
御宅を並べるのは中国にすら20年遅れてしまったソフトウェア分野で結果出してからやれお前らみたいなの逆に迷惑
ウェブつながりのつい最近の話でNode-Sass(LibSass)が非推奨になりDart-Sassになった理由は色々言われているが要はC++でsassの実装は極めて難しくLibSassをメンテする・できるボランティアがいなくなったからなわけで
じゃあお前らご自慢のRustでLibSass書き直せよ?お前らなら余裕だろ?結果出してくれよ?
お前らみたいにネットのコメントだけでイキってる奴らって最高にダサい tauriってrustとjsは同時にデバッグできるのん? ドキュメント読む限りでは
Rustは他のRustプログラムと同様にgdb/lldb
jsはWebViewのデバッガを利用することになるようだが >>73
公式ドキュメントの方法じゃないけどVSCodeのrust-analyzer使えばlaunch.jsonやtasks.json書かなくても簡単にRustのデバッグできるよ
UIは実行後のウィンドウでCtrl+Shift+iでWebView Consoleが開くからconsole.logはこっちのコンソールで確認できる
ただUIのjsのブレークがうまくいかないからこっちは俺が教えてほしい 出来ても結局自分でライブラリ類は書かなきゃ行けないんでしょ?
jsの大量のライブラリが使えるならいいんだけど >>72
なぜ失敗altJS言語なんかに頼ってるんだ?
当然Rust版sassもある >>68
>Rustでは一日1000行もコード書いてないだろ
日本のITの主力のドカタ向けのRustの仕事はまだほとんどないだろうからな。
だから、いまRustしている奴の多くは個人の趣味でRustしている感じだろうし。
俺的にはRustを使った社内システムの開発とかやっているレベルで激すごいなって思う
Rustがメジャーになれば受注案件でRustも使うってなるんだろうが 現実を直視できないアホばっか
Rustの案件なんてあるわけないだろ都内ですらC++のドライバ開発で人材集めるの相当苦労するのにRustでプロダクションクオリティで書けるPGがいたとして名抜きの奴隷なんてやるわけない
だからそんなプロジェクトはないし案件が発注されることもない なるほどRustを叩いているのは受注土方だったんだな
こちらは自社開発だから便利で安全で高速なRustを普通に採用できている ローカルなツールを自分一人でシコシコ作ってるってパターンだろw 現実にRust利用がどんどん広がっていってる現状に嫉妬してるおまえらはRustアンチスレの方へ行けよ > 現実にRust利用がどんどん広がっていってる
>>83の脳内現実w 自社開発製品
・FizzBuzzイテレータ
・カウントアップイテレータ
・フィボナッチイテレータ
当社製品はすべてジェネリック対応
型の最大値を超えると自動的にイテレート終了
Rust製で安心安全高速!
5ちゃんねるユーザー大絶賛!!
「所有権複製論」の複オジ先生自ら開発!!! このRustアンチ
いつも不利になると作り出した仮想敵叩きへと逃げ込むな WebAssembly で圧倒的需要を勝ち取ったRust の勝利 >>85
5ちゃんねるユーザーからゴミ扱い!!の間違いでは? 自演自画自賛してたから
大絶賛でも間違いではない
いや、間違いか >>88
Wasmで、DOM直書きできるのは、今のところRustしかないことが
いまのWasmを書く際のRust人気になってるようだ。
しかし、今後、ライブラリの中にDOM操作を隠蔽できてしまえば、
ライブラリを使う限り自分でDOM操作はしなくて良くなるからDOM直書きは
不要になる。 >>93
君は日本語を直書きできるようにしたほうがいいんじゃないか? >>95
現段階でWasmを使おうとしている人の大部分は、
「WebプログラミングはHTMLとDOM操作で行うもの」
という固定観念があるので、それが直接的に出来るRustを使おうとしていると
言うことだ。
しかし、DOM操作を関数の中に閉じ込めてしまえば、DOM操作と言う概念を
一切合財忘れてしまって、Windowsプログラミングのような手法でWeb
プログラミングできるようになる。 >>95
現段階でWasmを使おうとしている人の大部分は、
「WebプログラミングはHTMLとDOM操作で行うもの」
という固定観念があるので、それが直接的に出来るRustを使おうとしていると
言うことだ。
しかし、DOM操作を関数の中に閉じ込めてしまえば、DOM操作と言う概念を
一切合財忘れてしまって、Windowsプログラミングのような手法でWeb
プログラミングできるようになる。 >>97
いったんそうなってしまうと、WebプログラミングにDOM操作が全く必要なく
なってしまうので、WasmにおけるRustのアドバンテージが消失してしまう
可能性が高い。 rustでもDOM操作はJS経由してるし直接的にできるわけではないでしょ
wasmでrustが有利とされているのはランタイムが薄くてバイナリサイズが小さくできる点では >>99
そもそもJSの時点で速度に不満の有る人がどれだけいることか、という点がある。
C++なら既存の資産もあるし、nativeアプリと互換性を持たせることが出来る
メリットもあるが、Rustにはない。 >>99
そもそもJSの時点で速度に不満の有る人がどれだけいることか、という点がある。
C++なら既存の資産もあるし、nativeアプリと互換性を持たせることが出来る
メリットもあるが、Rustにはない。 twitterを見ていると、Rust派の人は、JSより高速になることをメリットと考えている
ようだが、JS自体がもともと結構速いので、多くの用途では実際にはほとんど
体感速度は高速にはならない。
なので、Wasmの意味が無い、用途が無い、という結論に至ってしまう。
これはそもそも、Wasmが作られた経緯を無視しているから。
WasmはC++をブラウザで使いたい、という事から始まったもの。
EmscriptenでC++をasm.js化していたものが、それをさらに効率よくするために
生み出された。
だから、もともとJSを高速化したいことが目的ではなく、C++を使うことが
目的だった。
Rustでは駄目なのだ。Rustでやろうとするから、そもそも論に陥る。
そもそも、そんなに高速にする意味があるのか、という。 Rustはメンドクサイのだ。
だから、「そこまでして高速にする必要があるのか」という疑問に至る。
ところが、C++はRustほどはめんどくさくない。
普通に直感的に書いたものが、JSの5倍程度の速さを安定してたたき出す。
なので、C++で書くと楽なので意味があるが、Rustはめんどくさいので意味が無い、
ということになり、Wasm不要論へと繋がっていく。
しかしそれは、Rustを使おうとしたことがそもそも間違いなのだ。 てか明らかにvueもreactもいじったことない奴が騒いでるだけだろ。
まともに相手するだけ無駄だわ。 世界中のIT技術者から愛されているプログラミング言語はなにか。
プログラミング関連のQ&Aサイト「Stack Overflow」を運営する米Stack Exchangeがそのような調査結果を発表した。
各言語の「Loved」(愛している)と「Dreaded」(恐れている)の比率でLovedが最も高かったのは「Rust」(86.73%)で7年連続で1位になった。
回答数は7万1467件。
https://www.itmedia.co.jp/news/articles/2206/24/news128.html https://www.atmarkit.co.jp/ait/articles/2107/08/news112.html
「WebAssemblyアプリケーションの作成に使用している言語は何か」と質問したところ、Rustが最も多くの回答を集めた。
「WebAssemblyアプリケーションの作成に今後最も使用したい言語は何か」という質問でも、Rustを挙げた回答が最も多かった。 そりゃそうなるわな
既存のメンテ以外ではC++で書くことはない
時間とともにRust一色となるだろう Rustは圧倒的にコーティングしやすい
様々な近代的なパラダイムを洗練して採り入れたことが大きい
メモリ解放も完全自動で気にしなくていいのにC並に高速というオマケ付き >>108
安全安心のおまけもついてくる
>>110
Rustに大きな代償はない 煩雑。
参照でツリーが作れない。
リンクリストが本来の性能を引き出せない。 これらのRustの問題点は、教授レベルでも理解出来てない人が多い。 教授レベル?!
複オジ大先生 vs 数学100点大先生のやり取りはいつもいつも有意義有意義ww 今日日曜だけどつまらない書き込みしてんじゃないぞ
一日最低1000行書かないとレスしたらダメだぞ ライフタイムがらみで一日なんどかキーボードかマウスを投げたくなる
自動で判定しろよ >>116
そんな悩むようなことか?
そこまで酷いのは何か基本理解の欠如があるのではないか
簡単な具体例を出すことを勧める オブジェクトの寿命に関するルールは実際には C++ とそれほど差が無い。
厳密に検証するということと、検証に必要なちょっとしたアノテーションが必要ってだけ。 1000行書くという謎の目標にこだわってるからライフタイムの理解がおろそかになってるのでは
エラーが出るたびに原因をしっかり調べれば同じ過ちを何度も繰り返すことはなくなるでしょ 登大遊は凡人レベルのコードでいいなら1日1万行は余裕で書けるって豪語してて草生えたな
一時期は天才少年プログラマーと持て囃されてた彼も所詮日本の凡才駄プログラマーだったな
彼を見てるとわかるが日本人は手段にこだわって目的を達成できずに結果残せないないアホばかりなんよ
SNSやナレッジコミュニティやオフ会でドヤ顔で偉そうに蘊蓄たれてイキリ散らかしてるやつばかりなのって要するに日本の終わってるゼネコンビジネスIT業界で楽しみを見出せる要素がそこしかないからなんだってことよ
如何に日本のプログラマーがゴミで哀れな奴らかわかる そもそもコードを書く時間よりもその
コードのリファクタリングなどの時間の方が多い
そしてリファクタリングでは行数は減る方向が多い
書く行数の多さを気にするのは質ベースより量ベースの典型的なダメパターン 普通にプログラミングするには問題ない程度にライフタイムを理解した上でも、
Rustには沢山の欠点が有り、ライフタイムをこれ以上理解しても、それは
解決しないと思ってる。
なぜなら言語そのものが持つ欠点だから。 それはそう。
足りない諸々は unsafe でやれ (プログラマが正しさを保証しろ) というデザインであって、全部を面倒見れるとは誰も思ってないよ。 大先生方wとまともに議論が成り立つわけないじゃんww >>123
しかし、Rustの方式では、ある種のアルゴリズムは、unsafe の中だけに
閉じ込めきれないことがあり、結局、アプリでそのアルゴリズムを本来の
効率では使えないことがある。
これも言ってることを理解するには経験と深いイマジネーションが必要なので
反論してくる人が居てもその反論が間違いで、Rustの欠点として本当に存在
している。
昔、C言語が登場した頃、アセンブラほどには速度を引き出せ無い事が有ったが、
大事な部分の関数をアセンブリコードで書けばそれで解決した。だから、
C言語がこんなに普及した。
ところが、Rustでは、それと同じ事が出来ない。
unsafeの中だけに閉じ込めきれず、「はみ出してくる」部分がsafeに扱えないので破綻してしまう。 具体性の欠片もないフワフワした話しかできないんなら黙ってりゃいいのにw linked listの人の完全論破されたら潜伏してほとぼりが冷めてから全く同じ主張を繰り返すムーブ何回目だよ >>126
具体的なことを何一つ言えない時点で話にすらならないが
一つ重要なアドバイスをしてあげよう
unsafeとは他の言語と同じ状態ということ
つまりunsafeについて批判すればするほどそれはRust以外の言語がいかにダメなのかを語っていることになる
ちなみにRustはunsafeの中でC言語と同じことができるしもちろんインラインアセンブラも書ける
つまりRustはC言語と同じ機能及び性能を有している側面がまず第一としてある
その上で外部を巻き込むことなくunsafeな部分を内部に完全に閉じ込めた各モジュール例えば標準ライブラリなどを次々と生み出すことにも成功している
そしてRustコンパイラが安全性を保証するプログラムを現実に書くことができることを実証してきた
だからこそIT大手各社が共同でRustを支持する状況にまでなったのだ なんか違うというレベルじゃなく一番大事なところが間違ってるよ このスレでよく見かけるパターン
Rustアンチな人は不利になると「なんか違う」「間違ってる」など呟くが具体的には何も言えない このスレじゃなくて5chすべてがそうなんだよ馬鹿www
こんな便所の落書きにすら劣るキチガイの巣窟で正論打っても意味ねーんだよ
こいつらはこいつら自身が一番嫌いなDQNやチンピラと同じ大いなる無駄なことして暇つぶしてるガイジどもなんだよwww 複オジは信者の自分以外はみんなアンチにみえちゃうみたいw cと同じに欠けるってのは明らかに嘘だろ。メモリモデルが違いすぎるっつーの。 >>135
「メモリモデル」という言い方は、PC-9801のような16BIT MS-DOS時代に
別の意味で使っていたから混乱を招くが、言いたいことは分かる。 >>139
結局のところ>>129で合っているわけか >>138
そんな真面目な用語じゃなくて
プログラマがメモリに対して持つメンタルモデルとかそのくらいの意味ではないかと思われる >>142
そのレベルの話だとしてもスタックやヒープの使い方はrustもcも同じだよね
何をもって違いすぎると言っているのかがわからん >>129
>unsafeとは他の言語と同じ状態ということ
unsafeでもRust特有のメリットもあればデメリットもある
特にC/C++とは担保されてるsafetyのレベルが根本的に違うので「unsafeなら他の言語と同じ」とか言ってる人はunsafeをまるで理解してないので騙されないように そこはあまり本質的じゃないな
Rustは機能的にも速度的にもC言語の代替となれる点が本質だろう
そのうえでRustは非常に大きなプラスαがあるからC/C++は不要となった Rustの側で書き換えないから
let a=99;
とかした奴をCに渡してC側で書き換えるのってアウトだよね? Rustの登場でC/C++が要らなくなったのは当然
>>147
まずはRustの初歩を学習必須
Rustではlet mut a = 99; とmutを指定すればその変数が書き替え可能
呼び出し先で書き替えたいならば
まずRustの関数を呼び出す時は &mut a と可変参照を渡せば呼び出し先で書き替え可能
Cの関数を呼び出す時はそれを *mut とポインタにして渡せば呼び出し先で書き替え可能 >>146
全てunsafeにでもしない限り、効率を落とさずには代替になれない例が有ると言っている。
ポインタ値をアプリ全体でLinkedListのノードを識別するための id 値として
利用している場合だ。
index 番号では効率が劇的に下がるケースが多い。 >>151
その件に限らず全てのケースで以下が成立する
基本事項: RustではCと同じ速度&同じ安全度で常に全ての実装が可能
追加事項: RustではCと同じ速度&完全に安全なインタフェースで多くの実装が可能
したがってCが不要となったとの話はもちろん正しい >>153
それはmut宣言していない変数を(先のC関数もしくはRust unsafeで)書き換えてしまうことになるためあまりよろしくない
書き替えるならばmut変数のmut参照を直接*mutにした方が良いのでは
let mut a: 型名 = 初期値;
c_func( & mut a as *mut _ )
>>154
それは>>152で正しい >>147
FFI呼び出しに要求されるsafetyを満たしてないと言う意味ではアウトだけどそれがどうかした? まーた複オジ vs 100点オジの低レベルな言い争いになってるから
隔離スレ復活させたほうがいいな >>160
>>155に間違いは無いようだし
君はさっきから的外れなことばかり書いてるような >>151
それがどうしたというんだ?
何を言いたいのかわからん。 > 全てunsafeにでもしない限り
誰も問題にしてないところを勝手に取り上げるのはストローマン論法っていうんだぜ! >>151
なにを問題にしてるのかよくわからんが必要なら全てunsafeにすればいいやん
それでもCとかと同じでそれ以外のケースではRustの方がより安全なんだし リーナスがこのスレを見ていたらLinuxに採用されることはなかっただろうね メンタルモデルってプログラマー界隈ではよく知られた言葉だと思ってたんだけど通じない人もいるのね プログラマー界隈で言ってる奴を見たことないしそもそも違い云々の時にそんなもん出されても困惑するだけ >>169
自分の周りでも普通に通じるけど、よく考えるとどこで知った用語か謎かも…
なんか有名なプログラミング系の本とかに書いてあったっけ? 適当な造語をさも常識のように語るのはやめようね
そもそもそんな言葉使わなければいい話 >>172
プログラミングのコンテキストでよく使われるようになったのはUI/UXデザイン分野でよく使われてたからじゃないかな
ドン・ノーマンの「誰のためのデザイン?」とかかなり昔の本から使われてるよ そもそも拾う必要すら無かったレスを拾ったばっかりによく分からん論争に
なんかすんませんな 複オジ大先生がそんな言葉ないとおっしゃってるんだぞ!
スーパー自宅開発者の複オジ大先生が間違ってるとでも言うのか!! >>165
「全てunsafe」だぞ。
アプリ全体をunsafeということだ。
なら、C/C++で十分。 だから
> ポインタ値をアプリ全体でLinkedListのノードを識別するための id 値として利用している場合だ。
の場合だけだろ
お前はそんな特殊なアプリしか作らないのかよw
そもそもノードの識別を全体にばらまいてるとか設計がタコなんじゃね? >>180
RubyやJava、オブジェクトの「識別番号」が取得できることがあるが、
それはポインタ値だ。通し番号ではない。
つまり、C言語では伝統的に、リンクトリストのノードを識別するために
ポインタ値が使われている。そしてそれこそがリンクリストの本来の使い方。
だれかが間違えて、通し番号で識別する習慣が生まれてしまったが、それは
集団幻覚みたいなもので、誤った使い方だ。 で、何が言いたいんだ?
Linked Listをアプリ全体にばらまいてるアホ設計を正当化しようとしてるのか?w >>177
気に入らないやつを片っ端から複おじ認定するのは荒らしなんだろうか >>183
その子はキチガイ
>>159でも気に入らない二人だけが書き込みしてるように見えてる >>181
GC言語では、ポインタと言ってもコストの高いポインタとなっていて、コストの高いガベージコレクションで回収する。
それに加えて、データ競合を防ぐには更に何らかの競合回避コストも加わってくる。
一方で、C/C++ではリンクされたノードリストからノードを外す時に、そのライブラリがノードを解放してしまうと、そこへのポインタを保持していた場合にダングリング発生。
それを回避するためにはshared_ptrなどのコストの高いポインタを使わざるを得ない。
ちなみにC++のshared_ptrはスレッドセーフだからマルチスレッド時でも大丈夫だが、逆に言えばシングルスレッド時には無駄なコストがかかっている。
Rustでは、そこはRcとArcの2種類が提供されており、シングルスレッド時にはコストの低いRc使用、マルチスレッド時にはRcだとコンパイルエラーとなってくれてArc使用と、最小限のコストで済む。
このようにノード解放の観点だけ見ても、考慮すべきことをRustコンパイラは適切に指摘してくれる。 なんでずっとRustスレでRustのセールストークやってるんだ? RustスレでRustのネガキャンやってるやつよりマシだろ >>182
C言語が速い秘密はLinkedListとそのノードをアプリ全体でポインタ値で識別している
ことにある。先頭を0として1,2,3と割り振った通し番号を使っていたと
したら、全然速度が出ない。
そしてその証拠が、JavaやRubyなどで「識別番号」が8桁の16進数で表示できる
ことだ。その識別番号とは生ポインタ値のことであり、それがそのオブジェクトを
唯一に特定できる最も効率的な方法である。
他の方法では効率が落ちる。 >>185
あなたは、理解が浅い。
RustのRcやArcには欠陥がある。
そんなもので済むならとっくにCやC++でも採用されている。
C/C++の歴史の長さを舐めてはいけない。 >>188
同じ話を何度も繰り返すなよ、ボケ爺か?
そうであってもそのアプリがCと同じでそれ以外のアプリならRustの方が安全って書いてあるだろ >>187
他人に説明できるだけの合理的理由が無いことは自覚してるんだな…… えっ、なにか説明が欲しかったのか?
スレ読んでりゃわかると思うがw >>189
欠陥があると主張するならば、その理由を示さなければならない。
さらにC++でも採用されていることを知らないのは無知ではないか?
C++のshared_ptr = RustのArc = SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
それらのスレッドセーフでないコストの安いバージョンがRustのRcである。
これらは、安全にポインタを共有しつつ即時解放を行なうために、必須の機能である。 ラスタシアンは何故算数おじさんに触れずにいられないのか >>193
いや、RustのRcなどは、C++とshared_ptrと同じじゃない。
全然違うと言っても過言ではない。 >>195
なぜか自分のレスには反応してくれないんだよね
>>196
具体的になにが違うの >>196
違いがあると主張するならば、この議論で意味のある違いがあることを示さなければならない。
さらに前述の、欠陥があると主張した件についても、その欠陥を示さなければならない。 >>197
>具体的になにが違うの
平日の昼ひまでこのスレにくるおじさん・じじいは
C++のshared_ptrと同じじゃないということを知ってさえいれば激十分なんだよ。
だから、具体的になにが違うかは(知らないから)答えられない。
C++とRustの深い知識あるようなすごい奴が平日の昼暇でここで遊んでいる
なんてことはないだろう。 Full Stack Rust App Template using Yew + Actix!
https://youtu.be/oCiGjrpGk4A ここRustプログラミングに関することならば何でも歓迎
各々の関心がないことの和集合を取ると全体集合になる
特定の人にとって関心がないからと言って排除してはいけない 違いが大きすぎるとどこが違うとかいうのを説明するのが難しくなる。
織田信長とオムライスの違いを説明できるか?
まあ shared_ptr と Rc の違いはさすがにそこまで大きくはないけども、
前提となる C++ と Rust の違いも小さくはないので比較する意味を感じないな。
shared_ptr は shared_ptr だし Rc は Rc としか言いようがないだろう。 リファレンスカウント方式の複製可能なスマートポインタという点では類似のものと言って良いのでは
元々はc++とrustで実行効率に差があるという話だがその観点でどういう差があるのかね
そもそも実行効率が何のことを言っているのかがよくわからんから議論しても仕方ないか >>203
全く別物の比較なら、信長は人間、オムライスは食べ物、というようなザックリした説明で良くなるのでは? Arcとstd::shared_ptr<>が似てるという人に対して、「いや、std::shared_ptr<>とRcは全然違う」と反論するのがおかしいのでは? >>206
そうだよ。
それを適用するなら
shared_ptr は C++ のスマートポインタ、 Rc は Rust のスマートポインタということしか言えなくなる。 >>208
俺らのレベルではその程度の知識で十分だろ
で、スマートポインタでもなんか違いあるの?と質問されても具体的に答えられなくても
全く問題ないからな。
一方、すごい人からすれはstd::shared_ptr<>とRcは全然違うとなるんだろうが
(すごい人敵にはそれらは例えばstd::shared_ptrは信長で人間、一方、Rcはオムライスで食べ物ぐらい違う!
でも、俺らは人間だって餌として食べることができるから同じだろ) >>196
>>193 は
> C++のshared_ptr = RustのArc = SwiftのARC が同じ機能であり、スレッドセーフなリファレンスカウンタ利用の共有ポインタ方式。
って書いてるんだから同じじゃないとか全然違うとかフワフワしたこと言ってないで
・機能
・スレッドセーフ
・リファレンスカウンタを利用
の各項目について違いを書きなよ >>212
だとするとshared pointer方式ってどんな方式??
リファレンスカウンタを利用しないshared pointer方式もあるってことだよね? >>214
shared pointerはc++のが有名すぎるからなんとも言えないなぁ。
参照カウント以外でポインタを共有するのはリンクリスト方式とかあるよ。 ARCで管理してる時点でRustはガベコレじゃないからすごい!って理論は破綻してるんじゃありませんかね? >>216
誰がそんなこと言ってんの?
静的に管理できるものは静的に管理するし、実行時にしかわからないものは実行時に管理するってだけのことだ。
参照カウンタの適用範囲を間違えてるプログラマがいるならそれはそいつが無能。 Rust公式の日本語意訳にはしっかりRustはガベコレじゃないから高速って書いてあるね >>216
Objective-C/SwiftのARCとRustのArcは同じ3文字略語だけど別のものだよ
それを理解した上で言ってるのなら別にいいんだけどさ >>216
そもそもRust公式が「メモリリークはメモリ安全の範疇」と言っているしな。 >>220
それはRustの定義がおかしい
一般的にはメモリリークがあるとメモリ安全だとは言わない 流れぶった切りだけど単純にRustの人たちはGUIどうしてんの? なんだ、じゃあ、バグはセーフティと定義したら、Rustは安全高めなのか。 >>221
Rust が言語の仕組みによって防ごうと努力する範囲にメモリリークは含まないという定義だよ。
それを表すのに「Rust の仕様の中では」メモリ安全という用語を使っているのであって、
定義におかしいもクソもない。 定義なんだから。 >>224
クラスと名付けられている概念はない。
あなたにとってクラスとは何のこと? 何が出来ればクラス? >>216
ARCで管理しているのはSwift
RustはC++と同じくRAIIなので高速
どうしても共有メモリを使いたい時のみshared_ptrやRc/Arcを用いる >>225
そのRustの仕様の中でメモリ安全性を達成できていないんだから
Rustの仕様の中でメモリ安全性という用語を使うのは不適切
Rustの謳うメモリ安全性は世間一般のメモリ安全性とは異なる概念なんだからそれを表すには他の用語を使うのが適当かと >>224
クラスはその根幹の継承がデメリットだらけと結論が出ているためGoやRustなどでは採用されていない
メンバー変数やメンバーメソッド等とは構造体で使えるため困ることはない
Rustでは構造体を含む任意の型に対して横断的に共通適用可能なトレイトがあり非常に強力で利便性がよい >>229
知らんがな。
大抵の専門用語は一般名詞に (その分野における) 明確な定義を与えることで成り立ってるのはごく普通のことだろ。 >>229
世間一般なんてものはなくそれぞれがそれぞれの定義域に依る
そしてそれが明確になっていればよい
例えばRustではメモリ競合は防止可能と明確化しつつ、より一般的な競合状態は対象外と明確化している
原理的に無理なものは無理なのだからそこは明確化してあればそれでよい >>228
aliasingの話してるところにRAIIが来るのもよくわからないがRAIIだと高速という理屈はさらにわけわかめ >>222
windows-rsでunsafe祭りになりながら書いたよ。オススメはしないが。 SwiftのARCとRustのArcの区別がつかない人は論外なので発言を控えてほしい
ただでさえしょうもないのにしょうもなさが倍増するからね・・・
SwiftのARCはAutomatic Reference Counting
https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html
RustのArcはAtomically Reference Counted
https://doc.rust-lang.org/std/sync/struct.Arc.html >>233
C++とRustはヒープ利用に対してRAIIによるデストラクタ呼び出しによりリファレンスカウンタ無しでメモリ解放するので高速
さらに加えてRustでは所有権と借用のルール明確化により解放の安全性も静的に保証している
一方でSwiftはヒープ利用に対して常にリファレンスカウンタを用いるARCによりメモリ解放の管理をするため低速 >>236
その流れで継承不可のクラスベースのオブジェクト指向言語がどういうものになるか思考実験的に考えてみなよ それよりSQLが超苦手な俺はPRQLにめちゃくちゃ期待しているのだがラスタシアン達はSQLも達者なのかね? pijul使ってみたけど、改行コードがCRLFだと非対応で
バイナリファイル扱いになるという謎仕様でまいった
差分とか出せなくなる
ファイルタイプ判別を変えるオプションは無い
それは置いといても、表示もドキュメントも超簡素で
もうすぐ1.0.0リリースを迎えるとは思えない状態
ほとんどの入門記事で使われている重要コマンドpijul statusが
最近のバージョンで削除されたのも謎すぎる
だいじょうぶなのかこれ >>239
今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん!になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。 >>242
外人の禿げたおっさんはだいたいエスキューエル言うてるやろ コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。
それが必要になるクソさと、トランスパイルコストの損益分岐点が最初に現れたのがJSってだけだと思うよ。 >>240
メモリリークに関しては
まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない
したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い 「循環参照は自然に発生しない」なんていう解説狂信者おじさんがいる限り、プロジェクトには絶対Rustは採用しない...... ほんとこの種の信者は迷惑だわ
普通は多人数で作業して、データー構造をRc<T>をWeak<T>にあらかじめしておくようなことはしないし、”わざと作成したのだから意図通り”とか
相手(これから学ぶ人や新人)を騙すために都合の良いことを吹き込んでいるようにしか見えない・・・
それなら自動メモリ管理ではないので、作り方/使い方により自然/意図しない使い方でリークも場合もあると明確に認めて、その分だけ
自動メモリ管理ではないないので速度が速いし、メモリー解放のタイミングもある程度コントロール出来ると誠実に話したほうが余程、印象が良いのに。
胡散臭い宗教の勧誘に見えるような態度だから叩かれる >>241
PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな
一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね 循環参照は自然に発生しないって、コードを何も書かなければ発生しないって意味かな >>248
新たなプロジェクトが次々とRustを採用している現実を直視しようぜ
>>249
循環参照はRust以外だと知らぬ間に発生してしまう自然なよくあるものだが
Rustでは複雑な操作で意図的に作り出さないと出現すらしない点を理解しようぜ RAIIでメモリをケアするのは
GC方式にくらべて高速ってのはまぁそうなんだけど
それよりも
開放タイミングが決定的であることのほうが特徴
オブジェクトの生存期間によってメモリの使用期間もプログラマが管理できて嬉しい >>236
参照カウント方式と区別したいなら、「GC方式」みたいな曖昧な用語はやめて「トレーシングGC」を使おうぜ。 >まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
この時点で嘘だらけなんだから、それ以上読む必要無い
日本語ブログだとこういう複オジレベルの人が多数派なので
Rustを本気で学びたいやつは英語のリソースメインで学ぶことを強くすすめる >>249
アンチは実際にプログラミングしたことがないのかね
Rc<T>自体は書き換えできないのでRc<T>だけでは循環参照を作ることができない
Rc<T>とWeak<T>は互いに対称ではないため直接置き換える対象ではない
例えばnewもRc::new(T)とWeak::new()で引数Tの有無からして異なる
さらに多人数で作業するから強い循環参照を知らぬ間に作ってしまうとの言い訳も意味不明だ >>255
Rustは所有者がいなくなると自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全で合っている >>257
メモリを解放しないCopying GCの方が高速なんだけどなぁ。
Rustもメモリ解放しない実装なのかね?RAIIならスタック領域しかメモリを確保しないとか。 >>258
C++もRustも仕組みは同じ
RAIIによりスコープを外れた対象のスタック部分が解放される時にそのデストラクタによってヒープ部分が解放される
汎用的にはこれが最も高速かつ利便性>>253が高い
Copying GCは特殊な環境で特殊な使い方に限定する場合は速いこともありうるがデメリットも多く一般的には使われることが少ない
使用メモリが多くなるとかコピーで値を移動させるため非常に遅いなどのデメリットの他に
そこを指す全てのポインタ値をGCのたびに全て修整しなければならないという致命的な欠陥がある
C/C++/Rustなどでスタック上に置かれたポインタ値の全てを的確に書き換えるのは不可能なので使えない 短時間で終了するプログラムはfree呼ばずにexitした方が高速な場合がある
copy gcも条件付きだが高速な場合がある
常にRAIIによるメモリ解放が他の手段より高速というのは誤り
100%正しいという風に断言するから枝葉の議論になるし最初から論理的に厳密な文章書いた方が良いよ >>260
これは特殊な使い方限定の話を持ち出したら意味がない話
既に書いたようにCopying GCは汎用的には使いものにならない
一般的にはRAIIによる解放が最も高速かつ利便性が高い
そのためC++でもRustでもその方法がとられている copying GCはJavaで使われているのだが
解放しない、以外でスタックの解放(malloc的なものに対する)freeより速いものはあるの? >>246
C++にもweak_ptr<>あるけど。 RAIIがGCより高速なら
RAIIの一例であるshared_ptrはGCの一例であるARCより高速ということになるが
どういう原理で高速になるの? でも、JavaはC++も20倍速いってサイト無くなったじゃん。 >>261
だって、RustはC++0xのパクリじゃん。 >>264
shared_ptrではRAIIによって解放しない
RAIIによってデクリメントするだけ
SwiftなどでのARCが遅い理由は参照型の全てにおいてshared_ptrを使用しているような状況であるためコストが高い >>269
unique_ptrとshared_ptrの役割の違い、動作の違いを理解できていない君が
間違えて用いてもC++ではコンパイルが通ってしまったりして実行時に問題を引き起こす
Rustは間違えて用いるとコンパイルエラーとなり通らないから安全側に救われる >>268
参照型の全てにshared_ptrを利用したら何で遅くなるの? >>257
即座に開放というのがOSに返却とか認識してたらアウトだぞ。
アロケーターなに使うかで実際の挙動は変わってくるからな。
普通しないがクソアロケーター使ったら、OSからみたらリーク同然になったりするし。 所有者がいないとメモリ解放って間違ってるよね?
所有者がいてもブロックから出たら解放されるからコンパイルエラーが出てコンパイルされない >>272
そんなバカな認識するのはオマエだけだろw >>273
所有者がいなくなるとメモリ解放であってるよ
スコープを抜けると所有者がいなくなりデストラクタが呼ばれて管理していたヒープ領域があれば解放される 所有権とは?の話に戻っちゃうな
複製おじさんネタで散々繰り返したやつ なんか合ってるのか分からんけど最近思うこと
Rustの言語仕様内に明確に含まれているのはlifetimeだけで
所有権とか所有者ってのは実はただのメタファーでしかない? C++はコンテナのアロケータと積み荷のアロケータが別とかできるくらい柔軟ですよ。 コンセプトをコンパイラにハードコーディングして変えられないようにしたのがRustってこと? >>256
こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ?ゴミのくせにイキって恥かいてんじゃねーわw
The Rust Programming Language 日本語版
循環参照は、メモリをリークすることもある
循環参照を回避する: Rc<T>をWeak<T>に変換する
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html >>276
間違ってることを合ってると強弁するのいい加減辞めなよ 認める事を全くせず、大したコードも書いてないのにRustやってる事だけが自尊心だから勝手にアンチだの決めつけて
いつも人を見下して偉そう。プロジェクトチームの雰囲気はそいつがいるだけで常に最悪、チームの重荷・会社の害悪。
口癖は「意味不明」 >>282
実際にコードを自分で書いて理解したほうがいいよ。
その公式Bookに書かれている内容はもちろん正しいし、
その相手>>256の書き込み内容も正しくて、
両者に矛盾はないよ。 理解してないと書いてる人間が理解してないことは多いですよね どちらにしてもRust使っても気楽にコーディングできるわけでもなく
メモリ構造考えなければいけないんですね 結局、C++0xのパクリじゃないですか。
C++はそこからさらに10年以上進んでるのに。 それはないかな…
どっちも一長一短で視点がぼやけます >>279
説明用に作った概念ではあるけどRustの根幹に関わる重要な概念なので
「ただのメタファーでしかない」という言い方は微妙
自分の好き勝手に解釈した内容を公式見解かのように流布する輩を助長することになるから C++は高機能すぎて分けワカメなので、初心者用に出来ることを減らしますという、ジェネリクス界のPythonがRustでは? >>283
見たけど正しいやん
間違ってる!とウソをつくけど間違ってる点を指摘できないいつもの人かね? 誰も所有してないのに解放されないなら意味ないじゃん。 >>294
ヒープ領域に対して誰も所有(利用)しなくなった時に
・自動解放しない(要手動解放) ← C C++(下記除く)
・即座に自動解放する ← Rust C++(unique_ptrなど使用時)
・GCする時になってから自動解放する ← ほとんどのGC言語 Cで書くにしても、今時のCLIツールならヒープなんか解放せず放置しても実用上問題ないよね そもそも間違ってるとは何と照らし合わせて間違ってるという主張なのか
「そうあるべきではない」というべき論なら前提を明確にしない限り知らんがなとしか言えん >>295
いや、C++はアロケート時にアロケータを選択するから。
デフォルトが準備されてるだけで。
当然、GCもあり得るから。 だめだ、こいつに聞いても無駄だ。
誰かわかるやつ居ないのか。 >>284
アンチ君は皆に論破されると毎回
思い込みの仮想敵を作り人格攻撃を始めて逃避するようだが
そんな下らないことはアンチスレでやってほしい 自分より詳しいやつは全部アンチか。
それじゃダメだろ。 Rust信者スレ作ったらそっちに移動してくれますか? つまり、C++0xをパクって機能限定して簡単にしたのがRustだろ? >>295
プログラミング言語の進化の中で、
そのメモリ自動解放における高速性と安全性の両立をRustが初めて実現したってことになるのかな Region-based Memory Management の構想は Cyclone から始まってる。
この段階では実用化したとは呼びにくいが、実現は出来ていた。 >>304
C++以外からもいろいろパクってるからその言い方だと不正確に思う 正確にはこうだな
プログラミング言語の進化の中で
メモリ自動解放における高速性と安全性の両立を実現した初めての実用的な言語がRust C++0xがなかなか標準化されないので、それなら自分で作ろうと立ち上がったと本人が言ってるじゃん。 >>309
そこは常識の範囲内で実用的をどのように定義しても>>308を満たすのはRustだけだから問題ない 別にC/C++でもちゃんと作れば高速性と安全性は両立してるよ
ちゃんと作るのが難しいかどうかの話でしかないだろ >>312
C/C++では不可能
うっかり危険なコードを書いてもコンパイラが通してしまう
Rustはコンパイラが指摘して通さないため安全 難しさを度外視してちゃんと作ればいいと言うならアセンブラでも同じわけで。 >>312
残念ながらCとC++は安全性を満たしていない
現状Rustだけが安全性と高速性を両立させている じゃあChromeやSafari、Edgeじゃなく、お前のブラウザーふぁいあーふぉっくすにしろよ?安全じゃないんだろ?ぷゲラ うっかり前提条件が保証できていないunsafe fnの呼び出しを書いてもRustコンパイラは通してしまうではないですか >>313,315
ああ、Rustが決めた安全性か
まあ>>274みたいなのには目をつぶるならそれでいいんじゃねw
はたから見たらオナニーにしか見えないけど
>>314
そうだよ、突き詰めたらレベルの違いでしかない
普通のひとは突き詰めること自体が馬鹿らしいって思うからこんなことで揉めたりしないけど >>318
うっかりunsafe関数を呼び出しのは不可能
Rustコンパイラが通さない C++が敗北した理由が安全性を疎かにしたことは事実だけど
当時は安全性なんてそこまで重視されていなくて速ければよい時代だった
さらに安全性と速さを両立させる使い物になるプログラミング言語が出てくるとは想像できなかった
ここ数年でC++がようやく退場する時代となったたけでありそれ以前はC++の天下であった >>318
実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう >>319
天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++ 「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな?それともわざとかな? マ板のコテハンが常駐するとどのスレも不毛地帯になるな >>323
レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ
>>325
> まあ>>274みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」 話は単純
RustはC++における問題のうちみんなが挙げてるような重要な部分を解決してしまった
それにプラスしてC++よりpRustの方がプログラミングしやすい点も非常に大きい >>330
そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ >>329
「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな 年寄りはRustに構わないで欲しい
黙ってCでも書いてて >>332
Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用 >>334
歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ > 287 名前:デフォルトの名無しさん [sage] 投稿日:2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
> どちらにしてもRust使っても気楽にコーディングできるわけでもなく
> メモリ構造考えなければいけないんですね
読んでなるほどなと思った
よくわかんないけどとりあえず動けばいいという人と、
ちゃんと理解して自分の思う通りに動かしたい人の違いだなと >>335
俺,win使っているが
そのよい言語のRustをコンパイルするのに(C/C++する気ないのに)駄目な言語のmsvcを入れないと
とコンパイルできないてのがな
で、なんでmsvc必要なんだ?
ひょっとしたら、linuxでもgccとかを入れないと駄目なのか >>337
その人があまりにも知識不足の可能性が高い
Rustでも他の言語と同様に(C互換FFIを除いて)メモリ構造なんて公開も保証もしていない
ほとんどのプログラミング言語はメモリ構造なんて低いレベルで使うものではなくもっと抽象度の高い部分でその定義と保証がなされるもの
だからRustでも他の言語と同様にメモリ構造は考えなくて良いし考えてはいけない
メモリ構造は言語として保証していないし保証しないからこそ大胆なコンパイル最適化を行なっている
話を戻してその人はメモリ構造ではなくデータ構造と言いたかったのではないか?
データ構造は他の言語と同様にRustでも考えなければならない
それがプログラミングの中心だから >>338
そんなこと知らずに、そういうレスしているところにドン引きだな
自分で調べた?
調べたら、その結果をここで報告よろしく >>338
Rust批判派があまりにも知識不足で驚いた
ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる >>339
SwiftとかABI stabilityを実現してるやつは仕様としてメモリレイアウトを定義して公開してるやろ >>341
["rust linker cc not found"] [検索] まあ>>287の書いてるメモリ構造という言葉はメモリレイアウトでもデータ構造でもないのは明らかだけどな 隔離スレ復活させないとノイズだらけできつくなってきた >>342
そのABIはコンパイル後のバイナリのフォーマットの話だぜ
今回の『気楽にコーディングできるわけでもなくメモリ構造考えなければいけないんですね』はプログラミングの際の話だから関係ない
プログラミングする上でメモリ構造は考えなくていい
例えばRustの型VecやStringなども各々のがどんなメモリ構造になるかは規定も公開もない
もちろんソースコードを読めば内部のデータ構造までは分かるがそれに依存してコードを書いてはいけないし依存できないよう抽象化されたインタフェースのみ規定公開されている >>345
同感
アンチ活動は別のスレでやってほしい
ここ本スレでやるのはマナー違反だと思う
今後Rustへのアンチ活動は以下のスレへ書くこと
Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/ >>343
なるほど、
>341
>ちなみにこちらはLinuxだがrustc(=Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな >>350
おまえ低能だな
そんな内容と設定ではそのスレは過疎って終わることくらい予測できるだろ? Cellを使っていて思ったんだが例えば
trait CellUpdateWith<T> {
fn update_with(&self, f: impl FnOnce(&mut T));
}
impl<T: Default> CellUpdateWith<T> for Cell<T> {
#[inline]
fn update_with(&self, f: impl FnOnce(&mut T)) {
let mut inner = self.take();
f(&mut inner);
self.set(inner);
}
}
このようにメソッドupdate_with()を用意しておけば
内部更新もわかりやすく記述できるな
let foo = Cell::new(vec![1, 2, 3]);
foo.update_with(|v| v.push(7));
身代わりにself.take()でdefault値を入れてCellから取り出し
self.set()でCellへ戻すという無駄な操作は最適化で消えるようだ
https://godbolt.org/z/19c4EbErG >>351
それをわざと狙ってんだろうなww
いかにもやりそうなこと >>354
この手の人は自分が排除されることを最も恐れてるんだよ
そうならないための策ならなりふり構わず何でもやる
自分が排除される側にいる自覚がなければそんなことやらない >>308
糞言語で自意識過剰の公開オナニーをする信者、マジきもい >>308
プログラミング言語界に大革命をもたらした画期的な言語だな 15年近くc/c++触ってなくて(ずっとjava触ってた)
rustの所有権とか何故こんな仕様になったのか経緯がわからなくて
最近のc11以降の仕様の?unique_ptrとかshared_ptrとかstd::moveとかstd::forward学んで
(元々boost にスマートポインタがあった記憶があるけど記憶が曖昧)
どうしてこう言う機能が出来たのか少しわかった
今のc++はconst 地獄だしとにかくコードが汚くなる
こりゃrust の方が良いわ
あと型名の付け方が好き。u32とかf32とか
昔cで書いてた頃typedefでわざわざ定義してたよ const 地獄 ← 判る
static_cast うぜー ← 判る
Rust 万歳 ← 判らん >>353
もっと便利にできるぜ
use std::cell::Cell;
trait CellWithMethod<T> {
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R;
}
impl<T: Default> CellWithMethod<T> for Cell<T> {
#[inline]
fn with<R>(&self, f: impl FnOnce(&mut T) -> R) -> R {
let mut inner = self.take();
let result = f(&mut inner);
self.set(inner);
result
}
}
fn main() {
let foo = Cell::new(vec![1, 2, 3]);
foo.with(|v| v.push(7));
assert_eq!(4, foo.with(|v| v.len()));
assert_eq!(7, foo.with(|v| v[3]));
assert_eq!(vec![1, 2, 3, 7], foo.with(|v| v.clone()));
} >>360
CellでVec使えるのか
何か間違って学習していた
https://qiita.com/wada314/items/24249418983312795c08
> 1. Cellの中身の型はCopyをimplしていなければならない
https://dev.classmethod.jp/articles/rust-smart-pointer/
> ・Cellの中の型はCopyトレイト実装が必須
https://qiita.com/usagi/items/fc329895cebd3466910e
> Cell は値の "移動" によって内部可変性を実装するため <T> は Copy 可能な "値" 向けのコンテナーで、
> i32 や Copy trait を実装した何かを扱うのに"適した"コンテナーです。
https://zenn.dev/mebiusbox/books/22d4c1ed9b0003/viewer/5df75e
> Cell<T> の大きな制約として, T は Copy トレイト境界があることです.
実際にはCellはCopyを要求していない
やってみたら>>360のコードが動いてCell<Vec<_>>が使えた >>362
標準ライブラリのderiveは型パラメータに無条件にトレイト制約課すようになってるから
derivativeみたいな制約を自分で指定できるcrateを使うと良いよ
https://github.com/mcarton/rust-derivative >>361
get()がCopyを要求するからってのもあるけど
古いThe BookにはCellはCopy専用・RefCellはCopy以外も使えるという説明があったので
それが日本語訳とかで残ってたんじゃないかな >>360
!Syncで参照無しならデータ競合を起こさない、という点を使った用法だな
便利だから公式サポートすればいいのにな StackOverflowで「好きな言語No.1」だそうだが、調査方法に問題が有り、
二位以下も聞いた事が無いような言語ばかり。 CarbonとかいうRustとC++のあいのこみたいなのが出てきた RustがCarbonに勝ててるところが見つからないな Rust vs Carbonスレ立ててそっちでやれ このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい このスレにはRust好きの愚民がたくさんいるようですね。
Carbonさん、やっておしまいなさい CarbonとRustは名称の紛らわしさではどっこいどっこいだな とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう JSのTypeScript
C++のCarbonって感じかね
どうなるんだろうね
確かにC++を無くすのは勿体ないがまだ0.1か いつ1.0になるかなぁ 10年後くらいか
Rustよりも難しくはなくメモリ管理も楽になるのかな Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
現在のCarbonのドキュメントを見る限りRustの領分に入ってきていないでしょう
それよりもC++と書き方がかなり変わっていて互換性がなく別言語の様相でCarbonは中途半端な立ち位置に見える Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
結果的にRustより難しくなっても驚かないけど そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
C++も当然マスターしてないといけなくて、学習量は明らかに増えてる気もする ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した
どちらかと言うとザーボンの色違いがカーボスなら納得なんだけど… Carbonって中途半端すぎね?
まともな言語設計者ならオブジェクト指向もう採用しないと思うんやけどなんか継承機能もあるみたいだし
なんでこういう中途半端のところもC++参考するんだよこういうところこそRust参考にしろよ >>384
C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる ま、2-3年後にどうなってるかだな
バックにGoogleいるらしいから開発終了なんてことはなさそうだが >>386
逆じゃね?企業だからこそ開発者の熱意とか関係なくコストに見合わないとなれば容赦なく切られるかと
Goみたいに社内で使うことが確定してしまえば安泰だけど SDGsの流れ的にCarbonは使われなくなる運命 5年たったらまたオブジェクト指向が再燃してるかもしれない
と言うか業務では大規模開発にはオブジェクト指向が必須なんだな
モジュールでは全体が見通せない 話題が逸れるが >>384 が C++ の型システムをオブジェクト指向と呼んでるっぽいのが気になる。
オブジェクト指向はオブジェクト同士がメッセージを送りあう形でプログラムを構成する思想のことで、
それを言語機能としてどのように支援するのかには様々なバリエーションが有りうる。
型システムとは独立した概念だよ。
ふんわりした概念なので定義によるが Rust もオブジェクト指向 (をサポートする) 言語に分類されることはある。
それはそれとして、 C++ の型システムもベストとは言えないが最悪というわけでもない。
実際にかなり多くの場面で活用されている実績は認めないといけない。
要するに「この程度で十分」ではあるんだよ。
C++ の本当につらいところは C から引き継いだガバガバさや歴史的事情のワケわからんところであって、
型システムの根本的な改善はそれほど切実に必要だとは思わないな。
C++ が駄目だと否定するんじゃなくて C++ みたいなことを C++ より上手くやるという方向性はアリだろう。 >>391
前半は正しいが
後半のクラス継承システム程度で十分という点には賛同しかねる
今までの現実の多くのケースはクラス継承システムしか使えない環境だったから無理矢理にそれを使っているだけである 似たような機能のものを大量に書く場合どのように実装するのが楽かどのように管理するのが楽か
モジュールではないな >>394
その点ではRustもC++も同じオブジェクト指向なので何を主張したいのかわからない
Rustの基本はselfに見られるようにオブジェクト指向
違いはC++がクラス継承なのに対してRustはトレイト
ジェネリックから見るトレイト境界による型制約となり
逆の視点から見るとトレイト付加によるメソッド拡張となる いくらRustが有望だと言われていても、ポインターがないと使いづらい場面ってあるよな
ツリー構造とか、ポインターなしで大して実行速度も落とさず記述する技があるようだけど・・・・大掛かりなことをするのなら労力を割くのもいいけど、ちょっと使うだけには労力がかかりすぎる >>396
Rustにも様々なポインタがあり
様々な仕様と様々な安全度合いで記述できる >>385
Rustからわかるように、求められているのは膝を打ち抜く自由の無いc++であり、コーダーに使わせる言語。
unsafeはc++で実装すりゃいいので、継承とかは使うだけに限定するという手もある。 >>391
話し手がなにをオブジェクト指向の言語としているのかどうか判断する程度の読解力は持ち合わせてくれないかな?
RustはC++のように継承を導入することによってもたらされる問題を回避するためにclassじゃなくてtraitを基本的なプログラムの構成要素として採用することで既存のオブジェクト指向言語と一線を画すというプログラミング言語史に残る進歩を達成していた >>400
Haskellの型クラスの方が先だろ。
「プログラミング言語史に残る進歩」とかさすがに恥ずかしいレベル。 >>401
RustのtraitをただのHaskellの型クラスの類似物としてしか認識できないのはお前が単に馬鹿だから
Rustのtraitは本来継承もmixinとも違ったC++のclassより洗練された新たなプログラムの構成要素だっていう側面が理解できていない馬鹿が多すぎる
ただRustではこのtraitという構成要素に実用上の面から今度は型クラスという機能も持たせているというだけで話の順序が違う
こんぐらいRust書いていたらtraitには単に型クラスだけの意義だけじゃないってわかると思うんやがお前にはそういった才能もないただのネット上で繰り返し喧伝されている宣伝にしか注目する脳がないいわばにわかの部類の奴だということがわかった traitの画期的な部分はc++のabstract classで実現できないの? >>402
何が言いたいのかよくわからないけど型クラスになくてtraitにあるものって何?
associate typeはrustの発明だと思うけど、そういうこと言いたいわけでもなさそうだし 自分が崇拝する神だけが唯一正しいと妄信して
他人の考え方を徹底的に糾弾排斥するのがカルト
カルト化した人間とまともな議論ができると思うな >>404
公式サイトにすら出典付きで載ってあることなんだけどなんでここで聞くの?
繰り返しになるがtraitの型クラス以外の側面に気づけないのはお前が単に馬鹿なだけ >>406
そういうのを誘導しないからお前はダメなんだよ。
prev.rust-lang.org/ja-JP/faq.html#how-do-rust-traits-compare-to-haskell-typeclasses
How do Rust traits compare to Haskell typeclasses?
Rust traits are similar to Haskell typeclasses, but are currently not as powerful, as Rust cannot express higher-kinded types. Rust’s associated types are equivalent to Haskell type families. >>407
traitの方が表現力低いって言ってるじゃねーか >>407
それURLがprevで始まっているように古い情報ページ
わざわざそれを出すのは何か意図がある? >>408
正しい情報を啓蒙するのは面倒だということを知らしめる意図じゃない? >>404
Rustのトレイトは
トレイト境界を実装で指定できるだけでなく
トレイト境界を型宣言でも指定できるなど
様々な点で型クラスと異なるよね? >>404
associated typeもhaskell由来 >>412
トレイトに関しては当然Haskellの型クラス由来の部分が多いけど互いに片方にしかないものもあり異なる側面があるわけか >>416
普通のこれだろ
struct Foo<T: Trait1 + Trait2> {
inner: T,
} >>418
これが>>402が言う型クラス以上の意義があるものなの? 402の話は402に聞け
少なくとも>>418は型定義の時点で制約できるから意義がある >>418
-XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language. >>421
いきなり何かわからない話を向けられても困る
解説せよ トレイトのどの辺が「洗練された新たなプログラム構成要素」と感じるのか全然分からん
俺の中ではインターフェースと一緒の扱い
Rustが画期的だったのはOwnership/Referenceルール + Borrow Checker
この点に異論ある人はいないよね? >>423
一般的なインタフェースなんて
Trait Boundsもimpl Traitもdyn Traitもないゴミ
>>419
その点でも差異があるだけでなく
Rustのトレイトは基本概念こそHaskellの型クラスと同じだがそれ以外は各々の言語に適応してかなり異なる >>424
そりゃ言語に合わせて変えるところがあるのは当たり前だが、
基本概念が同じだというなら類似物ではあるだろう。
カテゴリ分けしたらおおよそ同じところに分類するよ……。 >>425
それは違うのではないかな
例えばHaskellはRustのtraitでのdyn(動的解決)とimpl(静的解決)といった重要な基本概念を欠いているよ C++の欠点は、何でもできること。
その欠点をなくして、わかりやすくしたのがRust。
バイナリ界のJavaと言い換えても良い。
ほとんどのプログラマはC++よりRustを使うほうが良い。 >>410
だから最新情報に誘導しろよ。
無能か? >>427
これからRustはIT土方専用言語になっていくんだろうなあ >>424
>一般的なインタフェースなんて
>Trait Boundsもimpl Traitもdyn Traitもないゴミ
言語化できてないから本質を理解できていように見える
Trait Boundはジェネリック型の型制約で一般的なインターフェイスも型制約として機能する
一般的なインターフェイスは動的ディスパッチなのでdyn Trait相当
impl Traitがmonomorphizationのことを言ってるならそれはTraitの機能じゃなくGenericsの機能
C++で20年前から使えるよね?
C++以外でもSwiftみたいに一部の言語はGenericsのspecialization機能があるけど一般的にはオーバーロード使ってstatic dispatchにすることが可能 >>418
javaのgenericsでextends使うとできるやつかな? >>429
msとかgoogleとかの狙いはそうだろ。
土方がコーティングしてもバグが入り込まない。
その代わり難易度が上がっているからコーダーの単価上がりそうだけど、msとかgoogleはそんなの気にしないだろうし。 >>432
rustの画期的な部分なんだろ?言い返せないのかよダサいなお前
本当に革新的なのは>>423あたりなんじゃないの kumagiとか見てると、google社員でもc++触らせたらあかん奴ってのが結構いるのがわかる。 >>431
Javaのジェネリクスは変な制限が多く
インタフェース指定していって問題があってもコンパイルエラーとならず実行時エラーとなるものがあるなどJavaは論外
他にも問題多すぎてRustに何ひとつ勝てないから新システムを機会にJava→Rustとなったものも出てきている >>434
Ownership/reference自体はc++にもあるからあんまり革新的とは思えないな。
コールスタック&RAIIを中心にしてメモリ管理ルールを再構築して、厄介なヒープメモリの管理をできるだけ避けて高速化しているのが特徴だと思う。
革新的なのはそのルールを徹底していることくらいかと。 安全性とゼロコスト抽象化の制約下で開発効率を高める仕組みを導入していることがRustの特徴だよね
言語仕様や処理系実装上での苦労や工夫はいろいろあるが、それらによって実現される機能自体が目新しいものというわけではない Rustが発明したのかどうかはしらんけど、Borrow Checkerは他の普通の言語にはない仕組みで、目新しく感じるけどなあ
Borrow Checkerが効かないようなコードを書くんだったらRustを使う意味が感じられないぐらいにはね >>436
インターフェースの問題とJavaの問題を混同するのが論外 Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
Rust独自なのは多分shared xor mutableとmove by defaultじゃないかな >>437
そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。 キモいな
Javaは遺伝子引き継いでないから代理出産に違いない >>442
javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。 >>435
あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。 >>435
C++だけでなくRustも理解できてない?
@
純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる!」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。 >>447
それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない? >>448
低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw OwnershipルールとReferenceルールがWhat
Borrow CheckerはHowに相当
Howにももちろん価値はあるが
それと同じくらいWhatをシンプルに絞り込んだものにしたことにも価値がある
後知恵で見れば当然に見えるようなシンプルなルールを作るのはものすごく難易度が高い >>451
わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける >>445
残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。 ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
そして私的プロジェクトとして実装し始めた。
2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。 C++標準化委員の人でもあったんか
それにしてもRustっていいネーミングだよな
なんかしっくりくる 正直なところ一般的な単語とか1文字とかの言語名はやめて欲しいと思わなくもない。 >>453
逆じゃね。自分たちで作ってるからこそアルゴリズム方面の知識の意味があるのでは >>454
Hoareはホーアかホアだと思うんだが
ホアレはどこの国の読み方? >>456
昔は大変だったけど今時はグーグルさんもだいぶ賢くなって来たから〇 言語や〇 langでいける >>454
>2016年4月、ホアレ氏は最初の製品をRustと命名し出荷した。
2006年の間違いじゃない?
ちなみに>>451に書いてるReferenceルールやBorrow CheckerはGraydon時代にできたものじゃないよ RustじゃなくてHoareの方が検索性は高かったと思う
言語に自分の名前つけたっていいじゃん、最初だけイタい人扱い受けるだけだし でも本当にHoareなんて名前付けたら絶対Tony Hoareのほうだと思われるやろな >>464
ほんこれ
あんな有名人とfamily nameが一緒とかすごい偶然だよな Rust-Oneとか見たいな感じの名前が良かったんじゃないかとw 新言語を作る際にはありふれた言葉を使うなってコンセンサスがあれば…
C java go Perl Ruby Rust ... せめて後ろに +lang した名前を正式名称にしてくれりゃなあ
Javalang、Clang、Golang、Rustlang...
clangは名前衝突するから今更ムリだけど RustとかGoはもう今じゃメジャーだから大分マシだけど
上の方に出てるCarbon?だのみたいな新しい知名度低いようなのにとっちゃ検索されづらいのって結構大きいデメリットじゃないのかね Rustでは検索にこまったことないけどなぁ
CやGoではそれなりに困ったことある
特にC >>469
perlは違うくね
入れるならpython Pythonはまさかちょっとしたイタズラ心で命名した言語が
30年経ってこれほどまでに普及するとは思ってないだろうなぁ。 ゲームのRustが人気になっていても問題なく検索できてるなぁ パーソナライズ (その人のアクセス傾向を検索結果に反映する) がそこそこ機能してるっぽいという話はあるなぁ。
個人情報保護の法律との兼ね合いが難しいみたいだが。 CはC言語で検索してもC++が出てきやがるからな
迷惑な言語だわC++ 全然、思想や人柄が違う人を後継者に立てようとしても無理が有るな。 >>456
その例でいってとにかくクソダメなのが Go
言語仕様も前時代的なウンコみたいな仕様だが何がだめといって名前がクソすぎ
ついでにいうとマスコットが致命的にキモすぎる goはgolangって呼び方が一般化してるから問題なくね?
親会社もalphabetだし、仮に一般名詞でも検索してやんよっていう自信の現れなのかも。
あとlisp monsterのほうが可愛いよね ゴラン高原はイスラエルが不法に占領してるシリアの土地であり、日本政府はシリア高原と呼称するそうだぞ。 今ちいかわってキモいキャラが流行ってるように
Gopherくんもいずれ世界的なマスコットキャラクターになるよ 今マイコン用クレートでメジャーなのってどのあたり?
自分で作るにあたり参考にしたいのだが プロトコルの方のgopherについて調べる人が困るでしょ プロトコルはイーサリアムとビットコインで実現出来ます
この2種類以外は今後不要になります Web3なんて流行るわけねーだろ
スマートコントラクトの開発コスト高すぎ&不便すぎ それに引き換えBorrow Checkerは開発コスト低くて便利だね Rust=Web3 だからWeb3業界の勢いが無くなったら影響受けるよ Etherはイーサーだけど
Ethereumはァセーリアム
日本語読みだと外人に通じないから注意な 3年以内にMoveが天下取るとか言われてるけど本当かね >>503
最新のブロックチェーン言語も知らない奴はここから消えて >>504
あれLibraってまだ生きてんの?
ぜんぜん音沙汰聞かないけど >>499
ありがと。見てみます
どのくらいのさじ加減が使いやすいのかが難しい・・・ >>505
世界に殺された
もし生まれたら恐ろしいことになってただろうしな アレはAptosとして生き残った
大型の資金調達を連発して次の投機の標的になってる std::io::Result<()>
↑の()ってなんすか?
Ok(());
↑の()も。
「空」を意味してるってことでいいんですか? 5つの何かを返す関数なら
return (a, b, c, d, e);
0つの何かを返す関数なら
return ();
と考えてもよく何も返さないこと bevyとFyrox Engineはどちらの方が良いのかな
人気度はbevyな気がするが Rustでプラグインシステム組むならwasiが安牌かな エディタとかツールの機能拡張だよ。
RubyとかJVMとかある程度の動的さを持つランタイムがあると開発楽だけど、GoやRustみたいにスタティックリンク、シングルバイナリが基本になると
たしかにwasmベースで作るのが筋が良いのかねぇ。 クロスプラットフォームで同一バイナリが動いてそこそこ高速で組み込み用途に向いてる
という条件だとLuaかwasm プラグインというよりマクロの実行環境の話だな
Luaやwasmはホストアプリにランタイムを同梱する必要がある Luaやwasmを使うようなスクリプト型(スクリプト言語のことではなくて、上位レイヤのシナリオだけをユーザーに書かせる方式)の拡張って、
よほどホスト側にプラットフォームとしての魅力がない限りは成立しないよ
ホストがスクリプトに対して提供している機能以上のことはできないわけだからな
そうじゃなくて、やりたいのはホストにない機能を追加できるプラグイン機構じゃないの? >>520
Rustでやりたいってことは実行速度を重視してるんだろうし動的リンクしかないだろ
しかしwasmにしてもいいっていうならJavaScriptやらLuaの活用も検討しろ そういえば Rust の proc macro を wasm としてコンパイルしたらどないやという話はあったんじゃなかったっけ?
最終的にどういう結論になったのか追ってないんやが……。
必要な機能は Rust コンパイラの中に全部あってシステムの外とやり取りする必要もないから良い案に思える。 >>525
Luaやwasmからホストの用意した機能を呼び出す形だけでなく
ホストからLuaやwasm側の処理を呼び出す形も実装可能だよ
DLLに比べると相当手間がかかるけど 動的リンクするにしてもABIがunstableだからインターフェースはextern "C"で公開せざるを得ないし
それなりの量のグルーコードが必要になるかと
その辺良い感じにどうにかしてくれるcrateがあるかもしれないけど >>528
そうしたとしてもホスト側に存在しない(ホストからスクリプトに対して公開されていない)機能は使えないでしょ? >>530
ホスト側を経由せずに外にアクセスするのは禁止できたほうが嬉しいことも多いだろ?
俺が使っているソフトでプラグイン機構があるものというと画像ビューアとかメッセンジャとかだが
それほど自由に外の世界にアクセスする必要はないし、不必要ならアクセスさせないに越したことは無い。
(悪意あるプラグインを作り難くなるので。)
制限があるというのと制限を付けられるのは表裏一体なのでそんなの場合によるとしか…… >>529
> 動的リンクするにしてもABIがunstable
あー、そうだったわ
めんどくさいんだった 野良プラグイン入れて環境壊して上等!って時代でもないからねえ。
ある程度、できること制限できるようにしたプラグイン機構も大事な時代よ。
そういう点でwasmがセキュリティとパフォーマンスのバランスが取れていて魅力という層もあるでしょ。 >>530
そりゃ広い意味で言えばどんな機能だってホスト側に存在してなければ使えない
「ホストにない機能を追加できるプラグイン機構」ってどんなものイメージして言ってるの? 今の環境で正しくレンダリングされる10年前に作られたWebサイトは多くない
同様にTauriで作成されたアプリが10年後でも問題なく使用できるのだろうか Tauriはバックとフロントが明確に分離されているからOS標準ブラウザに変更があっても修繕はしやすそう
Macとかだと突然仕様変えてきそうで怖いな Rustでライブラリをどうやって選定してんの?
crate.io見て人気のを選んでんの?
GETだけのためにhttpclient使おうとしたらtokio入れて使えとか全然意味わからんしコンパイルしたら
これを使うには2018使えと2022使えが出てくる…
他のに変えても変わらず
GETなんてコピペ産業で実現させてくれよ
use
初期化
GET
これで終わらせてくれ >>539
まあ今はそういう人向けの言語じゃないからね
とりあえずreqwestのblocking clientでやってみて合わなそうならあきらめろん crate.ioにwebclient一覧が並べてあるけど結局最近のダウンロード数見て判断なんだろうなと
どれもtokio使ってるしCurlコマンドみたいに一発でGETやPOSTって感じでもない
tokio必須と言うことは標準でasyncライブラリの完成度が低いんだろうけど
憶測が当たってるかどうかもよくわからない >>542
Rust は標準ライブラリの中に非同期ランタイムを持ってない。
言語として非同期を扱えるようにしつつ具体的な部分は外部のクレートに任せられるように
分離に成功しているという意味では十分に完成度は高いとも言える。 >>539
簡単これだけ
#[async_std::main]
async fn main() {
let uri = "https://httpbin.org/base64/SGVsbG8sIFdvcmxkIQ==";
let s = surf::get(uri).recv_string().await.unwrap();
assert_eq!(s, "Hello, World!");
}
Cargo.tomlの[dependencies]に適当に
async-std = { version = "*", features = ["attributes", ] }
surf = "*" 簡単に使いたいなら、非同期じゃなくて同期版のhttpクライアントライブラリ使いなよ Goを素直に使っとけ
標準ライブラリでそのままできる上に非同期もGoroutineを使うだけ
テスト用のライブラリも用意されてるからクライアントサーバーもそのままテストできる >>546
Goなんていうものは不要
Rustで簡単に使える 標準ライブラリでHTTPクライアント・サーバー・テスト・非同期を全て統一的に扱えるってのはかなり強みではある
Rustはランタイムコストをゼロに近づけるためライブラリ化しているが、それは必ずしも利用者にとってメリットがあるわけではない
あくまでもOSやドライバなどを作る上でランタイムコストを削らないと適さないからそうなっているだけ
>>539 みたいな人にはまず用途を考えた上で高レイヤーのプログラムを作りたいのであれば素直にRust以外の言語を使うことをお勧めする >>548
あまりにも狭い視野と酷い誤解をなさっているようだが
ウェブ関係はRustのメリットが十分にある分野で実際にRustで利用が多い分野 複オジ相手にするのは隔離スレか実質隔離スレの次世代スレだけにしろ >>548はいつものRustアンチのキチガイかな
RustはOSやドライバ用と嘘をついてそれ以外なら他の言語を使うべきと誘導する書き込みがそっくり キチガイ同士ここ以外で仲良くやっとけよ
邪魔なんだよ 次世代スレの方もワッチョイ付ければ例のバカが寄り付かないことがほぼほぼ実証されつつあるので
あとは過疎を恐れず移行すれば万事解決です structに不変なフィールドを持たせるにはどうしたらいいのですか?
const定数ではなく、インスタンスごとに初期化時に値を設定したら、その後は変更不可能。
他のフィールドは変更可能でも。 >>557
直接的にメンバに指定を付けることは出来ない。
Rust のアクセス制御はモジュールが基本単位になっていて、
「メンバに pub が付いていない」「そのモジュールの中でメンバを変更することがない」ならば変更不可能なメンバになる。 >>560
言語としてのRustにはピクリとも興味がわかなかったが
なんだか急にRustに興味がわいてきたぞー VSCode + CodeLLDB + LLDBでデバッグしているのですが、ポインタに関して見方がよくわかりません
Borrowed pointer typeの参照先の値ってデバッガ上でどうやったら見れるんですか? 今の時代ってcc++rustなんて、低レイヤーをやってる人以外は不要だな
Java Script全盛のこの時代にいちいちコンパイルするなんて面倒で仕方ない この言語開発した人、Swiftにいっちゃったみたいだけど追い出されたの? 確か燃え尽き症候群で自分から離れたんじゃなかったかな ジャバスクリプト全盛の時代にネイティブこんぱいらなんて
不要だろ。
jsでカーネルのラードンをつくる猛者まで出てきた Arc<HashMap<T1, T2>>みたいにした場合って、どの範囲でスレッドセーフになるんですか? 範囲はHashMap全体たが
Arc単体で提供するスレッドセーフはimmutableな共有所有のみ
その例だとHashMapは読み取り専用になる
他を要求するなら他と組み合わせる
まずArcは置いといて単独所有の時
整数やブールならAtomicXxxでスレッドセーフ
一般的な型ならMutex<T>
読み取り同時複数ならRwLock<T>
それぞれコストが異なるので使い分ける
その上で共有所有ならArc<.....>をそれらの上に被せる もちろんTがSync+Sendの時のみ
Arc<T>はSync+Sendとなる 条件を満たせなければコンパイラが指摘してくれるところがRustの良さ
間違えていても安全でなくてもコンパイルが通ってしまい実行時に酷い目に合う従来の言語 >>578
思い込みで誤読しているあんたが馬鹿っぽい
>>576にはそんなこと書かれていない >>578
うちの会社にもいるわ
ビルド出来たってドヤ顔のバカ
そんなものは、ある程度の言語の知識があればいいだけ。 デバッグスキル0の奴がビルドだけでOKとか思いたがるんだわ。 急に書き込み減ったけどもう飽きられたの?
Scalaのときもそうだったけどエンジニアがこういう読みにくい言語で現場を遊び散らかして負債だけ残すの何とかして欲しいわ ?の意味とか;の違いとか、すぐに調べられないからバッドノウハウ化しているよね。FAQとかダメダメだし。
せめて検索性に配慮して記号を決めればな。?::くらいにしても問題ないだろうに。 ピークを過ぎた感はある
Scalaで遊んでたのはDDDとか高レイヤの好きな意識高い系が中心だったからまあそこまで酷い負債にはなってないけど、
その点Rustの負債はタチが悪そうだな Amazonがプログラミング言語「Rust」を使っている理由
https://japan.zdnet.com/article/35183866/
Amazon Web Services(AWS)は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。
AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100%を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service(S3)」「Amazon Elastic Compute Cloud(EC2)」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。
「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50%削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。 >>590
そういう基本的なのはチュートリアルに書いてあるんだから何をあらためて検索する必要があるっていうんだ? >>590
文法は場当たり的に学ばないで初学者向けドキュメント読んだ方が良いと思うけどそれは置いておいて、
rust operatorでググって出てくるこれ参照して演算子の意味調べてもう一度ググれば良いのでは
それすらめんどくさい?
https://doc.rust-lang.org/book/appendix-02-operators.html question markとかsemicolonで調べればいいんだよ 例えば
question mark site:doc.rust-lang.org
で検索すれば必要な解説がすぐ見つかる >>593
公式に「チュートリアル」てあったっけ?
THE Book読めということかしらん?
>>594
Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど……
>>595
公式の解説出てこないんだけど、公式には説明無いんかね? >>596
おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。 >>597
エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと
少なくとも記号よりは検索しやすい 所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。 >>597
> THE Book読めということかしら
せやで。
まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。
常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、
エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。
なるべく一発で検索できたほうが便利というのはわからんでもないが、
演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば
どうせ色々と見るはめになる。 >>600
所有権チェックをなくすってどういうこと?
referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと? コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理 ビルドしなくてももっと気軽にわかるようにしろってことか?
linterの領域外れてる気もするが 細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。
でもなー、そういうことすると整合性がとれてないままの未定義コードが世に溢れてしまうのは確実だろう。 所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ
後から直そうとか思うと結局全部作り直すはめになるから
一度チェックなしモードとかで作っちゃうと永遠にそのままだろうね >>592
そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。 >>601
the book読めというのはさすがに初心者殺しだと思うけどなぁ。
公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん? 学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう >>609
えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を
用意してくれるなんてスゲー親切だと思うが、何が不満なんだ?
(俺自身は英語あんまりわからんので日本語訳を読んだ。) >>609
the bookは初心者のためのもの
Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている
?は自分でエラー処理を書くようになり、
さらに自分の関数でResultなどを返すようになり、
そこでErr(e) => return Err(e)などを書くようになり、
そこでのショートカット表現として必要になるものだから
the bookでも同じ順で学べる
?をいきなり調べたい時や詳細を知りたい時は
the Rust referenceを開いて🔍をクリックして
question markと打てば該当ページに辿り着く 今時、ネイティブ吐く必要なんて全くない
tsでもvscのようなソフトが作れるんだし。
ユーザーランドではネイティブはもはや不要だろ vscはコア部は全部C++だけど。
そのうえに薄くjs乗ってるだけやがな。 Tauri (Rust) vs. Electron (C++)の戦いの結果…
> Electronの代替を目指す軽量なRust製フレームワーク「Tauri」
> https://www.publickey1.jp/blog/22/electronrusttauri.html
>
> Electronはフロントエンドの基盤としてChromiumを組み込んでいますが、
> Tauriでは代わりに各OSが備えているWebViewの機能を、抽象化レイヤのwry経由で呼び出すことで、
> クロスプラットフォームを実現しつつChromiumを不要にしています。
> フレームワーク内にChromiumを組み込まないことでセキュリティも向上すると、Tauri開発チームは説明しています。
↓ 「マジ?!」と思っていたらマジだった!!
>開発フレームワーク「Electron」に複数の脆弱性
>https://news.mynavi.jp/techplus/article/20220818-2426640/
>
>Electronは、HTML5やCSS、JavaScriptといったWeb技術を用いてデスクトップアプリケーションを開発することができるフレームワークで、
>Microsoft TeamsやVisual Studio Code(VSCode)、Discordなどの人気アプリケーションでも利用されている。
>今回のElectronの脆弱性に関する発表は、米国で開催されたサイバーセキュリティカンファレンス「Black Hat USA 2022」の次のセッションで行われたもの。
>研究チームがElectronを使用して開発された20のアプリケーションを調査し、そこで発見された複数の脆弱性について報告した。
>発見された脆弱性の一例としては、以下が挙げられている。
>・VS Codeにおけるリモートコード実行の脆弱性
>・Discordにおけるリモートコード実行の脆弱性
>・Microsoft Teamsにおけるクロスサイトスクリプティング脆弱性
>・ChromeのCSP(Content Security Policy)バイパスの脆弱性
>・V8のリモートコード実行の脆弱性 >>621
そうなん?わりとネイティブが薄くてTSが主体だと思ってた。 GUIがtsの時点でお察し
やたらとモッサリしてんじゃん --emit asmで吐かれるアセンブラリストのフォーマットの資料ってどっかにある?
gas系っぽく見えるけどちょいちょい判らないのが・・・ --emit=asm -C "llvm-args=-x86-asm-syntax=intel”とかで指定できるみたいよ VScodeがもっさりは感じたことないな
ネイティブのVSのほうが重すぎ 関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの? >>629
隔離スレでドヤりたいというユースケース >>628
一旦変換すりゃいいだけなんじゃないの。 知らんけど。 例えばこんなの
fn func(x: u8, y: u8) -> u8 {
let x32 = x as i32;
let y32 = y as i32;
let z32 = (((x32 - y32) * 170) >> 16) + y32;
return z32 as u8;
}
4行使うのは冗長かなーと思わなくもなく・・・
テンポラリ変数の名前を考えるのもちょっと面倒だし >>633
シャドーイングできるからテンポラリの変数名は不要だよ
let x = x as u32;
でいい >>633
行数短くしたいだけなら
fn func(x: u8, y: u8) -> u8 {
let (x, y) = (x as u8, y as u8);
(((x - y) * 170) >> 16) + y) as u8
}
とは書けるけどやってることは全く同じだしこれで期待に応えられてるかは分からん >>635
2行目間違えた
as i32 に読み替えて >>633
その例は手動で最適化すると
fn func(_x: u8, y: u8) -> u8 {
y
}
それはともかく
行数を節約したいという間違った価値観を捨てることをおすすめ ホントだごめん訂正
fn func(x: u8, y: u8) -> u8 {
y - (x < y) as u8
} 結局u8で返すなら
途中でi32使わずとも
工夫するとu8のままだけで算出できちゃったりするわけか 逆方向にシフトした場合は?
そんな用途があるのか知らんけど >>641
それはu8部分の下位8bitが常にゼロとなって
足しても引いても影響ないかな スタンダードな書き方みたいなのはないのかな
なら>>634で行こうと思います
あと>>633は右シフトを間違えていました
16ではなく8です Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの? もちろん
そして依存しないよう3種類用意されてる
assert_eq!(0x01020304, u32::from_be_bytes([1, 2, 3, 4])); // big endian
assert_eq!(0x04030201, u32::from_le_bytes([1, 2, 3, 4])); // little endian
assert_eq!(XXX, u32::from_ne_bytes([1, 2, 3, 4])); // native endian native endianというのは初めて聞いたのですが、これはどういうものなのですか? この場合 >>644も書いているようにコンパイルターゲット環境のエンディアンのこと
特にターゲット指定がなければ自分の使っているPC環境で通常はx64などlittle endianになりますが
そこでleと指定してはダメで環境に応じて適切に対応させるためにneを使います
一方でAPIなどでエンディアンが指定されてる時は指定通りbeかleを使います >>645
サンクス。u32とかにはfrom_leとかあるみたいですね。こっちの方が使う機会は多そう
デフォルトのバイトオーダーを変更したり、変数やフィールド単位でバイトオーダーを設定する
みたいな芸当は流石に無理なのかな・・・ググったけどそれっぽい情報は見つけられなかった >>648
操作に最適なバイトオーダーは使用CPUで決まるネイティブエンディアン
だから原則としてネイティブエンディアンのみでプログラミングする
例外として外部とのやりとりなどエンディアン指定がある時はその境界で変換 >>648
内部的に色々な表現を有りということにするならやりたい操作を個別に定義するしかないよ。
でも普通はそんな煩雑なことをしたくないから
内部的には一環した表現を使って必要な変換は入出力のみというのが一般的な構成だし、
言語やライブラリも基本的には一般的な構成に倣っている。 >>648
変数やフィールドのメモリ上の表現が特定のエンディアンにしたいのであれば、
#[repr(C)]
struct BeU32([u8; 4]);
みたいな構造体を用意して
impl Be32 {
fn get(&self) -> u32 { u32::from_be_bytes(self.0) }
fn ser (&mut self, v: u32) { self.0 = v.to_be_bytes(); }
}
こういうアクセサを実装すれば良いかと
何の役に立つのかはよくわからないけど、特定のエンディアンでシリアライズされたデータにそのままアクセスしたい場合とかに便利なのかな RustをOpenMPIに対応させるようなプロジェクトってありますか? OpenMP なのか Open MPI なのかどっち 知りたいのはOpenMPIの方です
ググるとOpenMPIとOpenMPを勘違いしたと思われるRayonを紹介する記事が出てきたり、OpenMPがらみのサイトが出てきたり、なかなか状況が分かりません・・・・ MPIはHPC以外では使う必要ないです
機械学習でも有用だとは思いますが
そもそもフレームワークが対応していないから
全部自前で作ってるような人以外は必要ないです Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは 良くありがちな奴だと思うけど
struct ARGB32 {A: u8, R: u8, G: u8, B: u8,}
みたいに書くとスネークケースじゃないと警告が出るけどどう書くのがRust流なの?
これ小文字にしちゃったら少なからず可読性が落ちるよね #[allow(non_snake_case)]
しかしフィールド名だけ小文字にすれば不要
struct ARGB32 {a: u8, r: u8, g: u8, b: u8,}
そして可読性が落ちると思わない 構造体名もCamelCaseでArgb32とすべきかな 識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。
略語を使わずに書くとこうかね?
Color<T>{alpha: T, red: T, green: T, blue: T}
CMYはどうなるとか言い出すやつがいると面倒そうだけど。 enum Color {
Red,
Blue,
Green,
RGB(u32, u32, u32),
HSV(u32, u32, u32),
HSL(u32, u32, u32),
CMY(u32, u32, u32),
CMYK(u32, u32, u32, u32),
} 最低限ガイドには従った方が良いと思う
https://rust-lang.github.io/api-guidelines/naming.html
acronymはひとつ単語として扱うとあるから Rgb とか Argb とすべき
あとは適当なグラフィック系ライブラリの実装を見て真似してみたら良いのでは
規約に従ってないライブラリも多いけど
そもそも既存crate使えば独自にArgb型定義する必要もなくなるかもしれない API ガイドラインってことは、 API として公開しない (内部的な) 名前は雑でいいってことだよね。 >>661
個人的にはこっちの方が好きだけど
規約的にダメなら仕方ない >>666
非公開部分を将来公開APIにする可能性や、自分以外の誰かがソース読んでパッチ作ってくれる可能性考えると、
最初から内部も規約に従ったものにしておいた方が良いと思う
そもそもひとつのプロジェクトの中で公開部分と非公開部分で異なる規約混在するのも嫌では mozillaは公開できない関数名を使ってオープンソース化が数年遅れた過去があったなぁ。 >>669
94年初リリースで98年ソース公開で
数年遅れるとは? CreateFileW in windows::Win32::Storage::FileSystem - Rust
ttps://microsoft.github.io/windows-docs-rs/doc/windows/Win32/Storage/FileSystem/fn.CreateFileW.html
とかAPIガイドラインもクソもないけど名前だけRustに寄せたところでリファレンスドキュメント(MSDN)との差異が
拡大するだけでメリットはほとんど無いような JPEG、MPEG、PNG、HEVC・・・すでに略されている物をありがちな命名規則で書くと判りにくくなる >>663
その方向でやってみます
というかこの構造体をArrayに沢山詰めようとすると初期化が難しいのか。どうしようか悩んだ結果こうしてみた
#![no_std]
const LEN: u32 = 640*480;
let mut bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};
bitmap[0].red = 0xFF;
アセンブラリストを見る限りは問題なさそう acronymを全部大文字にするか先頭だけ大文字にするかってそんなに大きな問題かな
一貫性のあるルールに従っていれば書き手や読み手として混乱することもないと思うんだが Ipv4なんて一瞬なんのことか分からんかったな
結局慣れで、一貫性以上に価値のある好みなんてのはない >>676
その一貫性が崩れるのがいやなんだろ。
ドキュメント・コメントでは全部大文字なのにコードでは先頭だけ大文字とか。
慣れの問題だが、今まで/一般的 に全部大文字で慣れてるものをこの時だけ先頭大文字に慣らせというのは抵抗感あって当たり前。 >>676
問題の大小なんて誰も言ってない。
今までの慣れ/一般的な表記 を置き換えるのは抵抗感あるって話。 命名規則を利用する目的は可読性や開発効率の向上などのはず
一般的な表記から外れるのであればそれなりの理由が必要であろう
「命名規則に従ったから」では「目的より手段を優先している、合理性がない」などと
突っ込まれてもしょうがない JavaScriptのアイツは
XmlHttpRequestと命名されるべきだったのか?
XMLHTTPRequestと命名されるべきだったのか? eXtend Markup Language Hyper Text Transfer Protocol Request 完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、
LCD TV、nVidia、iOS IoT Hubなんかをどう表記するかとか変数名ならどうしようとか考えるのめんどいから
表記の慣例とか無視して全部キャメルケースにしちゃうな ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった Rustすれのレベルの低さにガッカリ
Python質問すれとかみたいに和気あいあいとしてない殺伐にドッキリ >>675みたいに書いた場合
>let mut bitmap:[u32; LEN] = [0; LEN];
のmutが余計だと警告が出る。この場合実際に確保されるメモリ領域は書き込みも出来るスタックフレームだろうし
mutを取っても動作上は問題ないと思うけど、mutがない領域に書き込むことになりプログラムの意味としては誤っている
参照先を強制的に書き換えるようなコードを書くと、とコードと警告と動作のミスマッチが起きる気がするけど
なんか上手い書き方はないのだろうか
この辺の低レイヤーの用途で参照先を書き換える話ってBookのReferenceやUnsafeあたりにもそれっぽい事書いてないし
どこを見たらいいのか判らない >>675
ARGB32にDefault実装して
let mut bitmap : [ARGB32; LEN] = Default::default();
とするのが良いかと
repr(C)がついてない構造体のメモリ上での表現がどうなるかは保証されてないから元のコードが意図通り動作する保証はないと思う >>687
[T; N] は N <= 27 までしかDefault実装されてなかったからこのコードじゃダメだった
こっちならOK
let mut bitmap: [ARGB32; LEN] = std::array::from_fn(|_i| Default::default()); 最後の手段のtransmuteは安易に使うものじゃないと思う >>687
すみません。構造体にはrepr(packed)を付けています。u8がパディング無し4つ並ぶはず
repr(C)だとCと同様にパディングされる可能性が出てくると思うのですが
>>688
CloneとCopyを付ける方法に関してはどのような動作になるのか確信を持てていないです
原則コピーになるという情報は出てきますが、画像のバッファだし原則参照で必要なときだけ
コピーしたいです(すでに初期化とは別のところで問題になっています。参照とコピーの
切り替え方法が判らない) >>686
最初に定義した変数bitmapはmoveしてるだけだからmutは余計でいいと思うけど? >>692
自分の理解があっているか不安なんですが、mutを付けずにletで宣言すると書き換わらない値として
書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか?というのが心配な点です
言語仕様上mutを付けない宣言でも必ず読み書き可能な領域に配置されるというのであればそれでかまわないと思いますが
とりあえず手元のx64向けのコンパイラではmutを付けずともスタックフレームに配置されるようですが
組み込み向けなど他のコンパイラでも同様の動作を前提として問題ないのか判りません
古いバージョンのBookにはスタックやヒープの解説があったようですが
ttp://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/the-stack-and-the-heap.html#:~:text=Memory%20management&text=The%20stack%20is%20very%20fast,explicitly%20allocated%20by%20your%20program
最新版にこのページはないような・・・しかも
>Rust ‘stack allocates’ by default, which means that basic values ‘go on the stack’.
だとRAMを節約したいからROMに配置する実装もあり得ると読めなくもない let bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<_, [ARGB32; LEN]>(bitmap)};
これでいいってことじゃない?
一個目のbitmapは実際書き込んでないからmut不要
二個目のbitmapは変数名同じだけど一個目とは別の変数で、こっちは次の行で書いてるからmut必要 あぁ言いたいことは分かった
確かにtransmuteしてるからバックエンドの挙動によっては変なことになりうるかもね
ただそれは別にmutをつけても保証はされない気がする >>691
repr(packed)を指定した構造体のフィールドへのアクセスは未定義動作を引き起こす可能性があるからrepr(packed)は基本的には使わない方が良いよ
https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacked
確かにrepr(C)やrepr(Rust)はパディングされる可能性があるけど、フィールドのアラインメントを適切にするために必要なものなので
パディングが問題になるならフィールドのメンバーの順序やサイズを見直すか、フィールドの値を読むのに std::ptr::read_unaligned を使う必要があるよ
https://doc.rust-lang.org/std/ptr/fn.read_unaligned.html
read_unalignedのドキュメントにも書いてあるけど、アライメントが不適切なフィールドへの参照を作るのすら未定義動作になるという落とし穴もあったり、
repr(packed)な構造体の取り扱いにはいろいろと注意が必要になるので、本当に必要なとき以外は使わない方が良いよ
あと、repr(packed)はrepr(packed, Rust)と同じ意味になるので、構造体のフィールドがメモリ上でどのような配置になるかの保証はないよ
フィールドの定義順とメモリ上での順序を同じにしたいのであれば repr(C) または repr(C, packed) と指定する必要があるよ
いずれにせよ今回は全てのフィールドがu8だからrepr(C)でパディングが挿入されることはなく
無駄にメモリを消費することもないよ
どうしてもパディング挿入が心配なら mem::size_ofやmem::align_ofを使って構造体のサイズとアライメントに関するアサーションを加えるのが良いと思う >>693
let a = ...;
let mut a = a;
みたいに書いた場合、一個目のaと二個目のaは別の変数扱いでそれぞれ個別に領域が割り当てられるよ
二個目のaに格納されるのはaの値で、ポインタじゃないから一個目のaが書き込み不可な領域に格納されていたとしても
二個目のaのために割り当てられた読み書き可能な領域に一個目のaの値がコピーされるような動作になるはず
最適化によって一個目のaと二個目のaが同じ領域を使い回すようになるかもしれないけど、二個目のa定義後はその領域に対する書き込みは可能なことが保証されてるはず
transmuteを呼び出した場合も同じで、
transmute(a) という呼び出しをした場合transmuteに渡されるのはaの値なので、二個目のaの定義後は問題なくaに書き込めるはず
ただし、transmuteに&aを渡して&mutに変換するみたいなことをすると未定義動作になるから注意は必要
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
> Mutating immutable data. All data inside a const item is immutable. Moreover, all data reached through a shared reference or data owned by an immutable binding is immutable, unless that data is contained within an UnsafeCell<U>. >>693
>mutを付けずにletで宣言すると書き換わらない値として
>書き込めないメモリ領域(例えば.textセクション)に配置されたりしないのか?というのが心配な点です
しねーよ。
組み込みだろーがそれは変わらない。
letついて束縛変数といわれようが変数は変数。 今はしないけどそうなるような最適化は禁止されてないのでは コンパイル時に値が確定してないとtextセクションに書けないでしょ そっちは定数でconstだしそうなる
letはあくまでもimmutableな変数であり定数ではない コンパイル時に確定するような式なら最適化でありえるんじゃないの? どのように最適化されようが
constではなくlet x = ...ならば
let mut x = x; とムーブして書き換え可能
これは言語のレベルで保証される
そしてそのように使うならば最適化も無駄なことせずにtext segmentでなくdata segmentに置くだろう CloneとCopyについて
let mut bitmap:[u32; LEN] = [0; LEN];
let mut bitmap:[ARGB32; LEN] = unsafe {core::intrinsics::transmute::<[u32; LEN], [ARGB32; LEN]>(bitmap)};
と
#[derive(Clone, Copy, Default)]
&
let mut bitmap:[ARGB32; 16] = [ARGB32::default(); LEN];
で読み書きを
bitmap[0].red = 0x80;
let x = bitmap[0].red;
bitmap[0].green = x;
としてみたけど出力された読み書き部分のコードは同じでした。もっとでかい構造体じゃないとムーブかコピーかの区別は出来ないのかな
>>696
マジか。Rustでもパディングの問題がつきまとうのか。でも
>Accessing unaligned fields directly with e.g. packed.unaligned is safe however.
って事は.redとかでアクセスする場合はコンパイラが良きに計らってくれるのでアクセス境界の問題は起きないって事かな?
画像データのバイトやビットの並びなんてすでに決まっていてプログラムはそれに合わせるしかないのが普通でしょうし
勝手にパディングされても困ります
実は並行してCでも書いているんだけど構造体のパディングの制御は処理系依存らしくて移植性を優先すると
データは整数の配列で持って論理演算とシフトで分解、構築するコードになってしまってます どの言語でも同じ
Rustでも&mutでtransmuteしてもendian依存は避けられないな
let mut x = 0x01020304_u32;
let a = unsafe { std::mem::transmute::<&mut u32, &mut [u8; 4]>(&mut x) };
a[1] = 7;
assert_eq!(x, 0x01020704);
とlittle endianでは7の位置はこうなる このスレでよく出てくる μt ってなんなん?
音的に mut をそう書いてる異常者がいるだけかと思ってるんだけど、なにか別の意味を持った概念や機能だったりするの? 自分も思ったけどブラウザによっては & mut がそうなるみたい >>708
なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。 例えば
pixel.alpha = in[0].alpha;
pixel.red = in[0].red / 2;
pixel.green = in[0].green / 2;
pixel.blue = in[0].blue / 2;
out[0] = pixel;
と
red = 0xFF & (in[0] >> 16);
green = 0xFF & (in[0] >> 8);
blue = 0xFF & in[0];
red /= 2;
green /= 2;
blue /= 2;
pixel = 0xFF000000 & in[0];
pixel |= red << 16;
pixel |= green << 8;
pixel |= blue;
out[0] = pixel;
ではだいぶ見やすさが違うような >>704
パディングというかメモリアクセス時のアラインメントについてはCPUの仕様だから言語関係ないよ
x86がunalignedなアクセスについてゆるゆるだから忘れられがちだけど雑に書いたプログラムをarmで動かしたりするとクラッシュする
今回はu8へのアクセスだからさすがにパディング入れられることはないと思うけどね >>712
シフト処理など隠蔽してくれるアクセサメソッド用意したらだいたい同じような読みやすさになるのでは Rust固有じゃないけど移植性を改善する方法に1バイトずつ処理するという手があるけどこの実装は、今時の32bitや64bit環境で
相応にデバフが入るんですよね。MSVCでも8bitロード×8を64bitロード×1に最適化してくれなかったし
>>713
そこを抽象化するのが処理系の仕事では。いまだに構造体でパース・・・みたいなコードを見かけるし
>>714
読みやすさは改善しても今度は速度にデバフが入るような。こういうケースでアクセサメソッドを利用したとして
全てインライン展開&最適化されますかね?一つでもコールやブランチが残ったら速度が結構落ちるだろうし >>707
色んなブラウザで見てみたけど
&mut (分けて書くと & mut )が μt と表示されるのはバグってるchmateだけっぽい >>716
ほー、chmateはワザとunescapeしてるのか?
5chがUnicode文字表示できるようになったんだし、そういうのはもう余計なお世話だな HTML等の文字参照を処理する場合でも
μt (= & m u ; t )が μt となるのは正しいけど
&mut (= & m u t )が μt となるの間違いだからこれはバグと思われる 文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
良し悪しは別にして html を扱うブラウザではそれほど珍しくはない
個人的には余計な事すんなとは思う これはmateのバグです
& x y z ; とセミコロンで終わる場合のみその部分を文字参照として解釈するのが正しいです & amp ; amp; を空白なしで書き込んだら & に変換されてしまった
実体参照複数回展開しているのかな
& ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね
ガワ作って入出力を完全に外部に出さないとコードがみんな消えてしまうのは不便です
最適化レベルによる変化とか全然確認出来ないし ちょっと意味がわからない
こうなるはずだから困ることはないと思うけど
・最適化によってRustが定めている意味が変わることはない
・pub宣言しているものは中で呼ばれていなくても単体コンパイルで消えることはない
・pub宣言されていないものは中で呼ばれていなければ今後も誰からも呼ばれないためwarningが出て消える genericな関数だと呼び出し元がないとコード生成されないとか? その場合でも実際に使う型々でtestを書くだろうからcargo testで確認できるでしょ >>726
ありゃうちの環境の問題か。pub付けただけじゃ関数丸ごとなかったことにされる
pub extern "C"でRust外の入出力にしてようやく消えなくなる
もうちょっと調べてみる >>729
ちなみにターゲットはbinと(r)libのどっち?
binならpubでも消えるかも >>730
変更してみた。staticlibだとpub付けても消える。rlibなら消えないようだ
とりあえずrlibにしておいてある程度形になってきたら変更すればいいか
コード自体はどっちでも大差ないだろうし [u32; LEN]と[ARGB32; LEN] の件、アラインメントが違うからtransmuteの時点でUBだけど Tauriで動画プレーヤー的なのを作るサンプルってどっかにある?
ただ再生するデータは既存のmp4ファイルなどではなくRustプログラムから渡したい
あと再生、停止、コマ送り、シークなどの基本的な機能は実装したい TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ?
そして既存のWeb技術を活かせるのがTauriの利点だろ?
そうならば例えばhls.jsなど既存の好みの動画配信再生フレームワークを使えばいいだけじゃないか?
Webサーバーサイドやったことあるならばフロントエンドからファイルに見えているものは本物のファイルである必要はなくサーバーサイドが算出していれば十分だろ? >>734
>HLS
ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない
特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど
再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中
ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか?なんか無駄に実装量が増えるけど その手のやつでオーバーヘッド減らすならOS毎にネイティブ実装するしかなくない? なんとかtauri使うにしてもJSやらWASMやらで動画レンダリングするようなもの作らないとだめそう 実装を追加させない方法ってありますか?
別個に渡されたふたつの型が同じであるという制約を付けたいという目的で
以下のようなトレイト Same を定義した場合、実装を追加できてしまうと破綻してしまうので、
なんらかの方法で制限できるだろうかという疑問です。
pub trait Same<T> {}
impl<T> Same<T> for T {}
// 使用例
pub fn foo<T, U>(x: T, y: U)
where
T: Same<U>,
{
}
ちなみに目的を上述しましたけども実際には目的というよりは題材です。
つまり具体的な用途は考えておらず、質問はあくまでも「実装させない方法があるかどうか」です。 trait Sealed {}
pub trait Same<T>: Sealed {} ふたつの型が同じという制約を付けたいなら
TとUじゃなくTとTにすればいいじゃんか >>738
達成したいことが特にないらしいからなんとも言えないけど enum を使っても近いことはできるんじゃないかな。
enum Same{SameA(型A),SameB(型B)}
みたいにしてやれば、Same 経由で扱う限り実装は増やせないぞ。 >>739-740
実装を追加させないテクニックのひとつとして有用ですし紹介はありがたいです。
しかしそれだと Sealed を実装した型だけにしか使えず、 >>738 で示したような汎用的に型を比較するトレイトには使えないですよね。
この Same のように機能するトレイトに実装を追加させないというのは前提と考えて欲しいです。
>>741
そういうレスが付くことを避けたいから最後の文をつけたつもりなんですが……。
Rust の初心者として様々な言語機能を理解したいという立場で疑問に思った部分を抜き出し、
説明のために前提条件を設定したのであって、前提条件の部分自体は解決したい課題ではないです。
いわゆるXY問題というものの存在は承知しておりますので
解決したい大元の問題を示さないというのがモヤモヤするだろうなというのはわかります。
わかりますが、大元の問題というものはありません。
この範囲で完結するパズルだと思ってください。 impl Foo for Tが存在する時点で他の型にFoo実装しようとするとconflictしなかったっけ fundamentalな型に一通り実装しておけば良さそう fundamental云々はcoherent ruleの話でconflictとは関係なかったわ なるほど、 C++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。
&T とか &mut T とかも先に実装しておけば追加の余地をなくせると。
&T とか &mut T とか以外にどういうのがありえますかね? >>750
ありがとうございます。
言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。 今のところデバドラだけという話だけど
基幹部分の新実装をRustで作りましたという
人が絶対現れるからそのときどうなるだろ 誰もvoldemort typeの名を呼ぼうとしない MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて
非GC言語が必要な状況ではRustを使うべき時だ」ってツイートしてるけど
Visual StudioでもRustが最初からパッケージングされてるようになるのかな https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に >>756
MSがRustの開発環境に投資するならVSCodeのエクステンションじゃない?
いまさらVSに対応言語を追加する気はないでしょ
どう考えてもWindowsユーザーは少ないだろうし >>756
マーク・ルシノビッチ氏、Microsoft AzureのCTOなのか。
インサイドWindowsにはお世話になったわ。 Iteratorに対するIntoIteratorのように
Futureに対するIntoFutureということか
しかも.awaitに対して自動適用だからもっと効果が大きいか
非同期を返すビルダーに対してFutureを返させるためのビルド完了指示メソッド呼び出しが不要となる Rust analyzerが優秀過ぎてMSが入る余地なさそう
PythonがMS Storeから落とせるみたいにインストールが楽になるとかならありそう
VSに導入されたらそれはそれで面白いんだけど.Net言語との連携が強化されないと旨味がないな 既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとなる可能性もあるので意味はある >>758
VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな >>762
書き方悪かったわ
Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった
GoのCGoみたいな仕様だったら色んな意味で面白いと思う rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか?
編集を破棄して保存前の状態にしたい時があるので、できれば自動で保存したくないのです
Vim系プラグイン等を入れていれば無限に戻せるのかもしれないものの、Vimが使えない身としては困ってしまいます >>766
ああそれならありだな
まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな C#も.Netも全く興味ないので知らないが
PythonでもJavaScriptでも何でもRustで作ったライブラリなどを簡単に呼び出すことができる仕組みがそれぞれ整えられている
既存のものの置き換えは無意味だが新たに作られるものはRustで書くことが増えている repr(C)でCのフリしたRustじゃなくて、俺はありのままのRustが動いている世界線が見たいよ >>769
でも、破棄ならコミット後の状態にも戻せるぜ? >>771
ABI安定化するまではFFIでextern "C"は避けられないよ >>773
そんなことすべきでない
自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト
外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい 双方でマーシャル/アンマーシャルが必要になって無駄だよね 対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない
他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない >>774
pubなitemのABIに最適化関係ある?
なんかと混同してない? もしかして repr(Rust) のこと言ってる? Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう
結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの? >>781
dylibの場合pubは大いに関係あるよ ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ >>782
むしろCは決まってるの?
決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな 近年になって作られた高速リンカ mold の作者の話でも、
文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。
C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし
どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、
結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が
解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。 CはCPUベンダーが呼び出し規約を文書化してるよ
moldの話はELFやリンクに関連する話では
確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ?
>>786
呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ >>789
そこでいう実装依存ってプラットフォームごとの差違のこと?
それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの? >>791
その段階ではあまり曖昧さはない。
リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、
その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。
アーキテクチャによって扱いを変える必要がある場合もあるし。 >>792
コンパイラがリンカに渡す情報って統一規格があるの? >>793
別に統一されちゃいないがELFとかPEとか じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは? >>795
ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。
ただ現実には全てが正しく実装されているわけではなく、
場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。
仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。
そういう歴史的負債がどんどん積み重なってわけわからんようになる。 元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ
LLVMがよしなにやってくれるのでは ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね? Option<NoneZeroUsize>などを使えば
IDやカウンタなどの用途でOption<usize>などを使っていたものを
半分のメモリサイズで済むようになるの? >>799
任せてください。符号ビット省略しておきますね Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに
Microsoftはダメなの? try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ 言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは 正直LinuxにRustなんて辞めればいいのに・・・ Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの
作り方の解説とかどっかにある?例えばJPEGやPNG、MP3、AVIとかを扱うようなコードを想定
関数単体のテストはともかく、結合した状態で全てのコードを動かそうとすると入力パターンがどんどん増えるし
パディングビットにゴミがあっても問題ないかなどを考慮しだすと更に膨れあがる
さらに歴史が長いフォーマットだと、そもそも仕様をどう定義するのかという点が問題になることもあるし >>803
別に独自拡張とか入れてないだろ
コンパイラへの機能追加は全部本体に入れていてnightlyで使える状態だし
Linuxカーネル向けのallocなんかは単にライブラリであって言語自体がforkしてるわけではない >>807
メディアのエンコーディングのことはさっぱりしらんけど、一般的には結合テストじゃなくて、単体テストでパターンは網羅すべし
できるんならやればいいけど、結合テストで入力の網羅なんて普通はやらない >>812
条件分岐で関数Aを呼ぶべき所を間違えてA'を呼んでいて出力結果がちょっと変・・・というのをさっきやらかした
関数そのものに問題はないし処理内容がちょっと違うだけなので実行は出来てしまうのがいやらしい
で、テストを作ろうとしたけどどうしようか悩み中 >>807
歴史があり、曖昧さが残るフォーマットの再実装はできればやりたくない仕事だな。
対応する仕様を現代で最低限必要なものを取捨選択して決め打ちで実装しつつ、考慮漏れでクリティカルなものは取り入れていく方式でやるしかないよ。
歴史あるフォーマットの曖昧な対応を追体験する作業は、不毛だからできれば既存実装におまかせすべき。 >>814
中間コンポーネントの単体テストって普通どうやるんだろ
後段のコンポーネントを切り離してテストするのか?繋げたままテストするのか?
切り離せるようにするとその部分にバグが入り込む余地が生まれるし
>>815
歴史が長いと仕様上○○であるがこれに準拠しないアプリやデータが少なからず存在するため
△△のような実装がベターだみたいなのが沢山あるからねぇ
そしてこの手の情報はググっても網羅するのが難しい >>811
Linux側にメリットがないと言ってる? >>816
> 中間コンポーネントの単体テストって普通どうやるんだろ
中間の意味がよく分からんけど>>813みたいな話なら関数A、関数A'をモックにしてテストする
たいていのテストツールではモックの呼び出し回数のテストができる >>816
JavaみたいにDIが発展しているタイプの言語だと中間コンポーネントが呼び出すコンポーネントはモックをインジェクトしてやって、適切なメソッドが呼び出されたかのテストとかよく書くね。
けど、正直Rustを含む他の言語で中間のレイヤだけ独立してテスト書くようなこだわりはあまり見たことも書いたこともないなぁ。
モジュール設計の考え方が変わるからかな? 今作っているのだとこんな感じかな?
関数C(データの前処理、処理単位への分割)
↓
関数B(処理全体の制御)→関数A'(処理1-2)
↓
関数A(処理1-1)
>>818,819
その場合モックへ切り替える機構はどうするんだろ
そのためにコードを書き換えていてはミスが入り込む可能性が高くなるし、条件付きコンパイルも同様のリスクがある
てかThe Rustのテストの所を見ても関数の呼び出し状況をテストする方法とかは書いていないんだよな
なんかその辺を良い感じに可視化してくれるツールとかあるんだろうか >>820
すまん rust だと cargo test で単体テストを実施するみたいだけど mook/stub をどうやって使うかはよくわからんかったわ
C++ とかだと googlemook とか使ってテスト用のモッククラスを作って入れ替えるかたちだね cargo testで関数テスト、モジュールテスト、モジュール間テストなどあらゆるテストをやっているけどダメなの? >>823
>>820 > その場合モックへ切り替える機構はどうするんだろ
に答えてやってくれ モックやスタブは別モジュール化しておいて
mod tests内では本物モジュールをuseする代わりにそれをuseするだけじゃないの? あと#[cfg(test)]でそれをuse
そして#[cfg(not(test))]で本物use 他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな
説明が面倒だ >>827
テスト以外の開発の話でも
フレームワークに依存してやってる人は
単純なこと含めて本質的なことを理解してない人が多く
フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ
何がどう動くんだか判らないCのコードを正当化するつもりなのだろうか
Rustは人間が注意すれば問題ないみたいな考えはレガシーで時代遅れだ
という思想の言語だと思っているんだが違うのかな >>829
#ifは使わないし
cfg(test)はテスト分離のため必須でしょ
どんな環境でも魔法は無いよ >>829
cfg使わないで済むいい方法があるなら書いてよ... mod tests に cfg(test) は必要だとして
依存性の注入にはtrait使えって事なのでは traitで置き換え可能にするのが面倒というのはありそうだな。 AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな >>834
usize はポインタのサイズということになっている。 >>831
単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる
C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前
そうしないとそもそも単体テストにならないじゃん
わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ
そういうことができるようにあらかじめコード設計しておかないといけないがな
考えてなかったならリファクタが必要 本物と異なり決まった値を返す送信元スタブと
本物と異なりassertだけする送信先モックを
mod testsの中では本物の代わりにuseするだけだよね
入れ替えちゃうからtrait制約で本物も偽物も受け付け対応とかわざわざする必要ないよね >>839
useしたモックをどうやって注入すんの
関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、
genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは
それともmod testsの外もcfgで置き換えると言っている? 要は
use imp::Foo;
fn target(foo: Foo) {}
がテスト対象だとして
mod tests {
use mock::Foo;
#[test]
fn test() {
target(Foo::new());
}
}
してもコンパイル通らないよね
targetがimp::Fooもmock::Fooも受け付けるようにするにはtraitが必要では >>842
他の言語は他のやり方でやってるだけだろ u32 を格納する型が必要になり、また、逆に u32 に変換する必要もあるという状況で
せっかくだから u32 に変換可能な型は受け入れようと考えてこんなコードを書きました。
しかしエラーになります。
struct Code(u32);
impl<T: Into<u32>> From<T> for Code {
fn from(x: T) -> Self {
Code(x.into())
}
}
impl From<Code> for u32 {
fn from(Code(x): Code) -> Self {
x
}
}
結果的に自分自身への変換を許すことになってしまうのが既存 (標準ライブラリ)
の定義と衝突しているという理屈は理解しているのですが、
問題を解消するためにこの定義が受け入れる範囲から自分自身 (Code) は除外するように
うまく制約を付ける方法は思いつきません。
そもそもこんなところで勝手に変換するのがよくない作法だとかそういうのは脇に置いて
「自分自身だけ除外するような制約」を上手いこと表現できませんかね? 初歩的なことですまんけどさ
メソッド内で↓みたいなのってよく見るけど、こう言うのってself.asdfのまま使用するのに比べてどういった利点があるの?
let asdf = self.asdf; 書き方は違うけどフィールドそれぞれに対して処理を行う場合に抜け漏れがないことをコンパイラにチェックさせる目的でローカル変数にすることはある
let Foo { foo, bar. baz } = self;
としておくと後続の処理で使わないフィールドがあったときにコンパイラが警告してくれる
構造体に新たにフィールド追加した場合も分割代入の箇所でコンパイルエラーになるので修正必要箇所を洗い出すことができる 本人は俺ってスゲー、天才やん!
って思ってるんだろうけど後でコード見たらなんでこんなイミフなことしてるんだ?バカじゃねーの
ってなるパターンかと
まあこういう工夫をすること自体は悪くない フィールドそれぞれに処理をするシチュエーションがわからない >>851
俺もそのdestructuring assignment自体は使いまくる
しかし目的が漏れチェックとは違うのでこうだな
let Self { foo, bar, .. } = self; こうやって自己満足の意味不明なコードが量産されていく 全フィールド舐めるのが重要な処理ってシリアライズとかだろうか
そんな小手先のテクニックとかじゃなくてproc_macro組んだ方がいいと思う
シリアライズしたいだけならserde使って#[derive(Serialize)]
これも結局proc_macroだわな コマンドライン引数や設定ファイルの定義をclap::Argやserde::Deserializeで宣言的にやって、
それらを処理するところで分割代入してローカル変数にして処理してる
人間が意識的に気をつける必要がある箇所を極力減らしたい気持ちでやっている
好き嫌いあるかも知れないけど趣味プロダクトだしコーディングの意図をコメントに残してるから許せ >>844
impl<T: Into<u32>> From<T> for Code {}の定義はFromの反射性と衝突するから間違ってる。
Into<u32>を受け付けたいなら関数のパラメタの型をT: Into<u32> or impl Into<u32>にすればいい。
まあ、実装上の規約として必要なんで内部ではtrait IntoFooはパターンとして使われるけど外に漏らすようなものでもない。 アドレスを考えれば明白に別物
一方で
let t = (123, "abc");
let (x, y) = &t;
と自動マッチングしてくれて
&t の型は &(i32, &str)
x の型は &i32
y の型は &&str
となる
つまり&(T, U)が(&T, &U)に分割代入される amd64ターゲットでアセンブラリストを吐かせてみたらr13が全く使用されていないんだけど
r14、r15よりr13を空けておく理由がなにかあるのかな うまく表現できないのですが、cやc++なら部分から始められる(動くものが作ることができる)のですけど、rustはそんな気がしないというか
伝わりにくいかもしれませんけど そういう事象をちゃんと論理がとおった表現ができないからrustが使えないんだよきみは! 作りたいものの設計のイメージがc++でできているならそれをrust化するのは比較的簡単だろうしそれができないならrustの基本的な理解が足りないだけかと Rustはデータ構造を最初に設計しないといけないというのはあるな
C++でもちゃんとそういうやり方が出来てるなら素直に移行できるだろうけど
雑にポインタ持ち回ったり実装の都合でアドホックに相互参照入れちゃったりする人には厳しいだろう C系は良くも悪くも動いてしまうんよな
そんで知らぬ間に副作用まみれになっている 雑に始めてから整理していくスタイルなら C++ のほうがやりやすいというのは理解できる。
でも雑に始めたら整理する機会などないのが現実。 >>867 ですが、
部分から始められるというのは、部分的な学習からということです
ここまで学習すればここまではできるとか
rustでは最初のプログラムを作るにもたくさんのことを知らなければならないというか
Haskellをかじったことがあり、とても興味深いのですが
わかりにくい独り言に、レスをくださってありがとうございました >>874
> 部分的な学習から
できない。
部分的に学習して何かができたように見えても必ず間違ったものを書いているのが C++ というもの。
学習を進めていくにつれて間違っていたことに何度も気づくのでうんざりした経験があるだろ? 部分的な学習ってのは
C with classes -> STL -> move
みたいな感じじゃない?
他人のコード読むなら全部必要だけど、独習してる分には最初テンプレートとかなくてもいけるでしょ >>875 >>876
横からだけど、「部分的な学習」はもっと手前のところ。初心者でも
空のコード->リテラル->関数呼出->ライブラリ使用->変数定義・使用
あたりで使い方が広がるんだけど、Rustは関数呼出-変数あたりに概念のデカイ塊がある。
このあたりをまとめて覚えないと機能するプログラムを組めないので、学習者には辛い状態が続く。
Rustはc++以上に挫折しやすいと思う。 借用と実体(所有権)を常に意識しなきなならんからね
Cだと全部ポインタ使うから意識しないんだけどね どんなプログラミング言語でもいいから何か言語を学習済みの人にとって
他の言語を学習するのは部分的に段階的にすることが可能だよ
もちろんRustでも同じで初心者向けの学習本
The Rust Programming Language
https://doc.rust-jp.rs/book-ja/
を順番に少しずつ進めれば部分的に段階的に学習できるよ >>877
段階を経ず一気に進める無謀なことをする人だけが挫折するかもしれないが無謀なその人が悪い
>>878
いきなりそこまで進める人は単なる無謀者
まずは他の言語と同じ使い方
・実体のコピー
・参照(=借用)
のみ使っている限り所有権なんて知らなくてよい
参照を戻り値としない限りライフタイムも知る必要ない
まずは部分的な学習をすればいい
その後で所有権とライフタイムを学べばよい >>877
> 関数呼出-変数あたりに概念のデカイ塊がある
C++ にもある。
あるのに中途半端な状態で間違った使い方が出来てしまうのが問題の根源。
まともに機能していないことに気づかずに
機能するプログラムを作れていると誤解して後になって結局は行き詰る。
>> 878
意識する必要はある。
コンパイラが検証してくれないのだからむしろ C のほうが強く意識する。 まずは(Copy実装型の)数値演算だけやって変数と関数の使い方を覚えればいいだけじゃん
所有権なんて出て来ないぜ
その後にようやく数値の配列をやってその参照渡しと可変参照渡しを学ぶ
といったように順番にちよっとずつ学習していけば全くの初心者でも躓くことはない 部分的な学習ができないと主張してるやつは、いきなり無茶なことをしてるバカだけだな。 >>880
でも標準機能の中でその理解が必要なんだよ
into_iterとかiterとか
その辺は本当にちゃんと理解してないとまともなループする書けない 言語の学習ではあまりないと思うけど複数のコンポーネントを全て完動させないと到達出来ない領域があるのは確か
レイヤーが下がるとそう言うのも珍しくない >>885
それは一気に全てを理解しないといけないと思い込んでるアホ人間だから
初心者のうちはfor文なんてざっくりした理解で十分に学習をどんどん進められる
後にIntoIteratorを理解する段階になってようやくfor文を完全に正解に理解すればよい >>887
いやそれは無理があるだろ
所有権と借用の理解は型変換の時にも必須
collectとか使うときにも必須
競プロみたいな数値だけ扱うようなプログラムならかけるけど >>886
それは言語の学習と関係ないよね
Rust固有の話でもないね
つまり今回の話と全く関係ないでしょう
ちなみにそういう時はサンプルコードなどをまずは魔法の呪文とブラックボックスとして受け入れましょう
そして一つずつ把握する範囲を広げていけばよいのです
失敗する人は最初から全てを把握しようとする人だけです >>885
問題点が分かってきた。
「部分的な学習」というのは項目をひとつきちんと理解してから次の項目の学習に移るみたいなスタイルを前提としているんじゃないか?
俺が思ってた学習スタイルは「概念が存在していることは知っている」という程度の全体像から解像度を上げていくような方向性だった。
機能は互いに連携するので「この部分は完璧にわかっているけど他はまだ」なんて状況は有りえんし、そういう学習方法できちんと身につくとは思わない。
(もちろん人によってやりやすいスタイルはあるのだろうけども、個人的にはオススメ出来ない。)
流し読み程度でも入門書を一度読めば (細かい借用規則を覚えていなくても) iter を使うくらいは出来るよ。
そこから何度でも読んで細かい理解を深めていくんだよ。 >>889
キチガイは黙っていろ
どんな世界でもそんなに一気に大きく手を広げて学習しようとして上手くいくわけがない
単純に一つずつやっていくのが正しい
collectなんて後で困らん
そもそもイテレータ使わなきゃcollectは出て来ない
ぶっ飛んだことを書き込んでいることを自覚しろ >>889
collectを使わなくてもプログラムを書けるから少しずつ学習していく方法でも支障はないし
collectを一旦は魔術だとみなして仕組みの詳細まで把握せずに利用して進めていく学習方法でも支障はないし
FromIteratorなんてあとから学べば十分ですよ いやcollectをここまで安全かつ効率よく実装してる言語はないのにそれを使わないのは論外 戦国時代に例えるならここに名刀があります
ワタクシは未熟だからこの刀は使いませんと言って
戦に出て殺されるみたいな話
その名刀を最初から使えるように訓練すべき >>895
使いたいならば使えばよいだけですよ
初心者がFromIteratorの仕組みまで理解しないとcollectを使っちゃいけないのですか?
この場合の『部分的に学習』とはcollectの機能の一部をまずは表層的にのみ理解して使ってみることです
そしてこの『部分的に学習』は可能です いやだから「表層的な学習」だとコンパイルすら通せないんだって 何度も言ってるけどRustはコンパイルを通せば
意図してないエラーはまず起きないし
Nullで落ちるなんてこともない 頭がいいと思い込んでる馬鹿がいきなり複雑な難しいことに挑戦して失敗して
難しい!とわめく馬鹿パターンはどんな分野でもある
その馬鹿が>>896 「段階的学習」というのは数学や物理においては成立する言葉だがプログラミングにおいては成立しない
なぜなら「知識の差」が普遍的に影響を受けてしまうから
例えば数学では代数学の理論を知らなくても初等整数論は学べるがプログラミングではそのようなことはないとわかる 例えばアルゴリズムの問題もそう
「知らない」ことが致命的になり得る collectを知らないものが自前でfor文で同じことを実装していたらどうなるだろうか?
レビューで指摘され赤っ恥を書かされてプライドはズタズタ
それが原因で鬱になるかもしれん
さらにパフォーマンス悪くなる
精神的にも肉体的にもダメージを負うことになる >>905
真逆だ
初心者の学習過程ならばcollectを使わずに実装することは適切な練習問題だ
その段階を経てからcollectを学習した者こそ身に付く >>907
その通りなんだけど
Rustは段階的な学習ができない!と主張している変な人がいるのよ >>907
初心者・初学者に「the bookを読め」はさすがにむちゃだろ。
やっぱり「初心者はRust使わず他の言語から勉強しろ」が正解なのかね。 >>891
さすが餃子さん分かってらっしゃる
最初は大まかな理解→もう少し詳細な理解→最後に完璧な理解という解像度の段階的な学習を中心に
項目や範囲を広げていく網羅度の段階的な学習を組み合わせることでRustの学習を含めて一般的な事柄にも適用できる >>911
そこで言ってる「初心者」は「Rust の初心者」ではなく「プログラミングの初心者」の意味?
そうだとすると the book はちょっとハードルが高いということはあるかもしれんな。
でも C++ と比較すると C++ のほうがもっとハードルが高いと思う。
コンパイラが検出しないところで未定義に入り込むことがあまりに多い。
初心者が間違うのは当然のことだが、正しいのか間違っているのかわからないというのは間違っていることが明白であるよりもしんどい。
そこで間違ったまま邁進できるようなメンタルの持ち主はそれはそれで遠からず行き詰るし。 >>867 ですが、
>>876 さんがおっしゃることが僕の意図を言い当てています
c++を使わなくなって 15年は経ちますが、その頃の c++にはテンプレートはありましたがスマートポインタやラムダ式、その他諸々のモダンな機能はまだありませんでした(と思います)
クラス付きのCの部分で仕事をしていました
モダンなc++へ再入門するか、rustを学ぶか迷って rustに触れて今に至りました >>914
C程度の予備知識があるならば
>>907のRust Bookだけで容易に段階的に学習できるから何ら問題は起きず大丈夫 所有権も借用も生存期間も理解してなければ
メソッド呼び出し一つ満足にできないんだから
それら無しに動くものが作れるわけない
学習自体は言語に限らずどんな学習でも部分的段階的にやるもの
それ以外の方法なんてないんだから論点ずれてる >>916
それはさすがに無知すぎやろ
Rustは数値など所有権とは無縁な型で構成されているから
所有権なんて理解しなくてもプログラムを組める
段階的に後から所有権を学ぶことができる >>917
所有権も知らずにイキってた人はさすがに言う事が違うねぇww >>919
数値型はCopyを実装しているので所有権は無くムーブも起きない 数値型だけで>>867の言う「動くもの」を作ってみれば? 所有権は実在しない幻影
lifetimeとvarianceだけを見つめなさい どうも段階的にやれると思ってる人はデータタイプを数値に限定してる気がする
数値はコピー可能でありRustのサンプルとしてよく使われるが
コピー可能なオブジェクトというのは普通のアプリケーションでは効率が悪すぎて使わない
つまり所有権の理解は必須なのだよ 初学者にマウント取りするだけで、ステップアップの具体的なノウハウを示したり
理解しやすいドキュメントを整備提供したりできない積極的に導けない人間ばかりの
コミュニティが形成されてる言語は決して流行らない
行き着く先は*BSDのような”魔法使い以外は帰れ帰れ”した結果の荒涼とした世界 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
コピーして効率よく処理できる仕組みがないからmoveが生まれた 段階的なんてものは存在しない
理解してるかしてないか >>921
Hollow world から始めなさいよw https://doc.rust-lang.org/rust-by-example/hello.html
>>925
そもそも初学者って言ってるのに
> 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
とか頭おかしい 初学者にしてもスタイルは人それぞれだろうし皆がどうやってrust習得したか語ってくれた方が参考になりそう
自分はlifetimeが導入される前からrust触ってたからコンパイラに追加される機能を適宜試してみながら体で覚えた 初級者はHello, world!からって、かつての初級者はBASICから並みに罠じゃね
ほとんどのHello, world!は現代のプログラミングで必須の要素が欠落しまくっているからな 複オジも100点オジも
もう少しRust勉強してからレスするか
大人しくしとくかどっちかにしてくれ 今担当してる作業が、あるまとまった処理を上手く対応付けするとちょっと複雑な数値演算処理だけに置き換えられるので、
その数値演算ライブラリを作っているのだけど、確かに所有権は全く出て来ない。
入出力は配列(スライス)の参照渡しと可変参照渡しとなっていてライフタイム明記も無し。
所有権を学ぶ前に参照(借用)だけで十分に色んな実践ができると思う。
そして参照は他の言語でも配列などは参照渡しになるから、新たにスライスだけ覚えればRustを段階的に学ぶことができる。 俺はずっとJavaメインで、遊びでlispとかHaskellとか触る程度で低レイヤは触ってなかったんだけど、Rustでここまで現代的に書けるならアリだなって触り始めたクチだな。 >>930
まずハロワやれと言われるレベルの初級者ってプログラミング自体初めてやるようなレベルの人でしょ
それならあれこれ教えたところでどうせ理解不能になるだけなのでとりあえず動くものを作らせることには意味がある ただいまんこのあとは
シコシコちんちん シコシコ イソチンチン >>930
何を勘違いしてるんだよw
ハロワはプログラミングの勉強じゃなくて>>932も書いてる通り環境の勉強だぞ
お前の言う必須の要素が何を指してるのか知らんけど例えばif文の勉強したい時に動かせるかどうかは重要だろ >>934
(安全な)参照は所有権の上に成り立っているよ >>940
それも真
しかし>>934のような使い方だと所有権を意識する必要すらないのも真
同様に>>934のような使い方だと参照のライフタイムを意識する必要がないのも真
これは類似なものとしてC言語を使っている時に常に所有権とライフタイムを意識する必要性があるわけではないことも同様に例示される 噛み合ってない理由がわかった
競プロ勢が多いんだな
数値しか扱わないなら
ベターCとして書くことは容易だからね 競プロじゃないけどトレイトとかよく判らないから安定しているCとしてしか使っていないわ >>942
競プロ勢による書き込みが見当たらないこの状況で
妄想により幻覚が見えているのか? 色々書いたうちCLI程度の規模のプログラムだと大半は所有権の移動がなくて所有権の意識が薄いな
オブジェクトをnewするところは厳密には移動と言えるかも知れないが単なる値返しと捉えるだろう
あとはオブジェクトの参照を渡していくだけたから単なる参照渡し 毎日毎日息を吐くように嘘を吐く複オジ
控え目に言っても頭おかしい 数値型だけでは動くものが作れないことに気がついたみたいだな
Rustで所有権を理解せずに動くものを作るなんて柱を使わずに家を建てるようなもの >>946
関数が値返しと引数可変参照渡しへの書き込みだけならプログラムの規模や種類に関係なくそんなもんだろ
所有権が出てくる幕はない
もちろんライフタイムも出てこない そういう点では所有権が出てこなくてもかなりの範囲のプログラムを書けるよ >>949
いくつかの自明な場合にはライフタイムを省略しても暗黙のルールが適用されるから書かなくてもよいだけで、ライフタイムが存在しないわけではないよ。
その暗黙のルールが比較的自然に定義されてるってことなんだろうね。 >>951
それは違うな
>>949のケースは参照返しをしていないのだからライフタイムは出て来ない
ライフタイムの存在を意識する必要もない Rustを使ってると、参照を返すようなコードはだんだん避けるようになるかもしれないな 競プロみたいにmain関数のみ
データ型は数値のみ
データ構造は固定配列のみ
サイズも高々数百から数千程度なのでスタック確保でオッケー
配列への参照のみ必要
結果は固定配列を新しく作ってそこに詰めていく
これなら所有権など一切いらない この件は数値型や競プロは一切関係ない
ヒープを使うVecやStringやそれらを含む構造体を返しても『値返し』となる点がポイント
『参照返し』とならないため『ライフタイム』は登場せず『所有権』を意識する必要もない
そして『値返し』だけでも様々な実用的なプログラムをRustで作ることができる ついにlinux kernelにRustがマージされた模様 >>954
個人的にはdangling pointetとか内部オブジェクトを書き換えられる心配しなくて良くなるから
他の言語より積極的に参照返すようになってる気がする 参照返しの安全性を保証できるRustいいよな
参照返しを使わず値返しだけでもかなり広い範囲のことを処理できる点も同意 値返しとか参照返しなんて言葉をRustで使うなよw 参照を返す時のみ
ライフタイムの概念が登場
だから参照返しと値返しの区別は実質的に重要
もちろんRustでは常に(広義の)値返しとなる
そして参照返しとは参照を(広義の)値返しすること
参照返しの対義語として(狭義の)値返しを使ってもよい 構造体など参照以外の値がlifetime持つ場合もある
参照だけ区別するのはなぜ ここでいうlifetimeはlifetimeパラメーターのこと >>962
それはそのフィールドが参照を返しているね
構造体がライフタイムを持つのはそのような時 > 値返しとか参照返し
これはどこに定義された用語ですか?
それともオレオレ用語ですか?
https://en.wikipedia.org/wiki/Evaluation_strategy
> 3.1 Call by value
> 3.2 Call by reference
値渡し参照渡しは昔からよく聞くけど 最初に言い出したのは
>>952
> >>951
> それは違うな
> >>949のケースは参照返しをしていないのだからライフタイムは出て来ない
これか >>965
それは関数の引数としての渡し方だから返し方とは独立ではないか Return by Referenceも知らんのか・・・ Rustでは参照返しが有る時だけライフタイムパラメータが付くんよ
例えば3つの参照返しが有る時に3つのライフタイムが異なれば3つのライフタイムパラメータが付くんよ
だから参照返しが有るか無いか区別されてしまうんよ 結局Rustにおける値と参照とは何かを知るためには所有権の理解が必須なワケよ >>971
参照を返さない限り所有権の理解は不要
Rustでは配列も構造体も更にはヒープを用いるVecやString等も値として返される
つまり参照を返さなくてもある程度の広範囲のプログラムを書くことができる >>974
ムーブする必要ないよな
参照渡しだけしていれば所有権は出て来ないな 所有権要らないならRust要らないじゃんって思いながらずっと読んでる
どういう結論に持っていきたいの 釣りが目的で書き込んでるひとと、それに付き合ってレスしてるひとがいるからわけわからん 参照渡しだけして参照返しをしなければ
所有権もライフタイムも出てこないからそれらを意識することもない
結果として所有権とライフタイムを理解していなくてもそのスタイルでプログラムを組むことが出来てしまう >>976
rust 学習の話だろ?
未来永劫所有権の理解は不要なんて誰も言ってないと思うが 逆にrustだとどういう時に参照返しが必要になるの? >>980
Rust 特有の事情なんかないよ。
C/C++ でポインタや参照で返すときと同じだよ。 「参照で返す」「参照を返す」って表現する人 ←わかる
「参照返し」と言い続ける人 ←??? 同じだろ
参照を渡すことを参照渡し
参照を返すことを参照返し 値渡し参照渡しで言うと依然として単なる値渡しなのに
ただポインタを渡してるだけでそれを
「ポインタ渡し」とか言い出したり
ひどいやつだと「参照渡し」だと言いはったり
そういうのを過去にC言語界隈で見てきたから気になったんよ
独自解釈による珍妙なワードはこの世に必要ないと思うでしょ
>>983
そうですかボクからはもう何も言うことはありません >>984
それは君が区別すべきことを理解できていないから混乱している
会話や説明では何と何を区別するかが重要
もちろんRustでは常に指定した型そのものが渡され返される
だから区別するとしたら実体を渡したり返したりするのかその参照を渡したり返したりするのかが焦点となる
したがって参照渡しや参照返しという言葉がぴったり適して使われている あとポインタへのポインタを「ダブルポインタ」って呼んじゃう人もいたな
このスレでは「所有権の複製」ってのもあったな >>986
英語でもダブルポインタと言うし何を問題にしているのかわからん
自分勝手な線引きやルールがあってそこから外れると融通が効かなくなるダメな人かね? ゲームの方のRustで、ホロライブのRustのSeason3が終わるから検索汚染も減るかもな 参照で返すことを「参照返し」と言った途端ブチギレするのマジで意味不明なんだがその呼び方を否定するとどんなメリットがあるのだろうか >>984を見るとCでポインタで渡すことをポインタ渡しと言われるだけで発狂するようだからその人はキチガイ 他への参照を持つ実体を返すのは値返しか参照返しかはたまた別の何かか
なんて考えたくない 「ポインタ渡し」がNGなら「ポインタを渡すこと」も日本語でそう表現していいよと言語の開発者がわざわざお墨付き与えなければNGだと思う 今回はRustの段階的学習の話だから、これだけのことではないかい。
参照返しが含まれていなければ、ライフタイムを把握する必要がなく、所有権を学習していない段階でも、そのプログラムを書くことができる。
参照返しが含まれていれば、ライフタイムを把握する必要があり、所有権を学習した以降となる。 ぼくちゃんrust入門者
ライフタイム注釈だけはどうにかならなかったのとか思った
でもいろいろ満足
tauriやるぞう ホント毎日毎日アホなこと書いてるなぁ
釣られちゃうRust入門者は少し不憫 >>995
所有権を学ぶのを後ろへずらすことでRust学習の難易度を大きく下げられそうね このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 101日 13時間 18分 37秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。