C/C++小心者スレッドPart1

1 名前：デフォルトの名無しさん mailto:sage [2007/08/05(日) 06:18:18 ] プログラミング言語C/C++についての、小心者向けスレです。質問・要望・雑談などどうぞ。 関連スレやURLは>>2以降。 ■質問する人へ 質問する前に次の3つをすること。ここで回答を待つよりそのほうが早い。 　・ぐぐる 　・マニュアルで探す  　・FAQを読む 例えば www.bohyoh.com/CandCPP/FAQ/index.html 質問には以下を書くこと。へたくそな質問は再提出を要求される。 　・詳しい内容（「動きません」「うまくできません」では回答しようがない） 　・エラーメッセージ（なるべくそのままで） 　・実行環境（OS名、コンパイラ名） 　・最終的にやりたいこと（もっとよい方法がある場合が多いので） 回答してくれた人には「ありがとう」のひとことをいってあげて。 ■回答する人へ  相手は小心者、根気よく育てるつもりで。質問がへたくそなのも大目にみてあげる。 それができないならこないこと（だって小心者スレだもん）。 　・既出な質問やFAQは「XXXを読め」でいいので、叩かない＆怖がらせない。 　・わけわかな質問にもエスパー発揮で。できれば質問の仕方を教えるぐらいで。 　・自信がない回答ならその旨表明すること。誤った回答は初心者じゃ見抜けない。 宗教的な話題は禁止します。 856 名前：デフォルトの名無しさん mailto:sage [2010/03/07(日) 21:01:36 ] >>854 > C/C++にそんな型は存在しません。 小心者スレッドなんだからまあ良いではないか。 >>853 どんなコードでコピーしたの? そもそもBYTE型に256以上の値は入らないし、DWORDだったら4バイトだよね。 857 名前：854 mailto:sage [2010/03/07(日) 21:21:41 ] >>856 > 小心者スレッドなんだからまあ良いではないか。 一応 小心者 向けに多少はしたつもりだったんだが、 俺の言い方はやっぱまだ厳しかったか。 スマン 858 名前：デフォルトの名無しさん mailto:sage [2010/03/07(日) 21:40:13 ] コード見たほうが早いなたぶん 859 名前：853 mailto:sage [2010/03/08(月) 00:08:15 ] >>854-858 ありがとうございます、memcpy使えば良かったですね、 他の事に気がいっててそんな事にも気付かなかった、 orz あとDWORDは4バイトだったんですね、ご指摘ありがとうございました。 860 名前：デフォルトの名無しさん mailto:sage [2010/03/08(月) 10:55:08 ] 配列ならポインタを強引にキャストするだけでもよくね メモリ上の配置の把握が必要だけど、memcpyするにしてもそれは必要だし 861 名前：デフォルトの名無しさん mailto:sage [2010/03/08(月) 12:43:22 ] >>860 エイリアシングルールというものがあってだな。 www.radiumsoftware.com/0304.html#030408 862 名前：デフォルトの名無しさん mailto:sage [2010/03/09(火) 03:46:00 ] 8bit変数配列→32bit変数、ってだけならunion作れ 8bit変数配列→32bit変数配列、とかならどうしたもんだか 863 名前：デフォルトの名無しさん mailto:sage [2010/03/12(金) 22:33:09 ] unionつかったらエンディアンの問題はどうするの？ 864 名前：デフォルトの名無しさん mailto:sage [2010/03/12(金) 23:04:11 ] 2倍あるいは1/2倍していたところをビットシフトに書き換えたら、若干遅くなりました。 同じかそれ以上の速さになることはあると思っていましたが、遅くなるとはどういうことなんでしょうか？？ CPUには乗算や除算のほうが高速に行える回路が付いてるんでしょうか？？ 865 名前：デフォルトの名無しさん mailto:sage [2010/03/12(金) 23:45:00 ] >>864 推測ではどういう風にでも考えられるので コンパイラにアセンブリを吐き出させてみればどうでしょう 866 名前：864 mailto:sage [2010/03/13(土) 01:38:25 ] >>865 ありがとうございます。 アセンブラは読めませんが、がんばって解読してみます。 867 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 10:20:26 ] >>863 気になるなら#ifdefするなり効率落として変換関数書くなりすればいいんじゃね 綺麗で効率いい方法は知らん 868 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 10:40:47 ] 絶対にWindowsでしか使わないのにクロスプラットフォームで書きたくなる病とかあるよな 869 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 12:11:15 ] >>868 できる限り標準に準拠するのは正しい態度だと俺は思うよ * ずっとWindowsだけの仕事をするとは限らん * 元々Windowsだけのつもりでもコードの一部流用とかすることがありうる 870 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 13:45:37 ] 8bit配列→32bitなんていう処理についての話からの流れだからなぁ 汚くする理由の無い部分は綺麗に書くのが当然だが、エンディアン絡みの処理を すっきり綺麗に効率良く、って訳には行かんだろ現状 871 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 14:15:49 ] >>869 * 言語標準に準拠しつつクロスプラットフォームではないコードは極めて一般的 * OS標準に準拠しつつクロスプラットフォームでないコードは言うまでもなく一般的 * そもそも「絶対に」という前提の話 まず、クロスプラットフォームと規格準拠は全くの別物。前者の需要は極めて稀。 Windowsアプリを書く時にクロスプラットフォームにしようとするのは、かなり病的 にならないと困難だと思うぞ。犠牲も大きいし。 872 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 15:25:22 ] Qtとかの外部ライブラリを使えば クロスプラットフォームでも楽に書けるぞ。 873 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 21:57:02 ] >>871 プラットフォーム依存性が必要無いところは敢えて依存性持たせない方が 良いと俺は思うけどな 必要もなくプラットフォーム依存してるコードもよくあるが 元々絶対に流用しないつもりでも一部切り貼りって結構あると思うぞ 874 名前：デフォルトの名無しさん mailto:sage [2010/03/13(土) 22:02:26 ] forループのインデクスすらDWORD使うサンプルとかあるからな 875 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 07:46:33 ] 程度問題だな。病気レベルの無駄なことはやらない方がいい。無理せずに依存無く 書けるなら当然その方がいい。 Qtは微妙だろ。必要も無しにあれを選ぶ理由は無いと思う。 876 名前：872 mailto:sage [2010/03/14(日) 10:36:59 ] 別にQtじゃなくても、とにかくクロスプラットフォームな外部ライブラリなら 俺の言いたいことは伝わると思うんで、適当に読み替えてください。 877 名前：デフォルトの名無しさん mailto:sage [2010/03/14(日) 15:01:47 ] クロスプラットフォームなフレームワークに乗っかれば クロスプラットフォームでも楽に書けるぞ。 ・・・当たり前だろｊｋ 878 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 00:23:17 ] 本気で細かいことをしようとするととても楽に書けるなんてもんじゃないから、 普通は細かいことをバッサリ諦めるしか無いのがクロスプラットフォーム 879 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 00:27:38 ] まぁGUIに関しては特にそうだよね 880 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 08:24:51 ] 独自機能は全部諦めることになるしなぁ 881 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 21:37:14 ] >>878 細かいこと気にしない方が逆にいいものできたりして… 稀かもしれんが 882 名前：デフォルトの名無しさん mailto:sage [2010/03/15(月) 22:23:42 ] >>881 「逆にいい」は稀かと あっても無くても関係ない、ならまだそれなりにある話だが CUIなら割と素直にクロスプラットフォームになりやすいけどな それでも、元の流れの内容をエンディアン違いにまで対応させようとしたら あまり綺麗には済まないが 883 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 21:46:48 ] CUIでも、実用品でクロスプラットフォームなコードになると大抵はマクロで個別に ソース分岐させてるけどな。C/C++標準だけで書ける実用品なんて小物だけ。 LinuxとBSD系ですら、パフォーマンスを実用レベルにする為には移植作業が必要に なったりする訳で。Windowsならなおのこと。 884 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 21:56:00 ] 標準の範囲ではWindowsでUnicodeファイル名を扱えないし ディレクトリすら作れないし バイナリファイルを標準入出力で読み書きできないし 大きなファイルのシークもできない 885 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 21:57:51 ] だからクロスプラットフォームなフレームワークに乗っかろうぜ と言ってるじゃないか。 だれもC/C++標準だけで満足はしないさ。 886 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 22:03:09 ] オープンソースだと、単にWindowsのUnicodeファイル名などは 切り捨てているものも多いな 887 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 22:18:27 ] そしてパスに空白を含むと落ちるクソアプリができあがると 888 名前：デフォルトの名無しさん mailto:sage [2010/03/16(火) 22:24:03 ] >>887 > そしてパスに空白を含むと落ちるクソアプリができあがると たまにそういうクソアプリが見つかるけど、 それが原因だったんかい！ 889 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 01:19:44 ] クロスプラットフォーム向けのフレームワーク使ったところで、問題の本質の ほとんどは解決しないよな 890 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 18:28:38 ] プラットフォーム依存性があるにしろオープンソースでクロスプラットフォー ムというと firefox, thunderbird, gimp, cygwin とか思いつくけど これらってクソアプリやへぼアプリの分類なの？ 891 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 18:58:00 ] cygwinは最近出た1.7まではUnicodeファイル名に対応していなかった 実のところ、Windows専用でも、Unicodeファイル名に対応していないプログラムは ものすごく多い、特にコンソールアプリケーションではそれが普通 892 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 19:20:32 ] >>890 必死に移植作業してマクロで分岐させるんならいくらでもクロスプラットフォームに なるのは当然だろｗ 893 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 22:53:58 ] >>890 firefox, thunderbird, gimp, cygwin が クソアプリやへぼアプリだったら そうじゃないアプリって世の中にほとんどないんじゃないか？ 894 名前：デフォルトの名無しさん mailto:sage [2010/03/17(水) 23:49:10 ] クロスプラットフォームなコードでもクソじゃないのはあると言いたいんだろ だが、あの辺のは「現実に十二分な需要がある」から、仕方なく「多大な手間を掛けて 複雑なコードを書いて」実現してるから、牧歌的な話からは程遠い 895 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 00:16:50 ] >>894 > クロスプラットフォームなコードでもクソじゃないのはあると言いたいんだろ クロスプラットフォームのアプリのほとんどが クソアプリだってことが言いたいのかい？ 896 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 00:19:05 ] クソアプリの定義にもよるんじゃないの 例えばlameは最優秀のMP3エンコーダーだが、Unicodeファイル名には対応していない 897 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 00:31:07 ] 英語限定ならば問題は大分少なくなりそうだな… 898 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 00:32:40 ] そうだな GUIの場合、IMEという難関もあるし 899 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 11:56:10 ] >>895 どう見ても真逆の意味にしか読めないが 900 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:05:23 ] コードは肥大するけどお勉強の為に非依存で書いてみました、でも誰も使いません けどね、ってのが無駄 自然に非依存なコードになるならそれでいいんだよ（エンディアンなんかは面倒な ことをしなきゃ非依存にはならんけど） 実需があるなら無理もしなきゃならないし、変態コードが肥大しても許される 901 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 12:08:51 ] 実装の手間自体もでかいが、テストの手間のほうがより悲惨だな クロスプラットフォームを本気で考えるのは、プロジェクトが大きくなってからで いいと思う 902 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 14:36:18 ] クロスプラットフォームにするほど 他人が使ってくれるかどうかっていうところがなw 903 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:14:36 ] >>900 > 自然に非依存なコードになるならそれでいいんだよ（エンディアンなんかは面倒な > ことをしなきゃ非依存にはならんけど） 素朴な質問だが通常のコーディングでなぜエンディアンを 生で扱わなければいけないの？ 904 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:20:57 ] >>903 誰かがエンディアンを持ち出したからだろ 905 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:21:42 ] >900ではないが 少なくとも画像や音声など、バイナリデータを弄る場合には必ずエンディアンの問題は 出てくるでしょ ネットワークプログラミングにおけるntohl()のように、ホストエンディアンを 意識せずに「ホストエンディアンと対象エンディアン（bigないしlittle）を 変換する関数」を複数用意することで、問題を解決できることが多いと思うけど 906 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:35:28 ] >>905 画像，音声，ネットワークだと生で扱わなくてもライブラリがあるんでは 自分で用意する必要は必ずしも無いはず 907 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 18:47:09 ] そもそも>>900を読んで「通常のコーディングでもエンディアンを生で扱わなければ いけない」とは読み取れないんだが 908 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 20:41:29 ] >>906 ま、ライブラリにおんぶにだっこでいい場合はそうだね ただ、例えばntohl()のようなものはホストエンディアンによってコードを 分ける必要はなくしてくれるが、「ここはネットワークエンディアンに変換する 必要があるのでntohl()を呼ぶ」ような仕事は残るわけだから、 エンディアンを意識しなくてよい、というわけではないよね 909 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 22:06:47 ] >>908 それはどういうライブラリ使うかじゃないか？ たとえば画像の時は「必ずエンディアンの問題は出てくる」というが， magick++ みたいなもの使えば「エンディアンを意識しなくてよい」 という状況だと思うけど違う？ 910 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 22:30:11 ] >>909 正直議論の意味というか、何にこだわってるのか、何を知りたいのか 全く理解できんのだけど…… magick++を使ったことは無いのでわからんが、まあ、そう言ってしまえば 何だってそうだといえるだろうさ 画像処理で言うと、ファイルフォーマット内のバイトオーダーは ライブラリによって隠蔽されるケースは多いと思う が、ライブラリにロードしてもらった32bitラスタ画像のピクセルフォーマットが ARGBかBGRAか、といったことは、ピクセルを弄る場合には結局必要になるわけだ 911 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 22:54:34 ] picture[y][x].a = 〜 みたいに使えるんでないの？ ロードの処理が重くなりそうだが。 912 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 23:01:06 ] >>911 一瞬意味が分からなかった、その.aはARGBのAか まあ、そういう実装は可能だろうね Cだと PutPixel(point, a, r, g, b) のような関数ないしマクロを使うんだろう 913 名前：デフォルトの名無しさん mailto:sage [2010/03/18(木) 23:13:43 ] >>910 画像処理と言ってもライブラリを使える場合もあるから 「必ずエンディアンの問題は出てくる」ということも無いということだよ magick++ とかを使ってできることをわざわざ車輪を再発明する事もない場合も多いし 具体的にピクセルをどう弄りたいわけ？ 914 名前：デフォルトの名無しさん mailto:sage [2010/03/19(金) 01:45:40 ] >>913 ああ、要するに「必ず」は言いすぎだろ、という突っ込みか 確かに言い過ぎたね 915 名前：デフォルトの名無しさん [2010/03/19(金) 12:22:01 ] Windowsでカレントディレクトリを取得する方法を教えてください 916 名前：デフォルトの名無しさん mailto:sage [2010/03/19(金) 12:36:42 ] GetCurrentDirectory() 917 名前：デフォルトの名無しさん mailto:sage [2010/03/27(土) 23:45:49 ] 失礼します。 C++を勉強中の初心者です。 ポインタを関数の戻り値する場合は関数内の宣言にstaticをつけなければならないという記述をよく目にするのですが、 以下のようにstaticをつけずにHoge hを宣言しても問題なくプログラムが動き、5が出力されます。どういうことなのでしょうか。 typedef struct{ int k; } Hoge; Hoge* func(int a) { Hoge h; h.k = a; return &h; } int main() { Hoge* h = func(5); cout << h->k; } 918 名前：デフォルトの名無しさん mailto:sage [2010/03/27(土) 23:59:25 ] >>917 Hoge h がスタック上に作られている場合、関数から帰ってきた 直後は問題ない可能性が高いが、もう1回func()を呼んだり 別の関数を呼んだりすると、おかしくなる可能性がある。 919 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 00:02:59 ] >>917 動くのはたまたまです 試しに、func(5) のあとに別の関数を呼んでみてください 別の結果になると思います 920 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 00:16:44 ] なるほど たしかにおっしゃるとおりの事態が起きました。 ありがとうございます。 あと実はこのことに直接関わるかはわからないのですが、 別のプログラムにおいて、同じように構造体のポインタを戻り値とする関数をつくって内部の宣言をstatic有りと無しどちらも試したところ、 staticをつけた方はmainを抜けるところで停止してしまいます。 関係があるのかどうかよくわかりませんが、もし心当たりがありましたらお教えいただけると幸いです。 921 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 00:23:11 ] >>920 ソースをcodepadに貼れ 言ってる事がよくわからない 922 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 00:25:57 ] >>920 そんなことで悩むぐらいならポインタでなく実体を返せばいいと思う Hoge func(int a) { Hoge h; h.k = a; return h; } 923 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 01:30:09 ] >>922 構造体の配列を返したかったので・・・ すみませんどうやら別のところで引っかかっていたようで、今解決しました。 どうもお騒がせしましてすみません。 924 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 03:13:39 ] つーか根本的に関数側で確保した構造体のポインタを返すのがキモイ 呼び出し側で（空でいいから）構造体を用意して、そのポインタを関数に渡して、 関数側はその渡されたポインタで構造体の中身を加工する、っつーのが普通だし、 そういう設計ならポインタを返す必要も無いしstaticも要らないし、static無しで ポインタ返しても別に問題無い 何でそうなるかが分からんようだと辛い 925 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 09:22:50 ] >>924 関数側で確保した構造体のポインタじゃなくて構造体を返すのもダメ？ 926 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 10:41:34 ] >>924-925 (コピーのオーバーヘッドはおいといて)1個の構造体や、固定長の構造体配列ならそれでもいいんじゃないの？ 任意個数の配列をポインタではなく値で返す方法ってのを俺は知らないのだけど、どんなのがある？ >>920 staticつけないのは論外として、つけてもポインタの指し示す先が共有されていることは理解してる？ int *func(int n){ static int a; a=n; return &a; } int main(void){ int a,b; a=func(1); b=func(2); printf("a = %d, b = %d\n", a, b); /* a = 2, b = 2 */ return 0; } 927 名前：926 mailto:sage [2010/03/28(日) 10:42:50 ] ごめ、すっとぼけてた。 int main(void){ int *a,*b; a=func(1); b=func(2); printf("*a = %d, *b = %d\n", *a, *b); /* *a = 2, *b = 2 */ return 0; } 928 名前：925 mailto:sage [2010/03/28(日) 13:39:27 ] デザインの問題だけどたとえば何かデータをファイルから読むとか 与えたデータから新しいデータを作るというときに const vector<double> parseData(double x,vector<double> v,...){ vector<double> v1; …vector 領域確保して，データを料理してv1に入れる… return v1; } int main(){ ... vector<double> vData(paseData(x,v,...)); } みたいなのはなぜいかんのかなと思って void parseData(vector<double>&v1,double x,vector<double> v,...){ …vector 領域確保して，データを料理してv1に入れる… } int main(){ vector<double> vData; paseData(vData,x,v,...); } みたいに必ず書かなきゃいかんのかな？（確かに昔Fortranとかはいつもこういう スタイルだったなぁ） 個人的には前者の方が直感的だけど 簡単のため vector の例にしたけどもちろん自分で定義したデータ class でも同じこと 929 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 13:40:41 ] コピーが発生したら嫌じゃん 930 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 15:38:13 ] コピーのコストが問題にならない状況でなら、その手も使った。 931 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 16:47:51 ] 関数内でnewしてshared_ptrで返せばいいよ 932 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 17:06:34 ] #include <vector> #include <memory> #include <iostream> using namespace std; using namespace std::tr1; shared_ptr<vector<double> > parseData(double x){     shared_ptr<vector<double> > v1(new vector<double>);     v1->push_back(x);     return v1; } int main(){     shared_ptr<vector<double> > vData(parseData(1.5));     cout << vData->at(0) << endl; } 933 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 20:14:03 ] 何でstatic付けると助かるのかを理解しない限り、いくらでも似たような問題で 引っ掛かると思われ 934 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 20:24:01 ] #include <iostream> #include <vector> using namespace std; int sum(vector<int> vec){ int ammount = 0; for(vector<int>::iterator it = vec.begin();it != vec.end(); ++it){ ammount += *it; } return ammount; } // 2ch行数制限回避 int main() { vector<int> v; v.push_back(1);v.push_back(2);v.push_back(3); cout << sum << endl; // 表示結果: 6 } はいいんだけど、sumを template <class T, T zero> T sum(vector<T> vec) { T ammount = zero; for(vector<T>::iterator it = vec.begin();it != vec.end(); ++it){ ammount += *it; } return ammount; } にして、main中のcoutの行をcout << sum<int, 0>(v) << endl;にすると a.cpp:8: error: dependent-name ‘std::vector::iterator’ is parsed as a non-type, but instantiation yields a type a.cpp:8: note: say ‘typename std::vector::iterator’ if a type is meant のようになっちゃう。vector<T>::iterator itをT vector::iterator itに変えても a.cpp:9: error: ‘template<class _Tp, class _Alloc> class std::vector’ used without template parameters a.cpp:9: error: expected initializer before ‘it’ になっちゃう。 どう対処すればいいんでしょう？ 935 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 20:29:52 ] >>934 ja.lmgtfy.com/?q=error%3A+dependent-name 936 名前：デフォルトの名無しさん mailto:sage [2010/03/28(日) 20:57:05 ] typename vector<T>::iteratorか。 937 名前：デフォルトの名無しさん mailto:sage [2010/03/29(月) 20:14:09 ] test 938 名前：デフォルトの名無しさん mailto:sage [2010/03/29(月) 20:59:59 ] 個人的にはそろそろ>>928前者のような直接値を返すのも VC10とかg++ 4.3とかめちゃくちゃ新しいコンパイラならはありだと思うようになってきた。 C++0xのおかげでコピー発生しなくなったから。 939 名前：デフォルトの名無しさん mailto:sage [2010/03/29(月) 22:17:32 ] それはちゃんと右辺値参照をアレするクラスを書いた時限定じゃないのか 全てライブラリのコンテナに限定するなら構わんだろうけど 940 名前：デフォルトの名無しさん [2010/04/07(水) 05:36:10 ] error: pointer to incomplete class type is not allowedってどういうことですか? 941 名前：デフォルトの名無しさん mailto:sage [2010/04/07(水) 05:40:42 ] >>940 そのまんまだろう。 942 名前：デフォルトの名無しさん mailto:sage [2010/04/07(水) 13:16:50 ] >>940 不透明ポインタあたりでぐぐれ

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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