C++相談室 part165

2023/10/31(火) 07:37:38.52

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

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

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

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

2023/10/31(火) 08:59:52.78

>1 乙です

前スレ例外はループ脱出に使うような物じゃない、との意見に賛成です。

自分は、例外は「起こり得るけどいちいちエラー処理を書いたらアホな話を」「処理呼び出し毎ではないレベルで」「エラー対処コーディングするもの」と思ってます。

具体例は、
リンクリストなどコレクション操作でメモリ不足が起きた場合、のエラー処理。
コレクションの追加や削除を頻繁に行うコードって、大体はもっと概念レベルが高い事をやってるので、1件の追加レベルでエラー処理書いてたらアホな感じになる。

しかも、GUI プロセスを作ってて何か上手く動かないから特定のエラーだけを画面に表示したい、など、ことさら明確に対処したい場合です。プロセスが落ちればいいだけなら、main()の外側、の仕様がやってくれる。

古い本の情報だけど、SBリップマンによると、MS VC++と、sun、hp-ux の C++コンパイラで、例外を使う／使わないで速度性能調査したそうで、 4~6% の速度劣化があったとの事です。

2023/10/31(火) 09:37:52.87

スレ終了間際に現れる質問いいですかオジなんなの？w.

2023/10/31(火) 09:38:43.79

Pythonで言うと
forのStopIterationはへっ？だし
int()のValueErrorですら微妙

2023/10/31(火) 11:32:52.74

うるせえstd::stoi()ぶつけんぞ

2023/10/31(火) 16:49:04.12

>>3
ヘッダーの最後の行の #endif みたいなものだよ

2023/10/31(火) 23:53:09.44

>>6
と、言うことは対になる#ifがどこかに？

2023/11/01(水) 10:50:51.42

…（いくら5chとは言え、複数の人が集まる場所で、何かを教えて頂いてもお礼も言えず、面白い返しもできない人がいたとして。その人がプログラムに関してだけは素晴らしいコードを書ける、なんてことはあるのかな？と思う瞬間が人生の中であったり、なかったり）

2023/11/01(水) 12:51:50.53

（礼儀とプログラミングスキルは関係ないと思う）

2023/11/01(水) 12:53:02.45

（俺の昼飯どこ行った？）

2023/11/01(水) 16:02:16.42

(今日の昼飯はセブンのサバ塩焼弁当にしとくか・・・)

2023/11/01(水) 18:24:49.00

コードにはある程度そいつの人間性は反映されるな
スレチな話題ではあるけど

2023/11/01(水) 23:07:31.46

(本物のプログラマはPascalを使わない)

2023/11/01(水) 23:30:59.94

(でもPythonは使ってもいいのかな？って時々思う)

2023/11/02(木) 00:03:32.45

そろそろキャストは止めてスマポ使いましょう

2023/11/02(木) 02:43:15.24

まちゅまちゅの3Dライブみた
前も思ったけどみこちとかなたそのダンス、めっちゃシンクロ率高い
リズムがぴったり一緒なんだよね
ダンスほんとにうまくなったよな

2023/11/02(木) 02:43:45.89

誤爆った(´･ω･｀)

2023/11/02(木) 07:17:03.35

ホロライブか

2023/11/02(木) 10:44:27.02

(まちゅまちゅの3Dライブ?・・・ちょっと気になる)

2023/11/02(木) 23:48:48.29

(((お前ら括弧ばっかり使ってlisperかよ？)))

2023/11/03(金) 10:21:23.72

←vーー( ﾟ∀ﾟ)!ー^ー

2023/11/04(土) 18:56:36.20

コピーとムーブの挙動、というか管理難しい。。難しくない？

2023/11/04(土) 20:24:08.34

コピーやムーブはパターンに沿って管理できるからそんなに難しいとは感じないな。

ワイとしては参照の畳み込み (Reference collapsing) や変換の規則を毎回のように確認するんだけど全然頭に入ってこない。
参照はオブジェクトではないので逆に言えば値に対応する型が参照になることはないのだが、それはそれとして参照を含む型があり得るというのが今でも腑に落ちない。

2023/11/04(土) 20:28:09.97

参照しか知らんものだけど、ムーブて何か簡単に教えて
参照は実装上ただのポインタじゃん
ムーブはなにがどうなるん？

2023/11/04(土) 20:29:19.85

ムーブコンストラクタが起動する。
それだけ。

2023/11/05(日) 09:49:50.04

>>24
考え方としては、shallow copyを二重開放リスクを避けて行うための仕組み。
右辺値という特別な一時変数のコピーで特別なコピー(ムーブコンストラクタ)を実行するようにして、クラス設計者が必要に応じてshallow copyを実装しやすくしている。

2023/11/05(日) 10:41:04.16

>>24
moveはRustで言う所有権の移動じゃないか

2023/11/05(日) 13:06:56.97

>>24
aに戻り値などの一時オブジェクトbをコピーすると通常は

aでメモリを確保
bからメモリコピー
bのデストラクタでメモリを破棄

という動作になるけど、moveの場合

aにbでメモリをポインタで持ってくる
bのインスタンスでは破棄したことにする

とすれば無駄なメモリ確保とコピーが発生せず効率が良い

2023/11/05(日) 13:39:42.02

標準ライブラリでのムーブは所有権 (ownership) の概念を前提として構築されているし、
慣例としてもそのようにするものではあるんだが
言語としてはムーブコンストラクタ (またはムーブ代入演算子) を呼び出すというだけで
所有権の面倒をみる機能は何もない。
(辻褄が合うようにするのはプログラマの責任。)
何が起きているのかは所有権の概念と実装レベルで分けて考えたほうがいいと思う。

どう説明していいかわからんから関連する要素を箇条書きにしたらこんな感じかな。

・それがコピーの文脈であるかムーブの文脈であるか区別は出来る
・一般的にムーブの文脈であった場合 (寿命が尽きる直前の一時オブジェクトの再利用が出来る場合) にコピーより効率が良い動作が出来る可能性がある
・どのように効率がよくなるのかはそのクラス (のムーブコンストラクタやムーブ代入演算子) の定義次第
・典型的なムーブの実装はリソース本体を指すポインタの交換によって実現される
・ユーザーが定義を与えなかった場合のデフォルトのムーブは全てのサブオブジェクトをムーブすることになっている

2023/11/05(日) 13:42:20.39

で、このmove動作を定義するために、
一時オブジェクト（右辺値）に対する参照動作を関数定義できるようになっている

2023/11/05(日) 14:05:22.83

ムーブされるとそのポインタは変わってしまうと思うけど、そういうケースはないの？

2023/11/05(日) 14:18:09.07

言っている意味がよく分からないが、純粋なポインタにはムーブという概念はないよ
ムーブを定義できるのはクラスに対してだけ
他の人も言っているようにムーブといっても実体は単なる関数呼び出しなので、その中でプログラマが自分の責任で必要なコードを書くことになる

2023/11/05(日) 14:58:05.35

質問した人じゃないけど説明ありがたいです

ムーブ難しいと思ってたけどもっと早く勉強して仕事で使うべきだった

（文法解析した要素をポインタいじって並べ変えるんだけど…
二重所有を防ぐのを手作業コーディングで責任を持たなければならないプログラムを作ってしまった）

2023/11/05(日) 15:15:28.75

ただ、右辺値参照を使うと、通常の参照や代入と使い分けるためにconstやnoexceptを厳密に指定しないといけなくなりがちだから、
その辺の総合的な理解が必要になってくるのは注意点だね
constは一度付け始めるとライブラリ全部に伝染するからな･･･それを嫌って使わない派も結構いる（いた）よね

2023/11/05(日) 15:39:17.77

実際のコードだとポインタのムーブはunique_ptrとかにぶん投げで、自分で移動コード書くことはまずないな
自分でムーブ特殊関数の中身書くのはハンドル的なもののムーブを実現したいときくらい

2023/11/05(日) 16:12:35.07

とにかく unique_ptr が便利すぎるから何でもかんでも全部 unique_ptr 使うようになってしまった
まあそれでいいのかもしれないが

2023/11/05(日) 16:21:29.02

>>33
銀の弾丸ではない
手作業コーディングで責任を持たなければならないのは変わらない

2023/11/05(日) 17:10:59.04

所有権管理も結局はプログラマが書く (間違いを部分的にコンパイルエラーとして検出できることはある)、
所有権って具体的に何なんだってのはクラス定義に押し込めるという風に管理のレイヤを分けることが出来るってわけ。

クラス定義をした後は具体的に何をやってるのかを忘れて
所有権というものだと思い込むことが出来るという抽象化の仕組み。

2023/11/07(火) 10:10:32.04

>>37
アホか
普通に考えて、そのコード(クラス)の利用者が所有権について明示的に何かしなきゃいけなかったということだろ

2023/11/07(火) 19:02:58.77

>>33
エスパーするけど多分その用途だとmoveは使えない。

データを共有している感じなので素直にshared ptrを使うのがいいかと。shared ptrで性能的にキツイならshared ptrを参照渡しするか。

2023/11/07(火) 19:09:56.10

>>40
ちょっと補足すると、戻り値をshared ptrの参照にするのはNGですな。そこは素直にRVOに期待するのが良いか。

2023/11/09(木) 17:23:48.54

VC++なんだけど32bitで_thiscallを関数ポインタ経由で呼ぶことってasm使わないと不可能？
メンバ関数を関数ポインタ変数とすることは出来てもそこから第一引数にインスタンス入れたりしてもコンパイル時エラーになる

2023/11/09(木) 18:09:02.18

>>42
メンバ関数をポインタ経由で呼び出したいってことならstd::bindでできるはず

2023/11/09(木) 18:24:20.63

VC++ のことは知らんけどメンバ関数ポインタは関数ポインタより大きい実装になってる処理系がある。
メンバ関数ポインタを関数ポインタに変換した時点で呼び出すのに必要な情報が失われているかもしれない。

2023/11/09(木) 19:04:30.42

MJD?

2023/11/09(木) 19:13:19.18

エラーメッセージにヒントはない？

2023/11/09(木) 19:58:26.06

基本的には言語の規定内でやるに越したことはないので無理な型変換をしないで済ませられるように出来るものならそうしたほうがいい。
どうしてもそうできない事情がある(と質問者が認識している)ならもうちょっと詳しい状況をコードで示して欲しい。

2023/11/09(木) 21:12:03.97

>>43
ありがとう、逆アセ見たら完璧にthiscallになってた

メンバ関数っていうかthiscall指定したものは32bitだとecxレジスタにthisポインタが隠されていてそれ以外はstdcallと同じ
なので下みたいに第一引数にインスタンスのポインタを入れる事でecxに代入される感じになりそうだなーと思ったら無理だった
ちなみに64bitの場合はどちらもfastcallで同じだから単純に第一引数にthisポインタが隠されてるだけ
auto pFunc = CDate::addDay; // CDate addDay(int value)
CDate tomorrow = pFunc(&instance, 1);

2023/11/09(木) 21:28:58.67

てかググったら簡単なシミュレーション方法載せてるブログあった
_fastcallで宣言して第二引数のedxを捨て駒にする事で疑似_thiscallになる
つまりint(__fastcall * pFunc)(CDate*, void*, int)とすれば一応アセンブラ的な辻褄は合う事になる

2023/11/12(日) 10:07:59.74

質問なのですが型Tの参照を返す関数 const T& foo() の戻り値をautoのいくつかのバリエーションで受けてアドレスを見て見たのですが
　　auto x = foo();
　　auto& y = foo();
　　const auto z = foo();
　　const auto& zz = foo();
　　const volatile auto& zzz = foo();
　　cout << "&original=" << &g_vec << endl;　　 // &original = 00B013D8 (このアドレスは一例)
　　cout << "&x=" << &x << endl;　　　　　　　　// &x = 010FF8AC　// コピー(意図しないかも？)
　　cout << "&y=" << &y << endl;　　　　　　　　// &y = 00B013D8 // 参照(OK)
　　cout << "&z=" << &z << endl;　　　　　　　　// &z = 010FF888 // コピー(意図しないかも？)
　　cout << "&zz=" << &zz << endl;　　　　　　　// &zz = 00B013D8 // 参照(OK)
　　cout << "&zzz=" << &zzz << endl;　　　　　　// &zzz = 1 // !!!!
という行末コメントに記載の結果になったお
Q1. 参照で受けたい場合は auto でなく auto& とせねばならない、で正しい？
Q2. 間違えてauto で受けても動いてしまい発見し難いケースが多いと思うのですが
　　意図しないパフォーマンス低下になるので防ぐ対策とか無い？
Q3. zzzのｱﾄﾞﾚｽが1になるのは一体……
MSVC2019使用、言語の設定はC++14、

2023/11/12(日) 11:02:37.63

>>50
A1. 単に auto としたときに参照になることはない。
　　参照として受け取りたい場合は auto& にせねばならないというのは正しい。
A2. 参照かどうかで自動的に場合分けして欲しいなら decltype(auto) とすればいいが……
　　参照で受けるのが正しい状況なのかどうかは状況による。
　　テンプレート内など自動的な場合分けが必要な場合を除いては参照は参照として明示したほうがよくない？
　　(個人的感想です。)
A3. いくつか用意されている operator<< の基本的なオーバーロードの内で bool にマッチするから。
　　void* もあるのだけれど C++ では任意のポインタは void* へは暗黙の型変換されないのでマッチング候補にならない。
　　アドレスとして解釈して欲しいなら void* へ明示的に型変換しないといけない。

2023/11/12(日) 11:38:27.18

ごめん。間違いがあった。
ポインタは void* へ暗黙に変換できる。
この変換はオーバーロード解決時の候補になりうる。
ただ、 bool への変換とは優先順位に差がある。

2023/11/12(日) 11:42:25.19

>>51>>52
㌧クス、
なるほど
わかりた
↓こうなったわ
　　decltype(auto) z = foo();
　　const auto& zz = foo();
　　const volatile auto& zzz = foo();
　　cout << "&original=" << (void*)&g_vec << endl;　　　// &original=010213D8 (このアドレスは一例)
　　cout << "&z=" << (void*)&z << endl;　　　　　　　　 // &z=010213D8　　　// 参照(OK)
　　cout << "&zz=" << (void*)&zz << endl;　　　　　　　 // &zz=010213D8　　 // 参照(OK)
　　cout << "&zzz=" << (void*)&zzz << endl;　　　　　　 // &zzz=010213D8　　// 参照(OK)
　　cout << std::boolalpha << "&zzz=" << &zzz << endl; // &zzz=true　　　　// boolean
boolへの変換は使うことは無いと思うが正体は調べてみるわ

2023/11/12(日) 11:46:29.61

>テンプレート内など自動的な場合分けが必要な場合を除いては参照は参照として明示したほうがよくない？
非constなら考えるがこの場合foo()はconstオヌジェクトと参照を返してくるし、
これはもうdecltype(auto)一択で良いような気がが、

2023/11/12(日) 12:07:32.76

volatile を追加する変換は出来るが除く変換は出来ないから
volatile 付きのオーバーロードを用意していない operator<< では候補から消えて
bool だけが候補として残ってしまうってことになるみたいだな。

volatile が付いていない場合は
void* への変換のほうが bool への変換より優先順位が高いので
そっちが呼ばれる。

**あぼーん** · NG

あぼーん

2023/11/13(月) 02:33:43.38

>>56
案内サンクス

2023/11/14(火) 02:19:13.60

CLion使ってる人いますか？

2023/11/17(金) 17:16:02.48

日本人の死亡者が増えてるのに、メディアは報道規制
https://kizuna.5ch.net/test/read.cgi/cafe50/1699777256/l50

2023/11/18(土) 16:16:09.27

ラムダの参照キャプチャってconst参照に指定できないんだっけ？微妙に不便だな。

2023/11/18(土) 20:47:45.62

>>60
これじゃだめ?
#include <iostream>
using namespace std;
int main () {
const int a {0};
int b {0};
[&a, &b = const_cast <const int &> (b)] () {
++ a; // X
++ b; // X
} ();
return 0;
}

2023/11/26(日) 06:27:21.37

C++20 RangesはMicrosoftの説明がわかりやすかった

2023/12/05(火) 10:33:06.64

ふと今更思ったんだけど
ポインターpに対して演算子*が返す*pは、
値じゃなくて参照？

2023/12/05(火) 11:05:15.15

#include <type_traits>
#include <iostream>
using namespace std;
int main () {
int value {0};
int *p {&value};
cout << is_reference <int>::value << '\n';
cout << is_reference <int &>::value << '\n';
cout << is_reference <decltype (value)>::value << '\n';
cout << is_reference <decltype (*p)>::value << '\n';
return 0;
}

2023/12/05(火) 11:09:19.91

>>63
参照ってのが何を意味しているか分からんが
普通はポインターの示す場所の内容だ

2023/12/05(火) 11:22:18.93

>>63
ポインター p に対して *p とした場合の型は参照ではない。
たぶん >>64 は *p が参照と言いたいつもりで書いているんだと思うけど
decltype に与えられる式の型が T 型の lvalue だった場合には T& が返されるルールなので
その式が参照でなくても参照が返されることがある。

2023/12/05(火) 11:24:42.01

あ、ごめん。完全に間違った説明してたわ。忘れて……。恥ずかしい。

2023/12/05(火) 11:34:00.06

と思ってよく仕様を読んでみたらやっぱりこの (>>66) 考え方で正しいはず。

式が識別子式の時に限っては decltype は参照にならず式の型そのままで返すせいで decltype(value) は参照にならないが、
value と *p は型システム的にも値カテゴリ的にも同じだわ。

2023/12/05(火) 12:43:28.97

>>68
なるほどー! 横からだが勉強になった

2023/12/05(火) 12:48:03.77

巷のスマートポインタはoperator*で参照型を返すので
生ポインタも同じかと思ってたよ

2023/12/05(火) 13:28:25.92

互換性の都合とかがあるから仕方ないね。
場合分けが大量にあって単純な一般原則の組み合わせにはなってないから仕様を読み解くのがしんどい……

2023/12/11(月) 15:17:51.77

ある構造体Aがあります
Aの比較関数が複数ありますcompA0,compA1,compA2,...
比較関数の関数ポインタがありますcompA
compA = &compA2;

別の構造体Bがあります
BはAを内包しています
struct B{ A a; ... };
この構造体Bを、Aの比較関数ポインタcompAで比較してソートするにはどう記述すればよいですか？
std::vector<B> bs;
bs.push_back(...);...
std::sort(bs.begin(),bs.end(),?);

できればラムダ式を使わずにできるとありがたいです

2023/12/11(月) 15:22:02.06

>>72
ラムダ式使った方が良いと思うけど本当にラムダ式なしが良い?

2023/12/11(月) 15:29:19.94

使われると、ラムダ式の質問をすることになると思います・・・

2023/12/11(月) 15:45:20.57

>>72
もし C++20 を使えるなら (std::sort と違って) std::ranges::sort では比較関数とは別に
比較すべき要素を取り出す操作をプロジェクションとして与えることが出来るから
これ一発でいけてだいぶん楽できる。

std::ranges::sort(bs, compA, &B::a);

2023/12/11(月) 16:01:10.52

>>75
すげ! 今そんなのあるんやね

2023/12/11(月) 16:34:20.59

>>74
思い出すのがしんどくなってきた
#include <iostream>
#include <vector>
#include <algorithm>
#include <functional>
using namespace std;
struct A {int value_;};
bool compA2 (const A &lhs, const A &rhs) {
return lhs.value_ < rhs.value_;
}
struct B {A a;};
int main () {
vector <B> bs;
bool (*compA) (const A &, const A &) {compA2};
sort (bs.begin(), bs.end(), bind (compA, bind (mem_fn (&B::a), placeholders::_1), bind (mem_fn (&B::a), placeholders::_2)));
sort (bs.begin(), bs.end(), [compA] (const auto &lhs, const auto &rhs) {return (*compA) (lhs.a, rhs.a);});
return 0;
}

2023/12/11(月) 17:14:54.00

>>75
>>77
お二方、ありがとうございます
参考にして組んでみます

2023/12/11(月) 17:25:04.51

その場で合成するのはさすがに見通しが悪すぎるので、
C++11 頃の C++ を仮定して私がやるならまずアダプタを作ると思う。
ちょっと雑ですまんがとりあえずこんな感じ。

class compB_adaptor {
private:
using comparator = std::function<bool(const A&, const A&)>;
comparator compA;

public:
compB_adaptor(comparator comp) : compA(comp) {}
bool operator()(const B& x, const B& y) {
return compA(x.a, y.a);
}
};

使うときには間にひとつ挟むだけで済む。

std::sort(bs.begin(), bs.end(), compB_adaptor(compA));

2023/12/11(月) 22:08:32.24

>>79
求めていたものそのものであったため、採用させていただきました
ありがとうございます

2023/12/20(水) 23:47:12.14

int x;
std::cout << x;
でxが正ののときは「+」符号を付けさせるのってどうするんでしたっけ……
cout.form("%+d", x)とか以外で

2023/12/20(水) 23:58:48.32

cout << showpos

2023/12/21(木) 08:41:44.38

てきました㌧クス、
iosヘッダで探せば良かったのか、、、

2023/12/21(木) 20:01:46.13

C++23だとこれ
std::print("{:+}", x);

2023/12/22(金) 13:56:54.85

PythonやC#のようなf"{x}"構文が作られる事はないんだろうか

2023/12/22(金) 14:54:27.15

>>85
リフレクションが充実すればその上に実装できるので
直接的な言語機能として用意すると
辻褄合わせが後で面倒になるだろうし、
現時点で考えるのは時期尚早だと思う。

2023/12/24(日) 17:42:14.24

質問なのですが自作クラスFooのストリーム出力演算子に引数付きのマニピュレータを追加したいのですが
　　↓こんなやつ
　　Foo obj;
　　cout << custom_setw(10) << obj; // 整数のベクトル的なオブジェクトobjの要素を幅10文字で出力
custom_setw()で与えた10という数値をつつがなくFooのストリーム出力演算子
std::ostream& operator<<(std::ostream& os, const Foo& obj)
に渡すには一体どうすれば……orz

2023/12/24(日) 17:42:52.36

グローバル変数渡しは最初に思いつくのですが、ostringstream os1, os2とFoo obj1, obj2に対して異なるスレッドで
os1 << custom_setw(30) << obj1;　　// スレッド1
os2 << custom_setw(20) << obj2;　　// スレッド2
とかやったら詰むし
std::setw()とか一体どうやってるんじゃ……

2023/12/24(日) 18:05:55.09

>>87-88
特定の型を出力するときにだけ作用する書式を設定するマニピュレータってこと？

std::setw がやってるのはストリームのメンバ関数 width を呼ぶのと同じ。
ストリームのオブジェクトが幅に関する情報を保存するデータメンバを持っていて、それを変更してる。

もちろんあなたが定義した独自の型 (この例では Foo) に結び付いた書式を保持するところなんて存在しないから単純にはできない。
私が思いつくのは
　・ストリームのほうも新しいものを定義する、つまり basic_ostream を継承して Foo 用の書式を格納するデータメンバを増やす
　・ストリームに対応付いたデータを格納するものを std::map かなんかで保持しておいて Foo を出力するときはそれを参照する
ということくらいかな。

スレッドが絡むと面倒くさいけど、しょうがないね。

2023/12/24(日) 19:04:41.48

既存のcoutとかstringstreamとかで使いたいなら、グローバルのstd::unordered_map<std::ios_base*, MyManipData>にでも置いとくしかないだろうね
ストリームオブジェクトの状態で持たせるクソ設計が悪いんだ

2023/12/24(日) 19:34:37.93

レス㌧クス、
>ストリームのオブジェクトが幅に関する情報を保存するデータメンバを持っていて、それを変更してる。
なるほど……
これはユザーの立場からはメンバの追加ができない領域なので、Fooの側にメンバを持たせることにしますか……
class FooWrp {
　　const Foo& m_objRef;
　　int m_nWidth;
public:
　　FooWrp(const Foo& obj, int width) : m_objRef(obj), m_nWidh(width) { }
　　friend std::ostream& operator<<(std::ostream& os, const FooWrp& wrp) { ...(wrp.m_objRefの要素をwrp.m_nWidthに描かれている幅で出力する処理)... }
};

2023/12/24(日) 19:35:17.01

// 使い方
Foo obj;
cout << FooWrp(obj, 10);

ﾀﾞｯｻｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
しかし、「たかが表示の整形」のために排他制御しつつmapを弄ったりTLSの利用を考えるのもアレなのでこれはこれで仕方が無いのか、orz

2023/12/24(日) 19:45:29.51

ストリーム用の演算子なんか作らずに
オブジェクトの文字列表現を返す関数を用意したほうが汎用性高くない？

2023/12/24(日) 19:50:06.00

Foo obj;
std::string s = obj.str(10); // 10億ギガ文字
cout << s;
出力を完遂できるんかこれ……

2023/12/24(日) 20:00:55.29

C++20 からは std::formatter を特殊化して書式指定を解釈するコードを入れておけば
std::format で独自の型を表示しようとしたときにその特殊化が使われる仕組みになってる。

2023/12/24(日) 21:41:50.00

オブジェクトの文字列表現が10億ギガ文字もあるの！？
FooWrpオブジェクトをうっかりログに出力しちゃったら大変だね！！

2023/12/29(金) 19:34:46.18

実験せずに質問するますが、
int a, b;
cin >> &x >> &y;
に対し、
Q1. 「100 a」を入力したら例外もタイムアウト待ちも発生せず、cin.fail()がtrueになるだけ？
Q2. 「100」とだけ入力してそのまんま（リダイレクト元のファイルハンドルか何かが
　　タイムアウトもエラーもクローズもしなければ）ならそれっきり返ってこない？

2023/12/29(金) 19:40:39.84

EOFが抜けてたorz
Q2のケースにおいて「100 [EOF]」なら（多分）cin.fail()でとりあえずすぐ返ってくるのかそうか、

2023/12/29(金) 21:37:06.10

>>97
実にしょうもない確認なんだけど、
言いたいことは

int x, y;
cin >> x >> y;

でよいんだよね？

2023/12/30(土) 05:42:41.89

>>99
>int x, y;
>cin >> x >> y;
おk
ｽﾏﾝｶｯﾀorz

エラーとEOFのどちらかを検知したかったら!cin.good()が正しいっぽい？
https://blog.emattsan.org/entry/20110819/1313743195

ここまでは分かった気がするが、
ストリーム入力演算子std::istream& operator>>(std::istream& os, Foo& obj)の中で入力に失敗した場合
どうやってエラーを呼び出し元に通知したらええんじゃ……

2023/12/30(土) 05:50:37.02

クラスFooの入力ストリーム演算子の中で整数を2個読むとして、
std::istream& operator>>(std::istream& os, Foo& obj) {
　int x, y;
　os >> x >> y;
　if (!os.goot()) {
　　return os; // エラー発生時は単純にreturn os; でおk？
　}
　obj.m_x = x;
　obj.m_y = y;
　return os;
}

2023/12/30(土) 08:47:16.28

>>100
ストリームのフラグを立てるメンバ関数は setstate だけど
>>101 の状況ならフラグはもう立ってるから戻るだけで問題ないよ。

2023/12/30(土) 13:48:41.88

わかりた
ていうかエラー判定（eofbit以外のビットのセットを判定）なら!os.good()や!os.goot()ではなくて
os.failed()か!osですたね……orz
これらに関して追加の質問が出たら初心者スレに書くわｻｰｾﾝ；；；

2023/12/31(日) 20:09:05.68

class A{

char buf_[size];
}

このbuf_に任意のオブジェクトをplacement newして使用するのだけど
このオブジェクトをコピーしたりムーブする場合、単純にコピー元のbuf_からコピー先のbuf_にmemcopyしてしまって大丈夫ですか？

2023/12/31(日) 20:44:02.18

全く大丈夫じゃない
初心者スレからどうぞ

2023/12/31(日) 20:54:11.90

構造体から派生させれば出来るよ

2023/12/31(日) 21:04:16.47

せめてPODと言おう
初心者スレからどうぞ

2024/01/01(月) 00:18:02.48

POD は削除された。
trivially copyable の要件を満たすならその型は memcpy でコピーしてもよい。
std::is_trivially_copyable で判定できるのでどこかに制約を入れておけば安心かもね。

2024/01/01(月) 00:36:03.09

削除されたんですか？（バージョンいくつで？）

c++20 で非推奨になった、てのはすぐ調べられたんだけどその先が分からんです

2024/01/01(月) 00:46:07.42

>>109
規格の文面としては C++20 で POD はもう削除されていて POD の概念を使わない形で再編されてる。
std::is_pod はまだある (非推奨) からこれが POD の定義だという意味ではまだあるとも言えるけど。

2024/01/01(月) 00:46:34.65

アライメント忘れてるぞ

2024/01/01(月) 03:01:35.02

>>104
まず自分でコード書いてみ
よろしくないところは指摘してやるから

2024/01/01(月) 03:14:22.37

オワコン名称出してマウント。ﾌﾟｰｸｽｸｽ

2024/01/01(月) 03:40:47.98

POD が削除されたかどうかは重要ではなくて、 POD より弱い制約 (trivially copyable) で memcpy が許されるというのが主旨。
その点は C++11 からそうなってる。

2024/01/01(月) 04:06:49.46

「構造体」ってのも C++ 用語的にはイケてないと思うよ。

2024/01/01(月) 04:55:26.71

アライメントは基本型のどれかと同じアライメント制約に合わせれば良いいということなら
使おうとしているうちで最も厳しいアライメント制約に一致する基本型を含むunionで解決するというのがC言語における伝統的な手法という印象、
C++でunionにしたら（それが可能なメンバのみなら） memcpyは安全とかにはならない？

2024/01/01(月) 05:30:52.12

>>116
コンストラクタや代入演算子がトリビアルであることなどの制約を守れば共用体も trivially copyable になりうる。
(C++ の共用体はコンストラクタやメンバ関数を定義できるがそこらが制限されることになる。)

2024/01/01(月) 14:24:55.17

char* と long* のコピーは？

2024/01/01(月) 15:31:30.97

ポインタも含めてスカラ型は Trivially copyable
https://timsong-cpp.github.io/cppwp/n4861/basic.types#9

2024/01/03(水) 23:34:38.84

>>112
とりあえず書いてみたけどどうですかね？

template<std::size_t buf_size>
struct A {
private:
struct base_ {
virtual ~base_() {};
};
template <typename F>
struct derived_ : base_ {
F f_;
derived_(F f) : f_{ std::move(f) } {}
};
base_* p_;
alignas(alignof(std::max_align_t)) uint8_t buf[buf_size]={0};

public:
A() :p_(nullptr) {};
template <typename F>
void assign(F f) {
if (p_ == nullptr) {
p_ = ::new (buf) derived_<F>{std::move(f)};
}
}
//ｺﾋﾟｰｺﾝｽﾄﾗｸﾀ
A(A& src) {
p_ = ::new (buf) decltype(src.*p_); //ここが怪しい
};
};

2024/01/04(木) 00:44:07.87

decltype(src.*p_)ってbase_なのでダメだろう

2024/01/04(木) 00:58:18.81

ていうか、decltypeで型指定してるだけだからコピーもなにもされてないぞソレ

2024/01/04(木) 02:28:40.49

std::anyのコードでも読んだほうが早い

2024/01/04(木) 09:11:56.12

A::base_に以下を足してA::derived_で実装し
Aのコピーコンストラクタから呼べば?
virtual base_ *clone (void *p) = 0;

2024/01/04(木) 13:26:37.40

void*って、ポインターの先のサイズ未知だよなぁ

2024/01/04(木) 17:16:40.43

derived_かそのメンバf_の型を知るにはRTTIしかないのですかね？

>>121
decltypeだと派生先の型はわからないのか

>>122
実体のコピーの処理が抜けてました…

2024/01/04(木) 21:53:05.60

>>124
こんな感じです？

struct base_ {
virtual base_* clone (void *p) = 0;
virtual ~base_() {};
};

template <typename F>
struct derived_ : base_ {
F f_;
derived_(F f) : f_{ std::move(f) } {}
base_* clone (void *p_buf){
return new(reinterpret_cast<derived_<F>*>(p_buf))(f_);
}
};

A(A& src) {
p_ = src.clone((void*)buf);
};

2024/01/04(木) 22:19:16.70

derived_(F f) ←この時点でムダなコピーが１度発生していることには気付いてる？

2024/01/04(木) 22:21:15.81

>>127
書き込む前にコンパイルしなよ

2024/01/04(木) 22:41:26.61

バッファの中にオブジェクトを作れたら、それで何をしたいのかが気になる

2024/01/04(木) 23:21:36.86

>>127
cloneの中ってplacement newでcopy constructorを呼ぼうとしてるんだよな？
いちおうあってるけどundefined behaviorまみれ

2024/01/04(木) 23:35:27.70

たぶんやりたいことは std::allocator_traits::construct なのかな

2024/01/11(木) 04:45:44.72

例外って全部mainで捕捉すべきかな？

調べてみたら例外が捕捉されずにプログラムが終了する場合スタックアンワインドが起こるかは実装定義みたいなんだけど、それじゃグローバルなオブジェクトのデストラクタが呼ばれないんじゃないかって思って試してみたのよ。
https://ideone.com/wSLZfL
やっぱりデストラクタは呼ばれなかったからリソースリークが起こりうるんじゃないかと思うんだけど、例外に対してはどういう態度でいるべきかな？

A. リソースリークはまずい。だから例外は全部捕捉するべき。
B. 例外はロジック上捕捉する必要があるものだけ捕捉して、それ以外はほっといていい。
C. 例外が捕捉されなければstd::abortが呼ばれるので、コアダンプなりで色々調べることもできる。だからmainで例外を全部握りつぶすようなことはすべきではない。
D. 時と場合による。

例外時の挙動とか仕様とか調べてるうちに頭ぐるぐるしてわけわかんなくなってきた

2024/01/11(木) 08:40:16.50

そもそもプログラムが終了してリソースリークするのかな？
メモリー、ファイルハンドル、ソケット、ミューテックスなどのリソースはOSが責任持って解放するよね
どのようなリソースがリークしますか？

2024/01/11(木) 08:45:02.51

すべてじゃね？

2024/01/11(木) 08:46:53.81

>>133
すべてじゃね？
それらの選択肢は別に排他的な選択肢じゃないかと

2024/01/11(木) 09:02:22.25

OS管理なリソースはアプリの終了なんか知らないってのもあるからなぁ
得にドライバ関連とかな

2024/01/11(木) 15:30:41.76

>>136
あれ、少なくともAとCは排他的だと思うんだけど
全部の選択肢を選ぶとすると具体的にはどうなるのかな

2024/01/11(木) 20:09:25.46

今どきのOS使ってたらOSリソースはリークしない
まぁプロセスがゾンビになるのはよくあるが

2024/01/11(木) 20:09:51.72

>>137
しったかすんな

2024/01/11(木) 20:12:29.21

そもそもアプリ的にデータの不整合とか出るから論外だろう
ファイルやなんかの外部データ使わないなら関係ないだろうけど

2024/01/11(木) 20:12:30.15

よくあるのは異常終了時にファイルをフラッシュしておきたいとかだろ
汎用的にこれを実現するのは結構むずい

2024/01/11(木) 20:14:10.04

あとコアダンプの観点では例外飛ばさずに即死したほうがいい

2024/01/11(木) 21:36:53.22

エラーだからって一時ファイル山盛り残して放置しないでください

2024/01/11(木) 22:44:37.94

質問した者だけど

確かに近代的なOSであればリソースの始末はよしなにやってくれるだろうし、「絶対にデストラクタが呼ばれなきゃ困る」って状況でもなければいちいちすべての例外を捕捉する必要はないのかな（毎回ボイラープレートコードみたいに書くのもやだし）

2024/01/12(金) 01:18:38.26

例外処理って、メモリ破壊やファイルシステム破壊みたいな絶望的な状況を想定しなきゃいけないんだよ。
ファイルに何か書き込んだら他のファイルを壊しちゃうかもしれない、みたいな。

だからファイル関連の操作をしていいのは、ファイルシステム周りの無事を確信できるときだけ。
データを上書き保存とかしていいのは、データとファイルシステム両方の無事を確信できるときだけ。
何も確信できないときは、何もせずに墜ちなきゃいけない。

ってことで例外機構はデフォルトで何もせずに異常終了するようになってるんだよ。

2024/01/12(金) 02:09:19.72

理想的には全ての例外はキャッチされるべき。ただ、現実は理想的ではない。
キャッチするのは対処するためなので想定漏れで思ってもなかったような例外が上がってきた (対処が出来てない) ならそれはバグなんだから検証して修正する必要があるわけだし、検証しやすい形で止まったほうがいい。

C++ ではスタックの巻き戻しの途中で例外を送出したときの挙動は未定義なので通例ではデストラクタから例外を投げないように設計される。
つまりデストラクタでの後始末に失敗したらもうそれを (例外機構の仕組みでは) フォローできない。
想定されてない例外が上がってるときに後始末がちゃんとできずにわけのわからない動作を引き起こしたら検証にも支障がある。

2024/01/12(金) 09:48:31.22

じゃあ「投げられうるすべての例外に適切な対処ができるのが理想的だが、対処しきれない例外は投げられっぱなしにする（そしてプログラムを即座に異常終了させる）方が、思考停止でとりあえず捕捉しておくよりはまだマシ」ってことになるのかな
みんなありがとう

2024/01/12(金) 09:51:15.81

いやいや、ちゃんとデバッグしろよ
こんなやつとは絶対一緒に仕事したくない

2024/01/12(金) 09:58:11.40

ライブラリ書くときはライブラリで対処できない例外は握り潰さずに上位で伝搬させろ！と言われてるよね
アプリも同じだと思う
明確に対処すべきことがあるなら例外をキャッチすればいいし
ないならそのままプロセス落としてOSに任せればいいんでない？

2024/01/12(金) 10:01:16.79

投げられっぱなしにするって言い方が不適切だったかな、別に例外のせいでプログラムが実際に異常終了するのを見ても知らんぷりするって意味じゃないよ
実際にプログラムが異常終了したんだったらその都度原因は突き止めて修正するし、そもそもすべての例外に網羅的に対処するのが現実的なときは最初からそうするよ

2024/01/12(金) 10:06:03.47

try {} catch {}

2024/01/12(金) 17:12:14.63

想定される状況には対処しているならどこで想定漏れがあるかはやってみないとわからない。
経験を蓄積し続けるしかしょうがないんだよな。
蓄積がテストケースの形などになっているとより良いと思う。

2024/01/12(金) 17:26:50.90

自分の知らないライブラリの奥底からいつ投げられるかわからない例外なんて対処しようがない
かつスタックアンワインドしたらデバッグの手がかり消えるだけ

2024/01/12(金) 17:44:35.30

setjump()/longjump()

2024/01/13(土) 13:54:58.62

やっぱC++の例外は悪……
構造化例外ならwindbgでコアダンプを開いて!analyze -vで発生源を調べられる（仕組みは知らん
がC++の例外は例外オブジェクトが持ち出した情報が全て……
という印象……

2024/01/13(土) 14:10:21.49

やっぱ例外というﾌﾞﾂは、
アプリケーション領域においてプログラミがいろんなリソースを取り扱うようになった結果、
C言語流に関数の戻り値で起こり得る全てのエラーを網羅してチェックする方法が
現実的でなくなってきたから設けられたﾌﾞﾂなので
>自分の知らないライブラリの奥底からいつ投げられるかわからない例外(>>154
すなわち設計に対して想定外の事象が起きた知らせとしてが飛んでくるというのが基本的かつ本来的な姿

起こりえる全ての例外の処置を書かなければ設計とは言えない主義の人(>>149)は
寧ろ例外の使用をやめてC言語的な書き方で全てのエラーをチェックすべき
（他人様が作ったライブラリが例外を飛ばしてくるのは仕方が無いから全てcatchする

2024/01/13(土) 14:15:12.02

つなみにOSの内部ではすべてのリソースをOSが管理する前提なので例外の出る幕は無い
OSの設計に対して想定外の事象がOS内部で起きるとかあり得ないじゃない
レトロな（しかしメジャーな）OSがC++ではなくC言語で書かれ続けるのはそういう理由

2024/01/13(土) 14:21:37.75

何が返ってくるかわからん (ドキュメント化されていない) なら返却値の形になっていても正しく対処できないのは同じだろ。

2024/01/13(土) 14:37:35.65

例外だとテストしないドキュメントにも書かないというモラルハザードがおきやすいとは言えるだろう
返り値はエラー体系を自分で定義しないといかんからそうはなりにくい
まぁそれでも失敗を安易にfalseに丸めるどアホは多いけど

2024/01/13(土) 15:22:27.34

>>157
>すなわち設計に対して想定外の事象が起きた知らせとしてが飛んでくるというのが基本的かつ本来的な姿

それ一般にはリリース後に起きちゃいけないことでは。プロダクトにもよるが防ぐ努力は必要だと思うがね。

2024/01/14(日) 13:01:30.73

>>138
全選択肢を同時に選ぶって意味に捉えられちゃったかな？
そうじゃなくて、その選択肢自体が同時に適用すべきレベルのものじゃないと思うの

例外をキャッチするって決めたなら、そこには目的があるよね？
設計手順としては目的を決めてから例外を使おうって判断になるわけ

その目的次第だよね？っていうのがD
目的がリソースリーク防止ならA
Aのような目的を達成するために、目的範囲内でB
デバッグ目的ならC

製品等で客の目に見せたくないなどの営業目的があるならCはダメで、のべつまくなしBというのもあるかもしれない

2024/01/14(日) 13:06:09.91

大きな目で全工程トータルを考えると全部の選択肢を適用する必要があるし、適用のしどころが違うと思うってのが>>136の真意でした

2024/01/14(日) 13:12:37.16

>>148
これが正しいかどうかはおいといて、人命に関わらないなら、自分はその考え方に賛成！

完璧にデバッグしろというのは自動車と医療機器など人命にかかわるものだね
重要度に応じて工数のかけ方が変わってくるので、すべてのソフトウエアで一概にこうしなさいとは言えないかな

そういう意味ではD

2024/01/14(日) 15:16:56.65

>>162
ああ、なるほどね
分かりやすくありがとう、助かりました

2024/01/15(月) 08:10:14.00

人命にかかわらない場合であっても、末端の関数が投げる例外の種類を見落としただけでプログラム全体が
いきなり落ちるのは勘弁してほしいし、それを防ぐために全部の関数が投げる例外の種類を全部把握するというのも
無理ゲーに近い。
なので適当なレイヤーごとにざっくり std::exception をキャッチする造りにしてるな。例外の種類で選択したりはしない。

2024/01/15(月) 11:54:06.38

キャッチしてその後どうすんの？

2024/01/15(月) 18:12:26.71

何するか思い付かないならPG辞めろ
貴様には向いてない

2024/01/15(月) 18:20:04.00

>>167
そのtryブロックの処理が失敗したものとして処理を続ける。

2024/01/15(月) 18:42:14.36

テストケース爆増じゃん

2024/01/15(月) 19:20:39.72

なんで爆増？

2024/01/15(月) 20:40:13.04

その失敗する処理の具体例言ってみて

2024/01/15(月) 22:10:56.13

んでテストケース爆増の話は？処理の具体例次第で話が変わったりするとか？

2024/01/15(月) 22:45:20.95

依存関係のあるものに影響あるのは当たり前
原因不明の例外起こっても突き進むんだったら擬似的にそのケース作ってテストするわな普通は
出し渋るなら別にださなくていいよ
参考にならなさそうだし

2024/01/15(月) 23:24:57.00

それはいったい何のテストなんだろう。原因不明の例外を首尾よくキャッチできるかどうかテストしろと言っているんだろうか。
そもそもそういう例外を想定するなら、スルーして影響範囲が広がる方がテストは厄介になると思うがなあ。

2024/01/15(月) 23:36:35.23

たとえば業務用のラベルプリンターでAPIが提供されてるとか
とりあえず try ～ catch して「印刷中に不明なエラーが発生しました」みたいなまとめかたはあるかなー

2024/01/23(火) 17:00:13.54

すみません。質問させて下さい。次のコードがMinGW-w64 g++ v13.2では --itrでエラーになります。わからないのはVisual studio 2022およびVisual StudioがサポートするClang LLVMでは通って正しく
実行しているように見えます。--itrの仕様がないのはMinGW-w64 g++v13.2が正しいのでしょうか？それともVisual Studioが正しいのでしょうか？

#include <iostream>
#include <unordered_set>
using namespace std;

int main()
{
unordered_set<int> us = { 1,2,3,4,5,6 };

for(auto itr = begin(us); itr != end(us); ++itr) cout << *itr << endl;

auto itr = us.begin();
++itr; ++itr;
cout << *itr << endl;

--itr;
cout << *itr << endl;

cin.get();
return 0;
}

MinGW-w64 g++ v13.2のエラー
// error: no match for 'operator--' (operand type is 'std::__detail::_Node_iterator<int, true, false>')

2024/01/23(火) 17:23:45.88

>>177
unordered_set は forward iterator をサポートしているという規定がある。
https://timsong-cpp.github.io/cppwp/n3337/unord.set.overview#1
forward iterator は進めることは出来ても戻ることはできない。
この場合は operator-- がないのが正しい。

拡張してより高機能なライブラリを提供しても仕様に反するってわけではないけど
マイクロソフトのドキュメントでも特に拡張しているという文面は見当たらないから
あんまりあてにしないほうが良さそうには思う。
https://learn.microsoft.com/en-us/cpp/standard-library/unordered-set-class?view=msvc-170#iterator

2024/01/23(火) 17:34:44.31

おお、ありがとうございます。

2024/01/28(日) 11:36:45.25

>>173
横やが関数foo()で1つの例外が発生したらその時点のfoo()呼び出しに至る10個かそこらの関数が中断されるわけや
すなわち関数bar()が
　　処理A→B→C→D→return
の順で処理が進むことを気体しているところに、Bで呼び出している関数baz()がfoo()を呼び出している結果、foo()で例外を生じると
　　処理A→B→return
という処理順に変更になる。こうなっても大丈夫なようにtry { 処理B } catch ((fooが投げる例外)& e) { (eに対する適切な処置) } を書かねばならず、
これが実は潜在的には処理A、B、C、Dのどこでも起き得るから厳密なことを言えば全てについて書かねばならず、
それがfoo()呼び出しに至る10個かそこらの関数それぞれについて行われねばならない。
検証もそんだけ組み合わせが増える。

2024/01/28(日) 11:40:58.52

というわけでそんなの現実には不可能なので、現実的な処置としては
・ライブラリ製作者はなんか都合が悪い事が起きたら何でも呼び出し元に返す。
　第1選択としてはエラーステータスを返すことを検討し、それではコードが煩雑になりすぎる場合は例外を投げて異常を知らせる
・ライブラリを使う人はライブラリが例外を投げない条件で使うことを心掛け、自前のコード内でtry { } catch() { }を極力しない
という処置になるわ
けや

2024/01/28(日) 12:02:32.93

catchしようがしまいが、例外が起きて処理A→B→return となるのは同じだと思うが。
その場合の検証が必要だというならどっちも必要だろ。

2024/01/28(日) 12:13:11.85

>>182
>catchしようがしまいが、例外が起きて処理A→B→return となるのは同じだと思うが。
それは問題の認識がおかいし
例えば以下のコードにおいて、スレッドのゾンビを生じさせないためにはfuncB()をtry { } catch () { } は必須になる。
　void bar() {
　　funcA();　　// スレッドxを起動
　　funcB();　　// 中でbaz() → foo()の呼び出し
　　funcC();　　// スレッドxに停止シグナル発酵
　　funcD();　　// スレッドxの終了待ち
　　return;
}
このように一般に例外が飛んでくる関数にはcatchするかしないかの選択権など無い
例外安全なオブジェクト「だけ」で事が済んでいない限り、例外を受けると決めた時点でcatchせねばならない

一方、例外を生じないライブラリの使い方（関数の呼び出し方）を心掛けるかどうか。これなら選択肢がある

2024/01/28(日) 12:14:54.75

訂正orz
誤：例外安全なオブジェクト「だけ」で事が済んでいない限り、例外を受けると決めた時点でcatchせねばならない
正：例外安全なオブジェクト「だけ」で事が済んでいない限り、例外が飛んでくる想定であるならばcatchせねばならない

2024/01/28(日) 12:19:26.10

>>183
それはfuncB()に失敗の可能性がある時に必ず必要な話だろ？例外どうこうじゃないじゃん
funcB()が例外を投げずに古き良きintのエラーコードを戻り値で返す場合は何かが変わるの？
まさか「funcBの戻り値をガン無視すればfuncCもfuncDも実行されてくれるから完璧！だから例外はクソ！」っていうゴミカスみたいな主張をしたいわけじゃないよね？

2024/01/28(日) 12:28:00.13

>>183
それはcatchが必要かどうかの話だろ。
catchしたらテストケースが増えるかどうかという話とはなんも関係がない。

2024/01/28(日) 15:40:48.23

そもそも未知の例外飛んできた時点でそれを通したライブラリの例外安全性が守られてるか怪しいと考えるべき

2024/01/28(日) 17:01:39.99

例外安全性を守るのに例外の種類やそれが既知か未知かは関係ないだろうが、
仕様に明記した例外以外は堰き止めるのが正解だろうなあ。

◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) · 2024/01/28(日) 20:27:29.75

思い立って結城さんのデザパタ(古いjava で記述）を総称型（テンプレート）もちゃんと使ってC++ に書き直しているけれども、
new/delete からptr::shared_ptr に書きなおすと、もう構造がわかりにくくなってしまってどうしようもない
デザパタ＝抽象クラスプログラミングは C++ ではオワコンなの？
Visitor パターン
new/delete: https://ideone.com/6d43LO スッキリ書けてきもちいい
std::shared_ptr: https://ideone.com/oYzkxh 恐ろしい宣言の連発

>std::shared_ptr<Iterator<std::shared_ptr<Entry>>> iterator() { return std::make_shared<VectorIterator<std::shared_ptr<Entry>>>(v); }

なんかもう書いてても意味不明
CONSTRUCTOR(CONSTRUCTOR *p) とかコピコン以外にもみたことのないコンストラクタが要求されるし

2024/01/28(日) 20:53:25.29

>>189
スマートポインタを使わないバージョンも C++ 的にはすっきりしてない。
動的多態の必要が必要ないのに持つべきメンバ関数を強制するためだけに抽象クラスを使っていて不恰好に見える。
コンセプトの導入がだいぶん後回しになった C++ の問題でもあるんだが……。
設計理念が妥当かどうかはともかくとして、元が Java なら直訳めいた C++ への置き換えがすっきりと書けるはずがない。

2024/01/28(日) 21:08:52.58

ざっと見た感じだと抽象クラスとして必要なのは Entry だけかな。
ジェネリックラムダが visitor パターンで使いやすいのでそういうのが使いやすいように配慮するといいかも。
std::visit が C++ での visitor パターンのお手本だよ。

2024/01/28(日) 22:46:18.85

>>189
usingなりtypedefでエイリアス作れば?
using Entry_Ptr = std::shared_ptr<Entry>;

**デフォルトの名無しさん** (JP 0Hbd-DQL8) · 2024/01/28(日) 23:17:29.01

面白そうだからちょっと書いてみた。大きな変更点はこんな感じ。

・accept が受け取るのは単に Visitor の参照でいい。ここで shared_ptr を使う必要はない。
・Visitor が受け取るのも File や Directory の参照でいい。
・SizeVisitor もいらない。File と Directory はともに Entry の子クラスとして getSize() を実装してるんだから、無理に visitor パターンを使わなくても単に getSize() を呼べばいいだけ。
・iterator() が返すのも VectorIterator の shared_ptr ではなく、単に VectorIterator を返せばいい。

全体的に使う必要がない場面で shared_ptr を使ってるのが目立ったと思う。

https://wandbox.org/permlink/ZBKbF5iMVpb7Looi

だいぶすっきりしたんじゃない？

2024/01/28(日) 23:52:27.85

なんかもうポインタをいじるのが面倒になったので値としてやりとりしていいやという気持ちと
標準ライブラリを積極的に活用することにしたらこうなった。
https://wandbox.org/permlink/BQCNjfdJRKWAR3dg

◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) · 2024/01/29(月) 04:35:04.36

>>193
拝読させていただきました。なるほど、関係性を示すポインタ＝参照なら std::shared_ptr でくるむ必要ガない、というわけですか。
>>194
拝読させていただきました。Entry を値で持つのはいやだなあ。　dectype の使い方を学ばせていただきました。

◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) · 2024/01/29(月) 05:00:34.95

>>194
std::size_t()
あたりから読めていません。operator() をどう使っているのでしょうか？

2024/01/29(月) 12:08:36.13

スマートポインタを使うにしても std::shared_ptr って必要？
この場合は std::unique_ptr でよくない？
https://wandbox.org/permlink/dMolraFpQHKzYtF3

設計思想によるけどファイルシステムを表現するという前提だと
ひとつのルートディレクトリに連なる全てのエントリは実質的に一体のデータ構造なので
ルートディレクトリエントリの寿命が尽きれば全て解体ってことにしたほうが簡単でいいと思う。

ハードリンクの表現とかも考えるなら事情が変わってくることもあるだろうけど……。

2024/01/29(月) 21:21:12.23

>>189 c++
https://ideone.com/p3li2Y
・https://ideone.com/oYzkxh を元に若干の整理を行った

・他の人と同様shared_ptrを削除
　値で持てるところは単に値で持つほうがC++っぽいと思う
　ただ「Entry を値で持つのはいやだなあ」とのことなので部分的に残してる
　Javaの参照型変数をshared_ptrに置き換えようとして困るのは
　size_t File::accept(std::shared_ptr<Visitor> v) { return v->visit(std::make_shared<File>(this)); }
　ここがJavaだと単にvisit(this)で済むからスッキリするんだけど
　しかもこれmake_shared(this)だと多重開放するよね？？

>>189 c++
https://ideone.com/2uUpwH
・https://ideone.com/p3li2Y を元に若干の整理を行った

・make_shared<File>(this)の多重開放？を修正
　std::enable_shared_from_thisを使ってJavaの参照型変数っぽい使用感を得た。

・struct this_is_private {};
　これは単にコンストラクタを実質的にprivateにするためだけに使ってる
　https://en.cppreference.com/w/cpp/memory/enable_shared_from_this
　https://stackoverflow.com/questions/8147027/how-do-i-call-stdmake-shared-on-a-class-with-only-protected-or-private-const
　このへん参照されたし

**デフォルトの名無しさん** (JP 0Hbd-IHfd) · 2024/02/03(土) 04:38:02.47

https://wandbox.org/permlink/LEl2MT7OdGIlVKC4

なんか「子クラスのコンストラクタに親クラスのオブジェクトを渡して子クラスのメンバを初期化する」（？）みたいなことができちゃってるんだけど、これってどういう仕様でこうなってんの？
Wandbox上だとC++2aではコンパイルできてC++17ではコンパイルできなかったからcpprefjpのC++20の機能の一覧も見てみたけどそれらしいものはなかったし

2024/02/03(土) 09:26:19.03

>>199
designated initializer も C++20 からの機能なんだけど……それは脇に置く。

この場合は集成体初期化に該当する。
C++17 から基底の初期化も集成体初期化で扱えるので
child c{p};
というように初期化出来ていた。

更に C++20 では集成体初期化を丸括弧で書いても良いことになったので
child c(p);
とすることが許されるようになった。