【初心者歓迎】C/C++室 Ver.50【環境依存OK】

>>944
＞後者の方がすこし速いと聞いたのですが
>>948の人の説明の通りだけど、例を挙げてみる。

sizeof(test)==1MBだとして（あえて極端なサイズで説明）
前置だと、インクリメントして自身の参照を返すだけ。
後置だと、1MBの実体をtmpとしてコピーして、
自身をインクメントして、tmpを返す(値渡しになるのでまた1MBコピー)

つまり後置だとコピーコンストラクタが２回追加される。
２回目についてはmove semanticsを使えば緩和出来るけど。

>>952
それどのコンパイラ？
コピーコンストラクタがインラインならほとんどのコンパイラで
確実に最適化されるって思ってるんだけど違うのか？
それに説明するなら一般的な例で頼む。極例はずるいよ。

場合によってはほとんどのコンパイラで確実に最適化される
↓
場合によっては一部のコンパイラでは最適化されない
↓
前置インクリメントでいい場合は前置を使っておくと速いかもしれない
↓
(平均すれば)後者の方がすこし速い

って流れでしょ。

サイズが極端なだけで例としてはごく一般的だよ。
a++++++++;とかなら極端な例だろうけどさ。

>>953
ずるいとか言われても(；´д｀）

最適化出来るコードなら最適化されるだろうし、
出来ないならされないよ・・・

「後置＞前置」なコストと言ったつもりは無かったんだけど、
「後置≧前置」と補足しておいた方がよかったかな。

>>955
質問文みるかぎりイテレータだろうし、1Mのデータはポインタで保持だろうし、
参照カウンタ使うなり真っ当に実装してればセフセフだし、ちょっと大袈裟じゃない？

と思ったけど、まあ確かに確認した方がいいのかもしれない。。。

VC2005使ってるんだけど、名前空間stdってどこにあるの？
とりあえず<new>とか<memory>などをインクルードしたら使えるようになるんだけど

翻訳単位で検出できればどこにだってあっても良い。
後方参照も可能。

違う話題ですが、C++で、deleteに、
1. delete オブジェクトへのポインタ
2. delete [] オブジェクト配列へのポインタ
の二種類ある理由が良く分かりません。
配列かどうかは、内部的に分かりそうなもので、1と書いても
自動的に判断してもし、newで配列として確保された物のポインタ
であるなら、2の意味と捉える事がどうして出来ないのでしょうか。
そして、もし、間違って逆に記述してしまった場合、どうなるの
でしょうか。

配列かどうかは、内部的に分かりそうなものでもないです。

配列をただのdeleteでやるとオブジェクト一つ分しか消してくれなかったはず

>>961
それはたまたま。それを当てにしてはいけない。

CObj *pObjs = new CObj[100];
として、
delete [] pObjs;
で配列全体を削除出来ると言うことは、100個分であるという情報
は、内部的に分かっているんですよね。
なら、
delete pObjs;
としても、100個まとまったメモリブロックだと言う判断は付く
と思うんですが。

>>963
無理です＾＾

ありがとうございます。
後置よりも前置がよい場合がある理由はわかりました。でも、現実には、実装方法が、
++i ===> int &operator++();
i++ ===> int &operator++(int);
となってますが、
++i ===> int &operator++(int);
i++ ===> int &operator++();
となっていても別に直感に反していないような気がするのですが、
何か、現実の実装方法が、「なるほど、理にかなってる」と思えるような理屈はないでしょうか？

>>964
なぜ?

>>966
コンパイラ製作会社に問い合わせて独自拡張規格で何とかならないかきいてみたらどう？

>>958
とりあえず<new>とかをインクルードしとけばいいってことですか

>>968
名前空間には使用に先立つ明確な宣言などは特に必要ない。
翻訳単位で後に検出できれば問題ない。

後に検出できるためにインクルードしてるってことでいいですか

>>970
何がしたいの？
stdにある<new>の機能を使いたいの？
名前空間自体は別に使用に先立って特に何もしなくてもいいけど、
名前空間にある関数やクラスなどについては当然ながら宣言や定義が必要だぞ？

#include<new> しないとstd::bad_allocが使えない状況なんで、それを使いたいんです

すれば良いだろ

>>959
そりゃもちろんdelete1本に絞って、
delete内部で配列かどうか判別するという方法も考えられる。
実装は別に難しくないだろう。全ての単体のnewをnew[1]相当にすればいいだけだ。

だが、そんなオーバーヘッドを許さなかったのが（当時の）C++クォリティ。
D&Eを引いてみてもやっぱりそういう理由のようだ。

>>972
それはstdを使いたいのではなく、std::bad_allocを使いたいと言う。

ごめんなさい

>>974
>>959じゃないけど、やっぱりそういう理由なんだ。

卓上デバッグの時代だからな。

>>963
最適化のため、そういう保証を課してない。
deleteのときは「何個分か」を見なくて済む。

>>965
D&Eにそれに関する記述がある。
簡単に書くと、
「キーワード使う構文とか考えたけど、
キレる人が結構居たので結局これに落ち着いた。
他の単項演算子は前置形なので、前置インクリメントも同じく引数無し、
(int)は後置のマークとした。
C++の中で異質だけど、十分有効だろう」
とのこと。

>>957
std配下のクラスを使いたいってことだよね？
ヘッダファイルが分かれてるから、必要なものをインクルードすればおｋ
std:vectorなら<vector>, std:listなら<list>といった感じ。

卓上でデバッグか。卓上でやることといえば徹マン明けの点数計算くらいしかない俺とは大違いだな。

fopenが成功した段階で、メモリ上にファイル内容があるんですか？
それともfreadするたびにHDDにアクセスしてコピーするのかどっちなんでしょう

試しにブレイクしながら1GBほどのファイルを読み込んでみればすぐわかることじゃないかな？

>>981
普通はCライブラリとOSでキャッシュするが、
キャッシュサイズとかタイミングは処理系依存。
でも巨大ファイルを全部キャッシュするようなことはしないだろうね。

ありがとうございました

次スレ誰か頼むぜ

979の人、ありがとうございます。
なるほど、単項演算子は前置だし、定義するときは引数なしでやるから、という論理か。
ところでD&Eっていいですね。俺もそろそろ読む時期がきたかな。

作ったよ。
ところで、version番号は59にしたけど、これでいいかな。
ttp://pc11.2ch.net/test/read.cgi/tech/1206809426/

>>987
ごじゅう・・・きゅう！？

59？ずいぶんすっとんでない？

次は52か53くらいじゃなかったっけ？

デバイスコンテキストハンドルについてなんですが
BeginPaint()で取得したHDCを
自作描画クラスのメンバ変数HDC*へ代入してクラス内で使用しても大丈夫でしょうか？

HDC hDC = BeginPaint( hWnd, &ps );

MyDraw mydraw(&hDC); //HDCのアドレスをコンストラクタで取得してメンバ変数として使いまわしたい
/*
色々な処理
*/

EndPaint( hWnd, &ps );

>>988-990
いや、結構長い間50で停滞してたし、一回51になったこともあったけど、また50に戻ったりしてるから、、、これくらいかな、と。
だいたい、１つのスレの寿命が1〜3ヶ月くらいだとおもうので、50から59の飛躍といっても4〜5ヶ月くらいの飛躍でしょ。

>１つのスレの寿命が1〜3ヶ月くらいだとおもうので、50から59の飛躍といっても4〜5ヶ月くらい
(´･ω･｀)？

>>992
記憶によると50→51→50→？だから次は53くらいだと思うんだが… 59は飛び過ぎじゃね？

まぁ同じタイトルのスレが乱立してなければ最新なのがわかるからいいよ

>>991
EndPaint以降にそのhDCを使い続けることが無ければ、問題ないよ。

おまんこおーぷん(あいつのなまえ)

res997.bokki();

>コンパイルしています...
>error: bokkiは実装されていません

猫も杓Cもプログラミング

1000生トイレ！

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。