[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
120: (ﾜｯﾁｮｲ e95f-pFp4) 2024/01/03(水)23:34 ID:w4EAqTeZ0(1) AAS
>>112
とりあえず書いてみたけどどうですかね？
template<std::size_t buf_size>
struct A {
private:
struct base_ {
virtual ~base_() {};
省21
121(1): (ﾜｯﾁｮｲ 9901-r6/T) 2024/01/04(木)00:44 ID:/FDyuY0i0(1/3) AAS
decltype(src.*p_)ってbase_なのでダメだろう
122(1): (ﾜｯﾁｮｲ e1f0-JZT3) 2024/01/04(木)00:58 ID:ECF9R1Fj0(1/2) AAS
ていうか、decltypeで型指定してるだけだからコピーもなにもされてないぞソレ
123: (ﾜｯﾁｮｲ 0644-M+UX) 2024/01/04(木)02:28 ID:oZapr/U70(1/2) AAS
std::anyのコードでも読んだほうが早い
124(1): (ﾜｯﾁｮｲ 9901-r6/T) 2024/01/04(木)09:11 ID:/FDyuY0i0(2/3) AAS
A::base_に以下を足してA::derived_で実装し
Aのコピーコンストラクタから呼べば?
virtual base_ *clone (void *p) = 0;
125: (ﾜｯﾁｮｲ 6564-QK8A) 2024/01/04(木)13:26 ID:1KQpMTCj0(1) AAS
void*って、ポインターの先のサイズ未知だよなぁ
126: (ﾜｯﾁｮｲ e95f-pFp4) 2024/01/04(木)17:16 ID:ACseOt7T0(1/2) AAS
derived_かそのメンバf_の型を知るにはRTTIしかないのですかね？
>>121
decltypeだと派生先の型はわからないのか
>>122
実体のコピーの処理が抜けてました…
127(2): (ﾜｯﾁｮｲ e95f-pFp4) 2024/01/04(木)21:53 ID:ACseOt7T0(2/2) AAS
>>124
こんな感じです？
struct base_ {
virtual base_* clone (void *p) = 0;
virtual ~base_() {};
};
template <typename F>
省10
128: (ﾜｯﾁｮｲ e1f0-JZT3) 2024/01/04(木)22:19 ID:ECF9R1Fj0(2/2) AAS
derived_(F f) ←この時点でムダなコピーが１度発生していることには気付いてる？
129: (ﾜｯﾁｮｲ 9901-r6/T) 2024/01/04(木)22:21 ID:/FDyuY0i0(3/3) AAS
>>127
書き込む前にコンパイルしなよ
130: (ﾜｯﾁｮｲ 651a-R/a6) 2024/01/04(木)22:41 ID:Dv09vJ7A0(1) AAS
バッファの中にオブジェクトを作れたら、それで何をしたいのかが気になる
131: (ﾜｯﾁｮｲ 0644-M+UX) 2024/01/04(木)23:21 ID:oZapr/U70(2/2) AAS
>>127
cloneの中ってplacement newでcopy constructorを呼ぼうとしてるんだよな？
いちおうあってるけどundefined behaviorまみれ
132: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 823e-OTTg) 2024/01/04(木)23:35 ID:td6kYpbC0(1) AAS
たぶんやりたいことは std::allocator_traits::construct なのかな
133(1): (ﾜｯﾁｮｲ 7f7c-JApz) 2024/01/11(木)04:45 ID:wlSOhq+Y0(1/2) AAS
例外って全部mainで捕捉すべきかな？
調べてみたら例外が捕捉されずにプログラムが終了する場合スタックアンワインドが起こるかは実装定義みたいなんだけど、それじゃグローバルなオブジェクトのデストラクタが呼ばれないんじゃないかって思って試してみたのよ。
外部ﾘﾝｸ:ideone.com
やっぱりデストラクタは呼ばれなかったからリソースリークが起こりうるんじゃないかと思うんだけど、例外に対してはどういう態度でいるべきかな？
A. リソースリークはまずい。だから例外は全部捕捉するべき。
B. 例外はロジック上捕捉する必要があるものだけ捕捉して、それ以外はほっといていい。
C. 例外が捕捉されなければstd::abortが呼ばれるので、コアダンプなりで色々調べることもできる。だからmainで例外を全部握りつぶすようなことはすべきではない。
省2
134: (ﾜｯﾁｮｲ dff7-1VUN) 2024/01/11(木)08:40 ID:8oRrkiTZ0(1) AAS
そもそもプログラムが終了してリソースリークするのかな？
メモリー、ファイルハンドル、ソケット、ミューテックスなどのリソースはOSが責任持って解放するよね
どのようなリソースがリークしますか？
135: (ﾜｯﾁｮｲ 7f01-2R+Q) 2024/01/11(木)08:45 ID:ETJgFBFV0(1/2) AAS
すべてじゃね？
136(2): (ﾜｯﾁｮｲ 7f01-2R+Q) 2024/01/11(木)08:46 ID:ETJgFBFV0(2/2) AAS
>>133
すべてじゃね？
それらの選択肢は別に排他的な選択肢じゃないかと
137(1): (ﾜｯﾁｮｲ 7f3a-NF1f) 2024/01/11(木)09:02 ID:dA95iQ6m0(1) AAS
OS管理なリソースはアプリの終了なんか知らないってのもあるからなぁ
得にドライバ関連とかな
138(1): (ﾜｯﾁｮｲ dfab-acFs) 2024/01/11(木)15:30 ID:hAXa3uBd0(1) AAS
>>136
あれ、少なくともAとCは排他的だと思うんだけど
全部の選択肢を選ぶとすると具体的にはどうなるのかな
139: (ﾜｯﾁｮｲ ff11-Nf4k) 2024/01/11(木)20:09 ID:AWAYnmwT0(1/4) AAS
今どきのOS使ってたらOSリソースはリークしない
まぁプロセスがゾンビになるのはよくあるが
140: (ﾜｯﾁｮｲ ff11-Nf4k) 2024/01/11(木)20:09 ID:AWAYnmwT0(2/4) AAS
>>137
しったかすんな
141: (ﾜﾝﾄﾝｷﾝ MMdf-7Pe6) 2024/01/11(木)20:12 ID:h5T3Zf1WM(1) AAS
そもそもアプリ的にデータの不整合とか出るから論外だろう
ファイルやなんかの外部データ使わないなら関係ないだろうけど
142: (ﾜｯﾁｮｲ ff11-Nf4k) 2024/01/11(木)20:12 ID:AWAYnmwT0(3/4) AAS
よくあるのは異常終了時にファイルをフラッシュしておきたいとかだろ
汎用的にこれを実現するのは結構むずい
143: (ﾜｯﾁｮｲ ff11-Nf4k) 2024/01/11(木)20:14 ID:AWAYnmwT0(4/4) AAS
あとコアダンプの観点では例外飛ばさずに即死したほうがいい
144: (ﾜｯﾁｮｲ df5a-XokC) 2024/01/11(木)21:36 ID:40hQdtQK0(1) AAS
エラーだからって一時ファイル山盛り残して放置しないでください
145: (ﾜｯﾁｮｲ 7f7c-acFs) 2024/01/11(木)22:44 ID:wlSOhq+Y0(2/2) AAS
質問した者だけど
確かに近代的なOSであればリソースの始末はよしなにやってくれるだろうし、「絶対にデストラクタが呼ばれなきゃ困る」って状況でもなければいちいちすべての例外を捕捉する必要はないのかな（毎回ボイラープレートコードみたいに書くのもやだし）
146: (ｽｯｯﾌﾟ Sd9f-d+nK) 2024/01/12(金)01:18 ID:P05ikaaEd(1) AAS
例外処理って、メモリ破壊やファイルシステム破壊みたいな絶望的な状況を想定しなきゃいけないんだよ。
ファイルに何か書き込んだら他のファイルを壊しちゃうかもしれない、みたいな。
だからファイル関連の操作をしていいのは、ファイルシステム周りの無事を確信できるときだけ。
データを上書き保存とかしていいのは、データとファイルシステム両方の無事を確信できるときだけ。
何も確信できないときは、何もせずに墜ちなきゃいけない。
ってことで例外機構はデフォルトで何もせずに異常終了するようになってるんだよ。
147: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7f3e-Cx9t) 2024/01/12(金)02:09 ID:Z8/dVhwe0(1/2) AAS
理想的には全ての例外はキャッチされるべき。 ただ、現実は理想的ではない。
キャッチするのは対処するためなので想定漏れで思ってもなかったような例外が上がってきた (対処が出来てない) ならそれはバグなんだから検証して修正する必要があるわけだし、検証しやすい形で止まったほうがいい。
C++ ではスタックの巻き戻しの途中で例外を送出したときの挙動は未定義なので通例ではデストラクタから例外を投げないように設計される。
つまりデストラクタでの後始末に失敗したらもうそれを (例外機構の仕組みでは) フォローできない。
想定されてない例外が上がってるときに後始末がちゃんとできずにわけのわからない動作を引き起こしたら検証にも支障がある。
148(1): (ﾜｯﾁｮｲ 7f7c-acFs) 2024/01/12(金)09:48 ID:1nCpSyqU0(1/2) AAS
じゃあ「投げられうるすべての例外に適切な対処ができるのが理想的だが、対処しきれない例外は投げられっぱなしにする（そしてプログラムを即座に異常終了させる）方が、思考停止でとりあえず捕捉しておくよりはまだマシ」ってことになるのかな
みんなありがとう
149(1): (ﾜﾝﾄﾝｷﾝ MMdf-7Pe6) 2024/01/12(金)09:51 ID:Vmsz+UsIM(1) AAS
いやいや、ちゃんとデバッグしろよ
こんなやつとは絶対一緒に仕事したくない
150: (ﾜｯﾁｮｲ 5f4e-1VUN) 2024/01/12(金)09:58 ID:yLdIK4jH0(1) AAS
ライブラリ書くときはライブラリで対処できない例外は握り潰さずに上位で伝搬させろ！と言われてるよね
アプリも同じだと思う
明確に対処すべきことがあるなら例外をキャッチすればいいし
ないならそのままプロセス落としてOSに任せればいいんでない？
151: (ﾜｯﾁｮｲ 7f7c-acFs) 2024/01/12(金)10:01 ID:1nCpSyqU0(2/2) AAS
投げられっぱなしにするって言い方が不適切だったかな、別に例外のせいでプログラムが実際に異常終了するのを見ても知らんぷりするって意味じゃないよ
実際にプログラムが異常終了したんだったらその都度原因は突き止めて修正するし、そもそもすべての例外に網羅的に対処するのが現実的なときは最初からそうするよ
152: (ﾜｯﾁｮｲ df09-dvWY) 2024/01/12(金)10:06 ID:Umd8uX9b0(1) AAS
try {} catch {}
153: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7f3e-TQnC) 2024/01/12(金)17:12 ID:Z8/dVhwe0(2/2) AAS
想定される状況には対処しているならどこで想定漏れがあるかはやってみないとわからない。
経験を蓄積し続けるしかしょうがないんだよな。
蓄積がテストケースの形などになっているとより良いと思う。
154(1): (ﾌﾞｰｲﾓ MM0f-Nf4k) 2024/01/12(金)17:26 ID:059LeD4FM(1) AAS
自分の知らないライブラリの奥底からいつ投げられるかわからない例外なんて対処しようがない
かつスタックアンワインドしたらデバッグの手がかり消えるだけ
155: (ﾌﾞｰｲﾓ MM9f-2j6O) 2024/01/12(金)17:44 ID:bUlwQWI8M(1) AAS
setjump()/longjump()
156: (ﾜｯﾁｮｲ df63-+bVA) 2024/01/13(土)13:54 ID:rNqWj2dY0(1/3) AAS
やっぱC++の例外は悪……
構造化例外ならwindbgでコアダンプを開いて!analyze -vで発生源を調べられる（仕組みは知らん
がC++の例外は例外オブジェクトが持ち出した情報が全て……
という印象……
157(1): (ﾜｯﾁｮｲ df63-+bVA) 2024/01/13(土)14:10 ID:rNqWj2dY0(2/3) AAS
やっぱ例外というﾌﾞﾂは、
アプリケーション領域においてプログラミがいろんなリソースを取り扱うようになった結果、
C言語流に関数の戻り値で起こり得る全てのエラーを網羅してチェックする方法が
現実的でなくなってきたから設けられたﾌﾞﾂなので
>自分の知らないライブラリの奥底からいつ投げられるかわからない例外(>>154
すなわち設計に対して想定外の事象が起きた知らせとしてが飛んでくるというのが基本的かつ本来的な姿
起こりえる全ての例外の処置を書かなければ設計とは言えない主義の人(>>149)は
省2
158: (ﾜｯﾁｮｲ df63-+bVA) 2024/01/13(土)14:15 ID:rNqWj2dY0(3/3) AAS
つなみにOSの内部ではすべてのリソースをOSが管理する前提なので例外の出る幕は無い
OSの設計に対して想定外の事象がOS内部で起きるとかあり得ないじゃない
レトロな（しかしメジャーな）OSがC++ではなくC言語で書かれ続けるのはそういう理由
159: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7f3e-TQnC) 2024/01/13(土)14:21 ID:3bve4IFf0(1) AAS
何が返ってくるかわからん (ドキュメント化されていない) なら返却値の形になっていても正しく対処できないのは同じだろ。
160: (ﾜｯﾁｮｲ ff18-Nf4k) 2024/01/13(土)14:37 ID:b/trpwza0(1) AAS
例外だとテストしないドキュメントにも書かないというモラルハザードがおきやすいとは言えるだろう
返り値はエラー体系を自分で定義しないといかんからそうはなりにくい
まぁそれでも失敗を安易にfalseに丸めるどアホは多いけど
161: (ﾜｯﾁｮｲ ffcf-mfjK) 2024/01/13(土)15:22 ID:o+zGF69d0(1) AAS
>>157
>すなわち設計に対して想定外の事象が起きた知らせとしてが飛んでくるというのが基本的かつ本来的な姿
それ一般にはリリース後に起きちゃいけないことでは。プロダクトにもよるが防ぐ努力は必要だと思うがね。
162(1): (ﾜｯﾁｮｲ 7291-Qz6p) 2024/01/14(日)13:01 ID:H7tsxQrq0(1/3) AAS
>>138
全選択肢を同時に選ぶって意味に捉えられちゃったかな？
そうじゃなくて、その選択肢自体が同時に適用すべきレベルのものじゃないと思うの
例外をキャッチするって決めたなら、そこには目的があるよね？
設計手順としては目的を決めてから例外を使おうって判断になるわけ
その目的次第だよね？っていうのがD
目的がリソースリーク防止ならA
省3
163: (ﾜｯﾁｮｲ 7291-Qz6p) 2024/01/14(日)13:06 ID:H7tsxQrq0(2/3) AAS
大きな目で全工程トータルを考えると全部の選択肢を適用する必要があるし、適用のしどころが違うと思うってのが>>136の真意でした
164: (ﾜｯﾁｮｲ 7291-Qz6p) 2024/01/14(日)13:12 ID:H7tsxQrq0(3/3) AAS
>>148
これが正しいかどうかはおいといて、人命に関わらないなら、自分はその考え方に賛成！
完璧にデバッグしろというのは自動車と医療機器など人命にかかわるものだね
重要度に応じて工数のかけ方が変わってくるので、すべてのソフトウエアで一概にこうしなさいとは言えないかな
そういう意味ではD
165(1): (ﾜｯﾁｮｲ 4d34-7Ntv) 2024/01/14(日)15:16 ID:by9QQMRz0(1) AAS
>>162
ああ、なるほどね
分かりやすくありがとう、助かりました
166: (ﾜｯﾁｮｲ 6ecf-CdjJ) 2024/01/15(月)08:10 ID:Y8oMeLNI0(1/5) AAS
人命にかかわらない場合であっても、末端の関数が投げる例外の種類を見落としただけでプログラム全体が
いきなり落ちるのは勘弁してほしいし、それを防ぐために全部の関数が投げる例外の種類を全部把握するというのも
無理ゲーに近い。
なので適当なレイヤーごとにざっくり std::exception をキャッチする造りにしてるな。例外の種類で選択したりはしない。
167(1): (ﾌﾞｰｲﾓ MM22-7+/r) 2024/01/15(月)11:54 ID:0QYW1wwzM(1) AAS
キャッチしてその後どうすんの？
168: (ﾜｯﾁｮｲ 41f0-u9am) 2024/01/15(月)18:12 ID:FtZTeDOW0(1) AAS
何するか思い付かないならPG辞めろ
貴様には向いてない
169(2): (ﾜｯﾁｮｲ 6ecf-CdjJ) 2024/01/15(月)18:20 ID:Y8oMeLNI0(2/5) AAS
>>167
そのtryブロックの処理が失敗したものとして処理を続ける。
170: (ﾜｯﾁｮｲ 46ea-7+/r) 2024/01/15(月)18:42 ID:Lgn9c/GO0(1/3) AAS
テストケース爆増じゃん
171: (ﾜｯﾁｮｲ 6ecf-CdjJ) 2024/01/15(月)19:20 ID:Y8oMeLNI0(3/5) AAS
なんで爆増？
172: (ﾜｯﾁｮｲ 46ea-7+/r) 2024/01/15(月)20:40 ID:Lgn9c/GO0(2/3) AAS
その失敗する処理の具体例言ってみて
173(1): (ﾜｯﾁｮｲ 6ecf-CdjJ) 2024/01/15(月)22:10 ID:Y8oMeLNI0(4/5) AAS
んでテストケース爆増の話は？処理の具体例次第で話が変わったりするとか？
174: (ﾜｯﾁｮｲ 46ea-7+/r) 2024/01/15(月)22:45 ID:Lgn9c/GO0(3/3) AAS
依存関係のあるものに影響あるのは当たり前
原因不明の例外起こっても突き進むんだったら擬似的にそのケース作ってテストするわな普通は
出し渋るなら別にださなくていいよ
参考にならなさそうだし
175: (ﾜｯﾁｮｲ 6ecf-CdjJ) 2024/01/15(月)23:24 ID:Y8oMeLNI0(5/5) AAS
それはいったい何のテストなんだろう。原因不明の例外を首尾よくキャッチできるかどうかテストしろと言っているんだろうか。
そもそもそういう例外を想定するなら、スルーして影響範囲が広がる方がテストは厄介になると思うがなあ。
176: (ﾜｯﾁｮｲ 11fb-5Qxc) 2024/01/15(月)23:36 ID:rchiNbsm0(1) AAS
たとえば業務用のラベルプリンターでAPIが提供されてるとか
とりあえず try ～ catch して「印刷中に不明なエラーが発生しました」みたいなまとめかたはあるかなー
177(1): (ﾜｯﾁｮｲ 2778-EFyZ) 2024/01/23(火)17:00 ID:kD0da0AW0(1/2) AAS
すみません。質問させて下さい。次のコードが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()
{
省12
178: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-G0Zh) 2024/01/23(火)17:23 ID:MIeJSKFF0(1) AAS
>>177
unordered_set は forward iterator をサポートしているという規定がある。
外部ﾘﾝｸ:timsong-cpp.github.io
forward iterator は進めることは出来ても戻ることはできない。
この場合は operator-- がないのが正しい。
拡張してより高機能なライブラリを提供しても仕様に反するってわけではないけど
マイクロソフトのドキュメントでも特に拡張しているという文面は見当たらないから
省2
179: (ﾜｯﾁｮｲ 2778-EFyZ) 2024/01/23(火)17:34 ID:kD0da0AW0(2/2) AAS
おお、ありがとうございます。
180: (ﾜｯﾁｮｲ 6d63-H5uA) 2024/01/28(日)11:36 ID:W0uCnQb30(1/4) AAS
>>173
横やが関数foo()で1つの例外が発生したらその時点のfoo()呼び出しに至る10個かそこらの関数が中断されるわけや
すなわち関数bar()が
処理A→B→C→D→return
の順で処理が進むことを気体しているところに、Bで呼び出している関数baz()がfoo()を呼び出している結果、foo()で例外を生じると
処理A→B→return
という処理順に変更になる。こうなっても大丈夫なようにtry { 処理B } catch ((fooが投げる例外)& e) { (eに対する適切な処置) } を書かねばならず、
省3
181: (ﾜｯﾁｮｲ 6d63-H5uA) 2024/01/28(日)11:40 ID:W0uCnQb30(2/4) AAS
というわけでそんなの現実には不可能なので、現実的な処置としては
・ライブラリ製作者はなんか都合が悪い事が起きたら何でも呼び出し元に返す。
第1選択としてはエラーステータスを返すことを検討し、それではコードが煩雑になりすぎる場合は例外を投げて異常を知らせる
・ライブラリを使う人はライブラリが例外を投げない条件で使うことを心掛け、自前のコード内でtry { } catch() { }を極力しない
という処置になるわ
けや
182(1): (ﾜｯﾁｮｲ 66cf-5eDQ) 2024/01/28(日)12:02 ID:Gsm093HM0(1/3) AAS
catchしようがしまいが、例外が起きて 処理A→B→return となるのは同じだと思うが。
その場合の検証が必要だというならどっちも必要だろ。
183(6): (ﾜｯﾁｮｲ 6d63-H5uA) 2024/01/28(日)12:13 ID:W0uCnQb30(3/4) AAS
>>182
>catchしようがしまいが、例外が起きて 処理A→B→return となるのは同じだと思うが。
それは問題の認識がおかいし
例えば以下のコードにおいて、スレッドのゾンビを生じさせないためにはfuncB()をtry { } catch () { } は必須になる。
void bar() {
funcA(); // スレッドxを起動
funcB(); // 中でbaz() → foo()の呼び出し
省7
184: (ﾜｯﾁｮｲ 6d63-H5uA) 2024/01/28(日)12:14 ID:W0uCnQb30(4/4) AAS
訂正orz
誤：例外安全なオブジェクト「だけ」で事が済んでいない限り、例外を受けると決めた時点でcatchせねばならない
正：例外安全なオブジェクト「だけ」で事が済んでいない限り、例外が飛んでくる想定であるならばcatchせねばならない
185(1): (ﾜｯﾁｮｲ 797c-+np5) 2024/01/28(日)12:19 ID:/bXkl1Cz0(1) AAS
>>183
それはfuncB()に失敗の可能性がある時に必ず必要な話だろ？例外どうこうじゃないじゃん
funcB()が例外を投げずに古き良きintのエラーコードを戻り値で返す場合は何かが変わるの？
まさか「funcBの戻り値をガン無視すればfuncCもfuncDも実行されてくれるから完璧！だから例外はクソ！」っていうゴミカスみたいな主張をしたいわけじゃないよね？
186(1): (ﾜｯﾁｮｲ 66cf-5eDQ) 2024/01/28(日)12:28 ID:Gsm093HM0(2/3) AAS
>>183
それはcatchが必要かどうかの話だろ。
catchしたらテストケースが増えるかどうかという話とはなんも関係がない。
187: (ﾜｯﾁｮｲ 5ef3-qitC) 2024/01/28(日)15:40 ID:JnoCOYDS0(1) AAS
そもそも未知の例外飛んできた時点でそれを通したライブラリの例外安全性が守られてるか怪しいと考えるべき
188(2): (ﾜｯﾁｮｲ 66cf-5eDQ) 2024/01/28(日)17:01 ID:Gsm093HM0(3/3) AAS
例外安全性を守るのに例外の種類やそれが既知か未知かは関係ないだろうが、
仕様に明記した例外以外は堰き止めるのが正解だろうなあ。
189(4): ◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) 2024/01/28(日)20:27 ID:0TnCAHFI0(1) AAS
思い立って結城さんのデザパタ(古いjava で記述）を総称型（テンプレート）もちゃんと使ってC++ に書き直しているけれども、
new/delete からptr::shared_ptr に書きなおすと、もう構造がわかりにくくなってしまってどうしようもない
デザパタ＝抽象クラスプログラミングは C++ ではオワコンなの？
Visitor パターン
new/delete: 外部ﾘﾝｸ:ideone.com スッキリ書けてきもちいい
std::shared_ptr: 外部ﾘﾝｸ:ideone.com 恐ろしい宣言の連発
>std::shared_ptr<Iterator<std::shared_ptr<Entry>>> iterator() { return std::make_shared<VectorIterator<std::shared_ptr<Entry>>>(v); }
省2
190: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 2a3e-vdg+) 2024/01/28(日)20:53 ID:hRRbWEE/0(1/3) AAS
>>189
スマートポインタを使わないバージョンも C++ 的にはすっきりしてない。
動的多態の必要が必要ないのに持つべきメンバ関数を強制するためだけに抽象クラスを使っていて不恰好に見える。
コンセプトの導入がだいぶん後回しになった C++ の問題でもあるんだが……。
設計理念が妥当かどうかはともかくとして、元が Java なら直訳めいた C++ への置き換えがすっきりと書けるはずがない。
191: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 2a3e-vdg+) 2024/01/28(日)21:08 ID:hRRbWEE/0(2/3) AAS
ざっと見た感じだと抽象クラスとして必要なのは Entry だけかな。
ジェネリックラムダが visitor パターンで使いやすいのでそういうのが使いやすいように配慮するといいかも。
std::visit が C++ での visitor パターンのお手本だよ。
192: (ﾜｯﾁｮｲ b501-PlwZ) 2024/01/28(日)22:46 ID:VLKT1lFt0(1) AAS
>>189
usingなりtypedefでエイリアス作れば?
using Entry_Ptr = std::shared_ptr<Entry>;
193(1): (JP 0Hbd-DQL8) 2024/01/28(日)23:17 ID:wkb3ctO/H(1) AAS
面白そうだからちょっと書いてみた。大きな変更点はこんな感じ。
・accept が受け取るのは単に Visitor の参照でいい。ここで shared_ptr を使う必要はない。
・Visitor が受け取るのも File や Directory の参照でいい。
・SizeVisitor もいらない。File と Directory はともに Entry の子クラスとして getSize() を実装してるんだから、無理に visitor パターンを使わなくても単に getSize() を呼べばいいだけ。
・iterator() が返すのも VectorIterator の shared_ptr ではなく、単に VectorIterator を返せばいい。
全体的に使う必要がない場面で shared_ptr を使ってるのが目立ったと思う。
外部ﾘﾝｸ:wandbox.org
省1
194(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 2a3e-MxBP) 2024/01/28(日)23:52 ID:hRRbWEE/0(3/3) AAS
なんかもうポインタをいじるのが面倒になったので値としてやりとりしていいやという気持ちと
標準ライブラリを積極的に活用することにしたらこうなった。
外部ﾘﾝｸ:wandbox.org
195: ◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) 2024/01/29(月)04:35 ID:M6sadnnj0(1/2) AAS
>>193
拝読させていただきました。なるほど、関係性を示すポインタ＝参照なら std::shared_ptr でくるむ必要ガない、というわけですか。
>>194
拝読させていただきました。Entry を値で持つのはいやだなあ。 dectype の使い方を学ばせていただきました。
196: ◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) 2024/01/29(月)05:00 ID:M6sadnnj0(2/2) AAS
>>194
std::size_t()
あたりから読めていません。operator() をどう使っているのでしょうか？
197: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 2a3e-MxBP) 2024/01/29(月)12:08 ID:WXyC0nMC0(1) AAS
スマートポインタを使うにしても std::shared_ptr って必要？
この場合は std::unique_ptr でよくない？
外部ﾘﾝｸ:wandbox.org
設計思想によるけどファイルシステムを表現するという前提だと
ひとつのルートディレクトリに連なる全てのエントリは実質的に一体のデータ構造なので
ルートディレクトリエントリの寿命が尽きれば全て解体ってことにしたほうが簡単でいいと思う。
ハードリンクの表現とかも考えるなら事情が変わってくることもあるだろうけど……。
198(2): (ﾜｯﾁｮｲ bda8-xxv9) 2024/01/29(月)21:21 ID:eAAuxXw40(1) AAS
>>189 c++
外部ﾘﾝｸ:ideone.com
・外部ﾘﾝｸ:ideone.com を元に若干の整理を行った
・他の人と同様shared_ptrを削除
値で持てるところは単に値で持つほうがC++っぽいと思う
ただ「Entry を値で持つのはいやだなあ」とのことなので部分的に残してる
Javaの参照型変数をshared_ptrに置き換えようとして困るのは
省13
199(1): (JP 0Hbd-IHfd) 2024/02/03(土)04:38 ID:bq1KvR69H(1/2) AAS
外部ﾘﾝｸ:wandbox.org
なんか「子クラスのコンストラクタに親クラスのオブジェクトを渡して子クラスのメンバを初期化する」（？）みたいなことができちゃってるんだけど、これってどういう仕様でこうなってんの？
Wandbox上だとC++2aではコンパイルできてC++17ではコンパイルできなかったからcpprefjpのC++20の機能の一覧も見てみたけどそれらしいものはなかったし
200(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-MxBP) 2024/02/03(土)09:26 ID:Sz70frqK0(1/2) AAS
>>199
designated initializer も C++20 からの機能なんだけど……それは脇に置く。
この場合は集成体初期化に該当する。
C++17 から基底の初期化も集成体初期化で扱えるので
child c{p};
というように初期化出来ていた。
更に C++20 では集成体初期化を丸括弧で書いても良いことになったので
省2
上下前次1-新書関写板覧索設栞歴
あと 802 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.040s