プログラミング言語 Rust 4

**デフォルトの名無しさん** · 2017/10/14(土) 17:38:14.04

Mozilla発のプログラミング言語「Rust」のスレです

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

前スレ
プログラミング言語 Rust 3
https://mevius.5ch.net/test/read.cgi/tech/1495343069/

**デフォルトの名無しさん** · 2017/10/14(土) 17:50:32.20

乙py

**デフォルトの名無しさん** · 2017/10/14(土) 19:21:55.29

rustって難しいの？
使いにくい言語って結局クソじゃね？
有難がってるのって信者だけ？

**デフォルトの名無しさん** · 2017/10/14(土) 20:28:14.94

簡単だからみんなに愛されてるよ

**デフォルトの名無しさん** · 2017/10/14(土) 20:49:22.17

低能には無理なだけ。

**デフォルトの名無しさん** · 2017/10/14(土) 21:21:44.96

乙rs

**デフォルトの名無しさん** · 2017/10/15(日) 02:22:15.99

>>3
厳しい先生だと思う。
でもそれは俺らのためでもあって、rust先生の審査を通ったプログラムは安全と言える。
ただ先生も普段が厳しすぎるとは思ってるので、わかってる奴ら用にunsafeって抜け道も用意してくれてる、、、
そんな感じ。

**デフォルトの名無しさん** · 2017/10/15(日) 17:08:59.82

>>3
そう。信者と本山（モジラ）だけ
試しにAPIサーバでも書いてみりゃ即この言語使えねえってわかるぞ

**デフォルトの名無しさん** · 2017/10/15(日) 17:11:39.41

あと何度もいうけど「Rustのコンパイル通らないプログラムは危険」とかいうデマゴーグが嫌い
きちんと状態管理すりゃいくらでも正しく動くのに
やれstatic領域は排他制御しろだのやれこの変数はスコープ明示的に切れだのいらんことばっかいうのがRustコンパイラな

**デフォルトの名無しさん** · 2017/10/15(日) 17:45:57.69

書きやすさは一旦置いといたとしても
保守のしやすさってどうなんだろうか
この言語は、保守しやすいコードへ導く言語なんだろうか

**デフォルトの名無しさん** · 2017/10/15(日) 17:55:29.27

>>10
一度書いたものを書き換える度にコンパイラが奇声をあげるので変更もままならないという意味では保守性（）は高いかもな
メンテナンス性がまったくないともいう

**デフォルトの名無しさん** · 2017/10/15(日) 18:15:28.06

>>11
メンテナンス性はまったくない、でFA？

言語とのしてのメンテナンス性の傾向ってのは
さほど語られてるのを目にしないけど個人的には

Java
10年後数万行のコード見てもわりと整然としてる
あとから何度も手を入れて運用していける

Ruby
最初書きやすい、表現力が高い？と感じながらスイスイ書いていける
半年後、雑然としていてまったく読めない
クソみたいなコード書いた自分が悪いとはいえ

↑こういう感想を抱いている

**デフォルトの名無しさん** · 2017/10/15(日) 18:56:05.11

そもそもRustはプログラミング言語として破綻してるので、
モジラ信者でもない限り使わん触らんが一番幸せだ

悪いことは言わんからRustのことは忘れろ

**デフォルトの名無しさん** · 2017/10/15(日) 19:40:50.30

>>13
ほんと定期的に沸くなこのアンチ

>>12
メンテナンス性でいうなら、最初に型さえうまく設計してれば結構拡張性あるから、
その辺はどっちかというとHaskellに近いかな
クセはあるけど型をきちんと理解して最初の設計に組み込んでおけばかなり自由が効く

最初の型合わせゲームは辛いけどな

**デフォルトの名無しさん** · 2017/10/15(日) 21:01:33.85

ID:OLs+Obq4 くらいの基地外になれば100年だって粘着する。

**デフォルトの名無しさん** · 2017/10/16(月) 00:56:00.52

firefoxをRustで書けるわけないと言ってたのがMozilla以外使わないに後退したのか

**デフォルトの名無しさん** · 2017/10/16(月) 01:34:41.28

>>16<br>
そりゃまぁ、事実としてmozillaがRustでfirefoxを書いちゃったからな

firefox Quantum beta 試してみたけど確かにchrome並みに速くなったな
そしてchromeよりメモリは食わないのが良い
でも正直、俺はメモリ不足を感じたことがないからChromeベースのVivaldiを使い続けるが

無事にfirefoxも出たことだしRustもう少し普及してくれないかなぁ

**デフォルトの名無しさん** · 2017/10/16(月) 06:58:12.63

quantam はcssしかrustになってないからまだ速くなるらしいぞ

**デフォルトの名無しさん** · 2017/10/17(火) 15:47:54.26

>>18
ブラウザのレンダリング速度ってcssをどれくらい速く捌けるかが大部分なんじゃないの？
それ以外がRustになったところで速くなるといっても微々たるものなのでは．．．

Servoって確かJSエンジンは従来のSpiderMonkeyをそのまま使ってるんだよね
JSはGCあるし、DOM管理（Rust側のDOMオブジェクトとの連携）とかどうやってるのかよく分からんけど
DOM管理の部分とかがRustになったらさらに速くなるのかな？

今のQuantumってGecko全体の何%くらいがRustになってるんだろう？

**デフォルトの名無しさん** · 2017/10/17(火) 18:19:17.27

firefoxはまだまだchromeに負けてる
https://www.phoronix.com/scan.php?page=article&;item=firefox-quantum-bench&num=1

rustの力ではよどうにしかして😣

**デフォルトの名無しさん** · 2017/10/19(木) 23:42:22.47

というか Servo はいつになったらまともに動くようになるんだろう。
精力的に開発が行われているのに、数クリックでフリーズする状況が年単位で続いているのが謎すぎる。

**デフォルトの名無しさん** · 2017/10/20(金) 00:07:38.98

>>21
数クリックでフリーズってどういう事？
普通に動くぞ

**デフォルトの名無しさん** · 2017/10/20(金) 00:17:55.96

>>22
定期的にバイナリ落としてきて Windows/Linux で試しているけれど、リンクを数回辿る
くらいの操作で入力を受けつけなくなる。 Windows と Linux は物理的にも違うマシン
だし、おま環じゃないと思うんだけどなあ。

**デフォルトの名無しさん** · 2017/10/20(金) 02:33:32.00

>>23
下のサイトでnightlyビルドで公開されてるやつ試したが日本語サイトは全滅だった。
英語サイトならWikipedia, Github, Rustの公式サイトあたりは見れたぞ。
Amazon, youtube, google mapは動かなかったが。。。
ちなWin10ね

https://servo.org

**デフォルトの名無しさん** · 2017/10/21(土) 15:27:07.62

>>24
起動直後にそれらのサイトにアクセスすると普通に動くけれど、
そのままリンクを辿ったりするとフリーズしない?
こちらもそこで落とした Nightly on Win10.

**デフォルトの名無しさん** · 2017/10/21(土) 15:39:44.95

rocketというwebフレームワーク気になる

そもそもrustってwebサーバーに向いてる？🤔

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

rocketワイも気になるンゴ

**デフォルトの名無しさん** · 2017/10/21(土) 18:49:44.39

trait Foo: Sized {
const BAR: Self;
const BAZ: Self = Self::BAR;
}

beta や nightly では通るのに、stable ではエラー出して通らないのな。

**デフォルトの名無しさん** · 2017/10/21(土) 22:00:10.66

あ

**デフォルトの名無しさん** · 2017/10/21(土) 22:37:04.09

>>29
あ、アは、日本語の音節の1つであり、仮名の1つである。1モーラを形成する。
五十音図において第1行第1段（あ行あ段）に位置する。
by wikipedia
https://ja.wikipedia.org/wiki/あ

**デフォルトの名無しさん** · 2017/10/22(日) 05:54:14.55

>>26
向いてはないな

web系は処理速度や信頼性、保守性よりも生産性が重要視される。
生産性ではRustはphpやruby on rails には劣る。

かといって向かないとも思わない。
現にRustのweb系のフレームワークは複数存在してるし、
どれも今のところ結構精力的に開発、更新されてる。

Rustはc++と比べて抽象化と並行性という意味では優れているから、
特にRocketは他言語のwebフレームワークにも負けないレベルの短いコード量で
Webサーバー作れる(あくまで個人的な感想。異論は認める)し、
将来的には並行性を活かしてパフォーマンスも改善されると思われる。

Rustが好きなら十分アリだと思う。
逆に目的のWebサーバーさえ作れれば言語なんかどれでも良い
って感じならRustはないな。

Rustは慣れるのにとにかく時間がかかるけど、慣れちゃえば
それほど生産性の低い言語だとは思わないし(高いとも思わないが)。。。
結局は学習コストがRustの一番の問題なんだよなぁ。。。

思ったより長文になった。すまぬ

2017/10/22(日) 09:29:16.36

web系で一括りは雑でしよ
シングルスレッドでうぇいうぇいやってるアプリ層と下位の屋台骨支えてるところでは世界が違う
シンプルにまずはc++の代替を狙う言語でいい
仕事で使うレベルを考えるとc++の教育コストにうんざりしてるからrustには期待してる

2017/10/22(日) 11:20:50.04

そーいえばいつの間にかrustfmtのフォーマットが変わって
くそめんどいことになってるけど、
どうしてこうなったの

**デフォルトの名無しさん** · 2017/10/25(水) 21:48:06.68

C/C++を覚えなきゃだめです
Rustを使うにしろGo言語を使うにしろです何の新しい言語を使うにしてもです
世のライブラリの大半はC/C++用に作られているわけです
Rustでラップされたライブラリ、代替できるRustで書かれたライブラリ、そんな便利なものがたくさんあればいいのですが

**デフォルトの名無しさん** · 2017/10/26(木) 17:41:17.14

typedef struct Foo {
int x;
int * x_ref;
} Foo;

Foo foo;
foo.x = 11;
foo.x_ref = &foo.x;

C で書くとこんな感じになる、自分の要素への参照を要素として持つ構造体って、Rust じゃもしかして書けない？
苦心してこんなん書いてもやっぱ無理だし。

use std::mem;

struct Foo<'a> {
x: i32,
x_ref: &'a i32,
}

impl<'a> Foo<'a> {
fn new() -> Self {
let mut foo = Foo {
x: 32,
x_ref: unsafe { mem::uninitialized() },
};
foo.x_ref = &foo.x;
foo
}
}

**デフォルトの名無しさん** · 2017/10/26(木) 18:27:07.74

参照として持たせる意味が分からない

**デフォルトの名無しさん** · 2017/10/26(木) 18:39:59.49

カーソルに使うんだよ。

**デフォルトの名無しさん** · 2017/10/26(木) 23:52:30.58

前もこのスレで同じようなこと聞いてダメだったはず

一つの構造体の中に、配列とその中のどれかを指す参照が入ってる構造

解決策は、参照をやめてインデックスを持つ

**デフォルトの名無しさん** · 2017/10/28(土) 17:28:01.09

let mut foo = vec![false; 20];
// fooの2番目と3番目をtrueにするには
foo[1] = true;
foo[2] = true;
// しかないでしょうか？

**デフォルトの名無しさん** · 2017/10/28(土) 18:11:36.42

2番目と3番目以外がどうなってもいいなら
let mut foo = vec![true; 20];

**デフォルトの名無しさん** · 2017/10/28(土) 18:33:36.35

すいません…
良くありません

**デフォルトの名無しさん** · 2017/10/28(土) 19:14:18.79

実際のところ生産性ってどうなん？
GUIプログラムとかにも向いてる？
いい感じのGUIフレームワークがあったとして。

**デフォルトの名無しさん** · 2017/10/28(土) 19:33:23.13

>>39
何がしたいの？
いろいろ出来るけど

**デフォルトの名無しさん** · 2017/10/28(土) 19:58:15.36

>>43
pythonでいえば
foo[1:2] = [True] * 2
みたいなことです

(1..3).for_each(|x| foo[x] = true);
といちいち書くのが面倒(な上処理が重そう)だったので伺いました
実装したいのはアトキンの篩です

**デフォルトの名無しさん** · 2017/10/28(土) 20:29:56.20

>>44
効率が悪いってのはindexアクセスを二回やるとこのこと？
ここは過疎ってるからまじめに聞きたければSlack行くとよいよ

**デフォルトの名無しさん** · 2017/10/28(土) 20:41:41.30

let mut foo = vec![false; 20];
println!("{:?}", foo);
foo.get_mut(1..3).unwrap().iter_mut().for_each(|v| *v = true);
println!("{:?}", foo);

**デフォルトの名無しさん** · 2017/10/28(土) 20:43:42.54

コスト気にしてるみたいだけど、release でコンパイルすれば、結局
foo[1] = true;
foo[2] = true;
したのと変わらん結果になるんちゃうか？

**デフォルトの名無しさん** · 2017/10/28(土) 21:55:42.13

>>45,47
そうなんでしょうか(LLVM IRも読めない)
それで進めようと思います
ありがとうございました

アトキンの篩は他の言語だとどれもヒープ
確保してforループでヒープ操作という感じですが
横着して同じような実装をRustで書くとas usizeばっかだしで一目でダメとわかるコードに…

**デフォルトの名無しさん** · 2017/10/29(日) 00:23:56.31

Atkinの篩、実装を見てみたが（察し）

https://phillip-h.github.io/reikna/docs/reikna/prime/fn.atkin.html
https://github.com/FrogBomb/prime_sieve

**デフォルトの名無しさん** · 2017/10/29(日) 09:47:38.74

Kotlinのスコープ関数みたいなことができるcrateってありますか？

**デフォルトの名無しさん** · 2017/10/29(日) 11:47:41.30

'a type と 'a + type の違いが分からん.

**デフォルトの名無しさん** · 2017/10/29(日) 11:48:57.06

obj.method(args) って形はマクロを使っても崩せないんじゃないかなあ
動作的にwithみたいなのは一関数でできるんじゃない？
無理すればメソッドとして実装することもできるかと
https://play.rust-lang.org/?gist=2133c56a393f15a3ff5d059016ed3b11&;version=undefined

便利か？と言われたらそうでもないかも

**デフォルトの名無しさん** · 2017/10/29(日) 11:50:41.46

>>51 'a + typeじゃなくて'a + Traitじゃない？

**デフォルトの名無しさん** · 2017/10/29(日) 12:23:33.14

>>52
なるほど！
最近Kotlin書くことが多くてスコープ関数使ってみたら、いちいち変数に入れなくてよかったり（変数名を考えなくていい）レシーバを指定しなくてよかったりして楽に感じたので、Rustでも同じようなことできるcrate公開されてないかなと思っていたところです！

**デフォルトの名無しさん** · 2017/10/29(日) 12:31:27.29

>>53
おお、その通りだ。分かってなさすぎるな…。
fn hoge<'a, T: 'a + Trait>( x: &'a T );
&'a T が参照先オブジェクトの寿命を表しているのはいいとして、
'a + Trait の 'a の意味がよく分からない。

**デフォルトの名無しさん** · 2017/10/29(日) 17:07:16.08

>>55 自分もよく分かってないし、見覚えの無い使われ方があったときにそれを指す言葉を知らなくて時間がかかるんだけど、
https://doc.rust-lang.org/book/second-edition/ch19-02-advanced-lifetimes.html
↑にあるように、<>の中ではlifetimeや総称型を使うよ、と宣言するのと、T: Traitとやって型の境界(bound)を指定するのの2つの意味があって、
T: 'a + Traitってのは型TがTraitをimplしていることと、もし参照型だったりlifetimeを持つ型だったりしたときは'aより長生きなものに限りますって意味になる、らしい

意味は分かる。けど、hoge(v)としたとき、lifetime関連のエラーを吐く具体的な値vの例が思いつかない

**デフォルトの名無しさん** · 2017/10/29(日) 18:50:42.32

whereで書いたほうがわかりやすいね

**デフォルトの名無しさん** · 2017/10/30(月) 21:06:32.26

>>35
まず、そのままのコードでは new() の返り値が move されるときに
&x のアドレスが変わってしまう(実際には最適化で move されない
だろうけど言語仕様的には)ので、そのコードがエラーになるのは正当。
なので x か Foo 全体を box 化する必要がある。ただ box 化すれば
コンパイルが通るかというと、 box を deref して得られる参照は box
の中身の寿命ではなく box 自身の寿命になるので、 transmute で
チートする必要がある。

fn new() -> Self {
let mut foo = Box:new(Foo {
x: 32,
x_ref: unsafe { mem::uninitialized() },
});
foo.x_ref = unsafe{ mem::transmute::<_, &'static _>(&foo.x) };
foo
}

**デフォルトの名無しさん** · 2017/10/30(月) 21:26:14.87

失礼。コンパイル通らないコードを貼り付けてしまった。

fn new() -> Box<Self> {
let mut foo = Box::new(Foo {
x: 32,
x_ref: unsafe { mem::uninitialized() },
});
foo.x_ref = unsafe { mem::transmute(&foo.x) };
foo
}

**デフォルトの名無しさん** · 2017/10/30(月) 22:54:07.55

ありがとう。
move するとアドレスが変わるというのは無理矢理実験したときに気付いたけれど、
実際はこんな感じで Box 化された構造体の特定の変数への参照が欲しかったので、
>>38が言った前スレの>>507-514辺りを見て、こんな感じで解決してました。

use std::mem;

struct Bar(i32);

struct Foo {
x: Box<Bar>,
x_ref: &'static i32,
}

impl Foo {
fn new() -> Self {
let mut foo = Foo {
x: Box::new(Bar(10)),
x_ref: unsafe { mem::uninitialized() },
};
let dummy = mem::replace(&mut foo.x_ref, unsafe { mem::transmute(&foo.x.0) } );
mem::forget(dummy);
foo
}
}

**デフォルトの名無しさん** · 2017/10/31(火) 00:31:43.31

>>60
ああ、確かにリファレンスとはいえ forget() しとくべきだね。
このコードについては↓でも問題ないけど、まあ実際の初期化はもっと他にも
処理があるだろうから、一般にはこううまくは行かなかいか。

struct Foo<'a> {
x: Box<Bar>,
x_ref: &'a i32,
}

impl<'a> Foo<'a> {
fn new() -> Self {
let x = Box::new(Bar(10));
Foo {
x_ref: unsafe { mem::transmute(&x.0) },
x: x,
}
}
}

**デフォルトの名無しさん** · 2017/10/31(火) 18:55:06.66

Rcって何のためにあるんですか？　所有権？　借用じゃダメなん？
所有権持ってる変数のライフタイムを超えて借用できないからRc？
色んなコンテナや、色んなデータ構造に渡って持たせたいときはRc？

https://ideone.com/IP9Jk4
書いてみたらなんとなく納得行ったような気がする

**デフォルトの名無しさん** · 2017/11/03(金) 08:56:29.78

標準に整数型のトレイトがないの意味わかんねぇ
std::net以上に需要あるでしょ

**デフォルトの名無しさん** · 2017/11/03(金) 19:05:06.62

>>63
Scalaも無かった気がする

**デフォルトの名無しさん** · 2017/11/04(土) 09:52:47.01

Haskellで言うNun型クラスみたいな奴ってことか？
トレイトでやろうとすると要定義メソッド多すぎたり、
累乗みたいな計算の実装が遠回りになったりしそうできつそうに見えるな

**デフォルトの名無しさん** · 2017/11/04(土) 10:16:41.16

Haskellは数値も抽象化してるせいでパフォーマンスにかなり影響与えてるしね…

**デフォルトの名無しさん** · 2017/11/04(土) 11:00:10.28

s/Nun/Num/
Scalaはその辺を、暗黙の型変換でシームレスに扱おうとして闇を量産してるんだよな
Rustは今んとこ特になんもしてない感じか

**デフォルトの名無しさん** · 2017/11/04(土) 11:30:17.70

numクレートじゃいかんの？
https://github.com/rust-num/num

**デフォルトの名無しさん** · 2017/11/05(日) 10:17:10.41

numクレートが標準にないのが嫌なんだろうけど、std::timeみたいに標準サポートやーめたってなりそう
Into/From使えば別に困らんしと需要は少ないのではなかろうか

**デフォルトの名無しさん** · 2017/11/07(火) 20:38:24.64

https://ideone.com/XBh9VX
・AA treeを実装
・1.8.0で主に確認(ideoneは1.14.0)
・Rc<RefCell<Option<Node<T>>>>を中心に実装
・ふんだんにRc::clone()を乱発
・Tも<T: Copy>でコピーしちゃう
・肝心の木の操作部分は、wikipediaでの表現に近くなるように表現
・基本的によく分かってないので色々奇妙な事をしているかもしれない

昔からチラホラ「Rustで木構造は苦しい」と耳にしてて興味があったのと
最近ほかのスレで実装してた人がいたのをみて触発されたので書いた
最初はOption<Rc<Node<T>>>で書いてたけど
RcとRefCellの組み合わせを試してみたくなって方向転換
けっきょくどっちが正解だったのかは不明

**デフォルトの名無しさん** · 2017/11/07(火) 20:46:48.79

ただのAA木に Rc なんて要らんだろ。Option<Box<Node<T>>> で済むだろ。

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

AA木の削除操作はwikipediaのやつだとpred(自分より小さい値のうち一番大きいもの)とsucc(自分より大きい値のうち一番小さいもの)を
子ノードから取ってきた後に子ツリーに対して再帰的にdeleteをしてくってなってるけど、ノードの値がNoCopyだとRc使うかunsafe使うかしないと無駄なコピーが発生しない？

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

>>70
「他スレで実装してた人」って俺のことだな。
↓のスレのことだろ？

次世代言語Part7[Go Rust Swift Kotlin TypeScript]
https://mevius.5ch.net/test/read.cgi/tech/1508403098/

木構造は持ち主(親)が1つに限定されるはずのでRcもRefCellもいらないと思うよ。
実際、自分はOption<Box<_>>という形で実装してるし。
RcとRefCellの練習するんならグラフ構造とかがいいじゃないかな。
グラフ構造ならRcとRefCellはほぼ必須になるんじゃないかな。
グラフ構造はRustどころかC, C++でも実装したことないから詳しくは分からんけども。

>>72
俺の実装では、Option型のtakeメソッドを使ってるぞ。
そしてtakeメソッドの中ではunsafeが使われてる。だからコピーもないはず。
そのことじゃないのか？俺のほうが何か勘違いしてる？？

70 · 2017/11/08(水) 20:27:30.89

https://ideone.com/4BnXSI
・AA treeを実装
・1.8.0で主に確認(ideoneは1.14.0)
・今回はOption<Box<Node<T>>>中心に実装
・Tも<T: Copy>でコピーしちゃう
・肝心の木の操作部分は、wikipediaでの表現に近くなるように表現
・前の奴>>70のコピペから開始してるから妙なとこ残ってるかも

>>72
wikipedia見ただけでそのへんに着目できたのってすごい
前回は実はそこで一旦あきらめてコピーとOption<T>の導入に踏み切った
今回もTのコピーうんぬんについては挑戦せずそのまんまコピーしてる

**デフォルトの名無しさん** · 2017/11/09(木) 01:32:36.02

>>73 Option::takeを使って子ノードのsuccかpredの値を取ってくるとすると、その子ノードの値はNothingになるよね？
wikipediaの例だとその後にdeleteを再帰的に行うことで(delete内で適宜skew&splitを呼んでる)バランスを保つよう処理してるけど、Nothingが入ってる時点でうまく動く保証が無い
そのスレで書いてくれたものは要素としてCopyであるi32を使ってるから問題が見えないんじゃないかと思う

>>74 自分も>>73の例を見る前に多相型でちょっと書いてみて、どうすんだこれって気付いたんで偉そうなこと言えないっす
Rust固有の問題じゃないような気がしてるよ。C++とかで多相型にしてみたとしても、「子ノードの値を自身の値にする」って部分でコピーが行われる気がしてならない
一瞬だけどAA木の中に同じ値を持つノードが発生しているから、AA木の実装を綺麗に書こうとしたらT:Copy or T:Cloneって制約は必須なんじゃないかと

**デフォルトの名無しさん** · 2017/11/09(木) 03:38:46.05

>>75
ああ、なるほどね。
確かにi32の部分をTに置き換えると T: Copy か T: Clone が必須になるね。
これは確かに無駄なコピーが発生してるわ。
まぁ、この実装だとおそらく元になったwikipediaのコードの時点で
無駄なコピーが発生してることになるよね。
wikipediaの場合はi32(4byte)くらいならコピーしてもいいやってスタンスなのかな？
Tの場合は何byteになるか分からないからそういうわけにもいかないということかな？
これ以上は考えるのが面倒になってしまった。。。orz

70 · 2017/11/09(木) 19:44:06.23

https://ideone.com/dFoFa9
・>>70の<T: Copy>を<T: Clone>に変更
・ついでにRc付きで運用してみて様子を観察

でっかい構造体の場合はこういうふうなのがマシなのかな
Clone運用してるとこに、さらにRcもってくると気持ちよすぎ
おかげで内部の操作に由来した余計な割り当ては無くなった
CloneトレイトとRcには敬意を表したい

>>75
そこんとこの苦悩はもうしゃあないのかな
それについてはもう思考停止します

77 · 2017/11/09(木) 19:45:08.89

×・>>70の<T: Copy>を<T: Clone>に変更
○・>>74の<T: Copy>を<T: Clone>に変更

**デフォルトの名無しさん** · 2017/11/09(木) 20:45:25.15

rustのことはわからんけどコピーしないAA木は実装したことがあるので口を出させろください
「succかpredの値をnodeにコピーしてからsuccかpredを削除」しているわけなので
リンクを繋ぎ変えてsuccかpredとnodeをまるごと入れ替えるようにすれば、コピーは要らなくなりませんか

**デフォルトの名無しさん** · 2017/11/09(木) 22:34:40.35

コピーしない実装も不可能じゃないと思うけど、削除時の再平衡をちゃんと理解してないから分からん
ちょっと勉強してみるわ

**デフォルトの名無しさん** · 2017/11/10(金) 00:49:41.25

データ構造,アルゴリズム,デザインパターン総合ｽﾚ 3c2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1466315249/l50

**デフォルトの名無しさん** · 2017/11/10(金) 23:43:40.77

num crateって昔標準じゃなかったっけ？rustc_privateだけだっけ？

**デフォルトの名無しさん** · 2017/11/11(土) 03:49:20.94

Rustの日本語書籍ってまだ出てないのですか？

**デフォルトの名無しさん** · 2017/11/11(土) 21:51:46.65

>>83
https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/

**デフォルトの名無しさん** · 2017/11/12(日) 00:57:30.78

>>84
ありがとうございます

**デフォルトの名無しさん** · 2017/11/13(月) 15:07:53.78

言語は割といい感じなのに何でcargoはこんなにウンコなん(´・ω・`)

**デフォルトの名無しさん** · 2017/11/13(月) 21:10:10.81

cargoのどこが不満やねん

**デフォルトの名無しさん** · 2017/11/13(月) 21:12:20.77

ビルドとパッケージマネージャを一緒にしてcrates.io必須にして、他のビルドツールとの連携がつらいんでNIH症候群になりがちで、あんま好きになれないのがcargo
環境変数でビルド先のディレクトリが変わるけど、そこらへんのドキュメントも乏しいのが難点

**デフォルトの名無しさん** · 2017/11/14(火) 01:18:01.25

戻り値の型をflow sensitiveに推論してくれなくて、rustcが推論間違えてそれに気付くのに一日潰れてしまった。

>>86,88
わかる。囲い込んでるのにcargo自身が大したこと出来なくて色々困るんだよね。
色々方針が変わるし。mvnと同じ問題起こしたnpmと同じことしてるし。

言語は良いんだよ。

**デフォルトの名無しさん** · 2017/11/14(火) 01:25:20.09

rust製のOSSのウェブサーバーってないの？

**デフォルトの名無しさん** · 2017/11/14(火) 01:50:40.15

>>90
hyperかな　Webフレームワークのironやnickelがhyperに依存してる

**デフォルトの名無しさん** · 2017/11/14(火) 17:05:10.90

>>90
ロケット

**デフォルトの名無しさん** · 2017/11/14(火) 17:57:48.10

ウェブサーバーって書き方が悪かった
RocketやIronを使って実際に運営されてるウェブアプリはある？

小規模なTwitterクローンとかでいいんだけど

**デフォルトの名無しさん** · 2017/11/14(火) 22:28:34.56

server書いてます。フレームワーク書いてますは沢山あるけど運用例聞かないね、そう言えば。

**デフォルトの名無しさん** · 2017/11/15(水) 01:12:59.55

だってどこも使ってないもの
泥箱みたいなところはモジラから金もらって「使ってます」って提灯持ちしてるだけ

事例やソースが一切出てきてないのが証拠
いい加減Rustそのものがモジラのステマの産物だと認めろ。これはプログラミング言語ではない

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

プログラミング言語ではある

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

ディスりにモジラ絡める時点で長いこと荒らしてるいつもの暇人だってすぐ分かるんだよなあ
自分から具体的な話ができないししてもすぐ反論されて終わるもんだから他人の愚痴に便乗するしかできなくなってる

ボローチェッカに自分のコード全否定されて頭がおかしくなった可哀想な子を生み出したRustの業は深い

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

ボローチェッカにボローボローに否定されたんやなぁってやかましいわｗｗｗ

**デフォルトの名無しさん** · 2017/11/15(水) 06:53:08.67

つーかおまえらはrustで何書いてんの？

**デフォルトの名無しさん** · 2017/11/15(水) 10:20:38.06

それな
まだ仕事で使ってる人はいないだろうし