C++相談室 part123

1 名前：デフォルトの名無しさん mailto:sage [2016/02/21(日) 16:36:27.08 ID:jZESqUY+.net] C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレに お願いします。 前スレ C++相談室 part122 peace.2ch.net/test/read.cgi/tech/1453557975/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.97【環境依存OK】 peace.2ch.net/test/read.cgi/tech/1439849418/ ■長いソースを貼るときはここへ。■ 　codepad.org/ 　ideone.com/ 275 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 00:01:35.54 ID:gceSYQgA.net] 同じネームスペースは必ず同じコンパイル単位だとは限らないけど 同じネームスペースの{}で囲われた部分は同じコンパイル単位になるだろ さもなくば、}が無いです、ってコンパイラに怒られる 同じコンパイル単位で、{}は必ず対になってなきゃダメだからね だからネームスペースどうこうってより、その後ろの{}こそが重要なんだよ {}に囲われた部分は必ず同じコンパイル単位になるから 本当なら前方参照は可能なはず 今は同じクラス内に有るもののみ前方参照が可能だが これはクラス定義内は{}で守られていて必ず同じコンパイル単位になることが保証されているからだとも考えられ 同じ理屈でネームスペースにも拡張しても良いはず もっと単純に、同じコンパイル単位であれば、前方参照が可能としても良いと思うがね 今のクラス内のみ前方参照が可能とかという、中途半端な仕様は意味が分からないね 文法的に出来るんならやれよ、他の今風の言語は大体可能だぞ C#なんか、コンパイル単位を飛び越えて前方参照が可能なように 並行してコンパイルするって聞いたことあるぞ、本当かどうかは知らんがな 未定義なシンボルに出会ったら、一旦中断して、別のファイルをコンパイルするって感じかね 全く本当かどうかは知らないし、適当だが、C++にそこまでの要求はしない ただ、同じコンパイル単位であれば前方参照できても良いだろってだけの話 276 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 00:52:56.35 ID:gceSYQgA.net] 極端な話、今のC++でもソースコード全体を適当なダミークラスで囲ってやれば 前方参照し放題の、順番なんか気にしない状態になるわけで(←実際には多少の制約はあるが) 既に、そういうことが現実に可能な状態なわけだから 同じコンパイル単位で前方参照を可能にすることは技術的に然程難しいことではないはずなんだよね 277 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 00:53:35.71 ID:R7oQ7N64.net] 必要ないからだろ。 クラスのメンバ関数は前方宣言できないかわりに前方参照できるようにしてるだけで。 278 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 01:02:25.39 ID:gceSYQgA.net] //test.hpp class name { 　　void method(); //←コレ }; これがメンバ関数の実質的な前方宣言だろ 実体の方はcppファイルにあるんだからな だから、C++的には、たとえクラス内の前方参照が出来なかったとしても、一応成り立つんだよ なのに、クラス内に関してだけは、利便性のために前方参照が可能となっている だったら、利便性のために、同じコンパイル単位内であれば前方参照可能としても良いだろ 279 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 01:22:01.07 ID:gceSYQgA.net] つまりは、もし仮にC++がクラス内で前方参照が出来なかったとしたら クラス内で何か相互参照しているような場合は 必ずクラス定義とメンバ関数の実体は分けて定義してください、ってことになるわけだが 実際それで問題ないし、C++erには日常茶飯事にすら感じる話だが これが面倒だからクラス内に関しては特別に前方参照を可能としたわけでしょ でも、「相互参照している場合はクラス定義とメンバ関数の実体は分けて書いてください」 は、クラス内だけじゃなくて、C++の彼方此方に頻出するわけで クラス内の相互参照問題だけ特別扱いする意味が良くわからないんだよね 技術的に可能な範囲で考えると、同じコンパイル単位なら前方参照可能だろう 280 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 01:46:28.08 ID:gceSYQgA.net] 俺もね、C++が全く前方参照を許していないのだったら諦めもつくよ むしろ清いとすら思う でもクラス内だけは特別に前方参照可能なんだよ もしクラス内の前方参照が出来なくても言語としては成り立つにも拘わらずだよ？ もし出来なくても、クラス内で相互参照が発生した場合は、クラス定義とメンバ変数の実体を分けて書けって話で これはC++では日常だろ？仮にクラス内の前方参照が出来無くてもC++的には普通のこと、むしろ自然 でも何故かクラス内だけ前方参照可能なんだよな 同じクラス内に有れば、変数もクラスも関数も、前方参照可能なんだよ 実際、ダミーのクラスでコードを囲めば、クラスだろうが変数だろうが関数だろうが 前方参照し放題って書き方も可能で、一つのテクニック それが可能なのだから、技術的には同じコンパイル単位であれば前方参照可能に出来る筈なんだよ 281 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 02:13:30.73 ID:gceSYQgA.net] 訂正 クラス定義とメンバ「変数」の実体 ↓ クラス定義とメンバ「関数」の実体 282 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 04:38:36.51 ID:XYqbGPFP.net] 確かにクラスでforward-declarationがいらないが為にめちゃくちゃ解りにくいソース書いて来る奴らにイライラするときがあるな 283 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 06:24:16.72 ID:PsUKAneX.net] ぼくのかんがえたさいきょうのしーぷらすぷらす の独演会は終わった？ 284 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 11:50:49.57 ID:WF7rFyWl.net] 「利便性を向上させる機能が一部既に存在しているのだから適用範囲を拡大すべき」 そんなにおかしな意見ではないと思うが どこの世界にも「改善」を否定する283のような残念な人間は居るものだ 285 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 11:55:58.57 ID:c8zeaZJl.net] 別に改善を否定してるとは限らないだろ？ 単に長文を否定してるだけかもしれない 286 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 12:05:50.76 ID:1UcnLTLP.net] こんな所で吠えてても実装なんてされないよ？ 287 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 14:02:39.92 ID:VjFIrQgn.net] 反響があれば実装はされるだろ。 288 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 14:25:54.39 ID:WCvUs0lb.net] まあ長文はいらないよね。 別に大したこと言ってないんだから1レスで短く説明すればいい。 289 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 14:26:38.30 ID:3jrP1VBb.net] 反響があるくらいならとっくにC++なんて廃れてるよ 290 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 15:12:18.63 ID:lSGTJ8xS.net] 対偶を取ると、 「C++が廃れてないなら反響はなかった」 291 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 17:36:52.78 ID:lHuhk1uY.net] ADL周りの仕様が今以上に訳ワカメになるからダメだろう。 クラスと違って名前空間は後でいくらでも弄れるのだから、コード書く人間がどれが呼ばれるか今以上に予測が難しくなる。 292 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 19:25:22.04 ID:8DyMxRve.net] >>284 そう言うのがそれしかないとでも思ってるのか？ 例えば inner class がどうあがいても前方参照できないことについてはどう思ってるんだい？ 自分のことしか考えてなさそうだから ぼくのかんがえたさいきょうのしーぷらすぷらす って書かれるんだよ 293 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:19:55.72 ID:gceSYQgA.net] >例えば inner class がどうあがいても前方参照できない struct outer { 　　struct inner_a 　　{ 　　　　void method(){ inner_b::method(); } 　　}; 　　struct inner_b 　　{ 　　　　static void method(){}; 　　}; }; 普通にinner_a内からinner_bを使えますが、いったい何のことを言っているんですか？ コンパイルもちゃんと通りますよ 294 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:30:15.59 ID:EHNG1aVZ.net] それはVSだからとかいうのがあったりする 295 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:35:08.09 ID:PsUKAneX.net] >>293 > いったい何のことを言っているんですか？ それはこっちの台詞だよ... inner class 前方参照 あたりでググってから出直してこい 296 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:37:16.35 ID:gceSYQgA.net] そうなの？ 297 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:39:49.11 ID:gceSYQgA.net] >>295 だったら、インナークラスの前方宣言が出来ないって書くべきで 「inner class がどうあがいても前方"参照"できない」 って書くのはおかしくないですか？そっちのミスでしょ 298 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:53:21.58 ID:gceSYQgA.net] VSだけかもしれないけど、こんな複雑なコードもちゃんとコンパイルできる struct outer { 　　void method() 　　{ 　　　　inner_a().method(); 　　　　auto obj = new inner_b::inner_inner; 　　　　obj->method(); 　　　　obj->value = inner_b::inner_inner::enum_::e; 　　} 　　struct inner_a 　　{ 　　　　void method() 　　　　{ 　　　　　　inner_b::inner_inner().method(); 　　　　} 　　}; 　　struct inner_b 　　{ 　　　　struct inner_inner 　　　　{ 　　　　　　enum struct enum_{ e, }; 　　　　　　enum_ value; 　　　　　　void method(){} 　　　　}; 　　}; }; 一旦クラスで囲んでしまえば、こんな入り組んでいても、何事もなかったかのように前方参照が出来てしまう C++を同一コンパイル単位内で前方参照を可能とすることに、文法的な隔たりや、技術的ハードルは無いという事だね 299 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:56:46.43 ID:WCvUs0lb.net] まだ荒らし足りないのか 300 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 21:57:25.47 ID:PsUKAneX.net] >>297 > 「inner class がどうあがいても前方"参照"できない」 > って書くのはおかしくないですか？ メソッドではなく inner "クラス" の前方参照ができるようになってから出直してこいよ 301 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:05:10.18 ID:WCvUs0lb.net] >>300 いやお前も何言ってるんだよ・・・。 302 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:09:47.23 ID:WF7rFyWl.net] >>292 「クラススコープでできていることと同等のことを一つの名前空間定義のなかでもしたい」 というID:gceSYQgAの話と関係無いことを言い出す理由が不明。 唐突に根拠も無く「自分のことしか考えてなさそう」とか言い出すあたり、 知覚障害か何か？ 303 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:10:12.26 ID:jX68pRI9.net] この手の議論のためだけに無駄に頑張る人が多いのがc++ってイメージ。 304 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:13:56.70 ID:gceSYQgA.net] >>300 struct outer { 　　void method(){ inner_b obj;　//←これ } 　　struct inner_a 　　{ 　　　　void method() 　　　　{ 　　　　　　inner_b obj;　//←これ 　　　　} 　　}; 　　struct inner_b{ }; }; VSだけかもしれないけど、インナークラスの前方参照は出来ますよ、ただし、メソッド内ではね struct outer{ inner *ptr; inner{}; }; って書けない話だろうけど struct outer{ struct inner; inner *ptr: struct inner{}; }; って前方宣言してあげれば良いだけで、大した手間ではない 同一コンパイル単位で前方参照できるといっても、例外は有って構わないわけで struct hogehoge; と書くことぐらいの手間は全くの程度問題 305 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:23:03.30 ID:gceSYQgA.net] 何事にも例外が有ってよいと思うわけです、ハイ 完ぺき主義者ではないので 仮に 「インナークラスの型のポインタ変数を前方参照っぽく定義より先に使って宣言したいときは 　struct hogehoge;　と事前に前方宣言しなければならない」 というルールが有ったとしても、この程度は何の手間でもないから問題ないですね 306 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:24:08.59 ID:gceSYQgA.net] あーこれ間違ったわ struct outer{ inner *ptr; inner{}; }; ↓ struct outer{ inner *ptr; struct inner{}; }; struct が抜けてたわ 307 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:25:04.02 ID:WCvUs0lb.net] >>305 それならそのまま使えばいいじゃないの。 何に不満があるんだよ。 308 名前：デフォルトの名無しさん [2016/03/09(水) 22:25:25.73 ID:eOjuPS6Y.net] int main() { struct A{ A(){} }; struct B{ A a; int x; }; B b = B(); printf( "%d\n", b.x ); 309 名前：デフォルトの名無しさん [2016/03/09(水) 22:26:12.04 ID:eOjuPS6Y.net] b.xがvc2015だと0なのに2012、2013だと不定値になります。何故でしょうか。 310 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:28:49.66 ID:lHuhk1uY.net] 不定なのが偶々0なだけ 311 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:30:44.15 ID:av11/7D/.net] 初期化されてないから 312 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:32:19.48 ID:WCvUs0lb.net] >>309 0が正しいと思う。MSのバグじゃないの？ 313 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:34:09.23 ID:+X5y9V0s.net] >>309 0が正しい。 314 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:35:46.14 ID:+X5y9V0s.net] なので、VC++のバグに1票。 315 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:37:39.69 ID:PsUKAneX.net] >>302 できるからやればいいじゃん って言うのは ID:gceSYQgA が言ってること以外にも色々ある ってまで説明しないとわからんの？ 主張するのは勝手だけど、長々やるほどじゃねーだろ って言われてるだろ 316 名前：デフォルトの名無しさん [2016/03/09(水) 22:41:03.03 ID:WCvUs0lb.net] ごめん血迷ってた。default-intializedだね。 317 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:43:46.61 ID:+X5y9V0s.net] >>316 zero initializeでは？ 318 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:46:47.91 ID:lHuhk1uY.net] いやPODだから不定値だろ 319 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:48:02.12 ID:WF7rFyWl.net] PODだと不定値 などという仕様がどこから出てきたのか 320 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 22:49:51.34 ID:+X5y9V0s.net] >>318 だからゼロ初期化という仕様なんだって。 321 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 23:01:30.54 ID:WF7rFyWl.net] ついでに、PODがあるようには見えない 322 名前：デフォルトの名無しさん [2016/03/09(水) 23:05:53.89 ID:WCvUs0lb.net] 逆、非PODだから不定値。 自分はPODのカッコ付きと勘違いした。 323 名前：デフォルトの名無しさん mailto:sage [2016/03/09(水) 23:10:57.26 ID:WF7rFyWl.net] ここまで、>>309の炎上学習法若しくは確認間違いという指摘無し 324 名前：デフォルトの名無しさん [2016/03/10(木) 01:14:31.68 ID:lKwsVgJC.net] という>>323 の炎上学習法に見えるね 自分で確認するのが面倒だからって 325 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 01:44:57.86 ID:eUGHchpD.net] 0になったり他の値になったりするのは、偶々だね。 12.6.5のサンプル struct C { C(){} A a; const B b; int i; int j = 5; }; // initializes members as follows: // OK: calls A::A() // error: B has no default constructor // OK: i has indeterminate value // OK: j has the value 5 規格書読めない初心者は発言しないように。 326 名前：デフォルトの名無しさん [2016/03/10(木) 01:58:57.97 ID:8KJ6+/BF.net] >>325 話を読めない人は発言してもいいんですか？ 327 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 02:32:53.57 ID:mfhQ4lhr.net] >>325 お前さーC++14の規格票を持ってることだけが自慢なんだろ 俺も持ってるからお前の間違い突っ込んでやるよ 328 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 02:47:23.86 ID:eUGHchpD.net] タダで入手できるもの持ってると自慢できるのか? じゃ、自慢しよう どうだ、まいったか 329 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 03:23:13.76 ID:mfhQ4lhr.net] >>328 タダだと？どこで無料で入手出来るというんだ お前もしかしてタダで入手したのか？ 330 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 03:41:17.30 ID:mxNsUMFn.net] >>308-309 B() で B 型のオブジェクトが値初期化 "value initialize" される。 (8.5 p11) B はユーザー定義のデフォルトコンストラクタを持たないクラス型なので、値初期化のプロセスとして まずゼロ初期化 "zero initialize" され、そのあとデフォルト初期化 "default initialize" される。 (8.5 p8 bullet-2) int 型の B::x がゼロ初期化されると値 0 になる。 (8.5 p6 bullet-1) そのあと B::x がデフォルト初期化されるが、 int 型なので何も行われず 0 のまま。 (8.5 p7 bullet-3) と言う感じで、 C++14 の規格に従うと 0 になる。 C++03 以降だと経路が多少違うものの同じ結果になるけど、古の C++98 では B::x は不定となってしまっていた。 www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#35 MSDN 見る限りだと 2013 で value initialize に対応してそうなんで、 2013 で不定ならバグかな。 https://msdn.microsoft.com/en-us/library/w7wd1177%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/w7wd1177%28v=vs.120%29.aspx 331 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 10:36:48.16 ID:OLUNjZSr.net] >>330 この仕様ってポインタに対しても有効？ 以前似たような質問が議論されてたんだけど。 echo.2ch.net/test/read.cgi/tech/1439849418/184 332 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 11:13:34.09 ID:l944yzKo.net] 330じゃないけどポインタもscalar typeだから同じくゼロ初期化でしょ でもvalue initializeルールに依存するようなクラスは書くべきじゃないなあ echo.2ch.net/test/read.cgi/tech/1439849418/184 をNode node;ってやっちゃったらやっぱりnode.nodeは不定だよ こんなコードは書かずにちゃんとコンストラクタを書いて明示的にnullptrで初期化しなくちゃいかん 333 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 11:23:42.71 ID:mBEuB6ly.net] デストラクター作ってPODを諦めてるのに、適切に初期化するコンストラクター無いとか ただのバグでしかない 334 名前：デフォルトの名無しさん [2016/03/10(木) 11:46:11.58 ID:xbWf2tod.net] やっぱりvc2012でも2013でもxはゼロで初期化されません バグですか gccではゼロになります 335 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 13:35:05.45 ID:l944yzKo.net] バグだね >>308のBはxの初期値が重要ならこれもバグ 336 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 18:43:26.84 ID:uK8a0ubO.net] VCの規格無視はいつもの事らしいから気にすんな 337 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 20:58:27.62 ID:l944yzKo.net] 調べたらこのバグは2012年6月にはもう報告されているね https://connect.microsoft.com/VisualStudio/feedback/details/746973/incorrect-c-11-value-initialization-for-type-with-implicitly-declared-but-non-trivial-default-constructor VC++ 2015 RCでやっと直ったらしい 338 名前：デフォルトの名無しさん [2016/03/10(木) 21:21:03.49 ID:wKO6hiHF.net] そもそもが、int()で0だなんて馬鹿げたルールができたばっかりに... 339 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 21:38:31.66 ID:kxB40Mc+.net] マイクロソフト「C++11対応は2015 Update 2から本気出す」 340 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 22:09:45.41 ID:1z8FCjXU.net] >>331 有効 using P = int *; P p{}; はp==nullptrになる 341 名前：デフォルトの名無しさん mailto:sage [2016/03/10(木) 22:59:23.79 ID:XIXQ4NCN.net] 変数の初期値がどうなるかというだけの話でこんな議論になるのはC++ぐらいだろうなぁ。 342 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 11:55:53.38 ID:+X87dz7B.net] 値か0の初期化を当たり前にし、初期化なしを例外記述にする方向性なのだろう。 今のところ(バグがあるので)値初期化を信じず、 未初期化を前提に書けと言うのは、ある意味正しいのかもしれないが、 考え方としては逆行しているね。 343 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 12:52:11.72 ID:Y6ECzuws.net] ある意味正しいじゃなくてパフォーマンスを考慮すると未初期化がデフォなのはC++としては完全に正しいんだよ 0初期化がデフォになってしまったらCを継承したC++の利点が薄れてしまう value initializationこそがC++の思想に逆行してると思う 344 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 13:05:18.46 ID:kWA4jyXp.net] >>308 そもそも非POD型をメンバーに持つPOD型は非POD型になるだろ。 ＞cpplover.blogspot.jp/2010/06/c0xpod.html ＞さらに、非PODな非staticデータメンバーを持たないこと。 345 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 13:10:43.94 ID:vYMpLkUm.net] コンストラクタの強制なんかを見ると、 うっかり未初期化の値を使うことによる不具合を防ぐって 言語思想も含まれてるでしょ。 となると、単純な値にも何らかの初期値が保証される方向性もアリかと。 初期値は保証されるが、そのことによるパフォーマンス上のペナルティがない、 プログラマが初期化すればデフォルト初期値の処理は発生しない、 という仕様なら八方丸くおさまると思ったり。 346 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 13:12:37.67 ID:+X87dz7B.net] >>343 正しいなら実装側でstack protectorなんてデフォルトにならないよ。 現状もパフォーマンスが欲しいときだけ別にするというのが基本だ。 347 名前：デフォルトの名無しさん [2016/03/11(金) 13:13:39.58 ID:2/u08KSA.net] 基本強制初期化で int a = noinit; みたいにしたら初期化しない方式で 348 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 13:21:02.38 ID:zH9xDiQd.net] デフォは未初期化で記述方法によっては初期化もしてくれるって方針だろ。 その記述方法が紛らわしいのと、規格通り実装しないのがメジャーなコンパイラの１つなのが問題 もう少し分かりやすい記述なら良いのに、現状だとデフォルトconstructorが呼ばれているようにしか見えない。 349 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 14:21:15.08 ID:49om0mRF.net] >>347 Dでは int i = void; // デフォルトの初期値を省く コンパイラのオプションで従来動作も選べればすぐ導入可能だと思うがね 350 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 15:25:46.64 ID:dykTweBs.net] >>349 だからどうしたって話 int i{0}; とタイプすることもできないのか 351 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 15:35:13.63 ID:kWA4jyXp.net] int i();　でもいいよ。 352 名前：デフォルトの名無しさん [2016/03/11(金) 15:36:56.24 ID:kuBG6faz.net] int i = 0; while(std::cin >> i) std::cout << i; こんな馬鹿っぽい初期化いらんし邪魔だ 353 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 18:27:14.35 ID:0EDCO8WT.net] >>351 ウソを書くな 354 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 22:49:53.55 ID:YlUxysAB.net] >>351 それは関数宣言だと何度 355 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 22:52:02.91 ID:RA7SR1be.net] お前ら一体 何を言ってるんだ 356 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 22:56:28.69 ID:YlUxysAB.net] >>344 その通りだけど、ゼロ初期化とは何の関係も無い件 357 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:02:09.89 ID:4G2Dcq4h.net] 15年C++書いてきて 別案件でC#と数ヶ月戯れたけど C++はやっぱり変態だと感じたわ 良くも悪くも 358 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:09:07.85 ID:RA7SR1be.net] C++はぐちゃぐちゃ汚いよね 359 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:30:50.24 ID:RoKMXwVB.net] それは綺麗なC++コーダに出会ってない坊やだからさ 360 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:31:51.83 ID:+X87dz7B.net] またハゲの話してる…。 361 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:33:00.33 ID:RA7SR1be.net] いや書き方の問題じゃなくて言語仕様自体の問題なんd 362 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:35:30.87 ID:a6R8C1/e.net] C++はヘンタイだし、クソ言語だと思うけど、 大好き 363 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:36:37.63 ID:+X87dz7B.net] あなたの落とした物はこのC++CLIですか？それともこのJ#ですか？ 364 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:37:36.54 ID:RA7SR1be.net] 言語体系や構文ではC#が上だが、玄人好みなのはC++ 365 名前：デフォルトの名無しさん [2016/03/11(金) 23:43:00.34 ID:+X87dz7B.net] ヘンタイな玄人好みって、まるで素人童貞みたいな言い草だな。 366 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:44:29.48 ID:RA7SR1be.net] すまんわかるようでわからん 367 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:53:03.42 ID:YlUxysAB.net] お前ら一体 何を言ってるんだ 368 名前：デフォルトの名無しさん mailto:sage [2016/03/11(金) 23:54:21.02 ID:RA7SR1be.net] ほんとだよ全く 369 名前：デフォルトの名無しさん mailto:sage [2016/03/12(土) 00:03:43.97 ID:z2WBnFu0.net] でもそれがc++なんだよね。 370 名前：デフォルトの名無しさん mailto:sage [2016/03/12(土) 00:35:06.18 ID:FH3bqKTZ.net] こういうことをC++でやるにはあの機能ではダメでこの機能を使ったこの設計でなければならない っていう無知と思い込みから汚いコード書いて無駄に苦労してる人は珍しくないぞ 371 名前：デフォルトの名無しさん mailto:sage [2016/03/12(土) 01:39:29.17 ID:Zbyfy48z.net] 自分だけはキレイなコードかいてるという前提 372 名前：デフォルトの名無しさん mailto:sage [2016/03/12(土) 01:43:01.42 ID:Pl4Qm8o2.net] データ構造を隠蔽したままinterfaceを隔離する方法ってありませんか？ class IContainer { }; class Ifold { 　　virtual do(IContainer& container) const = 0; }; class VectorContainer : public IContainer { private: 　　std::vector<double> container_; }; みたいな感じでIfoldのインターフェースはコンテナに依存しないようにしたいです。 visitorパターンにするとIContainerに、Ifoldの具象クラスのacceptメソッドが増えていくのが…。 何かうまい実装はありませんでしょうか？ 373 名前：デフォルトの名無しさん mailto:sage [2016/03/12(土) 02:13:17.49 ID:VClvi+pB.net] 言っている意味が全然わからない。 Ifoldの具象型がIContanerの具象データに依存してるって事？ 上位型だけでやりとりしたいなら、IfoldかIContainerどっちでも良いが、 具象型の中でダウンキャストでもすればいいだろ。 374 名前：デフォルトの名無しさん mailto:sage [2016/03/12(土) 02:16:35.39 ID:VClvi+pB.net] もし外でvisit/accept可能か確認したいなら、 bool supports(IContainer&) (またはIfold&)とか付ける。 それ以外思いつかないが、そういうことじゃない？ 375 名前：デフォルトの名無しさん mailto:sage [2016/03/12(土) 02:18:19.39 ID:Pl4Qm8o2.net] >>373 Ifoldの具象型がIContainerの具象型が中で持ってるデータ構造に依存するのはOKです ダウンキャストというと、どのように行えばいいですか？ インターフェースクラスからは具象クラスがわからないため何にダウンキャストすればいいか決定できません…

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef