24/02/12 22:50:36.74 4VueJhli.net
>>686
C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。
一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。
701:デフォルトの名無しさん
24/02/12 22:54:09.63 RSTU7X98.net
>>685
Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる
702:デフォルトの名無しさん
24/02/12 23:33:02.01 g0MzjlGR.net
>>692
ダックタイピングの言い回しに前例はなくても原因はあるんだろう
そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある
703:デフォルトの名無しさん
24/02/12 23:52:54.50 Dj37TM3K.net
委譲やダックタイピングを理解してないのもどうかと思ったけど
↓これらの区別ができてないのは致命的だと思うので勉強しようね
静的型付け/動的型付け
静的ポリモーフィズム/動的ポリモーフィズム
静的処理/動的処理
704:デフォルトの名無しさん
24/02/13 00:30:00.87 xtMg5XLl.net
確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？
705:デフォルトの名無しさん
24/02/13 02:23:26.95 vbRTXFPD.net
ファクトチェック界隈では事実かデマかが確固たる論点だよね
公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ
706:デフォルトの名無しさん
24/02/13 03:26:01.95 s0kRtfrq.net
オレオレ定義で擬似問題作るの止めろ。
ダックタイピングについてはWikipediaの解説でいいか。
ja.m.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0
英語版が一番詳しいかね。
707:デフォルトの名無しさん
24/02/13 07:31:17.64 KlTxxkJG.net
>>683
フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある
結局パターン通りに作る云々が論じられるのはフレームワークを使う側
708:デフォルトの名無しさん
24/02/13 08:18:01.41 EJGfS3Xj.net
>>699
アンチパターンや亜種になるだけで全部パターンだぞ
709:デフォルトの名無しさん
24/02/13 08:30:13.65 eXWviQcC.net
はじめにパターンありき、ではない
710:デフォルトの名無しさん
24/02/13 09:29:40.48 d0oThnC1.net
ダックタイピングはお手軽さを上回るデメリットだらけの悪手法
問題もなく安全で高速なRustのトレイト方式が最善策
トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所
711:デフォルトの名無しさん
24/02/13 10:20:47.32 yeb3oliP.net
うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？
712:デフォルトの名無しさん
24/02/13 10:23:31.22 T85IlqBy.net
>>703
そんなわけないでしょ
713:デフォルトの名無しさん
24/02/13 10:29:29.95 iVxwtbvh.net
>>703
Pythonは遅いし本質でない実行時デバッグも大変だし
速くて実行前に静的に解決できるRustがベストな言語だよ
714:デフォルトの名無しさん
24/02/13 10:30:11.10 ep9QvdZW.net
>>703
その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう
715:デフォルトの名無しさん
24/02/13 10:31:44.87 mnEJD8Sx.net
>>703
その講師優秀やな
716:デフォルトの名無しさん
24/02/13 11:11:21.55 mXdLEMzy.net
>>705
その講師も大概だがお前もデバッグをまともにやったことないだろ。
717:デフォルトの名無しさん
24/02/13 11:16:14.81 iVxwtbvh.net
>>708
Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ
718:デフォルトの名無しさん
24/02/13 11:22:46.51 BKo58x30.net
ここまで俺の自演
719:デフォルトの名無しさん
24/02/13 11:32:02.27 mXdLEMzy.net
>>709
よっぽどレベル低いことしてない限りそこまでキツくはないわ。
むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。
720:デフォルトの名無しさん
24/02/13 11:43:25.76 bOFev+sF.net
>>703
どーせデータ分析やデータサイエンスの講師だろ
くだらない釣りやめろ
721:デフォルトの名無しさん
24/02/13 11:46:14.62 bOFev+sF.net
まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな
くだらねえほんと
722:デフォルトの名無しさん
24/02/13 11:53:02.08 rA+hqhZ3.net
荒らしに構った時点でお前らの負け
723:デフォルトの名無しさん
24/02/13 11:57:48.21 qvC4XjeP.net
>>703が荒らし判定されてて草ww
724:デフォルトの名無しさん
24/02/13 12:05:17.83 n6Gkr1cM.net
>>702
trait boundはgenerics と型パラメータの相互依存が重たい気が。
c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？
725:デフォルトの名無しさん
24/02/13 12:09:09.09 IxuyFkNI.net
わかる→ Pythonで簡単なスクリプトを書く
キチガイ→ Pythonでプログラミング開発する
726:デフォルトの名無しさん
24/02/13 12:12:34.52 KvZIg8uL.net
Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ
727:デフォルトの名無しさん
24/02/13 12:15:32.69 1UgkqCq+.net
よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？
728:デフォルトの名無しさん
24/02/13 13:03:33.72 X5Whr4lm.net
単発NG推奨
729:デフォルトの名無しさん
24/02/13 13:04:48.12 X5Whr4lm.net
単発NG推奨
連鎖あぼーん推奨
730:デフォルトの名無しさん
24/02/13 13:49:44.45 BKo58x30.net
スレNG推奨では？
731:デフォルトの名無しさん
24/02/13 14:10:44.85 q0xfm82v.net
また境界知能が暴れてんのか
いい加減諦めろよ
732:デフォルトの名無しさん
24/02/13 15:09:27.64 j+0n3+gu.net
C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど
733:デフォルトの名無しさん
24/02/13 19:22:36.57 ui4ZrT7T.net
XML大嫌い
734:デフォルトの名無しさん
24/02/13 20:34:52.16 u8WS3GIa.net
>>716
やりたいことがよく分からないけどtraitのassociation typeで解決しない？
I: Iteratorだと要素の型はI::Item（正確には<I as Iterator>::Item）になるみたいな
C++のconceptだとtypenameに相当するのかな
traitにgenericsの型パラメータ持たせるかassociation type使うかの判断は慣れるまで難しいけど
選択肢が複数あって外部から決められる ⇒ generics型パラメータ（例：AsRef<T>）
traitを実装するときに内部で自動的に決まる ⇒ association type（例：Deref::Target）
みたいに使い分けるといい
全部をgenericsの型パラメータでやろうとするとカオスになる
735:デフォルトの名無しさん
24/02/13 21:06:36.86 4D6oEUgV.net
>>716
できる
例えばこのように
URLﾘﾝｸ(docs.rs)
pub trait Service<Request> {
type Response;
type Error;
type Future: Future<Output = Result<Self::Response, Self::Error>>;
// Required method
fn call(&self, req: Request) -> Self::Future;
}
ここで型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタResponseは依存しない
736:"reply_link">>>726 その二種類の混合も可能
737:デフォルトの名無しさん
24/02/13 21:08:42.27 4D6oEUgV.net
ごめん
>>727はこうね
型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタRequestは依存しない
738:デフォルトの名無しさん
24/02/13 22:37:37.84 s0kRtfrq.net
ちょっと違うなぁ。
c++ template & conceptだと
wandbox.org/permlink/74j79ZQ3mbPb2cLO
みたいな感じでCircleはf()の影響を受けずに独立させることができる。
draw()メソッドというダックテストを満たせば他はどうでも良い。
Rustのgenericsだと
wandbox.org/permlink/CvepQKXOXaNTJoJm
みたいにCircleとf()の間にtrait Dという相互依存ができて、Circleを好き勝手に定義できなくなる。
f()が欲しいのはあくまでdraw()メソッドだけだから、双方にtrait Dが必要になるのは過剰な相互依存になる。
クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。
739:デフォルトの名無しさん
24/02/13 23:17:32.55 RVgq5WHA.net
それはgeneric constraintがnominalかstructuralかという違い
Rustはnominalのみでstructural generic constraintはサポートしてないよ
740:デフォルトの名無しさん
24/02/13 23:20:56.53 KlTxxkJG.net
Pythonは全てにおいてJuliaに劣った言語だな
741:デフォルトの名無しさん
24/02/13 23:28:47.57 u8WS3GIa.net
>>729
Circleを
fn f<T: Drawable>(t: &T) -> f64 { t.draw() }
に渡したいなら普通に
impl Drawable for Circle {
fn draw(&self) -> f64 { <Circle as D>::draw(self) }
}
を追加するな
コントラクトの明示を余計な依存関係だとは思わない
ちなみに
impl Circle {
fn draw() -> f64 {...}
}
みたいに本体のimplに定義するとCircleのself.draw()は全部こっちで解決されるから
impl Drawable for Circle {
fn draw(&self) -> f64 { self.draw() }
}
って書ける
１つの型に複数のtraitで同じ名前の関数を持たせるのはRustだとたまに見かける
impl Debugとimpl Displayはどっちもfn fmt()で別の実装するし
742:デフォルトの名無しさん
24/02/13 23:28:48.94 RVgq5WHA.net
>>726
>traitを実装するときに内部で自動的に決まる ⇒ association type（例：Deref::Target）
ある型に対するtrait実装をただ一つだけにしたいものや
自然と一つだけになるような性質のものはassciated typesを使う
使う側はassociated typesのほうが使いやすいので
悩んだらとりあえずassociated typesからはじめてみる
743:デフォルトの名無しさん
24/02/13 23:30:39.22 9eHJiOzP.net
>>729
そこはtrait介在させなきゃいけないところでしょ
Rustの方針が正しいと思うよ
744:デフォルトの名無しさん
24/02/13 23:32:24.97 RaqlAe+S.net
traitとかいうつまらない機能にこだわってないでPython極めろよ
時代はAIだぞ
745:デフォルトの名無しさん
24/02/13 23:35:00.89 8wj/C7pB.net
>>735
Rustをただ貶したいだけのやつは黙っとけよ雑魚
746:デフォルトの名無しさん
24/02/14 05:05:25.04 uLd8jazY.net
Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。
比較で持ち出すならせめてNimにしろよ。
747:デフォルトの名無しさん
24/02/14 05:28:01.52 uLd8jazY.net
>732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。
まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。
748:デフォルトの名無しさん
24/02/14 06:58:38.09 t2TEYrx/.net
>>738
>>これはRustが嫌っているクラスの継承みたいなもの
クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない
749:デフォルトの名無しさん
24/02/14 07:00:00.30 HWQ4xiFb.net
自演きもいなあ
750:デフォルトの名無しさん
24/02/14 07:00:27.71 523CbVaw.net
実装継承はゴミ
751:デフォルトの名無しさん
24/02/14 07:05:57.04 Uwd6Wtce.net
>>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い
752:デフォルトの名無しさん
24/02/14 07:33:52.24 uLd8jazY.net
>>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。
753:デフォルトの名無しさん
24/02/14 08:08:30.71 b46uhNiQ.net
>>742
実運用はビルド済だから関係ないな。
754:デフォルトの名無しさん
24/02/14 08:09:58.02 t2TEYrx/.net
>>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない
755:デフォルトの名無しさん
24/02/14 08:41:45.06 W3PM5KGQ.net
>>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ
756:デフォルトの名無しさん
24/02/14 08:51:32.74 t2TEYrx/.net
>>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる
757:デフォルトの名無しさん
24/02/14 08:55:57.66 b46uhNiQ.net
>>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。
758:デフォルトの名無しさん
24/02/14 09:07:35.89 L7EuZktb.net
真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ
759:デフォルトの名無しさん
24/02/14 09:20:06.07 BSRmwKLd.net
>>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか
Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな
760:デフォルトの名無しさん
24/02/14 09:36:07.02 48k6rT3Y.net
>>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね
761:デフォルトの名無しさん
24/02/14 09:47:17.10 c6aYZ04m.net
>>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装することで結果的に各機能の合成となる
762:デフォルトの名無しさん
24/02/14 09:59:07.19 YhuSf3ik.net
細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う
763:デフォルトの名無しさん
24/02/14 10:10:46.95 Z6/Yikm0.net
>>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。
>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？
764:デフォルトの名無しさん
24/02/14 10:17:10.59 naKe/3pl.net
ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ
765:デフォルトの名無しさん
24/02/14 10:27:45.39 s2Ev9A6j.net
>>738
言語側のサポートならマクロで十分でしょ
macro_rules! impl_drawable {
($type:ty) => {
impl $crate::path::to::Drawable for $type {
fn draw(&self) -> f64 { self.draw() }
}
}}
を定義すれば
impl_drawable!(Circle);
だけでimpl Drawable for Cirle {...}を生成できる
渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング
Drawableに関数を追加したらマクロにも追加すればいい
draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい
impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる
766:デフォルトの名無しさん
24/02/14 10:44:54.87 AzS2pw5X.net
ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう
767:デフォルトの名無しさん
24/02/14 10:53:25.15 naKe/3pl.net
>>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ
768:デフォルトの名無しさん
24/02/14 11:07:38.32 RfRsJx+N.net
使う側が気をつけるならC++も問題ないからな
769:デフォルトの名無しさん
24/02/14 11:17:22.43 NjTyhCIW.net
>>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター
770:デフォルトの名無しさん
24/02/14 11:23:15.20 FEB+PUkj.net
>>759
そゆこと
だからRustは不要
771:デフォルトの名無しさん
24/02/14 11:28:02.15 naKe/3pl.net
ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない
772:デフォルトの名無しさん
24/02/14 11:51:49.92 L7EuZktb.net
ここで>>9-20の流れを振り返ってみましょう
773:デフォルトの名無しさん
24/02/14 11:52:42.46 3OoaoCBc.net
C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば
fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}
みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。
774:デフォルトの名無しさん
24/02/14 12:13:59.14 s2Ev9A6j.net
>>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん
>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする
775:デフォルトの名無しさん
24/02/14 12:19:27.37 Cdw7DngV.net
>>761
だから の文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。
776:デフォルトの名無しさん
24/02/14 12:25:13.12 b46uhNiQ.net
>>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。
777:デフォルトの名無しさん
24/02/14 12:29:23.30 naKe/3pl.net
>>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している
778:デフォルトの名無しさん
24/02/14 12:49:07.16 b46uhNiQ.net
>>768
自明だと検証できる証明を示して頂戴。
検証可能性の無い主張は単なる疑似科学だし。
779:デフォルトの名無しさん
24/02/14 12:52:16.39 KpCwABm3.net
欠点がない言語なんて無いから言い争ってもね。
780:デフォルトの名無しさん
24/02/14 12:57:57.69 p6Tfi6cJ.net
そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明
781:デフォルトの名無しさん
24/02/14 13:07:28.33 L7EuZktb.net
たし🦀
782:デフォルトの名無しさん
24/02/14 13:09:31.24 aR1xhX8a.net
おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき
783:デフォルトの名無しさん
24/02/14 13:16:05.40 eD+V22zq.net
drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ
784:デフォルトの名無しさん
24/02/14 13:33:10.33 Q08aEmFz.net
境界知能が可視化されてる
785:デフォルトの名無しさん
24/02/14 13:53:52.28 Z6/Yikm0.net
>>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。
786:デフォルトの名無しさん
24/02/14 13:55:32.21 eD+V22zq.net
>>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ
ダックタイピングは白紙の契約書にサインするようなものだ
787:デフォルトの名無しさん
24/02/14 13:57:04.55 s22bd+Hs.net
>>775
お前のこと？
788:デフォルトの名無しさん
24/02/14 14:31:04.48 h4S8S2sP.net
>>777
これな
789:デフォルトの名無しさん
24/02/14 14:41:15.13 3OoaoCBc.net
>>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……
790:デフォルトの名無しさん
24/02/14 15:12:12.70 s2Ev9A6j.net
>>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな
791:デフォルトの名無しさん
24/02/14 15:36:36.14 S2bQYQek.net
>>764
Rustで++は排除されている
理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな
792:デフォルトの名無しさん
24/02/14 16:02:27.29 3OoaoCBc.net
>>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。
793:デフォルトの名無しさん
24/02/14 16:29:39.74 ona7PgM1.net
>>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ
fn increment(dest: &mut u32) -> u32 {
std::mem::replace(dest, *dest + 1)
}
794:デフォルトの名無しさん
24/02/14 16:36:51.93 b+wxXawK.net
質問している人間相手なら関係ないことを書いて良いわけではない
795:デフォルトの名無しさん
24/02/14 16:42:22.39 3OoaoCBc.net
>>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。
796:デフォルトの名無しさん
24/02/14 16:46:13.61 L7EuZktb.net
ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん……
797:デフォルトの名無しさん
24/02/14 16:46:26.67 b+wxXawK.net
一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない
798:デフォルトの名無しさん
24/02/14 16:51:03.66 3OoaoCBc.net
>>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。
ID:S2bQYQek さん、すいません
799:デフォルトの名無しさん
24/02/14 17:05:32.23 ZK4bCcm/.net
人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい
800:デフォルトの名無しさん
24/02/14 17:06:20.11 Q08aEmFz.net
だから境界知能なんでしょ
801:デフォルトの名無しさん
24/02/14 17:19:45.82 qgmjNVo3.net
腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう
802:デフォルトの名無しさん
24/02/14 17:26:03.70 h4S8S2sP.net
tmuxよりscreen派だよ。
803:デフォルトの名無しさん
24/02/14 17:50:47.59 6CXfQ6Kw.net
個人的には後置インクリメントだけを関数化するのは微妙に感じる
fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う
804:デフォルトの名無しさん
24/02/14 19:51:05.67 7rKeAYke.net
>>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。
805:デフォルトの名無しさん
24/02/14 19:57:21.78 b46uhNiQ.net
>>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。
806:デフォルトの名無しさん
24/02/14 20:14:14.28 yh2p7tDo.net
>>796
C++では機能の異なる同名メソッドを区別できないから欠陥品
807:デフォルトの名無しさん
24/02/14 20:52:10.35 b46uhNiQ.net
>>797
引数・戻り値で区別できるだろ。
808:デフォルトの名無しさん
24/02/14 21:01:37.45 yh2p7tDo.net
>>798
それに依存してしまうのがC++の限界
809:デフォルトの名無しさん
24/02/14 21:18:41.79 b46uhNiQ.net
>>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。
810:デフォルトの名無しさん
24/02/14 21:58:58.38 H5X+9PTs.net
>>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため
811:デフォルトの名無しさん
24/02/14 22:13:29.10 uLd8jazY.net
>>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？
Rustのtraitて、副作用のコントロールできたっけ？
812:デフォルトの名無しさん
24/02/14 22:26:20.82 8gvFvpJ5.net
traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ
813:デフォルトの名無しさん
24/02/14 23:19:42.33 3OoaoCBc.net
>>803
コンセプト。
814:デフォルトの名無しさん
24/02/14 23:20:56.22 3OoaoCBc.net
>>792
毎度毎度のことで余裕を削られた最後だったんだよ。
815:デフォルトの名無しさん
24/02/15 00:20:11.01 AyUC+mx+.net
毎度毎度のことという認識を持っていながらなぜここに書き込むのか
816:デフォルトの名無しさん
24/02/15 00:23:07.31 x2y7hFPc.net
>>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。
817:デフォルトの名無しさん
24/02/15 07:06:08.60 13EQhuxe.net
>>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的
818:デフォルトの名無しさん
24/02/15 07:43:10.62 j4EJcuA3.net
>>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。
819:デフォルトの名無しさん
24/02/15 07:55:56.64 hKdVOM0D.net
>>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり
820:デフォルトの名無しさん
24/02/15 08:11:38.37 j4EJcuA3.net
>>810
検索したけど見つからなかった……
リンクある？
821:デフォルトの名無しさん
24/02/15 08:17:50.82 Me0Wd39H.net
[Why I Use Golang In 2024](URLﾘﾝｸ(www.youtube.com))
822:デフォルトの名無しさん
24/02/15 08:19:40.94 j4EJcuA3.net
>>812
サンクス。
家帰ったら見るわ。
823:デフォルトの名無しさん
24/02/15 08:48:36.69 UeUfm3Ct.net
>>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、
824:デフォルトの名無しさん
24/02/15 09:52:51.93 x2y7hFPc.net
>>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。
825:デフォルトの名無しさん
24/02/15 09:55:25.99 LYiZEs3M.net
エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？
826:デフォルトの名無しさん
24/02/15 10:07:56.04 x2y7hFPc.net
>>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。
827:デフォルトの名無しさん
24/02/15 10:11:47.35 9MXGquuv.net
C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる
828:デフォルトの名無しさん
24/02/15 10:21:13.40 qaCOVcST.net
まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは
Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある
829:デフォルトの名無しさん
24/02/15 10:32:36.57 LYiZEs3M.net
>>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…
830:デフォルトの名無しさん
24/02/15 10:37:24.02 x2y7hFPc.net
「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。
現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。
C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。
Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。
831:デフォルトの名無しさん
24/02/15 10:38:37.60 TrooctNX.net
今の時点で使いやすければなんでもいいんだYO
832:デフォルトの名無しさん
24/02/15 10:45:22.07 9MXGquuv.net
C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま
833:デフォルトの名無しさん
24/02/15 11:47:28.36 olqTmpaN.net
C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ
834:デフォルトの名無しさん
24/02/15 12:02:34.79 oxTsPXaA.net
>>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法
835:デフォルトの名無しさん
24/02/15 14:40:35.94 wvzNp0zm.net
そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分
836:デフォルトの名無しさん
24/02/15 14:47:01.34 z+RD4XEG.net
サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある
837:デフォルトの名無しさん
24/02/15 16:20:13.71 x2y7hFPc.net
>>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。
838:デフォルトの名無しさん
24/02/15 16:46:19.25 606b12LT.net
>>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね
839:デフォルトの名無しさん
24/02/15 16:50:52.01 olqTmpaN.net
すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる
840:デフォルトの名無しさん
24/02/15 17:21:54.77 SzbBTI0k.net
>>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない
841:デフォルトの名無しさん
24/02/15 17:26:25.25 BHoNDVf7.net
Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい
842:デフォルトの名無しさん
24/02/15 17:31:26.55 dtRRoOMy.net
Ruby は、Go/Rust/Elixir の3大言語を超えた！
Rust の上昇は止まったか？
Stack Overflow 米国年収。2022 -> 2023
Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7
多くの言語 : 6.5～7 -> 7.3～7.8
PHP : 5 -> 5.9
Dart : 4.4 -> 5.6
843:デフォルトの名無しさん
24/02/15 17:35:21.87 eOw5Ad1t.net
>>832 夢見てないで現実見ては？
URLﾘﾝｸ(active.nikkeibp.co.jp)
844:デフォルトの名無しさん
24/02/15 17:41:41.98 wvzNp0zm.net
>>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草
845:デフォルトの名無しさん
24/02/15 17:53:07.0
846:4 ID:8jpdfcc8.net
847:デフォルトの名無しさん
24/02/15 18:08:05.70 uSGIT3N+.net
>>834
せめて用途別のプログラミング順位を挙げてくれ
…単発に言っても無駄か😭
848:デフォルトの名無しさん
24/02/15 18:08:23.00 giVh/goG.net
Goは２年も続けられるだろうか
大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら
返されたResultを無視してもコンパイラが警告出さないからやめた
Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに
↓を見て気持ち悪さを感じる人には向かない
file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる
849:デフォルトの名無しさん
24/02/15 18:11:15.85 x2y7hFPc.net
>>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。
起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。
850:デフォルトの名無しさん
24/02/15 18:19:47.46 SZiIKMeC.net
「Go」、2月のTIOBE指標で過去最高8位に
URLﾘﾝｸ(japan.zdnet.com)
URLﾘﾝｸ(japan.zdnet.com)
851:デフォルトの名無しさん
24/02/15 18:24:55.60 x2y7hFPc.net
>>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。
852:デフォルトの名無しさん
24/02/15 18:31:33.80 j4EJcuA3.net
>>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。
853:デフォルトの名無しさん
24/02/15 18:34:16.56 3rKktGL8.net
>>817
これはごもっともな意見
50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる
それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題
854:デフォルトの名無しさん
24/02/15 19:40:03.38 TrooctNX.net
50年後にC++23はサポートされているのだろうか
というかC++は50年後もアップデートしているのだろうか
855:デフォルトの名無しさん
24/02/15 19:52:43.98 flxKbqvK.net
>>843
cargo fix --edition
のあるRustは至れり尽くせりだよ
856:デフォルトの名無しさん
24/02/15 20:00:49.77 nijJOd3e.net
>>844
既にC++17とC++20で以前導入の機能の削除が大量に行われている
857:デフォルトの名無しさん
24/02/15 20:11:12.94 Zy70aZMD.net
じゃあもうRustで良いじゃん
858:デフォルトの名無しさん
24/02/15 20:27:48.49 Y7OgkdHD.net
CになかったC++の機能は削除してもチューリング完全が保証される
逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター
859:デフォルトの名無しさん
24/02/15 22:27:00.96 MX4y8Eg+.net
>>840
Kotlinが上がってきてるのうれしい
Fortranも上がってるのはなぜだ
860:デフォルトの名無しさん
24/02/15 22:56:46.83 x2y7hFPc.net
C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。
たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。
基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。
実質的には Rust のエディションみたいなことにはなってるんだよなあ。
861:デフォルトの名無しさん
24/02/15 23:13:05.86 17JkefKn.net
llvmも実装はc++だし。
862:デフォルトの名無しさん
24/02/15 23:33:02.83 CqGYBNeH.net
>>850
Rustは必ずeditionを明示しないといけないから
あるソースコードがどのeditionなら確実に動くのか明確にわかる
そしてそのeditionを指定してコンパイルも通り実行もできる
しかしC++は当初のC++11に従いコンパイルできて動いていたものが
今はC++11の機能のいくつかは削除されてしまっているために
863:デフォルトの名無しさん
24/02/15 23:44:16.83 x2y7hFPc.net
>>852
C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが
864:デフォルトの名無しさん
24/02/15 23:57:58.06 m2l7AKkd.net
一般人と同等の読解力を複オジに期待しないこと
865:デフォルトの名無しさん
24/02/16 01:17:00.51 2uzjzXJf.net
cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ
勉強になるわ〜
866:デフォルトの名無しさん
24/02/16 02:58:58.82 T31Boec7.net
>>853
名前が同じならなんでも良い…… ってこと！？
867:デフォルトの名無しさん
24/02/16 05:29:44.45 VnZfCvN7.net
>>856
「規格が同じなら」ということだよ。
c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。
868:デフォルトの名無しさん
24/02/16 06:06:29.14 VMcEA5aE.net
RustのEdition方式が優秀すぎる
新たな機能の規格で分けるのではなく
各Editionは後方互換性の変化で分けているため
過去に書かれたコードも必ず動く
869:デフォルトの名無しさん
24/02/16 08:50:06.12 T31Boec7.net
>>857
規格が同じといいつつ機能消してんだから同じなのは規格の名前だけじゃん
870:デフォルトの名無しさん
24/02/16 08:50:57.44 T31Boec7.net
規格から機能ごと消えるんならよう
871:デフォルトの名無しさん
24/02/16 08:57:09.07 MpEo3rxP.net
>>859
消してないけど何いってんの？
872:デフォルトの名無しさん
24/02/17 07:36:35.11 pKHDV/cx.net
ID:T31Boec7
流石にこいつ日本語能力なさすぎだろ
ガイジかな？
873:デフォルトの名無しさん
24/02/17 07:58:38.87 y2U3e6uM.net
mojo vs rustでmojo公式とnetflix天才とRust本著者で盛り上がっている
URLﾘﾝｸ(www.youtube.com)
>>814,835
早口なので大変だろうけどちょとした言葉の節々に情報があるからリスニングがんばれ
874:デフォルトの名無しさん
24/02/17 08:38:43.36 P+bU7/QC.net
>>863
copilotで要約して貰うのが時間も短縮できるのに無能だなw
875:デフォルトの名無しさん
24/02/17 11:31:52.42 /wuPDCL7.net
>>864
この天才同士のディスカッションを楽しめないなんて損してんね🥲
876:デフォルトの名無しさん
24/02/17 11:55:10.10 wfN7KjH7.net
Netflixの天才とかいうのが胡散臭くて信頼性がないんだけどどういう人なのよ。
877:デフォルトの名無しさん
24/02/17 12:54:06.77 p6Fewl3N.net
>>863
この人の英語聞き取りにくい
もうちょっとゆっくり喋って欲しい
中身うっすいのにさ
878:デフォルトの名無しさん
24/02/17 12:58:21.47 p6Fewl3N.net
>>862
普通に境界性知能ってやつでは？
この手のは全部そうだと思うようにしてる
879:デフォルトの名無しさん
24/02/17 17:40:44.30 SxaDWram.net
>>863
ベンチマーク試してみたところ以外はブログ記事のまんまなのでわざわざ動画で見なくてもいいなこれ
公式ブログに書くならもうちょっとちゃんとしたベンチマークやれよって感じ
見識を疑うレベル
880:デフォルトの名無しさん
24/02/17 18:56:01.48 bc7xcSj4.net
Netflixの天才がいかがでしたかブログレベルの動画を出すとは
881:デフォルトの名無しさん
24/02/17 19:01:49.62 hd6B0gbf.net
>>863
動画内の指摘が記事に反映されてMojoがRustの3倍速いじゃん!!
Mojoコンパイラ賢いな
882:デフォルトの名無しさん
24/02/17 19:07:25.89 1+LtKHMi.net
以前からMojoがCより何倍も速い！とかやってるけど
ベンチ方法や条件などが何かおかしい
883:デフォルトの名無しさん
24/02/17 20:11:15.92 lHr0QJnq.net
SIMDが効くような恣意的なベンチだしな
884:デフォルトの名無しさん
24/02/17 21:00:37.77 QWthdRCX.net
でもデータを見てから断罪するのは俗っぽいから
データを見ないでロジハラするのがベター
885:デフォルトの名無しさん
24/02/17 21:16:16.12 lHr0QJnq.net
DynamicVectorは最適化でSIMD使うように最適化されるってだけだろ
あと末尾最適化する
くだらなすぎる
886:デフォルトの名無しさん
24/02/17 21:40:36.38 WeOJL5ES.net
え？ Rustって末尾最適化できんの？
887:デフォルトの名無しさん
24/02/17 23:56:23.75 uU5eCENW.net
Rust Reserved keywords
KW_ABSTRACT : abstract
KW_BECOME : become
KW_BOX : box
KW_DO : do
KW_FINAL : final
KW_MACRO : macro
KW_OVERRIDE : override
KW_PRIV : priv
KW_TRY : try
KW_TYPEOF : typeof
KW_UNSIZED : unsized
KW_VIRTUAL : virtual
KW_YIELD : yield
888:デフォルトの名無しさん
24/02/18 09:43:13.97 2fU6EVDD.net
>>873,875
同じLLVM系なのにRustが3倍遅いのかよ!!
Mojoがコンパイラ賢いのかRustコンパイラが...
889:デフォルトの名無しさん
24/02/18 10:23:17.76 8VIVYK48.net
あれを見て本当にRustが遅いと思っちゃう層の人にRustは向いてない
890:デフォルトの名無しさん
24/02/18 10:24:13.10 8VIVYK48.net
ちなみにSIMD云々は本質じゃないよ
891:デフォルトの名無しさん
24/02/18 10:33:07.03 diN1NxZN.net
>>879が3倍速いRustコードを出すってよ
892:デフォルトの名無しさん
24/02/18 10:46:23.01 fnRzA2e2.net
これはGoの方が速いんじゃないか？
893:デフォルトの名無しさん
24/02/18 11:13:09.56 NoFg1fuK.net
GoはGCを伴う言語だから論外
MojoはC/C++/Rustより3倍速い
894:デフォルトの名無しさん
24/02/18 11:27:28.89 YdXgtYKq.net
>>878
同じLLVMといってもMLIRという数値計算に最適化されたIRを使ってるから速い
恣意的な例である
895:デフォルトの名無しさん
24/02/18 11:36:55.83 a/PaZk8n.net
そういえば昔Delphiがコンパイルの速さを売りにしてたの思い出した
なんか懐かしい
896:デフォルトの名無しさん
24/02/18 12:18:39.29 Wi99yBdV.net
20年後にRustを懐かしむスレはここですか？
897:デフォルトの名無しさん
24/02/18 14:55:22.54 LhS8zjp4.net
20年後には流石にもっと良い言語が登場して流行っていることを期待している
898:デフォルトの名無しさん
24/02/18 15:22:23.80 L2mk1x1a.net
>>885
アンダースヘルスバーグ天才だよな
ボーランドでDelphi作って
マイクロソフトでC#とTypeScript作って
899:デフォルトの名無しさん
24/02/18 15:34:23.48 CKqOMEmo.net
>>888
MAUIくん！病室に戻るんだ！
900:デフォルトの名無しさん
24/02/19 09:27:30.10 JlpPRp2V.net
>>888
俺は天才とは思わない
この人ってお手本となる言語があって
それをよりよくすることは得意な気がする
901:デフォルトの名無しさん
24/02/19 10:19:49.07 j7eyydGe.net
普通の人が実務で使うような汎用プログラミング言語は
とびぬけた画期的なパラダイムで構成しても使い難いし、
ひとつひとつはどうということはない要素を上手く組み合わせる
バランス感覚が重要って感じはあるね。
天才的な閃きでどうにかするようなものではない。
902:デフォルトの名無しさん
24/02/19 11:58:45.15 r1DaNm3S.net
既存のものをうまく組み合わせたりリーダーシップをとったりするのに天賦の才があったという意味なら天才かな
903:デフォルトの名無しさん
24/02/19 12:07:19.13 BnjhEPJH.net
自分は何も出来ない無才なのによく言うわw
904:デフォルトの名無しさん
24/02/19 14:11:02.99 JlpPRp2V.net
C#→Javaのビミョーなところを直す
Delphi→Pascalのビミョーなところを直す
TypeScript→JSに型付け
905:デフォルトの名無しさん
24/02/19 14:41:59.29 FfoO1n86.net
Rustのビミョーなところを直して欲しい
906:デフォルトの名無しさん
24/02/19 15:33:58.75 BnjhEPJH.net
R#だすかー
907:デフォルトの名無しさん
24/02/19 16:37:49.01 pyxz0P7h.net
Turbo PascalやDelphiやVisual J++は彼か作ったと言えるがTypeScriptはHejlsbergが作ったわけじゃないからな
広報+コントリビューター+社外との政治的調整役
908:デフォルトの名無しさん
24/02/19 18:10:38.68 VthC7yJG.net
R#とか絶対統計処理用の言語じゃん
909:デフォルトの名無しさん
24/02/19 18:20:06.89 BnjhEPJH.net
そうだな
じゃあRustyNailって名前にするか
910:デフォルトの名無しさん
24/02/19 18:38:07.38 j7eyydGe.net
ビミョーなところをどうにかしたってどうせ別のビミョーなところが出てくるに決まってるんだよ。
だましだまし発展させて行き詰まったあたりでまた新しい何かが登場するのが世の中のサイクルというもんだ。
911:デフォルトの名無しさん
24/02/19 18:50:17.05 JlpPRp2V.net
割とマジでヘルスバーグ動きますの可能性はある
Carbon、Go→Google
Rust→Mozilla
？→Microsoft
この流れは確かにある
912:デフォルトの名無しさん
24/02/19 20:05:38.11 gidehIA9.net
GoogleもMicrosoftもRust支持で
Carbonの公式FAQにはRustが使えるならRustが良いと明記されている
913:デフォルトの名無しさん
24/02/19 20:34:12.24 VthC7yJG.net
Rust支持というより、現状最良の選択肢がRustであると認めているだけでは
なのでもっと良い選択肢を作ることが出来たら嬉々として打ち出してくる可能性はあると思う
914:デフォルトの名無しさん
24/02/19 20:55:09.09 WSW9DaUh.net
代替の芽が今ないから早くて十数年以上先
MojoはPythonベースで関心が数値計算に向いていて違う
915:デフォルトの名無しさん
24/02/19 20:57:44.38 34j+4tJw.net
Netflixの天才は2年かけて右端の住人になったのか
URLﾘﾝｸ(pbs.twimg.com)
これからは目立った実績が無いのにRust歴が長いと
型〇ナニーで時間溶かしてると認定される
916:デフォルトの名無しさん
24/02/19 21:23:20.71 MW9zngaI.net
>>905
Go？
Goはランタイムが大きくGCベースの言語だからRustの代わりにならんよ
917:デフォルトの名無しさん
24/02/19 21:38:55.37 BnjhEPJH.net
>>906
結局さ一周回ってAdaで良いんじゃ？
918:デフォルトの名無しさん
24/02/19 21:46:39.06 VDl5KQ6V.net
オーガスタちゃんが平�
919:嘯ｹと命令する言語？
920:デフォルトの名無しさん
24/02/19 22:19:23.32 hvnIqBoW.net
Web用途だとRustはtokioと関連ライブラリが必須だからGoよりランタイム大きくなるけどね
921:デフォルトの名無しさん
24/02/19 22:41:42.37 +OQMy10I.net
>>909
Rustバイナリが小さい
tokio+hyper他で特別な指定もなく普通に作ったweb server実行バイナリがstrip後に1.3MB
922:デフォルトの名無しさん
24/02/19 23:17:36.45 aeOZND98.net
サーバーエンドでバイナリサイズなんてどうでもいいけど専有メモリ量がJavaやGoより小さいのはよい
923:デフォルトの名無しさん
24/02/20 03:09:16.36 sgoVzbhC.net
Rustってcargo buildとかやると通信量結構えげつない
924:デフォルトの名無しさん
24/02/20 08:39:03.07 VuVDzPkr.net
依存関係があるライブラリをダウンロードすれば Rust に限らず
それなりにたいくさんひっついてくるのはよくあること。
925:デフォルトの名無しさん
24/02/20 08:51:21.95 HobPlk1l.net
C++でビルドする前にapt-getしてね、ってのも同じことだしな
926:デフォルトの名無しさん
24/02/20 09:54:42.94 avQkuhyK.net
Rustだと依存ライブラリの数が桁違いに多くなるのが原因
927:デフォルトの名無しさん
24/02/20 10:20:25.82 VuVDzPkr.net
お前それ、 JavaScript の前でも同じこと言えるの？
928:デフォルトの名無しさん
24/02/20 10:20:33.45 kmanQ674.net
>>903
その通り
Rustの次に期待
929:デフォルトの名無しさん
24/02/20 13:00:59.06 MPPpoDC+.net
>>907
ブロックが波カッコだったらなぁと思ったことある。
930:デフォルトの名無しさん
24/02/20 13:46:52.53 sgoVzbhC.net
一回DLしたパッケージOSにキャッシュしてくれればいいんだけど
そうじゃないから学習でやってると無尽蔵に取りにいくのはなんとかならんのか
931:デフォルトの名無しさん
24/02/20 14:05:25.22 VuVDzPkr.net
>>919
えっ、普通にキャッシュしますが……。
932:デフォルトの名無しさん
24/02/20 14:18:44.11 YaBXE8T+.net
>>919
1回しかダウンロードしない
その後はそのキャッシュを用いる
933:デフォルトの名無しさん
24/02/20 14:47:39.06 NZma60kC.net
それよりディスク使いすぎだろ
ビルドの中間生成物が簡単にギガ単位になる
934:デフォルトの名無しさん
24/02/20 15:44:30.40 s70xdtq8.net
>>922
それな
複雑なコンパイラでインクリメンタルビルドを高速化するには空間性能を犠牲にするしかないんだろ
935:デフォルトの名無しさん
24/02/20 15:54:29.36 VuVDzPkr.net
大きなライブラリは動的リンクすることにしてもいいけど、
そしたら実行環境の管理と開発環境の管理を分離しづらくて面倒くさくなる。
どうやったってどこかに負担はかかるならストレージさえあれば
だいたい解決ってほうがいいという戦略なんだろ。
936:デフォルトの名無しさん
24/02/20 18:32:02.94 NZma60kC.net
Rustほどディスク使う言語他にあるの？
桁違いに多いと思うんだが
937:デフォルトの名無しさん
24/02/20 18:32:44.23 pzacWR0B.net
ディスクはまあTB行かなければ何をやっても良いわ
938:デフォルトの名無しさん
24/02/20 18:46:34.01 2x98KEBQ.net
ビルドキャッシュの一部を何もしなくてもプロジェクト跨いで共有してくれればまだいいんだけどね
用途的に外部ストレージやNASに置くようなものじゃないというのが困るところ
939:デフォルトの名無しさん
24/02/20 18:56:04.80 qhUDP5tY.net
Rust (cargo)のソースダウンロードしてすべて同一マシンでビルドする前提の設計はいいと思う。
soとかdllとかjarみたいなの、あまり信頼したくないというか。
940:デフォルトの名無しさん
24/02/20 19:01:23.73 aUCxPGU2.net
Crates.ioを信頼してどうせ落ちてきたもの毎回ソース全行確認したりはしないんだから、落ちてくるものがバイナリになっても別に良いかな
941:デフォルトの名無しさん
24/02/20 19:12:55.50 HobPlk1l.net
so使ってsymbol not foundとかよくあるしな
基本的にC++ソフトのビルドは作者が使ってるディストリでしか再現しないと思ったほうがいいくらい
しょうがないからDockerでビルド環境作ったりするけど面倒だしディスクも食うし
結局ディスクキャッシュが多少多いくらいで済んでるRustが一番マシな気がする
942:デフォルトの名無しさん
24/02/20 19:56:43.04 hRyg00SZ.net
soが悪いのではなくまともなパッケージマネージャーもまともな依存解決ツールもないのが悪い
943:デフォルトの名無しさん
24/02/20 20:07:01.59 +of8n4/M.net
確かにOS非依存のC++標準パッケージマネージャと中央レジストリがあれば良かったかもね
ただその場合でもABIが不安定なのはどうしょうもないから
Rustと同じく手元で全部コンパイルする方式になったと思うけど
944:デフォルトの名無しさん
24/02/20 20:11:30.03 VuVDzPkr.net
Cargo 風の管理をする C++ 用パッケージマネージャはある。
最初からそのパッケージマネージャ用に構成してくれてないと
なかなか素直にはビルドできないことに変わりないんだけど。
パッケージマネージャが優秀でも C++ 世界では
「統一されていない」ことが面倒くささになってる。
945:デフォルトの名無しさん
24/02/20 21:39:15.46 1smOJz8O.net
そう考えると中間言語形式で配布できてAOTコンパイルもできる.NETがさいつよって話？
946:デフォルトの名無しさん
24/02/20 21:43:07.30 BYbBGAeA.net
NuGetが使いやすいと感じた事がないし、充実していると感じたこともない
947:デフォルトの名無しさん
24/02/20 21:59:58.18 VuVDzPkr.net
>>934
dotNET は事前コンパイルしてもランタイムサポートの分厚さ (にかかる実行コスト) は避けられないので
コンピュータの性能を絞りきるようなつよつよ最適化は無理じゃないかなぁ。
いろんな方式の良いところを上手く取り入れて総合的には良いものに仕上がってるとは思うけど
それが最強かというと状況によるんじゃないの。
948:デフォルトの名無しさん
24/02/20 22:14:04.42 sgoVzbhC.net
>>921
チャプターサンプル毎にプロジェクト作ったら毎回DLしてるように見えるけど
949:デフォルトの名無しさん
24/02/20 22:16:27.29 FbkkUU+G.net
パッケージの使い勝手という意味ではdocs.rsの存在も大きい気がするな
どんな野良ライブラリでも決まった場所に決まったフォーマットのAPI一覧が確実に存在するというのはかなり便利
950:デフォルトの名無しさん
24/02/20 22:30:04.17 VuVDzPkr.net
ドキュメントを全く書かなくても少なくとも公開されている一覧はわかるってのは強い。
最悪の場合でもコードへのリンクもあるし。
Haskell のリポジトリがこういう感じだったので他の言語でもこれくらいやればいいのにと思ってたから
Rust で取り入れてくれたのはかなり嬉しい。
951:デフォルトの名無しさん
24/02/20 22:37:39.60 NZma60kC.net
>>926
いや、スマホでセルフ開発する時に困るだろ？
952:デフォルトの名無しさん
24/02/20 22:45:53.34 VuVDzPkr.net
>>940
そんなやつはおらんで～～
953:デフォルトの名無しさん
24/02/20 22:47:07.61 1CgxDriU.net
ス、スマホ？
954:デフォルトの名無しさん
24/02/20 23:05:21.55 YDnp1LJs.net
procマクロとかコンパイル環境で展開したいものを除くとtarget指定した環境に依存するだけだから手元でコンパイルする必要性は全くない
いずれにしろどこでビルドするかと中間生成物のサイズが異常にデカくなる話とは別の話だよね
955:デフォルトの名無しさん
24/02/20 23:07:55.15 VuVDzPkr.net
もしスマホで開発する人がいたとしても
レンタルサーバに接続して表面上の操作にスマホを使うだけで、
実質的なストレージ・計算リソースはサーバのものを使う形にするのが普通。
スマホ内で完結させようとしたらツールチェインをセットアップするだけでもクソ面倒くさい話になるぞ。
956:デフォルトの名無しさん
24/02/21 00:35:56.53 ax8uXPdD.net
働いてないとスマホで開発するとかいう前代未聞の人間がいるんだな
957:デフォルトの名無しさん
24/02/21 01:44:30.82 q3i686zw.net
スマホで開発はむしろ最先端
958:デフォルトの名無しさん
24/02/21 05:17:16.65 cGlapTzK.net
iPhoneが出たばかりの頃から、脱獄して開発環境を入れてObjective-Cでプログラミングしてる人は一定数居ただろ。
最近では、どのプログラミング言語でも使えてLinux（Android）と遜色ないよ。
今のスマホは、外部モニターも外部SSDも繋げるし、外部グラボのGPUでLLM開発だってできる。ほぼほぼRaspberryPi5と変わらないよ。
だからこそ組み込みにも強いRustが注目されてるんｼﾞｬﾏｲｶ
959:デフォルトの名無しさん
24/02/21 05:44:41.84 cGlapTzK.net
スマホでRustformersからLLM開発する場合、ローカルにOllama入れとくか、サーバにGPT-4やLlama2を入れとくかぐらいの違いしかない。
Google Coralもスマホでも使える前提の製品で、このチップは発熱量が減ればスマホに内蔵されるだろう。
実際、Vision Transformerのような技術を応用しているApple Vision Proが製品化されたから、スマホからこういった機器に移行するのかもしれない。
今後数年間、これらの技術動向から目が離せない状況が続くんだろう。
960:デフォルトの名無しさん
24/02/21 08:28:43.22 /iiJfWDN.net
ダウンロードしたクレートキャッシュの自動削除はもうすぐ来そう
ビルドキャッシュの自動削除はその後実装予定っぽい
URLﾘﾝｸ(blog.rust-lang.org)
961:デフォルトの名無しさん
24/02/21 08:31:36.21 /iiJfWDN.net
グローバルなビルドキャッシュ共有の話も予定には挙がってるね
962:デフォルトの名無しさん
24/02/21 09:05:07.84 33Eh81yS.net
>>934
何を基準でさいつよかの定義による
デスクトップ
Web
バックエンド
iOS/Android
ゲーム
とC#だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC#使えれば何でも作れるという意味ではさいつよ
963:デフォルトの名無しさん
24/02/21 09:19:16.71 VUY6mIOu.net
>>951
.netの毎年の長文blog最適化レポートを見ると2年後くらいでNativeAOT最適化がC/C++に肉薄すると思う
964:デフォルトの名無しさん
24/02/21 10:25:34.81 ygn/feiE.net
デスクトップ
Web
バックエンド
iOS/Android
ゲーム
とC言語だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC言語使えれば何でも作れるという意味ではさいつよ
チューリング完全なので
965:デフォルトの名無しさん
24/02/21 10:33:55.14 3B94ePzU.net
無能なやつほどゴールデンハンマー症候群に罹患しやすい
966:デフォルトの名無しさん
24/02/21 10:37:42.60 33Eh81yS.net
>>953
嘘ばっかりだなw
967:デフォルトの名無しさん
24/02/21 12:23:52.50 FRHKNAr+.net
>>949
さすがに問題として認識はしてたんだな
スマホセルフ開発の日は近い
968:デフォルトの名無しさん
24/02/21 12:50:43.67 ax8uXPdD.net
マジでスマホしか持ってないの？
クソワロタ
969:デフォルトの名無しさん
24/02/21 13:41:48.13 s/93fWsg.net
ウェアラブル系の機器には失望した。
どこへでも持っていけるよりどこへも往く必要のないインフラこそ目指すべき未来だろ。
970:デフォルトの名無しさん
24/02/21 14:32:00.13 T2E+AzfY.net
>>954
同意
971:デフォルトの名無しさん
24/02/21 15:10:22.61 KvtS9dqN.net
>>958
背もたれ付きベッド
972:デフォルトの名無しさん
24/02/21 15:11:12.28 KvtS9dqN.net
>>953
Rustはチューリング安全だぞ
973:デフォルトの名無しさん
24/02/21 16:06:34.40 RjxZ1GsP.net
>>957
働いてないと「スマホで開発==スマホしか持ってない」という発想になるんだなww
974:デフォルトの名無しさん
24/02/21 16:15:10.41 cGlapTzK.net
>>960
ベッドといえばフランスベッドが取り扱ってるAI 視覚支援機器『オーカム マイアイ2』(OrCam MyEye 2)は、
イスラエルのオーカムテクノロジーズ（OrCam Technologies Ltd）の製品だったな。
これは活字の読み上げみたいだけど、寝具メーカーは、どこへも往く必要のない未来インフラをAI使って目指してるんだろう。
ウェアラブル系が狩猟型・動物型とすれば、寝具系は農耕型・植物型なんだろうな。人間は生活の約３割は寝てるんだから当然だけど。
975:デフォルトの名無しさん
24/02/21 16:30:25.40 vYwp44u6.net
表向きはどうであれたぶん寝たきり用だから話を膨らませるのはそのくらいにしとけ
976:デフォルトの名無しさん
24/02/21 16:47:28.48 OHlXXLmE.net
いくらなんでもスマホでコーデングはせんやろ
977:デフォルトの名無しさん
24/02/21 16:49:23.05 1mshJDzd.net
寝たきりで親指しか動かないとかならスマホでコーディングするかもしれん
978:デフォルトの名無しさん
24/02/21 16:54:05.86 s/93fWsg.net
性能がどうこうよりもシンプルに画面が狭いのはすごくつらい。
無理。
979:デフォルトの名無しさん
24/02/21 18:17:59.27 ax8uXPdD.net
>>962
いやお前に当てはめてるだけだぞ
何言ってんだ？
980:デフォルトの名無しさん
24/02/21 21:37:40.46 4F0o6gVI.net
はちみつ餃子氏最近見ないからRust関連は触れないことにしたのかと思ったらコテ外して書き込みに来ててわろた
981:デフォルトの名無しさん
24/02/22 16:00:18.09 o0M/RgFs.net
>>969
新スレ立ったときに名前欄に入力するのを忘れてたままやな
982:デフォルトの名無しさん
24/02/22 23:42:55.14 1e40BABA.net
>>949
毎晩ならその機能もう使えるのか
983:デフォルトの名無しさん
24/02/23 12:05:46.18 vPqrWVzU.net
今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうが。
984:デフォルトの名無しさん
24/02/23 12:05:51.79 vPqrWVzU.net
今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうけど。
985:デフォルトの名無しさん
24/02/23 15:12:44.34 z6SHyxko.net
iPadでXcode使えるからそれで遊んでみれば
986:デフォルトの名無しさん
24/02/23 15:20:09.67 CheDQupm.net
Rustが使えないとな
987:デフォルトの名無しさん
24/02/23 15:21:05.22 jTrUecQ5.net
クソスレまで立てちゃってw
素直に中古のノートPCでも買えよ
988:デフォルトの名無しさん
24/02/23 16:04:17.89 02Kw336h.net
traitの種類多すぎて把握しきれん
使い分けもようわからんし
989:デフォルトの名無しさん
24/02/23 16:18:25.67 NJWNbZ5N.net
Pythonのpep20みたいなってRustにもあるの？
990:デフォルトの名無しさん
24/02/23 16:32:06.33 eHVJk53E.net
スマホやタブレットなどのモバイルOS上に開発環境用意するのは主に2つユースケースがある
1つはモバイルOS上で実行させる小さなユーティリティを作るため
だいたいlinux emulatorみたいなアプリ内環境で稼働させる
もう一つは出先の空いた時間や障害対応等の緊急時にノートPCを持ち歩かなくても簡易的な作業なら対応できるようにしておくため
前者はスマホだけで作るやつもいるにはいるが少数派
なので今のところはメイン開発環境は別に用意してるのが大半
991:デフォルトの名無しさん
24/02/23 17:15:31.94 kgcjkDLJ.net
PEP20って何だよと思ったらあのウンコポエムだった
992:デフォルトの名無しさん
24/02/23 17:26:44.63 kgcjkDLJ.net
次スレタイトル間違えてしまったのですまんが誰か立て直してくれ
規制食らってもう立てられなくなった
993:デフォルトの名無しさん
24/02/23 17:35:21.56 CheDQupm.net
>>977
traitとは機能を抽象化した抽象型だから使いたい機能のtraitを選ぶか作ればよい
structなどの具象型は各々必要な各機能(trait)を実装しているもしくは実装すればよい
そして抽象型(trait)を用いてプログラミングすることでその機能を実装する全ての具象型を対象とした共通コードにできる
994:デフォルトの名無しさん
24/02/23 17:38:39.47 CheDQupm.net
次スレ
Rust part23
ｽﾚﾘﾝｸ(tech板)
995:デフォルトの名無しさん
24/02/23 17:45:54.27 kgcjkDLJ.net
>>983
ありがとう
996:デフォルトの名無しさん
24/02/23 17:51:32.20 jYYzpIEX.net
>>978
こういうのをまとめようとはしているよ
URLﾘﾝｸ(smallcultfollowing.com)
997:デフォルトの名無しさん
24/02/23 20:10:18.94 1IK2X2kO.net
>>982
FromとかAsRefとかDerefとかの時点でもうようわからんぜ
998:デフォルトの名無しさん
24/02/23 22:42:10.08 oukljDwS.net
Fromは汎用的な変換だよ
変換に失敗する可能性を含む時はTryFromを使う
AsRefは参照から(別型の)参照への読み替え変換
コストがかからない場合が対象
コストがかかるものはFromを使う
Derefは変換ではなく演算子
変換は複数の型への変換を実装できるけど
演算子なので各型で決められた一つの型へderefできる
&T→T
Box<T>→T
Rc<T>→T
Vec<T>→[T]
String→str
PathBuf→Path
など
999:デフォルトの名無しさん
24/02/23 23:50:59.87 1IK2X2kO.net
あー。それぞれの比較はまあそうなのかもしれないんだけど、そもそもどういうtraitがあってどういう時に使うべきなのかを全て把握できてないせいで実際にコード書く時にどれを使うとRustらしいコードになるのかわからなくなるってのがしんどいんだよね
1000:デフォルトの名無しさん
24/02/23 23:59:41.76 hX/YHnPg.net
>>988
どの分野のどんな話でも基本パターンの学習による慣れ
問題
match std::env::args().XXXXX {
Some("yes") => ...,
Some("no") => ...,
_ => ..., // エラー
}
1001:デフォルトの名無しさん
24/02/24 02:12:39.95 YQ3M0cmx.net
梅
1002:デフォルトの名無しさん
24/02/24 04:00:00.27 felFEjYK.net
「当然こういうのが標準ライブラリにあって然るべきだろう」みたいな感覚ができるから結局は慣れ。
常識的に考えてあるだろうと思ったら nightly だったみたいなこともよく経験するから俺が欲しいようなものはみんな欲しいんだなと思う。
実質的に言語の一部みたいなくらいのやつは嫌でも避けられないから何度もドキュメントを読み返すはめになるし、そのうち自然に使えるようになる。
1003:デフォルトの名無しさん
24/02/24 12:21:57.67 lhpjpr9r.net
>>987
Derefは演算子でも利用されるがDerefそのものが演算子(や演算子の実装)というわけではない
Type Coercionというのは型変換(Type Conversion)の一種なのでDerefは変換ではないというのもやや言い過ぎ
各型で決められた一つの型にderefされるのは演算子だからという理由ではなくて
Derefはスマートポインタが包んでる値へのアクセスを便利にするために用意されたものだからderef先の型は自然と一つに決まるため(>>733)
&T→TはDerefの役割ではない
1004:デフォルトの名無しさん
24/02/24 12:57:43.72 Sbx59RJL.net
AsRefとBorrowは未だにわからんなあ
調べてもHashMapがBorrow要求するならそこだけBorrow使っておけばいいか……で思考停止してる
1005:デフォルトの名無しさん
24/02/24 13:58:08.04 Q2pRspv0.net
埋
1006:デフォルトの名無しさん
24/02/24 13:58:23.94 Q2pRspv0.net
生め
1007:デフォルトの名無しさん
24/02/24 13:58:40.99 Q2pRspv0.net
、埋め
1008:デフォルトの名無しさん
24/02/24 13:58:46.56 Q2pRspv0.net
！埋め
1009:デフォルトの名無しさん
24/02/24 13:58:52.17 Q2pRspv0.net
？埋め
1010:デフォルトの名無しさん
24/02/24 13:59:00.55 Q2pRspv0.net
○埋め
1011:デフォルトの名無しさん
24/02/24 13:59:07.65 Q2pRspv0.net
～埋め
1012:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 34日 14時間 37分 28秒
1013:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています