[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
747: (ｽﾌｯ Sd9a-JU6R) 03/15(土)17:45 ID:UQwxamXid(1) AAS
[](){}();
748: (ﾜｯﾁｮｲ 1963-BNp6) 03/15(土)22:57 ID:nPJTLBuF0(1) AAS
停止性問題を一般のケースについて解く機械的手続きで有限時間で必ずおわるもの（アルゴリズム）は存在しないが
人間は納期までにプログラムえおデバッグできる……できる……たぶん……
749: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e932-exlI) 03/16(日)09:48 ID:B4wnHsDg0(1) AAS
出来なかったら誰かがどういう形かで責任を取る。
それが社会ってもんだ。
750: (ﾜｯﾁｮｲ d963-lHAu) 03/16(日)11:01 ID:N4spayNe0(1/2) AAS
有限時間内に終わる機械的計算手続きとして存在するかという観点で考えたとき
デバックの不可能なプログラムは存在しないという例の命題は偽な可能性、
もっともこの正確な引用は「バグのないプログラムは存在しないがデバックの不可能なプログラムもまた存在しない」であって全体として矛盾した主張であることは前から指摘されてあるが
751: (ﾜｯﾁｮｲ d963-lHAu) 03/16(日)11:04 ID:N4spayNe0(2/2) AAS
訂正orz、
誤： 有限時間内に終わる機械的計算手続きとして存在するかという観点で考えたとき
正： 任意のプログラムのデバッグと言う手続きが有限時間内に終わる機械的計算手続きとして存在するかという観点で考えたとき
752: (ﾜｯﾁｮｲ 1302-BOwI) [!donguri] 03/17(月)06:41 ID:/+A5sOUu0(1) AAS
ラムダ式に+の話は始めて知った
勉強になった
753: (ｵｯﾍﾟｹ Sr9d-exlI) 03/17(月)09:17 ID:3/T8wXeSr(1) AAS
>>746
それちょっとだけ解説きぼん ぶっちゃけなんとなくで使ってて気持ち悪かった
754: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e932-exlI) 03/17(月)09:55 ID:xz+hBXXy0(1/3) AAS
オーバーロード解決のルールは大雑把には
・候補の中で実引数と完璧に型が一致するものがあればそれが選ばれる。
・完璧な一致がないが暗黙の型変換を適用したら一致するという候補があればそれが選ばれる。
ということになってる。
実際には変換の中にも優先順位がごちゃごちゃあってかなり複雑なんだけど……。
で、組み込みの単項 + が受け取りうる型は何かというと算術型、スコープなし列挙型、またはポインタ型の三つ。
外部ﾘﾝｸ:timsong-cpp.github.io
省4
755(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e932-exlI) 03/17(月)09:58 ID:xz+hBXXy0(2/3) AAS
単項 + の話題がウケたみたいなのでオマケで * の話もしようかな。
単項 * にクロージャを渡した場合は関数の参照になる。
つまり *[](){} としたら型は void(&)() ってことね。
式中に参照が現れたら参照が指す先の型に変換されて、関数指示子が現れたら関数ポインタに変換されるので多くの状況では最終的に関数ポインタになっちゃうんだけど。
756(1): (ｻｻｸｯﾃﾛﾙ Sp9d-H5Hv) 03/17(月)10:46 ID:qCQLpZeYp(1) AAS
要するに副作用って事か
環境によってとかオプティマイズ如何で違った動きになる事は無いのかなぁ
757: (ﾌﾞｰｲﾓ MM33-EPiB) 03/17(月)11:12 ID:ly7jZf+WM(1/2) AAS
ならんだろw
758: (ｻｻｸｯﾃﾛﾙ Sp9d-H5Hv) 03/17(月)11:24 ID:F8F0vPkQp(1) AAS
昔、ARM系の環境で配列とポインタがまるっきり違う扱いになって困ったって事があったんだよなぁ
759: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e932-exlI) 03/17(月)11:44 ID:xz+hBXXy0(3/3) AAS
>>756
これは言語仕様の話なので言語仕様に沿わないことがあるなら単にコンパイラのバグってだけだ。
760(2): (ｽｯﾌﾟ Sd33-pKjK) 03/17(月)13:02 ID:kJ3GyyA+d(1) AAS
「関数の配列」なんてものが存在しないC++で、関数ポインタに合法的な加減算することなんてないはずなのに、その仲間である単項+が効いちゃうのは気持ち悪くはある
761(1): (ﾜｯﾁｮｲ 711b-yxlS) 03/17(月)13:42 ID:EbB+xfjB0(1/2) AAS
関数ポインタをインクリメントしたら次の関数になるとかだったら便利よね
762(1): (ﾌﾞｰｲﾓ MM33-EPiB) 03/17(月)13:56 ID:ly7jZf+WM(2/2) AAS
次ってどこだよ
763: (ﾜｯﾁｮｲ 711b-yxlS) 03/17(月)14:43 ID:EbB+xfjB0(2/2) AAS
関数のアドレス順とか
764: (ｻｻｸｯﾃﾛﾙ Sp9d-H5Hv) 03/17(月)15:28 ID:nF5lR4//p(1) AAS
コード書いた順だろw
765: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 217f-a7BF) 03/17(月)16:50 ID:qL9fWs880(1) AAS
>>760
私もそう思う。
いつからこうなのか探ってみたら1984年のリファレンスマニュアルではそもそも単項 + は存在せず、
外部ﾘﾝｸ[pdf]:web.archive.org
1989年には単項 + が現れていてポインタも受け取れるようになってる。
外部ﾘﾝｸ[pdf]:www.softwarepreservation.org
この間にどんな議論があったのかよくわからん。
省1
766: (ｱｳｱｳｴｰ Sa23-D2PX) 03/18(火)18:06 ID:2EW8BzNca(1) AAS
>>760-762
各要素のサイズが一定じゃないから無理なんやろな
767: (ﾜｯﾁｮｲ 1302-BOwI) [!donguri] 03/21(金)19:45 ID:zuSmXANM0(1/2) AAS
>>755
またまた勉強になったお！
ありがとうございます！！
768: (ﾜｯﾁｮｲ 1302-BOwI) [!donguri] 03/21(金)19:49 ID:zuSmXANM0(2/2) AAS
関数のアドレスなら呼び出して
スタックに無理矢理アク(以下略)
769: (ﾜｯﾁｮｲ 0107-exlI) 03/21(金)22:32 ID:pLF+KLC30(1) AAS
そういうむちゃくちゃが簡単にできるのがC/C++
そんなことしながら、チップを覚えるんだよなあ
自分、次はMIPS覚えないと
770(1): (ｱｳｱｳｴｰ Sa23-D2PX) 03/22(土)14:21 ID:U6/Lg1xxa(1) AAS
どっかのタイミングでbpがスタックギリギリ飛ばすんじゃなくて
コンパイラが128bytesくらい飛ばす仕様になった気がするんだけど
あれは0埋めで(ホントはバグがあるのに)奇跡的にバグ回避するテクニックなのか
他に理由あるんか
771: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e932-a7BF) 03/22(土)18:01 ID:nNEN9uWE0(1/3) AAS
>>770
128 ビット (16 バイト) じゃない？
SIMD とかの都合で 16 バイトアラインが必要な環境が出てきたからという事情だと聞いたことある。
772(1): (ﾜｯﾁｮｲ d963-lHAu) 03/22(土)20:51 ID:kbZO019Z0(1/4) AAS
質問なのですがstd::unique_ptr<T>とかstd::shared_ptr<T>みたいなSTLで定義済みの
テンプレートクラスをfriendにすることは合法？
用途はシングルトンﾊﾟﾃｨｰﾝのオブジェクトのプログラム終了時の自動解放
773(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e932-exlI) 03/22(土)21:29 ID:nNEN9uWE0(2/3) AAS
>>772
T のデストラクタが private なのを std::unique_ptr<T> からのアクセスは許すってこと？
特に問題ないよ。
ところでテンプレートクラスじゃなくてクラステンプレートな！
774(1): (ﾜｯﾁｮｲ d963-lHAu) 03/22(土)22:33 ID:kbZO019Z0(2/4) AAS
>>773
㌧クス、
>T のデストラクタが private なのを std::unique_ptr<T> からのアクセスは許すってこと？
>特に問題ないよ。
それがTのコンストラクタがprivateなﾊﾟﾃｨｰﾝなのです！
friendにしないとビルドが通らないかった（VS2022、VS2015）。
多分moveとかの最にstd::unique_ptr<T>がTのコンストラクタにアクセスするのだと思う。
775(1): (ﾜｯﾁｮｲ d963-lHAu) 03/22(土)22:39 ID:kbZO019Z0(3/4) AAS
AA省
776(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ e932-exlI) 03/22(土)23:40 ID:nNEN9uWE0(3/3) AAS
>>775
new Foo() を Foo のメンバ関数の中でやる分には自分自身の中でやることなので friend 宣言は不要。
std::make_unique<Foo>() をすると std::make_unique の中で Foo のコンストラクタを呼ぼうとするから std::make_unique<Foo> をフレンド宣言する必要がある。
777(2): (ﾜｯﾁｮｲ d963-lHAu) 03/22(土)23:48 ID:kbZO019Z0(4/4) AAS
>>776
>new Foo() を Foo のメンバ関数の中でやる分には自分自身の中でやることなので friend 宣言は不要。
と思うじゃん？
↓現実
>friendにしないとビルドが通らないかった（VS2022、VS2015）。(>>774
エラーメッセージは熟読していませんぬが、
多分クラステンプレートの実体化がクラスのメソッド全部についてまとめて行われる的なことが起きて、
省1
778(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ ed32-PAPZ) 03/23(日)00:18 ID:Ft35v0Bz0(1/3) AAS
>>777
私は Visual Stuio 2022 (MSVC 17) にコンパイルさせてエラーが出ないことを確認した上で書いてる。
手元に Visual Studio を入れていないのでオンラインコンパイラだけど。
コードを呼び出す側なども補うとたぶんこんなのだよね？ 私が問題の理解を間違えている箇所はある？
#include <memory>
class Foo {
private:
省14
779(1): (ﾜｯﾁｮｲ ed7c-etgo) 03/23(日)00:19 ID:YXTjT4M+0(1/2) AAS
通ったが？
外部ﾘﾝｸ:godbolt.org
780: (ﾜｯﾁｮｲ ed7c-etgo) 03/23(日)00:20 ID:YXTjT4M+0(2/2) AAS
あ、被った
内容は一緒
781: (ﾜｯﾁｮｲ 9901-Awih) 03/23(日)00:21 ID:/EbbY7QB0(1) AAS
>>777
エラーメッセージは読まんといかんよ
分からんときは今ならLLMに読ませると良い
782: (ﾜｯﾁｮｲ e563-0why) 03/23(日)01:58 ID:IgihfQRv0(1/4) AAS
>>778>>779
お騒がせしましたｻｰｾﾝ；；；orz ビルドが通らないというのは私めの勘違いだった模様。
コードはそれで良いです。
そのコード（最小サンプル）、および最小サンプルにする前のコード×VS2015でもfriend宣言部分をコメントアウトしてビルドが通った 。n_
フレンド宣言friend std::unique_ptr<Foo>; を付けるに至った履歴が無いので推測ですだが
デストラクタがprivateのままだったタイミングがあったのかも……
（m_pObjが生ポインタのタイプのSingletonはデストラクタがprivateでもビルドが通る（デストラクタを呼ぶ人が居ないため）
省1
783: (ﾜｯﾁｮｲ 622d-hk3H) 03/23(日)09:31 ID:CXYOr+7B0(1) AAS
繰り返しになるが熟読した方がいいぞ
無視していいメッセージかそうでないかも区別できるようになるから
784(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ ed32-PAPZ) 03/23(日)09:32 ID:Ft35v0Bz0(2/3) AAS
元の話題からはずれる余談だけれど、静的記憶域期間を持つブロックスコープの変数は最初に通過したときに初期化されるルールがある。 (条件によるので常にではない。)
外部ﾘﾝｸ[dcl]:timsong-cpp.github.io
なのでシングルトンパターンはこう単純化して書くことも出来る。
#include <memory>
class Foo {
Foo() = default;
public:
省8
785(2): (ﾌﾞｰｲﾓ MM19-xG3a) 03/23(日)10:12 ID:i5B9IukZM(1) AAS
それunique_ptrにする意味ある？
shared_ptrなら意味わかるけど
786: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ ed32-PAPZ) 03/23(日)10:45 ID:Ft35v0Bz0(3/3) AAS
>>785
意味ないな。
787: (ﾜｯﾁｮｲ e563-0why) 03/23(日)10:56 ID:IgihfQRv0(2/4) AAS
>>784
サンプルコードでは省略したけんども、Double-checked lockingの実験をしたかったﾉﾃﾞｽ！
■ Double-Checked Locking is Fixed In C++11
外部ﾘﾝｸ:preshing.com
つなみに関数内staticオブジェクト初期化（初回実行時）のスレッド安全性がどうーなっているのかは
よく知りま栓（よって採用には消極的
>>785
省5
788: (ﾜｯﾁｮｲ e563-0why) 03/23(日)10:57 ID:IgihfQRv0(3/4) AAS
すまんこTeamsのノリで途中送信すたorz
誤： スレッド安全性担保がそこそこ重い同期オブジェクトで一方unique_ptrの所有権移動は非同期に行われることはなさげ
正： スレッド安全性担保がそこそこ重い同期オブジェクトで行われている危険性がある。一方unique_ptrの所有権移動は非同期に行われることはなさげなので多分軽量
789(1): (ﾜｯﾁｮｲ e563-0why) 03/23(日)11:03 ID:IgihfQRv0(4/4) AAS
だいたいstd::unique_ptrとstd::shard_ptrでは前者が1個のポインタと同じサイズなのに後者は2個分ある（ヒープにとられた参照カウンタへのポインタを持つため
sizeof(shared_ptr)=16
sizeof(unique_ptr)=8
というのもあり、std::unique_ptr<T>で済むところをstd::shared_ptr<T>推しするのはいかがなものか……
790: (ﾜｯﾁｮｲ 0653-xG3a) 03/23(日)21:04 ID:k0m2+uGk0(1) AAS
>>789
shared_ptrを使えと言ってるのでなくunique_ptrの意味が特にないと言ってる
別に使ってもいいけどお前それをわかってんの？ってこと？
ついでに言っておけばshared_ptrを使う場合ってのは参照カウントがゼロになったらシングルトンを破棄するみたいな凝った実装する場合に使う
791(1): (ﾜｯﾁｮｲ ed7c-etgo) 03/24(月)00:16 ID:zeyD/Mo00(1/2) AAS
unique_ptrじゃなくてナマポ使えって言ってんの？どこでdeleteする気なの？
792(1): (ﾜｯﾁｮｲ 0653-xG3a) 03/24(月)00:22 ID:wvKmLjta0(1) AAS
>>791
static Fooでいいだろってことだよ
自分で気づけなかったな
793: (ﾜｯﾁｮｲ ed7c-etgo) 03/24(月)07:56 ID:zeyD/Mo00(2/2) AAS
えぇ・・・？
794(1): (ﾜｯﾁｮｲ 65e7-aE+1) 03/24(月)08:43 ID:s0JFvm8m0(1/2) AAS
>>792
マルチスレッドで問題あるんじゃなかったっけ？
資料どこにあるか忘れたけど。
795(1): (ﾜｯﾁｮｲ 65e7-aE+1) 03/24(月)08:50 ID:s0JFvm8m0(2/2) AAS
>>794
ずいぶん前に問題無くなっているのね。
外部ﾘﾝｸ[html]:cpprefjp.github.io
796: (ﾌﾞｰｲﾓ MM62-xG3a) 03/24(月)09:19 ID:8nOZWVbeM(1) AAS
>>795
もし解決されてないならunique_ptrでも問題出るでしょ
797(1): (ﾜｯﾁｮｲ 4602-BGJw) 03/24(月)23:17 ID:C5SHS/Z30(1/2) AAS
Makefileについて教えてください。
ベースディレクトリにMakefileがあり、サブディレクトリは以下の構造としたいです
・src\内にhello.c func1.c func2.cが、include\内にfuncs.hがある
・*.oはobj\内に作る
・最終成果物は.\sample.exeとして作る
ソースファイル、ヘッダファイルの増減時にSRCS、INCSを修正すれば済むようにと、
以下のようなMakefileを作っているのですが、makeすると
省20
798(1): 797 (ﾜｯﾁｮｲ 4602-BGJw) 03/24(月)23:24 ID:C5SHS/Z30(2/2) AAS
すいません、タブが崩れました
下の方ですが、全角スペースで記載してますが
$(PROGRAM): $(OBJDIR)/$(OBJS) $(INCDIR)/$(INCS)
$(CC) $(CFLAGS) -o $(PROGRAM) $^
.c.o:
$(CC) $(CFLAGS) -c $(SRCDIR)/$<
こうです
省1
799(2): Fish (ﾜｯﾁｮｲ 652f-MaZR) 03/25(火)02:35 ID:3npSY7mr0(1) AAS
OpenCVについての質問です。VS2022を使用し、includeやopencv_world4100d.libの設定が終わり、検証のためにMatを宣言してimread、imshowのみを書いて検証しようとしたのですが、dllの設定がうまくいってなかったのかコンソールにdllのloadがfailedと大量に出力されます。OpenCVの入れ方を教えてほしいです…まだC++初心者で5チャンの投稿も初心者なので何か変だったらすみません…
800: (ｱｳｱｳｳｰ Saa5-WcQO) 03/25(火)04:37 ID:ztarSHRBa(1) AAS
>>798
.o:
$(CC) $(CFLAGS) -c $(SRCDIR)/$<
>>799
環境変数
801: (ﾜｯﾁｮｲ 9901-Awih) 03/25(火)12:24 ID:sbXkgTme0(1) AAS
>>799
exeと同じディレクトリにloadがfailedと言われるdll置いてみたら?
802(1): (ﾜｯﾁｮｲ 6e6c-JaxA) 03/26(水)11:17 ID:ZFGsgZnF0(1) AAS
Makefileを作る時の$<と$?と$^の使い分けを教えて下さい
特に$<が何のためにあるのか分かりません。これだと2番目以降の材料が無視されてしまって動かない場合があるんじゃないかと心配になります。あと、makeは常に新しい材料のみコンパイルするという事は、すべてのケースで$?で良いのではと思ってしまいます。超初歩的な質問だと思いますがよろしくお願いします
803(1): (ﾜｯﾁｮｲ 6518-hacg) 03/26(水)13:48 ID:GrIMF1MA0(1) AAS
C言語だとオブジェクトファイルの依存ファイルは，cファイルとそのcファイルが使うhファイルだけどコンパイルするのはあくまでcファイルだけ
だから依存関係の1つ目にcファイルを，2個目以降にhファイルを書いておけば$<でコンパイルできる
とかかな
804(1): (ｱｳｱｳｳｰ Saa5-WcQO) 03/26(水)15:00 ID:NpEBbPpga(1) AAS
>>802
っ 外部ﾘﾝｸ:tex2e.github.io
805: (ﾜｯﾁｮｲ 6232-bZOK) 03/26(水)15:48 ID:OM1iPrvu0(1) AAS
>>797
基本的にサフィックスルールは何十年も前からobsolete扱いなのでやめた方が良い
806: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 09fa-p0tU) 03/26(水)20:50 ID:cSMtN3B/0(1) AAS
ところでこの場合の makefile の話は GNU Make を前提にするということでええんか？
807(1): 797 (ﾜｯﾁｮｲ 4602-BGJw) 03/26(水)22:53 ID:dm/+cX2j0(1) AAS
皆さんいろいろと情報をどうもです
結局、以下のようなものと落ち着いてます
ちなみに使ってる環境のmakeはGNU Make 4.4で、GNU Makeの機能を多用してます
「$(OBJDIR)%.o: $(SRCDIR)%.c」と書ける理由は、pattern rulesという機能なのですかね
ここをforeachとかで書こうとしてましたが、これでいけると聞き、書いてみたら動いたのでもうそのままです
以外に汎用性が出そうだと感じてますが、改良点があればまたご意見ほしいです
PROGRAM = c_sample.exe
省13
808: (MX 0H1d-JaxA) 03/26(水)23:25 ID:Z/+2BBNHH(1) AAS
>>803
>>804
ありがとうございます
助かりました
809: (ﾜｯﾁｮｲ 9901-Awih) 03/27(木)00:00 ID:KC9fXGxH0(1/3) AAS
汎用するのならautotoolsを使った方が良いのでは?
810: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ ed32-p0tU) 03/27(木)01:07 ID:gbE/Uiq80(1) AAS
拡張子に exe がついてるということはウィンドウズを想定してるんじゃないの？
cygwin とか msys2 とかだと autotools を入れるのは簡単だけどそうじゃないならめんどいかも。
811: (ﾜｯﾁｮｲ 06b2-xG3a) 03/27(木)02:03 ID:eJjdVc1D0(1) AAS
普通cmakeでしょ
好きじゃないけど
812(1): (ﾜｯﾁｮｲ 6262-bZOK) 03/27(木)08:24 ID:8EB6UmzB0(1) AAS
>>807
分かったからもう消えろ
ここはCのスレではないしmakeのスレでもない
813: (ﾜｯﾁｮｲ 9901-Awih) 03/27(木)09:16 ID:KC9fXGxH0(2/3) AAS
makeスレなくなったね
814: (ﾜｯﾁｮｲ 9901-Awih) 03/27(木)10:58 ID:KC9fXGxH0(3/3) AAS
ないと思ったらUNIX板だったようだ
815(1): (ﾜｯﾁｮｲ 4202-rYal) [!donguri] 03/27(木)14:55 ID:OeqyroTj0(1) AAS
>>812
過疎ってきてるし
C++とmakeは連動すること多いから
話題はあってもいいんじゃねーかと
書き込んでみるテスト
816: (ﾜｯﾁｮｲ 4279-Br5P) 03/27(木)18:38 ID:bm95RmrL0(1) AAS
ノーマルスーツを着ろシャア
817: (ｱｳｱｳｳｰ Saa5-WcQO) 03/28(金)12:58 ID:VPiwRdmLa(1) AAS
>>815
あってもいいけどコンパイラの使い方までかな
makeは誘導した方が良いと思う
818(1): (ﾜｯﾁｮｲ 6ea1-pnyl) 04/06(日)00:01 ID:xzDebXnC0(1/3) AAS
質問なのですが基底クラスでpublicとした仮想関数の可視性を派生クラスでprivateに狭めることができるのですが
なんでこんな仕様なの？
これは逆に言うと派生クラスでprivateとした一般メソッドに対し、
たまたま同じシグネチャの仮想関数を基底クラスで定義されたら基底クラス経由でprivateとしたメソッドを外部から呼び出せ
てしまいカプセル化の危機……！
そういう仕様になっているメリットとは一体……
819: (ﾜｯﾁｮｲ 4587-wZYf) 04/06(日)07:42 ID:xouJqKec0(1/2) AAS
前者は仮想関数を派生クラス経由で呼べないように出来る
というか派生のコンストラクタをprivateにして、friend指定したcreatorクラス経由でしか生成出来ないようにするとかそういうのに便利
あと後者は、試してないけど派生の同シグネチャの関数は基底経由で呼べないと思うよ、vtblに登録されてないから
820: (ﾜｯﾁｮｲ 45f5-pnlG) 04/06(日)08:51 ID:2WEREMbe0(1) AAS
継承に関しては早すぎる最適化の問題もあるから、そのまま使うんじゃなくてアダプタに切り離した方がいいと思う。
Boostあたりにアダプタ用のライブラリないかしらん。
821(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-nY3F) 04/06(日)09:09 ID:CSMreA7R0(1/4) AAS
>>818
コードで言えばこういう状況かな？
外部ﾘﾝｸ:wandbox.org
基底にある仮想関数と同じシグネチャならオーバーライドするという規則は単純に言語設計の失敗。
だからこそ override 指定子が導入された。
override 指定子ではオーバーライドのつもりでオーバーライドになっていないときを検出できても
オーバーライドではないつもりでオーバーライドになってしまうことは検出できないのだが……
省1
822: (ﾜｯﾁｮｲ 45ba-wZYf) 04/06(日)09:14 ID:U2fAIE9I0(1) AAS
ああそっか、シグネチャ同じなら強制的にオーバーライドになるんだっけスマン
823(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-nY3F) 04/06(日)09:27 ID:CSMreA7R0(2/4) AAS
意図せずオーバーライドになってしまうことがあるのは失敗だが、
意図して private でオーバーライドする分には「そういうインターフェイス」なのだからカプセル化の破綻ではないよ。
824: (ﾜｯﾁｮｲ cd7c-a/1F) 04/06(日)10:21 ID:gleSakN+0(1) AAS
リスコフの置換原則を破るからあんまり良くはないと思うけどな
基底クラスとして振る舞わせる気がないならprivate継承すべきだ
825: (ﾜｯﾁｮｲ 6ea1-pnyl) [sa] 04/06(日)10:25 ID:xzDebXnC0(2/3) AAS
>>821
なるほど……
virtualが省略可能なのが諸悪の根源かとｵﾓﾀがそっちか……
>>823
通常はBaseクラス→派生クラス、の順で設計するから「そういうインターフェイス」と考えてだいたい良いのかもしれませんけども
派生クラスまで設計した後にBaseクラスにメソッドを追加して、それがたまたま派生クラス独自に定義したprivateメソッドと
同じシグネチャになってしまった場合、Baseクラス経由で派生クラスのprivateメソッドを意図せず呼べてしまうという
省1
826: (ﾜｯﾁｮｲ 6ea1-pnyl) 04/06(日)10:32 ID:xzDebXnC0(3/3) AAS
んまーBaseクラスにメソッドを追加しようとする時点で変更の影響範囲を派生クラスまで広げて調査すべき
というのは正論やがコンパイラで検出可能な不都合のチェックのを人にやらせるのはｲﾏｲﾁ……
827: (ﾜｯﾁｮｲ 457b-wZYf) 04/06(日)11:31 ID:xouJqKec0(2/2) AAS
大抵のコンパイラで普通警告出るやろ？
上下前次1-新書関写板覧索設栞歴
あと 175 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.035s