C++相談室 part122

1 名前：デフォルトの名無しさん mailto:sage [2016/01/23(土) 23:06:15.32 ID:HdItgJjm.net] C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレに お願いします。 前スレ C++相談室 part121 peace.2ch.net/test/read.cgi/tech/1449240881/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.97【環境依存OK】 peace.2ch.net/test/read.cgi/tech/1439849418/ 次期規格C++1zはこちら C++14/C++1z 20 peace.2ch.net/test/read.cgi/tech/1410382924/ ■長いソースを貼るときはここへ。■ 　codepad.org/ 　ideone.com/ 52 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 22:11:13.46 ID:aGf3VXDj.net] >>39 > A *a(int i) {return as.add(new A(i));} add() の中の push_back() で例外飛んだらリークする。 変な独自コンテナラッパーなんか作らないでおとなしくスマートポインタ使えばいいのに。 53 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 22:45:59.01 ID:u8HkWBJk.net] >>30 こういう誤りによるメモリリークを根絶するため new自体がソースコード上に現れるのを避けるのが普通 f(unique_ptr<A>(new A), unique_ptr<B>(new B)); ちなみにコンストラクターの例外は関係無い 54 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 22:51:40.35 ID:MTh5r7jR.net] >>51 これは知らなかった。 それ自身のdtorは走らないみたいだから、fopenしてたり生のポインタ使ってたりすると危ないかも。 ideone.com/IOYMAt 55 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 22:55:07.69 ID:ATEV5j5o.net] >>52 > push_back() で例外飛んだら www.cplusplus.com/reference/vector/vector/push_back/ > If a reallocation happens, the storage is allocated using the container's allocator, > which may throw exceptions on failure (for the default allocator, > bad_alloc is thrown if the allocation request does not succeed). ↑これのこと？ 56 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 22:57:30.92 ID:aGf3VXDj.net] >>55 うん。 57 名前：5 mailto:sage [2016/01/25(月) 23:27:49.38 ID:2nNO2C2F.net] >>31により当初の目的だったweak_ptrの排除ができ、またスマポの使用が今回の場合 不適切というわけではなさそう（というか自分的にはベストな解）ことが分かり 満足したので、質問を締めさせていただきます。 回答くれた方どうもありがとうございました。 58 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 23:46:30.78 ID:u8HkWBJk.net] >>50 パディングビットの規定を探したらCにたどり着いた これでよい？ C++ 3.9.1p3 Fundamental types → C言語 5.2.4.2.1 Size of integer types → C言語 6.2.6 Representations of types → C言語 6.2.6.2.5p5 Integer types 『The values of any padding bits are unspecified.』 59 名前：デフォルトの名無しさん mailto:sage [2016/01/25(月) 23:59:58.70 ID:aGf3VXDj.net] >>58 そんなところ。 Cでも保証は無いよね。あったところでC++で「保証」とはいえないんだけど。 60 名前：デフォルトの名無しさん [2016/01/26(火) 00:41:34.27 ID:LScUQqmU.net] >>57 とりあえずOpenGLとか触ったほうが良いと思います 61 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 00:45:45.80 ID:GVbqnwMe.net] >>60 なんで？ 62 名前：デフォルトの名無しさん [2016/01/26(火) 00:55:25.80 ID:LScUQqmU.net] >>61 データ構造が見えてなさそうだから 63 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 01:15:04.16 ID:88T0+SoF.net] 3D空間上でvertexはedgeを、edgeはfaceを、faceはelementを構成するっていうデータ構造はごく普通でしょう むしろ>>42みたいに全部vectorでやれとかいうほうがおかしい 64 名前：デフォルトの名無しさん [2016/01/26(火) 01:20:06.74 ID:LScUQqmU.net] >>63 内包させるのは普通じゃないよ 65 名前：デフォルトの名無しさん [2016/01/26(火) 01:25:45.01 ID:LScUQqmU.net] というか ＞vertexはedgeを、edgeはfaceを、faceはelementを構成するっていうデータ構造はごく普通でしょう こんなの見たこと無いよ 普通は各々verticesとして持ってるでしょ 66 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 01:29:56.87 ID:88T0+SoF.net] ＞各々verticesとして持ってる 意味がわからない elementとかの定義をvertexのリストだけでやるの？ tetraやhexaならいいけどpolyhedronはどうするの？ 67 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 01:38:32.76 ID:usMbn1Xz.net] 「普通」とか「おかしい」とか主観でモノを言っちゃうからめんどうなことになる。 >63はそういう構造をよく使う、あるいはよく見る。 >65はそういう構造を見たことが無い。 それだけのことなら相手に合意を迫る必要はまったく無い。 同じものを作ってるなら話は認識あわせに意味があるかもしれないけど、 ここじゃアカの他人なんだからそんなこともあるじゃろ、でおしまい。 二人とも、もう寝たほうがいいよ。 68 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 01:38:35.41 ID:zaDrFWLK.net] メッシュ変形なんかやるときは別だけど OpenGLで表示させるだけなら普通は頂点とインデックス列だけで事足りる 69 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 02:02:32.36 ID:88T0+SoF.net] そっかごめん 自分機械設計屋なんだけど、流体シミュレーションだとpolyhedron要素があるんで こういうデータの持ち方するのよね OpenGLは使ったことないっす 70 名前：デフォルトの名無しさん [2016/01/26(火) 02:53:27.61 ID:LScUQqmU.net] 多面体使う人でもEdge主体の構造じゃないのか？ まあもういいや大した話じゃないし 71 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 07:13:49.17 ID:8rZ+8lOF.net] そこそこまっとうなことを言っているのに理解されなかった>>63が哀れ(ﾁｰﾝ) 72 名前：デフォルトの名無しさん [2016/01/26(火) 07:26:37.18 ID:RIXqMqyc.net] 結局パディングはUMRんですか 73 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 13:43:58.10 ID:CloTf5dE.net] >>71 書き方が悪いんだよな プログラマの思考と反対というか elementは複数のfaceで構成され faceは複数のedgeで構成され edgeは複数のvertexで構成される ていう書き方の方がよかったと思われ 74 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 15:23:46.68 ID:VGU1ghG/.net] >>73 いや、表現の問題じゃないでしょｗ ちなみに俺はそっちより>>63のボトムアップ的な発想の方が自然 あんまり階層構造つくって持ちまわるよりは フラットにしたほうが結局ラクなんじゃないかって発想には 俺も個人的には同意する 75 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 16:05:26.42 ID:MwP9iauO.net] 継承を行うと親クラスのコンストラクタが隠蔽されてしまうのですが、 コンストラクタが継承されないこの仕様にはなにか深い訳があるのでしょうか。 多重継承が関係しているような気もするのですが、 そもそも単一継承のJavaも同様の仕様なのでもっと根本的な理由があるのだと思うのですが。 76 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 16:07:43.83 ID:MwP9iauO.net] すみませんサンプルの貼り付けを忘れていました。 ideone.com/v8QQHq 77 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 16:29:07.16 ID:uqIl8Fge.net] >>75-76 サンプル 10 行目の注釈はないものとして struct X : public Base { 　X(int i) : Base::Base(i) {} // 子から間接的に呼び出す必要がある }; と書くのはいかんの? Base() だけで自動的に Base::Base() を呼んで欲しいってことかな。 78 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 16:39:57.28 ID:XdnYao0l.net] 派生クラスをインスタンス化するときに派生クラスのコンストラクタは 呼び出さないで基底クラスのコンストラクタを直接呼び出したい？ そんなこと出来ないのは当たり前なのだが そんなことしたくなる深い訳の方が気になる 79 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 16:40:10.39 ID:CloTf5dE.net] 例えば有名なモデリングソフトのメタセコイアのMQOファイルはモデルを>>73みたいに記述してあるよ ただしedgeは無く、面は複数の頂点で表現されてたが エレメントが複数の面で構成されるのは仕方ないし 面が複数の頂点で構成されるのも仕方ないように思うが なんでもフラットな方が便利なのは常識だが 一体どうやってフラットにするのか興味があるわ struct face{ int elem_no; float v[16][3]; int v_size; }; vector<face> faces; こんなデータ構造じゃ、特定のエレメントだけ抜き出すのが大変だし さらにもっとフラットにして struct vertex{ int elem_no; int face_no; float v[3]; }; vector<vertex> vertices; こんな構造にしちゃうと、かなりフラットになるが、面単位で何かするのに まず同じface_noに属する頂点を探し回らなきゃならなくて超面倒なんだが さらにもっとフラットにすると struct vertex_elem{ int elem_no; int face_no; int vertex_no; int x_y_z_flag; float value; }; さすがにこれは無いか 80 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 16:48:50.66 ID:XdnYao0l.net] X(int i) : Base(i) {} を書くのが面倒くさいということか？ それを自動生成するのは条件を絞れば可能かも知れんが余計に分けわからなくなりそう 81 名前：77 mailto:sage [2016/01/26(火) 16:51:07.74 ID:uqIl8Fge.net] >>77 は勇み足だった。C++11だと下のように書くか。 #include <iostream> using namespace std; struct Base { int i; Base(int i) : i {i} { cout << "ok! I got " << i << endl; } }; struct X : public Base { X(int i) : Base {i} {} // Base::Base() でなく }; int main() { X x {1}; // Base側のコンストラクタを呼べるでしょ cout << "Yes, x.i == " << x.i << endl; return 0; } 明示的なコンストラクタ呼び出しでなく {} による初期化。 82 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 17:13:30.76 ID:MwP9iauO.net] >>80 そうです、Baseを継承する派生クラスが沢山ある場合が面倒です。 コンストラクタの継承が行われれば、派生クラス側でわざわざ決まりきったコンストラクタを書かずに済むのでコードがシンプルになるなのですが、 それが出来るオブジェクト思考言語は意外と少ないです。 83 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 17:37:45.67 ID:5mNKNaDj.net] >>82 class B { public B() {System.out.println( 84 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 17:39:33.39 ID:JvvEVEHG.net] ダブルクォーテーションで途切れるの悔しい… >>82 class B { public B() {System.out.println(”B”);} public B(int i) {System.out.println(”B i”);} } class D1 extends B {} // 自動的に追加されるコンストラクタ内で暗黙的にsuper() class D2 extends B {public D2(int i) {}} // 暗黙的にsuper() class D3 extends B {public D3(int i) {super(i);}} のとき new D1();new D2(1);new D3(1); でそれぞれ B, B, B iを表示 Javaだと引数無しのときだけチョッと手間省けるね 85 名前：84 mailto:sage [2016/01/26(火) 17:46:54.81 ID:LDY5A4Ql.net] ごめん、今確かめたらそれはC++でも一緒だったｗ struct Base { int i; Base() : i(0) { cout << ”ok!”; } }; struct X : public Base {}; これで X x; は普通に行けたねｗ 86 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 17:50:26.64 ID:XdnYao0l.net] >>82 なるほど。それなら分かるわ 基底クラスのコンストラクタはある意味継承されてるんだけど protected（ちょっと違うけど）みたいな扱いになってるんだよな 何かキーワードとかであなたの言う意味での継承が出来てもよい気がしてきた 87 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 18:41:50.54 ID:/Dc76BnU.net] >>75 釣りは要らん その内 コンストラクターの継承も知らないのかバーカバーカ と言うんだろ？ 88 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 19:55:14.89 ID:XdnYao0l.net] 釣られたわ C++11から出来るようになってるね ideone.com/PwOSrY 89 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 20:04:25.08 ID:yZwoVaS8.net] >>88 それで十分に嬉しいように見えるんだけど using Base::Base;の一行を書くのは>>75的には 「子から間接的に呼び出す必要がある」に該当しないのかな？ あと>>77が何を言っているのか意味不明なの俺だけ？ 90 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 21:25:05.76 ID:I8Y70xN6.net] >>51 これってコンストラクタ中から例外飛んで来たらいずれにせよメモリリークするから無駄って解釈でいいの？ この例だとdeleteはされるけど、結局デストラクタが呼ばれるわけじゃないからメンバにポインタ混じっててnewしてたりするとリークするよな 91 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 21:52:07.33 ID:8rZ+8lOF.net] 構築が終わっていない中途半端な状態でデストラクターが呼ばれたらそれこそ大変だ 少しは脳みそ使った方がいいぞ 92 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 22:52:14.01 ID:IXu06oBB.net] C++ではインスタンスxのコンストラクタ内で例外が発生した場合、 xのデストラクタは呼ばれない（理由は>>91の通り という言語仕様なのは真実なので、逃げ手としてnewに細工がしてあるだけの話 生のハンドルとかはこれそのものでは救えない。 コンストラクタで生のハンドルを確保するコードを普通に書いたら、コンストラクタが例外を生じたときにリークする それを避けるための正しいテクニックは、 1) きちんとハンドル（リソース）のwrapperを書いて、 2) そいつをxのメンバにしとく である（メンバのデストラクタは、xのコンストラクタが例外を生じても呼ばれる んまー常識的には「コンストラクタで例外を発生させない」とか「例外が発生したら諦める」設計のが 特殊な用途以外では普通な希ガス、 93 名前：92 mailto:sage [2016/01/26(火) 22:56:25.94 ID:IXu06oBB.net] >>92ﾌﾟﾁ訂正 s/コンストラクタ内で例(が|を)発生/コンストラクタから例外をスローさせない/g コンストラクタ内で例外が発生しそうなところはtry { } catch { }で囲ってしまうのも一つの手ではある 94 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 22:58:40.82 ID:usMbn1Xz.net] >>90 RAII の徹底ができていなければリークする可能性が出てくる。 例外の発生がコンストラクタからかどうかはあんまり関係ない。 95 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:02:54.28 ID:RBo8KHcc.net] やはりバカにはC++の敷居が高いようだな 96 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:05:13.87 ID:8rZ+8lOF.net] ラッパーを使うのは王道な一つの手だが 一つの関数内で例外安全なコードを書いてればリークは起こらない。 それすら出来ないようでは他の言語を使った方がいい 「コンストラクタで例外を発生させない」と言うのはやや方向性が違っていて 「プログラムを書かなければリークは起こさない」レベルの思考 97 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:06:58.14 ID:zcSlqmoV.net] >>95 自己紹介はしなくていいぞ 98 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:12:32.60 ID:I8Y70xN6.net] じゃあもしライブラリとして提供されてるクラスがメンバに複数ポインタ持っててコンストラクタで複数newして、しかもメモリが足りなくなる可能性が結構高い場合はどうすりゃいいんだ？ 他のライブラリ使うのはいろんな理由で無理、ライブラリの互換性のために元のソースいじれないってなったら漏れたらあきらめるしかないのか？ 99 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:14:58.68 ID:8rZ+8lOF.net] 例外安全でない糞ライブラリの中身をいじれない場合はどうすればよいの？ 質問しなきゃわからないほど馬鹿なのか 100 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:22:01.99 ID:I8Y70xN6.net] >>99 今まさに近い状況になってて、例外飛んでくるのはまた別の原因なんですけど 実際どうすればいいんですか？自分一人だけライブラリ使わないってのはできないんですけど 101 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:23:01.51 ID:CloTf5dE.net] まぁでもコンストラクタの途中で例外が発生しても コンストラクタの中でtry-catchして適切にリソース開放すれば良いだけでは？ 102 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:23:51.29 ID:4LzhB3JY.net] 例外処理でメモリリークを気にしたりするのがナンセンスなんよ 例外起きたらあとはリソース閉じて終了するだけのことだから アプリケーションとしては終了に向かうだけだからリークも糞もないんよ 103 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:27:16.38 ID:XdnYao0l.net] >>100 ライブラリがバグってるならどうしょうもないだろ >>102 ずいぶんとおめでたい世界にいらっしゃるようで 104 名前：デフォルトの名無しさん [2016/01/26(火) 23:28:08.68 ID:sH2SZupb.net] コンストラクタで例外が発生したらそのクラスの何を解放するんだ 105 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:28:59.31 ID:4LzhB3JY.net] mallocに失敗したのにexit前にfreeを呼びたい みたいな不思議な連中は一定おるんよ 106 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:30:11.03 ID:8rZ+8lOF.net] >>101 おおまかにはそれでよいが 最低限 例外中立にしとくのがマナー 具体的にはfunction-try-blockを使うかthrow;で再スローするかラッパーを使うか 107 名前：デフォルトの名無しさん [2016/01/26(火) 23:30:13.68 ID:sH2SZupb.net] 例外発生する＝アプリを終了するってなんなんだよ 108 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:30:33.16 ID:XdnYao0l.net] >>104 例外発生するまでに確保済みのリソース そんな面倒なことにならないようにRAIIの徹底はもう必須だよ 109 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:31:01.96 ID:CloTf5dE.net] ちなみにnewしたオブジェクトのコンストラクタ内で例外が発生した場合 デストラクタは走らないけどoperator deleteは呼ばれるからメモリリークしないよ 110 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:34:08.88 ID:TGWAfBDP.net] >>98 その通りだよ。 111 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:38:07.07 ID:8rZ+8lOF.net] >コンストラクタ内で例外が発生した場合デストラクタは走らない 揚げ足を取ると、走るケースが全くない訳ではない 112 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 23:44:41.90 ID:usMbn1Xz.net] >>111 ほんとならくわしく。 113 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 00:02:05.29 ID:zgyqI55G.net] >>112 コンストラクタ内で例外が発生してもコンストラクタ内でキャッチしてしまえば走らない コンストラクタ内で例外が発生してもコンストラクタ内でキャッチしてしまえば走らない 114 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 00:02:50.96 ID:zgyqI55G.net] ごめｗｗｗｗｗｗｗｗ 走るの間違いｗｗｗｗｗｗｗｗｗｗ 115 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 00:04:30.16 ID:0q1DRp6s.net] 触れないソースのリソースリークなんて気にしても仕方ないだろ 気持ち悪いけど放っておけ 116 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 00:13:07.10 ID:zgyqI55G.net] 普通に使ってリソースリークの危険があり、 かつユーザーの立場からリークを阻止する手段が無いというのは ライブラリのバグと言って過言ではない 117 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 00:34:28.52 ID:zSFGO6dq.net] いや普通にバグだから 118 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 00:47:13.92 ID:tYkYQITg.net] それでお客様が納得してくれるとでも？ 119 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 00:52:40.92 ID:0q1DRp6s.net] 仕様ですの一点張り 120 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 01:45:10.90 ID:zgyqI55G.net] >>100 longjump()か例外をthrowするかして大域脱出すると良い ID:I8Y70xN6が。 121 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 02:00:29.05 ID:gidaw1Ah.net] コンストラクタ内でtry catch 再throwでいいんだろ？ 何も難しいことなんてないじゃない。 122 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 03:05:27.95 ID:3jiwec3B.net] >>113 なるほどな ちなみにコンストラクターから例外が漏れた場合でもデストラクターは走る事がある struct A { 　A() {} 　A(int) : A() {throw 0;} 　~A() {} }; int main() { 　A a{0}; } 123 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 06:38:25.30 ID:oAun2w+9.net] >>121 つ初期化子 124 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 07:11:47.54 ID:3jiwec3B.net] >>123 初期化しがどうかしたか？ カタコトではただのアスペだぞ 125 名前：デフォルトの名無しさん [2016/01/27(水) 07:34:44.55 ID:T1kNk2gL.net] >>108 それはそのクラスが内部で処理することであってユーザーは何を解放するんだよ 126 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 08:01:41.14 ID:7tk5IOS7.net] ↑こんなところにアスペがもう一人 127 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 10:47:19.58 ID:oAun2w+9.net] >>124 コンストラクタ初期化子 128 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 12:30:07.60 ID:eULyfEEH.net] >>125 >それはそのクラスが内部で処理することであって ずっとその話なのだが 129 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 12:56:11.97 ID:zSFGO6dq.net] 初期化子もそうだけどデフォルトコンストラクトされる変数もそうだな コンストラクタ内でtry-catchできない やっぱりコンストラクトでの例外はまずいんじゃないか？ 130 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 13:59:04.99 ID:oAun2w+9.net] C++17ではできるんだっけ？ 131 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:48:02.83 ID:gidaw1Ah.net] 初期化子リストもメンバ変数も関係なくね？ 初期化しきれたクラスはデストラクタが呼ばれ、初期化できなかったクラスは内部でcatchしてエラー処理して再送するだけ。 やっぱ単純だよ。 我らがMeyer先生はなんて言ってるの？ 132 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:08:44.32 ID:7tk5IOS7.net] >>129 できないと判断した根拠は？ ideone.com/WlFMej >>131 メイヤー「ワシ、ちょっとC++引退するわ」 133 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:10:24.29 ID:7tk5IOS7.net] 一カ所訂正 誤 try m{}, x{} 正 try : m{}, x{} 134 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:15:50.95 ID:7tk5IOS7.net] >>127 荒らしは去れ 135 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:45:02.79 ID:oAun2w+9.net] >>131 コンストラクタ初期化子に書くメンバーが初期化はコンストラクタのスコープ内部じゃない。 自作クラスだったら君の言うように内部catchすればいいけど他作クラスで例外をthrowするタイプだtry-catchで囲めない。 136 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:49:38.11 ID:oAun2w+9.net] >>134 まさか14以降を前提にしてるなんて言うまい？ 137 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 19:31:29.47 ID:3jiwec3B.net] >>136 お前はコンストラクター初期化子や例外という言語機能がC++14以降だとでも言いたそうだな どれだけ勉強不足なんだ 138 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 19:39:57.53 ID:6XO7CsMP.net] お前らに一度確認していい？ 初期化リストつったらコンストラクタのパラメータのカッコの横の クラス名(引数) : この部分 {} を言うんだよな？ 駆け出しの頃にC++プライマーとかいう分厚い本で学んだときは たしかこうだったはずなんだが std::initializer_listの出現で落ち着かない気持ちになってきてる 139 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 19:53:14.68 ID:3jiwec3B.net] >初期化リストつったら (中略) >を言うんだよな？ いやまずそこから違う 140 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 20:04:51.00 ID:1b0Lj9r3.net] クラス名(引数) : この部分は初期化子 {} 141 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 20:41:04.94 ID:aFoLhF8M.net] >>140 とんくす！ ↓少し学んだ ISO/IEC 14882:1998 12.6.2 Initializing bases and members ctor-initializer: 　: mem-initializer-list mem-initializer-list: 　mem-initializer 　mem-initializer , mem-initializer-list mem-initializer: 　mem-initializer-id ( expression-listopt ) mem-initializer-id: 　::opt nested-name-specifieropt class-name 　identifier 142 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 20:44:21.08 ID:gqKHFo+S.net] >>129 だからtry-catchなんかしない。>>94,108のとおりRAIIで解決する。 なんというか１０年前にタイムスリップした感がある。↓読んでくれ。 https://www.google.co.jp/search?q=C%2B%2B+%E3%82%B3%E3%83%B3%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%82%BF+%E4%BE%8B%E5%A4%96 143 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:00:23.97 ID:zSFGO6dq.net] >>132 あなたのおっしゃる通りです。いい加減なこと言ってごめんなさい魔が差しましたｗ やはり大事なのはRAIIの徹底ですね 144 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:08:05.10 ID:oAun2w+9.net] >>137 えっ？ 初期化子までtry説に含めるのはC++11ではできないって言いたいだけなんだけど？ 145 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:09:24.27 ID:oAun2w+9.net] ×try説 ○try節 146 名前：デフォルトの名無しさん [2016/01/27(水) 21:10:04.69 ID:0xRCKJUw.net] RAIIって初期化がキモみたいなネーミングだけどデストラクタの解放の方が大事じゃね 147 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:13:01.64 ID:1b0Lj9r3.net] >>141 ああ、構文規則の非終端記号名のmem-initializer-listと混同していたのか。 148 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:16:28.24 ID:3jiwec3B.net] >>144 ISO/IEC 14882:1998 15p1 8行目 ISO/IEC 14882:2003 15p1 8行目 ISO/IEC 14882:2011 15p1 8行目 ISO/IEC 14882:2014 15p1 8行目 これのどこを読んだらいったいそんな嘘が出てくるのか 149 名前：デフォルトの名無しさん [2016/01/27(水) 21:19:58.24 ID:hY0OCllE.net] だからHaskell使えと言っとるだろがボケ。 150 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:23:34.50 ID:zSFGO6dq.net] >>144 俺はあなたに釣られちゃったけどこれが真実です ideone.com/rVg5CP 151 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:26:16.20 ID:Qr5LJlmv.net] このスレって常連の2、3人がID変えながら互いを罵ってんだよな？ 152 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:27:35.65 ID:3jiwec3B.net] >>150 C++14の結果のようだが コミュ障は去れ

---

---

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

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