1 名前:デフォルトの名無しさん [2009/01/11(日) 11:21:38 ] C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレに お願いします。 前スレ C++相談室 part65 pc11.2ch.net/test/read.cgi/tech/1230341243/
82 名前:デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:23:36 ] え?
83 名前:デフォルトの名無しさん [2009/02/16(月) 22:31:59 ] 後発スレで自演厨が暴れてるな
84 名前:デフォルトの名無しさん [2009/02/17(火) 01:47:18 ] イテレータのコンセプトは素晴らしいと思います。 ところで<algorithm>ヘッダのテンプレートはほとんどistreamの入力イテレー タに適用できません。 イテレータにバッファを内蔵し前進イテレータに変換すると適用できると思う のですが、こういったものはすでに作られていないのでしょうか? また、アイデアそのものに問題点はありますか? よろしくお願いします。
85 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:02:04 ] >>84 std::istream_iterator std::istreambuf_iterator
86 名前:デフォルトの名無しさん [2009/02/17(火) 02:07:09 ] >>85 両方ともinput_iterator_tagが指定されています。 forward_iterator_tagを想定するとお考えください。
87 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 02:38:59 ] >>84 Boost.Spiritがfile_iteratorというランダムアクセスできるイテレータを持っている。 内部でどんな実装をしているかは知らないが。 あと、イテレータではないけど、pstadeのovenというライブラリのmemorizedが 汎用的なバッファ機構(メモ化)を備えていて、 たとえ、元のカテゴリが入力だったとしてもこれを通せば前進になる。 p-stade.sourceforge.net/oven/doc/html/oven/range_adaptors.html#oven.range_adaptors.memoized 問題点はよく知らない。 ただ、memorizedは汎用なので、vectorやdequeに貯め込んだり、 file_iteratorのようにストリームに特化して作ったほうが、より効率が良いとは思う。
88 名前:デフォルトの名無しさん [2009/02/17(火) 02:44:54 ] >>87 boostのはたしか、ファイルをすべてメモリー上に読み込むような感じの ものだったと思います。 若干意味合いが異なります。 ovenはちょっと見てみます。
89 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 03:34:25 ] >>84 要素へのアクセスで、初めて読む部分かすでに読んだ部分かで処理を分けることになるので、 vector などのコンテナに必要な分を読み込んでから処理するのに比べて効率が悪くなりそう。 そのうえで、実際には必要な分を読み込んでから処理すれば十分なことがほとんどになるので あんまり需要が無いんだと思う。 本当に必要だといえる状況だと言うことなら、興味があるのでどんな場面か教えて欲しい。
90 名前:デフォルトの名無しさん [2009/02/17(火) 03:44:01 ] >>89 入力がある場合すべてにおいて必要になるのではないかと思っています。
91 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 03:55:28 ] >>90 それはないだろ。たとえばテキストファイルを1行ずつ読み込んで処理する場合、 getline() あたりで1行読んでの処理をループすればいい。
92 名前:デフォルトの名無しさん [2009/02/17(火) 04:04:38 ] >>91 入力を解析する必要がある場合すべて。 <algorithm>ヘッダを使用するという前提で。
93 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 04:12:17 ] >>92 その説明だと、vectorとかに蓄えればいいのでは、という疑問が解消されない。 どういう利点があると考えるのか詳しく聞きたい。
94 名前:デフォルトの名無しさん [2009/02/17(火) 04:15:40 ] >>93 ストリームの存在意義についてですか? いろいろ使い道はあるはずだと思いますけど。
95 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 04:23:34 ] >>94 研究するのは勝手だけれど、具体例を出せないのに意義を語られても困る。
96 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 04:34:30 ] >>94 いろいろと言うならひとつ挙げるくらい簡単だろ。
97 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 04:37:31 ] >>94 ストリームの存在意義など聞いていない。 >84 で挙げてる入力イテレータから前進イテレータへの変換をすることが、 必要な分だけコンテナに読み込んでからコンテナのイテレータを使うことに対して、 どんな利点があるのか挙げろと言っている。
98 名前:デフォルトの名無しさん mailto:sage [2009/02/17(火) 07:50:35 ] >>84 せっかくだからGoFのデザインパターンを全て調べてみろ
99 名前:デフォルトの名無しさん [2009/02/18(水) 02:33:36 ] >>97 亀レスで申し訳ありませんが、ストリームの存在意義そのものが答えになら ないでしょうか?
100 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 02:40:00 ] >>99 それしか言えないなら聞き方を変えるけど、一旦コンテナに貯め込む方式の欠点は何?
101 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 02:56:05 ] >>99 そう思うんならお前の脳内にある「ストリームの存在意義」を挙げればいいだろ。 それを聞く前に答えになるかならないかなんて、エスパーでもなけりゃわからん。
102 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 03:00:44 ] 一般的なストリームの存在意義といえば、一度にメモリ上に読み込まずにちょっとずつ 処理することで少ないメモリで大量のデータを処理できると言う点があるだろう。 しかし >84 で挙げている方法は「バッファを内臓」することでこの点は失われているように見える。
103 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 03:31:07 ] いろいろ適当。 input_iterator it0; input_wrapper_forward_iterator it1(it0); input_wrapper_forward_iterator it2; // ? find_if(it1,it2,cnd()); it2はどう定義するの?
104 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 03:33:56 ] find_ifはinputでいけるねごめん。
105 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 03:46:48 ] こうか stream st; input_iterator it00(st.begin()),it01(st.end()); input_wrapper_forward_iterator it10(it00),it11(it01); algorithm(it10,it11); stream st; input_iterator it00(st.begin()),it01(st.end()); vector v(it00,it01); algorithm(v.begin(),v.end()); このレベルじゃ意味はまったくないな。
106 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 08:45:38 ] 変態だな
107 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 14:26:32 ] ゆとり
108 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 16:17:15 ] C++を使うなら妥協って物も覚えたほうがいいよ
109 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 17:04:12 ] 妥協は物じゃないよ
110 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 17:16:54 ] 名詞だから物だよ
111 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 17:30:59 ] じゃあ、名詞としての”妥協”を覚えればいいんだな
112 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 19:15:24 ] 屁理屈こねないの。
113 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 21:43:29 ] 形式名詞はひらがなで書けということですね。
114 名前:デフォルトの名無しさん [2009/02/18(水) 22:50:24 ] ::func() って記述を見かけたのですが、::の前って省略できるんですか?
115 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 23:00:43 ] >>114 #include <iostream> void func() { std::cout << "This is ::func()" << std::endl; } namespace AAA { void func() { std::cout << "This is AAA::func()" << std::endl; } void aaa() { func(); // AAA名前空間のfunc()が呼ばれる ::func(); // グローバル名前空間のfunc()が呼ばれる } }
116 名前:デフォルトの名無しさん mailto:sage [2009/02/18(水) 23:23:21 ] >>115 さん ありがとうございます。 名前空間を念頭に置いてコードを読み直してみます。
117 名前:デフォルトの名無しさん mailto:sage [2009/02/19(木) 01:46:02 ] >>116 読むのはいいけど真似するなよ
118 名前:デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:09:13 ] wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
119 名前:デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:12:34 ] すみません。 どなたかMPEG Audioのdist10というプログラム使ったことある方いらっしゃいませんか?
120 名前:デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:18:25 ] >>116 ヒント:スコープの概念。 static const int32_t var = 1; グローバルスコープ namespace foo { static const int32_t var = 2; } fooスコープ class hoge { public: static const int32_t var = 3; } hogeスコープ ::varは1 foo::varは2 hoge::varは3
121 名前:デフォルトの名無しさん mailto:sage [2009/02/25(水) 11:10:00 ] wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
122 名前:デフォルトの名無しさん [2009/03/13(金) 20:52:41 ] throw new std::runtime_error("saji");
123 名前:デフォルトの名無しさん mailto:sage [2009/03/14(土) 00:30:03 ] >>122 newされたstd::runtime_error * だと!そんなもんthrowされたらまさにサジを投げるしかないな。
124 名前:デフォルトの名無しさん mailto:sage [2009/03/14(土) 07:13:32 ] >>122 newはもちろんジョークだよな?
125 名前:デフォルトの名無しさん [2009/03/18(水) 18:38:05 ] C++相談室 part67 C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレに お願いします。 前スレ C++相談室 part66 pc11.2ch.net/test/read.cgi/tech/1234420483/
126 名前:デフォルトの名無しさん mailto:sage [2009/03/19(木) 17:24:05 ] wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
127 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 09:58:48 ] std::sort で std::vector の要素をソートしようとしています。std::sort の第三引数にでたらめな比較結果を返す 比較関数を与えるとvector の要素の一部がおかしな値に置き換わってしまい、場合によってはプログラムが 異常終了してしまう現象に悩まされています。問題を再現するプログラムを用意しました。 #include <iostream> #include <vector> #include <algorithm> #include <cassert> int a[10] = {0, 0, 0, 1, 1, 1, 1, 0, 1, 1}, pos = 0; class ComparisonFunc { public: bool operator()(int i, int j) { return a[pos++] == 1; } }; void main() { int t[] = {3, 5, 1, 4, 2}; std::vector<int> v(t, t+5); std::sort(v.begin(), v.end(), ComparisonFunc()); assert(pos == 10); for (std::vector<int>::iterator it = v.begin(); it != v.end(); ++it) std::cout << *it << std::endl; } このプログラムを実行すると第3要素の値がおかしくなります。VC++ 2008 Express Edition と g++ 4.3.0 (MinGW) では一応実行が終了しますがIntel C コンパイラ 9.0 だと異常終了します。 環境は Windows XP SP3 (32ビット) です。「でたらめな比較結果を返す比較関数」を考えているのは、 ユーザが比較関数をスクリプト言語で定義できるシステムを作っているからです。operator() メソッドの 中でスクリプト言語で定義された比較関数を呼んで、その戻り値を operator() の戻り値として返す仕組みです。 そのためどんな比較関数が来てもプログラムが異常終了しないようにしたいと思います。どんな対策が 考えられるでしょうか? std::sort が比較関数の異常を検知して適当なところで処理を中断して例外でも スローしてくれたらと思うのですがそこまで面倒は見てくれないようです。
128 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 10:47:27 ] >>127 std::sortに渡すコンパレータは辻褄のあった結果を返さないといけないと仕様で決められている。 そうでない場合の動作は未定義。 つまり、でたらめな結果を返す可能性のあるコンパレータはstd::sortには使えない。 ソート関数を自作するか、コンパレータを検証する関数を追加するしかないだろうね。 いずれにしても矛盾を検知しようと思ったら、O(n log n)では済まないと思う。
129 名前:デフォルトの名無しさん [2009/03/20(金) 16:49:42 ] c++で作られたプログラムを逆アセンブルしてるんですが、アセンブリ言語について質問できるスレってありませんか?
130 名前:デフォルトの名無しさん [2009/03/20(金) 17:16:32 ] このへんじゃね? pc11.2ch.net/test/read.cgi/tech/1172916032/
131 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 17:20:20 ] C++で書かれたプログラムを逆アセ出来る人ってすごいなぁ。 意味不明じゃね?
132 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 17:30:16 ] 逆アセするならそもそもアセンブラ理解しないと・・・。 80x86系統の命令コード表あると思うからそれ見ながら分解していけばいいかと 後単純なプログラムでコードがどうなるかをチェックし続けるっていうのが解析の基本><
133 名前:デフォルトの名無しさん [2009/03/20(金) 17:34:18 ] >>130 ありがとうございました。 >>131 IDA pro とか簡単に逆アセンブルしてくれて、しかもグラフィカルに構造を表示してくれるので あんまり知識が無くてもなんとなく分かります しかも無料で使えるし。 ソフト自体が英語だしあんまり解説サイトとかが無いのが辛いですが・・。
134 名前:131 mailto:sage [2009/03/20(金) 19:47:12 ] IDA proってすげーー
135 名前:デフォルトの名無しさん [2009/03/20(金) 19:56:39 ] 引数オーバーロードによって戻り値を変えるプログラムが g++ (1)3.3.6と(2)4.2.4で挙動が違います。 実行後 main戻り値が (1) => 2 / (2) => 1 となります。 NS1をNS2に書き換えると両方とも2が戻ります。 どっちの挙動が標準規格的には正しいですか? //以下そのプログラム #include <stdio.h> namespace NS1 { struct HUGA {}; } namespace NS2 { int get(...) { return 1; } template <typename T> int f() { NS1::HUGA huga; return get(&huga); } int get(NS1::HUGA * ) { return 2; } } int main() { return NS2::f<int>(); }
136 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 20:01:56 ] うーん。もしかして、Cのソースがあるものなら、直接アセンブラソース吐かせれば良いんじゃね? バイナリを解析したいのならスマソ。
137 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 20:32:04 ] >>135 1
138 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 20:43:39 ] >>135 2
139 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 20:44:56 ] Visual C++2008では 2 になったけど 実際の動作は1にならないといけないみたいね。 vararg は言語によるすべての型チェックを無効にして 常にもっとも一致した型であることを強制するので 多重定義の解決では自動的に最優先になるみたい。
140 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 20:50:00 ] 俺も気になってやってみた。 g++ (GCC) 3.4.5 (mingw special)では返り値は1で、 Borland C++ 5.5.1 for Win32では返り値は2だった。 …つまりg++ 4.2.4はちゃんと正しい進化を遂げているということか。
141 名前:133 [2009/03/20(金) 20:54:37 ] >>136 がっつりexeファイルです。 コマンドプロンプトで動く簡単(そう)なコンパイラがあるので、それを解析してデコンパイラを作ってみたくて・・。 にしても、2ちゃんねるのスレッド検索って、「アセンブラ」とか「アセンブリ」で検索すると結果が出るのに、 「アセンブ」で検索すると出ないんですね。ふしぎ!
142 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 21:02:36 ] (...)の絡む名前解決の定義ってISO/IEC 14882:2003にあるの? もしなければ現段階では鼻から悪魔ってことになっちゃうんだけど
143 名前:デフォルトの名無しさん mailto:sage [2009/03/20(金) 21:21:21 ] よこから質問なんですが (...) ってどうつかうんですか? void func(int n, ...) みたいのであればstdarg.hのマクロでやるのとは思うんですが (...)みたいな...のみとはなんなんなんですか?
144 名前:135 mailto:sage [2009/03/20(金) 21:37:44 ] 試してくれた人ありがとうございます。 >>139 ...をvoid*にしても(2)はやっぱり1です。 ちなみにfの定義を非templateにすると両方とも 1になります。template関数が実体化されるときに 初めてオーバーロードの解決を行うっていう理屈で あれば(1)が正しいような気もします。 ただそれはあまりにもマクロ的な発想だし(2)が 正しい? NS1をNS2を書きかえると(2)が2に成るのも謎・・・。
145 名前:デフォルトの名無しさん [2009/03/20(金) 23:05:11 ] page4.auctions.yahoo.co.jp/jp/auction/d91264064
146 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 00:58:20 ] >142 もちろんある。 っていうか、SFINAE を使う場合に用いられる場合がある。 >139 そして ... のオーバーロード解決の優先度は最低だ。 >常にもっとも一致した型であることを強制するので これで優先されるのは関数テンプレートの時。 >144 > template関数が実体化されるときに > 初めてオーバーロードの解決を行うっていう理屈で > あれば(1)が正しいような気もします。 two phase lookup でぐぐれ。 dependent name の名前解決は実体化時まで遅延される。 nondependent name の名前解決は通常通り行われる。 get(&huga) は nondependent name なので名前解決は 通常通り行われ、この場合は get(...) に解決されるはず。 > 14882:2003 > 14.6 Name resolution/9 > If a name does not depend on a template-parameter (as defined in 14.6.2), a declaration (or set of declarations) > for that name shall be in scope at the point where the name appears in the template definition; the > name is bound to the declaration (or declarations) found at that point and this binding is not affected by > declarations that are visible at the point of instantiation. > > 14.6.3 Non-dependent names/1 > Non-dependent names used in a template definition are > found using the usual name lookup and bound at the > point they are used.
147 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 01:07:07 ] 補足。 >っていうか、SFINAE を使う場合に用いられる場合がある。 Modern C++ Design に優先順位が最低であることがポイントであるとした上で載ってるので 変態 templater にはそれなりに知られたテクニックだと思われ。
148 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 01:13:14 ] む・・・むずいw
149 名前:135 mailto:sage [2009/03/21(土) 01:20:21 ] >146 調べきれてないけど4.2.4の方が(規格的には)正しいような 気がしてきました。 NS2->NS1の書き換えはADLの関係でget(HUGA*)がヒット(2がかえる)。 だからget(HUGA*)を位置を変えずにNS1に持っていっても同様に 2がかえるのを確認しました。 get(void*)とget(HUGA*)をtemplate関数の特殊化とした場合 同様に2がかえる。 => depend name? それ以外の場合(オーバーロードの解決)は純粋に出現 順序で決定されると。 => nondependent name? もうちょっと調べてみます。ありがとうございます。
150 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 01:20:51 ] 解決されるときに(...)の優先度が最低になるのが見付からないなぁ ま事実だけ覚えときゃ十分か
151 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 01:48:31 ] >149 「NS2->NS1の書き換え」ってどこ書き換えたの? テンプレート引数 T に依存するかどうかが dependent name かどうかの判断なので、 4.2.4 の挙動もおかしい気はする。 >それ以外の場合(オーバーロードの解決)は純粋に出現 >順序で決定されると。 先に宣言されたものが常に選ばれるみたいに読めて微妙。 >150 13.3.3.2/2
152 名前:135 mailto:sage [2009/03/21(土) 02:32:23 ] >151 > 「NS2->NS1の書き換え」ってどこ書き換えたの? 135のサンプルを「NS1->NS2の書き換え」の間違えです。 まとめると //1を有効 & 他無効 => 2 //2を有効 & 他無効 => 1 //3を有効 & 他無効 => 2 #include <stdio.h> namespace NS1 { struct HUGA {}; } namespace NS2 { int get(void*) { return 1; } // int get(NS1::HUGA * ) { return 2; } //1 template <typename T> int f() { NS1::HUGA huga; return get(&huga); } int get(NS1::HUGA * ) { return 2; } //2 } namespace NS1 { // int get(NS1::HUGA * ) { return 2; } //3 } int main() { return NS2::f<int>(); }
153 名前:135 mailto:sage [2009/03/21(土) 02:42:13 ] 補足 152のサンプルは3.3.6では全部2になります。 4.2.4みたいにADLの対象か否かで解決遅延対処になるか 否かってのはなんかしっくりこない・・・。
154 名前:127 mailto:sage [2009/03/21(土) 05:46:58 ] >>128 でたらめな比較結果を返す関数を与えた場合の動作は未定義なんですね。 致し方ないので既知の問題としてドキュメントに記載してユーザに注意 してもらうことにします。ありがとうございました。
155 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 08:00:42 ] 比較関数全体をユーザ定義にするんじゃなくて、比較処理はC++で書いて、 条件を(比較結果がデタラメにならない程度に)カスタマイズできるように すればいい気がするなぁ。
156 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 13:19:32 ] for_eachについて教えてほしいのですが、下記のコードでfor_eachの三番目の引数である CPrint()に引数を設定ていないのにveciTableの要素が、void operator()(int iValue) 〜へ渡されているのはどうしてですか? #include <vector> #include <algorithm> #include <cstdio> using namespace std; struct CPrint { void operator()(int iValue) { printf("%d\n", iValue); } }; int main() { vector<int> veciTable(3); veciTable[0] = 111; veciTable[1] = 222; veciTable[2] = 333; for_each(veciTable.begin(), veciTable.end(), CPrint()); return 0; }
157 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 13:22:22 ] >>156 CPrint()(veciTable[0]) などのように operator () が呼び出されるから。
158 名前:デフォルトの名無しさん [2009/03/21(土) 13:22:33 ] std::tr1::bindですが、↓がコンパイルできません。 Aのメンバ関数に引数を渡したいのではなくて、X::funcBにAを渡したいのです。 どうすればいいでしょうか。 class X { class A { ... }; void funcA(void) { for_each(container.begin(), container.end(), std::tr1::bind(&X::funcB, _1)); } void funcB(const A& a) { ... } std::vector<A> container; };
159 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 13:24:23 ] >>158 エラーメッセージは?
160 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 13:26:23 ] >>158 X のインスタンス指定が抜けてるよ。 std::tr1::bind(&X::funcB, this, _1) でいけるんじゃない?
161 名前:158 mailto:sage [2009/03/21(土) 13:46:42 ] >>160 であっさりうまくいきました! 昨日一晩の苦労が…。感激です。 >>159 thisがないときのエラーメッセージは(VC9ですが) 「error C2825: '_Fty': '::' が後に続くときは、クラスまたは名前空間でなければなりません」の後 「テンプレートのインスタンス化 'std::tr1::_Result_type1...' の参照を確認してください」という bind特有の長いメッセージが続きます。
162 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 14:21:43 ] 長文で申し訳ない。 >153 やっぱり 4.2.4 の挙動もおかしいと思う。 インスタンス化時点での名前解決の対象になるのは ADL のみみたいだけど、 そもそも、テンプレートパラメータに依存する dependent name に対するものだけなので。 ぴったりしたケースじゃないけど 4.3.1 に対してこんなバグレポもあがってるので、 gcc の挙動をそんなに信用できないと思う。 ttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=36883 テンプレートパラメータに依存しないものならインスタンス化を待たなくとも結果は変わらない はずだし、遅延すると通常の名前に対するものと異なる直感に反する結果を与えかねないので、 定義時点で名前解決を行えばいい。 一方、テンプレートパラメータに依存する名前について定義時点のみで名前解決を行うとすると、 制約が強すぎる。例えば STL を使う場合、コンテナのヘッダをインクルードする前にコンテナの要素型と 必要な操作が宣言されていなければならない。 従って、インスタンス化まで名前の解決を遅延したいが何でもかんでも名前解決の対象にすると、 これまた直感に反する結果を与えかねない。 ということで、ADL のみに制限しているという理解。 ……なんだが、14.6.4 の規定自体に問題がある気がしてきた。 ADL じゃない lookup はインスタンス化時点では行わないようにも読めるんだが、qualified name lookup も インスタンス化時点で行われないと、dependent name な基本クラスのメンバにアクセスできなくなるので そんなわけないと思うのだが。 C++ Templates The Complete Guide では dependent qualified name もインスタンス化時点で名前解決されるって 書いてあるんだが、一方、インスタンス化時点で名前解決されるのは ADL のみという記述も結構見かける。
163 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 14:27:34 ] g++の挙動はおかしいから 有名なソフトじゃ禁止コーディング規約いっぱいあるよ C++のインプリで世界最悪なのがg++だし
164 名前:デフォルトの名無しさん [2009/03/21(土) 20:10:57 ] アンチg++必死だなw
165 名前:135 mailto:sage [2009/03/21(土) 20:28:38 ] >162 つまみ食いみたいなレスになりますが・・・ >gcc の挙動をそんなに信用できないと思う。 私もgccのbugzilla幾つか確認したけどアサインされてないバグって 結構いっぱいありますな。外野があれこれいうのもなんだけどあれで C++0x対応が収束するのやら。 > ということで、ADL のみに制限しているという理解。 そもそもオーバーロードは遅延名前解決の対象になるのか? 152の//3はnamespaceが違うのでget(void*)とはオーバーロードの 関係ではないわけで、そういう風に考えると、名前解決が遅延するのも 自然な気がしてきました(w f()内でget呼び出しがTに依存していないのにも関わらず 名前解決が遅延するのがバグであったとしても、 本来はTに依存させて使用するのが普通で、そのバグを 前提にしたロジックを組まなければ何とかなるかと。
166 名前:デフォルトの名無しさん mailto:sage [2009/03/21(土) 21:19:05 ] >165 > そもそもオーバーロードは遅延名前解決の対象になるのか? > 152の//3はnamespaceが違うのでget(void*)とはオーバーロードの > 関係ではないわけで、そういう風に考えると、名前解決が遅延するのも > 自然な気がしてきました(w 名前解決(というより照合と呼ぶべきかもしれないが)とオーバーロードの解決は別のステップで、 まず名前の解決を行い、その後、名前解決によって発見された候補関数群から、呼び出すべき関数が 選び出される(これがオーバーロードの解決)。 なので、名前の解決が遅延された時点でオーバーロードの解決も遅延される。 ちなみに、private とかのアクセス制限が確認されるのはこの後。
167 名前:デフォルトの名無しさん mailto:sage [2009/03/22(日) 01:01:10 ] >>163 >C++のインプリで世界最悪なのがg++だし いるいる、「絶対○○」とか「世界一○○」とか何の根拠もなしに比較したかのように語る人w
168 名前:デフォルトの名無しさん mailto:sage [2009/03/22(日) 01:28:11 ] ここの住人は頭がみんな良さそう 名前空間なんて、 松坂大輔 宮川大輔 のようなものとしか理解してないんだがな、俺的には。
169 名前:デフォルトの名無しさん mailto:sage [2009/03/22(日) 02:52:53 ] よくわからんけど、gccは新しいのでやってくれ。windowsもlinuxも4.3.3以前のは入れてない。
170 名前:デフォルトの名無しさん mailto:sage [2009/03/22(日) 13:12:11 ] gccについて疑問に感じたのなら、本家のforumが待ってるよ。
171 名前:デフォルトの名無しさん mailto:sage [2009/03/22(日) 16:44:02 ] >>169 gccの4.x系は、Linux上での動作はいいが、Windows上での動作は問題があるって聞いてるんだが。 だからMinGWも最新安定版はg++は3.4.5なんだと。 (アルファ版なら4.x系もあるだろうが。)
172 名前:デフォルトの名無しさん mailto:sage [2009/03/22(日) 16:46:44 ] gcc の話は↓こちらでどうぞ。 GCCについて part8 pc11.2ch.net/test/read.cgi/tech/1192201659/
173 名前:デフォルトの名無しさん mailto:sage [2009/03/23(月) 12:22:42 ] 聞いた話じゃなぁ
174 名前:デフォルトの名無しさん mailto:sage [2009/03/23(月) 23:18:14 ] 心を振るわせる話なら信用するのに どうして鼓膜を振るわせる話は信用しようとしないのだ。
175 名前:デフォルトの名無しさん mailto:sage [2009/03/24(火) 00:30:19 ] 質問です ソースファイルAでnewしたインスタンスを 別のソースファイルBでdeleteしたりしても大丈夫なんですか?
176 名前:デフォルトの名無しさん mailto:sage [2009/03/24(火) 00:39:08 ] インスタンスの実体が対応してれば大丈夫だろ
177 名前:デフォルトの名無しさん mailto:sage [2009/03/24(火) 01:03:40 ] 変な設計だとは思うけどな
178 名前:デフォルトの名無しさん mailto:sage [2009/03/24(火) 02:43:52 ] コンストラクタをcppに書いて、デストラクタをインラインでヘッダに書けば普通に起こる状況だな
179 名前:デフォルトの名無しさん mailto:sage [2009/03/24(火) 08:21:36 ] クロスDLL問題ってのとは全くの別物だよね? そもそもどうしてあれはダメなんだろ?
180 名前:デフォルトの名無しさん mailto:sage [2009/03/24(火) 09:21:41 ] それは、それぞれでnewとdeleteの実装が別物だとうまくいかないという話。 msvcr90.dllですべて統一するとか、shared_ptrのようにdeleteごと渡すとかすればいい。 そして、コンパイラが違うとvtblやRTTIの形式が違うという話へ続く……。
181 名前:デフォルトの名無しさん mailto:sage [2009/03/24(火) 09:28:56 ] そんな面倒事に悩まされる前に一つのモジュールに閉じ込める工夫に労力注げ…と
182 名前:179 mailto:sage [2009/03/24(火) 09:35:57 ] >>180-181 へーそういうことか。 ありがとう!