Rust Part7
■ このスレッドは過去ログ倉庫に格納されています
RustでVulkanを使いたいのですが、現状非公式のバインディングを使うしか無いのでしょうか…? デバッグビルドの時に、リリースビルドした依存クレートを使う簡単な方法はありますか?
target/release/depsをtarget/debug/depsに名前を調整して移すとできてる感じですが
もっと簡単にできないでしょうか。 なるほど
当面自作のスクリプトでdebug/depsいじります Rustに限った話じゃないんだがGUIツールキットもゲームエンジンもC++が主流
でもC/C++以外でC++の呼び出しが出来る処理系はほとんどない。うぼあー スマホゲームとか一時はUnityだらけだと思ったけど今は違うの? CどころかC++同士の異コンパイラ間ですら呼べなかったと思うけど。 ウィンドーズホンだとC#からC++/CXを経由してネイティブなC++が呼べたお なるほど。開発環境が決まっててABI決めうちできるならいけるのか。 Cは社交界のオキテを知らない村娘だから
不用意に呼ぶとズッキュウウウンしちゃったりするのよ
だから簡単に呼べなかったりするけど呼べるときはシャワーも浴びずにすっ飛んでくる、そんな子 C++のライブラリへのバインディングでほとんどのAPIがunsafe&unsafeって書いて無い奴もunsafeかもしれんから自分で気をつけてね☆
みたいのがあるんやが
これってRustで書く意味無くね…? 貴方がRustで書き直せば喜ぶ人もいるんじゃない? >>448
C++のライブラリ使うからだろ。
Rustで書かれたもの使うか、Rustで書き直せ。 Box<T>のTを初期化せずに返すunsafe fn box_t() -> Box<T> があったとして
let mut t;
unsafe {
t = box_t();
// Tの初期化
}
にするのと
let mut t = unsafe { box_t() };
// Tの初期化
ですますのとどっちが良いRust? >>452
unsafeで囲む範囲はどの言語でも最小限にしろよ
初期化にunsafe要らんのなら囲むな >>448
unsafeなAPIに対してrustで安全なラッパーを被せてやれれば意味がある unsafe fn vec_t_n(n: usize) -> Vec<T> {
let mut v: Vec<T> = Vec::with_capacity(n);
v.set_len(n);
v
}
fn vec_t_n(n: usize) -> Vec<T> {
let mut v: Vec<T> = Vec::with_capacity(n);
unsafe { v.set_len(n); }
v
}
unsafe fnにするかfnにするか
例えばutf-8を保証するStringのようにTがなにかを保証する型だとして
Vec<T>の中身がTでないかもしれないからunsafe fnが良いRustでOK? >>455
1文字ずつ文字間開いてるとucs2で書かれてるように見える >>458
そのコードだけで言えばset_len()を使うことで保証されなくなるlengthの正しさを
呼び出し側が保証する必要があるのかどうか
from_utf8_uncheckedみたいな別のunsafe fn使ってればそれによって壊される安全性があるなら
その安全性を呼び出し側が保証する必要があるのかどうか https://keens.github.io/blog/2015/09/23/rustwokakutokinochiken/
move semanticsのお陰でGCがないので本当に小さい。hello, worldが277KBだった。
Javaででかいのが当たり前で大昔の感覚を忘れてしまったんだが
ちいさい? たった13バイトの文字列をコンソールに出力するだけで283648バイトを浪費wwwww minimal runtimeってタイトルなんだからランタイムが小さいって話だろ。比較対象はGoとかHaskellとかであって、Cが小さいなんてのは当たり前。 ファミコン版のスターフォースのROMは16KBやったんやで 一方ルーストはhello, worldとコンソールに表示させるだけで277KBwww エミュROMでぐぐったら出てきた
ドラクエ3が256KByte
ドラクエ3が128KByte
ドラクエ1が64KByte
どれもKbitではない N88-BASICとかディスク拡張命令とか考えなければ32 KBに収まってた
数十KBというのは広大な情報量
人間の遺伝子もジャンクDNAを除けば10 KB強ぐらいなのではないか go だと Hello, work! だけで 2MB でした本当にありがとうございました 日本は欧米と比べてココがダメ!
↓
韓国のほうがもっとダメなのでセーフ! https://www.atmarkit.co.jp/ait/articles/1910/17/news088.html
「Rust」言語を採用したAWS、Rustプロジェクト支援を開始
Amazon Web Services(AWS)は2019年10月14日(米国時間)、オープンソースのシステムプログラミング言語「Rust」について、開発プロジェクトをスポンサーとして支援することを発表した。
Rustは、高速で信頼性が高く、効率的なコードを作成、保守できるように設計されている。2015年に最初の安定版がリリースされて以来、実システムへの導入が大きく進んでおり、GoogleやMicrosoft、Mozillaのような企業がいずれもRustを使用している。
例えばMicrosoftは自社製品の脆弱(ぜいじゃく)性の約7割を占めるメモリ安全性の問題を解決するためにRustが役立つと指摘している(関連記事)。
AWSでもRustの利用は大幅に拡大しており、「Lambda」「EC2」「S3」のようなサービスにおいて、パフォーマンスに敏感なコンポーネント用の言語として採用している。
AWSは先ごろ、軽量のマイクロ仮想マシン(microVM)を数秒で起動できる安全な仮想化技術「Firecracker」をオープンソースとして公開したが、ここでもRustが採用されている(関連記事)。 それでも数秒かかるんか…
コールドスタートの悪夢未だ醒めず >例えばMicrosoftは自社製品の脆弱(ぜいじゃく)性の約7割を占めるメモリ安全性の問題を解決するためにRustが役立つと指摘している(関連記事)。
これWindowsの脆弱性の話だろうけど、
静的解析ツールでは解決しないってことなのか? >>480
その関連記事は>>27。そのソースは>>190
静的解析ツール等を併用してもC/C++では無理があると指摘している mut を マットって読んでる人いる?
コアチーム含めミュート派が大勢なのは知ってるけど
eがないとミュートって読むのは不自然だし、時々eをタイプしそうになるから
マット派になろうかと思ってるんだが >>482
マット派
レットマットって発音が気持ちいい 結構いろんな読み方してんのね
マット派いたから安心して転向するわ
ちなみにドイツ語ではムートって読んで勇気って意味らしい わかる
fnとかpubとかunwrapとか普通にわかりにくい pubはまあわかるけど
fnとunwrapは他言語でもあるし普通にわかりやすいと思ってたわ
IntoIteratorとかは素直にIterableでいいのにとは思う しかしRustでOS作ったらCより性能悪かったという記事があったはず
新しくOS用のプログラミング言語を作った方が良いのでは
RustはOS開発を主眼にしてるわけじゃないだろう Rustは配列の境界値チェックがあるから普通に使うとCよりちょっと遅いよ OS組もうとするとRustの言語概念を無視するような書き方をしなきゃいけない
みたいに書いてあったんだけど 「Rust」言語はCよりも遅いのか、研究者がベンチマーク結果を解説
ttps://www.atmarkit.co.jp/ait/articles/1909/13/news133.html
このソースは
A high-speed network driver written in C, Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python
ttps://github.com/ixy-languages/ixy-languages
これかな >>497
ケースバイケースだろ。
なんでも杓子定規にとらえるなって言ってやれ。 いや普通にOSソース見ればそらrust向いてねーわってなるよ。
杓子定規にrust使おうってほうが気が狂ってるわ。 Rustを使わないからそうなっているのかもしれんぞ
どこでRustだと不利なのか説明してくれ ストレージからプロセスを読んで起動する、とか
そもそもコンテキストスイッチングの処理とかは所有権の概念(データの寿命が入れ子)から外れてくる
気がするが、別にunsafeにせねばならないほどでもないキモス
他に何かある? その昔はlispやforthでもos書いたりしたんだからrustで書けないことないだろう。 バグ発生率ってどうやってカウントするのが一般的なんやろか?
完全にただの思いつきで無意味な比較だけどgithubのgoとrustで総issue数/contributor数だと1人あたり2倍ぐらいgoのが多いね issueってバグじゃないだろ。
機能要望とか議論とかあるじゃん。 小さめのサイズの本で、初心者向けの本が出た!
Rustプログラミング入門、酒井 和哉、2019/10/13 >>506
バグ発生率は、バスタブ曲線だろ。
初期によくバグる
土方をやってると、バグを多く出さないと、客に提出できないw
漏れは、平均的なIQ レベルより、間違いが少ないから、
いつも、アホみたいなバグを、わざと自分で作って、バグ発生数を増やしていたw
あらかじめ勉強している人は、滅多に間違わないから、バグ発生数基準だと困るw
一方、全く勉強していない香具師は、バグが多い 仕様書にバグが多いのはあれわざと仕込んでるのかなるほど ネストした構造体のコンストラクトパターンみたいなやつはもっとチュートリアルで
説明した方がいいんでないのとは思う。
多分めんどくさい書き方にしかならんからやらんのだろうけれど。 三項演算子は便利だったなぁ、と他言語を思い出して感動してるってことかな 組み込みもネットワークツールもほとんどc以上の生産性を出すことないしな。。
一番有効な領域ってデバッガーじゃねーの?とは思う。 Bookを6章まで読んだ俺が >>224 で書いたのが
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=dc60559b7af47298d305be80b340ee98
?の便利さに気づいた俺が書いたのが
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=308e7fe634f1e539c1f936c3989022f0 .file_name()?.to_str()?.to_string()
Rustだっさ 公式に呼びやすい名前をつけないのがよくない
question mark operatorじゃわかりにくいから
error propagating operatorかerror handling operatorで ダサいかどうかとかどうでもよすぎる
性能、書きやすさ、読みやすさ、安全性がすべて 性能 境界チェックのせいでだいぶおそい
書きやすさ 地獄
読みやすさ 悪夢
安全性 噂ではあるらしい
?まみれになるぐらいだったらヌルポで落ちても変わらんやん
どうせ無理に回復とかしないほうがいい類のだろ ぬるぽで落ちるのは運が良かっただけで何でも起きうるし最悪スーパーハカーの餌食になる
?はちゃんとエラーで終了してくれる
って理解でおk? ヌルポって、javaのあれのこと?
シンタックスだけ比較して意味あんのかな >>523
ちがう
ぬるぽだとまず間違いなくぬるぽエラーで落ちる
NullSafeのありがたさはnullにならないこと
場合分けを考えずに常に変数を確実なひとつの値として扱える モナドだろうがなんだろうがNullはNullだ
へたに回復してしまうとほかに影響が波及して大惨事につながりやすい
むしろ最初からNullにならないことを保証してくれる方がうれしい
なのになんでOKで帰ってきた結果からfileNaeme取るのまで?つけさせられとんじゃ まあNULLで潔く死んでくれた方がってのは確かにあるわな。 エラーかどうかのチェックは、NULLかどうかのチェックとは違う
ここ大事なところなので間違えちゃダメ 潔く死んで欲しいなら明示的にunwrapなりexceptなりすればよい
バグなのか想定されたエラーなのかを区別して明示的にコーディングできるのがrustの利点では OptionとかResultにケチつけてるのは加齢臭キツすぎる 下手に回復して大惨事になるのは、下手だからでしょ
file_nameに?付けてるのはディレクトリの場合無いからでしょ
なんでそんなことが疑問になるのか分からない Optionとか中途半端でたちわりーわ。
てかrustみたいにライフタイム意識する言語の場合、あんまり役割ない気がするけどね。 ■ このスレッドは過去ログ倉庫に格納されています