X

結局C++とRustってどっちが良いの？ 2traits

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2023/04/02(日) 00:42:57.53ID:W9/nq+tL
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていうスレ。

前スレ: 結局C++とRustってどっちが良いの？
https://mevius.5ch.net/test/read.cgi/tech/1677286186/
0799デフォルトの名無しさん
垢版 |
2023/04/30(日) 10:56:20.23ID:RO3CktaP
bindgenでC/C++のheader変換させると
warning: type `ho_ge` should have an upper camel case name
help: convert the identifier to upper camel case: `HoGe`
みたいな余計な御世話なメッセージが出捲るんだが
これを抑制する方法って無い？
0801デフォルトの名無しさん
垢版 |
2023/04/30(日) 14:46:52.74ID:eJ3rvh+g
.to_string() とか
.to_str() とか
.to_str().expect("やりなおせ") とか
.to_str()? とか
.as_str() とか
一貫性がないな
0802デフォルトの名無しさん
垢版 |
2023/04/30(日) 14:50:03.03ID:xL1w2Uvw
>>799
抑制する方法もエラーメッセージに出てなかったっけ？
0803デフォルトの名無しさん
垢版 |
2023/04/30(日) 16:01:15.73ID:RO3CktaP
#![allow(non_snake_case)]
#![allow(non_camel_case_types)]
#![allow(non_upper_case_globals)]
で出来たけど
#[allow(non_snake_case)]
#[allow(non_camel_case_types)]
#[allow(non_upper_case_globals)]
にしろって書いてあるサイトもある
どっちなんだろ
0804デフォルトの名無しさん
垢版 |
2023/04/30(日) 16:11:01.60ID:RO3CktaP
2つ以上のC/C++のprojectから
bindings1.rs
bindings2.rs
みたいに造って同時にinclude!()すると
定義の衝突とか出るけど
header1.hとheader2.hのどっちにも
#include <iostream>
みたいなの書いてあるとそうなるんかな
面倒だな
0805デフォルトの名無しさん
垢版 |
2023/04/30(日) 18:48:15.79ID:wJbSgVTK
DDR4-SDRAMのCASレイテンシーは、15クロックではなく、15(ns)程度だった。
3GHzのCPUだと、45クロックという事になる。
0806デフォルトの名無しさん
垢版 |
2023/04/30(日) 19:13:17.45ID:4cTphIc0
>>805
いろいろ間違ってるで
SDRAMのCASレイテンシってのはナノ秒じゃなくクロックサイクル数
それもCPUクロックじゃなくRAMクロックのサイクル数
0809デフォルトの名無しさん
垢版 |
2023/04/30(日) 19:41:46.22ID:N5T1k6H1
>>801
Rustは一貫性があるようにガイドラインで命名ルールも定められている
as_xxxとto_xxxの違いは基本的に
as_xxxはコストなく別の型とみなす
to_xxxはコストかけて別の型を作るかみなす

その例ではもちろんstrとStringは別の型
基本的にas_strとto_stringが使われる
as_strは内部でstrとみなせるデータを持っている時にそこを指すだけなのでコストがかからない場合
to_stringは任意の型からStringを作り出すのでコストがかかる
to_stringはtrait ToStringのメソッドだがtrait Displayを実装することで自動的に実装される

唯一の例外がto_str
これは外部からのデータに対して存在する
strは必ずvalidなUTF8であると保証されている
一方でOsStrやそれを使っているPathは必ずしもvalidなUTF8であると保証されない
そこでUTF8チェックのコストが生じるのでto_strとなる
FFIであるCStrからも同様にto_strとなる
0811デフォルトの名無しさん
垢版 |
2023/04/30(日) 21:38:41.35ID:JKacdrUN
1クロック君も分かってないんだから
あんまり人のことは言わんほうがええで
0812デフォルトの名無しさん
垢版 |
2023/04/30(日) 21:45:00.52ID:r3YjkTH3
Python界隈のCodonを以前評価したけど速度面でC/C++と同等なのは単純なケースに限られるようだった
しかも多分皆が最初にみたAckermannの例はgccがclangを凌駕するパターン(再帰Fibonacciなんかもそう)
良いとこだけ記事にした方がいいねもらえるという情報ジレンマ..
0814デフォルトの名無しさん
垢版 |
2023/05/01(月) 00:28:33.95ID:SO3cX7+E
>>811
1クロック君 = ID:bU1qZ3nv のことか？
流し読みだと805は1クロック君で、>>752=move君(C++,Rust,Python)とコムソートの話をしてるのね

Rustユーザ-> >>563みたいな数独パズル状態でどん詰まり傾向、途中LinkedListは遅い発言を受けるも >>581でやっと動くが何もしない
1クロック君->呼ばれて登場、いつもの虚言連射 自分の思い込みと異なる現実を見たくないから意地でもコード書かない
move君->(いろいろ分かってないので、1クロック君の虚言でも)何かしら動くコードにしてideoneに置く、慣れないC++で
C++側->面白がってコード弄る、ベンチ晒す、けど全員離脱 move君はそれでも勉強になったとお礼

move君、いい奴なんじゃね？
0816デフォルトの名無しさん
垢版 |
2023/05/01(月) 09:28:12.86ID:KqibJVEU
あらゆるところに関所がある
まるで江戸時代だ
裏山に抜け道を見付けて分け入っても
突然藪から棒に番人が現れる
ところがそんな番人も
unsafe印籠を魅せれば一撃で退散だ
unsafe万歳!!!
こんなことなら最初から
表通りでunsafe印籠を出しておけば良かったんだ
きっと番人たちも思っているはず
さっさと最初からunsafe印籠魅せやがれ
無駄な手間取らせやがって
こんなのがエコシステムとか失笑もの
0817デフォルトの名無しさん
垢版 |
2023/05/01(月) 10:11:02.89ID:PhTcfeBC
C++のバイブルeffective C++でやってることを何も考えなくても
できるのがRustだよな
0818デフォルトの名無しさん
垢版 |
2023/05/01(月) 11:26:54.16ID:58qbKD3W
C++のconstを更にウザくした感じをデフォルトにした?
まぁ安全なんだろうけども
0820デフォルトの名無しさん
垢版 |
2023/05/01(月) 12:59:11.10ID:w7ftGEnh
これが先週のLinkedListチャレンジの結末である

Rust → どん詰まり傾向、1になればゴール
慣れないC++で → 慣れてなくとも独力で0を1にして動くコード提出、その先は先輩たちがサクッと引きあげ
0821デフォルトの名無しさん
垢版 |
2023/05/01(月) 13:08:10.08ID:6zKo1tMC
ちょっとした車輪ならぱぱっと組めて当然なのがC++ (俺はまだまだだけどｗ
だからこそ、メモリ関係のバグ・デバグに気を取られたくない unsafeの取り込みは急務
0822デフォルトの名無しさん
垢版 |
2023/05/01(月) 13:35:33.76ID:nAkxf6DU
よろしくゴサシュー

×Rust → どん詰まり傾向、1になればゴール
〇Rust → どん詰まり、1に出来ずに、ポエムにいいね
0823デフォルトの名無しさん
垢版 |
2023/05/01(月) 13:52:07.74ID:Gt7Bjt72
FPGA君も居るんだね
0824デフォルトの名無しさん
垢版 |
2023/05/01(月) 17:12:27.61ID:eFKh9HN+
C++でもnew/deleteなんてだいぶ前から使ってないけどな
C++03時代の話を未だにしてるけど、20年も前の環境だし、Boostも1.84からC++03のサポート終了が本格化する
この際、C++20まで一気にジャンプしたら良い
C++17と20の間にも互換性の壁があるので、過去の資産があるならC++17でも良いかもしれない
C++20は便利なので、資産が無いなら一気に飛べ
0825デフォルトの名無しさん
垢版 |
2023/05/01(月) 20:01:02.15ID:K5ZoaRkG
顧客には「リスク歓迎型」と「リスク重視型」いるが、Rustはいまのところ
前者が使ってる段階。
0828デフォルトの名無しさん
垢版 |
2023/05/01(月) 21:35:47.11ID:WwaB4YeM
>>824
C++20になったらこれに対応できるようになるって話はどうなったんだっけ？

[Ruby]
a.sort().reverse().map{|x| x.to_s}.join("-")

[JavaScript]
a.sort().reverse().map(x => x.toString()).join("-")

[Rust]
a.iter().sorted().rev().map(|x| x.to_string()).join("-")
0829デフォルトの名無しさん
垢版 |
2023/05/01(月) 23:46:23.25ID:Hk/n819+
よく表れる偉そうな人は
プロジェクトでは活躍できているの？
0830デフォルトの名無しさん
垢版 |
2023/05/02(火) 00:22:12.87ID:HfuJGdbc
>>828
既存のイテレータの問題を改善するためにC++20でstd::rangesが導入された
しかし限界というか期待外れというか無理があって使いやすいものにならなかった
0831デフォルトの名無しさん
垢版 |
2023/05/02(火) 00:49:58.35ID:1DAvDJUY
>>826
リスクを恐れずに新しいものを好む人、失敗しても特になんとも思わない人が
試している状態だということ。
0832デフォルトの名無しさん
垢版 |
2023/05/02(火) 01:35:45.73ID:icSV2sCY
>>831
それは5年以上前の話
現在は様々なインフラがRust製に置き換わりつつある段階
例えばRustで書かれたAWSが安全に問題なく高速に作動し、その上に世界中の各社のサービスが動いていて、世界中の人々が恩恵を受けている
0833デフォルトの名無しさん
垢版 |
2023/05/02(火) 01:41:41.06ID:1DAvDJUY
>>832
ただ、プログラミング業界において、まだ、使用者数が1%未満くらいしかない。
イノベーター理論によれば、2.5%位までが「イノベーター層」、次の20%
位が、アーリーアダプター層で、それらを合わせた23%位が、「リスク歓迎層」
いわゆる「人柱層」であり、その後に「キャズム」と呼ばれる溝が有ると言われている。
だからRustが普及するためにはまだまだずっと先が有る。
0834デフォルトの名無しさん
垢版 |
2023/05/02(火) 01:45:06.54ID:1DAvDJUY
>>833
大勢に影響ないが、数値はちょっとずれていて、ちゃんと調べてみたら、
イノベーター層: 2.5%
アーリーアダプター層: 13.5%
----キャズム----
アーリーマジョリティー層 34.0%
だったわ。
0836デフォルトの名無しさん
垢版 |
2023/05/02(火) 01:54:56.85ID:1DAvDJUY
有料商品だとリスクを恐れて買わない人が多いけど、Rustは無料だから
試すのはタダだから、金銭的には損はしないが時間とストレージ容量は損する。
ジュースみたいに飲んで美味しいわけでもない。
0837デフォルトの名無しさん
垢版 |
2023/05/02(火) 01:58:03.27ID:1DAvDJUY
Rustを試す場合、ストレージが結構食うのと、「パス汚染」の問題や、いつのまにか
大事にしていた開発の複雑なツールチェイン環境が
「おかしくなるかも知れない問題」が有る。
経験法則として、ツールチェインが壊れることは辛すぎる。
0838デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:05:41.68ID:1DAvDJUY
Rustは、確かにニーズは有ることはあるが、緊急レベルが低いのかもね。
それとターゲット層が狭いかも。
0839デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:12:40.43ID:1DAvDJUY
Rustを使いたがってる層って、なぜかサーバーサイドで使おうと思ってる人が多いが、
複雑で遅くなるような処理はMySQLやSQLiteみたいなDBMSがやってしまう。
だから自分でやる部分は余り速度が必要なかったりする。
Rustは安全性と速度の両方重視だが、この場合、速度は不要であり、安全面だけ
しか残らないがだとすると、JavaやRubyなどでも互角と言えてしまう。
しかも分かり易さは後者の方が勝ってる。
0840デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:15:06.87ID:1DAvDJUY
SNSを見ても、なぜかRustをフロントやデスクトップアプリで使おうとしている人は少ない。
そもそもデスクトップアプリが絶滅危惧種になりつつあるが。
多分、GAFAMが全部需要を吸い取っているからかも知れんが。
0841デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:28:34.92ID:7LVjR2sm
ガンダム00のイノベーター理論か
0842デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:28:36.64ID:1DAvDJUY
そもそも、サーバーサイドやフロントは、CもC++も余り使われてこなかったが、
SNSでは、なぜか、そっち側でRustを使いたがってる人が目立つ。
そもそも、デスクトップやゲームでCやC++が強い。だから、C++の優位性や
慣れ親しみが有る人と層が被ってない。
なのに、彼らは「C/C++をRustが置き換える」と主張している。
彼らにはそもそも自分がCやC++を愛した時期があったのかと問うてみたい。
C++を使いこなした上で、さらにそれより便利だからRustを使おうとしている
ならまだしも、C++とは縁遠い人達がRustを礼賛している様に思えてならない。
0843デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:32:22.41ID:1DAvDJUY
もともとC++が大嫌いな状態で、C++が消えてなくなればいい、と思っている
層がRustを嬉々として使いたがっている様に見えるのだ。
そして彼らはC/C++を一切話題にしない。もし今ままでC/C++を使い倒してきた
ならば、少しは触れてもいいはずなのに、彼らが好きな言語としてあげるリスト
の中には、決まって、C/C++が全く触れられておらず、
JS、Go、Kotlin、Java、Pythonなどが上がってくる。
C#ですら上がって来ない事が多い。
0845デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:36:05.66ID:1DAvDJUY
昔から言われてきたことだが、Windowsのデスクトップアプリを作るのは、
ほぼ Visual Studio 一択 だということである、
そして、その場合、通常、C/C++(MFC、Win32)、C#(WinForms、WPF)、VB
のどれかとなる。
プロは、有料のVSを購入して、C++でMFCで組むのが標準とされてきた。
0846デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:50:16.47ID:7LVjR2sm
MFCは流石にストレスだな
0847デフォルトの名無しさん
垢版 |
2023/05/02(火) 02:51:03.38ID:7LVjR2sm
BoostはURLやJSON、そしてついにMySQLが入ったぞ
0848デフォルトの名無しさん
垢版 |
2023/05/02(火) 03:00:27.06ID:7LVjR2sm
RegexはC++のパワーが発揮される好例だが、あまり使われてないね
文字を返すイテレータさえ用意できれば、どんなデータ構造にも正規表現が使えるんだから凄いけどね
0849デフォルトの名無しさん
垢版 |
2023/05/02(火) 03:04:05.05ID:1DAvDJUY
>>848
RegExの基礎の部分で、日本語周りがちょっと独特の仕様だった気がする。
UTF8やSJISには状態がない(Stateless)符合なのに、状態があるかのような
独特のC関数(?)を基礎にしている。
それは、もはやほとんど使われて無い、「Shiftじゃない方のJIS」の
ShiftIn(SI), ShiftOut(SO)方式ならそうかも知れないが。
0851デフォルトの名無しさん
垢版 |
2023/05/02(火) 03:11:39.95ID:1DAvDJUY
>>843
補足すると、C++が好きで、または、どこかに問題点を感じながらも使ってきたが、
さらに良いものを見つけたからRustに移行したい、というなら、C++も好きな
言語リストに入れたり、話題に触れたりするものだが、彼らは一切、
C++に触れようとしない傾向がある。
どんな言語にも欠点があるから、長年使ってきた言語であるならば、
愛着があっても、欠点も知っている。だから、もしC++を使ってきたならば、
C++の欠点を沢山気付いても、一方で、愛着も持っているはずだ。
ところが、彼らは、C++について一切触れずに、初心者用の簡易言語で
あるところの、JS、Java、Kotlin、Go、C#、Pythonなどには沢山触れるが、
C++には一切触れようとしない。
0852デフォルトの名無しさん
垢版 |
2023/05/02(火) 03:20:05.38ID:7LVjR2sm
>>851
キミもあまりC++を使っていないのでは？
0854デフォルトの名無しさん
垢版 |
2023/05/02(火) 04:07:41.22ID:6GBjYlnU
世の中の流れが様々な方向からRustへ向かっているところをみると残るは時間だけの問題かな
ロジックに弱い一部のプログラマーはRustでスマートに組めない傾向があるからその点での差別化も進むのかもしれない
0855デフォルトの名無しさん
垢版 |
2023/05/02(火) 04:14:17.45ID:1DAvDJUY
>>854
もしかしたらそうなのかも知れないな、と思う自分もいるが、
数値を見れば、ランキングは19位くらいで、使用者数は1%未満の状態。
それと個人的には、言語としてメンドクサイ。
0856デフォルトの名無しさん
垢版 |
2023/05/02(火) 04:38:02.37ID:6GBjYlnU
>>855
Rustをメンドクサイと感じるならロジックが苦手な人なのかもしれないね
一般的にどの言語でもプログラミングする時はロジックをパズルのように解いて組み立てていくんだけど
複雑な対象かどうかでそのパズルの難易度は様々でロジックが苦手な人は難しいパズルのケースではお手上げ

Rustではその解かなきゃいけないパズルが問題によって難易度が増す場合もある
それと引き換えに様々な多大な恩恵が生じるわけだけどロジックが苦手な人には難しかったり面倒だったり無理だったりしてしまう
でも元々のパズル自体の難度に対してそれほど難しくなるわけではないためプログラマーのほとんどはクリアできるけどね
結果的に極一部のロジックが苦手なプログラマーを切り捨てることで可読性や開発効率や安全性などを上昇させるのがRustというものの本質かもね
0858デフォルトの名無しさん
垢版 |
2023/05/02(火) 04:45:42.58ID:iwR4I1Vp
ぶったぎるようでいて、多分関連ある 素直に聞かせて
上のほうでも少し出たけど、RustのOOPってどうなん 慣れればわりとなんでも書ける?
所有権関係を見習いたくて、そればっかり今まで調べてて、OOPの書き心地に目を向けてなかった
0859デフォルトの名無しさん
垢版 |
2023/05/02(火) 04:54:26.56ID:iwR4I1Vp
>>850
たまにはATL/WTLも思い出してあげてください

あれ使いこなせるようになりたいな
そんなことを思いながらC++を趣味でやってる(異業種です
0860デフォルトの名無しさん
垢版 |
2023/05/02(火) 04:58:39.18ID:6GBjYlnU
>>858
RustやGoなど最近の言語ではOOPの癌であるクラス継承を完全に廃止してくれている点が朗報
代わりにRustでは強力なトレイトがあって非常に分かりやすく可読性もよいコードに誘導されて書き心地もよいよ
ただしクラス継承という癌におかされ中毒症状というか依存症の人の一部はリハビリ期間が必要なこともあるみたい
0861デフォルトの名無しさん
垢版 |
2023/05/02(火) 05:48:34.65ID:iwR4I1Vp
COMとか使ってたしねえ 今でもあるけど
やたらややこしくしないまで含めて、継承は使ってた世代だねえ
template<>だけがあるような感覚? (概要を聞いてからリファレンス見る勢
0862デフォルトの名無しさん
垢版 |
2023/05/02(火) 06:21:41.90ID:htF/u6KD
Rustのtraitは機能や能力や属性でもあるし制約条件でもあるし抽象的な型でもあるしtraitオブジェクトとしての値でもあるし
traitと普通の型とは直交する存在だから多対多の関係になるけど
trait自体に別のtraitが制約としてつく形でtraitの持つ機能の継承のように見せかけて継承ではないけど親子関係的になったり
実際のコードではほとんどのケースで具体型にモノモーフィゼーションされるからコストはないけど
一部のケースではtraitオブジェクトになって動的ディスパッチになる点ではC++で仮想関数を定義する基底クラス的な立ち位置でもあり
0863デフォルトの名無しさん
垢版 |
2023/05/02(火) 07:08:44.62ID:KGzdAUSh
>>861
templateをRustでジェネリクスとして表現する時に、そのジェネリックパラメータに対して、条件(制約)を課す指示となる「トレイト境界」としてもトレイトが登場
そのおかげで、C++のtemplate使用時の展開深入りしたわかりにくいエラーメッセージが出る前に、Rustではトレイト境界を指定するようにとコンパイラが叱ってくれて話が早いこともある
0864デフォルトの名無しさん
垢版 |
2023/05/02(火) 07:41:43.85ID:7LVjR2sm
世界中で使われたはずのHaskellが跡形もないからどうだろな
0865デフォルトの名無しさん
垢版 |
2023/05/02(火) 08:07:22.94ID:kr+/BuUA
GC言語なんていくらでも置き換えが効くからな
しかもGC言語は用途が狭く限定
ダメ言語C++が長く崩れなかったのはライバルが登場しなかっただけにすぎない
何もかも優れている非GC言語が登場してC++がようやく崩れた
0867デフォルトの名無しさん
垢版 |
2023/05/02(火) 09:16:12.71ID:AMbvZcVM
>>833
プロダクトライフサイクルにおける顧客割合の意味を理解してたらそんなアホみたいな比較はしない
0868デフォルトの名無しさん
垢版 |
2023/05/02(火) 10:52:59.55ID:xauM/oA9
>>860
このレベルの理解力しかない複オジがRustを推すからバカにされるんだよな
いい言語なのに
0869デフォルトの名無しさん
垢版 |
2023/05/02(火) 11:28:20.72ID:pc/ucEUa
>>860
何で継承を廃止したのかな?
新たなパラダイムを採用するにしても
継承を残しとけばC++ユーザの取り込みが進んだだろうに
0871デフォルトの名無しさん
垢版 |
2023/05/02(火) 12:15:36.07ID:7LVjR2sm
>>869
C++ユーザーは取り込めないし、取り込む気もないのでは

C++より優れているという宣伝文句は、主にスクリプト言語を使っている人の心をくすぐるのだと思う
0872デフォルトの名無しさん
垢版 |
2023/05/02(火) 12:18:56.04ID:gDBZ1McM
>>870
自分で考えなよ
顧客タイプ別の割合を足せば100%になるんだからちょっと考えればわかるでしょ
0873デフォルトの名無しさん
垢版 |
2023/05/02(火) 12:23:57.05ID:avRvtz73
>>869
何でか説明してるレスに何でか聞くのってヤバいと思う
0874デフォルトの名無しさん
垢版 |
2023/05/02(火) 12:38:11.31ID:7LVjR2sm
そもそもRustはC++に比肩しうるような性能を持たない
0877デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:06:17.14ID:7LVjR2sm
DEVICE=A:\DOS\HIMEM.SYS
0879デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:13:06.37ID:7LVjR2sm
主にJS使いがRustを使ってるからね
0880デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:21:48.41ID:moHVYXda
>>874
上手に書けば似たようなもんだろうから、性能はそんなに争わなくていいぞ
ヘタクソが使ったら性能出ない、じゃどっちもどっちｗ
0881デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:21:50.46ID:rS/MFCk8
>>869
Rustと関係なく昔からOOPでは
継承(is-a)より合成(has-a)が望ましい
という話を聞いたことがない？
合成(has-a)の方が柔軟性が高いだけでなく
各機能ごとにコードを分けられるため
可読性も上がり保守性も良くなる
菱形多重継承の問題も避けられる
巨大な親クラスを用意する必要もなくなる

別の見方をすると
継承は複数の役割を混ぜて詰め込んでいる
コードの共通化や多層性など別々の役割が混在してる
それが上述の継承の様々な問題を引き起こしている
それぞれの役割が個別に提供されたら継承は不要となる
そして問題はなくなり可読性も保守性も向上する

以上の話はRust以前から言われてきた話
そしてGoもRustも当然のように継承は廃止した
まともなプログラマーなら継承は複数の役割が混在してることに気付いてる
だから継承がない言語でもそれぞれの役割ごとにプログラミングすることができる
一部のダメなプログラマーを除いて継承がない言語で困ることはない
コードの可読性や保守性が上がったことで継承廃止に納得賛成する
0882デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:29:15.44ID:EwZoXXsg
>>872
分かりませんので教えていただければ幸いです。
Rustにおける100%になるような顧客の集合(分母)とは何に当りますか。
0883デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:35:22.14ID:pc/ucEUa
>>881
新たなパラダイムを採用するにしても
継承を残しとけばC++ユーザの（Javaとかもかな?）取り込みが
もっと進んだのではないのかな?
本当に良いパラダイムであるのなら継承を残したままC++が呑み込むと思うよ
0884デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:46:33.32ID:rS/MFCk8
>>876
#[derive]は継承ではない
継承とは複数の役割を混在させた汚い概念
その説明については>>881を読んでほしい

#[derive]自体は手続き型マクロによる機能の付加
だから何を付加するかそのマクロ実装によって機能は変わる
トレイトを自動実装させるものもあれば
トレイトは出て来ず無関係にその対象にメソッドを生やすことも可能
マクロといってもRustコードの構文解析木を入出力とできるため高機能
0885デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:46:57.82ID:moHVYXda
継承といってすぐ思いつくのは、COMのIFoo2:IFoo みたいなときだけど、Rustでもできないわけじゃないでしょ
0886デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:47:22.90ID:0THLQfdG
>>873
説明できてるつもりなのがマジでヤバいな
トレードオフを理解出来ないやつは適性ないから早めに辞めたほうが本人のためにも世の中のためにも良い
0887デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:52:39.31ID:zNH+FeOM
crate hoge を使うとき
extern crate hoge; する人と
use hoge; する人がいるけど
どっちがどう違うん？
0888デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:58:37.73ID:moHVYXda
ちな、C++は継承全盛の時代にクソの山が築かれたので、その反省から、継承はナシでいくって発想はそんな違和感ない
現役のC++erは、そのクソの山をくぐってる(新参も過去資産を読まされるからね)から、継承するにしても注意深く設計する
だから、あんま反論する気はないからね
0889デフォルトの名無しさん
垢版 |
2023/05/02(火) 14:58:45.32ID:rS/MFCk8
>>883
継承はコードの可読性や保守性を下げるだけの存在なので不要
継承は複数の役割が混在した汚い存在
それぞれの役割を分離して実現できる方がまともなプログラマーとってうれしい

>>885
複数の役割が混在した継承という言葉や概念を用いるのはよくない
そのような汚い継承というものはRustに存在しない
もちろんそれぞれの役割の実現方法は別々の方法としてRustにある
0890デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:04:00.26ID:zNH+FeOM
>>856
C/C++もRustもどっちでも良いけど
Rustはアルゴリズムで悩むよりコンパイル通すことに悩む時間の方が長くなると感じる
まだ慣れてないだけかも知れないのは認めるが
アルゴリズムを実装したいのに集中力を削がれる
0891デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:10:31.30ID:zNH+FeOM
>>858 >>860
traitは便利だけどC#のpartialに似てる部分もあって
実装があっちのファイルこっちのファイルに分散してて
管理出来てないとどこに何があるのか判らなくなる傾向はあると思う
C/C++はヘッダーさえ追いかければどこに何が定義されているか見付け易いが
Rustは時々えっこんなのここで定義してあったんだみたいな発見があるし
気付かないで再発明してから後になってえっ既にあったの？ってなるときがある
0892デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:13:11.14ID:moHVYXda
>>889
伝わってねえ
継承時代のインタフェースってのがあるんだよ 特にWindowsにはね
MSが全面採用って言ったんだから、できないはずないんだって
0893デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:14:50.82ID:8SBmOXa9
>>890
それは単に慣れていないだけだよ
Lispを始めた時も最初は手続き型言語以外に慣れなくて似たような感じだった
Prologの時も宣言型言語の発想の転換に慣れるまでそんな感じだった
狭い範囲の言語しかやって来てないとその感じを初体験かもしれないね
いずれも最初のうち慣れるまでを乗り越える
0894デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:19:27.33ID:zNH+FeOM
>>881
>Rustと関係なく昔からOOPでは
継承(is-a)より合成(has-a)が望ましい
という話を聞いたことがない？
合成(has-a)の方が柔軟性が高いだけでなく
各機能ごとにコードを分けられるため
可読性も上がり保守性も良くなる
菱形多重継承の問題も避けられる
巨大な親クラスを用意する必要もなくなる

↑ここはNimもうまくやってると思うが
規模が大きくなると型推論とかmatchで時間かかりそう
0895デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:20:21.37ID:rS/MFCk8
>>892
申し訳ないがWindows特有の話には一切関心かない
そしてそれはプログラミング言語の話でもない
マイクロソフトがRustについても大量のドキュメントとライブラリ提供している
それらを見ればよいのではないか
0896デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:22:44.69ID:UlsqlHPi
>>887
extern crateはちょっと古い書き方（今でも用途ゼロではない）

rustコンパイラが外部のクレートを参照するためには
ソース内でextern crateを指定するかrustcに--externオプションで渡す必要があるんだけど
今はcargoがdependenciesの中身を全部渡してくれるからextern crateの出番は減ってる

今でも外側からのテストコードでdependenciesに含まれてない自分のクレートを参照する時は
extern crate [テスト対象のクレート名];
みたいに使われたりする
0898デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:35:19.29ID:pc/ucEUa
>>889
>継承(is-a)より合成(has-a)が望ましい
使う場所が違うんでないの?
composition（has-a）を使うべきところで
継承で設計するので破綻すのではないかな?

所有権システムの話と違って
継承は合成と両立できるのなら
排除する必要はなかったと思うんだよね
0899デフォルトの名無しさん
垢版 |
2023/05/02(火) 15:43:54.19ID:moHVYXda
>>895
「言語学者」だな
どうにも話がかみ合わない時があるのは、こういうとこなんだろうな。。

じゃあ、WindowsからはC++はなくせない、貴方はその点には異論も関心もないということでおｋ?
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況