21/08/09 00:22:56.88 Xf+oNAim.net
Googleもサポートやめる
578:デフォルトの名無しさん
21/08/09 00:45:05.35 iRm2fJ4Y.net
C++/CLIのCLIってマイクロソフト.NETのでしょ
579:デフォルトの名無しさん
21/08/09 16:05:33.35 bWVDlgk2.net
LLVMのバックエンドがgcc並みになれば万事解決
580:デフォルトの名無しさん
21/08/09 16:10:16.25 OWI9S7jW.net
>>564
それが全てだろ。
開発コミュニティが長期的に維持されない (維持される見込みがない) なら
他の何が良くても産業的に使い難い。
581:デフォルトの名無しさん
21/08/09 16:57:51.57 qYrd5+ip.net
はぁ。
>>561はGCを持った仮想マシン環境に移植することがC++/CLIと似た状況だと言っていたのかと思ったが、
そこは全然これっぽっちも関係ない話なわけね。
開発コミュニティが途中で投げ出す恐れなんて言っていたらあらゆるものが当てはまりそうだが。
582:デフォルトの名無しさん
21/08/09 20:27:58.38 xgGPGjpP.net
競プロでRustを使ってみようと思って勉強してたんだけど、
再帰関数がめっちゃ面倒なのね
関数の外のスコープの変数の読み取りができないから、
全部引数に記述しなくちゃいけなくて凄い面倒
処理速度が速かったので期待してたんだけどな(´･ω･`)
583:デフォルトの名無しさん
21/08/09 20:38:14.63 yQGrG0lM.net
>>545
ダメの方で通るでしょ
宣言でStringを&'static strにする
"green"とだけ書けばプログラムコードのread onlyエリアに確保されて&'static strのライフタイムになる
Stringを使うとheapエリアを余分に使ってしまうので損
もちろん文字列が伸びたり一部書き換わったりなど対応したい時ならばStringを使う
584:デフォルトの名無しさん
21/08/09 21:19:46.40 9eWGuwAZ.net
>>570
全部引数渡しは当然だろう
問題なのは末尾再帰が出来ない事
585:デフォルトの名無しさん
21/08/09 21:26:05.96 fbmhz8DS.net
>>570
グローバル変数使いたいなら static mut 使えば良いのでは
unaafe 必要だけど別に安全性欲してないでしょ？
586:デフォルトの名無しさん
21/08/09 21:59:43.94 xgGPGjpP.net
>>573
マジかそんなんあんのか！！！！
static mut test: i32 = 0;
fn main() {
unsafe {
test = 1;
unsafe fn calc() {
if test == 1 { println!("yes") }
}
calc();
}
}
yes表示ｷﾀ━━(ﾟ∀ﾟ)━━!!
ありがとうありがとうヽ(´ー｀)ノ
587:デフォルトの名無しさん
21/08/10 00:56:57.83 u04QFiKf.net
純粋なグローバル変数は仕方ないけど、thread_localは
もっと簡単な使い方にしてほしかったなー
コールバック関数みたいに引数で渡せないパターンが面倒
588:デフォルトの名無しさん
21/08/10 01:04:05.56 1P7sVbl8.net
引数だけで解決できないなら設計が悪い
589:デフォルトの名無しさん
21/08/10 01:17:00.79 mSeKT5En.net
>>575
どうなって欲しいの？
590:デフォルトの名無しさん
21/08/10 02:01:49.31 pisrhHbj.net
競プロに向いてるかって言われるとそうでもない気はする
591:デフォルトの名無しさん
21/08/10 02:02:54.83 ukJY1zau.net
>>573-574
static mutは割とめんどくさい問題があるみたいだぞ
URLﾘﾝｸ(qiita.com)
592:デフォルトの名無しさん
21/08/10 02:13:08.50 KzRmJx3E.net
>>570
グローバル変数の代わりに関数の引数を増やすと毎回連れ回す形で見にくくなるけれど
再帰関数ではなく再帰メソッドにしてしまえば引数を増やさずにいくらでもパラメータを使えます
例えば「再帰で1からnまでの和や積」を求める例で「差分diff」が可変パラメータとした場合
struct Arith { diff: i32 }
impl Arith {
fn sum(&self, n: i32) -> i32 { if n <= 0 { 0 } else { n + self.sum(n - self.diff) } }
fn mul(&self, n: i32) -> i32 { if n <= 1 { 1 } else { n * self.mul(n - self.diff) } }
}
fn main() {
let diff1 = Arith { diff: 1 };
assert_eq!(diff1.sum(10), 55); // 1+2+3+4+5+6+7+8+9+10
assert_eq!(diff1.mul(7), 5040); // 1*2*3*4*5*6*7
let diff2 = Arith { diff: 2 };
assert_eq!(diff2.sum(10), 30); // 2+4+6+8+10
assert_eq!(diff2.mul(7), 105); // 1*3*5*7
}
今回はdiffの部分が1個だけですが複数のパラメータにもできます
こうすることで「グローバル変数を使わず」＆「引数を毎回連れ回さず」に書けます
593:デフォルトの名無しさん
21/08/10 04:53:07.24 yd00h36W.net
>>574
キャプチャしたいだけならクロージャ使えばいいけど
let test = 1;
let calc = || {
if test == 1 { println!("yes") }
};
calc();
再帰ならaccumulator的なものを連れ回すほうがいいと思う
594:デフォルトの名無しさん
21/08/10 05:14:22.44 gCWS4DSe.net
>>581
moveしなくていいの？
595:デフォルトの名無しさん
21/08/10 05:38:40.18 2mfgVpK+.net
struct使ってimplで&mut selfを持ち回せばいい気が
596:デフォルトの名無しさん
21/08/10 09:41:32.99 u04QFiKf.net
>>576
全部自分で作れるんならね
既存のライブラリとかOSのAPIとかの制限は自分じゃどうにもならん
597:デフォルトの名無しさん
21/08/10 09:51:21.46 u04QFiKf.net
>>577
.with使うのが面倒 .borrow_mutもね
そのまま読み書きしたい
そもそもstaticな時点で生存期間のチェックなんていらないんじゃないかと
598:デフォルトの名無しさん
21/08/10 14:05:16.63 mSeKT5En.net
>>585
可変参照が複数同時に存在すると即UBだから safe なコンテキストでは with や borrow は必須にせざるを得ないだろうね
RefCell とかと同じ
599:デフォルトの名無しさん
21/08/10 15:05:08.24 QyXjq7Ed.net
みんなありがとう、なんとなく再帰できたよ。やり方あってるかわからんけども
以下お試しプログラム
URLﾘﾝｸ(paiza.jp)
use std::*;
fn main() {
let mut str = String::new();
io::stdin().read_line(&mut str).unwrap();
let mut nums0: Vec<i32> = str.trim().split(" ").map(|it| it.parse().unwrap()).collect();
let mut test = Test { nums: nums0 };
println!("{}", test.calc(0));
}
pub struct Test {
nums: Vec<i32>,
}
impl Test {
pub fn calc(&mut self, id: i32) -> i32 {
if id == self.nums[0] { return 1; }
let mut res0: i32 = 0;
for i in 1..=3 {
if id + self.nums[i] <= self.nums[0] {
res0 += self.calc(id + self.nums[i as usize]);
}
}
return res0;
}
}
600:デフォルトの名無しさん
21/08/10 15:09:12.73 QyXjq7Ed.net
ちな、同じプログラムをkotlinで
fun main() {
var numList = readLine()!!.split(" ").map { it.toInt() }.toIntArray();
fun calc(id: Int): Int {
if (id == numList[0]) return 1
var res: Int = 0
for (i in 1..3) {
if (id + numList[i] <= numList[0])
res += calc(id + numList[i])
}
return res;
}
println(calc(0))
}
601:デフォルトの名無しさん
21/08/10 15:34:52.35 yd00h36W.net
>>587
このケースだとmutの必要もないし
単に`fn calc(id:i32, nums:Vec<i32>) -> i32`にすればよくない？
602:デフォルトの名無しさん
21/08/10 16:13:38.39 QyXjq7Ed.net
とりあえずできるかどうか適当に書いたものだからｗ
あと、これはindexだけを順繰りに送っていけばいいので引数1個でいいけど、
複雑な問題だとindexに、3次元配列の添え字として3つ、その配列本体、比較する配列の文字列とか、
さらにメモ化するためには、メモする配列もとか、めっちゃ引数がもの凄くなることがあるのね
だから、なんとかグローバル変数にアクセスできないかと思って
逆に構造体に全部の参照したい変数をまとめて、それだけを持ち回るとかもいいかもｗ
603:デフォルトの名無しさん
21/08/10 22:09:35.86 OZBv7QiC.net
再帰使うならもっと再帰っぽく書いてくれ
numsの初項とそれ以降の数値の意味が全く違うなら同じ変数に入れないでくれ
書き捨てや試行錯誤の途中ですらやらないぞこんなの
604:デフォルトの名無しさん
21/08/10 22:40:39.77 OOQ3UOoB.net
競プロってそういうもんだし……
605:デフォルトの名無しさん
21/08/10 22:43:09.06 QyXjq7Ed.net
>numsの初項とそれ以降の数値の意味が全く違うなら同じ変数に入れないでくれ
確かにそうなんだが、一度配列にいれちゃったからいいと思ってｗ
そして十分に再帰っぽいと思うけどなあ
↓スキルがありそうな人のご意見なので、もし良ければ再帰での美しい実装を披露して欲しい
↓参考にしたいのでよろしくお願いします
URLﾘﾝｸ(paiza.jp)
606:デフォルトの名無しさん
21/08/11 00:14:29.43 KIBLBTNR.net
スマン競プロなの失念してた。ならしょうがないゴメンよ
607:デフォルトの名無しさん
21/08/11 01:42:26.90 z0BKpdQB.net
dpに関しては再帰使わない方が計算量少なそう
608:デフォルトの名無しさん
21/08/11 02:02:46.71 umCpXnDX.net
>>592
競技プログラミングが何の実用的な実力に結びつかず、全く役に立たない遊びに過ぎない、と言われているのはそこですね
609:デフォルトの名無しさん
21/08/11 02:13:25.09 haNghl2/.net
再帰でメモ化したバージョンとループでボトムアップにしたバージョン
URLﾘﾝｸ(play.rust-lang.org)
テストはしてない
610:デフォルトの名無しさん
21/08/11 02:37:36.02 z0BKpdQB.net
メモ化するならグローバル変数(もしくは引数で渡す)にした方が良いんじゃないの？
611:デフォルトの名無しさん
21/08/11 02:55:43.83 oifoaA/x.net
>>596
競プロは戦闘機でいうところのアクロバット技術と同じようなものだな
アクロバット飛行はときに見るものを魅了するし部分的には実戦に通じるような高度な技術も必要だが
それ自体は実戦では役にたたず実戦でアクロバット飛行のような飛び方をしようものなら撃墜される
612:デフォルトの名無しさん
21/08/11 06:37:52.46 MmQ+sLSI.net
>>593
やってみた
入出力例のassertも通ったけどこれでいい？
fn main() {
assert_eq!(17, count(10, &vec![2, 3, 4]));
}
fn count(n: i32, abc: &[i32]) -> i32 {
if n < 0 { 0 } else if n == 0 { 1 } else { abc.iter().map(|a| count(n - a, abc)).sum() }
}
613:デフォルトの名無しさん
21/08/11 17:20:51.95 haNghl2/.net
>>598
そだね
少し数が増えるとめちゃ効率悪かったわ
614:デフォルトの名無しさん
21/08/11 18:22:13.11 iayIuizo.net
>>600
おお 与えられた数値をmapのなかでラムダ式で計算して、リストのsumするところが素晴らしいｗ
この場合はカウントだからsumだけど、最小値のminとか最大値のmaxとかでも利用できそうだ
615:デフォルトの名無しさん
21/08/11 20:10:22.26 iayIuizo.net
>>600
いま試しにやってみたけど、メモ化は必須だから、その美しさは保つことができなかった(´･ω･`)
616:デフォルトの名無しさん
21/08/11 20:23:36.62 haNghl2/.net
メモを連れ回す方式に修正した
borrowだと面倒なのでmoveにしたがRefCell使うともう少し速くなったりするのかもしれない
URLﾘﾝｸ(play.rust-lang.org)
617:デフォルトの名無しさん
21/08/11 20:39:47.21 zSuiQf57.net
競プロって計算量を落とせるアルゴリズムを考えることがポイントだと思うんだけど
実装言語の差異はどれくらい影響してくるの？
618:デフォルトの名無しさん
21/08/11 20:46:12.70 iayIuizo.net
>>605
あくまで参考だけど、こういうのがあるよ
URLﾘﾝｸ(twitter.com)
ただ3次元配列になると途端に速度が落ちるとか、そういうのもあるので鵜呑みにはできないけど傾向ってことで
あと、各言語の時間制限をしているサイトもある
URLﾘﾝｸ(paiza.jp)
この各言語の時間制限をみると、運営が考えている言語ごとの速度の違いが大まかにわかる
(deleted an unsolicited ad)
619:デフォルトの名無しさん
21/08/11 21:01:22.52 +LwnMsCS.net
競プロやっても日本の情報処理産業の国際的地位向上に結びつく気がしない
620:デフォルトの名無しさん
21/08/11 21:19:11.26 iayIuizo.net
そら趣味だもの。仕事とは関係ない
ただ、言ってる論理構成が、某小学生youtuberが義務教育なんか
必要ないって言ってる理屈と同じだなと感じる
621:デフォルトの名無しさん
21/08/12 00:24:49.53 pB2NXWq+.net
>>603
メモ化するならこう
fn main() {
let mut input_line = String::new();
std::io::stdin().read_line(&mut input_line).unwrap();
let input_numbers: Vec<i32> = input_line.split_whitespace().filter_map(|s| s.parse().ok()).collect();
let n = input_numbers[0];
let abc = &input_numbers[1..];
let mut memo: Vec<i32> = vec!(1);
memo.resize((n + 1) as usize, -1);
println!("{}", count(n, abc, &mut memo));
}
fn count(n: i32, abc: &[i32], memo: &mut [i32]) -> i32 {
abc.iter().map(|a| { let m = n - a; if m < 0 { 0 } else { if memo[m as usize] == -1 { memo[m as usize] = count(m, abc, memo); }; memo[m as usize] }}).sum()
}
622:デフォルトの名無しさん
21/08/12 02:22:16.40 WcppFbZK.net
>>608
むしろ義務教育でyoutube撮影方法教えるべきだとか主張するアホと一緒だろ
623:デフォルトの名無しさん
21/08/12 04:12:25.44 /wS1lumL.net
>>608
資格主義や学歴主義もだけど戦略不在でそれ自体が目的化しているように感じる
手段が目的化して迷走している事例は腐るほどあるような
624:デフォルトの名無しさん
21/08/12 14:49:35.08 xCjM/E2I.net
競プロはある種のパズル
パズルを解いたり競ったりを楽しむのもの
パズルをたくさん解くことで仕事のプログラミングに活きる部分がなくも無いが
その二つを同一視してる人は有害
625:デフォルトの名無しさん
21/08/12 15:56:43.60 id/zPgju.net
同一視してるというか
同一視された方が有利になれる人が同一視するように仕向けている
それ誰よっていうと、サロン屋や人材屋
626:デフォルトの名無しさん
21/08/12 18:29:44.63 /wS1lumL.net
○○検定とかも同じ臭いがする
627:デフォルトの名無しさん
21/08/12 18:49:01.38 5/ThobAf.net
キャベツ？
628:デフォルトの名無しさん
21/08/13 02:12:49.72 nWHbUrjv.net
Rustlingsの問題なんだけど、これの37行目のmutってなんで必要なの？？？
URLﾘﾝｸ(ideone.com)
参照するアドレスが変わるわけでもないのに・・・・どう理解すればいいものなんだろう・・・・
それと、ある構造体を構成するメンバーって、全部がmutか否かの二択になっちゃうわけ？混ぜれないの？？？
629:デフォルトの名無しさん
21/08/13 02:51:10.09 FruLH7M6.net
>>616
え？どこに参照が出てきているの？構造体そのものでしょ
そして直後に構造体の中を書き換えているからmutが必要
そして構造体のメンバーはバラバラに生死貸借が起きることはないからメンバー個別の指定の必要性はない
630:デフォルトの名無しさん
21/08/13 02:55:04.80 E7XaaQej.net
38,39でその構造体のメンバーに代入するのに必要
631:デフォルトの名無しさん
21/08/13 11:51:53.45 FT9FF6Ap.net
>>616
1. let mut x = create_order();
2. let mut x = &create_order();
3. let y = &mut create_order();
4. let mut y = &mut create_order();
それぞれ何がmutableなのか違う
「参照するアドレスが変わるわけでもないのに」ってのは3番目をイメージしてると思われる
632:デフォルトの名無しさん
21/08/13 18:27:47.71 fDsS9u/P.net
let mut your_name = Some(String::from("変更前"));
match robot_name {
Some(ref mut name) => *name = String::from("変更後"),
None => (),
}
println!("君の名は。: {:?}", your_name);
633:デフォルトの名無しさん
21/08/14 04:36:12.68 ndgh8Ezu.net
初歩的な申し訳ないんだが
let x = "hello".to_string(); // convart text to a string テキストを文字列に変換
let y = String::from("hello"); // get text directly テキストを直接取得
これの違いがわかりません
やってること同じですよね？
出力の違いが出る例とかあれば教えてもらえないでしょうか？
634:デフォルトの名無しさん
21/08/14 06:01:03.88 AK8F+nV0.net
to_stringはinlineでString::fromしてるから全く同じ
impl ToString for str {
#[inline]
fn to_string(&self) -> String {
String::from(self)
}
}
635:デフォルトの名無しさん
21/08/14 06:06:43.67 ndgh8Ezu.net
>>622
早朝からレス感謝
もやもやがとれて勉強に集中できそうです
ありがとうございました
636:デフォルトの名無しさん
21/08/15 13:09:40.85 QO3tNTj5.net
社員120人が原則テレワーク、「在宅勤務を語ろうチャット」で不安解消 ピクスタ流の働き方
URLﾘﾝｸ(www.itmedia.co.jp)
正社員ゼロ､会議ゼロのベンチャーが､急成長している驚きの秘密
URLﾘﾝｸ(president.jp)
テレワーク率95％をキープ！ “全員原則テレワーク企業”が導入した「Uber手当」「Zoom飲み会代」
URLﾘﾝｸ(www.itmedia.co.jp)
驚異のテレワーク率「9割超」 営業利益16倍の企業は、生産性が「下がった」社員をどのようにケアしたのか
URLﾘﾝｸ(www.itmedia.co.jp)
Withコロナ時代の営業改革とは？アステリアが説く「ワークログ」と「マイクロラーニング」の重要性
URLﾘﾝｸ(saleszine.jp)
出社率100％→50％ オフィスレイアウトの変更例 社員が「オフィスに行く理由」を考慮せよ
URLﾘﾝｸ(www.itmedia.co.jp)
キャンピングカーでテレワーク 京急などが実証実験
URLﾘﾝｸ(www.itmedia.co.jp)
コロナ禍で働き方が激変 これからのシェアオフィスに必要なものとは？
URLﾘﾝｸ(www.itmedia.co.jp)
【サンフロンティア不動産】～通うオフィスから“集うオフィス”へ
アフターコロナ時代の働き方を提案するワークプレイス「LIT（リット）」2021年５月オープン
URLﾘﾝｸ(prtimes.jp)
637:デフォルトの名無しさん
21/08/16 09:44:36.63 MZWGbmHz.net
loop式はbreakで指定した値を返せるのに
なぜwhile式やfor式は値を返せないの？
Option型にしてbreakで値を指定した時だけSome(値)としてそれ以外はNoneとすれば便利なのに
638:デフォルトの名無しさん
21/08/16 10:30:33.78 rx7L9F9W.net
(while true のような実質無条件ループを除き)条件付きループをbreakで抜けるのは可読性を下げる要因になるから一般的にはRustに限らずできるだけ避けるだろ
悪い作法を推奨するような機能は付けるべきではない
639:デフォルトの名無しさん
21/08/16 10:39:16.03 WTBg47DG.net
ほぉたしかにそうゆうのあれば便利な時もありそう
macroで似たような物は作れそうな気がする
たしかにlispとかでもwhileはnil returnだな(´・ω・｀)
640:デフォルトの名無しさん
21/08/16 12:47:44.44 meTevnZp.net
>>626
forでお目当てのものが見つかったらその時の値を欲しい時
当然そこで打ち切りたいから普通にbreakすると思うが君は回り続けるのかね？
641:デフォルトの名無しさん
21/08/16 14:09:14.90 ScFkjf4y.net
>>628
打ち切りたいなら、take_whileの結果を対して回せばよくね？
642:デフォルトの名無しさん
21/08/16 14:32:54.40 ebJKRLr3.net
手間かけて機能拡張するほどのメリットがないってことだろうね
URLﾘﾝｸ(github.com)
643:デフォルトの名無しさん
21/08/16 16:29:22.27 RqqPeHPy.net
つまりforやwhileではなくiterを使うかloopを使えってことか
644:デフォルトの名無しさん
21/08/16 16:36:53.53 iL7TnNF0.net
awaitとか ? が絡むとループ使いたい場合はあるかもね
645:デフォルトの名無しさん
21/08/16 16:57:08.35 QDTL5fKB.net
>>632
それらメソッドチェーン部分ではもちろん使えるけど
iter系で指定するクロージャの中でも使えるんだっけ？
646:デフォルトの名無しさん
21/08/16 20:57:35.53 iL7TnNF0.net
>>633
Item が Option や Result なら ? は使えるけど
await は async fn か async block の中でしか使えないからほぼ使えないと思ってよさそう
647:デフォルトの名無しさん
21/08/16 22:05:08.22 bBW7ChkS.net
featuresは？
648:デフォルトの名無しさん
21/08/16 23:25:05.01 e18AJ9DT.net
>>634
?の方だけど、NoneやErrを除外してSomeやOkの皮を外すのはfilter_map使わないとメンドイね
例えばこんな感じで「?」はクロージャ内で使えた
println!("{}", std::env::args().filter_map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<String>());
実行結果
$ cargo run 4 test 7 5 987654321 6
rust
649:デフォルトの名無しさん
21/08/17 01:06:37.74 diXkc4zq.net
>>636
これは filter_map よりも map().collect::<Result<String, _>>() の方がよさそう
650:デフォルトの名無しさん
21/08/17 01:42:37.78 2Xo4qCNa.net
全く関係ないけど、
for x in v
には、
for x in &v
for x in &mut v
for x in v.iter()
のようなバリエーションもあるようだけど、
for &x in v
のような書き方も出来るの？
あと、v と書いても v.iter() の省略なの？
この辺の話はどこに書いてる？
651:デフォルトの名無しさん
21/08/17 01:44:24.62 2Xo4qCNa.net
>>638
ついでに、
let x = &y;
は、
let &x = &y;
let &x = y;
みたいに書くことも出来るの？？？
652:デフォルトの名無しさん
21/08/17 01:46:10.93 yPn/BtRt.net
>>638-639
左辺と右辺はパターンマッチで対応するメカニズムになっている。
653:デフォルトの名無しさん
21/08/17 02:15:00.92 Ok9gkDKS.net
>>638
forの展開はこ�
654:ﾌ辺とか。.iter()じゃなくて.into_iter()やね https://doc.rust-lang.org/reference/expressions/loop-expr.html#iterator-loops
655:デフォルトの名無しさん
21/08/17 03:20:14.87 q/ldIEfm.net
この言語の敷居の高さの上げ方は異常すぎる。誰も全容分かってない
656:デフォルトの名無しさん
21/08/17 03:39:07.39 yPn/BtRt.net
C++ よりマシ。
657:デフォルトの名無しさん
21/08/17 04:00:51.74 run+2ZVZ.net
それだと最初のエラーを拾ってしまうけど今回はエラーになる引数を与えてそれらを無視して拾い集めるコード
もしエラーにならない引数だけを与えて成功するコードならばその方針もいいかも
あとfrom_u32はOptionを返すのでResultでなく全体をOptionにするとして
最後にunwrapも必要なのでmap().collect()のコードは以下になると思いますが
元の>>636より長くなってしまいますね
println!("{}", std::env::args().skip(1).map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<Option<String>>().unwrap());
実行結果
$ cargo run 4 7 5 6
rust
658:デフォルトの名無しさん
21/08/17 09:39:00.09 Wyc5eeHq.net
小中学生あたりでもわかる本ある？
659:デフォルトの名無しさん
21/08/17 09:48:35.92 uTdncVPo.net
きったねぇコードだな
660:デフォルトの名無しさん
21/08/17 13:39:50.79 hwU1GG4D.net
参照型の変数xをlet文で新しい変数yの初期値にした場合、
let a = 123;
let x:&i32 = &a;
let y = x;
y は参照型になるんだっけ？
そもそも、最初の文は
let x = &a;
と書いても全く同じ意味だっけ？ さらに、
let x:&i32 = a;
と書いても同じ？
661:デフォルトの名無しさん
21/08/17 14:30:13.21 082KifEP.net
>>647
試してみるといいよ
yの型を知りたければtype_of(&y)で
fn type_of<T>(_: &T) -> &str {
std::any::type_name::<T>()
}
let a = 123;
let x = &a;
let y = x;
println!("{}:{}, {}:{}", x, type_of(&x), y, type_of(&y));
662:デフォルトの名無しさん
21/08/17 14:31:53.69 hwU1GG4D.net
答えを知ってる人に書いて欲しい。
この言語、試してみないと型すら分からないんだったら困るな。
663:デフォルトの名無しさん
21/08/17 14:35:58.73 Ok9gkDKS.net
>>647
> y は参照型になるんだっけ？
なる
> そもそも、最初の文は
> let x = &a;
> と書いても全く同じ意味だっけ？
ほぼ同じ
下だとaの型がi32に固定されない点だけ違う
> さらに、
> let x:&i32 = a;
> と書いても同じ？
これは全然違う
そもそも型エラーでコンパイルできない
664:デフォルトの名無しさん
21/08/17 14:41:24.86 QXNoWfC2.net
>>647
めちゃ基本的なことなので入門書を読もう
665:デフォルトの名無しさん
21/08/17 14:45:56.55 hwU1GG4D.net
本を読んだけど、明確には書いてなかったと思う。
let文に置いて参照型が右辺の場合、左辺も参照型になるということなのか。
ということは、letを書かない代入文で左辺に参照型で無い型を
書いて、右辺に参照型がある場合にはエラーになるのか？？？
わけが分からん。
666:デフォルトの名無しさん
21/08/17 14:51:57.21 WvkHdE3s.net
C++出身の人かな
667:デフォルトの名無しさん
21/08/17 15:00:35.72 hwU1GG4D.net
C++出身だ。
Rustにおける参照型の変数の規則性が分からない。
668:デフォルトの名無しさん
21/08/17 15:06:15.30 Ok9gkDKS.net
>>654
Rustの参照はC++の参照じゃなくてポインタのほうが近いよ
669:デフォルトの名無しさん
21/08/17 15:06:32.93 uFWUzCTr.net
Rustから入る人や
色々な言語をやってきた人は理解が早い
しかしC++だけやJavaだけしか経験ない人は
自己中な思い込みが激しくて素直に学習しようとせずに間違った解釈したりして無駄な質問ばかりしがち
670:デフォルトの名無しさん
21/08/17 15:06:36.98 hwU1GG4D.net
Rustは例はあるが、ちゃんとした論理的な言葉や数式の様なもので、規則性が
書いてないのではない？
C++だともっと厳密に書いてある。
671:デフォルトの名無しさん
21/08/17 15:10:48.52 +ZvfT+RK.net
>>652
何て本？
672:デフォルトの名無しさん
21/08/17 15:11:29.96 hwU1GG4D.net
>>656
そうではなくて、規則性を言葉で書いてくれ、ということだよ。
試してみてなんとなくの経験法則とかじゃなく。
673:デフォルトの名無しさん
21/08/17 15:12:37.71 hwU1GG4D.net
>>658
bookの印刷版も読んだが、途中読み飛ばしたページもあるが
読んだところにはちゃんと書いてなかったと思う。
数学的な規則が欲しいんだ。
文学的な言葉や例ではなく。
674:デフォルトの名無しさん
21/08/17 15:13:56.74 Ok9gkDKS.net
>>657
そういう位置付けのドキュメントはこれだね
ただし冒頭にもある通り完全ではない
The Rust Reference
URLﾘﾝｸ(doc.rust-lang.org)
675:デフォルトの名無しさん
21/08/17 15:15:28.48 Y5PdM7En.net
>>656
まずはC++を忘れろ
思い込みは習得の邪魔になる
あるいは様々な言語をやってきていれば各言語で概念や書式や用語などが少しずつ異なることが理解できるはずだ
676:デフォルトの名無しさん
21/08/17 15:18:24.83 hwU1GG4D.net
>>662
めんどくさいので試してないんだよ。
試さなくても数学の用に読んで理解できる規則が欲しい。
Cのポインタは難しいとされるが、俺は数学が得意なので本を読んだだけで
完璧に理解できた。
C++探せばちゃんと書いてある本がある。
677:デフォルトの名無しさん
21/08/17 15:23:08.50 hwU1GG4D.net
>>661
BNFで書いてあるようだが、具体的にどこに書いてあるか示してくれ。
ちなみにBNFだと意味論までは語れ無い事があるので無理かも知れない。
678:デフォルトの名無しさん
21/08/17 15:24:30.00 +8wra73u.net
「俺は数学が得意なんだ！」
ワロタ
いつものBoxおじいさんじゃん
679:デフォルトの名無しさん
21/08/17 15:24:31.45 hwU1GG4D.net
目次を見てもReferenceの文字が見当たらないが。
C++だとちゃんとあるぞ。
どうしてReferenceも型のはずなのに、目次すらないんだよ。
680:デフォルトの名無しさん
21/08/17 15:25:31.33 hwU1GG4D.net
>>665
トップだったからな。
681:デフォルトの名無しさん
21/08/17 15:27:48.00 bPhCjiXF.net
>>660
そこまで言うならば十数種類あるRustドキュメントのうち、
editionとapiとstdとreferenceとtheとcookとexampleあたりにあとはcliとasyncくらいまでが基礎かな。
あと外部たがcargoとrustcにrustdocなどのbookも。
unstableやnomiconは後でいい。
wasmやembedded系bookも必要なら。
682:デフォルトの名無しさん
21/08/17 15:28:18.82 jTG+Bjsl.net
IQ87の人でしょ
相手しちゃダメ
683:デフォルトの名無しさん
21/08/17 15:29:44.40 hwU1GG4D.net
>>668
なんで、この言語に置いて最も重要な型の一つの規則性がそんな何千ページもの
本を読まないと解説されてないんだよ。
684:デフォルトの名無しさん
21/08/17 15:30:14.32 hwU1GG4D.net
>>669
お前の友達と一緒にすんな。
685:デフォルトの名無しさん
21/08/17 15:35:47.16 JF4CPCdG.net
>>667
数学得意ならRustも深く理解しやすい
強い静的な型システムの元にある
そして生死貸借も明確で数学的にメモリ安全性を保証
利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない
686:デフォルトの名無しさん
21/08/17 15:44:19.09 hwU1GG4D.net
>>672
さっきから聞いているのに、ちゃんとした論理的規則を語った人は誰も居ない。
つまり、今このスレに居る人達は誰も理解してない証拠だろう。
つまりこれは、Rustが試してみないと分からない言語だからではないか。
687:デフォルトの名無しさん
21/08/17 15:46:21.18 diXkc4zq.net
>>673
5chじゃなくて users.rust-lang.org あたりで聞いてみたら
専門家がいっぱいいるよ
688:デフォルトの名無しさん
21/08/17 15:48:51.11 hwU1GG4D.net
>>674
参照型はRustにとって最重要の型。
それがそんなところに質問しなければ分からないというのは困ったことだぞ。
689:デフォルトの名無しさん
21/08/17 15:56:13.41 UjpqRJxn.net
ポインタを理解するのにもRustを理解するのにも数学の得意不得意は関係なくね？
ポインタを理解できない人をあまり多く見たことがないから実際のところどうなのかよく分からないんだが
690:デフォルトの名無しさん
21/08/17 15:57:56.00 U4J278+6.net
>>670
どこにも記述されていないことを君が自己中心的な思い込みで間違いなく判断や間違った推測をしているから>>647や>>652の書き込みになっている
let文や呼び出し引数はirrefutable pattern matchingであり各種destruturingはあっても個々の型は対応する
Tと&Tがmatchingすることはない
691:デフォルトの名無しさん
21/08/17 15:59:25.04 hwU1GG4D.net
>>677
どから、それがどこに書いているのかリンクを張ってくれ。
あなたの独自説ではなく、公式のな。
692:デフォルトの名無しさん
21/08/17 16:06:26.36 KRsjniKD.net
>>672
>利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない
rustではcoercionと呼んでるものが暗黙の型変換だぞ
693:デフォルトの名無しさん
21/08/17 17:16:17.31 uVOQbHaf.net
グリーンスレッド何それ？さんだっけ？
694:デフォルトの名無しさん
21/08/17 17:20:32.19 apgY8ckc.net
公式の言葉が欲しいってならreferenceのlet statement, reference patternsあたりでもみりゃいいんじゃないっすかね知らんけど
695:デフォルトの名無しさん
21/08/17 17:32:50.74 fMgDzJWA.net
rustは思ったより流行りそうにないなぁ。
使用者爆発的に増えてくるハズがC++知らん人は
そもそも使う層じゃないし、
C++知ってる人は、逆にめんどくさいから様子見、流行らなければスルー
ぐらいかね。
696:デフォルトの名無しさん
21/08/17 18:03:44.37 PENy3uzh.net
ぶっちゃけ1言語のみしか使えないようなプログラマが有能だとはとても思えないが
実際にそういう人はいるけど融通効かないし生産性が高いとも思えない
所詮ドカタじゃないの
697:デフォルトの名無しさん
21/08/17 18:14:54.04 yPn/BtRt.net
>>682
C++ で疲弊した人が Rust に移ってるってのはあるぞ。
698:デフォルトの名無しさん
21/08/17 18:21:01.37 diXkc4zq.net
>>675
だからそう主張してくればよいじゃん
ここにいる人じゃ話にならないんでしょ？
699:デフォルトの名無しさん
21/08/17 20:01:51.20 uTdncVPo.net
疲弊というかドロップアウター
700:デフォルトの名無しさん
21/08/17 21:03:40.91 iE5VyQYC.net
>>647
上３つの式は正しいのに、なんで下２つの式はそうなるのか
701:デフォルトの名無しさん
21/08/17 21:04:44.45 iE5VyQYC.net
>>687
見間違えた
一番下の式だけだね
702:デフォルトの名無しさん
21/08/17 21:18:21.30 sY2NwSu8.net
実際はc++わからんけどrustわかればマウント取れそうじゃね？って馬鹿しか手を出してないという現実。
703:デフォルトの名無しさん
21/08/17 21:24:14.87 hwU1GG4D.net
Rustは、GoogleTrendsでは他の言語に比べて低空飛行だけど(Kotlinと同じくらい
ではあるが)、他の言語が下がる傾向があるのに対してRustだけは少しずつ上がってる。
Stackoverflowでは既にC++の30%～40%位まで質問の量が迫ってきているとか。
なので良く分からない。
GoogleTrendsが実際と合ってないという説も見かけた。
704:デフォルトの名無しさん
21/08/17 21:26:37.22 hwU1GG4D.net
crates.ioでcrateをダウンロードされた回数が20億回を越えていたり、
投稿されたcrateの数が3万種類を超えたりとか。
20億回というのはとんでもない大きな数字。
全世界のプログラマの数は2,500万人くらいだそうだから相当な数だ。
良く分からないくらい異常に大きな数値。
705:デフォルトの名無しさん
21/08/17 21:35:56.30 hYkkAkQv.net
iocrateはきっと誰かがwhile true do; cargo build; cargo clean;doneみたいの流し続けたんだろ
c++よりマシなのは確かだがredosだかみたいの全然進まんしc++,cな代替物にはなれなさそう
tech giantsみたいな連中が根幹部分rustに変えるみたいな事言ってるけど流行ってる感じ全然しないよね(´・ω・｀)
706:デフォルトの名無しさん
21/08/17 21:40:50.24 jTG+Bjsl.net
久しぶりに流行ってない流行らないアピールきてるね
707:デフォルトの名無しさん
21/08/17 21:41:43.37 LO76a4+c.net
土方では流行らないでしょ
708:デフォルトの名無しさん
21/08/17 21:45:28.03 yac5fWyQ.net
リポジトリの分散化考えないとマジ負荷が半端無さそう
709:デフォルトの名無しさん
21/08/17 21:49:53.88 fMgDzJWA.net
rustで作ったライブラリは他の言語から使いやすいんかい？
c\c++置き換えるなら、むしろそここそ一番重要かもしれん。
710:デフォルトの名無しさん
21/08/17 22:12:04.05 53TH2cCY.net
>>696
Rustのライブラリは他言語からは使いにくいのが問題になっていると聞いたが。
多分、C/C++のライブラリのようにはいかないと思う。
711:デフォルトの名無しさん
21/08/17 22:14:00.60 53TH2cCY.net
>>692
前半、なるほど。
githubで最高人気であるところのvue.jsも、いいねは2万くらいだったと思うし。
なんか数値に異常さを感じる。
712:デフォルトの名無しさん
21/08/17 22:16:21.15 53TH2cCY.net
vue.jsのgithubでのStar数は、18万7,000だった。
crate.ioのダウンロード回数はこの1万倍を越えている。
普通に使っているだけでは辻褄が合いそうに無いな。
全世界の全てのプログラマが100回くらいcrateをダウンロードしたことになる。
713:デフォルトの名無しさん
21/08/17 22:54:36.64 Ok9gkDKS.net
crates.ioのDL数と比較すべきはnpmのDL数では？
URLﾘﾝｸ(www.npmtrends.com)
714:デフォルトの名無しさん
21/08/18 00:15:56.99 24ORvnDg.net
crates.ioのダウンロード数は依存crateのCIが走る度に増えるようなものだからそりゃ多くなるでしょ
GitHubのstarと比較したのはなぜ？
715:デフォルトの名無しさん
21/08/18 00:33:37.55 c7Y+RcIr.net
別にプログラマが手動でダウンロードするわけではないんだが…
1回コンパイルすると100個以上落としてくるのも普通だから
2千万回コンパイルが実行された、という程度の話
ざっくり5年で均せば1日1万回ってとこか
716:デフォルトの名無しさん
21/08/18 01:06:03.53 WOvB8ChX.net
CIだろうね。人がcargoを直に打ってるとは思えん
717:デフォルトの名無しさん
21/08/18 01:16:27.76 wcIqldgw.net
強力にキャッシュが効くはずのCIでツールが未整備なために効かず
異常にDL数が伸びてしまっただけだろう
718:デフォルトの名無しさん
21/08/18 04:35:06.87 AXrkZvXQ.net
CIのライブラリインストールが動画の次に無駄な帯域を食ってると言われているだけある
719:デフォルトの名無しさん
21/08/18 09:18:01.26 k0LDI8WO.net
>>639
難しく考えすぎ
&と*の関係は単純明白
let a = 123; // a: i32
let b = a; // b: i32
let p = &b; // p: &i32
let q = p; // q: &i32
let &r = &p; // r: &i32
let x = &q; // x: &&i32
let s = *x; // s: &i32
let c = *r; // c: i32
let y = &&c // y: &&i32
let z = y; // z: &&i32
let d = **z; // d: i32
720:デフォルトの名無しさん
21/08/18 09:35:44.42 GD93l4al.net
ライブラリが他言語から使いにくいってのも謎だな
他言語からならC ABI一択なわけで、どの言語でライブラリ書こうが使い勝手は同じだと思うが
721:デフォルトの名無しさん
21/08/18 09:48:19.81 JVjfL7Fa.net
>>697
例えばPyO3でPythonからRust呼び出せるよ
722:デフォルトの名無しさん
21/08/18 10:49:15.04 NS5B/B7Q.net
>>672
自動的な参照外し(*を記載してないのに*適用)って、値を使うところで&Tや&&Tなどが使われたときにTの値になる、というルールだからそれも数学的でしょ。
あと&Tではない各種スマートポインタや自作の型を、*記載で参照外しする時も、Derefトレイト実装通りに行われるからこれも数学的。
723:デフォルトの名無しさん
21/08/18 11:27:15.93 k0LDI8WO.net
>>647氏が混乱したのもそこかもね
例えば
let a = 99;
let b = &a;
assert_eq!(100, b + 1);
assert_eq!(100, *b + 1);
つまり値を使う所では参照のままではなく安全に*が自動適用
構造体のフィールドアクセスも
struct Point {x: i32, y: i32}
let p = Point {x: 19, y: 31};
let q = &p;
assert_eq!(p.x, q.x);
assert_eq!(p.y, (*q).y);
つまりフィールドアクセスする所では参照のままではなく安全に*が自動適用
だからC言語などにある「q->y」という記法がRustには不要なので存在しない
724:デフォルトの名無しさん
21/08/18 11:41:08.71 XfIyaV62.net
こじつけの自己レス自演が気持ち悪い
これでバレないとおもってるんだからww
お前も頑張って勉強中なの丸出しなのになぜそんなに上から目線で書きたがる？
725:デフォルトの名無しさん
21/08/18 12:12:05.22 cmZsMbhP.net
>>710
assert_eq!(100, b + 1); は通るけど
assert_eq!(99, b); はコンパイルエラーになるところがミソかな
726:デフォルトの名無しさん
21/08/18 12:12:56.84 Lbl25gGI.net
演算子も含めてメソッド呼出しのときの self の参照が調整されるのは言語コアの機能だけど
演算子の右辺で参照が剥がされるのは参照を受け取るバージョンのメソッドも用意されてるから
という理解でいいんだよね？
727:デフォルトの名無しさん
21/08/18 12:16:13.67 UTiWVDvk.net
>>710
>assert_eq!(100, b + 1);
`b + 1`のbは*が自動適用されてるわけじゃない
728:デフォルトの名無しさん
21/08/18 12:52:27.85 KGSse8GZ.net
そこはstd::ops::Addトレイトのimplがあるかどうか
ただしi32と&i32に対してはあるけど&&i32に対してはない
そのためさきほどの例だと
let a = 99;
let c = &&a;
assert_eq!(100, **c + 1); // i32はそのままOK
assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
assert_eq!(100, c + 1); // &&i32のAddトレイト定義はないからコンパイルエラー
729:デフォルトの名無しさん
21/08/18 13:56:40.85 XmrgRQmj.net
繰り返し間違った内容垂れ流すのいい加減やめれ
730:デフォルトの名無しさん
21/08/18 14:02:16.47 NAGfODce.net
>>715で合ってるよ
731:デフォルトの名無しさん
21/08/18 14:42:37.07 tdn9Bdbv.net
ご愁傷様
732:デフォルトの名無しさん
21/08/18 15:05:20.49 PR0UGd3d.net
ご安全に*
733:デフォルトの名無しさん
21/08/18 19:37:59.33 e8CK2aK/.net
質問したようなのと近い流れになってて助かった
(0..7).filter(|&x| x == 0);
↑これ通るから ↓こうしたら駄目だった。なんでなん？
let mut vec0 = vec![1, 2, 3, 4, 5, 6];
vec0.iter().filter(|&x| x == 1);
そこで、様々テストしたら、↓の方法でコンパイルが通ることがわかった
どのやり方が一般的なん？個人的には1か4かと思うんだけど。あと、2は+0することで型推論が働いてるのん？
vec0.iter().filter(|&x| *x == 1); //1
vec0.iter().filter(|&x| x + 0 == 1); //2
vec0.iter().filter(|&x| x == &1); //3
vec0.iter().filter(|&x| x.clone() == 1); //4
vec0.iter().filter(|x| **x == 1); //5
vec0.iter().filter(|x| *x == &1); //6
734:デフォルトの名無しさん
21/08/18 19:43:27.81 4IMEZtM2.net
全部結果まで含めて正しかった？
735:デフォルトの名無しさん
21/08/18 19:48:58.01 e8CK2aK/.net
ベクタの内容を↓にして
let mut vec0 = vec![1, 2, 1, 4, 1, 6];
1の数をcountするようにして表示させてみたけど、>>720の1～6のやり方でどれもcountの数は同じだね
736:デフォルトの名無しさん
21/08/18 20:01:07.37 e8CK2aK/.net
いいぞ！いいぞ！これも通るぞ！！
let mut test6 = vec0.iter().filter(|&&x| x == 1).count();
let mut test7 = vec0.iter().filter(|x| x == &&1).count();
let mut test8 = vec0.iter().filter(|x| *x + 0 == 1).count();
ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ
737:デフォルトの名無しさん
21/08/18 20:03:48.63 gDWYR9GO.net
Bible終えるのにどれぐらい時間かかりましたか？
738:デフォルトの名無しさん
21/08/18 20:30:38.07 4eCzRIG7.net
>>720
739: (0..7).filter(|&x| x == 0);と同等なのは let v = vec![1,2,3,4,5,6]; v.into_iter().filter(|&x| x==0);
740:デフォルトの名無しさん
21/08/18 20:47:56.15 e8CK2aK/.net
>>725
うおー、まじか！
わかったありがとう。だからforループはちょっと違う挙動になるんだな
741:デフォルトの名無しさん
21/08/18 21:38:07.08 KGSse8GZ.net
違いをわかりやすく示すと
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());
742:デフォルトの名無しさん
21/08/18 21:41:22.71 e8CK2aK/.net
ありがとうありがとう
&TのイテレータとTのイテレータが別々になっているとはおもわなんだ
743:デフォルトの名無しさん
21/08/18 21:54:22.03 8n3xPETQ.net
まだ慣れてないからideに言われるがままに直してるな、、
744:デフォルトの名無しさん
21/08/18 22:38:04.93 ErZJGc/A.net
イテレータ回りはこのスライドが良いと思ったけど多少基礎知識ないときついかもしれんな
URLﾘﾝｸ(speakerdeck.com)
745:デフォルトの名無しさん
21/08/18 23:13:44.45 KGSse8GZ.net
>>728
そう考えるよりもムーブor借用と捉えるほうがいいかな
vec0.into_iter()だとムーブになるから値そのものが次々と来る。しかしその後にvec0は使えない。
vec0.iter()だと借用になるから値への参照が次々と来る。その後もvec0は使える。
(&vec0).into_iter()でも借用になるから値への参照が次々と来る。その後もvec0は使える。
746:デフォルトの名無しさん
21/08/19 02:05:43.13 58T7qCMn.net
この2つは何が違うんですか？
演算子?
URLﾘﾝｸ(tourofrust.com)
unwrap
URLﾘﾝｸ(tourofrust.com)
747:はちみつ餃子
21/08/19 02:52:20.85 z/GAGLjl.net
>>732
これは例がよくないな。
もう一段ほど関数呼出しを挟む構造になっていればより分かり易くなる気がする。
? 演算子はエラーだったときにそのエラー値を返り値として return する。
つまりその例の場合は do_something_that_might_fail が
エラー値を返したときは main から抜ける。
関数がエラーを出したときに上位にもエラーとして伝播させる機能。
unwrap は Result を剥がすが、エラー値だったときにはその場で panic する。
unwrap を書くというのは「エラー値が返されることはないことをプログラマとして保証する」
または「そのエラーに対して対処する方法はない、対処する気はない」という表明で、
assert 的な意味合いを含む。
エラーの対処を書くのが面倒だけど Result を剥がして型は合わせないといけない
というときに雑に unwrap することはあるんだけど、
多少なりとも汎用的なライブラリにするなら (事前条件が正しい限り) panic が
起こるのは好ましくはないので使い方は慎重に。
748:デフォルトの名無しさん
21/08/19 03:04:22.69 KOsZ1Iay.net
>>732
?演算子はほぼtry!マクロのsyntax sugar
言語自体に組み込んだ時にその適用範囲を広げた
try!マクロとは見やすく省略して書くと
Result型rに対してはtry!(r)がほぼmatch r { Ok(n) => n, Err(e) => return Err(e) }となる
つまり?演算子はOption型やResult型の尻につけてNoneやErrの時にreturnする
一方でunwrapはpanicして死ぬ
749:デフォルトの名無しさん
21/08/19 06:51:23.03 3IqCrn23.net
ほぉ、なるへそ
noneとかへの振る舞いの遅延行為としての?op
ある関数を呼んだ関数自体でerrへの振る舞い決定すべきだと考えた場合は?opにする
とすると?op含んだ関数のcallerはmatchとかのタイプ別振る舞い定義をちょっとやかましめ書く必要ありだな
いまいちpanicの振る舞いが分からん
spawned threadが内部でパニくった場合その娘、息子スレッド（スレッドの下層スレッド）とそのスレッド自体にのみunwindが適用されるんだよな？(´・ω・｀)
750:デフォルトの名無しさん
21/08/19 08:14:51.20 1vsNr98D.net
何でやねん(笑)
751:デフォルトの名無しさん
21/08/19 12:31:22.21 vGJ7k9jZ.net
vec0.iter().filter(|&x| x == &1);
これの数字に&つけて型同じにしたら通るってのが納得できないな～
比較がプリミティブ型の変数同士だったら自動的に数値として扱って欲しい
752:デフォルトの名無しさん
21/08/19 13:09:24.52 5RRw/fpd.net
>>737
それは強い静的型付けのメリット
異なる型同士の==が通るのは困る
といいたいところだけど
PartialEqトレイト次第で異なる型でも==してくれる場合もある
文字列など
でも整数は厳密でi32とi16ですら不許可
753:デフォルトの名無しさん
21/08/19 13:34:53.71 vGJ7k9jZ.net
>>738
でも、上の例で
vec0.iter().filter(|&x| x + 0 == 1);
が通るのは+0したときに中身がプリミティブ型だから数値だけ取り出してくれてるんでそ？
754:デフォルトの名無しさん
21/08/19 13:41:52.67 NIu45PdU.net
>>739
それはまた別で>>715
つまり足し算の実装
755:デフォルトの名無しさん
21/08/19 14:53:02.41 qnkUxlpG.net
&i32 + i32 の計算ができるようAddトレイトで実装されていて、結果をi32で返すようになってるからエラーにならないってことでしょ？
756:デフォルトの名無しさん
21/08/19 14:59:15.22 OmSSsNQv.net
>>741
そのとぉーり！
757:デフォルトの名無しさん
21/08/19 15:34:51.11 SriMwJau.net
>>741
ご丁寧にi32+i32 i32+&i32 &i32+i32 &i32+&i32の4種類をカバーしてくれてるね
&&i32はサポートしていないため
vec0.iter().filter(|x| x+1==2)はコンパイルエラー
758:デフォルトの名無しさん
21/08/19 16:37:43.70 gHMNbMrQ.net
まず>>715の間違いを反省しようね
>let a = 99;
>let c = &&a;
>assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
759:デフォルトの名無しさん
21/08/19 16:44:47.80 hQY8lbBV.net
>>744
それであってるぜ
&i32+i32は左だけ参照を外してi32にして足し算する
760:デフォルトの名無しさん
21/08/19 17:44:32.43 t/I60tUF.net
そりゃ当たり前だろw
とことんダメなやつだな
761:デフォルトの名無しさん
21/08/19 18:58:02.70 58T7qCMn.net
>>733
>>734
丁寧に教えてくれて、ほんとありがとう
762:デフォルトの名無しさん
21/08/19 21:41:29.08 vGJ7k9jZ.net
>>743
なるほど、なんかすべての挙動を把握しないとならないんだね
でも、やっぱり「&1」が通用するのは納得いかない(´･ω･`)
763:デフォルトの名無しさん
21/08/19 22:05:30.35 RF3Q0l8Y.net
>>748
基本的には正しく型を用いれば済む
&i32は数値ではなく数値への参照にすぎない
*付けなくても済む便宜の恩恵を受けるのはよいけどそれを理解したうえでしているかどうかの違い
764:デフォルトの名無しさん
21/08/19 22:29:20.97 c562wt5h.net
String と &str が == で比較できるなら i32 と &i32 も比較できて良い気はする
単に impl がないだけだから pull req 送ったら取り込んで貰えるのでは
765:デフォルトの名無しさん
21/08/19 22:55:59.39 vGJ7k9jZ.net
もう純粋に&1て、1の参照じゃんね
その意味がわからんし、存在意義がわからん
変数同士ならわかるけど、定数的に書いてるんだったらもうプリミティブ型だったら
中身で判断してくれよヽ(`Д´)ﾉｳﾜｧｧｧﾝ
766:デフォルトの名無しさん
21/08/19 23:28:13.13 2mmZi2HD.net
>>750
今もi32と&i32の組み合わせ4通り定義
そこへ&&i32が加わると9通り定義
そこまでする意義は？
>>751
だからx==&1ではなくて素直に*x==1と書こう
767:デフォルトの名無しさん
21/08/19 23:48:19.67 k/U3ouxt.net
>>751
プリミティブのwrapper crateを作って自分の好きなように定義すれば万事解決
768:デフォルトの名無しさん
21/08/19 23:58:39.37 A1SUdzrU
769:.net
770:デフォルトの名無しさん
21/08/20 00:03:22.90 o+L+NM8T.net
推奨する方法をやりやすく、推奨しない方法をやりにくく
Rustは他の言語に比べると特に後者についてよく考えられてる
771:デフォルトの名無しさん
21/08/20 00:07:53.98 iQK+FWFq.net
>>754
postgresクレートのquery()でparamsに数字を書きたいときとか
pub fn query<T>(&mut self, query: &T, params: &[&(dyn ToSql + Sync)]) -> Result<Vec<Row>, Error>
where
T: ?Sized + ToStatement
772:デフォルトの名無しさん
21/08/20 01:09:30.92 W7hoDzmL.net
>>752
*x == 1 と書けというのは分かるんだけど
impl PartialEq<String> for &str や impl Add<&i32> for i32 があるのに
impl PartialEq<&i32> for i32がないのは一貫性がないように思う
なんで実装されていないのだろうか
773:デフォルトの名無しさん
21/08/20 01:11:40.00 W7hoDzmL.net
>>757
自己解決
RFC1332で議論されていた
774:デフォルトの名無しさん
21/08/20 01:12:10.07 hEbF/PXF.net
rubyもpythonも見よう見まねで書けるんだけどなー
javaなんてC++とほとんど同じだから半日もあればマスターできる
でもrustだけは勉強しないと無理っぽい
難しいよ
775:デフォルトの名無しさん
21/08/20 01:34:49.41 qcewwL/9.net
>>757
実は整数と文字列ではそこの逆転現象が起きていて
Stringと&strの等号比較はOK
assert!("xyz".to_string() == "xyz")
しかしStringをmatch文でアームに&strだとコンパイル型エラーでNG
// assert!(match "xyz".to_string() { "xyz" => true, _ => false, });
&i32とi32の等号比較はコンパイル型エラーでNG
// assert!(&123 == 123);
しかし&i32をmatch文でアームにi32だと比較OK
assert!(match &123 { 123 => true, _ => false, });
776:デフォルトの名無しさん
21/08/20 01:38:48.16 omEK/Sui.net
オブジェクトの同一性 (メモリ上の同一の場所に配置されている) を判定したいときって
参照を == で比較しても駄目ですよね？
ポインタを取り出すのも恰好が悪いように思うんですが、
なんか定番の方法ってあります？
777:デフォルトの名無しさん
21/08/20 01:44:35.28 qcewwL/9.net
>>754
消費(ムーブ)せずに参照で済ませるためにiter()を使うと当然 &1 が出てくる
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());
これはVecだから消費するinto_iter()が使えば 1 に出来るけど
スライスだと消費という概念がないから必ず &1 が出てきてしまう
778:デフォルトの名無しさん
21/08/20 01:55:55.02 jENR+46K.net
>>761
Rustは所有権があるから同一メモリを指すのは所有権を持つものへの参照同士かな
つまりコード上明白であり比較する必要性がないことに？
779:デフォルトの名無しさん
21/08/20 02:30:09.57 qcewwL/9.net
こういうことかな
複数の参照もmut参照も生ポインタも当然すべて同じアドレスを指している
let mut i = 123;
let pi1 = &i;
let pi2 = &i;
println!("{:p}", pi1); // 0x7fffebf915a4
println!("{:p}", pi2); // 0x7fffebf915a4
let pi3 = &mut i;
println!("{:p}", pi3); // 0x7fffebf915a4
let rpi3r = pi3 as *mut i32; // 生ポインタ
println!("{:p}", rpi3); // 0x7fffebf915a4
生ポインタを使って書き換えると元の変数が書き換わるので確かにこれは変数の格納アドレス
unsafe {
println!("{}", *rpi3); // 123
*rpi3 = 456;
}
println!("{}", i); // 456
780:デフォルトの名無しさん
21/08/20 02:32:13.12 0J8On0UY.net
ptr::eqで
781:デフォルトの名無しさん
21/08/20 10:16:46.67 Z3M3k8Ob.net
メンテナンス性最悪の自己満足オナニー言語
782:デフォルトの名無しさん
21/08/20 11:41:07.99 0Iuc7w1s.net
>>766
それは逆
メンテナンス性は最も優れているプログラミング言語の一つ
783:デフォルトの名無しさん
21/08/20 13:42:55.60 ZqTwz4dI.net
ポインタ関連の問題が所有権と参照で絶対に発生しないってのはデカイよね
784:デフォルトの名無しさん
21/08/20 13:59:09.33 lR6AxyIv.net
将来の苦痛を先に解消できるのが良いのにな、不具合も絞り込みやすい
メンテナンス性悪いってどの辺言ってんのか聞いてみたい
785:デフォルトの名無しさん
21/08/20 14:18:54.33 nkJxp5PO.net
一年ぶりに触るソースを大規模改修しても、コンパイル通せばほぼ動く安心感ある
他言語（特に動的型言語）だと相当テストを作り込まない限り、このメンテナンス性は得られない印象
786:デフォルトの名無しさん
21/08/20 14:28:37.40 y1HLeTwS.net
データ設計を少し考えさせられることによって
メモリ安全性を得ただけでなく見通しも良くなったｗ
787:デフォルトの名無しさん
21/08/20 15:07:52.58 No4kn/Ah.net
潜在的にバグの原因となる変数の扱いすると
コンパイラが怒るのは安心できる
788:デフォルトの名無しさん
21/08/20 15:24:51.42 W7hoDzmL.net
>>768
絶対に発生しないは言い過ぎ
789:デフォルトの名無しさん
21/08/20 15:31:54.88 sJeXN42B.net
繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。。
そして文字列が複数あったり、更にそれをマクロにされると、それで書き直しが必要だったり
多くの言語でも初心者と上級者で当然、コードの美麗さに違いが出るが余りにも差があり過ぎ
たった「一年ぶり」でコンパイルが通らない言語なんてあるだろうけど、そんな話じゃない
790:デフォルトの名無しさん
21/08/20 16:06:16.17 c/gVhnyt.net
イテレータなんてどの言語にもあるし困るようなことか？
無理やり導入で汚い言語よりもRustは綺麗に洗練されていて書きやすい
791:デフォルトの名無しさん
21/08/20 16:12:21.41 BL1Grv4c.net
同じようなことなのに人によって書き方が全然違うからクソって言いたいんじゃないの？
792:デフォルトの名無しさん
21/08/20 17:10:02.79 H8grjHSU.net
何が何故問題なのか説明できないイチャモンなんかほっとけ
793:デフォルトの名無しさん
21/08/20 20:06:41.30 W7hoDzmL.net
文字列が複数種類あることが嬉しい人のための言語
嬉しくない人は別の言語を使うべき
794:デフォルトの名無しさん
21/08/20 20:28:27.92 TearUC8B.net
>>778
例えばいわゆるスクリプト言語などはいずれもRustのString型相当のものしかないため非効率でメモリ食い散らかす状態になっていますね
Rustはそれに加えて部分を指し示すだけの文字列スライス&str型を持っているので無駄なアロケーションを防いで効率の良いコードを書けるようになっていますね
795:デフォルトの名無しさん
21/08/20 21:05:31.52 ma1oO0u7.net
>>774
> 繰り返しでiter()を使ったりinto_iter()を使ったり、ループを使ったり、高階を使ったり。
あなたはちょっと無知すぎます。
まず高階関数とも言われるmap()やfilter()等を用いるにはイテレータが必須ですから同じことを指しています。
どちらかを選ぶようなものではありません。
次にRustのforループもイテレータ必須で内部でイテレータを作ってforループを回していますから同じことです。
forループ方式と高階関数方式の2種類で書けてしまうじゃないか！と言いたいのでしょうが、これは他のプログラミング言語でも同じで2種類あります。
796:デフォルトの名無しさん
21/08/20 21:07:42.14 EDzGRqES.net
内包表記なる書き方がある言語もあるらしいねｗ
797:デフォルトの名無しさん
21/08/20 21:38:29.08 6XnQ3Oqv.net
繰り返しでiter()を使ったりinto_iter()を使ったりと複数のやり方があるのはおかしいとの御指摘だが
into_iter()は値のイテレータ
iter()は参照のイテレータ
同じものに対して適用しても別のイテレータが得られる
798:デフォルトの名無しさん
21/08/20 21:47:24.73 pKmgqbo7.net
少し前までは荒らし以外は結構いいスレだったが
近頃はC++スレでダベってた暇人たちが引っ越して来ちゃってゴミスレ化しつつあるね
799:デフォルトの名無しさん
21/08/20 22:24:24.81 ZqTwz4dI.net
>>782
これ、同じメソッドにするのではなくて、イテレータにするのはiter()で共通にして、
参照する場合には、別のメソッドにしたほうがいいんじゃないのかなと思う
例えば
iter() ← 値
iter().ref() ← 参照
とか
800:デフォルトの名無しさん
21/08/20 22:50:20.88 hEbF/PXF.net
なんで配列にイテレータないんや！
配列を使うな！ vecを使えということなのか
そういえばC++でもvector使えとか言われてたな
もっと配列にも愛を！
ところでvecより配列の方がうれしいことってある？
実は配列いらない子なんじゃないかと思い始めた
801:デフォルトの名無しさん
21/08/20 23:02:42.83 Dd/EBaxX.net
>>784
それはiterのシグネチャがメソッドチェーンするかどうかで変わってしまうから
今のRustの型システムでは表現不能だと思う
プログラマ視点でも、後続する関数呼び出しがその手前に影響するってのはかなりわかりにくいのでは？
802:デフォルトの名無しさん
21/08/20 23:22:41.88 tipMusVW.net
>>785
スタックとかヒープとかアロケーションとか気にならない用途ならRust使わなくてもいいと思うの
803:デフォルトの名無しさん
21/08/20 23:47:01.90 Omw4vOgK.net
>>786
moveをデフォルトにするのは無理だけど
iter()は参照でiter().into()で値ならCow的なのでなんとかなる気がする
804:デフォルトの名無しさん
21/08/20 23:47:19.51 iQK+FWFq.net
>>785
> Rust 1.53からは配列型に対して直接IntoIteratorトレイトが実装されるようになり、配列をそのままループに使うことが出来るようになりました。
URLﾘﾝｸ(tech-blog.optim.co.jp)
805:デフォルトの名無しさん
21/08/20 23:54:51.56 hEbF/PXF.net
>>787
いやいや、もちろん配列との比較なんだから、アロケーションの発生しない処理の話だよ
スタックを気にするなら、むしろヒープに置いた方がいいし
(キャッシュミスヒットの話じゃなくて、スタックオーバーフローの話ね)
806:デフォルトの名無しさん
21/08/20 23:55:03.84 Dd/EBaxX.net
>>788
それだとinto_iterとは意味変わっちゃってるのでは
intoで元のコレクションのコピーが作られて、それをイテレートするってことでしょ？
コピーを作らず所有権を奪って値をイテレートする方法がなくなってしまう
807:デフォルトの名無しさん
21/08/20 23:56:59.11 hEbF/PXF.net
>>789
おお！ 知らなかった。
ってかめっちゃ最近じゃん！
追いかけるの大変だな
808:デフォルトの名無しさん
21/08/21 01:58:33.16 kcBD0DB/.net
>>784
iter().cloned() とか使えば良いのでは
809:デフォルトの名無しさん
21/08/21 05:48:08.14 lXSuJ2vU.net
hoge.iter()だと参照でhoge.iter().fuga()だとhogeの所有権ぶんどる、みたいなのは無理な気がする
810:デフォルトの名無しさん
21/08/21 06:24:06.23 kvS3AY0X.net
>>790
Vecは可変長なので必ずヒープからアロケーションが発生します
一方で配列は必ず固定長でスタックに置かれます
>>784
(&vec0).into_iter()はvec0.iter()となるので
into_iter()だけにすることも出来なくはないと思いますが
書き方が面倒なので簡潔なiter()と共存してるのだと思います
811:デフォルトの名無しさん
21/08/21 09:34:58.66 v7gED8U+.net
>>791
Cow使えばできるという話じゃないよ
lazyに所有権を取得するような機能を持った型を追加すれば
今の型システムでも表現できないってことはないんじゃないかって話
そういう型を追加することを型システムの変更と言うのであれば
今の型システムでは表現できないてのに同意するよ
812:デフォルトの名無しさん
21/08/21 09:43:26.29 KTz5aeQ/.net
>>795
アロケーションが発生するのは伸長するときだけでしょ
伸長するような用途だったら、そもそも配列使えないし
>一方で配列は必ず固定長でスタックに置かれます
だめじゃん。スタックオーバーフロー考慮するならvecの方がいいじゃん
まあ、自分も組み込み以外でスタックフレームのサイズなんて考慮したことないけど
813:デフォルトの名無しさん
21/08/21 09:50:40.59 KTz5aeQ/.net
>>795
ちなみにスタックにあることによってL2キャッシュに載りやすいだろ！
という意見ならそれは同意する。サイズが小さければね。
814:デフォルトの名無しさん
21/08/21 10:08:08.47 /0ZvMIRv.net
>>797
> アロケーションが発生するのは伸長するときだけでしょ
いいえ。
Vecの実体は必ずヒープにアロケーションされます。
Vec自体は(指定しなければ)スタック上で、ヒープへのポインタや長さなどで構成されて固定長です。
Stringも内部はVec<u8>なので同様です。
815:デフォルトの名無しさん
21/08/21 10:12:53.88 KTz5aeQ/.net
>>799
ああ、アロケーションじゃなくてヒープにってところを問題視してる？
ガベージコレクションの発生を懸念してる？
816:デフォルトの名無しさん
21/08/21 10:22:22.66 HwKH2mPW.net
>>800
Rustではガベージコレクションは起きない
しかしスタック上かヒープ上かの区別は重要
スタック上のデータはその関数を終える時に消滅する
817:デフォルトの名無しさん
21/08/21 10:31:43.28 KTz5aeQ/.net
>>801
>Rustではガベージコレクションは起きない
ヒープを使ってるんだから起きないわけないだろ
＞スタック上のデータはその関数を終える時に消滅する
Vecの中身だって関数を終えるときに解放されるでしょ
されないんだっけ？
そもそもの話は配列を使ってるところをVecにしても問題なくね？ってことなんだけど
どこが問題になるかの例を示してもらえたら、わかりやすい
818:デフォルトの名無しさん
21/08/21 10:58:14.92 Hi//C77Q.net
rustにはガベージコレクションがないんだぜ・・・
819:デフォルトの名無しさん
21/08/21 11:04:35.75 eqU3IJp1.net
デストラクタ的な機構で後始末するのはガベージコレクションとは普通言わない
820:デフォルトの名無しさん
21/08/21 11:09:11.24 JLDZmydZ.net
Cでもひーぷをつかうとがべーじこれくしょんがおきるの？
821:デフォルトの名無しさん
21/08/21 11:11:34.22 6mCMrQuL.net
ヒープへのメモリアロケーションはコストが高いから避けたいんでしょ
822:デフォルトの名無しさん
21/08/21 11:25:28.41 ozkLLafu.net
>>802
RustにGCはない
Vecの中身(配列相当部分)はスタック上ではなくヒープ上なので関数を終えるときに解放されない
Vec自体が消える時に解放される
Vec自体(ポインタと長さなど)はスタック上にあれば関数を終える時に消える
もちろんVec自体を関数の返り値として返すことは出来る
受け取った上位の関数でVecの中身を使える
例えば
fn main() {
let mut v: Vec<i32> = make_i32_vec_from_args();
v.push(999);
println!("{:?}", v);
}
fn make_i32_vec_from_args() -> Vec<i32> {
let mut v = Vec::new();
std::env::args().skip(1).map(|s| s.parse::<i32>().unwrap()).for_each(|n| v.push(n));
v
}
$ cargo run 111 222 333
[111, 222, 333, 999]
823:デフォルトの名無しさん
21/08/21 11:42:53.96 3jqa2oM2.net
そういや何でalloca()無いの？
824:デフォルトの名無しさん
21/08/21 12:23:12.36 kcBD0DB/.net
>>795
Box<[T; N]> のように配列がヒープに置かれる場合もある
825:デフォルトの名無しさん
21/08/21 12:35:23.13 5zDPvhJy.net
>>809
それはBoxだからであって、そんなこと言い出したら整数だってヒープに置かれうる
しかし普通に「整数型はスタックに置かれる」と言われる時は、Boxを使わない場合を意味している
Boxを使えばヒープに置かれるのは自明だからだ
したがって、整数や配列やVecの管理データ部分はそのままだとスタックに置かれるがVecのデータ実体は常にヒープに置かれる、で良い
826:デフォルトの名無しさん
21/08/21 13:25:00.39 KTz5aeQ/.net
うーん、なんだかなー
みんなヒープのことを無限にバイトを吐き出す魔法の箱かなんかだと思ってない？
>>805
>Cでもひーぷをつかうとがべーじこれくしょんがおきるの？
当然
Cのmalloc/freeやC++のnew/deleteでもガベージコレクションは発生する
wikipediaの「ヒープ領域」がよくまとってるよ
いくつかの理由からfree/deleteのガベージコレクションはJavaやC#のガベージコレクションよりも超高速だ
それでも、組み込みの世界ではガベージコレクションのせいでリアルタイム性が失われることを嫌がって、
ヒープを使わなかったりする
じゃあ、組み込みでは動的なメモリをどうするかっていうと、リンクドリストのノードをメモリブロックに
見立てて、メモリ管理システムにしたりする
これだと取得も解放も定数時間のコストだからね
>>807
すまん、例をみてますます配列なくても困らない気がしてきた
配列でできて、Vecにできないことはないの？
827:デフォルトの名無しさん
21/08/21 13:35:03.05 +9L1DmAB.net
>>811
Rustにはガベージコレクションはありません
おっしゃる通りヒープからの取得も解放も定数時間のコストで行なわれ更にガベージが溜まることはありません
Rustでは生存期間や所有権に貸し借りが明白になっているため、使用中のものが解放されたり、解放済みが使われたり、使用済みが解放されなかったりは起きません
828:デフォルトの名無しさん
21/08/21 13:50:09.86 KTz5aeQ/.net
>>812
>ヒープからの取得も解放も定数時間のコストで行なわれ
これってどういう原理？ 本当に定数ならそれもうヒープじゃないんじゃ
ヒープツリーを辿る処理も未使用ノードを結合する処理も定数時間って
ありえないと思うんだけど
829:デフォルトの名無しさん
21/08/21 14:16:15.10 G8x/1s0B.net
もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
そのためRustにガベージコレクションがないことを理解できていないような感じ？
830:デフォルトの名無しさん
21/08/21 14:22:08.01 KTz5aeQ/.net
調べた
・rustのヒープはフリーリストアロケータじゃない
（サイズごとのメモリスラブをさらに分割して使う）
・取得・解放は定数時間じゃない
(メモリスラブ全体が未使用になったときに、デフラグして別サイズのスラブとして利用可能になる)
→これ実質ガベージコレクション処理じゃん
・当然デフラグは発生するが、大して問題にならない
→そうだろうね。C++でさえアロケータ書いたことない
・問題になるならアロケータを自作することも可能(デフォルトはjemalloc)
だそうだ。
ヒープはヒープ構造じゃないのか……
831:デフォルトの名無しさん
21/08/21 14:36:21.13 KTz5aeQ/.net
>>814
>もしかしてmalloc/freeのヒープメモリ管理のことをこの人はガベージコレクションと呼んでいるのかも
freeの中にもガベージコレクション処理があるんだよという話
javaと違ってマーク＆スイープ処理いらないから早いけどね
>そのためRustにガベージコレクションがないことを理解できていないような感じ？
そんなことはわかってる
今は処理コストの話をしてる
サイズが変わらないVecと配列(配列なのでもちろん固定長)でそこまで優位の差があるのかと訊いた
そこでVecはヒープを使う(からダメだ)という答えが返ってきたので、
ヒープを使うとなぜダメなんだ？ ガベージコレクションのオーバーヘッドを気にしてるのか？と
そうするとrustはガベージコレクションありませんと言われた
じゃあ、結局のところヒープを使うとなぜダメなんだ？
832:デフォルトの名無しさん
21/08/21 14:43:58.08 3jqa2oM2.net
勝手に定義した「ガベージコレクション」なんか議論するだけ時間の無駄
833:デフォルトの名無しさん
21/08/21 14:48:02.99 HlQuVij0.net
>>816
あなたが完全に間違っている
それを世間ではガベージコレクションとは呼ばない
834:デフォルトの名無しさん
21/08/21 14:50:34.09 KTz5aeQ/.net
>>818
辞書が絶対とは言いたくないがwikipediaの「ヒープ領域」見て
835:デフォルトの名無しさん
21/08/21 14:52:48.65 Hi//C77Q.net
自分でfreeしたものをGCと呼ぶとは強者が現れたな
836:デフォルトの名無しさん
21/08/21 14:53:06.41 O7+p4qIy.net
それこそwikipediaの「ガベージコレクション」見てもらった方がいいのでは。
837:デフォルトの名無しさん
21/08/21 14:53:37.02 6mCMrQuL.net
もうジェマロクはデフォルトじゃないよ
838:デフォルトの名無しさん
21/08/21 14:58:27.12 Hi//C77Q.net
そういやこんな記事があったよ
実装言語を「Go」から「Rust」に変更、ゲーマー向けチャットアプリ「Discord」の課題とは
URLﾘﾝｸ(atmarkit.itmedia.co.jp)
> 平均すれば高速に動作していたものの、数分ごとに平均応答時間が急に大きくなり、
> ユーザーエクスペリエンスを損なっていた。調査したところ、
> これはGoの中核機能であるメモリモデルとガベージコレクタ（GC）に起因することが分かった。
> Rustではガベージコレクションが不要だ。
> 同社がRead StatesサービスをRustで実装しようと考えたのはこれが理由だ。
> Rustを使えば、Goで実装した場合に生じた平均応答時間の急増は見られないだろう。
839:デフォルトの名無しさん
21/08/21 15:02:21.85 KTz5aeQ/.net
>>820
だから、ここではコストの話をしてるんだって言ってんのに
>>821
見た。もちろん知ってる。
本題からずれてる。自動解放とかデフラグの定義の話がしたいんじゃない
配列とVecのことが知りたいんだって
なんだってこう話を逸らすんだ？
840:デフォルトの名無しさん
21/08/21 15:02:56.01 watXYiN6.net
>>819
URLﾘﾝｸ(ja.wikipedia.org)
> 7月15日（土）12:22の版で記述いただいた内容のうち、「ガベージコレクション」という部分だけ誤りと思われるので、7月19日（水）02:32の版で消させていただきました
せやな。
841:デフォルトの名無しさん
21/08/21 15:10:24.32 hSZ/tOwO.net
>>824
まずはプログラミング言語におけるガベージコレクションとは何かを理解して
次にRustではそのガベージコレクションがないことを理解して
その上で何を質問したいのかを整理してはいかがでしょうか？
それを終えてからでないとあなただけ用語の定義が異なったままでは話が進みません
842:デフォルトの名無しさん
21/08/21 15:10:57.04 IZ1Oj5x4.net
ガベコレは普通javaとかpyのコンパイラやらインタプリタがreference counterをオブジェクトに勝手に付随させる事を想定するけどな
Vec arr処理コストの違いに関してはbuffer使わないんだからarrayの方が基本的には糞みたいに早いと思うがな
そこらosとかによって最適化図られるからオブジェクト生成のとき以外は決定的な違いあんまなさそうだが
要素数をコンパイルタイムに決定(これのアルゴにもよるが)出来るなら普通はシンプル配列の方が速いよね
goはparallel threadingみたいな部分で変なgc実装してて大量に独立の計算量ハード問題導入するからねそこらへんがドイヒーなんだろうな
俺は好きだけど(´・ω・｀)
843:デフォルトの名無しさん
21/08/21 16:18:04.16 iwjgeVKb.net
>>824
何度も説明されている通り
配列は固定長なのでデータ管理部分はなく配列は通常スタック上
Vecは可変長なのでデータ管理部分がありそれは通常スタック上そして配列相当部分は常にヒープ上
844:デフォルトの名無しさん
21/08/21 16:29:59.01 0b1Dm8dh.net
コンパクションとガベージコレクションの区別がついてない
世の中のガベージコレクターがコンパクションもやってるからといって
コンパクションのみを指してガベージコレクションとは呼ばない
845:デフォルトの名無しさん
21/08/21 16:33:27.85 Ay6lvOn8.net
ふりだしに戻る >>787
846:デフォルトの名無しさん
21/08/21 16:37:39.49 KTz5aeQ/.net
>>828
それの何が問題？
stringの実装はヒープだけど問題ないよね？
こういう使い方をすると配列より100倍くらい遅いとか、メモリリークするからVec止めて配列使えとか
そういう注意点ある？
もちろんループの中でVec::newするとオーバーヘッドでかいとか、
そういうわざとらしいのはなしにして
あえていうなら初期化の記述量がちょっと増える、とか？
847:デフォルトの名無しさん
21/08/21 16:59:15.86 dJkGQ7Qm.net
>>831
誰も何も問題にしていませんよ
あなたが勘違いをして勝手な何かを問題にしているだけ
StringはVecにstructの皮を被せただけなので状況は同じ
848:デフォルトの名無しさん
21/08/21 17:06:03.36 Hi//C77Q.net
>>829
HDDの頃はよく使ってたHDD最適化と容量を増やすみたいなソフトを思い出した
HDDのデフラグ → メモリコンパクション
HDDにある不要なキャッシュの削除 → ガベージコレクション
こんな感じに似てるな
849:デフォルトの名無しさん
21/08/21 17:16:16.64 eqU3IJp1.net
ヒープがヒープ構造じゃないのかとか言ってるから本当に何も知らなかったのだろう
オレオレ用語使われると混乱するからとりあえずmalloc動画くらいみて勉強してきてほしい
850:デフォルトの名無しさん
21/08/21 17:26:30.08 KTz5aeQ/.net
>>834
そこ話の本筋じゃないんだよなー
Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー
851:デフォルトの名無しさん
21/08/21 17:30:07.73 pF+sRbnf.net
>>835
ヒープ使ってるからダメ、なんて誰も言っていない
全ては君の勘違い
852:デフォルトの名無しさん
21/08/21 17:31:33.62 KTz5aeQ/.net
>>836
そうなの？ じゃあ結論として配列はVecに置き換えても問題ないってこと？
853:デフォルトの名無しさん
21/08/21 17:52:04.92 eqU3IJp1.net
Vecは固定長配列(型[u8; 32]とかで表されるやつ)を置き換える用途としては使えないが, 逆に言えばそれだけ
854:デフォルトの名無しさん
21/08/21 18:26:53.45 Hi//C77Q.net
むしろ配列なんてクレート使わないとコンパイル時点で数値が決まってないと使えないから
ほとんど出番がないんだから、どこに悩む必要があるというのか
855:デフォルトの名無しさん
21/08/21 18:30:22.30 AgJApIsV.net
>>835
＞Vecはヒープ使ってるからダメって言われて、何がダメか説明してくれって言ってるだけなんだけどなー
あなたの妄想ではないですか？
スレを読みましたが、
Vecはヒープ使ってるからダメと言われた書き込みが見当たりません。
856:デフォルトの名無しさん
21/08/21 18:31:04.95 3jqa2oM2.net
ヒープは悪であるということをハッキリと言う
857:デフォルトの名無しさん
21/08/21 18:41:19.82 tswurJ+7.net
Linux のデフォルトではスタックの大きさは 8 メガが上限じゃなかったっけ？
(Windows だともっと小さかったはず)
大きさが固定 (コンパイル時に確定する) でかつ十分に小さく寿命が短いなら配列をスタックにおく
のは性能的に有利 (確保と解放のコストが小さい) だが、大きさを見積もれないときにスタックに置くと
スタックが足りないときにどうにもできないで即死するしかない。
大きさのわからない配列はスタックに置くべきではないというのが世の常識というもの。
少なくとも高レイヤのアプリケーションでは。
858:デフォルトの名無しさん
21/08/21 20:16:15.20 3jqa2oM2.net
仮想メモリなんだからスタック8GBに設定すればいいんじゃないの？
859:デフォルトの名無しさん
21/08/21 20:43:23.20 7GAoG1Iq.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
URLﾘﾝｸ(nim-lang.github.io)
Nimは限りなく抑え込まれたタイプ量で高い生産
860:性とPythonのような高い可読性を実現し ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる 「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
861:デフォルトの名無しさん
21/08/21 20:47:51.35 6mCMrQuL.net
Nimは知らんがパイソンが読みやすいなんて
862:デフォルトの名無しさん
21/08/21 20:53:42.26 Z4f8T8IW.net
pythonが特別読みやすいとは思わんが、pythonで読みづらいコード書くやつが
何で実装しても読みやすいものを書くことはないだろう。
863:デフォルトの名無しさん
21/08/21 20:55:25.62 6DBrqemS.net
>>844
Pythonはたまたま外部ライブラリ充実などで普及していますが、あまりよろしくない言語です。
そのためPythonで開発したいという人はいないです。
なので「Pythonのような高い可読性を実現している」と宣伝されても逆効果。
864:デフォルトの名無しさん
21/08/21 20:58:33.68 O7+p4qIy.net
>>844の人は関係ないスレに迷惑かけて、nimユーザーのイメージダウンが目的なんだろうか。
865:デフォルトの名無しさん
21/08/21 21:35:33.43 PyG7lKVy.net
積極的にPython使おうとは思わんなぁ。インタプリタ系はRuby使っているわ
Luaも結構良い感じだと思う