C++相談室 part163

2022/12/30(金) 23:16:31.37

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

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

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/01/23(月) 09:40:42.62

>>211
あなたがウソである証拠を示せばいいだけ。他者に証拠を求めてはいけない。

2023/01/23(月) 10:00:24.86

polymorphic_allocatorなんでコピーでresource伝播してくれないんだ・・・

2023/01/23(月) 13:17:00.05

>>211
C が始まったとき (1972 年) に C++ は無い。
C++ の前身である C with Classes の歴史の始まりは 1979 年で、そのときは
C のプリプロセッサとして書かれていたしあくまでも C の拡張と見なされていた。

後に C は C++ からかなり多くを取り入れることになるし
現在進行形で取り入れてもいるが、それを「派生」とは普通は呼ばない。

普通は呼ばないがそこらへんは言葉の定義の問題なので「派生」という言葉の
定義によっては無理すれば派生と呼べなくもないかもね。

2023/01/23(月) 14:21:27.16

>>209
>>210
CFrontなんてあったのですか
ヒントをありがとうございますた

2023/01/26(木) 06:18:10.77

名前付き引数標準化への動向って今どうなん
標準化はしないから各自勝手にやってねって感じ？

2023/01/26(木) 07:48:33.46

class A{
public:
　void operator () () {...}
};

class B : public A{
　void func(){
　　ここでオペレータ()を呼びたいとき、(*this)()としたら呼べますが、this→()では呼べませんでした。
　　なぜでしょうか？
　}
};

2023/01/26(木) 08:02:56.89

>>217
オペレータが左右にとるのは引数でthis->だけだと型が違うから？

2023/01/26(木) 08:03:37.78

>>217
メソッド名でないから。

確認していないけど this->operator()() かと。

2023/01/26(木) 09:02:29.12

メソッド

2023/01/26(木) 11:28:53.15

× メソッド
〇メンバ関数

2023/01/26(木) 11:34:13.17

さてはDelphiやってたな

2023/01/26(木) 12:10:18.58

>>219様のやり方でできました皆様ありがとうございます

2023/01/26(木) 12:11:12.58

すみませんもう一個質問させてください。

template<class T> class A{
public:
　void f(){…}
};

template<class T> class B : public A<T>{
public:
　void g(){f();}
};

というコードがあったとき、g 内の f が undeclared identifier だというエラーが出ますよね？
T が不明だからそうなるのだと説明されてるのを見たのですが、T はコンパイル時には確定してるのになぜダメなのでしょうか。

2023/01/26(木) 12:18:25.89

template<>class A<void>{};
のようにf()のない特殊化をされる
可能性があるってことさ

2023/01/26(木) 12:30:19.94

>>224
void g(){A<T>::f();}
かね。理由は知らん。

2023/01/26(木) 13:28:25.80

SFINAEに使う技

2023/01/26(木) 14:00:57.20

>>226
*this→fとするにしてもA<T>::f()とするにしても長いなあと思ってしまいます
しかたがないので、Bはテンプレートじゃなくても良いように設計し直します

2023/01/26(木) 14:08:41.08

this->f で済むだろうに、設計を変えるほどのことなのか。

2023/01/26(木) 14:16:44.11

>>226
それでは>>225のケースでコンパイルできない
void g(){typename f();}
では?

2023/01/26(木) 14:17:00.65

>>226
それでは>>225のケースでコンパイルできない
void g(){typename f();}
では?

2023/01/26(木) 20:20:42.59

すでに出てるけどA<T>が何者か確定してないので、
(B<int>とかの具体的な型が決まる時ではなく)テンプレート宣言時にエラーになる。

template<class T> class B : public A<T>{
using A<T>::f;
public:
void g(){f();}
};
のように親クラスA<T>にメンバーfがいることを宣言してやればテンプレート宣言自体は通る。

2023/01/26(木) 22:25:04.25

>>232
>>231

2023/01/26(木) 23:06:43.67

>>226,232も
>>225のケースで通るよな？

2023/01/26(木) 23:24:47.70

>>234
わりっ! 通る
勘違いしておった

2023/01/26(木) 23:24:56.86

>>234
わりっ! 通る
勘違いしておった

2023/01/27(金) 08:40:23.26

テンプレート引数の取得ってどうやるんでしたっけ？

template<int N = 100> class A{
　...
};

class B : public A<>{
　ここから N (=100) が見えなくて困ってます。
};

2023/01/27(金) 08:43:39.83

Aの中にstatic const int nankanokosuu = N;とか定義しておく

2023/01/27(金) 08:49:13.97

>>237
class B : public A<>{
template <template<int> class T, int N> int func(T<N>*) { return N; }
public:
void test()
{
cout << func(this);
}
};

2023/01/27(金) 10:58:57.46

>>238
templateって結局
template構文書くより
C言語で直で書いた方が
短くて性能も良いパターンが多い

2023/01/27(金) 12:06:29.37

性能やリソースと引き換えに楽をする為のものだから

2023/01/27(金) 12:26:38.33

>>240
std::vectorユーザーが直書きとか不可能だろ。

2023/01/27(金) 12:32:39.32

丸々作る必要なんか無いんだよ

2023/01/27(金) 12:35:25.48

小規模組み込みならそもそもnewやdeleteが使えない環境もある
Cより便利な記述が出来るからC++を使うというだけ

2023/01/27(金) 12:52:45.15

>>240
>>237をC言語で直で書いたらどうなるの?

2023/01/27(金) 13:48:07.44

>>240-241 テンプレートで性能やリソースを引き換えにすることなんか無いだろ。
・・・コンパイラの処理時間やメモリ消費の話ならあると思うけど、そういう話？

2023/01/27(金) 13:51:05.37

マジレスすると C++ のテンプレで頑張るより
Nim 使った方が楽だし時間の節約になるよ

2023/01/27(金) 14:14:37.74

>>246
組み込みのチープな環境のプログラムを組んで見ればわかるよ

2023/01/27(金) 14:40:15.09

>>240
ヘボなんだね

2023/01/27(金) 14:50:32.81

コードサイズは確かに増えるだろうが、性能は本当に測ったんか？

2023/01/27(金) 16:10:15.39

チープな環境ではコードサイズが増えるのは致命的

2023/01/27(金) 16:17:02.37

>>248
「組み込みのチープな環境」で組んでたことあるけど、心当たり無いよ。
コードサイズだって手書きなりマクロなりでも必要量は同じになるだろうし。
何か例でも挙げてみてもらえる？

2023/01/27(金) 16:29:51.65

>>246
テンプレート自体が実行性能の足を引っ張るってことはないが
個々の場面でより性能よく書けるはずのときに汎用部品で済ましてしまうってことはあるんじゃない？

そういうときでも個々の箇所をいじるよりは特殊化を足すだけで済むほうが楽だと思うが。

2023/01/27(金) 16:34:12.21

同じ結果になるように書けばそりゃ同じだろう
テンプレートで楽をすればコードは(一般的には)増える

memcpyで済む物が
型別にコードが発生したり

そういう所を気にすると結局楽が出来ない

2023/01/27(金) 16:37:07.22

>>253
全て特殊化したら楽が出来ない
手間が増えるだけ

2023/01/27(金) 16:40:41.26

10種類のテンプレート引数で使うコードは
基本的には10個のバイナリが生成される

10種類手で書けば
当然コードの共通化を(人間が)考える

2023/01/27(金) 17:11:02.52

>>255
必要なとき、効果があるときというのは当然の前提やが。
早すぎる最適化は諸悪の根源。雑に書いて動くようになってから必要に応じてチューニングするもんやで。

2023/01/27(金) 17:18:26.40

>>257
リッチな環境前提の発想
初めから考えないといけないチープな環境もある

2023/01/27(金) 17:22:03.06

Embedded C++やってろ

2023/01/27(金) 17:22:16.96

非力なハードで無理目なことをギリ勝負でやるときはアセンブラだろ

2023/01/27(金) 17:22:48.21

実際PC用コードの多くは組み込みでは全く使えず
ほとんどゼロからの開発になる

2023/01/27(金) 17:24:10.47

>>260
もちろん必要ならアセンブラも使うが
CやC++による最適化が先

2023/01/27(金) 17:24:25.29

そういう環境ってそもそも標準ライブラリ揃ってなかったりしない？このスレで扱う必要ある？

2023/01/27(金) 17:25:27.76

>>263
標準ライブラリのスレではないから

2023/01/27(金) 17:32:21.49

ぬるま湯環境しか知らないはちみつ
もう少し視野を広げた方が良いかと

2023/01/27(金) 17:50:48.85

なんかやたらマウント取りたがるな

2023/01/27(金) 17:55:50.00

学校でC++03教えてそう(笑)

2023/01/27(金) 18:01:40.26

ワイは Z80 時代を生きたおじさんやぞ。
いまどきチープな組み込みでも最初からそんなカリカリにチューニングするのはそんなにないやろ。
無いとは言わんけど C++ の利用例としては例外的やわ。

2023/01/27(金) 18:16:51.47

カリカリチューンとぬるま湯コーディング
はちみつの頭の中はどっちかしか存在しないのかよ

2023/01/27(金) 18:24:03.96

人のことを小馬鹿にするだけなやつ出てけよ
プログラム技術の話の邪魔だ

2023/01/27(金) 18:25:43.08

>>249が書いても説得力ゼロ
私は>>240でもないんだけど

2023/01/27(金) 18:28:51.80

は？　俺は技術の話をしている
途中で根拠も挙げずに変なことを言うやつにチクリとやったが
貴様と違いそれだけじゃねえんだよボケ

2023/01/27(金) 18:30:54.17

根拠あるじゃん

2023/01/27(金) 18:31:53.95

おれがいくつか書いた

2023/01/27(金) 18:32:25.20

どこにだよ
しどろもどろな返事だなスカタン

2023/01/27(金) 18:33:01.59

日本語読めない人かな？

2023/01/27(金) 18:38:13.74

ないものは示せないもんな
せいぜいそんな言い訳にもなってないことを勝手にぬかしてろ
俺はこれから夕飯作らにゃならんし害虫が出てくのを待つ意味でもしばらく落ちる

2023/01/27(金) 19:53:44.64

>>269
文脈見ろ。それは >>265 に対して言ってんだぞ。

2023/01/27(金) 19:59:17.27

10種類とかで肥大するのはテンプレートなのにデカい関数作るからやろ
共通化できる部分は型に依存しない箇所だからテンプレートだろうと外に出せる

2023/01/27(金) 22:01:21.69

>>270
それお前やろ

2023/01/27(金) 22:06:41.58

www

2023/01/27(金) 22:15:36.78

孤独のグルメじゃないけど「こういうのでいいんだよ」が最適解なこと多いよな、C/C++

2023/01/27(金) 22:37:05.53

あまりゴチャゴチャさせずにシンプルイズベストよな

2023/01/27(金) 22:40:45.09

C++20 のビューとやらを使ってみてるんだがデバッガで見づらすぎるのどうにかならん？

2023/01/27(金) 23:34:33.68

>>237
template<int N = 100> class A{
　static int nnn{N};
};
とすると、
A<123>::nnn が 123 になるはず。
static を付けない場合は、インタンスオブジェクトに対して取得できる。

2023/01/28(土) 15:20:49.48

これは>>239が面白いな

2023/01/28(土) 15:29:40.57

>>286
ありがとう
誰も反応しなくてつまらんかった

2023/01/28(土) 15:40:35.35

>>238
constexprの方が良いのかな?
static constexpr int nankanokosuu = N

>>285
constかconstexprかが必要
それはさておき初期化の位置に使っている中括弧 {N} はなに?

2023/01/28(土) 16:15:40.82

単に初期化で使ってるだけでしょ
今回はintであることが明白だから=でも()でも{}でも初期化できるけど

この手のコンパイル時に決まるやつはstatic constexpr一択だね
array<T, nankanokosuu> a;みたいに他のテンプレート引数に使える

2023/01/28(土) 16:18:27.56

constexprにするとコンパイル時に解決出来ない項目は弾かれてしまうからconstのままでいい
知らないなら余計な修正は加えるな

2023/01/28(土) 16:50:45.80

>>290
>>237のケースではtemplate引数のNを受けるのだから
コンパイル時に決まっているのでは?
コンパイル時に決まっていることが含意された
constexprの方が良いと思うけど?

2023/01/28(土) 17:08:38.28

>>288
>それはさておき初期化の位置に使っている中括弧 {N} はなに?
C++11位から導入された初期化の一種。
a{N}は、a = N とほぼ同じだが、縮小変換をしないということや、
「どんな場所でも必ず使える」特徴があると言われており、Stroustrup氏
は、= よりも {} を推奨している。
また、{} による初期化は「直接初期化」と関係が深く、= による初期化は
「代入初期化」と関係が深い。

2023/01/28(土) 22:18:12.18

>>292
なるほどC++11以降なのね
「縮小変換」「直接初期化」「代入初期化」がよく分からんが

2023/01/28(土) 23:35:50.70

>>293
「直接初期化(direct initialization)」とも関係しているが、
{}による初期化は、「一様初期化 (uniform initialization)」
で検索すると出て来やすい。
なお、ネットでdirect initializationを検索しても間違った定義が出てくるかも知れない。

2023/01/29(日) 00:27:43.05

>>294
なるほど「直接初期化」と{}による初期化（= [一様初期化]）は分かった
[一様初期化] https://cpprefjp.github.io/lang/cpp11/uniform_initialization.html
[直接初期化] https://learn.microsoft.com/ja-jp/cpp/cpp/initializers?view=msvc-170
「縮小変換」と「代入初期化」が分からん
「代入初期化」は=による初期化のことを言ってるのかな?

2023/01/29(日) 12:04:49.28

C++17のcopy elisionでルール変わったね

2023/01/29(日) 13:42:04.03

>>295
正しい定義かどうかは分からないが、一応、
「直接初期化」「コピー初期化」については、英語版の en.cppreference.com
をそれぞれ
「direct initialization」「copy initialization」
で検索すると「パターン」一覧が出てくるみたいだ。
ただし、一覧については「全てのパターン」かは定かではない。
例えば、direct initialization については、一覧には、new T(XXX) しか出てないが、
new T{XXX} でも良いハズ。

2023/01/29(日) 13:47:49.42

>>297
https://en.cppreference.com/w/cpp/language/direct_initialization

T object ( arg );
T object ( arg1, arg2, ... ); (1)

T object { arg }; (2) (since C++11)

T ( other )
T ( arg1, arg2, ... ) (3)

static_cast< T >( other ) (4)
new T(args, ...) (5)
Class::Class() : member(args, ...) { ... } (6)
[arg](){ ... } (7) (since C++11)

[説明]
* (5)は、() しか出てないが、{} でも可能 :
new T(args, ...) (5)
new T{args, ...} (5')

* (3) も、() しか出てないが、{} でも可能で恐らくother でなくてもいい筈だ(定かではない) :
T ( other )
T ( arg )
T ( arg1, arg2, ... ) (3)
T { other }
T { arg }
T { arg1, arg2, ... } (3’)

2023/01/29(日) 13:56:42.30

>>295
>「縮小変換」と「代入初期化」が分からん
>「代入初期化」は=による初期化のことを言ってるのかな?
縮小変換は、検索すると出てくる。
「代入初期化」という言葉は、俺の記憶違いだったらしく、「コピー初期化」
が正しかったようだ。難しい。

2023/01/29(日) 14:05:48.45

ここが分かり易いかな:
「Is it direct-initialization or copy-initialization?」
https://stackoverflow.com/questions/46634869/is-it-direct-initialization-or-copy-initialization

2023/01/29(日) 20:57:42.75

>>299,300
なるほど「縮小変換をしない」とは
例えば以下でエラーになるってことね
int a {1.0};
「コピー初期化」ってのはコピーコンストラクタを呼ぶ初期化
あるいはコピーコンストラクタ自体のことで良いのかな?

2023/01/29(日) 23:00:33.52

>>301
>「コピー初期化」ってのはコピーコンストラクタを呼ぶ初期化
>あるいはコピーコンストラクタ自体のことで良いのかな?
個人的には、
CPerson::CPerson( CPerson const &rPeson )
の形式のコンストラクタがコピーコンストラクタで、
それを使う初期化がコピー初期化、と思って今まで生きてきたが、
それだと、「直接初期化」の対比の意味のものとは違っているように思える。
どこかで、言葉の混乱が起きているかも。
分からない。

2023/01/29(日) 23:11:23.60

>>302
一部の例外を除いては、「コピー初期化」とは、= が書いてある初期化で、
「直接初期化」とは、= が書いて無い初期化、だといわれている。
但し、沢山例外があって、
T x = T(a);
などは、直接初期化なんだそうだ。
また、return a などは、コピー初期化、なんだそうだ。
記憶に頼っているので間違っているかも知れない。

2023/01/29(日) 23:20:25.89

コピコンか代入か明示するためのexplicitよ

2023/01/30(月) 01:17:26.91

>>302
コンストラクタはどれも直接初期化に使えるコンストラクタだけど
一定の形式を満たすものはコピー初期化の文脈「でも」使えるってだけ。

>>303
> T x = T(a);
> などは、直接初期化なんだそうだ。

これについて形式的にはあくまでもコピー初期化の一種ということになる。
https://timsong-cpp.github.io/cppwp/n4659/dcl.init#15
その上でコピーの省略が起きて結果的には直接初期化と同じ挙動になる。
https://timsong-cpp.github.io/cppwp/n4659/class.copy.elision#1

2023/01/30(月) 16:11:51.36

記憶に頼って書くけど、
1. 1つの引数を持つコンストラクタは、explicit修飾することが推奨されている。
2. explicit指定が無いと、そのつもりは無い「ひょんな場所」で勝手に変換コンストラクタとして
　利用されてしまうことがある。特に関数に引数を渡す場合に起き易いらしい。
3. CPerson::CPerson( CPerson &rPerson ) は、同じ型を単純にコピーする
　コンストラクタであるから、そもそも型の変換はしないので変換コンストラクタでなく、
　「コピー・コンストラクタ」と言われる。
4. つまり、CPerson::CPerson( AAA &rAAA ) のような場合に

2023/01/30(月) 16:18:21.06

>>306
[誤送信してしまった。スマソ]
4. つまり、CPerson::CPerson( AAA const &rAAA ) や CPerson::CPerson( int &rX )
　のような場合に explicit 指定することが推奨されていたと思う。

T x = T(a);

の場合、「C++のからくり」のような昔の解説書だと、最適化に任されているのではなく、
特別処理されているようなニュアンス(?)で、T x(a) と同じだと書いてあった。
もし、特別処理されてないと考えた場合、= の部分だけに着目すれば、T::T( T const &rX ) という
コピーコンストラクタの呼び出しと意味論的には考えて考えられなくも無い。
そうするとそこは「変換コンストラクタ」ではなく「コピーコンストラクタ」が使われることになる。
コピーコンストラクタはいくら使っても速度が遅くなる以外は劣化やデータの変化が無いため
無害と言えば無害。なので、explicit が付いていてもいなくても余り関係が無いような気がする。

2023/01/30(月) 16:24:16.09

>>307
[補足]
void f(T x);
に対して、
U a;
f(a);
と書くと、実引数aが仮引数xに渡される時の動作は、「コピー(?)初期化」と考えられて
いる。もしかしたら言葉は正しく無いかもしれないが、少なくとも「直接初期化」には
分類されないということ。
そしてexplicitが付いて無いコンストラクタは、このような初期化に対しては用いられ
ないことが保証されると書いてあったと思う。

2023/01/30(月) 16:25:22.84

>>308
[訂正]
誤: そしてexplicitが付いて無いコンストラクタは、このような初期化に対しては用いられ
　　ないことが保証されると書いてあったと思う。
正: そしてexplicitが付いている無いコンストラクタは、このような初期化に対しては用いられ
　　ないことが保証されると書いてあったと思う。

2023/01/30(月) 16:26:12.39

>>309
[再訂正]
誤: そしてexplicitが付いている無いコンストラクタは、このような初期化に対しては用いられ
　　ないことが保証されると書いてあったと思う。
正: そしてexplicitが付いているコンストラクタは、このような初期化に対しては用いられ
　　ないことが保証されると書いてあったと思う。

2023/01/30(月) 16:50:51.20

>>304
explicit指定の主な役割は、変換コンストラクタにexplicit修飾しておくことで
「変換コンストラクタが知らず知らずのうちに勝手に使われてしまう事」
を防げる、ということだったと思う。