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

**デフォルトの名無しさん** · 2023/02/25(土) 09:49:46.74

C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな？

**デフォルトの名無しさん** · 2023/03/27(月) 17:02:39.76

酷いのはお前の頭と顔だよ

**デフォルトの名無しさん** · 2023/03/27(月) 17:10:12.43

>>606
記事はバカだけどコメントはまあいいんじゃね？
それよりも、Rustを置き換えられる言語が出現しないと、Rustの天下が続きそ。
C並みに高速で何でも書けてGCもなく、にも関わらず様々な安全性が静的に保証される言語が、Rust以外に芽も出てこなさげ。

**デフォルトの名無しさん** · 2023/03/27(月) 17:19:21.38

>>605
MSだから

**デフォルトの名無しさん** · 2023/03/27(月) 17:23:03.66

何が続きそ。だよ
自演バレないように新文体開拓しようとしてんのマジでキモいわ

**デフォルトの名無しさん** · 2023/03/27(月) 17:26:14.23

コメントしたった

TypeScriptはC#やDelphiを作ったアンダースヘルスバーグが設計してるからです
以上

**デフォルトの名無しさん** · 2023/03/27(月) 17:26:50.78

Rustまだ全然天下じゃないんだが…
周り見えてない人なのかな？

**デフォルトの名無しさん** · 2023/03/27(月) 17:27:28.03

言うほどガベコレ悪いか？って話になるんだが君たち何を作ってんだ？

**デフォルトの名無しさん** · 2023/03/27(月) 17:28:15.22

言うほど1フレーム1フレームの処理落ちが問題になることしてんの？
ゲームくらいじゃね？

**デフォルトの名無しさん** · 2023/03/27(月) 17:28:57.15

その点ゲームでRustは使われない
マジで何してんの？って話よな

**デフォルトの名無しさん** · 2023/03/27(月) 17:35:59.10

>>614
車載ソフト関係だけど、命に関わるようなシステムは最大実行時間を理論的に算出出来ないとアカんのや
GCだとそれが出来ないから論外なんや、、

**デフォルトの名無しさん** · 2023/03/27(月) 17:37:53.83

>>616
ほんでその車載ソフトはRustで書かれんのか？

**デフォルトの名無しさん** · 2023/03/27(月) 17:39:01.06

>>617
いや、まだ言語的に対応してないからC/C++だね、、

**デフォルトの名無しさん** · 2023/03/27(月) 17:40:35.92

>>618
やっぱりね
いつになるんだろうねRustが対応するの
一生来ないかもしれん

**デフォルトの名無しさん** · 2023/03/27(月) 17:52:34.31

>>619
そうやね
ぶっちゃけ危なそうなものはコーディングルールで縛られるし、過去トラブルや不具合対策も沢山あるから困らないんだよね。
品質保証のためにアセンブラも見るけど、C/C++はアセンブラと比べながら見やすいし

**デフォルトの名無しさん** · 2023/03/27(月) 18:00:15.28

>>616
そこでリアルタイムGCですよ

**デフォルトの名無しさん** · 2023/03/27(月) 18:06:46.35

噂によると節電のためにRustを使うらしいな
電気代よりも例えば家賃の方がよっぽど高い人生だったら一生使わないのでは

**デフォルトの名無しさん** · 2023/03/27(月) 18:13:00.08

このままC++は消えていくだろう
アドバンテージが何も残っていない

**デフォルトの名無しさん** · 2023/03/27(月) 18:17:46.08

上の方で
「Rustのライブラリはあらかた揃って退屈なメンテ作業しか残ってない状態、そんなつまらない作業誰もしないから誰もメンテしなくなってだんだん人が離れていく一歩手前」みたいなQiiitaの記事あったけど、そんなライブラリ充実し始めてる？

**デフォルトの名無しさん** · 2023/03/27(月) 18:18:17.10

>>624
いやしてないよ

**デフォルトの名無しさん** · 2023/03/27(月) 18:27:56.70

新規プロジェクトは大方Rustになったが
既存プロジェクトは大規模な更新でしか切り替わらないだろな

**デフォルトの名無しさん** · 2023/03/27(月) 18:43:27.53

どっちかって言うと今Pythonとかでちゃんと動いてる、例えばAI用のテンソル計算処理、統計処理のライブラリをRuby用のために用意し直すのっていわゆる「車輪の再発明」みたいになってしまうからわざわざRustに移植するのってどうなん的な感じで充実してこないんじゃないかという気はする
ライブラリが充実してきてみんなが使い出すかどうかって技術的な問題だけじゃなくてその言語が出てきたタイミングとか社会情勢とか背景とかそういう要素もかなり濃密に効いてて、その意味でPythonはすげぇタイミングよかったという気はする

**デフォルトの名無しさん** · 2023/03/27(月) 19:22:16.60

Rustで仕事してないやつらばかりだの
儲かるから流行るんだぞ

**デフォルトの名無しさん** · 2023/03/27(月) 19:23:51.08

既存のものを移植するのは無駄な行為
既存のものはそのまま使えば良くそのまま使われている
新たなものはRustになっている
それだけの話

**デフォルトの名無しさん** · 2023/03/27(月) 19:25:47.39

Rustの仕事あるかい？

**デフォルトの名無しさん** · 2023/03/27(月) 19:33:28.90

>>627
rustもキラープロダクトが出れば一気に普及する

**デフォルトの名無しさん** · 2023/03/27(月) 19:43:52.09

>>622
節電というか、こちらはクラウド利用だけど間接的には当たりじゃね？
GC言語からRustへだけど、CPUコストとメモリコストが激減、だからクラウド側では節電となり、Rustはエコ。
GCなく自動メモリ解放する言語Rustの出現が今までの流れを変えた。

**デフォルトの名無しさん** · 2023/03/27(月) 20:10:16.56

Rustへの動きは2系統あるよな
C/C++からRustへの安全性を高める動き
GC言語からRustへの高速化＆省メモリ化の動き
まれに片方の動きの意識しかない人が想像力の欠如した書き込みをしている

**デフォルトの名無しさん** · 2023/03/27(月) 20:59:51.90

目的は1つだけ・手段はいくらでもあるという世界観はしつこく宣伝されてきた
逆に1つの道具で色々できるという話はあまり聞かない

**デフォルトの名無しさん** · 2023/03/27(月) 21:16:18.71

Rust製のTurbopackでjsのバンドルが数百倍高速になってもじゃあ俺もRust使おうとはならんのよ
AWSのバックエンドでRust使ってエネルギー効率が向上してもじゃあ俺もRust使おうとはならんのよ

理性的に考えろ

**デフォルトの名無しさん** · 2023/03/27(月) 21:18:03.30

オジの自演は特徴出すぎで草
こちらはクラウド利用www

**デフォルトの名無しさん** · 2023/03/27(月) 21:25:42.06

Windows3.1からMacOSにも流れなかったし
Cのニッチェを奪わなければRustはこの先生
きのこれない

**デフォルトの名無しさん** · 2023/03/27(月) 21:59:50.76

アンチは願望ばっかだな
エンジニアの上澄が認めたのだから争っても無駄

**デフォルトの名無しさん** · 2023/03/27(月) 22:10:09.18

>>638
儲かってる人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
Rustで何開発してるの?

**デフォルトの名無しさん** · 2023/03/27(月) 23:10:41.22

>>608
Rustの提唱するパラダイムがうまくいきだしたら、他言語もこぞって取り込むと思う
アカンとなったら、次のパラダイムが提唱…されるのは先の話だろうなあ俺生きてるかなまじで

**デフォルトの名無しさん** · 2023/03/27(月) 23:13:47.59

js、ptyhon、やってきて
rustは新鮮で学べてるけど
c++はやばくね、、、
依存やらのコンパイルの時点で挫折しそうなんだが
ドキュメントもわけわからんし

**デフォルトの名無しさん** · 2023/03/27(月) 23:20:50.21

>>640
所有権って途中から取り込めるの?
パターンマッチングとかは余裕だろうけど

**デフォルトの名無しさん** · 2023/03/27(月) 23:43:11.84

余裕だろ
ただ他言語もこぞってと言ってもGC言語は対象外なのでメジャーな言語で可能性があるのはC++のみ

**デフォルトの名無しさん** · 2023/03/27(月) 23:51:52.30

>>643
デフォルトでコピーコンストラクタやコピー代入演算子が起動するところを
moveコンストラクタやmove代入演算子が起動するように変更するってことでしょ?
余裕な訳ないじゃん
copy by valueな言語では後方互換性が犠牲になるので導入無理だよ

**デフォルトの名無しさん** · 2023/03/28(火) 00:23:27.41

>>644
いろんなやり方があるけど実装ができないようなものはない
やろうとすればどのやり方にするのがいいか
細かい仕様をどうするのがいいか
そういう意思決定に時間がかかるだけ

所有権システムをあとから取り込めないなんて発想をする人がRustを宣伝してるのがむしろ驚き

**デフォルトの名無しさん** · 2023/03/28(火) 00:42:21.55

>>645
文章読めないのかな?
今まででのコードでインスタンスがコピーされるところを
勝手にmoveにすり替えられたら大惨事だろw
今まで書いたコードを全部書き換えることになる
つまり後方互換性が犠牲になる
C++の開発当初からの方針で最大の特徴はCを内包していること
CもC++もcopy-by-valueな言語

**デフォルトの名無しさん** · 2023/03/28(火) 00:54:04.89

視野の狭い人だな

**デフォルトの名無しさん** · 2023/03/28(火) 01:08:09.67

>>647
問題についてどう解決するかを書きな?

**デフォルトの名無しさん** · 2023/03/28(火) 01:35:54.97

既にCとC++に互換性はない
しかし許された
また同じことをやってまた許されることは可能かもな

**デフォルトの名無しさん** · 2023/03/28(火) 01:46:32.83

まあ拡張子変えれば許されるよcpoとか
あとはsafeブロックとか？

**デフォルトの名無しさん** · 2023/03/28(火) 02:00:41.86

>>649
ほぼ互換性あるだろ? どういったケースのこと書いてるの?

**デフォルトの名無しさん** · 2023/03/28(火) 02:21:00.53

>>626
新規プロジェクトって例えばどれよ？

**デフォルトの名無しさん** · 2023/03/28(火) 02:21:41.39

>>628
なんの仕事してんの？

**デフォルトの名無しさん** · 2023/03/28(火) 02:22:00.97

>>644
>デフォルトでコピーコンストラクタやコピー代入演算子が起動するところを
>moveコンストラクタやmove代入演算子が起動するように変更するってことでしょ?
アフォ発見！

**デフォルトの名無しさん** · 2023/03/28(火) 02:24:01.41

>>641
オブジェクト指向できてないからだろそれ
C#学べ

**デフォルトの名無しさん** · 2023/03/28(火) 02:25:39.63

>>642
パターンマッチング導入はC++23でも無理
出てる案では便利になりそうにない
こればっかりは結果論になってしまうがRustと比較するとこれまでの基本設計が失敗してる

**デフォルトの名無しさん** · 2023/03/28(火) 02:31:45.17

>>644
現状のスマポとmoveを用いたC++の所有権システムはRustのシンプルな記述と比べると面倒で忘れたりミスしたりしてしまうがあれが限界っぽい
後方互換性を保ったままC++を快適にするのは不可能

**デフォルトの名無しさん** · 2023/03/28(火) 02:43:54.99

>>655
そいつが書いている3つの言語ともにオブジェクト指向なのでC#は不要だろう
Pythonは普通
JavaScriptはプロトタイプ方式の継承だがそれ以外は普通
Rustは継承を排除していて機能(メソッド群)毎にトレイトで合成するがそれ以外は普通

**デフォルトの名無しさん** · 2023/03/28(火) 03:31:25.51

>>658
Pythonやってるやつはオブジェクト指向理解できてないやつ多いよ
JavaScriptはまぁ基本使わんし
Rustはオブジェクト指向的なことできるようにしてるけどオブジェクト指向わからんやつ向けに制限かけてるって印象

**デフォルトの名無しさん** · 2023/03/28(火) 05:56:18.37

複雑になりすぎないようにするのは、それはそれでメリットでもある
C++では、やたらとややこしいクラスが上がってくる
それ〇〇使いたいだけちゃうん、みたいな

Rustが普及したら、Rust流のスマポにみんな慣れるから、自分の母語でも使うようになるよ

**デフォルトの名無しさん** · 2023/03/28(火) 06:40:30.67

>>659
その3つの言語をやってることから例えばウェブ方面だとしても
PythonでDjangoなどのフレームワークを使うにはオブジェクト指向は基本知識として不可欠
JavaScriptもReactなどののフレームワークを使うにはオブジェクト指向は基本知識として不可欠
Rustに対してはデタラメな印象だけで基礎的な理解すらなし
このスレで連投してる人の中で最もレベル低すぎ

**デフォルトの名無しさん** · 2023/03/28(火) 06:47:56.40

C++のOOPって、CRTPとかがすっと書ける、読めるレベルだからねえ
そんな難しくないけど、美しく書くには多少の経験は必要

あと、吐かれるコードにはもうちょい気を留めてほしいなと、マシン語寄りの俺は思っちゃうな
「そういう」用途ばっかりじゃないのはわかるんだけど

**デフォルトの名無しさん** · 2023/03/28(火) 07:05:58.21

そういや気にしてなかったけど
webも、APIがOOP式で提供されてるから、OOP無関係とは言えないけど、
自分でどんどんクラスを編み出して問題解決するC++とは、OOPに向かう姿勢は異なってくるね

クラスは簡潔なほうが、結局効率もいいんだけどねｗ

**デフォルトの名無しさん** · 2023/03/28(火) 07:15:22.07

>>663
それはPythonでもJavaScriptでも同じ
Web APIと関係なくプログラム独自の部分も自分でどんどんクラスを編み出して問題解決する
他を知らないためC++だけを何か特別だと思い込んでそうだな

**デフォルトの名無しさん** · 2023/03/28(火) 07:20:37.19

>>659 をちょっとだけ擁護してみたくなっただけだよｗ
どこだって、ライブラリ作成者はOOPに精通してるもんだが、
C++は、OOPに精通してないと、使ってますとか公言できないもんね
むっちゃ煽られるよｗその違いはあるなって思った

**デフォルトの名無しさん** · 2023/03/28(火) 07:41:04.68

OOPは精通するしないとか難しいものではないだろ
初心者かね

**デフォルトの名無しさん** · 2023/03/28(火) 07:49:36.20

C++でOOPができるといったら、当然のようにSTLが使え、boostが使える
あるいは、traitsやattribute,constexpr を織り交ぜて、ほぼゼロサンクなバイナリを叩き出せるレベル
俺は初心者だからそのレベルにはないな

ちょっとよそよりは要求レベルは高いだろって思ってる
母語のことはちょっとだけ誇りに思ってるけど、それより、一長一短的立場

**デフォルトの名無しさん** · 2023/03/28(火) 08:58:26.51

上のほうでだれかいってたけど、まともなC++erは、スマポくらい使えて当然
なんだけど…ソース単位で生ポ禁止ってのが普及しないんだよね

**デフォルトの名無しさん** · 2023/03/28(火) 09:04:22.01

newを書かなきゃ良いだけなのにね

**デフォルトの名無しさん** · 2023/03/28(火) 09:37:27.95

>>661
嫌だからわかってないんだってばこいつはさ
だからC++の依存関係で頭パンクすんだよ

**デフォルトの名無しさん** · 2023/03/28(火) 09:39:21.00

とりあえず
>>641
こいつがオブジェクト指向理解してないのは確かだろ

**デフォルトの名無しさん** · 2023/03/28(火) 09:56:21.67

>>661
君がオブジェクト指向理解できてなさそう

**デフォルトの名無しさん** · 2023/03/28(火) 10:06:33.49

>>669
C++もなんでもスタックに置きたいんだけど、きつきつなのが本来なんだよね
どんどんスタックを食うのは野暮っていう流儀もある

Rust流はメモリ使用の局所化を促進するから、
メモリキャッシュまで考慮すると、悔しいけどC++より効率出る余地がある
まあ実測してみないと、知らんけどｗ

**デフォルトの名無しさん** · 2023/03/28(火) 10:06:36.56

>どんどんクラスを編み出して問題解決する
奴はクラスを書けたらオブジェクト指向を理解してると思ってるみたいだからな

**デフォルトの名無しさん** · 2023/03/28(火) 10:09:59.68

>>674
確かになw
普通逆で一番抽象化できるところで遡ってツリー形式にやっていくもんだもんな

**デフォルトの名無しさん** · 2023/03/28(火) 10:28:38.80

>>673
「newを書かなきゃ」ってのは
make_uniqueとmake_sharedを使えって意味でした

**デフォルトの名無しさん** · 2023/03/28(火) 10:51:13.90

JavaScriptとPythonは
極力オブジェクト指向的な書き方をしないほうが
メンテナンス性も可読性も高まる言語だから
C++やC#とは事情が違うわな

**デフォルトの名無しさん** · 2023/03/28(火) 17:06:18.21

>>662
CRTPはC++のOOPで最も効率よい実装となり必須なテクニックであるが
美しいというのはウソでむしろC++の汚さの象徴の一つになっている

初心者や他言語の人たちもいるようだからわかりやすいコード
例として各派生のadd1()を用いて共通のadd2()やadd3()などを用意する場合

template<typename T>
struct AddN {
void add2() {
static_cast<T*>(this)->add1();
static_cast<T*>(this)->add1();
}
void add3 ...略
};

struct Foo : AddN<Foo> {
int x;
Foo(int i) : x(i) {}
void add1() {
this->x++;
}
};

以上となり慣れてしまうと感覚が麻痺してしまうが
CRTP (Curiously Recurring Template Pattern)の名の通り
「Foo : AddN<Foo>」といちいち自分をパタメータとして与えなければならない
「static_cast<T*>(this)」といちいちダウンキャストをしなければならない
このように「美しくない無駄なコード」になっている
つづく

**デフォルトの名無しさん** · 2023/03/28(火) 17:07:43.55

>>678のつづき
一方でRustではトレイトを用いて以下のコードとなる
C++での「美しくない無駄なコード」部分を消し去った状況とほぼ一致している

trait AddN {
fn add1(&mut self);
fn add2(&mut self) {
self.add1();
self.add1();
}
fn add3 ...略
}

struct Foo(i32);
impl AddN for Foo {
fn add1(&mut self) {
self.0 += 1;
}
}

逆にRustのこのコードと同じことを同じようにゼロコストで実現するには
C++ではCRTPを「美しくない無駄なコード」とはいえ使わざるをえない

**デフォルトの名無しさん** · 2023/03/28(火) 17:58:49.48

>>678-679
早まるな、俺は【CRTPが】美しいとは言ってない
初めて見たときは、なんじゃこりゃすげぇとは思ったけどねｗ

**デフォルトの名無しさん** · 2023/03/28(火) 20:04:32.17

>>679
CRTPを使わないで仮想関数にすると実行時のvtable経由のオーバーヘッドがあるんだよな
Rustは何も指定しなくてもCRTPと同じ状況になるから記述はシンプルで実行時オーバーヘッドもなく速いわけか

**デフォルトの名無しさん** · 2023/03/28(火) 20:17:15.74

そういえば初心者向けのサイト無いな
アイペンテックとか？

**デフォルトの名無しさん** · 2023/03/28(火) 20:32:01.59

C++のオブジェクト指向は動的ポリモーフィズムだから遅い
関数呼び出しのvtableオーバーヘッドがあるだけでなくインライン展開ができず最適化の機会も失われている
Rustは基本が静的ポリモーフィズムだからそれらのコストがなく速い

**デフォルトの名無しさん** · 2023/03/28(火) 20:33:07.14

CRTP使うと全部インライン展開されるのマジで不思議だよな

**デフォルトの名無しさん** · 2023/03/28(火) 21:00:58.63

>>684
適当なことを言うと規格票で殴り殺される
それがC++村の掟
悪いことは言わない
君はここから早く撤退したほうがいい

**デフォルトの名無しさん** · 2023/03/28(火) 21:30:24.26

>>627
Rubyの話はもういいよ

**デフォルトの名無しさん** · 2023/03/28(火) 21:35:05.32

>>684
CRTPを使えば常にインライン展開されるわけではない
CRTPを使った時のみ(vtable経由にならず静的に動作が確定するため)インライン展開が可能となり最適化の可能性も広がり速くなるという話
C++ではCRTPを使わないとRustと同等の速さになれない

**デフォルトの名無しさん** · 2023/03/28(火) 22:58:28.07

vtableが重く感じるとかどんな環境やねん。どうせエアプやろ。

**デフォルトの名無しさん** · 2023/03/28(火) 23:08:36.42

呼び出し回数多いと馬鹿にならんよ

**デフォルトの名無しさん** · 2023/03/29(水) 00:01:28.04

vtableが重いというよりインライン展開＋αの最適化が効かなくなるのが問題なんでしょ
使ってる関数が常に固定値（nullとか）を返すって事前に分かればそれによって分岐の整理ができたりするけど
間にvtableが挟まるとそういう予測が難しくなる

**デフォルトの名無しさん** · 2023/03/29(水) 00:09:55.54

>>687
CRTPを使わないと真に実現できないのはメソッド記法だけ

そしてvtableとインライン展開に君が想像するような関係性は無い
というか、同じ推論をRustで適用すれば「object-safeなtraitへのimplはvtableを量産しインライン展開を阻害するので悪、やめろ」ということにならないかい？

自分が何を書こうとしているのかよく考えてから書き込むことだ

**デフォルトの名無しさん** · 2023/03/29(水) 00:26:00.18

C++もRustも、OOPなアセンブラの用途があるからね
少々vtableを経ても平気だとしても、そういうバイナリ吐いてほしくないときはある
バイナリは覗かれるもの

**デフォルトの名無しさん** · 2023/03/29(水) 02:17:33.72

こういうしょーもない連中に限ってvtableによって速度が何%落ちるかなんて測ったこともないんだよ。
馬鹿馬鹿しい。

**デフォルトの名無しさん** · 2023/03/29(水) 03:03:32.31

>>688
vtableの参照による速度低下よりも最適化できないことによる関数呼び出しのコストが重い
例えば>>679のRust及びCRTPで書かれたC++コードはどちらもadd2()関数呼び出しの中身は最適化されて単なる「add 2」となる
しかしCRTPを用いずにC++で書くとadd2()関数呼び出しの中身は「vtable参照」＋「add1()関数呼び出し」＋「add 1」を2回することになる

**デフォルトの名無しさん** · 2023/03/29(水) 08:27:05.33

>>693
パフォーマンスを測るまでもなく、吐かれるバイナリの汚さ
書いた一言一句が何になるか、気になって仕方ないのがC++erだよ(諸派あり、用途にもよる
バイナリエディタに放り込んだらわかるまである

**デフォルトの名無しさん** · 2023/03/29(水) 08:41:42.91

>>694
おっ、そうだな
https://godbolt.org/z/M71z9cx74

**デフォルトの名無しさん** · 2023/03/29(水) 09:39:43.93

この英語版wikipediaのC++サンプルコードとコンパイル結果が詳しい
https://en.wikipedia.org/wiki/Virtual_method_table#Example
CRTPを使わないとvirtual method tableが出てきて不利になる

**デフォルトの名無しさん** · 2023/03/29(水) 10:58:30.49

CRTPが嫌ならテンプレート分ければいいだけでは？

**デフォルトの名無しさん** · 2023/03/29(水) 11:49:15.76

>>678
これってダウンキャスト入ってるから危険なこともできそう
相当するコードはRustではコンパイル通らない?
#include <iostream>
#define DOUT(arg) std::cout << #arg": " << arg << std::endl
template<typename T> struct AddN {
void add2() {
static_cast<T*>(this)->add1();
static_cast<T*>(this)->add1();
}
};
struct Foo : AddN<Foo> {
int x;
Foo(int i) : x(i) {}
void add1() {
this->x++;
}
};
struct Bar : AddN<Foo> {
double y;
Bar(double i) : y(i) {}
void add1() {
this->y+=0.1;
}
};
int main () {
Foo foo (1); Bar bar (0.1);
DOUT (foo.x); DOUT (bar.y);
foo.add1 (); bar.add1 ();
DOUT (foo.x); DOUT (bar.y);
return 0;
}

**デフォルトの名無しさん** · 2023/03/29(水) 11:51:44.76

実行したら以下のようになった
$ ./a.out
foo.x: 1
bar.y: 0.1
foo.x: 2
bar.y: 0.2
最後のbar.yは1.1になると思ってたんだがはて?

**デフォルトの名無しさん** · 2023/03/29(水) 12:42:03.29

そもそもBarはFooを継承してないんだから
ダウンキャストのところでコンパイルエラー出て良いようなもんだけど
何で通すんだろ? templateだとチェックを緩和してるのかな?
あるいはコンパイラのバグかな?
$ g++ --version
g++ (Debian 10.2.1-6) 10.2.1 20210110

**デフォルトの名無しさん** · 2023/03/29(水) 12:43:14.11

-ダウンキャストのところでコンパイルエラー出て良いようなもんだけど
+static_cast<T*>(this)->add1();のところでコンパイルエラー出て良いようなもんだけど

**デフォルトの名無しさん** · 2023/03/29(水) 12:55:36.31

最近のC++はよく分からんけどその例だとadd2使わないと多分変なことにならない
doubleをint扱いして1足しても1/(2^53)（←不正確、指数部による）くらいしか変動しないのかな
FooもBarもAddN継承してるからstatic_castでコンパイルエラーは出ないはず

Rustはクラス継承がないからstatic_castとの正確な比較はできない
traitで似たようなコード書くときはSelfキーワードで自分の型を指すからダウンキャスト必要ないし
敢えてstatic_castと対応させるならtransmuteだろうけどunsafe付きの関数だから危険でもコンパイルは通せる
（unsafeを使う範囲の安全性保証はプログラマの責任）

**デフォルトの名無しさん** · 2023/03/29(水) 13:10:19.46

>>703
>最近のC++はよく分からんけどその例だとadd2使わないと多分変なことにならない
あーごめんごめん！興味があったのはadd2を呼んだときの挙動だった
- foo.add1 (); bar.add1 ();
+ foo.add2 (); bar.add2 ();
$ ./test
foo.x: 1
bar.y: 0.1
foo.x: 3
bar.y: 0.1 <- 鼻から悪魔

>FooもBarもAddN継承してるからstatic_castでコンパイルエラーは出ないはず
なるほどキャストしているthisはAddN<Foo>*だから
Foo*にもBar*にもダウンキャストできるってことね
ありがとう

**デフォルトの名無しさん** · 2023/03/29(水) 13:47:10.36

正当?なC++的にはdynamic_castすべきなんじゃなかろうかって思うんだよね
でそれはvtable介してadd1にアクセスするのと変わらない
プログラマの責任でstatic_castして効率化する
ってテクニックは俺は割と好きだけども

**デフォルトの名無しさん** · 2023/03/29(水) 14:18:14.91

>>703
transmuteはダウンキャストではなく任意の型同士の強引な型変換(読み替え)だから当然unsafe
一方でダウンキャストは親から子、基底から派生、抽象から具体への変換を指す
Rustの場合は抽象的なトレイトから具体的な型への変換がダウンキャストとなる

Rustは基本的には静的ポリモーフィズムで
コンパイル時点で各具体的な型のコードへ安全に置き換わるモノモーフィズムなので
C++のstatic_castのような危険のあるダウンキャストを必要としないが正解

Rustでもdyn Traitを用いた場合のみ動的ポリモーフィズムとなり
C++のdynamic_castと同様に実行時ダウンキャストがdowncast()/downcast_ref()/downcast_mut()で可能だが
C++とは異なりRustはNull安全でダウンキャストできる