◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:Rust part16 YouTube動画>2本 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1656285423/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
☆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を語ろう
http://2chb.net/r/tech/1547549448/ 前スレにあったrustupのnamingの話だけど
rustupにサブコマンドがない時代なんてあったっけ？
updateのupじゃなくてsetupのupじゃないの？
>>6 コード的には主にmultirust.sh -> multirust.rs -> rustup.rsなんだけど
名前はrustup.shから引き継がれてる
rustup.shはサブコマンドがなかった
rustup.rsは最初からサブコマンドがあったけどrustupと叩くと今のrustup update相当の処理(update_all_channels)をしてた
>>987 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 当面は新規開発のドライバぐらいにしか使わないって話だっけ？
既に安定して動いているカーネル本体からスタートするのは非効率たから
ドライバだとunsafe祭りになると思うけど、それでもRust活かせるのかな
Rustは標準ライブラリからしてunsafeだらけ
C だとどこが「安全ではない」のかわからん。
>>19 やめとけ
Linuxの話題は
あわしろを召喚しちまうぞ
Cたけでなくほとんとのプログラミング言語がデータ競合を見過ごす、あるいは、対応しても実行時にようやく気付いてエラー
結局allocを用意して、Resultを返すような別方言のRustを作っただけじゃん。こんなんでええのかよ、糞言語
mallocに失敗してパニックするかどうかは最終的にどうやって切り替える仕様になるわけ？
>>32 全体が一気に切り替わるようなのは多分想定されてない
Resultを返すAPIが追加される感じ
例えばtry_reserveなんかはnightlyでは実装済み
話としては二段階あるんだよね
>>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
いずれにせよ
質問失礼します。
Rustってそういうゲームだったんだな
なるほど…どおりで皆が何いってるかがまったく理解できなかったわけですね。
redditでもゲームの方のrustの質問が来るのは珍しくない模様
Twitterで
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だから何も変わってないんだよ現実はそんなものさ
どこでも同じシンプルな結論が出ている
USの状況見るとRustが広く使われるようになるのはもう疑う余地ないと思ってるけど
C は使われる範囲が広すぎた。
5chに限らずネットだと言語だなんだドヤ顔で蘊蓄垂れてイキリ散らかしてる奴ばかりだがGoogleに腐るほど日本人、まともなアプリの開発できないとネタにされるくらいソフトウェア後進国のIT土人国家なのオチが綺麗過ぎて爆笑してしまう
C/C++よりコンパクトに機能が高く書きやすいからRustを使っている
JSをサーバーサイドに使うのはどうなんかね？
用途や状況に合わせて言語は使い分ければいい
RustRusｔ言うけどこのスレの人間たちもRustでは一日1000行もコード書いてないだろ
>>66 ウェブの表層のほとんどは「ビジネスロジックの記述」をやりたい。
Rust や C++ は良くも悪くも機械に対する指示としての側面が大きい。
ビジネスと機械の間を埋めるのがエンジニアの役割ではあるんだが、
ビジネス寄りのエンジニアとガチ技術寄りのエンジニアで棲み分けが有る。
もちろん何だって速いに越したことは無いが、
ソフトウェアをガチガチにチューニングしたって限界があるからなぁ。
頑張ってソフトウェアをチューニングしてもせいぜい二倍とか三倍とか程度にしか伸びん。
ビジネスが拡大すれば再現なく高い性能が要る (可能性が有る) わけで、
必要なときに機械の数を倍にすれば倍の性能になるデザインのほうが重要なんだよ。
俺は楽だからwebも含めて大抵はrustで書いてるな
こちらはまずはバックエンドとスクレーパー方面だけRust化した
お前らは日本人あるあるで手段と目的を履き違えてる奴ばかりなんだよ
tauriってrustとjsは同時にデバッグできるのん？
ドキュメント読む限りでは
>>73 公式ドキュメントの方法じゃないけどVSCodeのrust-analyzer使えばlaunch.jsonやtasks.json書かなくても簡単にRustのデバッグできるよ
UIは実行後のウィンドウでCtrl+Shift+iでWebView Consoleが開くからconsole.logはこっちのコンソールで確認できる
ただUIのjsのブレークがうまくいかないからこっちは俺が教えてほしい
出来ても結局自分でライブラリ類は書かなきゃ行けないんでしょ？
>>72 なぜ失敗altJS言語なんかに頼ってるんだ？
当然Rust版sassもある
>>68 ＞Rustでは一日1000行もコード書いてないだろ
日本のITの主力のドカタ向けのRustの仕事はまだほとんどないだろうからな。
だから、いまRustしている奴の多くは個人の趣味でRustしている感じだろうし。
俺的にはRustを使った社内システムの開発とかやっているレベルで激すごいなって思う
Rustがメジャーになれば受注案件でRustも使うってなるんだろうが
現実を直視できないアホばっか
なるほどRustを叩いているのは受注土方だったんだな
ローカルなツールを自分一人でシコシコ作ってるってパターンだろw
現実にRust利用がどんどん広がっていってる現状に嫉妬してるおまえらはRustアンチスレの方へ行けよ
> 現実にRust利用がどんどん広がっていってる
>>83 の脳内現実w
自社開発製品
この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経由してるし直接的にできるわけではないでしょ
>>99 そもそもJSの時点で速度に不満の有る人がどれだけいることか、という点がある。
C++なら既存の資産もあるし、nativeアプリと互換性を持たせることが出来る
メリットもあるが、Rustにはない。
>>99 そもそもJSの時点で速度に不満の有る人がどれだけいることか、という点がある。
C++なら既存の資産もあるし、nativeアプリと互換性を持たせることが出来る
メリットもあるが、Rustにはない。
twitterを見ていると、Rust派の人は、JSより高速になることをメリットと考えている
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を挙げた回答が最も多かった。
そりゃそうなるわな
Rustは圧倒的にコーティングしやすい
>>108 安全安心のおまけもついてくる
>>110 Rustに大きな代償はない
煩雑。
これらのRustの問題点は、教授レベルでも理解出来てない人が多い。
教授レベル？！
今日日曜だけどつまらない書き込みしてんじゃないぞ
ライフタイムがらみで一日なんどかキーボードかマウスを投げたくなる
>>116 そんな悩むようなことか？
そこまで酷いのは何か基本理解の欠如があるのではないか
簡単な具体例を出すことを勧める
オブジェクトの寿命に関するルールは実際には C++ とそれほど差が無い。
1000行書くという謎の目標にこだわってるからライフタイムの理解がおろそかになってるのでは
登大遊は凡人レベルのコードでいいなら1日1万行は余裕で書けるって豪語してて草生えたな
そもそもコードを書く時間よりもその
普通にプログラミングするには問題ない程度にライフタイムを理解した上でも、
それはそう。
大先生方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を支持する状況にまでなったのだ
なんか違うというレベルじゃなく一番大事なところが間違ってるよ
このスレでよく見かけるパターン
このスレじゃなくて5chすべてがそうなんだよ馬鹿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の側で書き換えないから
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++で十分。
だから
>>180 RubyやJava、オブジェクトの「識別番号」が取得できることがあるが、
それはポインタ値だ。通し番号ではない。
つまり、C言語では伝統的に、リンクトリストのノードを識別するために
ポインタ値が使われている。そしてそれこそがリンクリストの本来の使い方。
だれかが間違えて、通し番号で識別する習慣が生まれてしまったが、それは
集団幻覚みたいなもので、誤った使い方だ。
で、何が言いたいんだ？
>>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 他人に説明できるだけの合理的理由が無いことは自覚してるんだな……
えっ、なにか説明が欲しかったのか？
>>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!
VIDEO ここ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も達者なのかね？
うーん。
このスレ↓では、Rustはメモリーリークしない、Cはリークすると議論してたからなあ。
http://2chb.net/r/tech/1650185555/ pijul使ってみたけど、改行コードがCRLFだと非対応で
>>239 今の開発のトレンドが互換性維持で苦労して中途半端なものになるくらいなら好きな仕様にして最後全部トランスパイルすりゃいいじゃん！になってしまったな
世の天才が叡智を絞った結果がRust界隈含めて今まで散々馬鹿にしてたウェブ(JS)の後追いなの草生えるわ
ちなみに英語圏ではSQLはシークェルと発音するから覚えとけ
ラスタシアンの紳士諸君はえすきゅーえるとかクソダサい発音禁止な
PRQL 書き味が CloudWatch logs Insightと似てそうだけどあれもそんなにいいもんじゃないぞ。
>>242 外人の禿げたおっさんはだいたいエスキューエル言うてるやろ
コントロールも無視もできない処理系や既存資産の上でまともな進化や開発体験を維持しようとしたらトランスパイルになるのは必然だったんだろうな。
>>240 メモリリークに関しては
まず、Rustは自動的に即座にメモリ解放されるため他の言語と比べて高速かつ安全
ただし、Rustにおいて循環参照は他の言語と大きく異なり、
・意図的に色々と明確に指示して作成しないと、循環参照は自然に発生しない
・強い参照と弱い参照を使い分けることが出来るため、強い参照のみによる循環参照を避けることが可能
・意図的に強い循環参照を作成した場合は、それはRustにとって自動的なメモリ解放の対象とならない
したがって、Rustにおいて強い循環参照を意図的に作成した場合のみメモリリークが起こりうるが、わざと作成したのだから意図通り、という扱い
「循環参照は自然に発生しない」なんていう解説狂信者おじさんがいる限り、プロジェクトには絶対Rustは採用しない......
ほんとこの種の信者は迷惑だわ
>>241 PijulもPRQLなど最近の新たな試みはRustで実装されることが多いが
それらはRust言語のためのものではなく汎用的なものであり
それらの問題点もRustとは直接関係がない
今後Rustで書かれた新たなものがどんどん増えていくだろうがそこは区別すべきところかな
一方でそれらをRust言語で使うためのクレートなどがあれば
Rustプログラミングにおいて使う特有の話なので
それらの話題自体を避けるべきではないね
循環参照は自然に発生しないって、コードを何も書かなければ発生しないって意味かな
>>248 新たなプロジェクトが次々とRustを採用している現実を直視しようぜ
>>249 循環参照はRust以外だと知らぬ間に発生してしまう自然なよくあるものだが
Rustでは複雑な操作で意図的に作り出さないと出現すらしない点を理解しようぜ
RAIIでメモリをケアするのは
>>236 参照カウント方式と区別したいなら、「GC方式」みたいな曖昧な用語はやめて「トレーシングGC」を使おうぜ。
>まず、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した方が高速な場合がある
>>260 これは特殊な使い方限定の話を持ち出したら意味がない話
既に書いたようにCopying GCは汎用的には使いものにならない
一般的にはRAIIによる解放が最も高速かつ利便性が高い
そのためC++でもRustでもその方法がとられている
copying GCはJavaで使われているのだが
>>246 C++にもweak_ptr<>あるけど。
RAIIがGCより高速なら
でも、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 そんなバカな認識するのはオマエだけだろｗ
>>273 所有者がいなくなるとメモリ解放であってるよ
スコープを抜けると所有者がいなくなりデストラクタが呼ばれて管理していたヒープ領域があれば解放される
所有権とは？の話に戻っちゃうな
なんか合ってるのか分からんけど最近思うこと
C++はコンテナのアロケータと積み荷のアロケータが別とかできるくらい柔軟ですよ。
コンセプトをコンパイラにハードコーディングして変えられないようにしたのがRustってこと？
>>256 こいつのような気持ち悪い反吐が出る輩がいるからRustがいまいちメジャーにならない。公式ドキュメント書き換えてこいゴミ
上の文章読んでどの辺が「アンチ」だ？ゴミのくせにイキって恥かいてんじゃねーわｗ
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のパクリじゃないですか。
それはないかな…
>>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++以外からもいろいろパクってるからその言い方だと不正確に思う
正確にはこうだな
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++が敗北した理由が安全性を疎かにしたことは事実だけど
>>318 実際にプログラミングをしたことがないからアンチはそんな間違った発言をうっかりしてしまう
>>319 天と地ほどの差がある
コンパイル時点でエラーとして弾いてくれてコンパイラが修整すべき点をアドバイスしてくれるRust
コンパイラは何も言わずに通してしまい実行運用中に問題が発覚するC/C++
「前提条件が保証できていない」に触れていないのはうっかり読み飛ばしたのかな？それともわざとかな？
マ板のコテハンが常駐するとどのスレも不毛地帯になるな
>>323 レベルの違いは重要、90点より95点の方が良いのは確か
ただ100点かどうかを争ってもあんまり意味ないだろ
>>325 > まあ
>>274 みたいなのには目をつぶるならそれでいいんじゃね
オナニーは言い過ぎだけど自分の決めた範囲で100点だーって言うのはまあ勝手に言ってりゃいいので相手に無理強いしてもしょうがない
アンチ連呼おじさんの主張は「おまえらはプログラミングしたことが無い」
話は単純
>>330 そうだな
そしてRustが解決したという「問題」の範囲を大きく見せて誇大広告している人がいたのでぶっ叩かれたと
単純な話だ
>>329 「おまえらはもうプログラミングしていないだろ」
じゃないのか
若い時はしていたんだろうが、おっさん・爺になって仕事ではもうプログラミングしていない
比較は必死にするが実際のRustプログラミング話が無いおじさん・爺のRustスレだからな
年寄りはRustに構わないで欲しい
>>332 Linus含めたLinux開発陣も同じ結論
C++はダメな言語なので不採用
Rustは良い言語なので採用
>>334 歳をとってもうプログラミングしていないん(実質現役引退)だから
Cすら仕事で書いていないだろ
> 287 名前：デフォルトの名無しさん [sage] 投稿日：2022/07/09(土) 11:50:07.31 ID:lwwTn4Ql [2/3]
>>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アンチスレ
http://2chb.net/r/tech/1509028624/ >>343 なるほど、
>341
>ちなみにこちらはLinuxだがrustc(＝Rustコンパイラ)だけあればコンパイルできる
は、比較的新しいrustを使えばgcc(リンカ)イラネってことか
rustでリンカ作った方がgccのリンカよりずっと良いものになるだろうからな
http://2chb.net/r/tech/1657382429/ 隔離対象をアンチに限定しない汎用隔離スレ立てた
もう全部こっちでやってくれ
>>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触ってた)
const 地獄 ← 判る
>>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好きの愚民がたくさんいるようですね。
このスレにはRust好きの愚民がたくさんいるようですね。
CarbonとRustは名称の紛らわしさではどっこいどっこいだな
とりあえずcarbon自体のコードの8割がcarbonで書かれるエコシステムが確立してからだろう
JSのTypeScript
Rustはあらゆる面で安全と高速の両立する抽象化を実現した言語だから
Carbonは「Rustが難しすぎるから簡単にしたい」とは言ってなくて、C++と相互運用できる言語を目指してるだけっぽいからなぁ
そもそもCarbonの使い所ってC++のレガシーコードが大量にあるところだから
ドラゴンボールのゲームでドドリアの色違いでカーボスと言うのがいたのを思い出した
Carbonって中途半端すぎね？
>>384 C++とシームレスに相互運用することが最優先課題だから、そこはC++と同じにしておかないとそもそも存在意義がなくなる
ま、2-3年後にどうなってるかだな
>>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 いきなり何かわからない話を向けられても困る
解説せよ
トレイトのどの辺が「洗練された新たなプログラム構成要素」と感じるのか全然分からん
>>423 一般的なインタフェースなんて
Trait Boundsもimpl Traitもdyn Traitもないゴミ
>>419 その点でも差異があるだけでなく
Rustのトレイトは基本概念こそHaskellの型クラスと同じだがそれ以外は各々の言語に適応してかなり異なる
>>424 そりゃ言語に合わせて変えるところがあるのは当たり前だが、
基本概念が同じだというなら類似物ではあるだろう。
カテゴリ分けしたらおおよそ同じところに分類するよ……。
>>425 それは違うのではないかな
例えばHaskellはRustのtraitでのdyn(動的解決)とimpl(静的解決)といった重要な基本概念を欠いているよ
C++の欠点は、何でもできること。
>>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は他の普通の言語にはない仕組みで、目新しく感じるけどなあ
>>436 インターフェースの問題とJavaの問題を混同するのが論外
Borrow checker自体は2000年頃のCycloneの時点でほぼできていたっぽい
>>437 そう。
C++には何でもある。
それが欠点。
必要なものに厳選して誰でも使えるようにしたのがRust。
C++のアイデアとJavaの実用性、二つの遺伝子を組み合わせたのがRust。
ちなみにお母さんがJava、お父さんはHaskellという建前だけど、本当のお父さんはC++。
Haskellさんは、自分の子供だと信じてる。
キモいな
>>442 javaの立ち位置なんて、無関係な癖に建物の影からチラチラこちらをうかがって変な妄想してる気味悪い知らない奴だよ。
>>435 あの人はプログラミング能力だけの人じゃなくてDBとか分散システムのアルゴリズムが主戦場の人でしょ。
プログラム読み書き堪能に越したことはないけど、そこだけで人を評価するのは視野が狭いよ。
>>435 C++だけでなくRustも理解できてない？
＠
純粋に疑問なんですけどRust使ってる中で「値オブジェクトマジ助かる！」って事あるんですか。
適当に参照で渡したデータが意図せず書き換えられて伝搬して困る典型ケースはコンパイラが潰してくれる認識なんですが。
>>447 それはRustじゃなく値オブジェクトを理解できてない
院卒の新人だったりしない？
>>448 低レイヤーのプログラマーは値オブジェクトとか知らないほうが普通
アーキテクチャ設計といったらCPUやメモリアーキテクチャの事だと思ってたりするw
OwnershipルールとReferenceルールがWhat
>>451 わかる
Rustのメモリ周りや、UnixとかRISC-Vみたいに、システムを動作させるに必要な機能の数をできるだけ小さくするのって難しいけど、完成品を見ると当たり前じゃんみたいな印象を受ける
>>445 残念ながらスパナーとか普通に実装してるgoogleにおいてはあんまり価値のある能力ではないよ。
ISO、C++標準化委員のグレイドン・ホアレ氏はC++0xの標準化過程で、後方互換性を削ぎ落せば理解しやすくなることに気が付く。
C++標準化委員の人でもあったんか
正直なところ一般的な単語とか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とか見たいな感じの名前が良かったんじゃないかとｗ
新言語を作る際にはありふれた言葉を使うなってコンセンサスがあれば…
せめて後ろに +lang した名前を正式名称にしてくれりゃなあ
RustとかGoはもう今じゃメジャーだから大分マシだけど
Rustでは検索にこまったことないけどなぁ
>>469 perlは違うくね
入れるならpython
Pythonはまさかちょっとしたイタズラ心で命名した言語が
ゲームのRustが人気になっていても問題なく検索できてるなぁ
パーソナライズ (その人のアクセス傾向を検索結果に反映する) がそこそこ機能してるっぽいという話はあるなぁ。
CはC言語で検索してもC++が出てきやがるからな
全然、思想や人柄が違う人を後継者に立てようとしても無理が有るな。
>>456 その例でいってとにかくクソダメなのが Go
言語仕様も前時代的なウンコみたいな仕様だが何がだめといって名前がクソすぎ
ついでにいうとマスコットが致命的にキモすぎる
goはgolangって呼び方が一般化してるから問題なくね？
ゴラン高原はイスラエルが不法に占領してるシリアの土地であり、日本政府はシリア高原と呼称するそうだぞ。
今ちいかわってキモいキャラが流行ってるように
今マイコン用クレートでメジャーなのってどのあたり？
プロトコルの方のgopherについて調べる人が困るでしょ
プロトコルはイーサリアムとビットコインで実現出来ます
Web3なんて流行るわけねーだろ
それに引き換えBorrow Checkerは開発コスト低くて便利だね
Rust=Web3 だからWeb3業界の勢いが無くなったら影響受けるよ
Etherはイーサーだけど
３年以内にMoveが天下取るとか言われてるけど本当かね
>>503 最新のブロックチェーン言語も知らない奴はここから消えて
>>504 あれLibraってまだ生きてんの？
ぜんぜん音沙汰聞かないけど
>>499 ありがと。見てみます
どのくらいのさじ加減が使いやすいのかが難しい・・・
>>505 世界に殺された
もし生まれたら恐ろしいことになってただろうしな
アレはAptosとして生き残った
std::io::Result<()>
5つの何かを返す関数なら
bevyとFyrox Engineはどちらの方が良いのかな
Rustでプラグインシステム組むならwasiが安牌かな
エディタとかツールの機能拡張だよ。
クロスプラットフォームで同一バイナリが動いてそこそこ高速で組み込み用途に向いてる
プラグインというよりマクロの実行環境の話だな
Luaやwasmを使うようなスクリプト型(スクリプト言語のことではなくて、上位レイヤのシナリオだけをユーザーに書かせる方式)の拡張って、
>>520 Rustでやりたいってことは実行速度を重視してるんだろうし動的リンクしかないだろ
しかしwasmにしてもいいっていうならJavaScriptやらLuaの活用も検討しろ
そういえば Rust の proc macro を wasm としてコンパイルしたらどないやという話はあったんじゃなかったっけ？
>>525 Luaやwasmからホストの用意した機能を呼び出す形だけでなく
ホストからLuaやwasm側の処理を呼び出す形も実装可能だよ
DLLに比べると相当手間がかかるけど
動的リンクするにしてもABIがunstableだからインターフェースはextern "C"で公開せざるを得ないし
>>528 そうしたとしてもホスト側に存在しない(ホストからスクリプトに対して公開されていない)機能は使えないでしょ？
>>530 ホスト側を経由せずに外にアクセスするのは禁止できたほうが嬉しいことも多いだろ？
俺が使っているソフトでプラグイン機構があるものというと画像ビューアとかメッセンジャとかだが
それほど自由に外の世界にアクセスする必要はないし、不必要ならアクセスさせないに越したことは無い。
(悪意あるプラグインを作り難くなるので。)
制限があるというのと制限を付けられるのは表裏一体なのでそんなの場合によるとしか……
>>529 > 動的リンクするにしてもABIがunstable
あー、そうだったわ
めんどくさいんだった
野良プラグイン入れて環境壊して上等！って時代でもないからねえ。
>>530 そりゃ広い意味で言えばどんな機能だってホスト側に存在してなければ使えない
「ホストにない機能を追加できるプラグイン機構」ってどんなものイメージして言ってるの？
今の環境で正しくレンダリングされる10年前に作られたWebサイトは多くない
Tauriはバックとフロントが明確に分離されているからOS標準ブラウザに変更があっても修繕はしやすそう
Rustでライブラリをどうやって選定してんの？
>>539 まあ今はそういう人向けの言語じゃないからね
とりあえずreqwestのblocking clientでやってみて合わなそうならあきらめろん
crate.ioにwebclient一覧が並べてあるけど結局最近のダウンロード数見て判断なんだろうなと
>>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を素直に使っとけ
>>546 Goなんていうものは不要
Rustで簡単に使える
標準ライブラリでHTTPクライアント・サーバー・テスト・非同期を全て統一的に扱えるってのはかなり強みではある
Rustはランタイムコストをゼロに近づけるためライブラリ化しているが、それは必ずしも利用者にとってメリットがあるわけではない
あくまでもOSやドライバなどを作る上でランタイムコストを削らないと適さないからそうなっているだけ
>>539 みたいな人にはまず用途を考えた上で高レイヤーのプログラムを作りたいのであれば素直にRust以外の言語を使うことをお勧めする
>>548 あまりにも狭い視野と酷い誤解をなさっているようだが
ウェブ関係はRustのメリットが十分にある分野で実際にRustで利用が多い分野
複オジ相手にするのは隔離スレか実質隔離スレの次世代スレだけにしろ
>>548 はいつものRustアンチのキチガイかな
RustはOSやドライバ用と嘘をついてそれ以外なら他の言語を使うべきと誘導する書き込みがそっくり
キチガイ同士ここ以外で仲良くやっとけよ
次世代スレの方もﾜｯﾁｮｲ付ければ例のバカが寄り付かないことがほぼほぼ実証されつつあるので
structに不変なフィールドを持たせるにはどうしたらいいのですか？
>>557 直接的にメンバに指定を付けることは出来ない。
Rust のアクセス制御はモジュールが基本単位になっていて、
「メンバに pub が付いていない」「そのモジュールの中でメンバを変更することがない」ならば変更不可能なメンバになる。
>>560 言語としてのRustにはピクリとも興味がわかなかったが
なんだか急にRustに興味がわいてきたぞー
VSCode + CodeLLDB + LLDBでデバッグしているのですが、ポインタに関して見方がよくわかりません
今の時代ってcc++rustなんて、低レイヤーをやってる人以外は不要だな
この言語開発した人、Swiftにいっちゃったみたいだけど追い出されたの？
確か燃え尽き症候群で自分から離れたんじゃなかったかな
ジャバスクリプト全盛の時代にネイティブこんぱいらなんて
Arc<HashMap<T1, T2>>みたいにした場合って、どの範囲でスレッドセーフになるんですか？
範囲はHashMap全体たが
もちろんTがSync+Sendの時のみ
条件を満たせなければコンパイラが指摘してくれるところがRustの良さ
>>578 思い込みで誤読しているあんたが馬鹿っぽい
>>576 にはそんなこと書かれていない
>>578 うちの会社にもいるわ
ビルド出来たってドヤ顔のバカ
そんなものは、ある程度の言語の知識があればいいだけ。
デバッグスキル0の奴がビルドだけでOKとか思いたがるんだわ。
急に書き込み減ったけどもう飽きられたの？
?の意味とか;の違いとか、すぐに調べられないからバッドノウハウ化しているよね。FAQとかダメダメだし。
ピークを過ぎた感はある
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で調べればいいんだよ
例えば
>>593 公式に「チュートリアル」てあったっけ？
THE Book読めということかしらん？
>>594 Error propagationとかStatement and item terminatorぐらいしか記載無いんだけど……
>>595 公式の解説出てこないんだけど、公式には説明無いんかね？
>>596 おお、ここまで指定すれば見つかりますな。公式トップに検索窓ぐらい欲しいところだけど。
>>597 エラーとか文に関わるものということが分かれば、関連するリファレンス探すとっかかりにはなるんじゃないかと
少なくとも記号よりは検索しやすい
所有権チェックはありがたいけど、lintみたいにビルドと分けた方が使い勝手よかったと思うがな。
>>597 > THE Book読めということかしら
せやで。
まあそれに限らなくてもいいけどどんな入門書でも ? の説明がないなんてことはないでしょ。
常識的な手順通りに学習してれば ? が大まかに何をする演算子なのかくらいは知っているはずだし、
エラー処理にかかわるものだと知ってればもっと細かいドキュメントを探すのにも苦労するってことはない。
なるべく一発で検索できたほうが便利というのはわからんでもないが、
演算子であると同時に制御構文の類でもあり、周辺の機能と連携するのできちんとした理解をしようとすれば
どうせ色々と見るはめになる。
>>600 所有権チェックをなくすってどういうこと？
referenceが有効な間に元データをmoveした場合に警告だけ出してコード自体はコンパイルできるようにするとかそういうこと？
コンパイル(ビルド)時に所有権チェックの結果を使ってメモリの解放処理を挿入してるんだから分けるのは無理
ビルドしなくてももっと気軽にわかるようにしろってことか？
細かな所有権の整合性を後回しにしてとりあえず動く (ように見える) ところまでもっていきたいという気持ちはわからんもでない。
所有権周りのエラーって基本的なデータ構造に起因することが多いからなぁ
>>592 そのうち、他の分野のライフサイクルみたいに、製造時、利用時といった感じで電力効率が語られるようになるんかね。
>>601 the book読めというのはさすがに初心者殺しだと思うけどなぁ。
公式に絶壁の学習曲線をどうにかしようという意識はあるのかしらん？
学習曲線をどうにかしようという気合はめちゃめちゃあるが、バカを賢くしようというつもりはないだろう
>>609 えっ、なじみのない所有権システムとかも含めてめっちゃわかりやすく解説した the book を
用意してくれるなんてスゲー親切だと思うが、何が不満なんだ？
(俺自身は英語あんまりわからんので日本語訳を読んだ。)
>>609 the bookは初心者のためのもの
Rustを全く知らなくてもちゃんと順を追って理解できるように書かれている
？は自分でエラー処理を書くようになり、
さらに自分の関数でResultなどを返すようになり、
そこでErr(e) => return Err(e)などを書くようになり、
そこでのショートカット表現として必要になるものだから
the bookでも同じ順で学べる
？をいきなり調べたい時や詳細を知りたい時は
the Rust referenceを開いて🔍をクリックして
question markと打てば該当ページに辿り着く
今時、ネイティブ吐く必要なんて全くない
vscはコア部は全部C++だけど。
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で吐かれるアセンブラリストのフォーマットの資料ってどっかにある？
--emit=asm -C "llvm-args=-x86-asm-syntax=intel”とかで指定できるみたいよ
VScodeがもっさりは感じたことないな
関数の入出力はu8だけど関数内の計算はi32で行いたい場合って普通どんな感じで書くの？
>>629 隔離スレでドヤりたいというユースケース
>>628 一旦変換すりゃいいだけなんじゃないの。 知らんけど。
例えばこんなの
>>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
}
それはともかく
行数を節約したいという間違った価値観を捨てることをおすすめ
ホントだごめん訂正
結局u8で返すなら
逆方向にシフトした場合は？
>>641 それはu8部分の下位8bitが常にゼロとなって
足しても引いても影響ないかな
スタンダードな書き方みたいなのはないのかな
なら
>>634 で行こうと思います
あと
>>633 は右シフトを間違えていました
16ではなく8です
Rustのバイトオーダーってそのターゲットのネイティブ(x64ならリトルエンディアン)で良いの？
もちろん
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の方です
MPIはHPC以外では使う必要ないです
Open MPIに限らずMPIはアプリから見たらただのライブラリだからRust側で特別な対応は不要で単にCの関数を呼び出せばよいだけでは
良くありがちな奴だと思うけど
#[allow(non_snake_case)]
構造体名もCamelCaseでArgb32とすべきかな
識別子を極端に省略するのは良くないという現代のプログラミングの流儀と業界の略語でコンフリクトしてるよね。
enum Color {
最低限ガイドには従った方が良いと思う
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
https://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のアイツは
eXtend Markup Language Hyper Text Transfer Protocol Request
完全に好みの問題と思うから何らかのルールで統一されてればどっちでも良いと思うけど、
ルールから逸脱させるかどうか悩むならルールに合わせておくおじさんになった
Rustすれのレベルの低さにガッカリ
>>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にはスタックやヒープの解説があったようですが
http://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];
あぁ言いたいことは分かった
>>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だしそうなる
コンパイル時に確定するような式なら最適化でありえるんじゃないの？
どのように最適化されようが
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でも書いているんだけど構造体のパディングの制御は処理系依存らしくて移植性を優先すると
データは整数の配列で持って論理演算とシフトで分解、構築するコードになってしまってます
どの言語でも同じ
このスレでよく出てくる μt ってなんなん？
自分も思ったけどブラウザによっては & mut がそうなるみたい
>>708 なるほど、ありがと。
異常者かと思って真面目に読む気が失せてたんだけど誤解だったか。
例えば
>>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等の文字参照を処理する場合でも
文字列参照に & mut なんてないからテキトーに解釈してるんでしょ
これはmateのバグです
& amp ; amp; を空白なしで書き込んだら & に変換されてしまった
ライブラリとかのコンポーネントの一部を作っているときに入出力だけ不定値として扱う方法ってありませんかね
ちょっと意味がわからない
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で動画プレーヤー的なのを作るサンプルってどっかにある？
TauriってWebアプリのサーバーサイドがRustで一体型プログラムになっているだけだろ？
>>734 >HLS
ちょっと調べてみたけどHLSでいわゆるRAWデータを再生出来るという情報は見つけられていない
特にビデオが未圧縮データを扱えそうにない。オーディオは未圧縮FLACでいけるかもしれないけど
再生したいのがWebブラウザが対応していないデータなのでどうしようか考え中
ビデオはBMPのぱらぱら漫画でオーディオはHLSで未圧縮FLACとか？なんか無駄に実装量が増えるけど
その手のやつでオーバーヘッド減らすならOS毎にネイティブ実装するしかなくない？
なんとかtauri使うにしてもJSやらWASMやらで動画レンダリングするようなもの作らないとだめそう
実装を追加させない方法ってありますか？
trait Sealed {}
ふたつの型が同じという制約を付けたいなら
>>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++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。
>>750 ありがとうございます。
言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。
今のところデバドラだけという話だけど
誰もvoldemort typeの名を呼ぼうとしない
MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて
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のように
Rust analyzerが優秀過ぎてMSが入る余地なさそう
既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとなる可能性もあるので意味はある
>>758 VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな
>>762 書き方悪かったわ
Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった
GoのCGoみたいな仕様だったら色んな意味で面白いと思う
rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか？
>>766 ああそれならありだな
まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな
C#も.Netも全く興味ないので知らないが
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かどうかは関係ないでしょう
C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの？
>>781 dylibの場合pubは大いに関係あるよ
ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ
>>782 むしろCは決まってるの？
決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな
近年になって作られた高速リンカ mold の作者の話でも、
CはCPUベンダーが呼び出し規約を文書化してるよ
AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ？
>>786 呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ
>>789 そこでいう実装依存ってプラットフォームごとの差違のこと？
それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの？
>>791 その段階ではあまり曖昧さはない。
リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、
その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。
アーキテクチャによって扱いを変える必要がある場合もあるし。
>>792 コンパイラがリンカに渡す情報って統一規格があるの？
>>793 別に統一されちゃいないがELFとかPEとか
じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは？
>>795 ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。
ただ現実には全てが正しく実装されているわけではなく、
場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。
仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。
そういう歴史的負債がどんどん積み重なってわけわからんようになる。
元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ
ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね？
Option<NoneZeroUsize>などを使えば
>>799 任せてください。符号ビット省略しておきますね
Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない
Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに
try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ
言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは
正直LinuxにRustなんて辞めればいいのに・・・
Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの
>>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 > その場合モックへ切り替える機構はどうするんだろ
に答えてやってくれ
モックやスタブは別モジュール化しておいて
あと#[cfg(test)]でそれをuse
他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな
>>827 テスト以外の開発の話でも
フレームワークに依存してやってる人は
単純なこと含めて本質的なことを理解してない人が多く
フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける
cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ
>>829 #ifは使わないし
cfg(test)はテスト分離のため必須でしょ
どんな環境でも魔法は無いよ
>>829 cfg使わないで済むいい方法があるなら書いてよ...
mod tests に cfg(test) は必要だとして
traitで置き換え可能にするのが面倒というのはありそうだな。
AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな
>>834 usize はポインタのサイズということになっている。
>>831 単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる
C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前
そうしないとそもそも単体テストにならないじゃん
わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ
そういうことができるようにあらかじめコード設計しておかないといけないがな
考えてなかったならリファクタが必要
本物と異なり決まった値を返す送信元スタブと
>>839 useしたモックをどうやって注入すんの
関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、
genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは
それともmod testsの外もcfgで置き換えると言っている？
要は
>>842 他の言語は他のやり方でやってるだけだろ
u32 を格納する型が必要になり、また、逆に u32 に変換する必要もあるという状況で
初歩的なことですまんけどさ
書き方は違うけどフィールドそれぞれに対して処理を行う場合に抜け漏れがないことをコンパイラにチェックさせる目的でローカル変数にすることはある
本人は俺ってスゲー、天才やん！
フィールドそれぞれに処理をするシチュエーションがわからない
>>851 俺もそのdestructuring assignment自体は使いまくる
しかし目的が漏れチェックとは違うのでこうだな
let Self { foo, bar, .. } = self;
こうやって自己満足の意味不明なコードが量産されていく
全フィールド舐めるのが重要な処理ってシリアライズとかだろうか
コマンドライン引数や設定ファイルの定義を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はパターンとして使われるけど外に漏らすようなものでもない。
アドレスを考えれば明白に別物
amd64ターゲットでアセンブラリストを吐かせてみたらr13が全く使用されていないんだけど
うまく表現できないのですが、cやc++なら部分から始められる(動くものが作ることができる)のですけど、rustはそんな気がしないというか
そういう事象をちゃんと論理がとおった表現ができないからrustが使えないんだよきみは！
作りたいものの設計のイメージがc++でできているならそれをrust化するのは比較的簡単だろうしそれができないならrustの基本的な理解が足りないだけかと
Rustはデータ構造を最初に設計しないといけないというのはあるな
C系は良くも悪くも動いてしまうんよな
雑に始めてから整理していくスタイルなら C++ のほうがやりやすいというのは理解できる。
>>867 ですが、
部分から始められるというのは、部分的な学習からということです
ここまで学習すればここまではできるとか
rustでは最初のプログラムを作るにもたくさんのことを知らなければならないというか
Haskellをかじったことがあり、とても興味深いのですが
わかりにくい独り言に、レスをくださってありがとうございました
>>874 > 部分的な学習から
できない。
部分的に学習して何かができたように見えても必ず間違ったものを書いているのが C++ というもの。
学習を進めていくにつれて間違っていたことに何度も気づくのでうんざりした経験があるだろ？
部分的な学習ってのは
>>875 >>876 横からだけど、「部分的な学習」はもっと手前のところ。初心者でも
空のコード->リテラル->関数呼出->ライブラリ使用->変数定義・使用
あたりで使い方が広がるんだけど、Rustは関数呼出-変数あたりに概念のデカイ塊がある。
このあたりをまとめて覚えないと機能するプログラムを組めないので、学習者には辛い状態が続く。
Rustは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はコンパイルを通せば
頭がいいと思い込んでる馬鹿がいきなり複雑な難しいことに挑戦して失敗して
難しい！とわめく馬鹿パターンはどんな分野でもある
その馬鹿が
>>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 の言う「動くもの」を作ってみれば？
所有権は実在しない幻影
どうも段階的にやれると思ってる人はデータタイプを数値に限定してる気がする
初学者にマウント取りするだけで、ステップアップの具体的なノウハウを示したり
数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
段階的なんてものは存在しない
>>921 Hollow world から始めなさいよw
https://doc.rust-lang.org/rust-by-example/hello.html >>925 そもそも初学者って言ってるのに
> 数値といっても機械学習などで使うバカでかいTensorオブジェクトをコピーしたい人はいないだろう
とか頭おかしい
初学者にしてもスタイルは人それぞれだろうし皆がどうやってrust習得したか語ってくれた方が参考になりそう
初級者はHello, world!からって、かつての初級者はBASICから並みに罠じゃね
複オジも100点オジも
今担当してる作業が、あるまとまった処理を上手く対応付けするとちょっと複雑な数値演算処理だけに置き換えられるので、
俺はずっとJavaメインで、遊びでlispとかHaskellとか触る程度で低レイヤは触ってなかったんだけど、Rustでここまで現代的に書けるならアリだなって触り始めたクチだな。
>>930 まずハロワやれと言われるレベルの初級者ってプログラミング自体初めてやるようなレベルの人でしょ
それならあれこれ教えたところでどうせ理解不能になるだけなのでとりあえず動くものを作らせることには意味がある
ただいまんこのあとは
>>930 何を勘違いしてるんだよw
ハロワはプログラミングの勉強じゃなくて
>>932 も書いてる通り環境の勉強だぞ
お前の言う必須の要素が何を指してるのか知らんけど例えばif文の勉強したい時に動かせるかどうかは重要だろ
>>934 （安全な）参照は所有権の上に成り立っているよ
>>940 それも真
しかし
>>934 のような使い方だと所有権を意識する必要すらないのも真
同様に
>>934 のような使い方だと参照のライフタイムを意識する必要がないのも真
これは類似なものとしてC言語を使っている時に常に所有権とライフタイムを意識する必要性があるわけではないことも同様に例示される
噛み合ってない理由がわかった
競プロじゃないけどトレイトとかよく判らないから安定しているCとしてしか使っていないわ
>>942 競プロ勢による書き込みが見当たらないこの状況で
妄想により幻覚が見えているのか？
色々書いたうちCLI程度の規模のプログラムだと大半は所有権の移動がなくて所有権の意識が薄いな
毎日毎日息を吐くように嘘を吐く複オジ
数値型だけでは動くものが作れないことに気がついたみたいだな
>>946 関数が値返しと引数可変参照渡しへの書き込みだけならプログラムの規模や種類に関係なくそんなもんだろ
所有権が出てくる幕はない
もちろんライフタイムも出てこない
そういう点では所有権が出てこなくてもかなりの範囲のプログラムを書けるよ
>>949 いくつかの自明な場合にはライフタイムを省略しても暗黙のルールが適用されるから書かなくてもよいだけで、ライフタイムが存在しないわけではないよ。
その暗黙のルールが比較的自然に定義されてるってことなんだろうね。
>>951 それは違うな
>>949 のケースは参照返しをしていないのだからライフタイムは出て来ない
ライフタイムの存在を意識する必要もない
Rustを使ってると、参照を返すようなコードはだんだん避けるようになるかもしれないな
競プロみたいにmain関数のみ
この件は数値型や競プロは一切関係ない
ついにlinux kernelにRustがマージされた模様
>>954 個人的にはdangling pointetとか内部オブジェクトを書き換えられる心配しなくて良くなるから
他の言語より積極的に参照返すようになってる気がする
参照返しの安全性を保証できるRustいいよな
値返しとか参照返しなんて言葉をRustで使うなよw
参照を返す時のみ
構造体など参照以外の値が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では参照返しが有る時だけライフタイムパラメータが付くんよ
結局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入門者
ホント毎日毎日アホなこと書いてるなぁ
>>995 所有権を学ぶのを後ろへずらすことでRust学習の難易度を大きく下げられそうね
このスレへの固定リンク： http://5chb.net/r/tech/1656285423/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「Rust part16 YouTube動画>2本 ->画像>1枚 」 を見た人も見ています：・Rust vs Go Rust part9 Rust part8 C++ vs Rust Rust part31 Rust part30 Rust part27 Rust最強(仮) Rust part25 Rust part28 Rust part18 Rust part20 Rust Part7 Rust part6 Rust Part5 Rust part11 Rust part10 Rust part26 Rust part23 Rust part29 Rust part22 Rust part24 Rust part21 Rust part33 Rust part17 Rust part15 Rust part13 Rust part14 Rustアンチスレ Rustレスバトル会場 Android Studio 2 競プロにおいてのRust Rust(unsafe) vs C Rust part19 [ﾜｯﾁｮｲ] Closures vs Objects Android Studio Part4 Android Studio Part3 Visual Studio 2022 Part3 Visual Studio 2015 Part4 C vs C++ vs Rust Part.2 Visual Studio 2015 Part5 C vs C++ vs Rust Part.3 Visual Studio 2012 Part8 Android Studio初心者なんだけど Visual Studio 2019 Part7 Visual Studio 2010 Part21 プログラミング言語 Rust 3 Visual Studio 2019 Part4 Visual Studio 2019 Part6 Visual Studio 2022 Part2 Visual Studio 2019 Part5 Visual Studio 2022 Part1 プログラミング言語 Rust 4 Vue vs React vs Angular Visual Studio 2010 Part19 Visual Studio 2017 Part6 Visual Studio 2017 Part7 Smalltalk総合 Squeak Pharo Visual Studio 2008 Part 22 Visual Studio 2019 Part3 Visual Studio 2017 Part4 RedHat Enterprise Linuxを語る Visual Studio 2005 Part 27 Visual Studio 2017 Part6
09:54:59 up 5 days, 19:00, 0 users, load average: 56.16, 59.83, 57.05
in 0.058017015457153 sec
@[email protected] on 101022
ブックマークへ