プログラミング言語 Rust 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/05/21(日) 14:04:29.55

Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。

http://www.rust-lang.org/
https://github.com/rust-lang/rust

Servo
https://servo.org/
https://github.com/servo/servo

◆前スレ
プログラミング言語 Rust 2
http://echo.2ch.net/test/read.cgi/tech/1478023960

**デフォルトの名無しさん** · 2017/07/26(水) 10:26:21.34

https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/dining-philosophers.html
このチュートリアルもうちょいなんとかならないのか
クロージャー周りの説明が抜けてるからなんだかふわっと触って終了みたいな感じになるんだけども。シンタックスの方から学んだほうがしっくりする。

**デフォルトの名無しさん** · 2017/07/26(水) 12:59:44.03

>>321
ゲームエンジンそのものがRustで書かれているのでなければ移行はないと思ってる
自分は据え置き開発だけど、ライブラリやツールやアセットパイプライン含めてC++ならそのまま利用する方が楽だし、ゲーム会社ならC++の資産やノウハウも蓄積されてる

**デフォルトの名無しさん** · 2017/07/26(水) 16:21:03.85

>>323
環境的にc++14使うくらいは許されてるの？

**デフォルトの名無しさん** · 2017/07/26(水) 18:20:47.88

>>324
基本C++11かな
部分的に14の機能も使えるかも
そのうち使えるようになると思われる

**デフォルトの名無しさん** · 2017/07/26(水) 18:36:05.35

>>320はゲームエンジンそのものがrustにならんかのーって話じゃないの
その上っ面はC++のままで良いんでない

**デフォルトの名無しさん** · 2017/07/26(水) 19:49:44.76

>>322
最新ではその項無くなったよ

**デフォルトの名無しさん** · 2017/07/27(木) 00:05:30.43

>>327
なんややっぱりそうなんだ。
やっててあんまり面白いとも思えなかったしね。
今シンタックスのところを読んでるけど、goより学習コストは高いなーと思った。
メモリ管理のメンタルモデルは学習を避けることができないから、尚の事学習コストは高いよね。
使い始めに関してはc++より難しいんと違う？

**デフォルトの名無しさん** · 2017/07/27(木) 00:15:56.27

goを学習するモチベーションとなったのはgoroutineで並列処理を簡単に書けるからだったんだよね。
phpのバッチ処理を学習期間は2,3日で
goで並列処理を書けるようになった。

まぁ書けたってだけでgoの流儀って独特だから、その後の深淵に結構はまっていったんだけど。

深層学習の為のpython。
iosのためのswift。
みたくrustの始めるきっかけとなる分野ってなんかないのかな？

rustを書きはじめる皆さんのきっかけを教えてください。

**デフォルトの名無しさん** · 2017/07/27(木) 08:45:36.82

>>329
社内でのC++開発に疲れて代替を探して。
ブライベートで使って、社内もこれにしたいと妄想する。そして誰も社内でRust使えない。

**デフォルトの名無しさん** · 2017/07/27(木) 09:07:26.49

>>313
Rustにしちゃって、あなたの後任が困るとか、そういうことはないの？
社内でもRust認められてる？

**デフォルトの名無しさん** · 2017/07/27(木) 10:08:19.56

コードに問題があればcargo runでエラーが出ますけど
ビルドせずチェックだけを行う方法ないですか？

あと定番のlintツールも教えてください

**デフォルトの名無しさん** · 2017/07/27(木) 11:54:01.80

cargo check
clippy

**デフォルトの名無しさん** · 2017/07/27(木) 12:47:34.70

>>331
前任者も認められてたからgo使ったわけじゃなく、goがもっとマイナーだった頃に勝手に使ってただけだし
俺も存在するかどうかわからない後任者など気にしてない
うちは大きな会社じゃないので、何を採用するかはプロジェクトリーダー次第

**デフォルトの名無しさん** · 2017/07/27(木) 14:28:39.09

是非rust使ってレポートしてほしい

**デフォルトの名無しさん** · 2017/07/27(木) 21:27:35.77

rustって課題を解いていく感じの学習サイトってないすかね？
goとかjsだとあるんだけど、、、

**デフォルトの名無しさん** · 2017/07/28(金) 00:41:42.43

rusr by example 本家
https://rustbyexample.com

日本語訳
http://rust-lang-ja.org/rust-by-example/

**デフォルトの名無しさん** · 2017/07/28(金) 08:34:02.73

>>337
わぉ。ありがとうございます。普通にあってよかった

**デフォルトの名無しさん** · 2017/07/28(金) 10:12:39.22

nightlyって頻繁に更新ありますか？
モバイルに接続してるのであんまり通信したくないからstable選んだんですけど
clippyがnightlyでしかインストールできないのつらい

**デフォルトの名無しさん** · 2017/07/28(金) 13:36:38.25

てすと

**デフォルトの名無しさん** · 2017/07/28(金) 17:20:05.54

cargo checkだと全てのrsファイルをチェックするので
cargo check hoge.rsみたいに特定のファイルを指定してチェックする方法ありませんか？

**デフォルトの名無しさん** · 2017/07/28(金) 17:54:04.02

Stableでは無理
Incremental compilationの安定化を待ちなされ

**デフォルトの名無しさん** · 2017/07/28(金) 18:24:34.83

>>342
あ、そのモジュールが他のモジュールに全く依存していない場合はrustc hoge.rs --crate-type=lib --emit=metadataが一応使えるんだった
ただしこれはカレントディレクトリにゴミをまき散らすからあまりおすすめできない

**デフォルトの名無しさん** · 2017/07/28(金) 21:55:20.59

REPLが欲しいんですが安定したやつないかな

**デフォルトの名無しさん** · 2017/07/28(金) 22:25:19.67

目の前の便利な箱で調べること出来ない教えて君は
実はRustで作った人工知能試験で動作試験してるんじゃなかろうな

**デフォルトの名無しさん** · 2017/07/28(金) 22:36:44.17

いまbookやってるんですけど
fn main() {
let x = 1;
println!("Hello")
}
これ1回目buildすると
warning: unused variable: `x`
--> src/main.rs:2:9
|
2 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
って出るのですが、2回目buildするとこの警告が出なくなる
なんででしょうか？

**デフォルトの名無しさん** · 2017/07/28(金) 22:40:19.95

コンパイルの結果がキャッシュされているから

**デフォルトの名無しさん** · 2017/07/29(土) 00:47:07.63

rustってまだ安定してない感じ？
開発環境は何がおすすめなんです？
vscodeを試したけどあんまりrustに対応してない感が

**デフォルトの名無しさん** · 2017/07/29(土) 02:31:25.76

>>348
俺はIntelliJ派だから

**デフォルトの名無しさん** · 2017/07/29(土) 02:34:36.68

そうですか

**デフォルトの名無しさん** · 2017/07/29(土) 10:51:47.46

Rustについて調べているのですが2点ほど質問です
・所有権、借用権ってどのようなケースを想定した機能なのか？
　並行処理を行うコードを書く時には同期ミスによる破壊を防止できて便利そうだけど上手い活用ケースを想像できない
・OS無しで動かすコードを書くケースでRustが謳うメリットはどの程度いかせるのか？
　メモリマップドレジスタへアクセスするためにunsafeと生ポインタを多用することになる
　このようなケースでコンパイル時の安全性の検査条件などはカスタマイズできたりするのか

**デフォルトの名無しさん** · 2017/07/29(土) 12:41:44.44

vim + project.vim + rust.vimもいいぞ
コード量が多いと流石にIntelliJ使うけど

**デフォルトの名無しさん** · 2017/07/29(土) 12:52:24.62

IDEAとvscodeってどっちがおすすすめ？

**デフォルトの名無しさん** · 2017/07/29(土) 12:52:42.83

おすすめ？

**デフォルトの名無しさん** · 2017/07/29(土) 14:45:43.16

>>313
噂をすればなんとやら
facebookexperimental/mononoke: A Mercurial source control server, specifically designed to support large monorepos.
https://github.com/facebookexperimental/mononoke

>>351
メモリ安全性以外での所有権の活用例としては、すでにボディを書き込み始めたHTTPレスポンスに新たにヘッダを書き込めないことを静的に保証する、とかいうのがある
https://docs.rs/hyper/0.10/hyper/server/index.html#an-aside-write-status
ヘッダを書き込んだレスポンスの所有権を奪って、ボディだけを書き込める型にして返している
https://docs.rs/hyper/0.10/hyper/server/response/struct.Response.html#method.start

**デフォルトの名無しさん** · 2017/07/29(土) 16:04:35.17

もののけ

**デフォルトの名無しさん** · 2017/07/29(土) 16:29:29.84

ideaのrustプラギンはメソッドチェインが深くなるとハイライトされなくなって、リネームとかも取りこぼすことがある。それ以外はよくできてて満足

**デフォルトの名無しさん** · 2017/07/29(土) 16:43:27.84

>>351
所有と借用は、設計の考え方として言語問わず有効なので、コンパイラに強制されるのはかなり嬉しい。

と言うのも、所有を考えないで動的メモリを使ったプログラムは、シングルスレッドであっても、ライフタイム問題を起こしやすいんだよね。
他人にヤラれると殺意がわく。

**デフォルトの名無しさん** · 2017/07/29(土) 16:55:38.17

>>351
借用に関しては、不意の同期漏れ防止と思ってる。

ご存知の通り、マルチスレッドでは、同じオブジェクトを触るときに同期処理を入れないと、データ破壊しちゃうじゃん？
C言語だと、この危険な状態がデフォルトで、気付くかどうかは人間次第。
でも、rustはコンパイラがその危険な状態を防いでくれると言うだけだと思う。

**デフォルトの名無しさん** · 2017/07/29(土) 17:08:36.25

>>351
最後、OS無しはどうかなー。

自分ならこうするかなっていうテキトーな意見だけど、生メモリアクセスが必要な部分（デバドラとか）はC/C++で書いて、アプリ部をrustで書いてFFIバインドかなー。

**デフォルトの名無しさん** · 2017/07/29(土) 17:23:05.64

Rustの素晴らしさを理解するにはC++を理解する必要がある？

**デフォルトの名無しさん** · 2017/07/29(土) 17:27:03.96

>>360
メモリ安全にかけるのがrustなら
最初から最後までrustで書けるべきじゃない？

**デフォルトの名無しさん** · 2017/07/29(土) 17:41:05.57

>>362
最初から最後までメモリ安全じゃなくてもいいんじゃない？
適材適所で使い分ければ。

マルチスレッド問題はアプリ側に多い問題かなーって。
デバドラ最下層になると、そもそもマルチスレッド要件が無かったり、メモリイメージが生で見える触れる方が融通があって便利だったりするし。

ドメイン境界で考えて、rustを適用する範囲内で潔白なのが重要と思ってる。
この潔白さは、開発者の人数が多いドメイン（アプリ）で、真価を発揮するんじゃないかなと。

**デフォルトの名無しさん** · 2017/07/29(土) 18:00:00.71

racer + flycheck-rust でマクロ補完って無理？
println!とかwrite!とか毎回全部打つのがダルい

**デフォルトの名無しさん** · 2017/07/29(土) 18:10:49.31

>>363
結局cには勝てないのか。
rustってgcがないからメモリイメージを直接いじりやすいのかと思ってたよ。
redoxとかも結局c++に頼ってたりするんかな？

**デフォルトの名無しさん** · 2017/07/29(土) 18:13:03.21

>>363
あと最初から最後までメモリ安全のほうが良くない？
少なくともメモリ関連のバグを撲滅できるんであればrustの価値はあると思うんだ。
逆にできないならrustの存在意義ってなんだろ。

goは並行処理が言語機能に組み込まれてる。
rustはメモリ安全が売りだと思うんだけど、
そこってなかなか地味な売りな気がして

**デフォルトの名無しさん** · 2017/07/29(土) 18:57:22.38

>>365
Cに頼る→負けてるって事じゃないと思うけどね。
実際アセンブリ言語はなくならないわけだし。

CPU の高機能化、メモリの大容量化、プログラムの大規模化、があって、開発効率を高めるために、プログラムの大部分がC言語に置き換わったわけじゃん。
で、マルチコア全盛の時代になって、正常稼働面での重大要因としてメモリ安全性が注目されてrustが生まれたのだから、メモリ安全のメリットの大きいところだけrustに置き換わるってのが、普通の流れじゃないのかなーと思うよ。

別にCを駆逐する必要はないしょ。

**デフォルトの名無しさん** · 2017/07/29(土) 19:02:32.30

>>366
そもそも、ハードに近い層でのメモリ安全性って何？って話だと思うんだ。

で、メモリ安全の話が出てこない領域なのだから、rustの出番が無いって事で良いんじゃない？

**デフォルトの名無しさん** · 2017/07/29(土) 19:05:29.70

>>361
むしろC++をうまく使うために、rustの意味論（セマンティクス）を勉強して欲しい、って思う。

**デフォルトの名無しさん** · 2017/07/29(土) 19:59:14.72

goができたのはgoogle社内のc++プロジェクトの置き換えのためだけどrustってどんな動機でできたの？。
まさかブラウザ開発のため？

**346** · 2017/07/29(土) 20:14:02.81

>>347
キャッシュを無効にして毎回警告を出すにはどうしたら良いでしょうか？

**デフォルトの名無しさん** · 2017/07/29(土) 20:22:55.12

>>369
俺もRustはじめてからC++が少しよく書けるようになりました

**デフォルトの名無しさん** · 2017/07/29(土) 21:18:30.65

>>355
へー、monorepo用だからモノノケとな

mercurialをベースに仮想ファイルサーバーにする予定とは、なかなか壮大な計画だ

**351** · 2017/07/29(土) 21:52:24.31

レスありがとうございます

>>355,358-359
なるほど。やはり並列処理時の安全性を担保する機能なのですね
組み込みでRTOSもどきを作って並列処理させるなんて場合には有効なのかな

>>360
構文上罠が多いC/C++の代替となる言語を探していてRustを検討しています
なのでC/C++を使わずにC/C++相当のことを行いたいです
警告もエラーも無しに動作だけがおかしいとか勘弁して欲しいです
他にDも検討していますが何となく新しい方が何かと便利かなと思ったり・・・

**デフォルトの名無しさん** · 2017/07/30(日) 03:44:39.97

以前にこのスレであったら良いと言われていたOptionのEntry風APIが実装されて、しかも既にstabilizeされている
std: Stabilize `option_entry` feature ・ rust-lang/rust@ee064c3
https://github.com/rust-lang/rust/commit/ee064c380652fb7e40c1620fd74fb1406989d009

**デフォルトの名無しさん** · 2017/07/30(日) 08:00:41.23

>やはり並列処理時の安全性を担保する機能なのですね

race condition の解消はあくまでもメモリ安全の一部でしかない

**デフォルトの名無しさん** · 2017/07/30(日) 08:02:46.70

>他にDも検討していますが何となく新しい方が何かと便利かなと思ったり

Dが検討対象に入って、かつ、低水準用途なの？
意味わからんな

**デフォルトの名無しさん** · 2017/07/30(日) 08:03:42.92

351からは実際にプログラム組んだことの無い人の気配がプンプンしてる。

**デフォルトの名無しさん** · 2017/07/30(日) 11:40:03.02

cargo check のメッセージが加工しづらい
https://github.com/rust-lang/rust/issues/42653これ追加されて欲しい

**デフォルトの名無しさん** · 2017/07/30(日) 16:21:42.29

たぶんnode.js育ちの人だと思うけど、実質1行ないし3行で完結してるクレートが出てきてるね

**デフォルトの名無しさん** · 2017/07/30(日) 17:42:42.26

clippyインストールできないclippyインストールできないclippyインストールできない
clippyインストールできないclippyインストールできないclippyインストールできない
clippyインストールできないclippyインストールできないclippyインストールできない
修正したコミットがが日曜の夜にコミットするって作者が言ってるけど遅すぎ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

**デフォルトの名無しさん** · 2017/07/30(日) 19:43:29.15

CランタイムをスタティックリンクしたくてRUSTFLAGSに以下のフラグを設定しています。

RUSTFLAGS='-C target-feature=+crt-static'

これを環境変数で設定するのではなくCargo.tomlで指定するにはどうすればいいんでしょうか？
http://doc.crates.io/config.html を参考に下のように書いてみたのですが効いてないようでした。

[build]

rustflags = ["-C target-feature=+crt-static"]

オプションの書き方が違っているんですかね？

**デフォルトの名無しさん** · 2017/07/30(日) 19:51:11.45

["-C", "target-feature=+crt-static"]
でどうかしら

**デフォルトの名無しさん** · 2017/07/30(日) 20:00:04.61

うーん、このへん試してみたんですけどだめなんですよね。

["-C", "target-feature=+crt-static"]

["target-feature", "+crt-static"]

**デフォルトの名無しさん** · 2017/07/30(日) 22:39:37.27

>>381
一時的に古いnightly使えば良いのでは

**デフォルトの名無しさん** · 2017/07/30(日) 23:38:44.64

まだruct学んで2日目だけど
これパッケージ入れる時のコンパイルが長いね
補完強化のためにracer入れようとしたらsyntax_syntaxから全然進まなくてCTRL+C押しちゃったよ
基本的なものを覚えるだけならパッケージなんて入れなくても良さそうだけど
ステップアップしたときにそれなりのスペックのPC持ってないと学習するのが厳しい言語って感じ

**351** · 2017/07/31(月) 01:33:05.73

>>377
C/C++より判りやすく罠が少なくC/C++で出来ることは全て出来る言語を探しています

>>378
ネイティブに動くプログラムで一番経験があるのはアセンブラ(組み込み)です
C/C++はなんの警告もなくメモリがぶっ壊れるし、どこが壊しているのかも判りにくいし
苦手です

**デフォルトの名無しさん** · 2017/07/31(月) 09:17:51.12

アセンブラは型がないぶんさらにメモリ壊しやすいと思うが

**デフォルトの名無しさん** · 2017/07/31(月) 13:44:43.25

ライフタイムもコンパイル時に検査してライフタイムの外側からアクセスする処理もコンパイルエラーにするって

これって結局
全部ローカル変数になるってこと？
プログラム全体を通してアクセスする変数はmain関数で用意したローカル変数だからmain関数を抜けたあとは全部開放しちゃうからメモリリークも起きない？

cとかでもやろうと思えばできるって事？
cでmallocとかfreeを使わず、
全部変数定義してつかえばrustと同じ？

**デフォルトの名無しさん** · 2017/07/31(月) 16:54:10.50

メモリに限らずリソース確保全般を行わないプログラムって何ができるのか
可変サイズの入力を受け取るならmallocがほぼ必須じゃない？
1行MAX_LENGTH文字までのテキストしか処理しないとか？

**デフォルトの名無しさん** · 2017/07/31(月) 17:16:32.22

rustってどんな分野に向いてるのかいまいちわからないんだけど
webに使うのはおすすめできる？

**351** · 2017/07/31(月) 19:18:45.74

C/C++は言語仕様的にメモリの破壊を誘発しやすいと思っているんだけどそう思うのは自分だけなのだろうか

>>388
プロジェクトやプログラムの規模という要素もあるけどメモリを自由に管理できるアセンブラの方が見通しが良く
メモリ破壊に関するリスクも制御しやすいと思う。人間が理解しやすいように並べることも出来るし
もしメモリを壊した時もC/C++より何が起きるかを予測しやすいと思う

個人的にはメモリアクセスの規約を登録できてコンパイル時にそれをチェックしてくれると嬉しいんだけどな

**デフォルトの名無しさん** · 2017/07/31(月) 19:24:58.57

アセンブリ的な観点でCの挙動が予想できないと言っているようならRustなんて余計に抽象的で分かりづらいと思うのだが
Volatile関連の制御とかだって面倒なだけだし

**351** · 2017/07/31(月) 21:28:38.42

>>393
C/C++はメモリマップを意識しないと安全を確保できないけど、マッピングするのはコンパイラでありリンカでありOS
そのような状態で想定しないメモリアクセスが起きた時の挙動を予想することは自分には出来ないです
C/C++でバリバリ書いている人はこの程度出来て当たり前なのかな

**デフォルトの名無しさん** · 2017/07/31(月) 22:26:49.07

C/C++というレベルじゃなくて
LinuxのABIやldのリンカスクリプトがわからんレベルの人と予想

**デフォルトの名無しさん** · 2017/08/01(火) 18:09:39.02

>>391
いわゆるWebアプリを書く言語としてはおすすめしない。

**デフォルトの名無しさん** · 2017/08/01(火) 18:17:25.28

>>392
C/C++に慣れていないだけでは。
もしくは動的なメモリ確保を想定していないとか。

**デフォルトの名無しさん** · 2017/08/01(火) 18:21:43.31

>>394
(わりと一般的な)OS上で動かす限り、アセンブリ言語で書いても
リンカとローダが介在することには変わりないと思うけど。

**デフォルトの名無しさん** · 2017/08/01(火) 18:52:10.83

>>351はOS無しと言っている

**デフォルトの名無しさん** · 2017/08/01(火) 19:26:38.99

>>351
OSなしアセンブラを必要とする層で使える汎用高級言語を探してるならRustは適さないからお帰り
そういう言語が存在する気はしないけど夢追い人っぽいから応援はしてるよ

**351** · 2017/08/01(火) 19:28:04.99

新しめのプログラミング言語は十中八九メモリの安全を謳っているけどこれってC/C++でメモリの破壊や
メモリアクセス違反を多発させる事例が多いからと思っているけど違うのかな
これらの低減を目的にC/C++の代替言語としてRustやDなどを検討するっておかしな事なのだろうか

**デフォルトの名無しさん** · 2017/08/01(火) 21:16:08.18

>>400
まじかーgcがないってOS無しで動かせる唯一の言語だと思ってたから残念
例えばESP8266とかESP32で使えたらいいとか思ってたよ。

webが利用用途じゃないって残念すぎるな。
そうするとrust使ってる層って仕事でc++を使ってる組み込み関係の層が
趣味的に触る言語ってことかな。

**デフォルトの名無しさん** · 2017/08/01(火) 22:02:02.77

お前の中ではGC有無とOS要否は直結するのか(驚愕

ESPがどういうチップセット構成なのか知らんけど
ARM CPUならクロスコンパイルして動かせるんじゃね
多分、同じ程度の努力でGC載ってるGoも動くと思うけど

**デフォルトの名無しさん** · 2017/08/01(火) 22:04:43.31

cargo checkすると
warning: the option `Z` is unstable
というメッセージが出るそうなんですがこのメッセージを出す方法を教えて頂けませんか？

**デフォルトの名無しさん** · 2017/08/01(火) 22:04:54.04

Webに関してはそれなりに精力的に開発されているから将来的には使い物になる可能性もある
crates.ioとかだってRust製だしね

**351** · 2017/08/01(火) 22:43:53.38

>>402
ググるとラズパイ(タダのLinuxだが)向けコードをRustで書いてみたとか、プレステ1用のコードをRustで書いてみた
とか出てくるんだよね。自分が組み込みに使えるんじゃないかと思ったのもその辺が目にとまったから
昔よりかなり良くなっているとは言え汎用機と比べるとデバッグ手段は限定されるし、コンパイル時にコードの妥当性が
ある程度保たれるというのはメリットだと思う
組み込みで「どこかのメモリを壊しているようだが皆目見当が付かない」なんて事態は可能な限り回避したいしね

**デフォルトの名無しさん** · 2017/08/02(水) 00:38:23.97

>>400
いや、そういう用途向けでしょ。
実際にOSの実装に用いられてるし。

**デフォルトの名無しさん** · 2017/08/02(水) 00:46:25.26

上の人はOSを書こうとしているんじゃなくてOS無しのままコードを書くつもりなんでないの？
言い換えると、extern crate coreすら出来ないやつ

**デフォルトの名無しさん** · 2017/08/02(水) 01:03:22.66

なんか勘違いしてる人がいるね
Rustが強いのは「ちゃんとラップしてあげれば」どんな環境でも「安全に」動かせること
例えばとあるレジスタを触っているときに他のレジスタを触れないようにするとかも（場合によってはコンパイルエラーのレベルで）できる
ただこのラップするっていうのが一番面倒で、そこで安全を担保できなければ＝unsafe祭りならむしろCのが楽とも言える
ちょっとググったらArduinoでRustを動かすためのライブラリもあるからその辺り参考にすると良さそう

>>408
OS書くのもOS無しで書くのも変わらないと思うんだけど、coreを含められないってどういう状況？
libcoreは何にも依存してないからそんな状況ありえないと思ってた

**デフォルトの名無しさん** · 2017/08/02(水) 01:08:41.51

アセンブリ君

**351** · 2017/08/02(水) 01:16:10.65

あー・・・何となく判ってきた。組み込みでそのようなコードを書くのか判っている人からレスが付いていたのか

**デフォルトの名無しさん** · 2017/08/02(水) 01:21:03.63

>>396
>>405
今は使い物にならないって事？
向いてると思って趣味のWEBアプリに採用したけどやめたほうがいいのかな
Golangは古臭すぎて使う気起きないし
正直速度はどうでもいいけど構文が好き

**デフォルトの名無しさん** · 2017/08/02(水) 01:21:20.56

coreだって何にも依存しないというわけではない、けれどそれは自分で用意すれば良いしね
rust_begin_panicとかをどうやって用意するのかは知らないけど

**デフォルトの名無しさん** · 2017/08/02(水) 01:22:27.24

RustでもOS書けるでしょ
(もちろんCと同じく最低限のアセンブラはいるが)
ぐぐればいろいろ見つかるぞ

**351** · 2017/08/02(水) 01:38:12.16

>>411ミスった。訂正
×　組み込みでそのようなコードを書くのか判っている人
○　組み込みでどのようなコードを書くのか判っていない人

>>409
>例えばとあるレジスタを触っているときに他のレジスタを触れないようにするとかも（場合によってはコンパイルエラーのレベルで）できる
そういう話を聞きたかった。レジスタの操作順までコンパイラレベルで面倒を見てくれたらありがたいと思う
xに値を書き込む時はyのnビットを1にしてからxへ書き込むとかあるしな。その定義を作る気力があるかはともかくとして

>そこで安全を担保できなければ＝unsafe祭りならむしろCのが楽とも言える
ペリフェラルレジスタだけunsafeにしてすればと思ったけどそう単純な話ではないのかな
もちろん入力値のチェックは必要になるだろうけど

**デフォルトの名無しさん** · 2017/08/02(水) 02:29:19.43

>>413
確かにmemcpyとかあるね、忘れてた
まあこの辺りはCでも間違いなく自分で書くとこなので大したコストじゃないね
> rust_begin_panic
組み込みならシリアルにでもログ出して無限ループとかが普通かな？
こういうのはOS系のプロジェクトがとても参考になる

>>415
> その定義を作る気力があるかはともかくとして
実行時チェックなら多少楽になるだろうしそこは（精神的）コストとの相談だね

> ペリフェラルレジスタだけunsafeにしてすればと思ったけどそう単純な話ではないのかな
個人的にはunsafe使い始めると至る所で使うようになっちゃうのでお勧めしない
Rustの思想的にも未定義の挙動を許すunsafeはできるだけ避けるべきだしね
そんなの気にせずチェックしたいとこだけチェックさせるLint的な使い方もありっちゃあり

**デフォルトの名無しさん** · 2017/08/02(水) 07:02:07.94

redoxのアセンブラで書いてる所すらもrust(高級言語)で書きたいって夢を語ってるんじゃないの？
結局何がしたいのか分からんな・・・

そこについては諦めているなら既に実用化されているし
そこを追っているならチップ毎のクロスコンパイラ作りを頑張れとしか言いようがねぇよ

**デフォルトの名無しさん** · 2017/08/02(水) 08:11:06.98

>>415
レジスタまで意識する用途なら、高級言語を使わないのが正解では

> xに値を書き込む時はyのnビットを1にしてからxへ書き込むとかあるしな。
それこそボード固有の話になるので。
高級言語でやるとしたら機能レベルで関数化して中身はインラインアセンブリで頑張るとか。
何れにせよ言語レベルで対応する話ではないな。

**デフォルトの名無しさん** · 2017/08/02(水) 10:50:44.07

>>412
>向いてると思って趣味のWEBアプリに採用した

やってみたら良いと思う。
仮にミスマッチだったとしても、過程や結果を公開すれば、色んな人の役に立つ。

**デフォルトの名無しさん** · 2017/08/02(水) 12:12:53.41

rustっていまのところ
何にも向いてないということか。

golangみたいにgoといえば並列処理！みたいなウリがないとなかなか厳しいな。
とりあえずwebはgoでいいや。

**デフォルトの名無しさん** · 2017/08/02(水) 12:21:18.09

>>419
webアプリ作るならunsafe必須とか？
cもc++も触った事ないからunsafeだけは無理なんだけど…