C++相談室 part159

**デフォルトの名無しさん** · 2022/02/19(土) 11:56:42.14

前スレ
C++相談室 part158
https://mevius.5ch.net/test/read.cgi/tech/1636969758/

**デフォルトの名無しさん** · 2022/02/27(日) 14:51:04.74

>>282
ありがとうございます。
アップキャストダウンキャストも関わっていたのですね
すぐにはわかりませんでした。
たとえばなんですけど派生クラスBは基本クラスAに別の名前を付けてかつBで新たに
加えられたメンバはBから紐づけられていて、これらをセットにして見やすくしたものが
派生クラスBになると言う感じなのです？

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/27(日) 15:01:31.40

派生クラスのオブジェクトには基底クラスのオブジェクトが含まれる。
派生クラスの一部であるようなオブジェクト (基底やデータメンバ) をサブオブジェクトという。

**デフォルトの名無しさん** · 2022/02/27(日) 16:18:03.61

>>284
ありがとうございます。
サブオブジェクトがサブオブジェクトと言われることにつながるのですね。

**デフォルトの名無しさん** · 2022/02/27(日) 16:44:15.33

ダウンキャストは危険で、本来無条件にやっていいものではない
なので実行時型チェックをして使っている今回は問題ないだけ

なお、static_cast<ClassB*>(obj)->VirFunc()は最近のコンパイラ(gcc11.2)だと
最適化なし時はClassA*として仮想関数呼び出しと同じ方法で呼び出す
最適化あり時はvtableがClassB::VirtFunc()かどうか確認してインライン展開したものが実行される
(万一確認失敗したら仮想関数呼び出しと同じ方法で呼び出す)

**デフォルトの名無しさん** · 2022/02/27(日) 17:38:03.37

ダウンキャストをするならstatic_castではなくdynamic_castを使うべき。
見ているobjの実体がclassBじゃないなら失敗してnullptrを返してくれる。

そもそもダウンキャストが必要になること自体良い設計ではないが

auto* pb=dynamic_cast<classB*>(pobj);
if(pb){
pb->...;
}

**デフォルトの名無しさん** · 2022/02/27(日) 17:46:47.65

「キャストはなるべくするな、特にdynamicはコストが高い」と古文書にもあった

**デフォルトの名無しさん** · 2022/02/27(日) 17:54:22.89

今回はそれをtypeidでやりたかったんでしょ

**デフォルトの名無しさん** · 2022/02/27(日) 18:02:07.86

ダイナミックダイクマ

**デフォルトの名無しさん** · 2022/02/27(日) 20:42:58.79

なんかC++が気になるので実践的な情報でもなんでもありがたいです。
C++で食べてる人と話したこともないし・・・

**デフォルトの名無しさん** · 2022/02/27(日) 20:45:27.70

古文書には「#defineではなくconst,enum,inlineを使うといい」ってあるよ

**デフォルトの名無しさん** · 2022/02/27(日) 20:47:31.05

死海文書では「constexpr, enum struct, enum class」を使うことで難を逃れたと書いてある

**デフォルトの名無しさん** · 2022/02/27(日) 20:56:43.39

const使えば分かる。#defineのほうがやっぱり便利だわ。

**デフォルトの名無しさん** · 2022/02/27(日) 21:21:58.39

C++のenumは機能が弱いからなあ
Rustのenumみたいに任意の型の変数値を格納できるようにしてほしい

**デフォルトの名無しさん** · 2022/02/27(日) 21:31:32.92

>>275 >>276
その方針で全ての変数のデフォルトをC++のconst状態にしてしまったのがRustだね
代わりに値が変化する変数にだけミュータブル指定しないといけないけど
if-elseもループもブロックも値を返してくれるためほとんどの変数が変化しない

**デフォルトの名無しさん** · 2022/02/27(日) 21:36:52.29

char*やシンプルな構造体ならconst使うのはメリットあると思うが、
あれこれ機能が詰め込まれるクラスになると不便さ、面倒さのほうが際立つ。
多重継承並にハゲる原因になる。

**デフォルトの名無しさん** · 2022/02/27(日) 22:28:50.95

まーたしかにconst_castだらけになるかもしれないね

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/27(日) 23:37:06.31

const_cast を正しく使うのは難しい。
const なオブジェクトから const を剥がして書き換えるのは未定義。
数年前に LLVM が const 指定の情報を最適化に活用する方向に舵を切ったというニュースもあった。
const ではないオブジェクトに対して const なポインタや参照を経由している場合には
const を外して書き換えるのは許されるはずだが、
それが必要になるようだと設計を見直したほうがいい。

現在のコンパイラは賢くて、 const 指定をしてなくても書き換えられる可能性がないことを見抜いて最適化することも多いんで、
const の指定自体は最適化にはそれほど寄与しないよ。
ただ、 const を前提とした設計はコンパイラにとって最適化しやすい構造である可能性はある。

① const を前提にした設計にできるもんならしたほうがいい
② そうできないなら無理に const を付けないほうがいい (後で場当たり的に const_cast で const をはがすとどこかで間違う)

**デフォルトの名無しさん** · 2022/02/27(日) 23:43:44.46

書き換えないコードの場合はどういう最適化がされるのかを知りたいのだが。

**デフォルトの名無しさん** · 2022/02/27(日) 23:51:40.12

getterにlockを仕込む場合にgetterをconstにするべきかどうか悩む
const扱いにしてmutexに関してだけconstをはがすべきなのか

class C{
std::mutex _mtx;
int _a;
public:
int get_a(){
std::lock_guard lk(_mtx);
return _a;
}
void set_a(int a);
};

**デフォルトの名無しさん** · 2022/02/28(月) 00:43:20.93

>>301
俺ならgetterにはconst付けてmutexメンバ変数にはmutable付けるね。

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/28(月) 00:54:54.67

>>301
俺も >>302 には賛成。
mutex はあくまでも内部的な実装の都合であって、
それを mutable にしてもクラスの logical constness は維持されると判断する。

**デフォルトの名無しさん** · 2022/02/28(月) 01:18:45.25

>>300
だからお前は何を調べたとずっと聞いてるんだがｗ

**デフォルトの名無しさん** · 2022/02/28(月) 01:22:01.28

言い出した本人が逃げ出して答えないし、誰もはっきりと答えないんだからウソなんじゃね？

**デフォルトの名無しさん** · 2022/02/28(月) 01:25:22.84

状況に依るけどmutableにするなら俺はunique_ptrとかにするかもしれない

**デフォルトの名無しさん** · 2022/02/28(月) 01:42:21.31

>>305
言い出した本人はいるし、「お前は何を調べたとずっと聞いてる」のにしかも何度も聞いてるのに答えない＝お前が逃げ続けてるからだろ？ｗ

**デフォルトの名無しさん** · 2022/02/28(月) 01:47:08.01

本人いたのか。自分で言い出したはいいが実はさっぱり分からないって感じか。
それはそれで仕方ない。発狂してたら余計にやっぱりウソなんだ～ってなるだけだぞ。

**デフォルトの名無しさん** · 2022/02/28(月) 01:50:37.25

もう寝るけど、お前がただただ煽りながら発狂しちゃってる間も、毎日何某か書いてるんだがｗ
いつになったらお前がどこまで何を調べたのか詳細に説明してくれるのか心待ちにしてるよｗ

**デフォルトの名無しさん** · 2022/02/28(月) 01:50:44.99

>>302 >>303
ありがとうございます

なるほどフィールド側でconst扱いしないモードを初めから指定すればいいのか...

**デフォルトの名無しさん** · 2022/02/28(月) 01:54:51.97

>>309
やっぱりウソなのか。散々暴れといてしょうもない奴だな、おまえ。

**デフォルトの名無しさん** · 2022/02/28(月) 01:56:18.18

void f(const std::vector<int>&v){
for(size_t i=0; i!=v.size(); ++i)...
}

とかで
本来v.size()を毎回呼ばなきゃいけないけどconstだから1回呼ぶだけで十分って話とかじゃないの？

まあ俺も-O2コンパイル結果を読む気力はないからエアプ扱いしてもらって構わんが

**デフォルトの名無しさん** · 2022/02/28(月) 02:03:13.46

constなんていつでもconst_castで引っぺがせるんだから、勝手に定数畳み込みとかは出来ないし
じゃあそういうのが無いのを検知すれば出来るだろというと、そんなに賢いならconst無しの変数でも同じ事が出来るはず
結論から言うとconstは最適化に何の影響も及ぼさない
畳み込ませたい定数はconstじゃなくenumか#defineで定義するのが正解

**デフォルトの名無しさん** · 2022/02/28(月) 02:14:26.59

複数IDで暴れとるｗｗｗｗｗ朝までに具体的な事例を書いてねｗ
環境も明記されてないコンパイルも通ってないモノでは想像で言ってるだけってことになるよｗ

**デフォルトの名無しさん** · 2022/02/28(月) 06:31:25.23

>>312
この例は毎回v.size()呼んで遅くなりうる
それは最初に1回一時変数に受ければ解決するがそれがconstかどうかはまずパフォーマンスに影響しないだろう

もっというとこれは生のfor文の欠陥でこれからはstd::views::iotaを使っていくべき理由の1つだと思う

**デフォルトの名無しさん** · 2022/02/28(月) 06:47:54.89

>>315
その例はconstにしようがしなかろうがインライン展開されるので最適化結果に違いはないよ
そもそも最適化しやすくなると言ってるだけで、違いがあるとまでは言ってなかったんだけどｗ

>>314に書いたとおり、煽るだけ君は結局「想像で言ってるだけ」なんだなｗ
妄想はほどほどにしてくれｗ

最適化コードに違いがある例が以下。マクロの定義を空にすればconstなしのコードになる。
https://godbolt.org/z/YavYzrE3z
#define CONST const
template<typename T>
struct s {
T value;
operator T() CONST {return value;}
};
CONST s<int> a[] = {1,2,3,4,5};
template<typename T> T func() {
T r = 1;
for (int i = 0; i < sizeof(a)/sizeof(a[0]); ++i) {
r *= a[i];
}
return r;
}
int main() {
return func<double>();
}

**デフォルトの名無しさん** · 2022/02/28(月) 07:29:26.73

>>316
俺はこの話題に関して初めて書き込んだ者だが

**デフォルトの名無しさん** · 2022/02/28(月) 07:34:24.42

>>316
都合の良い例にしすぎだろ

**デフォルトの名無しさん** · 2022/02/28(月) 07:43:08.18

反証は1つで十分ｗ具体例の1つも書けない人は黙ってようねｗ

**デフォルトの名無しさん** · 2022/02/28(月) 08:14:09.88

ああすまん、変化しない例を出してるつもりだと思ってた
そんなコードでも変化したりするのね

**デフォルトの名無しさん** · 2022/02/28(月) 10:21:52.93

古文書には#defineは良くないってあったけど今のC++ってその辺り改善されたんですか？

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/28(月) 10:47:09.12

>>321
ある程度は。

**デフォルトの名無しさん** · 2022/02/28(月) 10:56:01.32

>>321
「その辺り」って何？
スコープとの相性が最悪って意味なら変わってないぞ

**デフォルトの名無しさん** · 2022/02/28(月) 11:04:38.67

>>323
他所からパクってきたコードですが、#defineはそのまま書き換えるだけだから以下や

#define SIX 1 + 5
#define NINE 8 + 1

int main(void)
{
printf( "What you get if you multiply six by nine: %d\n", SIX * NINE );
return 0;
}

以下の関数の呼び出しなどで意図しない挙動になったりとかです

#define SquareMulti(x, y) x * x * y
SquareMulti(++a, b)

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/28(月) 11:14:22.32

>>324
その程度なら inline や constexpr を活用するのが今は良い作法

**デフォルトの名無しさん** · 2022/02/28(月) 11:19:01.97

>>324
マクロに関してはそういう所は変わってない
餃子が言うようにマクロ以外の手段を使うというだけ

**デフォルトの名無しさん** · 2022/02/28(月) 11:20:49.97

>>321
#defineじゃないとできない/面倒なパターンが減ったという意味ならある程度はマシになってる

<numeric>とか<source_location>とかconstexpr/constevalとか

**デフォルトの名無しさん** · 2022/02/28(月) 11:24:50.52

>>321
#付いてるから、基本プリプロセッサ文だかんな

**デフォルトの名無しさん** · 2022/02/28(月) 11:39:25.77

スコープ付きの#defineが欲しい時ってあるよね…w

**デフォルトの名無しさん** · 2022/02/28(月) 12:09:06.26

ねーよｗ

**デフォルトの名無しさん** · 2022/02/28(月) 12:16:38.60

#define NAMESPACE namespase
#define NS ns

NAMESPACE NS{
void f();
}
void g(){
NS::f();
}

このへんのコードをプリプロセスの段階で正しく解釈するのは無理なのがね

#pragma defines(push)
みたいのが言語標準になればいけるか？

**デフォルトの名無しさん** · 2022/02/28(月) 12:32:49.89

馬鹿の妄想は放置して、マクロでないと困る例
#include <iostream>
#define PRINT_LOCATION() (::std::cout << __FILE__ ":" << __LINE__ << ":" << __PRETTY_FUNCTION__ << "\n")
namespace hoge {
void func() {
PRINT_LOCATION();
}
}
using namespace std;
using namespace hoge;
int main() {
PRINT_LOCATION();
func();
return 0;
}

**デフォルトの名無しさん** · 2022/02/28(月) 12:41:59.91

友達いなさそうだな

**デフォルトの名無しさん** · 2022/02/28(月) 12:49:02.69

そんなこと気になっちゃう程度の馬鹿よりは多そうだけど、多けりゃいいってもんでもないと思うぞｗ

**デフォルトの名無しさん** · 2022/02/28(月) 13:48:09.49

多くの回答ありがとうございます
やはり可能な限り#defineは避けた方が良さそうですね
ただ#defineでもできないことや、#defineにしかできないこともあるので変に毛嫌いせず勉強を進めてこうと思います

**デフォルトの名無しさん** · 2022/02/28(月) 14:03:01.00

例外中の例外なので、毛嫌いして全く問題なく、勉強する必要も全くないｗ

**デフォルトの名無しさん** · 2022/02/28(月) 15:55:04.33

Include Guard Macro以外の#defineは忘れてもいいと思う。

**デフォルトの名無しさん** · 2022/02/28(月) 17:13:33.60

ほんそれ
一生ソロプレイかつCにしがみつくつもりなら構わないけど
そうじゃないなら基本的に使わないべき遺物

**デフォルトの名無しさん** · 2022/02/28(月) 20:11:29.53

ほぼ同じ演算子オーバーロードを延々と書く場合とかマクロでまとめていいと思うけどね
テンプレートではどうしようもないレベルのメタプログラミングの手段として未だに有効

**デフォルトの名無しさん** · 2022/02/28(月) 20:17:53.65

むしろ、他言語にマクロ展開機能がないことが不満

**デフォルトの名無しさん** · 2022/02/28(月) 20:19:01.14

そうなる仕組みもどうかと思うけど、必要悪として採用するケースが「あってもいい」という程度だよ

**デフォルトの名無しさん** · 2022/02/28(月) 20:39:17.05

>>339
だよな

復号代入とかフルで揃えようとすると
毎回同じようなコードを延々書くからな

**デフォルトの名無しさん** · 2022/02/28(月) 21:11:31.61

だよなじゃねーよｗ
本当にマクロでないとできないケースなのかすら怪しいｗ

**デフォルトの名無しさん** · 2022/02/28(月) 21:21:08.91

>>339
テンプレートでできなくてマクロならできるとかそんなにはないだろ

>>340
C/C++ のマクロなんて PL/I から見たら子供騙しレベルだけどね

**デフォルトの名無しさん** · 2022/02/28(月) 23:32:29.49

>>340
C++に一番近い言語であるRustが多様な各種マクロを充実させているので乗り換えるのもよいかもね
マクロ以外にも非常に多くの問題が解決される

**デフォルトの名無しさん** · 2022/02/28(月) 23:58:07.07

ゴミのような文化を踏襲してしまった残念言語のRustさんのヘイトを上げるのはやめましょうｗ

**デフォルトの名無しさん** · 2022/03/01(火) 00:33:34.91

C++使ってるおれすげーみたいな

**デフォルトの名無しさん** · 2022/03/01(火) 01:06:15.88

C++を使いこなせないから皆下流行語の修得を目指す

**デフォルトの名無しさん** · 2022/03/01(火) 06:11:28.76

>>343
怪しいって明確に判断できねえのかよ
そもそも俺そんな話してねえし

**デフォルトの名無しさん** · 2022/03/01(火) 06:34:48.00

>>343
見てもないコードが明確に判断できたらこえーよ
そんな話じゃないって何いってんのｗ

**デフォルトの名無しさん** · 2022/03/01(火) 06:35:21.34

>>350
アンカー間違った。>>349な。

**デフォルトの名無しさん** · 2022/03/01(火) 07:02:46.96

>>350
おまえさん本当にC++使いか？
operator+とoperator+=みたいのの全組み合わせがマクロ使わずにできないとでも思うのか？

**はちみつ餃子** ◆8X2XSCHEME · 2022/03/01(火) 08:36:21.07

>>340
Cプリプロセッサを他言語で使ってもいいんですよ。

**デフォルトの名無しさん** · 2022/03/01(火) 09:06:42.29

>>340
マクロを持つ言語は多い
Rustのように用途に応じてマクロが何種類もあるケースもある

**デフォルトの名無しさん** · 2022/03/01(火) 10:19:23.90

struct B{...}*bP;
struct D1 : public B{...} d1;
struct D2 : public B{...} d2;
bP = (...)? &d1 : &d2;
これって駄目なんですね

**デフォルトの名無しさん** · 2022/03/01(火) 10:40:29.97

>>355
3項演算子の引数型が互換性のないD1*,D2*だからね

C#9あたりがターゲット型から3項演算子の型推測やってた気がするがC++に導入される日か来るんだろうか

**デフォルトの名無しさん** · 2022/03/01(火) 11:01:53.10

なるほど
素直にif文にしておきます

**デフォルトの名無しさん** · 2022/03/01(火) 11:08:34.73

つ static_cast<bP>(&d#)

**デフォルトの名無しさん** · 2022/03/01(火) 11:13:51.24

>>357
bP = (rnd() & 1)? (B*)&d1 : (B*)&d2;
ではあかんのか？

**デフォルトの名無しさん** · 2022/03/01(火) 11:14:23.15

rnd() & 1
は無視してくれｗ

**デフォルトの名無しさん** · 2022/03/01(火) 11:14:50.30

ああ、それでいいんですね
ありがとうございます

**デフォルトの名無しさん** · 2022/03/01(火) 11:54:42.57

今度はCに毒されていくC++スレｗ
プリプロセッサはincludeパス的に言語や標準ライブラリを結構意識したりしますｗ

**デフォルトの名無しさん** · 2022/03/01(火) 23:30:51.45

>>355
そういうのはRustがすっきり実現していていい感じ
静的モノモーフィングでコンパイル時に解決させる方法と
動的ディスパッチで実行時に解決させる方法の2種類を選びつつ簡単かつ安全に記述できる

**デフォルトの名無しさん** · 2022/03/02(水) 01:32:22.77

なんでこんなとこにrust信者が湧いてるん？

**デフォルトの名無しさん** · 2022/03/02(水) 03:41:00.25

C++のstatic_castで十分すっきりしてるし安全なんだがｗ

**デフォルトの名無しさん** · 2022/03/02(水) 03:51:26.38

うむ
まあRustはトレイトを導入しているためもっとフレキシブルに機能毎に事実上のキャストができる点で先に進んでる感じ

**デフォルトの名無しさん** · 2022/03/02(水) 04:16:03.37

std::visitで十分じゃないの？

**デフォルトの名無しさん** · 2022/03/02(水) 06:05:07.28

>>364
メンタルはルビ基地と同じだから相手すんな

**デフォルトの名無しさん** · 2022/03/02(水) 08:02:10.51

>>364
スレ違い野郎はNG推奨

**デフォルトの名無しさん** · 2022/03/02(水) 10:15:53.71

RustはUnityで作られてるんだからC#スレ行けよ

**デフォルトの名無しさん** · 2022/03/03(木) 11:52:56.52

有名なライブラリのコード覗いて見るとC++でもマクロ結構使ってるよね

**デフォルトの名無しさん** · 2022/03/03(木) 12:21:01.59

まあそこは女性のウェストが50cmだと思ってるスペック厨のオタクと現実に生きて実用的なものを開発してる人の違いだね

**デフォルトの名無しさん** · 2022/03/03(木) 12:24:43.91

有名ライブラリこそマクロに頼らないとやってられんとこあるからな

コンパイル環境(gcc/clang/MSVC)のスイッチとか
C++バージョンのスイッチとか(#define CONSTEVAL20 consteval/constexpr)

ボイラープレートの簡略化はどれぐらいやってるかは知らんが

**デフォルトの名無しさん** · 2022/03/03(木) 15:14:53.11

条件コンパイルには#ifdefがいるね

**デフォルトの名無しさん** · 2022/03/03(木) 16:48:19.79

文法ばかり勉強してコード書かないからマクロの必要性が見えないんだよ。

**デフォルトの名無しさん** · 2022/03/03(木) 18:39:02.62

ああ、マクロ不要論者は自分でライブラリ書いたことないというオチか
腑に落ちたわ

**デフォルトの名無しさん** · 2022/03/03(木) 19:24:38.63

まともにコード書く量も質も足りない人にはマクロの弊害を認識できてないんだろうなｗ
インクルードガードなどの条件コンパイルはプリプロセスではあるものの、一般的なマクロ置換処理ではないｗ

**デフォルトの名無しさん** · 2022/03/03(木) 19:49:49.09

本気でいってんの？このバカ

**デフォルトの名無しさん** · 2022/03/03(木) 20:05:07.59

単発IDで中身のない煽りだけの人が早速出現ｗ
臆病すぎｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/04(金) 05:56:44.52

> マクロ不要論者

誰？　いたっけ、そんなやつ

**デフォルトの名無しさん** · 2022/03/04(金) 06:37:36.91

>>380
>>336あたりじゃね？

**デフォルトの名無しさん** · 2022/03/04(金) 06:43:28.40

ああ、あのキチか
相手すると馬鹿が伝染るからやめようぜ