C++相談室 part24

C++に関する質問はこちらへどうぞ。
ただし質問の前にFAQに一通り目を通してください。
また、テンプレートライブラリ(STL含む)に関する質問は
専用の別スレへどうぞ。

過去スレ、関連スレ、関連リンクなどはこちら>>2-15

■過去スレ■
　1　http://mimizun.mine.nu:81/2chlog/tech/piza.2ch.net/tech/kako/980/980175292.html
　2　http://pc.2ch.net/tech/kako/996/996640937.html
　3　http://pc.2ch.net/tech/kako/1003/10038/1003832761.html
　4　http://pc.2ch.net/tech/kako/1009/10090/1009071535.html
　5　http://pc.2ch.net/tech/kako/1014/10142/1014217496.html
　6　http://pc.2ch.net/tech/kako/1018/10184/1018454705.html
　7　http://pc.2ch.net/tech/kako/1021/10217/1021787032.html
　8　http://pc3.2ch.net/tech/kako/1025/10250/1025010364.html
　9　http://pc3.2ch.net/tech/kako/1027/10273/1027347982.html
　10 http://pc3.2ch.net/tech/kako/1029/10293/1029315669.html
　11 http://pc3.2ch.net/tech/kako/1032/10323/1032345774.html
　12 http://pc3.2ch.net/tech/kako/1035/10350/1035005882.html
　13 http://pc3.2ch.net/tech/kako/1038/10380/1038031395.html
　14 http://pc2.2ch.net/tech/kako/1041/10413/1041328679.html
　15 http://pc2.2ch.net/tech/kako/1043/10436/1043605481.html
　16 http://pc2.2ch.net/tech/kako/1045/10457/1045746245.html
　17 http://pc2.2ch.net/tech/kako/1047/10475/1047560042.html
　18 http://pc2.2ch.net/tech/kako/1050/10501/1050177746.html
　19 http://pc2.2ch.net/tech/kako/1052/10526/1052625846.html
　20 http://pc2.2ch.net/tech/kako/1055/10551/1055162298.html
　21 http://pc2.2ch.net/tech/kako/1057/10575/1057580107.html
　22 http://pc2.2ch.net/tech/kako/1060/10603/1060361082.html
　23 http://pc2.2ch.net/test/read.cgi/tech/1062690663/

おおーーーーまじでーーーー
乙カレーーーーー

■基本■
[C++ FAQ]
　http://www.parashift.com/c++-faq-lite/
　http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
　　Cとその仕様を比較しながらの解説なので分かりやすい。
　　***** 質問の前に必ずこの二つに目を通してください *****

[禿 Stroustrup]
　http://www.research.att.com/~bs/
[C++ Final Draft International Standard]
　http://www.kuzbass.ru/docs/isocpp/
　http://www.kuzbass.ru/docs/ansi_iso_iec_14882_1998.pdf
[JTC1/SC22/WG21 - C++]
　http://std.dkuug.dk/jtc1/sc22/wg21/

[C/C++ Users Journal]
　http://www.cuj.com/
[cppll (ML)]
　http://www.trickpalace.net/cppll/ (日本語)

■Books■
amazon.com　C,C++関連書籍
　http://www.amazon.com/exec/obidos/tg/browse/-/3956/ref=br_bx_c_1_3/

The C++ Programming Language
　http://www.amazon.com/exec/obidos/ASIN/0201700735/
　http://www.amazon.co.jp/exec/obidos/ASIN/475611895X/ (翻訳)
C++ Primer (3rd Edition)
　http://www.amazon.com/exec/obidos/ASIN/0201824701/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756140068/ (翻訳)
The C++ Standard Library
　http://www.amazon.com/exec/obidos/ASIN/0201379260/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756137156/ (翻訳)
Effective C++
　http://www.amazon.com/exec/obidos/ASIN/0201924889/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756118089/ (翻訳)
More Effective C++
　http://www.amazon.com/exec/obidos/ASIN/020163371X/
　http://www.amazon.co.jp/exec/obidos/ASIN/4756118534/ (翻訳)
Exceptional C++
　http://www.amazon.com/exec/obidos/ASIN/0201615622/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894712709/ (翻訳)
More Exceptional C++
　http://www.amazon.com/exec/obidos/ASIN/020170434X/
Effective STL
　http://www.amazon.com/exec/obidos/ASIN/0201749629/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714108/ (翻訳)
Modern C++ Design
　http://www.amazon.com/exec/obidos/ASIN/0201704315/
　http://www.amazon.co.jp/exec/obidos/ASIN/4894714353/ (翻訳)
C++ Templates
　http://www.amazon.com/exec/obidos/ASIN/0201734842/

■Compiler■
[GCC]
　http://gcc.gnu.org/
　(Windows上でのPOSIX環境構築 http://www.cygwin.com)
[Borland C++ Compiler]
　http://www.borland.co.jp/cppbuilder/freecompiler/
[.NET Framework SDK]
　http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=ja
[DigitalMars]
　http://www.digitalmars.com/
[OpenWatcom]
　http://www.openwatcom.org/
[Comeau]
　http://www.comeaucomputing.com/
[Intel]
　http://www.intel.com/software/products/compilers/
[Metrowerks]
　http://www.metrowerks.com/mw/default.htm

■Libraries■
[Boost]
　Boost http://www.boost.org/
　(日本語) http://user.ecc.u-tokyo.ac.jp/~s31552/wp/boost/
　(日本語) http://www.kmonos.net/alang/boost/
[STL]
　STLport http://www.stlport.org/
　SGI-STL http://www.sgi.com/tech/stl/
　STLFilt http://www.bdsoft.com/tools/stlfilt.html
　(日本語) http://www005.upp.so-net.ne.jp/episteme/html/stlprog/
　(日本語) http://www.wakhok.ac.jp/~sumi/stl/
[Loki]
　http://www.moderncppdesign.com/
　LokiPort-MSVC7 http://www.geocities.com/rani_sharoni/LokiPort.html
　LokiPort-MSVC6sp5 http://fara.cs.uni-potsdam.de/~kaufmann/?page=lokiport
[他]
　ACE http://www.cs.wustl.edu/~schmidt/
　Blitz++ http://www.oonumerics.org/blitz/
　flex++ Bison++ http://www.idiom.com/free-compilers/TOOL/BNF-15.html
[他ライブラリリンク集]
　http://www.trumphurst.com/cpplibs/cpplibs.phtml
　(日本語) http://www.kmonos.net/alang/cpp/lib.html

■Libraries■
[Boost]
　Boost http://www.boost.org/
　(日本語) http://user.ecc.u-tokyo.ac.jp/~s31552/wp/boost/
　(日本語) http://www.kmonos.net/alang/boost/
[STL]
　STLport http://www.stlport.org/
　SGI-STL http://www.sgi.com/tech/stl/
　STLFilt http://www.bdsoft.com/tools/stlfilt.html
　(日本語) http://www005.upp.so-net.ne.jp/episteme/html/stlprog/
　(日本語) http://www.wakhok.ac.jp/~sumi/stl/
[Loki]
　http://www.moderncppdesign.com/
　LokiPort-MSVC7 http://www.geocities.com/rani_sharoni/LokiPort.html
　LokiPort-MSVC6sp5 http://fara.cs.uni-potsdam.de/~kaufmann/?page=lokiport
[他]
　ACE http://www.cs.wustl.edu/~schmidt/
　Blitz++ http://www.oonumerics.org/blitz/
　flex++ Bison++ http://www.idiom.com/free-compilers/TOOL/BNF-15.html
[他ライブラリリンク集]
　http://www.trumphurst.com/cpplibs/cpplibs.phtml
　(日本語) http://www.kmonos.net/alang/cpp/lib.html

■関連スレ■
[【C++】template 統合スレ -- STL/Boost/Loki, etc.]
　http://pc2.2ch.net/test/read.cgi/tech/1047978546/l50
[【C++】Boost使い集まれ！]
　http://pc2.2ch.net/test/read.cgi/tech/1033830935/l50
[C/C++の宿題やらせてください。]
　http://pc2.2ch.net/test/read.cgi/tech/1058283913/l50
[初心者にVisual C++を教えるスレ]
　http://pc2.2ch.net/test/read.cgi/tech/1056280510/l50
[VisualC++(MFC限定)相談室]
　http://pc2.2ch.net/test/read.cgi/tech/1056584836/l50
[ATL 相談室]
　http://pc2.2ch.net/test/read.cgi/tech/1029029882/l50
[C/C++でのWindowsPrograming議論スレ(質問お断り)]
　http://pc2.2ch.net/test/read.cgi/tech/1049790146/l50
[COMの世界を斬る！]
　http://pc2.2ch.net/test/read.cgi/tech/981823340/l50
[managed C++ やろうぜ！！]
　http://pc2.2ch.net/test/read.cgi/tech/1014486422/l50
[C++Builder相談室]
　http://pc2.2ch.net/test/read.cgi/tech/1054280736/l50
[タダで使えるBorland C++]
　http://pc2.2ch.net/test/read.cgi/tech/1054390397/l50
[Code of the Nerds" Digital Mars C/C++]
　http://pc2.2ch.net/test/read.cgi/tech/1044210976/l50
[GCCについて]
　http://pc2.2ch.net/test/read.cgi/tech/1046179115/l50
[OpenWatcom C++]
　http://pc2.2ch.net/test/read.cgi/tech/1033433728/l50
[タダで最強！フリーC/C++コンパイラ]
　http://pc2.2ch.net/test/read.cgi/tech/1035882599/l50

ごく炉宇様

俺には7と8が同じに見えるぜ。

【C++】template 統合スレ -- Part3
http://pc2.2ch.net/test/read.cgi/tech/1066493064/
Borland C++ BuilderX
http://pc2.2ch.net/test/read.cgi/tech/1065260556/
C++Builder相談室 Part7
http://pc2.2ch.net/test/read.cgi/tech/1061594556/
C/C++の宿題をやらせて。おながい。13代目
http://pc2.2ch.net/test/read.cgi/tech/1064541405/

でも、実際のとこPart24まで着たらネタがないな〜

>>13
じゃあ、私を育ててください
ちなみにJavaからの移行組ですが
classを書くときに

class S{
private:
int id;
char* name;
public:
char* getName(){
return name;
}
int getId(){
return id;
}
void setId(int id){
this.id=id;
}
void setName(char* name){
this.name=name;
}
}

などと、
１．アクセサ経由でプロパティーにアクセスするようなコード書きたがる
２．メソッドの定義と実装をclass内に書きたがる

こういうのはC++の世界では嫌われますかね？

>>14
1…別に
2…インラインメソッドになるけどプログラムが肥大化してもいいならいいんじゃない

そもそも>>14のコードはどう見てもバグってて無茶苦茶だけど

>>14
嫌われます。

つーか折角のOOもどき言語なんだから、
publicに変数置くような馬鹿の方が嫌われるよ。

>>15
> 2…インラインメソッドになるけどプログラムが肥大化してもいいならいいんじゃない

>>14 ぐらいならむしろオブジェクトコードサイズは減るケースも多いと思うが。

アクセサはインラインメソッドでいいよ。
インラインにしないと関数呼び出しの分無駄だし。

char* name;
char* getName(){
return name;
}
void setName(char* name){
this->name=name;
}

この辺は意図してやってるんじゃなければホームラン級の馬鹿コードだが。

getterはconstメソッドにしてクラスの中身を変えない事を明示すべき。
int getId() const {
return id;
}

クラスの中身というかインスタンスの中身ね

>>14
別に普通じゃね？
アクセサにブレークポイント置けるしね。

ただ、俺思ったんだけどさ
>>14みたいなの手書きするのってｲｸﾅｲ!(AA略)よね。
マクロみたいなの書けない？

private_proparty(name_t, name)

みたいなのから

private :
name_t name;
void setName(name_t name_){ name=name_; }
name_t getName(){ return name; }

を自動生成すんの。
getNameとかキャピタライズはムリだろうけど。

>>23
この辺読んでね
http://pc2.2ch.net/test/read.cgi/tech/1062690663/761-

>>15､20
その辺のポインタ系は突っ込まないで下さい
確かに間違ってました
あとクラスの最後の中カッコにセミコロンもつけたすの忘れてました

まあ、問題はそこではなくて
こういう書き方はダメなのかな？と思ったわけです
特にメソッド（関数メンバか？）なんて外に書いてたら

void S::setName(char* name)｛・・・｝
などと、余計わかりずらい用な気がしてたんです

ちなみに名前は「俺達」じゃなくて「安達」です。すいません

わざわざ例外仕様書いてる人いる？
const std::string& getName() const throw() { return name; }
みたいな感じで。

>>25
宣言と定義を分離すると、ファイルの依存性を減らせる。何でもかんでもヘッダに書くと、
メソッド1つ書き換えるだけでフルビルド状態になって大変だぞ。

でも、俺も setter/getter 程度ならヘッダに書くけど。

>>27
そうそう、あとヘッダファイルの使い方がわかりません
というか、なぜこんなものが必要なのかと思うわけです

定数とか定義するのなら
ヘッダファイルとかソース内ではなくて
別のリソースに書いてそれから読み込ませるのが
いろんな意味でイイと思ってました
それとも、俺の知らない便利な機能があるのですかね？


関数のポインタは便利ですね

#define private_property(name_t, name) \
private : \
name_t name; \
void set_ ## name(name_t name ## _) { name=name ## _; } \
name_t get_ ## name(){ return name; }

使わね？

>>29
それはどうやって使うんですか？

クラス内で
private_property(hoge_t, hage)
って1行書くと、その部分が

private :
hoge_t hage;
void set_hage(hoge_t hage_) { hage=hage_; }
hoge_t get_hage(){ return hage; }

に置き換わるの。

>>29
setterとgetterはprivateなの？
型ごとにその変なマクロを書くの？

>>31
hoge_t がポインタだと憤死確定だな……。intrusive_ptr や shared_ptr と組み合わせて使うのが
吉か？

つーかマクロでやったらIDEのコード支援機能が効かなくなるんでないの？

あくまで例だよ
別に変じゃないよ

おまいら馬鹿じゃねーんなら応用を利かせろよ

応用してる暇があったら手動で書いた方が速いね。

安達さんに質問です。
Java使ってた人がC++使うことになった理由は何ですか？

どっちかってと、IDEなりエディタの入力支援でやれって感じだが。

つまらん話題だな

とりあえずそんな変なマクロ使ってるコード見たら窓から投げ捨てるね。

手動よりは頭いいよ
サルじゃねーんだから

>>39
で、getterとsetterを自動で書いてくれるC++用IDEはどこにありますか？

>>42
そもそもgetterとsetterの意義が分かってるならそんなｳﾝｺマクロは書かない。

おれマクロで23みたいなことよくするけど
ゴミですか？

>>45
まちがいない。

テンプレートで同じ様なことできない？

>>45
読込専用のプロパティやら、
書込だけ公開するプロパティを作りたい場合はどうするんですか？
全種類マクロ作りますか？

エディタのマクロかなんかで置換すりゃ一発な気も
うちのは変数宣言書いた後ctrl+/でgetter、setter出来ます

値をそのまま操作するだけのsetter/getterのマクロを使うぐらいなら、
変数をpublicにしたって同じじゃん。

>>49
get,setするものがプリミティブ型かどうかや、ポインタかどうかなども見分けるようにしているのですか？

>>50
分かってない香具師ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!

つーかマクロなら確かに意味ないや。
自分でメソッド書けば、そのままでも意味あるけどね。

>>50
変数のアドレス取られたりしないし、後々 Set するときに何かしたいとか言うこともあるかもしれないからな。
その時だけを考えてるようじゃまだまだ素人だぞ。

>>54
後々何かしたくてもマクロで作っちゃってたら結局作り直しだろ。

>>50
世の中にはpublic変数に代入範囲の制限をつけたり
継承したりとあとから変更したくなっても
簡単に変更できない言語があるんですよ。

ちなみに簡単に変更できるようになったものは
プロパティと呼ばれます。

>45
君の感性は素晴らしいよ

>47
できないよ

>48
作れば？

>49
アホですね

>50
意義がわかってないね

>53
後々マクロに仕込めるじゃん

結論

*********************************
getterとsetterをプリプロセッサで書くな。
*********************************

>>57
偽物は帰っていいよ

>>55
その部分だけマクロはずして手で書けばいいだけだろ。

こういうとここそプリプロセッサの出番なんだよ
わかってないやつ大杉でつね

>>31
そうか、そうでしたね
そのまま埋め込まれるみたいな機能がありましたね

>>38
いや、C++は仕事関係ではなく単に自分の趣味みたいなものです
JavaやらPerlやらC#やらやってきましたが
C/C++っていうのはあまり触れた経験がなかったのです
C言語をほんの入り口程度やっただけで
Javaに配属されましたから・・・
これじゃプログラマとはいえないなと、なんとなく思いまして・・・
なんか不安なんですよね
今までずっとC/C++はいつか覚えなきゃいかんと気になってましてね
で今回本屋でC++何とか第３版とか言う本買ってやってるんですが
Cからやった方がいいと自分で思ってます
でも、関数とかさっきのchar*とかの扱いとか考えても
クラスでやった方が自分としては理解が楽なので
C++からやってます

とりあえず、これ系のマクロは他者に嫌がられることが多そうだから使わない。

>63
そんなんじゃboostなんて使えないんじゃん？

boostとは訳が違うだろ

文字列置換してコード量が減ったと自己満足するだけの、
マクロの使用はカンベン。

boostの思想は理解してもいいと思うけど
個人それぞれの思想がたっぷり仕込まれたソースを複数見るのはいやだ。

23に同意
だらだらアクセサ書き並べるよりよっぽど健全だな

private_property(hoge_t, hage)
protected_property(hoge_t, hage)
public_property(hoge_t, hage)
private_readonly_property(hoge_t, hage)
protected_readonly_property(hoge_t, hage)
public_readonly_property(hoge_t, hage)
private_writeonly_property(hoge_t, hage)
protected_writeonly_property(hoge_t, hage)
public_writeonly_property(hoge_t, hage)
public_read_and_protected_write_property(hoge_t, hage)
以下省略

>>68
自演はいいよ

そもそもsetter/getterがずらずらならぶような状況はおかしくないか？

>>69
privateやpublicなんかもパラメータ化すればすっきりするよ

23って反応いいよね

>>71
モデルなら問題無いような気もする

やりたい事が実現出来るのなら好きなように組めばいいと思う…

で、マクロを使ったとしてIDEの補完が効かなくなる問題に対してはどう対処するの？

>>51
分ける事は出来てるんだけど、ただのキー操作マクロなんで
見分けるなんて凄い物ではなく、単に操作の違いだけっす。
何て言うかctrl+shift+←とshift+endです。

>>71
自分の経験だと、データベースのカラムが多い時は
どうしてもそうなるのがあたりまえなんですが
といか、入れ物としてclassを使う場合なのですがね

>>66
マクロ → ソースコード量削減 としか発想できない奴は帰れ。

>71
スタブとか変数の数だけ需要があるじゃん
リリースでは必要ないかもしれないけど

マクロによるプロパティの実装

良い所
ソースコード削減

悪い所
IDEの補完が効かなくなる


適当に追記して下さい。

>>79
23の例にコード量削減以外の意味があるのか？
マクロ使う以上はもっと確固たる理由ってもんがなければならないと思うが。

つーか自クラス内のメソッドからもアクセサ経由でメンバ変数にアクセスするのが正しいOOだろ

おまいらIDEの補完がそんなに重要か？
それよりもマクロ解釈しないIDEなんて使うな
って話が先じゃないのか？

>>83
ネタにしては面白くない。

マクロによるプロパティの実装

良い所
・ソースコード削減

悪い所
・IDEの補完が効かなくなる
・見通しが悪くなる
(特にC++ではpublic:やprotected:などのアクセス指定子が実際の変数宣言とは別の行にあり、
見やすい所にあるのが普通なので、なんでpublic:が無いのにアクセスできるんだとか他人が見たら勘違いする)


適当に追記して下さい。

>>85
マーチンファウラーのリファクタリング読んでね(はぁと

マクロを使うってのは、コード量削減以外にも
形式化って意味があるんじゃね？

>>87
自己カプセル化フィールドだな。
C++だとインラインメソッドにできるから速度低下も無いし素晴らしいな。

>>87
C++にそんなプログラミング流儀はありません。
C++の書籍でそんなコード見たことありません。

>>86
見通しが悪くなるというか、妙な汗が出てくる。
なんか実装側にもトリッキーな仕掛けがあるんではなかろうかと。

>>90
それはあなたが古い書籍しか読んでないからです

>>87
ケントベックの Smalltalk ベストプラクティスパターン pp.99-103 も読んでね。
匙加減が大切。

ISO/IEC 14882:2003 出てるみたいだけど、何が変わったのさ？

角度とか

ま　た　J　a　v　a　厨　か

>>77
うぉっ、できた、結構できるもんだな
こりゃ便利、使わせてもらうぜ、ありがとん

つーかC++使える香具師ってJavaも使えるのが普通じゃないの？

>86
>勘違いする

そりゃ仕様確認しない方が悪いんじゃん？
まー大掛かりになるならドキュメント化は必要だね

C++の本あんまりでないからなあ。
仕方なくJava系の設計本読んで脳内でMyNativeProgrammingLanguage C++に変換ですよ。

IDEの補完って、結局コピペと同じ事なんだよ
修正起きたら大変だろうよ
その辺わかってない奴大杉

ドキュメントが必要なものよりドキュメントが必要ないもののほうがいい。
原則だろ。

正直くどい…

なるほど。
23の言いたいことがなんとなくわかった気がする。

わかったからぼちぼち終わりにしてください。

とでも言わないと23はいつまでもこの話続けそうだからな…

>102
あのさ、
IDEの機能こそドキュメント化必須じゃん？

逆にマクロならその定義見りゃ良い話にならねえ？

そうですね。

はぁ。
それじゃ、また。

なるほど。
23の言いたいことがなんとなくわかった気がする。

>>23
お前友達いないだろ

メタプログラミングの話ですか？

だいぶ違います

と言っても話は続いてますが… >>104

23の考えを究極的に進めたのがboost。

方向性が違いそうですが

祭りの会場はここですか？

祭りとしてはｲﾏｲﾁだったな

僕、今から用事あるんでこのへんで失礼します。

メンバ関数内で勝手にメンバ変数の値が変わってしまう・・・。
式も無いのに何で勝手に変わるのかわけが分かりません。
なぜなんでしょうか？

超初心者の質問で申し訳ないですが

this->

の意味を教えて下さいませんか？

意図せず期待しないメモリ領域に書き込みしている

そういう時こそアクセサの出番ですがな。

これ->空白

>>111
友達ってなによ

アツく語ってくれる>>23はどこにいったんだYO!
はやく戻ってきてくれ〜！

>>121
名前がわり〜よ。

意図しない事になる例。

class A
{
char name[4];
int age;
public:
　setName(char* s) { strcpy(name, s); }
　setAge(int d) { age = d; }
　A()
　{
　　setAge(10);
　　setName("あいうえ");
　}　
　~A()
　{
　　std::cout << name << "," << age << std::endl;
　}
}

>>124
いや、プログラム的な意味を教えてほしいのです。

>>127
すみません。sageはメール欄でした。

>>126
お前、23氏をばかにしているの？
クラス内でマクロを使うなんて日常茶飯事じゃん
VC++しか使ってない奴は引っ込め。

そうですね。

>>129
クラスオブジェクトのポインター

>>129
ありがとうございます。うっすら分かってきたような．．．
this-> って省略されているんでしたっけ？
どこを調べても載ってない．．．

何で意図しないことが起こるのかわかりません

>>133
笑った

>>134
>128氏が答えの例をあげてます。
メンバー変数にどこかでコピーしてるから

>>134
コード晒されないとわかりません

>>134
"あいうえ"は何バイトかよく考えてみろ。

9バイトだね

17バイトだろ？

>>140
全角文字1文字==4バイトってコード体系あったっけ？ハードウェアで
強制されたら仕方ないが。

有名どころだとUTF32

>>141
終端文字が１バイトで済んでいそうなことから、マルチバイトのエンコーディングと
思われるが謎だね(笑)
俗に言うJISだと 3 + 2*4 + 3 + 1 で15バイトとか
UTF-8だと3*4+1=13バイトとか
まあエンコーディングによっていろいろだが
5バイト以上なのは間違いなさそうなので、いずれにしろメモリ破壊は期待できるか。

>>132
template 絡むと、それ以外の意味もあるけどな。

C++では構造体もコンストラクタや関数を持つことができますが、
この場合sizeofを使うと、変数のみのサイズが返されますか？

>>145
virtualな関数を含むと、そうではない。

>>145
メモリイメージとsizeofに関して、structとclassはまったく同じ。
virtual関数があるかどうかで変化する。

>>147
あと基底クラスを virtual 継承してる場合も、一般的にはポインタ一つ分サイズが増える。

BCD値(0x123456)を普通の整数型に変換するルーチンやその逆はないでつか？

>>149
C/C++の宿題をやらせて。おながい。13代目
http://pc2.2ch.net/test/read.cgi/tech/1064541405/l50

>>145
やってみろよ、すっげー簡単な実験じゃねえか
んで、そのコンパイラがまあ普通なコード吐いてるかどうかは
ARMかLippmanあたりを読めば判断できる

ARM: ISBN4-901280-39-2
Lippman: ISBN4-8101-8101-4

勉強のためにiostreamを派生させて
strstreamのようなものを作ってみたいのですが
参考になるページとかありませんでしょうか？

>>152
勉強のためとか言っておきながら、参考になるページって・・・。
iostream読んでも見当つかないのなら、もっと自分の実力に見合った勉強をするべき。

勉強をしているときは何一つ参考にしてはいけない。
これ基本。

>>152
まず標準ライブラリのstrstreamの派生のさせ方を勉強して、
それを真似ると簡単。

C++標準ライブラリ、チュートリアル＆リファレンスは標準C++
ライブラリを深く知りたい人の必携本。

●●●マスコミの「盗聴、盗撮」は許されるのか？その８●●● http://natto.2ch.net/mass/kako/1011/10115/1011522150.html
387 名前： 文責：名無しさん 投稿日： 02/02/21 23:49 ID:FEi+B6dZ
作業服を着ていれば盗聴工事をしてもバレにくいですからね。
通行人が見ても普通の工事だと思うし。屋根のぼっててもわからないでしょう。屋根の修理かな？ってね。
排泄行為とか入浴を盗撮されると嫌だね。あれはどうかと思うよ。

732 名前： 投稿日： 02/03/12 19:46 ID:aN/JDfka
４月のドラマを２ちゃんのドラマ板でチェックしてみると、盗聴ドラマらしき番組
がいくつかある。野島某が脚本を書く「ゴールデン・ボール」は、怪しい。こいつ
が盗聴を利用して俺の書き込みを追跡しているのは、知っている。盗聴に頼らない
で発案するのが怖いのか、あるいは、ジンクス担ぎか。繰り返すが、電話／ｗｅｂ
／メール盗聴で得た俺の個人情報をヒントにしておきながら、俺の人生観や趣味を
否定する内容であった場合には、番組をぼろくそに叩いてスタッフに呪いをかけま
すので、あしからず。ほとほどにしておけよ、日テレ。今年は、戦争モードだ。

おっとっと。std::strstreamは古い標準化以前のストリームだね。
std::stringstreamを使いましょう。std::strstreamは次の標準化で
消えるかもしれないと言っている。

マルチスレッドに適した開発環境とOS教えれ。

>>158
MS-DOS 3.3c

>>154
さすがに暴論

>>153-154
勉強のためにしてるときでも
何か参考にするくらいはいいのでは?

test

>>158
CZAR

普段windowsで開発しているのですが、RedHat向けにバイナリを配布したと
思っています。
RedHat9はインストールしてコンパイルできて正常に動作確認できました。
このバイナリはRedHat9でしか動かないということになるのでしょうか？
7,8でも動かしたいなら、7の環境でコンパイルすればイイ？？
どなたか教えてください。

>>164
Win以外はバイナリ配布いらんよ

>>165
rpmは？

rpmなんて環境依存だろうが

src.rpmでいいよ

-static付けてコンパイルすれば
大抵のバイナリーは大抵のLinux上で動くから
それでrpm作ればいい

>>167
rpmくらいどこでも動くだろう
Red Hatの7,8,9だったら

c++で、

void * subA( void * );

のような宣言は

void subA( void );

とどう違うのでしょうか

void型のポインタ(void*)を返すか何も返さないか。

>>172
void型のポインタってなんですか

>>173
正直、入門書の一冊くらい読んでから質問してほしいが。

>>173
void* が分からんレベルなら、ここで聞くより入門書書いたまえ。

>>171
もしかしてＹ大学の今日〆切の課題をやってますか？
自分もそうです（笑

お互い頑張りましょう〜

代々木アニメーション大学？

voidポインタとか引数にvoidとか、C++っていうよりC言語の話題だな

voidの単語の意味を調べるのがさきじゃないか？

ということにしたいのですね

>>179
void の意味調べても void* はよく分からない気がするんだが。
素直に入門書買わせた方が。

>>173
なんでもポインター。

ドラえもん？

C言語習いたてのころにvoidとvoid*の違いに戸惑うよな。
両者には大した関係もないということで。

>>104
　形無しポインタつーいみではvoid*でいいんでない？

>>171
>void * subA( void * );
引数にどんな型のポインターでも渡せる。そして、どんな型にでも変換できるポインターを返す。
>void subA( void );
引数は受け取らないし値も返さない。
そして､これらの関数が同じスコープに存在したらそれらの関数の事をオーバーロード関数という。

#define EMPTY_ARG void
#define ANY_POINTER void*
#define NO_RETURN_VALUE void

NO_RETURN_VALUE FunctionA (EMPTY_ARG);
NO_RETURN_VALUE FunctionB (ANY_POINTER);
ANY_POINTER FunctionC (EMPTY_ARG);
ANY_POINTER FunctionD (ANY_POINTER);

こうやって書いてみると「あーなるほど」と思う?
同じ void でも状況によっていろんな意味があるってことなんだがな

>>186
一応C++スレなので
void *はどんな型からも暗黙変換できるが、
どんな他の型にも暗黙変換でき「ない」ポインタ、だな。

>>188
>>186は「暗黙」とは言ってないぞ。

void
static
extern
*
&
・・・同じ単語/記号に複数の意味を持たせる流儀は何か技術的な理由があったのだろうか？

暗黙でなければどんなポインタからどんなポインタでも変換できるけどな

>>190
新しいキーワード考えるのが面倒だったんじゃない？
あんまりいい風習じゃないのよなぁ。

文字列を入力として受け付けて、その文字列中に含まれる数字の合 値を求めてみてください。
例: a1b23g4 と入力された場合、1+2+3+4 で10 を出力してみせてください。

>>193
コードを書けとは言ってないようなので、人力でやれということか。
スレ違いだな。(笑)

復改を表現するのに、バックスラッシュ記号をキーボードで打ち込もう
と思うのですけれど￥マークがでてきてしまいます。
バックスラッシュ記号を表示するにはどうしたらいいのでしょうか。

>>195
フォントを変える。

>>194
すいません。コードおねがいします。

おいおいC++スレだからCで答えられるような問題出すなよ。
それとも回答者が思いきりSTLとかboostとか自作のクラスを
使って答えるとか。

istream_iteratorとC++ localeの演習では無かろうか。

だってマルチだし

>>190
.
->
::
などガイキチとまで言うガイキチが後を絶たないが
そういうのは放置として、お主はどう思う？

漏れは根底にある思想には反対したくないが
結果はイクナイと思っている

>>193
それくらいならperl使え

>>201
結果がいくないというのは
具体的にどういうモノであれば
良かったということなのか?

RS232Cでデータの送受信をしようとして
フレーミングエラー等をClearCommErrorで
dwErrorsに入るエラーフラグでチェックできると思い
使ってたんですがOSがXPのときはうまくいっている?様だったのですが
Win98上で動かした場合常にdwErrorsにフラグが立っているようで
うまくいきません
RS232Cでの通信エラーのチェックはどうやったら良いのでしょうか？

->と::は正直イラネーと思う

>>204
先ずはスレ違いということに気づけ。

>>203
もっと、ポインタとスコープをきちんと理解させる教育運動をすべきだった
過度の放任が招いた今のくるくるパーばっかりの大豊作にあきれ果てている

その一端に、配列をポインタと同一視させる過度の偽装がある

意味わかんない

同一視してないじゃん
int a[20];
int *b;

b++;
a++; //error

教育現場の問題と言語仕様の問題をごちゃまぜにする奴がいなければ
あとはどうでもいい

>>208
まずはその偽装が仕様書のどこに記述されているのか
説明してごらんあれ

つーかそういう時代遅れの話はCスレでどうぞ

しかし、今どきCスレなんかに行ってもなあ

時代遅れな連中ばかりがウヨウヨして
ガセネタばかりで盛り上がってる現状を見ると
あそこはあそこで隔離スレとしての役目を果たすのに
精いっぱいではなかろうか？

>ガセネタばかりで盛り上がってる現状を見ると
ﾜﾗﾀ

>>214
C++の常識をCスレに書き込んで突っ込まれた人ですか。
ここに愚痴を書くのはやめてね。

C++オタがDelphiスレでウザイのですが、どうしたらいいのでしょう？

主婦なら主婦の仕事ちゃんとやってから質問しろ。

>>218
他の仕事の奴には言わないのに主婦だけ言うのなｗ

日本の景気が悪いのは主婦がC++の勉強をしないからだ

ゲーム用のキャラクタクラスで、今までこういう感じのつくりにしてました。

class Character
{
public
　　// ↓実際はもっといっぱい列挙してます。各種状態異常のフラグとか、装備とか。
　　enum PARAM{
　　　　LEVEL,EXP,HP,MP,MHP,MMP,STR,INT,VIT,AGI,DEX,LUK,
　　　　END};
　　void SetParam(int i,int n){ param_[i] = n;}
　　void AddParam(int i,int n){ param_[i] += n;}
　　void SubParam(int i,int n){ param_[i] -= n;}
　　int GetParam(int i){ return param_[i];}
　　static int StatusBegin(void){return STR;}
　　static int StatusEnd(void){return END;}
private:
　　int param_[END];
}

全能力値に+10とか言う場合、
for (int i=Character::StatusBegin();i<Character::StatusEnd();++i){
　　character_.AddParam(i,10);
}
という感じでかけて、製作過程でパラメータ数が変動しても
enumさえ変えればオッケーなので激しく楽……だと思ってたのですが、
デバッグのときにparam_[10]とかで確認せねばならず、すごく不便だと気づきました。
最初っからメンバ変数をint level_,exp_...;としておけばデバッグの時は
楽なんですけど、そうするとforでまわせなくて不便なのです……。
うまい解決策はないでしょうか？

電卓の機能を模倣するプログラムを作成しなさい。
わかりません‥
どなたか教えていただきませんでしょうか‥

>>221
ステータスの変数を全てparamの配列にしてるのがそもそも間違い。
ちゃんと別々の変数にして、全能力値に＋１０とかやる場合は１つ１つ書いていく。
それからアイテムや魔法の効果は別のスクリプト書いてやるべき。
ハードコーディングは実験の時以外はやめた方がいい。

ああ、変数を別々にやる方法もやってたのか。
forで回せないなんて言ってるけど、高々１０個程度の変数なら
そこにforを使ったぐらいでソースが短くなったりきれいになることはないからやめな。

>>221
デフォルトコンストラクタのデフォルト引数でも利用して最初に初期化。

>>223-225
ありがとうございます。邪道ではありますけど、とりあえずの対処策を思いつけました。

class Character
{
public
　　// ↓実際はもっといっぱい列挙してます。各種状態異常のフラグとか、装備とか。
　　enum PARAM{
　　　　LEVEL,EXP,HP,MP,MHP,MMP,STR,INT,VIT,AGI,DEX,LUK,
　　　　END};
　　void SetParam(int i,int n){ reinterpret_cast<int*>(this)[i] = n;}
　　void AddParam(int i,int n){ reinterpret_cast<int*>(this)[i] += n;}
　　void SubParam(int i,int n){ reinterpret_cast<int*>(this)[i] -= n;}
　　int GetParam(int i){ return reinterpret_cast<int*>(this)[i];}
　　static int StatusBegin(void){return STR;}
　　static int StatusEnd(void){return END;}
private:
　　int level_,exp_,hp_,mp_,mhp_,mmp_,str_,int_,vit_,agi_,dex_,luk_;
}

csvデータからバイナリデータに変換するツールでもこのヘッダを利用しますので、
enumを切るわけには行かなかったので、こうなりました。
無理やり感が漂ってますけど、ファイルからデータ読み込みしてみて
正常に動きましたので、とりあえずこれで行ってみようと思います。
（今はとにかく動かすのが優先な時期なので）

ちょっと怖いかも
内部union持たせた方が

>>227
最初にunionでどうにかならないかと検討してたんですが、
配列のサイズをenum値で決定するところで詰まってしまったんです；；
うまくいく方法ってあります？

>>228
マジレスしていいか？
配列にするメリット、全然なし。やめろ。

class Character
{
　　//...
private:
　　union PARAM0{
　　　　int RowParam[END];
　　　　struct PARAM1 {
　　　　　　int level_,exp_,hp_,mp_,mhp_,mmp_,str_,int_,vit_,agi_,dex_,luk_;
　　　　} param;
　　} param;
　　struct PARAM2{
　　　　int level_,exp_,hp_,mp_,mhp_,mmp_,str_,int_,vit_,agi_,dex_,luk_;
　　　　int & operator[](int index){return *(reinterpret_cast<int *>(this)+index);
　　　　int operator[](int index)const {return *(reinterpret_cast<int *>(this)+index);
　　} param2;
　　//ここからは気にしない方がいいと思う。
　　typedef std::map<std::string,int> ContType;
　　static ContType str2idobj;
　　static void Init(){
　　　　str2idobj["LEVEL"]=LEVEL;str2idobj["EXP"]=EXP;str2idobj["HP"]=HP;str2idobj["MP"]=MP;
　　　　str2idobj["MHP"]=MHP;str2idobj["STR"]=HP;str2idobj["INT"]=MP;str2idobj["VIT"]=VIT;
　　　　str2idobj["AGI"]=AGI;str2idobj["DEX"]=DEX;str2idobj["LUK"]=LUK;
　　}
public:
　　static int name2Id(const std::string & arg){
　　　　ContType::iterator p=str2idobj.find(arg);
　　　　if(p!=str2idobj.end()){return p->second;}
　　　　assert(0);
　　}
};

ところで >>221 よ、

"オブジェクト指向"

って言葉、理解しているか？

「理解しているか？」って質問もたいがい無意味だよな。
余計なターン消費しないでとっとと言いたいこと言え。

>>229
はい。ですから最終的には配列は消す予定です。今ほしいのは
とりあえずの急場をしのげる妥協案なので、配列のみバージョンとの
互換性を重視してます。

>>230
unionの記述方法、参考にさせていただきます。
あと、operator[]でリファレンス返せばいいんでしたね。そんなテクあったの忘れてました＾＾；
name2Idのほうは、csvからのデータ変換といっても、残念ながら"LEVEL"とかいう
文字列が入ってくるわけじゃないんです。
カンマ区切りの数字がどえーっと並んでて、このうち2列目〜5列目が能力値だから
数字の範囲は1-999,6列目〜10列目が状態異常フラグだから数字の範囲は0-1、
というようなときに、この2,5,6,10の代わりにヘッダのenum値を利用したい、という
ことなのです。この値が、わりと不定なので。
最終的にはこのenum値を利用しようとするのはあきらめることになりそうですけど。

>>231
厳密に議論しようとすると時間の無駄になる、とっても危険な単語である、
という程度までは理解できています。
とりあえず、なにがお気に触ったのかだけ教えてもらえればありがたいです。

>>232
今回も見事にあてはまりましたな

ふつうは素直にメンバ変数にしてアクセサをしこしこ書いて、
コンストラクタで設定してやればいいわな。
ファイルの書き出しメソッドも用意しとけば、呼び出し側で
ループする必要もないし。
なにより、仕様変更が起こって、パラメータの数や順序が
変わっても、メンバ変数とアクセサの追加、および書き出し
メソッドに少し手を加えるだけでいい。
データがどのように保持されているか考えなくて良い、という
のがオブジェクト指向の「情報隠蔽」のメリットなのだから、
仕様変更の度にパラメータとenumの値の対応を気にしている
現状は、とても、「オブジェクト指向」のメリットを利用して
いるとは、言えんわな。二次元配列にclassの皮がついているだけ。

うわあなんだこりゃ。
>>229
激しく同意

VS 2003 のC++のdynamic_castって正常に動作する？
ポインタ引数であっても(リファレンス引数じゃなくても)変換に失敗したとき例外を投げて、
Debug Errorメセージが出てストップしてしまう。

>>237
プロジェクトオプションの実行時型情報がデフォルトでオフだよ。
オンにしないと使えない

#include "stdafx.h"
#include <cstdio>
class A{
public:
A(){}
virtual int func(){ return 1; }
};
class B{
public:
B(){}
virtual int funcb(){ return 2;};
};
class C: public A, public B{
public:
C(){}
int func(){ return 3;};
};
int _tmain(int argc, _TCHAR* argv[])
{
C *CC = new C;
A *AA= CC;
B *BB;
fprintf(stderr, "%X\n", BB = dynamic_cast< B *>(AA));
return 0;
}
gcc ではちゃんとキャストできた。VC++ 7.01だとランタイムエラーで落ちる。

>>238
ありがとmOm

A.copy( B )というメンバ関数があった場合
一般にBの内容をAにコピーするのでしょうか、それとも逆でしょうか。

>>241
そこで迷うなら
そのような名前のメンバーは存在してはいけない
と思え

>>233
>とりあえず、なにがお気に触ったのかだけ教えてもらえればありがたいです。

いや、別に藻前が悪いわけじゃない。
場数を踏めばそのうちにスタイルも変わってくるだろうし。
（ちなみに気に「サワル」のは「触る」ではなく「障る」だ。）

ただ、たとえばさ、今でも結構いるけど "VIP" と称して
１０年以上前のセルシオやシーマをいじり倒して、
ローダウンさせたりゴテゴテ派手な部品を取り付けたりしている車が
あるけど、藻前、あれらを見てどう思う？

漏れはこのコードを見たとき、なんとなくああいう車を見せられた時
のような感じを受けただけの事。
年寄りの繰言だと思って聞き流してくれ。

>>226
「実際はもっといっぱい列挙」の部分に数十個列挙していて
その数に目を奪われがちかもしれないが
将来的にそれが数倍に増えても問題ないような構造を考えてこそ
スケーラビリティのあるプログラム

>>242
サンクス

もうひっこむつもりだったのですが、気になったので確認させてください。

メンバ変数をたくさん取る代わりに配列で一括で用意したのは、
すべて型はintで済むという前提があるからです。
（突き詰めればフラグ関係はboolがいいんでしょうけど）

メンバ変数でそれぞれを用意すると、ヘッダでのメンバ変数の宣言順と
コンストラクタでの初期化順と書き出しメソッドでの出力順を対応させなければ
ならないという手間が発生します。
ですが、配列だと、初期化と出力はfor文で前からまわせばいいので、その手間は
発生しません。

さらにいま思いついたのですが、アクセサもtemplateを利用して、

template<int i> void SetParam(int n){ param_[i] = n;}

で汎用的なsetterにして、特殊なやつだけは

// 0以下をセットされても無視する。
template<> void SetParam<LEVEL>(int n){ if (n <= 0) return; param_[LEVEL];}

こうすれば、特殊化も容易です。アクセサをメンバ変数ぶんだけそろえることに比べたら、
圧倒的に少ない記述量になるはずです。

コンパイラが配列とenumの対応を認識できないという致命的な欠点を除けば、
この配列方式は十分なメリットがあるように思えるというか……思えたのですが。

結局のところ、若気の至りなんでしょうか……？

　　　　　/ ﾕﾒﾔﾌﾞﾚﾃｻﾝｶﾞﾘｱ!
|自宅|　λ......

そもそも外から自由にSetParam出来る事自体おかしい。
外から自由にSetParamできるという事はそのCharacterに対する敵に対して、
俺のHPなんかどうでもいいから好きに弄ってくれと言っているような物だ。

配列の各要素にエイリアスを用意して、
int a[2];
int *hp = &a[0];
int *mp = &a[1];

a[0] = 33;
*mp = 42;
どっちでもいけるっぽく。

>>247
こいつの事だからどうせ特殊化してコンパイルエラーしろとか言い出すんだろ。
template<> void SetParam<HP>(int n);

>メンバ変数でそれぞれを用意すると、ヘッダでのメンバ変数の宣言順と
>コンストラクタでの初期化順と書き出しメソッドでの出力順を対応させなければ
>ならないという手間が発生します。
そんなわけない。

>>250
>ヘッダでのメンバ変数の宣言順とコンストラクタでの初期化順
ここまではやらないと余計な事で混乱するハメになるよ

そもそも
HP,MHP
MP,MMP
あたりの対応はテンプレートクラスにするべきだろう。

入出力の対応をとれば良いだけだから、内部の宣言順は気にする必要なし。
ファイルのフォーマットが変わっても、入出力メソッドの書き換えだけで済む。

template<typename T> class ValueHaveMax
{
private:
　T current_;
　T max_;
public:
　T getCurrent() const throw();
　T getMax() const throw();
　T setCurrent() throw(OutOfBoundsException);
　T setMax() throw();
　//(実装略)
};

>>254
void setCurrent(T current) throw(OutOfBoundsException);
void setMax(T max) throw();

Exceptinal C++ に Stack の Pop は例外安全にできないと書いてあったのですが、
参照を返すようにすれば大丈夫なんじゃないでしょうか。

>>256
そいつの実体は、誰がどのようしてに押えておくんだ？

>>257
Stack クラスの中のバッファでしょう。

>>258
popしたのに、まだ残ってるのか？

>>256
39ページの脚注とか読む気はございませんか？

>>260
その通りでした。すみません。

250ではないが
>251
> >ヘッダでのメンバ変数の宣言順とコンストラクタでの初期化順
> ここまではやらないと余計な事で混乱するハメになるよ

ただの組み込み変数の初期化に神経質になるのもどうかと。
俺、数が多いときは割とコンストラクタ内部で下のように書くけど。
level = hp = mp = ... = 0;

>>262
コンストラクタなら
Character::Character()
: level(1), hp(40), mp(10)
{
// 名前の登録とか?
}
でいいと思うのだが。勿論0でも使えるし。

コンストラクタでマジックナンバーで与える初期値は０だろ
つーかデフォコンないメンバ入れるの？

組み込み型はデフォルトコンストラクタは存在するが自動的には呼ばれないぞ、と。

初期化がめんどいだけなら
inner structをメンバーにしてmemsetしちゃえばいいじゃん

>memset
いたたた

>>memset
>いたたた
いたたw

memsetﾏﾝｾｰ

そういやvirtualがあるとまずいんだっけか

inner structがPODなら大丈夫だろ

>>270
はぁ？

どうせ藻前裸は今PODを必死にぐぐってるんだろ。
レベルの低いスレだな。

w

Punipuni Oppai DQN

class A {
　struct {
　　int data1;
　　int data2;
　　...
　} data;
public:
　A() {
　　memset(&data, 0, sizeof(data));
　}
};
こういう意図で書いたんだけど、そんなに変かい？
std::fillでも使えってこと？

情報隠蔽も結構だけど、データクラスなら 221 の最初（二番目か?）の設計みたいなので
別段構わないと思うけど。。。

>>221 のコードの問題は、データクラスっぽいクラスに Character なんていうアクターっぽい
名前をつけてること。 class CharacterSpec とか class CharacterAttribute とかにすべき。

>>276
変じゃない

とりあえずmemsetしとけ

>>267とか>>271
イタタタ

↑結局PODが分からなかった香具師

PODなんかで誇る方が正直恥ずかしい…

それさえも分からない香具師はもっと恥ずかしい

次スレ案
POD相談室 Part25

せっかく禿がバスサイクルの問題に気がついてたのに

うわぁ、自分の尺度だけでしか香具師ガイルな。

C++厨の実力の知れるスレでつか？

>>300取ったら香具師がPODについて説明する事

>>280
確かに何をいまさらって感じではあるな

このスレくだらね

Perlでおなじみのドキュメンテーションのことだろ。

ひとりでアプリつくってんのに
情報隠蔽も抽象化も糞もあるかっての。ぼけ。

ひとりで作ってても十分利点はある。

低脳にはそれがわからんのです

俺なんかアドレス指定して書き換えちゃうもんねー。
もちろんアセンブラでプロセシ保護された空間をね。

>>292
君みたいな低能は君だけじゃないから気にするな

PODは、Modern C++ Designの49ページに書いてあるよ。


Cライクなstruct中にプリミティブ･データしか保持されていない場合、
つまり平凡な古いデータ(plain old data─以降、PODと略します)構造


だとさ。これ以外でPODって記述は見たことないから、
ぐぐっても見つけるのはつらいと思う。

POD C++ でおよその意味がわかるページは見つかりましたが。

PODでも整数型しかない場合以外はmemsetなんかで初期化するな。

>>297
ISOも読んだ事無いのかよ

>>299
PODの事分かってないだろ(ﾌﾟｹﾞﾗｯ

>>301
浮動小数点型が入っていたらPODじゃないの？

浮動小数点"数"型か。どうでもいいけど。

>>302
浮動小数点の事分かってないだろ(ﾌﾟｹﾞﾗｯﾁｮ

>>304
もしかして全ビット0が0.0になると保証されていると思っているの？C++で。

>>305
指数部とか仮数部とか分かるか？(ﾜﾗ

little endianだろうがbig endianだろうが全ビット0の浮動小数点数は0だろ。

>305
え、memsetって全bitを0にするんじゃないの？
(それが0.0を表すかはともかく)

>>306
CのFAQだが、http://www.catnet.ne.jp/~kouno/c_faq/c7.htmlの7.31

>>308
全ビットを0にするだけだからこそ、浮動小数点型に使って0.0になることを期待してはいけない。

>>309
それCのFAQだろ。C++だとポインタにしてもちゃんと0で埋めればぬるぽが入るだろ。

ｶﾟｯ

本物はあまりの恥ずかしさに逃げますた

>>313
本物ってなに？

>>311
本当に?

つーか、この中でついさっきまでDelスレで煽ってた香具師何人かいるだろ？

浮動少数のフォーマットはIEEE754だけじゃないぞ
0を代入すれば0.0になることは保証されているけど
0-fillしても0になることは保証されていない

実質外がないといえばそのとおりだが

整数は0で埋めると0になる保証あったっけ？

整数の0で埋めれば0になるだろ

memset相当だから
int a;//とか
for( int i = 0; i<sizeof( a ); ++i )
reinterpret_cast< char* >(&a)[i] = 0;
この場合。

memsetって1バイト毎に埋めるから遅くない？
DWORDとかで回すmemset無い？

>321
とりあえず手元のWindowsXP/VisualC++2003の環境だと
WindowsAPI(もしかするとマクロか？）のCopyMemoryが
32bitで回してくれてるみたいよ。
まあ、逆汗して確認しただけなんで
どの環境でもそう展開されるかどうかは知らないけど。

マチガタ。コピーじゃなくて0初期化か…スマソ。
でも類似品に ZeroMemory() とかあるんでこれでどーかな。
確認してないけど。

>>322-323
ZeroMemoryもCopyMemoryもmemset呼んでるだけだバカ。

VC7はサイズがn*sizeof(int)とかで、intとかのポインタ渡すと
rep stosdで回してくれるっぽいですね。
何か勘違いしてました。

あとmemsetが遅いのも嘘。
http://www-6.ibm.com/jp/developerworks/linux/010824/j_l-rt2.html

というかそういう古くさい話はC++スレでやってくれません事？

C++スレ->Cスレ

>>327
ここがC++スレだが。

328は修正だったのか(鬱

お前らC++スレに行けってさ

どなたか教えてください
class person{
int no;
string name;
int age;
}
見たいなクラスがあるとして、それをｌｉｓｔに積んでいます。
このうち指定されたnoを検索するようなプログラムを組んでいますが

list<person> plist;
list<person>::iterator i;

for (i=plist.begin(); i!=plist.end; i++){
if (plist.getno()==N)
return i
}
みたいなのしか思いつきません。
もっと効率的な検索方法を探しています。
ネットで調べてみるとmapやsetを使うと検索が早いようなことを見かけますが、
そこにある例題だと単純なｉｎｔtとかばかりで、このような場合どうやれば良いのかいまいちわかりません。
どなたか教えてくださ

>>327のような薄っぺらなガキ見てると気が滅入ってくる
何というか育て甲斐がなくてコレがずーんとやる気にひびくんだよ

>>332
struct PersonNoComparetor
{
　operator()(const person& a, const person& b) const { return a.getNo() > b.getNo(); }
};
typedef set<person, PersonNoComparetor> PersonSet;
PersonSet personSet;
PersonSet::iterator it;
it = personMap.find(N);

×it = personMap.find(N);
○it = personSet.find(N);

>>334
× Comparetor
○ Comparator

>>317
> 浮動少数のフォーマットはIEEE754だけじゃないぞ
とはいえ IEEE754 じゃないアーキテクチャを相手にすることを想定する必要があるかは、
書いてるプログラム次第だよな。俺の仕事だと IEEE754 以外は考えてない。

だいたい IEEE754 前提にしないと演算精度とかも変わってくる可能性があるわけで
（非正規化数が無いかもしれない）、やるならそこまで対応しないと意味ないし。

>>337
まあ、曲がりなりにもC++スレなんだからスケーラブルに逝くべきじゃない
ほんの少しのオブジェクト初期化コストを惜しんで
memsetするくらいなら組み込みコンストラクタに任せたりゼロを代入するべきだと思うな。
初期化コストが大きくてどうしようもないなら、必要になる前にプールすればいいんだから

浮動小数点って時点でどうあがいても近似値でしかない

>>332

332です
ありがとうございます
私のレベルでは難しくて、いまいち良く分からないのですが解析してみます。

>>339
アフォですか？ そんなことは問題にしていないのだが。

じゃIEEE754でないことの何が問題なんだ？

このスレでわかったこと
どうでもいい事でもめるから会議は長いんだな〜と思った。

>>342
memsetで0フィルしたときに値が0.0である保証が無いかもしれないって話だった気がするが

で結局IEEE754じゃないアーキテクチャは相手にする必要はあるのか、ないのか？
どっかのバカタレがIEEE754以外を考えていないことや精度が一致しないことを公に必要はあるのか、ないのか？
「そこまで対応」する方法がちゃんと用意されているのに、なぜmemsetなんだ？

ｸｽｸｽ

「そこまで対応しなきゃいけないソース」はmemset使っちゃ駄目
「使われる環境がわかっているソース」はmemset使った方が楽

自分で作ったヘッダファイルがインクルードできない・・・。

ほほー。

何で〜
わからーん。
開くことができないっていわれるのよ。
ただのmapコンテナのクラスをつくっただけなのにさ。
はじめたばっかだからよくわかんないよ

>>345
IEEE754と精度の話ってどこから出てきたんだ？

もひかひて8.3とか？

日本語のフォルダ名orファイル名とか？

空笑を呈している患者がいるな

折角コンパイラがデバッグしやすいように固定の初期値を入れてくれるオプションがあったりするのに、
わざわざ自分でmemset()でクリアしてしまってデバッグを困難にするのは理解できない。

ま、「そこに構造があるから取り敢えずmemset()」なんて香具師とはどっちみち話が合わないこと夥しいのだが。

>>355
　それはVC++だけの話じゃないか？

>>355
藻前はコンストラクタで初期化しないんですか？

そうか、どうも変だと思ったら
コンストラクタで初期化しない人だったのか。

そもそも始まりは(配列ではない)メンバーをまとめて初期化したいって話だったのに

しかも「IEEE754以外の場合は」とか言いながら
特定の処理系のコンパイルオプションまで持ち出して。

最近はコンパイルオプションもIEEEで標準化されつつある


と言ってみる

なんかこのスレ、ネチネチしてるね

日本のC++コミュニティはどこもネチっこいよ

まあここはレベル低いしな。

レベル高い日本のC++コミュニティはどこですか？

cppll以外で

cppllの話題に付いていけないからって妬むなよ

>>366
このへんがネチネチしてるね

あーあ

いつまでもしつこくネチネチとか言うな

アイーン対応

あいーん754対応しますた！

やった！ついにアイーン対応だ！！

質問お願いします。下のを通す正当な手段はないのでしょうか。
class B{
public:
    B& operator=(const B& rhs){}
};

class D : private B {
};

int main(int argc, char* argv[]){
    B b;
    D d;
    b = d; //コンパイルエラー 変換は存在するがアクセス不能
    return 0;
}

public継承に汁

>>373
レスサンクスです。すいません、それ以外でひとつ…。

いや、なんかこう眺めてたら抜け道ある気がしちゃいまして。
（キャストではなく、「基底クラスで〜があればいける！」みたいな）

やっぱり無理ですよねぇ。お騒がせ失礼、寝まする、アイーン

http://wwwdoi.elec.nara-k.ac.jp/html/jisyu/dxm/cap2/index.html
のcap26.cppのプログラム実行結果をテキストに保存するプログラムをください。
どこに実行結果の数値をテキストに書き込む処理を入れれば、
いいのでしょうか？

staticで確保したメンバ変数（正確にはSingletonです）の
デストラクタが、デバッガで見ていても一向に呼ばれた気配がなくて不安です。
こういうものなのでしょうか？

すいません、トンチンカンなこと訊いてました。
そりゃ自分で呼ばなければですよね・・・。

>>374
protected継承に汁
つーか、private継承なんて使わんぞ

>>372
もう寝ちゃったみたいだけど、usingを使えば出来るんじゃないかな。

b = d;
を
b = (B const &) d;
と書くとかって話か?

>>372
class D;
class B{
public:
B&operator=(const B&){return*this;}
B&operator=(const D&);
};
class D:private B{};
inline B&B::operator=(D const&d){return operator=((B const&)d);}
int main(int argc,char*argv[]){
B b;D d;
b=d;
return 0;
}

>>382
いやそれ、コンパイラは通してくれるだろうけど、C++プログラマの倫理観としては、ナシだろ？
って、それは372に言うべきか。

class B{
public:
    B& operator=(const B& rhs){return *this;}
};

class D : private B {
    inline friend int main(int argc, char* argv[]){
        B b;
        D d;
        b = d;
        return 0;
    }
};


mainをクラス内に書くのは妙な気分だね。

Javerですもの。

>>385
　Javaerでもstatic void mainになるで、ちょっとおかしくない？

>>386
Javerは細かいことは気にしないのさ☆

そういえばJavaはvoid main()なんだね。
C/C++はint main()なのに。

>>388
Javaで世界が完結してるからリターンコードなんてたいしたことないのさ

>>384
さすが、friend最凶伝説。気持ちﾜﾙ〜

>>383
private継承しておきながら
型変換の明示 (>>381のようなもの) を行なわず
暗黙の型変換を利用しようとしてる時点で倫理は消えているので
382でも無罪

ウホッ、情報ｲﾊﾟｰｲ。コードの読み応え満点。
皆さんレスありがとうございました。

正当な手段があるわけない事がよく分かったので、protected継承にしておきつつ、
Javarの漢気を胸に刻んだり、小粋なﾃｸﾆｰｸを後世に伝えたりしながら生きて逝きます。感謝感激。

ISO/IEC 14882:2003が出たと少し前cppllで騒いでいたけど何なのよそれ。

#define と enum ってどう違うんですか？

#define NONE 0
#define SPADES 1
#define HEARTS 2
#define DIAMS 3
#define CLUBS 4
も、
enum hoge {NONE = 0,SPADES,HEARTS,DIAMS,CLUBS}
も同じに見えるんですが。
#defineじゃなくてenumじゃないといけない例とかplz

#define NUM 10

struct A{
int NUM;
};

どうなるよ

VCだと名前で出るので便利
defineだと数字だけで(+д+)ﾏｽﾞｰ

C++で定数値のためにを#defineを
使う利点ってあるのかなあ?

>>397
あんまり変らないと思うが。
　コンパイラで処理するかプリプロセッサで処理するかの
　好みの問題じゃない。

そうじゃないよ。

>>398 は知能の低さを露呈してしまいました。

まあたしかに#defineじゃデバック情報はのこらないな。

>>398
395,396が指摘しているように
名前空間無視やデバッガのシンボルテーブルに
載らない点だけでも問題だと思うが。

>>400
なさけない、あと1分早ければねぇ。

>>393
(ﾉ･ω･)ﾉ お前は cppll へ帰れー
(ﾉ･ω･)ﾉ cppll へ帰れー
(ﾉ･ω･)ﾉ 帰れー

C++でdefine定数値を使う奴は低脳だと、かなり前に結論付けられているはずだが？

#defineは条件付きコンパイルをするうえで必須だと思うが。

>>406
それは >>394 の例とはズレてるような。正確には

　整数型の const 定数の代わりに #define 使うヤツはバカ

かね。浮動小数点は template 実引数として渡せなかったり、クラススコープのメンバとして
インライン定義できなかったりと、扱い微妙だが。

>>406
はぁ？オマエの頭ではdefine全否定っていう流れになってんの？馬鹿か？

>>408
明らかなバカは放っておこうよ

>>408
>>405が全否定しているから。

ところでVC++7.1とか使ってる人はみんな
class A{
　static const int PI = 3.15;
};
って感じですか。6.0な俺はできないわけですが。

>>410
おまえは会話の流れを読まないから私生活でも浮いてるんだヽ(`Д´)ﾉ！

enumの利点
・定数を増やしたときにナンバリングしなおさなくていい
・enumからintへのcastは安全だがintからenumのcastは危険なので
　範囲チェックを省略できる（危険なキャストをする馬鹿がいないと仮定してだけど）

例：
enum TYPE {
　TYPE_A = 0,
　TYPE_B,
　TYPE_C,
　TYPE_D,
};

void SampleFunc(TYPE type) {
　switch (type) {
　　TYPE_A:
　　　：
　　　：
　　default:
　　　// この関数が別のプログラマに呼ばれても
　　　// ここにくることはないハズ
　　　// （まあ強引に整数型からキャストする馬鹿が居ればその限りじゃないが
　}
}

また、TYPE_B2が増えても、C、Dを手でナンバリングしなおす必要がない。

外部データに出力した場合、
明示的にナンバリングする必要が出る可能性もあるわけだが

>>410
>>405は
>define「定数値」
と言っている。

>>413
>・enumからintへのcastは安全だがintからenumのcastは危険なので
ｎを最大の列挙子の値として
2^([log2 n]+1)-1　(^は累乗記号;[]はガウス記号)
以内の整数は安全にキャストできるからそうとも言えぬかと。

>>394
えーと、まあ。enumは型を形成するのに対して
#defineは単純な文字置換でしかない、というのが大きな違いだろうと思う。
確かに単に定数値を抽象化するだけの目的なら
「#defineではなくenum(もしくはconst整数型)でないとなにがどうあっても絶対ダメ」
ということは多分ないだろうが、コンパイラのチェックを受けられるかどうかとか
型として使えるかどうかの違いはそれなりに大きいのではないかな。

ちなみに定数値を抽象化する目的でないなら
「#defineじゃなくてenumじゃないといけない例」は
たとえばテンプレートあたり使ってるとででてきたと思う。

> ｎを最大の列挙子の値として〜以内の整数は安全にキャストできる
でたらめかな？

>>417
手元の入門書によると

> 整数型を列挙型に明示的にキャストするのは危険です。
> 整数型の値が列挙型の範囲を超える場合、または、
> 列挙型の要素の値が重複している場合のキャスト結果は
> 保証されません。

とのこと。
要するに重複してなくて範囲を超えない場合は安全なのかね？

> ISO/IEC 14882:2003
〜:1998 の改訂版。
変更はtypo修正と曖昧な文章の明確化のみで、
新たな言語仕様の追加・変更はなし。

余談だが、JIS規格のC++は〜:2003の方を訳したものになる。

定数が常にintだとは限らないんだがな

>>420
それがどうした。

定数で有名なものといえば
光の速さ
自然対数の底
円周率

enumとconstの話に

　ス　コ　ー　プ　が　出　て　こ　な　い

このスレはアフォばかり

>>423
どちらもクラスやネームスペース内で定義する事は可能だけど。enum も const
(暗黙のウチに static) 変数と同様にファイルローカルにしたければ、anonymous
namespace 内で定義すれば良いだけ。

そういう話じゃなくて、何かあるの？

const 変数と enum の最大の違いは

o const 変数は signed/unsigned など、複数の型を使える
o const 変数は定義と宣言を分離できる。enum は宣言 = 定義。

っつー点だと思われ。

>>424
なぜ「int/doubleなど」ではなく「signed/unsignedなど」なんだろう

器の小さい人間はsigned/unsignedといった小さな違いに目を奪われて
もっと大きな違いなんか思いもつかないものだ

> const 変数と enum の最大の違いは
最大の違いっていったら、enumが独自の型を形成する点だろ。

なんでこんな馬鹿ばっかりなんですか？

>>428
お前というとんでもない馬鹿がいるから他は見劣りするな。

>o const 変数は定義と宣言を分離できる。enum は宣言 = 定義。
定義と宣言を分離すると定数式じゃ使えなくなるがな。

>>424
#define との違いの話をしてるんじゃなかったのか。

>>430
ヘッダーに
extern double const PI;
と宣言を記述して
どこかのファイルに
double const PI = 3.14;
と定義を書くような方法も不可能ではない

>>432
配列の大きさとかじゃねーの？

>>427
そういや、以前

　enum XXX_FLAG { X_READ, X_WRITE };
　int func(XXX_FLAG flag);
　...
　func(X_READ | X_WRITE);

と書いてハマった経験がある。

>>433
C時代の時代遅れな老人じゃあるまいし
vectorとかlist使え

>>435
それは言い過ぎ。

プログラムの内容によっては、固定長でバイト列を取りたい場合もある。
ぺりふぇらるとの通信用バッファとかさ。

リンカの仕事とコンパイラの仕事の区別が付かないお馬鹿さんばかりだね。
ここは。

>>436
>>435はたぶんreserveしてそこに無理やり書き込ませるんだろ
c_strで得たバッファのconstをためらいもなくはずす人種だ

>>432
> extern double const PI;
> と宣言を記述して

これは、定数値の宣言じゃないよ。
変更できない｢変数｣の宣言だよ。

extern double volatile const PI;

なんて宣言もできるんだからさ。

浮動少数点数がコンパイル時定数である必要性はあるのか？

いや無い。つまり変更できない変数で十分。

immediateの意味で定数という言葉を使っている人と
constantの意味で定数という言葉を使っている人がいるようだ

// hoge.h
class Choge
{
private:
static const int T = 100;
int m_a[T];
};

ってのも書けるようになったの?
今使ってるコンパイラ、捨てようかな。

>>442
当然のように書けるよ。

>>443
ありがとう! 捨てます。

>>442
具体的になにを捨てるの？

http://www.geocities.co.jp/Milano-Cat/1568/throw.swf?b64=VkMrKzYuMILwDZGLgqmC5w%3D%3D%0Dk4qCsI7MgsSC6w%3D%3D%0DhKGEn4SfhKINhKBWQzaEoA2EoIFAgUCBQISgDYSgTVOBQISgDYSkhJ%2BEn4Sj

>>446
http://www.geocities.co.jp/Milano-Cat/1568/i575.swf?b64=jsyCxILIgqKCxQpjbC5leGWC8AqO5oLokdaCpoLr

>>447
Intelのものに？

>>411
そんなあなたにBOOST_STATIC_CONSTANT

#include <boost/config.hpp>

class A{
BOOST_STATIC_CONSTANT(int, PI = 3);
};

むしろboost使うならVC7.1が欲しい

VC++使ってるなら最新のコンパイラ買えよ。
GCC使ってるなら、3.4のパーサのデバッグしろよ。

ほんと、買えるものならVC++7.1Proだけで買いたいよ

VC++使わずGCC使え

だってGCCはBoost100%じゃないんだもん。

Boostの犬かい

Web上で見かけたんだけど

class parent{
public:
virtual void func( void ){ cout << "parent\n"; }
};

class child: public parent{
public:
virtual void func( void ){ cout << "child\n"; }
};

void main()
{
child a;
parent b;
parent &c = ( true ) ? a : b;
parent &d = a;
c.func();
d.func();
}

結果
parent
child

はVC++6.0のバグ？

>>456
VC++6.0でこれだとどうなるの?

#include <iostream>
class parent{
int x;
public:
parent(int i):x(i){}
virtual void func(void){cout<<"parent "<<x<<"\n";}
};
class child:public parent{
public:
child(int i):parent(i){}
virtual void func(void){cout<<"child "<<x<<"\n";}
};
int main()
{
child a(1);
parent b(2);
parent&c=(true)?a:b;
parent&d=a;
c.func();
d.func();
}

いい加減VC++6.0は捨てろ。それにスレ違い。

スレ違いではありませんので458を無視してください

BCCでもそうだった。なんでなんで？

virtual関数の実装が別コンパイル単位(ファイル)だったら起きない問題か。
クラス宣言内に実装があるので、可能ならインライン展開しようとするから
そんときのクラスの選択がバグってると。
さすがに >>457 の数字はちゃんと正しく(共に1が)出るんじゃないか。

VC6持ってる人検証キボン

参照だからじゃない

>>462
参照じゃなかったら文法違反だと思はれ。

>>461
俺もinline化に関わるバグと思う

vc6でやったよ。
xはprivateだからコンパイル通らんよ。
publicにしてさらに
//parent&c=(true)?a:b;
parent&c=a;
にしたら直ったよ。

安心したければGCC使えということで

GCCかよ(笑

VC++6なんていう、ANSIC++以前のコンパイラが
ANSIC++に対応してないっていう話はいい加減やめれ。
そんなの当たり前もいいところ。
それを鬼の首でもとったかのように喜んでるのはただの知的障害者。

>>468
規格制定前にその規格を満たす実装は存在していないという妄想の例

>457
> VC++6.0でこれだとどうなるの?
parent 1
child 1
三項演算子は正しくaを返してます。

>461
念のため関数定義を別のファイルにまで持っていきましたが再現したので
inlineは関係無いと思います


いろいろ試してみた結果、三項の部分は、どうも
parent &c = parent(( true ) ? a : b);
こんな風に解釈されているっぽいです。


ちなみに参照をポインタに変えたら、当然？期待通りに動いてくれます。

>>470
コンストラクターの呼出し回数を数えてみるといいかも

あ、その場合は
コピーコンストラクターを明示的に定義して
その中でカウントするなり、coutに向かって何かを書くなり

ANSIC++はある日突然現われたのではなく長い年月の議論の末に生まれているから
ANSIC++が確定する以前であってもANSIC++の概要を知ることは可能。
ANSIC++が確定する以前に作られたVC++6が
ANSIC++に書かれてあることの全てに対応できていなくても部分的に対応できていれば、
どこまで対応できているのかについての議論は今でも意味がある。
その議論そのものの存在意義を否定することができるのは
VC++6がANSIC++に書かれてあること全てに対応していない
ということが明確である場合だけとなる。

>>468
てことでVC++6はANSIC++に書かれてあること全てに対応していない
と言いたいということでよろしいか？

そんな古いコンパイラの話せずにおとなしくBoost100%のVC++7.1を使えばいいよ

>>463
ポインターってこと
parent* c = ( true ) ? &a : &b;

>>470
ということは、ポインタでなく値が式の結果となる三項演算子は
両者の型が違うときは共通化できる型に変換し、変換されるほうは
一時オブジェクトを生成して返してるってことになるのか。

VC++7.1 を使いたいのは山々なんだけど、いろいろなしがらみから現実には
まだまだ VC++6 をつかわにゃならんケースが多いんだろ。
実際問題、今現在でも VC++6 がもっとも使われている C++ コンパイラなんじゃないの？

>>477
そんな統計あるならソース出せ

>>477
　winだけならな

>>474
いっとくけどvc7.1も>>456のもんだい解決できないぜ

VC++はまずいよ。
こういうコンパイラーのおかしな動きで
システムに障害が出て
損害賠償請求されたらたまったもんじゃない。

>>481
納める前に動作確認するだろ。

>>482
馬具が必ず再現できるとは限らないよな
テスト至上主義には分からんか

>>483
まあそうだが、
コンパイラは規格に合致していることを契約しているわけではないので
従っていないことを理由に文句を付けることはできないよな。
コンパイラを選んだ時点で、現状のそのコンパイラの挙動に合わせて作る
しかない。
挙動を確認せずに間違って使ったほうが悪いんでは?

>>483
開発者の怠慢ですね

child a;
parent b = a;
が通ったんだけど・・・

もしかして漏れとんでもない勘違いしてる？

その前にポリモーフィズムと言ったら普通ポインターでは

virtual関数周りの動作は実際に動いてみるまで分からないから怖い。
>>456のようなバグも
そのバグが発生しても日常的には問題がなくて気付かず、
珍しい条件が揃ってから初めて症状が出てくるようなシステムだと
動作確認で問題を見付けられないだろうな。

>>486
勉強し直し

>>484
一般的に、コンパイラーを選ぶのも開発側の責任に含まれることが多いから、
コンパイラーのバグが原因であっても、そうでなくても、
すべてひっくるめて動作の不具合は開発側の責任になって
開発側の負担にて修正することになる。
契約によっては損害賠償もあるだろう。

>>490
人命に関わるバグだったりすると・・・ね

Windows上のシステムだと
コンパイラーの不具合でシステムが挙動不審になる確率より、
先にOSが勝手に落ちてくれる確率が高いから気にしない文化あり。

Windows以外の環境だと
VC++の選択はありえないのでこれまた問題ない。

>>492
別に開発環境のバグで起きたことについての損害賠償云々ってのはWindowsに限ったことではないんだが。

結局>>456のサンプルはVC++6でも7.1でも駄目なのか？

>>494
自分で試せ

つーかVCの挙動が正しいんじゃないか？

>>496
理由は？

VCが正しいとしても、constではない参照がテンポラリオブジェクトを指していることにならないか？

>>497
式'(true) ? a : b'の型はparent（parent &ではない）になるのが自然だと思われるから。

>>498
確かにそうだ。

VC7.0だと

これも
void foo(parent &){}
foo(parent());

これも
parent &c = parent(a);

コンパイル通るね。

Final Draftだから以後変わってるかもしれんが:
5.16 - Conditional operator [expr.cond]
の-3-の3個目では
if E1 and E2 have class type, (中略)
If the conversion is applied, E1 is changed to an rvalue of type T2 that
still refers to the original source class object (or the appropriate
subobject thereof). [Note: that is, no copy is made. ]

となってるみたいな。

>498
無名オブジェクトの、参照による延命ってやつ？では。

>499
(式) ? a : b;
のaとbが同じ型の場合だと、テンポラリは作られなかった。から正しくない。

>>499
> 式'(true) ? a : b'の型はparent（parent &ではない）になるのが自然だと思われるから。

まったく不自然なんだが。

parent & x = (true) ? a : b;
で、aとbが共にchildクラスだった場合もここでテンポラリー生成が自然？
となると
parent & x = a;
の場合もテンポラリー生成が自然ということになる。

499がどのように感じても、VCの動きは規格的に間違いなので
「VCの挙動が正しい」という結論には繋がない

>>505
根拠は？

>>505
お前が作った規格で正しいと言われてもなぁ（藁

だれか>>502を和訳してくれ

最終Draftだから以後変わってるかもしれんが:5.16 ―条件付きのオペレーター[expr.cond] の(3)の3個目ではE1とE2がクラス・タイプ(中略)を持っている場合、
転換が適用される場合、E1は、オリジナルの出所クラス・オブジェクト(あるいはそれの適切なサブオブジェクト)にまだ言及するタイプT2のrvalueに変更されます。[注:すなわち、コピーは作られません。]となってるみたいな。

>>509
おお、ありがとう

>>507
502の規格を作った人が505なのか?

>>505 == ANSIC++規格作者
ということで

つーかVCが正しいでしょ。
間違っているという奴は間違っている証拠を出せないんだし。

>>513
502が証拠では?

ANSI C++ と VC++ の挙動が違うということは分かった。
しかし ANSI C++ が正しいという証拠はない。
ANSI C++ が間違いで VC++ が正しいこともある。

>>515
ちょっと違う。正式なANSI C++の規格自体出ていない。

ふざけんなてめーら。
わざわざDraftなんか持ち出して嘘つきやがって。
ISOだとVC++が正しいじゃねーかよ。

― if E1 and E2 have class type, and the underlying class types are the same or one is a base class of
the other: E1 can be converted to match E2 if the class of T2 is the same type as, or a base class of,
the class of T1, and the cv-qualification of T2 is the same cv-qualification as, or a greater cv-qualification
than, the cv-qualification of T1. If the conversion is applied, E1 is changed to an
rvalue of type T2 that still refers to the original source class object (or the appropriate subobject
thereof). [Note: that is, no copy is made. ]

てことはANSI C++が間違いなので、ていうか存在してないので、
VCが正しいのか

>>518
違う。Draft(草案)が変更になった。

どうやらM$叩きは失敗したようだ。

>>478-479
http://www.trickpalace.net/cgi-bin/cppll/enq.cgi?mode=enquete&number=5

母数が少ないが、VC++6 がもっとも使われている C++ コンパイラ
という話はそれなりに信憑性があると思うぞ。

>>517
ん? 同じ文じゃないの?

つーか、英語を読めないだけだろ。

>>517
君の出してくれたISOはVC++の間違いを示してくれてるよ

>>521
少なすぎ。

いくらBoost100%でもこんなに簡単な所で間違えてるようじゃVC++もまだまだだな。

なんでプログラマって英語も読めない馬鹿が多いの？

>>527
ふーん。そうやってアメリカのいいなりになるのか。

>>525
激しく大笑いしました。

>>517
That is, That is, That is,

> If the conversion is applied,
> E1 is changed to an rvalue of type T2 that still refers to the original source class object
> (or the appropriate subobject thereof).
> [Note: that is, no copy is made. ]

no copy is made.
in other words,
refers to the original source class object.

VC++ made temporary object, in this case.

E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2
E1 is changed to an rvalue of type T2

つーかさ、ISOの記述が曖昧すぎるんだよ。

この件に関して
VC++の動きとISO C++の規格が不一致であることはずっと明確であるのだが、
VC++が正しいと言ってる連中は
VC++が正しくてISO C++が間違っていると言ってるわけだよな?

ISO/IEC 14882:2003ではMSの方が正しくなっているに違いない。

>>528
英語読めるだけでアメリカの言いなりだなんて。
お前は未だに敵国語は使うなの精神で生きているのか？（ｗ

しかし低級2cherがISO/IEC 14882:2003を所持しているはずが無いので、
この問題は海の底へと消え去るのでした。

>>531
> E1 is changed to an rvalue of type T2
> E1 is changed to an rvalue of type T2

もしかしてその続きが読めない人？

>>532
> VC++の動きとISO C++の規格が不一致であることはずっと明確であるのだが、
そこが間違っている。

http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003
PDF 273�j・・(´･ω･｀)

>>537
なぜ間違っていることになる？

ISO C++ Draftによると、
コピーは作成されず元オブジェクトへの参照になると書かれている。
VC++の動作ではテンポラリーオブジェクトとしてコピーが作成されている。
確かにISO C++ Draft的にはVC++の動きが間違い

でドラフトがどうかしたのか？
ドラフトが規格と全く同じだとでも？

いまだにVC++が正しいと信じて疑わない連中がいるようですが
そいつらとしては
「VC++的にはISO C++が間違い」
という結論になってるんですよね？

>>542
だからドラフトが違うんだってば。いい加減にしろよ。

まあBoostでさえ100%取れないGCCはそれ未満だけどな。

ちなみにその部分はドラフトも正式規格も同じ

>>545
ソースは？

>>543
ソースは？

>>538
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+14882%2D1998
14882:1998(訂正が盛り込まれる前の規格)は18�j。(昔から)
なんでこんなに違うんだろ?

必死で正式版を隠しているのが笑える。

ISO C++を100%取れないVC++と
Boostを100%取れないGCCの闘い

ISO C++とBoost、どちらを選ぶ人が多いか

どっちを選ぶもなにも、
PC-UNIXならGCCしかないし、
WindowsならVC++しかないし
Cコンパイラの選択肢なんて
あってないようなものです

>>550
GCCもISOC++100%取れてないからBoost100%じゃないんだろ。

>>552
ソースは？

>>553
えっ？ Boost100%じゃないのにISO C++100%だとでも？

>>552
いつから
「Boostが100%動けばISO C++100%」
というようになったんだ？

>>555
誰もそんなこと言って無いだろ。日本語読めないのか？

とりあえずここのレベル低い香具師らはexportも知らないんだろうな

>>556
「ISOC++100%取れてないならばBoost100%動作ではない」が真で
「Boost100%動作ではないならばISOC++100%取れてない」が偽ですか

>>558
当たり前だ。ボケ。

VC++を必死で擁護する人って
対偶もしらないアフォばかりということでよろしい？

>>558
逆っぽそうだけどなあ。
BoostはISOの機能の一部を使って実装されているものだし。

0%-----------Boost100%-------------ISO%

Boost 100%でもISO 100%にならないことはあるが、
Boost 100%になってないのにISO 100%になることはない。

0%-----------Boost100%-------------ISO100%

>>556
いや、言ってるよ

> GCCもISOC++100%取れてないからBoost100%じゃないんだろ。
というのは
Boost100%動いたらISOC++100%取れてると言ってるのと同じ意味

>>564 ははははは。お前真性馬鹿だろ。

564さらしあげ

564は釣りだろ釣りｗ。ﾌﾞﾊｧ

「AでないならばBでない」というのは
「BならばAである」と言ってるのと同じ意味。

段々と感情論になってきてますよ。
牛乳飲んでカルシウム補給せよ。

Boostが100%取れてないGCCがISO 100%になるはずないな。

ところで>>564よ。VCはBoost 100%なのだが、
ISO 100%だと本気で思っているのかね？

「ISOC++100%取れてないからBoost100%じゃない」
ってことが正しいなら
「Boost100%動いたらISOC++100%取れてる」
ってことになるのでは？

>>568
違います。もう少し勉強してください。

>>568
対偶だよね〜

>>571
なりません。もう少し勉強してください。

>>572
君がね

相変わらずレベルの低いスレだな

>>576
これくらいレベルが低くないと、プログラマなんてやってられません

>>568
> 「AでないならばBでない」というのは
> 「BならばAである」と言ってるのと同じ意味。
全然ちがう。1つ目が正しいなら2つ目は間違い。

>>571
> 「ISOC++100%取れてないからBoost100%じゃない」
> ってことが正しいなら
> 「Boost100%動いたらISOC++100%取れてる」
> ってことになるのでは？

1つ目は正しいが、2つ目は間違い。
GCCは「ISOC++100%取れてないからBoost100%じゃない」になる。
BoostもISOC++も100%じゃないGCCと、
Boostが100%だと分かっているVC++。
どちらが正しいか誰が見ても明らか。

0%---GCC------Boost100%-----VC------ISO100%

Boostが100%に達していないなら、ISOが100%に達することはないし、
Boostが100%に達していても、ISOが100%に達しないこともある。

Boostが100%に達していないGCCはISOが100%になることはない。
そしてBoostが100%だからといってVCがISO 100%だと言っている奴もいない。

一人、Boost 100%ゆえにISO 100%と勘違いしている馬鹿がいるみたいだが（藁

（´д｀）

>>579
違います。
VC++はBoost 100%だから当然ISO C++100%になります。

みなさん幸せなんですね。
こんなにもくだらない事で盛り上がれるなんて。

>>578
ネタの可能性が高いけどマジレス。
「AでないならばBでない」ということは、Bという集合はAからはみ出だしていないことになる。
つまりBはAに含まれる訳だ。
このことから「BならばAである」は正しい。

>>581
もうそろそろ諦めたらどうだ。GCCはISOを100%満たしていないし
GCCはVCよりも劣るのだよ。

>>584
たとえばお前とか
VC擁護してる馬鹿連中って根拠ないし、非論理的。

>>583
> 「AでないならばBでない」ということは、Bという集合はAからはみ出だしていないことになる。
> つまりBはAに含まれる訳だ。
> このことから「BならばAである」は正しい。

ネタだろうけど、A=バナナ、B=リンゴに当てはめてみたよ（ｗ

「バナナでないならばリンゴでない」ということは、リンゴという集合はバナナからはみ出だしていないことになる。
つまりリンゴはバナナに含まれる訳だ。
このことから「リンゴならばバナナである」は正しい。

>>552
> GCCもISOC++100%取れてないからBoost100%じゃないんだろ。

GCC叩きたくて必死らしいけど
そんな分かりやすい嘘をついてまで叩かなければならないのか？

0%---GCC------Boost100%-----VC------ISO100%

この図が真実を表している。だれも反論する奴はいないだろう。

>>586
ネタだろうけど、
「バナナでないならばリンゴでない」
は真ではないので、その推論は間違い。

おまえら、スレ違いですよ。
それにISO100%ってなんですか？どうやって確認するんですか？
ISOがテストプログラムでも用意してくれてるんですか？

>>587
どの点がウソだと？

>>586
>バナナでないならばリンゴでない
そもそもこれが間違っているだろ。
前提として「AでないならばBでない」が正しければ、
「BならばAである」が正しいと言っているわけで・・・

>>589
その通り。583の言っていることはめちゃくちゃ。

>>592
俺に反論するなよ。俺は単にA=バナナ、B=リンゴに置き換えただけだ。
583の言っていることがおかしいんだよ。

前提が間違っているなら、どんな命題も真って
直感に反するよな。

0%---GCC------Boost100%-----VC------ISO100%

この図が真実を表している。だれも反論する奴はいないだろう。

　←────→ISO 100%
↑
│
│　　　　GCC
↓VC++
Boost 100%

ここまでのまとめ。

550 ：デフォルトの名無しさん ：03/10/26 20:48
ISO C++を100%取れないVC++と
Boostを100%取れないGCCの闘い

ISO C++とBoost、どちらを選ぶ人が多いか


552 ：デフォルトの名無しさん ：03/10/26 20:53
>>550
GCCもISOC++100%取れてないからBoost100%じゃないんだろ。


555 ：デフォルトの名無しさん ：03/10/26 21:03
>>552
いつから
「Boostが100%動けばISO C++100%」
というようになったんだ？

556 ：デフォルトの名無しさん ：03/10/26 21:07
>>555
誰もそんなこと言って無いだろ。日本語読めないのか？

0%---GCC------Boost100%-----VC------ISO100%

この図が真実を表している。だれも反論する奴はいないだろう。

質問です。
mmintrin.h の組み込み関数使いたいんけど、
このファイル、VCのSP5についてなかったっけ？

SP5入れたのに mmintrin.h が見つからない・・・。
ProcessorPackじゃないとダメとか？

うへ〜、とりあえず論理的な間違いだけは落ち着いてちゃんと理解しようよ。

A: (x > 5)
B: (x > 7)

「AでないならBでない」: (x <= 5)なら(x <= 7)
「BならばA」: (x > 7)なら(x > 5)

対偶の真偽は常に一致。

ではISO C++とBoostの話をどうぞ。

>>600
雰囲気嫁馬鹿

552=556=VCマンセーによるGCC叩き

要するにISO 100%取れないだけのVCと
ISOもBoostも100%取れないGCCってことだろ。

GCCコンパイル遅いよね

対偶しらない中学生に説明してるみたいだな・・・
たとえば
「辛くなければ唐辛子ではない」これが正しければ、
「唐辛子は辛い」が成り立つ。

同じように
「バナナでないならばリンゴでない」これが正しければ、
「リンゴならばバナナである」も正しい。

ただし、「バナナでないならばリンゴでない」これが間違っているのは
明らかなので「リンゴならばバナナである」は正しくない。

ISOの100%ってなに？どうやって確かめるの？

そんなにISO100%にしたければ自分でコンパイラ作れ

>>601
0%---GCC------Boost100%-----VC------ISO100%
これをAとBに代入すると

Boost100%: (x > 5)
ISO100%: (x > 7)

「Boost100%でないならISO100%でない」
「ISO100%ならばBoost100%」

うむ。間違いではない。ところでISO100%と言った奴は誰かいるのか？

VCとGCCがそれぞれが何パーセント準拠しているのか分からんが
今回のバグ問題のようにいざってとき裏切ってくれるから
（ていうか今まで痛い目に会いすぎてるから）
漏れ的にはVCを信用しなかったりする

つまり、Boost100%でないGCCは
当然ISOも100%ではないわけだ。

>>550
　> ISO C++を100%取れないVC++と
　> Boostを100%取れないGCCの闘い
　>
　> ISO C++とBoost、どちらを選ぶ人が多いか
に対するレスとしての>>552
　> GCCもISOC++100%取れてないからBoost100%じゃないんだろ。
を読んで>>564
　> > GCCもISOC++100%取れてないからBoost100%じゃないんだろ。
　> というのは
　> Boost100%動いたらISOC++100%取れてると言ってるのと同じ意味
みたいに解釈したり >>568
　> 「AでないならばBでない」
みたいにどこからともなく"ならば"を召還したりできる人がいるらしいが、

552の発言って>>570
　> Boostが100%取れてないGCCがISO 100%になるはずないな。
と同じ意味だろ。

とりあえずおまいら必要充分条件から出直せ

子供の中には「対偶も真なり」を直感的に受けつけてくれない奴もいるようだ

対偶からも証明されているように、これが正しい。
0%---GCC------Boost100%-----VC------ISO100%

俺分かった。

ここにはVCはBoost100%(GCCは100%じゃない)だと知らない奴がいる。

>>615
Boostへの対応度とISO C++への対応度は別次元では？

>>617
Boostは、次期ISO C++(C++0x)のライブラリ案を目的として
ISO C++の仕様を前提にして実装されているものなわけだが

>>617
Boostって何か知っている？
C++の機能(テンプレート)を使ったライブラリだよ。
BoostのテストってのはC++のテンプレートが正しく
実装されていれば100%とれる。

>>619
ろくにBoost知らないくせにそんな適当な事書いて恥ずかしくないの？

Boostは100%であるVCだがISOは100%でない。
Boostは100%でないGCCはISOも100%でない。
それだけのことなのに何でこんなにレスついてんだ？（ｗ

>>621
みんな暇なんです。

>>620
言いたい事はそれだけのようですね。
間違いがないから指摘できないのでしょうが。

>>621
GCC LOVEなんです。

なあ、boostのリグレッションテストって日々増えてるんだよな？
http://boost.sourceforge.net/regression-logs/
100%なんて数字は今はどこにも書いてないわけだが。

>>623
boost::preprocessorはテンプレートで実装されてるんですか。そうですか。

>>623のような無知は怖いな

で
>>456 は？

--------------
今日の名(迷)言
--------------

**************************************************

Boostって何か知っている？
C++の機能(テンプレート)を使ったライブラリだよ。
BoostのテストってのはC++のテンプレートが正しく
実装されていれば100%とれる。



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　by >>619
**************************************************

いい加減、VC++6は

>>618
たまにコンパイラ依存 (ANSI C++ だと実装依存とされるやつ) のコードが発見されて、
修正が入ったりするけど。まぁ、かなり希だが。

>>629
いいから反論（ｗ

>>632
>>626

>>630
一世代前のVCがどうかしましたか？

>>634
二世代前ですが

二世代前ではなかろうか。

>>634
二世代前なんじゃないかな

ｹｺｰﾝ >>635-636

>>626
boost::preprocessorは何で作られていると思ってるんだ？（ｗ

Boostがテンプレートで作られていようが作られていまいが、
Boostで100%を取れないGCCはクソなわけだが。

ようするに標準C++への対応度から言えば
GCC < VCということですね。

boost100%って強調するけど、現時点じゃ100%じゃないし、
それにGCCだって98%(Failが6個)は達成してる。
おまえらそんなに奇抜なコード書いてるのか？

>>640
大してかわらんだろ。

>>642
GCCが具体的なのに比べて、VCは具体的じゃありませんね。

>>643
は？

は？ じゃなくてｗ

なんでくだらない議論になってるんだよ。
おまえら厨房の集まりだな。
ここは質問スレだろ！
激しくスレ違いなチャットなんてしてるんじゃねぇよ！！

>>645
は？

なんかのびてるから読んでみたんだけど

>>552　が
「Boost100%でないならISO100%でない」
「ISO100%ならばBoost100%」
こう言ったのを


>>555　の馬鹿が
「Boost100%でないならISO100%でない」
「Boost100%ならばISO100%」
と捉えて大騒ぎしてる。


ということでいいですよね？

とりあえず Boost100%ならIso100%である事を誰か証明してくれ。（漏れはよく知らん）
でなきゃ>>601は証明されない。

(例)
A : x > 4
B : abs(x) > 4
「A なら B」 は成立するが、「BならA」は成立しない。

>>649
>Boost100%ならIso100%である

だから、誰もそんなこと言ってないんだよボケ死ね

結局のところ、対偶を知らない中学生が
対偶を前堤にした意見に拒絶反応を示したということか

>>648
はい。そして現時点ではboost100%のコンパイラはないので、
boostリグレッションテストの項目がISOC++の規格的に満たされる
べきものならば、現時点でのISOC++100%のコンパイラはなさそうだということ。

>>648
> >>552　が
> 「Boost100%でないならISO100%でない」
> 「ISO100%ならばBoost100%」
> こう言ったのを

全然逆ですな

> 552 ：デフォルトの名無しさん：03/10/26 20:53
> >>550
> GCCもISOC++100%取れてないからBoost100%じゃないんだろ。

リンゴとバナナが入ったおかげでスレの流れがよう分からんでよ。

藻前らそんなに暇なのか

もういいじゃん。
VCはBoost100%。GCCはBoost100%じゃない。
VCはISO 100%じゃない。GCCも当然ISO 100%じゃない。
それだけ。

552=648=652
必死すぎ

>>657
そういうセリフは下げて言わなきゃｗ

sage路線でいきましょう

今時sage厨ははヤンねェヨ

オレのおかげで見事に荒れたな。ｳﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ

>>653
確かに「Boost100%でないならISO100%でない」 とは言ってないもよう。
途中のレスが混ざってしもた、削ろう

>>552　が
「ISO100%ならばBoost100%」
こう言ったのを


>>555　の馬鹿が
「Boost100%ならばISO100%」
と捉えて大騒ぎしてる。


ということでいいですよね？

>>662
うん。そして対偶とかいろいろ言って誤魔化しているがことごとく論破されている。

>>656
VC++も今はboost100%ではないんですが。。。
一番テスト項目をパスしてることは確かだとしても。

どこのコンパイラメーカーも自分勝手な独自仕様は入れるのに、
本分たる仕様をちゃんと実装しないその様は、俺の仕事ぶりとよく似ている。

>>662
> >>552　が
> 「ISO100%ならばBoost100%」
> こう言ったのを

いや、言ってないし

> 552 ：デフォルトの名無しさん：03/10/26 20:53
> >>550
> GCCもISOC++100%取れてないからBoost100%じゃないんだろ。

>>666
「GCCもISOC++100%取れてないからBoost100%じゃない」 == 「ISO100%ならばBoost100%」

じゃないの？

>>655
俺は暇である。
つまり暇でなければ俺でない。

>>667
それは対偶ではなく裏ですな
違うものになる

>>666
> いや、言ってないし
そう。言って無いのに、

>>555　の馬鹿が
「Boost100%ならばISO100%」
と言っていると思い込んだんだろ。

みんな楽しそうだなｗ
漏れも混ぜてー。(・∀・)ノ

555が馬鹿 555が馬鹿　555が馬鹿　555が馬鹿
555が馬鹿 555が馬鹿　555が馬鹿　555が馬鹿
555が馬鹿 555が馬鹿　555が馬鹿　555が馬鹿

>>650
Oh!ボケてました。（でも死ぬのだけは勘弁な）
正しくはBoost100% < Iso100% であるかないかを証明するソースをくれ、ですな。
要するに>>562の図は正しいのかと。
でなきゃ正しいのか間違ってるのか判断できませんがな。

キモｦﾀがうるせえな。
おまえらあんま調子になってっと頃すよ？

>>673
boostがISOC++の仕様のグレーゾーンを明らかにすることはあるだろう

>「AでないならばBでない」というのは
>「BならばAである」と言ってるのと同じ意味。

これは分かる。分かりやすく言い換えると
「動物で無いなら猫ではない」
「猫ならば動物である」
だからね。

しかし
>「ISOC++100%取れてないからBoost100%じゃない」
>「Boost100%動いたらISOC++100%取れてる」

これは分からない。そもそも↑この文は

>「AでないならばBでない」
>「BならばAである」

という形とは異なってるしさぁ。

●→逆
↓　 ↓
裏→対偶

さっきから対偶対偶って言っているやつって
何が対偶でそれがどう関係するのか一言も言って無いんだよな。
こいつ対偶自体良く分かってないのかもしれない。

>これは分かる。分かりやすく言い換えると
>「動物で無いなら猫ではない」
>「猫ならば動物である」
>だからね。

未だ生を知らず、いずくんぞ死を知らん(論語)
死を知れば生を知ったということですか？

>>679
自分で何が言いたいのか説明できないこと言わない。

>「AでないならばBでない」というのは
>「BならばAである」と言ってるのと同じ意味。
これ自体間違い。

>>680
具体例を当てはめても
それで何かを説明したことにはならんということ

>>676
それは「AはBを含む」という前提での話でしょう。
猫と動物を逆にしてみ。

「猫で無いなら動物でない」 ： 正しい
「動物ならば猫である」 ： 間違い

正直大愚よくしらんから、調べたんだけど、それとりあえず書いとくね


たいぐう 0 【対偶】

（名）スル
(1)対(つい)になっていること。対称をなすこと。
「此雲の変幻出没と彼水の寂静不動と―す/日本風景論（重昂）」
(2)修辞上、対比的な語句を対称して配置すること。漢詩文などで多用される。対句。
(3)〔数・論〕〔contraposition〕一つの命題「 p ならば q である」に対して、その後件の否定を前件とし、前件の否定を後件とする命題「 q でなければ p でない」をいう。ある命題が真ならば、その対偶も必ず真である。

一つの命題「 p ならば q である」に対して、
その後件の否定を前件とし、
前件の否定を後件とする命題「 q でなければ p でない」をいう。
ある命題が真ならば、その対偶も必ず真である。

調べて思ったんだけど、最初に対偶言い出した奴も馬鹿ってことですか？

>>683
> 「猫で無いなら動物でない」 ： 正しい
茶でも飲んでおちけつ。

C++からかなり遠い話題になったな。
まぁ、こんな風に走り出したら止まらないのも分かるが、ほどほどに・・・
どっかにスレ変えたら？

まあ、>>555が馬鹿ってことですな。

552 ：デフォルトの名無しさん ：03/10/26 20:53
>>550
GCCもISOC++100%取れてないからBoost100%じゃないんだろ。

555 ：デフォルトの名無しさん ：03/10/26 21:03
>>552
いつから
「Boostが100%動けばISO C++100%」
というようになったんだ？

>>683
AならばBってのは、Aが成立するものはすべてBであることが成立するっていうことなので
「猫でないなら動物でない」ってのは
「猫でないすべてのものは動物ではない」と言っていることになるヨ

これは対偶と似ているようで対偶とは関係ない。

>>686
その通り。

>>689
仮に、
「GCCもISOC++100%取れてないからBoost100%じゃない」これが真なら
「Boostが100%動けばISO C++100%」これも真。
と俺も思う。

正しくは、
「GCCもBoost100%取れてないからISOC++100%じゃない」だろう。

あれからまだ続いてるのかよ
>>674
わざわざ他人を騙る必要があるのか？

(^¬^)(^∀^)(^∃^)(^∧^)(^∨^)(^→^)

> 552 ：デフォルトの名無しさん：03/10/26 20:53
> >>550
> GCCもISOC++100%取れてないからBoost100%じゃないんだろ。

> 555 ：デフォルトの名無しさん：03/10/26 21:03
> >>552
> いつから
> 「Boostが100%動けばISO C++100%」
> というようになったんだ？


「ISOC++100%取れる」をA
「Boost100%動作」をBとする。

>>552は
「GCCもISOC++100%取れてないからBoost100%じゃないんだろ」
と発言している。この内容は
「GCCがBoost100%動作しない理由は『ISOC++100%取れてないから』である」
という意味であり、
ここには『ISOC++100%取れてない』ならば『Boost100%動作しない』
という前堤があることを暗示している。
すなわち552は、ここにて
「AでないならばBでない」と言っているものとみなされる。
これが真ならば、その対偶の「BならばAである」も真となる。

>>555の発言は、その対偶そのものに対して
いつからそのような前堤が成立するようになったのかを確認している。

やっと理解できた

「GCCもISOC++100%取れてないからBoost100%じゃない」

この文は間違ってる。しかし俺は「ISOC++100%取れるならBoost100%とれる」とムリヤリ解釈した。

つまり馬鹿は俺だ。

>>698=552
君の勘違いのおかげでこのスレ壊れちゃったよ

そんなことより
【初心者歓迎】C/C++室【環境依存OK】
http://pc2.2ch.net/test/read.cgi/tech/1059041347/
の次スレ誰か立ててくれよ。

てへ、ごめんね。でも552とは別人だよ。

456のコードすらまともに動作しないVC++6.0とVC++7.1は
捨てましょうというのが結論

そんな下らんことで146レスも消費したのか。

698、552両名が勘違いして555を叩き続けて
146レス消費した結果が「テヘ」かよ

でも、>>552の間違いを指摘するために、いきなり対偶を持ち出したら、混乱してもしょうが無いと思う。

>>704
俺は648からの数レスだけだよ

Boostの犬になると正常な判断を失うので
まずはBoost100%などという目眩ましに
騙されないようにすることから始めよう。

>>612

>>705
「対偶も真なり」に対して直感的におかしいと感じる子供もいるらしいが、
そういうアフォを前堤にC++の話をしてもつまんなくない？

>>705
552のように真とも偽とも区別つきにくい発言
(何をもって100%と言っているのか意味不明状態)
に対しては、その対偶を突きつけて
それに対して意見させるのも、良くある検証方法だと思われ

ところでrefman2003.pdfってどっからゲットできるの？

>>709
そんなつまらん話よりC++の話をしろ！

やっべ、なんだこのスレ進行。面白すぎだ。
おまいら、もっとガンガン続けちゃってください。

>>709 >>710
2chのようなあまり推敲されてない文章が大量にある場所だと
多少おかしな文章も頭の中で自動的に意味の通る文に補正しちゃうことあるでしょ？
それを踏まえるとちょっと唐突すぎないかなと。

このコードは各処理系でどのように動作する?

#include <iostream>
class parent{
public:
int x;
parent(parent const &i):x(i.x){cout<<"C parent (parent "<<x<<")\n";}
parent(int i):x(i){cout<<"C parent ("<<x<<")\n";}
virtual void func(void){cout<<"F parent "<<x<<"\n";}
};
class child:public parent{
public:
child(child const &i):parent(i.x){cout<<"C child (child "<<x<<")\n";}
child(int i):parent(i){cout<<"C child ("<<x<<")\n";}
virtual void func(void){cout<<"F child "<<x<<"\n";}
};
int main()
{
child a(1);
parent b(2);
parent &c=(true)?a:b;
parent &d=a;
c.func();
d.func();
}

対偶しらねー馬鹿厨は
C++いじる前に日本語勉強してこいっつーこった

>>715
とりあえずstd namespace指定がないので大抵コンパイルエラーかも(笑)

そのへん補正よろしく >>717

GCCだと

C parent (1)
C child (1)
C parent (2)
F child 1
F child 1

C parent (1)
C child (1)
C parent (2)
C parent (parent 1)
C parent (parent 1)
F parent 1
F child 1

VC7.0

結局VC7.0も駄目か
WindowsでGCC使えればなあ

>>721
7.0は7.1と大違い
といってもこの件は同じ結果になるような予感もするが

VC++7.0って
parent & c = (true) ? a : b;
を
parent & c = parent ((true) ? parent (a) : b);
と解釈するの？

C parent (1)
C child (1)
C parent (2)
C parent (parent 1)
C parent (parent 1)
F parent 1
F child 1

VC7.1

対偶って (A ⇒B ) ⇒ (not B ⇒　not A) って事か？
それよりド・モルガンの法則勉強しておいた方がC++には役立つぜ。
(A and B) == not(not A or not B) ってな。
(A or B) == not(not A and not B) も。

>>721
Mingw が使える。ただ UNICODE 関連やリソース作成、デバッグなどがメンドイから、
コンソールアプリ以外では使用をお薦めしない。

>>725
矢印が違うぞ。

>>727
⇔だったっけ？

>>698
罰としておまえのハンドルはこれから「バナナ」だ。
バナナ以外での出入りを禁止する。

アセンブラコード見たけど
漏れのgcc だと　(true)?a:b; を最適化しちゃうね。
-O0 オプションつけてもだめだった。

つまり
>Otherwise, if the second and third operand have different types,
> and either has (possibly cv-qualified) class type
すら判定していないのだから、その後の型変換だの、
コピーだのが起こりようがない。

> つまり
> >Otherwise, if the second and third operand have different types,
> > and either has (possibly cv-qualified) class type
> すら判定していない

んなこたーない。

俺がプログラマーを始めたころはドモルガンとか常識だったし
and or not xorが複雑に入り組んでいても混乱しないやつらばかりだった。
そうじゃないとCとアセンブリ言語のmixed language programmingの
環境についてこれない。

最近の若いやつらは
not (not a or b) と a and not b
a and not (a and b) と a and not b
の置き換えすら満足に思考できない。
論理式の合理化ができないから無意味にネストしたif文を大量に連ねる。
たまに置き換えをやろうとすると高確率で間違ってバグを作ってくれる。
「この一連のif文の意図は何ですか?」「私にも分かりません」

あと2進数が分からないし分かりたくもないと胸を張るやつらもいる。
そんなやつらが俺が若かった頃よりも多く稼いでることを考えると
酒がまずくなる。

酔いも回ってきたころだし、寝るか

なんでこのスレこんなに早いんだよ…
突然 対偶が出てきてソレを理解できない厨によって
スレがどんどん脱線し、混乱して 収束した
ということでOKですか？

お礼外にも馬鹿なこと言ってる奴大勢居たのにどこいった？

>>730
最適化とは違う話

parent &c=(true)?a:b;
parent &d=a;
c.func();
d.func();

を

for(int i=0;i<2;i++){
parent &c=(i)?a:b;
parent &d=a;
c.func();
d.func();
}

に変えても動きの本質は変わらない

>>734
バナナさんが最後だったんですよ。
いわゆるババ抜きのババを引いたときにゲーム終了って感じですね

>>731
漏れんとこは以下ですがねぇ。

g++ -g -O0 -o main main.cpp

parent &c=(true)?a:b;
lea 0xffffffe8(%ebp),%eax
mov %eax,0xffffffd4(%ebp)
parent &d=a;
lea 0xffffffe8(%ebp),%eax
mov %eax,0xffffffd0(%ebp)

>>736
そんなババナ

>>735
コンパイル通らない・・

full adder と half adder をC言語でエミュレートせよという宿題を
出された廚がいたので適当に答えておいた。あんなもん今じゃ
ほとんど忘れかけてるよ〜

>>735
gcc でこうなった

parent
child
child
child

>>737
なにがいいたいのですか？

>>740
昔はそういう宿題出されたら必死になって考えてたなあ。
今じゃネットで質問した方が早い。
そりゃ新卒もどんどん馬鹿になって小さくなるよ。
そのうち人間に肉として食われるようになるだろう。

よーし、今までの不手際を謝りながら、もう一度まとめさせてくれ
スマソスマソ
これでいいか？

#include <iostream>
using namespace std;
class parent{
public:
int x;
parent(parent const &i):x(i.x){cout<<"C parent (parent "<<x<<")\n";}
parent(int i):x(i){cout<<"C parent ("<<x<<")\n";}
virtual void func(void){cout<<"F parent "<<x<<"\n";}
};
class child:public parent{
public:
child(child const &i):parent(i.x){cout<<"C child (child "<<x<<")\n";}
child(int i):parent(i){cout<<"C child ("<<x<<")\n";}
virtual void func(void){cout<<"F child "<<x<<"\n";}
};
int main()
{
cout<<"<1>";child a(1);
cout<<"<2>";parent b(2);
for(int i=0;i<2;i++)
{
cout<<"<2>";parent &c=(i)?a:b;
cout<<"<3>";parent &d=a;
cout<<"<4>";c.func();
cout<<"<5>";d.func();
}
}

スレ違いだけど店頭PCにいたずらスレより。
このプログラムを .js の拡張子で保存し、走らせてみよう。
俺が悩んでいるのはjavascriptにsleep()がないために、
無駄にCPUを食うことだ。

var IE;
var ti = 2000;
for (i = 0; i < 5; i++) { // ここを適当に修正
IE = WScript.CreateObject("InternetExplorer.Application");
IE.Visible = true;
IE.Width = 1280; IE.Height = 930;
IE.Navigate("http://members.aol.com/pethumor/insane.swf");
var dstart = (new Date()).getTime();
while (1)
if((new Date()).getTime() >= dstart + ti) break;
ti = ti * 2 + 1000;
}

>>745
せめてC++に移植してからにしてくれ

>>746
わかった。C++ならWin32も使えるし簡単。まあ店頭へのいたずら
なのでjavascriptの方がお手軽だから使っただけ。

>>735 でﾜｶｰﾀよ。
731==742 ﾀﾝｺﾞﾒｿ。吊っ(ry
　∧||∧

>>748
さてはおまえバナナだな？

>>744
<1>C parent (1)
C child (1)
<2>C parent (2)
<2><3><4>F parent 2
<5>F child 1
<2><3><4>F child 1
<5>F child 1

GCCです
どうせコピーコンストラクターが呼ばれないから
参考にならないかもしれませんが参考のため

バナナ＝間違いをすぐ認める素直なアフォ

555のようなものをエサと言うんだよな

驚くほど沢山の馬鹿が釣り上げられたこと

そんなババナ

ここはバナナの気持ちが分かるインターネッツですね

>744
VC++6.0
（略）ループから
<2>C parent (parent 2)
<3><4>F parent 2
<5>F child 1
<2>C parent (parent 1)
C parent (parent 1)
<3><4>F parent 1
<5>F child 1

ちなみに ((i)?a:b) にピリオドを打つとインテリセンスが働きやがります。
そしてこう書き換えても
parent &c=(i)?a:8;
問題なくコンパイルが通り、こうなった
<2>C parent (8)
C child (8)
C parent (8)
C child (child 8)
<3><4>F child 8
<5>F child 1
<2>C parent (1)
C child (child 1)
<3><4>F child 1
<5>F child 1

面白いなぁ。
しかし、演算子オーバーロードもできない三項演算子で、
オブジェクトそのものを扱うなってことか。

確かborlandC++だと３項演算子にバグがあって
コンストラクタが呼ばれてないのにデストラクタが呼ばれるとか
そんな変な動作をするような話を聞いた。

今のところ、オブジェクトの実体を３項演算子に渡すのは
避けといた方が無難なんだろうね。

特異な書き方をする奴が悪いということでFA

VC酷いな
C parent (parent 1)
C child (child 1)
この二つの出現はありえない。

VCの三項でクラスを扱うと高確率でバグを産む気がする。
とりあえず三項禁止してif文にしようと思ったが
コンストラクターでのメンバー初期化のときはどうしようか。

ｽﾚ違い申し訳ありません。
yahooの投票、みんなで「その他」に入れてみよーよ！
http://sports.yahoo.co.jp/baseball/jps/event/
面白くなるぞー！！時間がありませんのでよろしくお願いします。
一人１票です。

>>744
VC7.1

<1>C parent (1)
C child (1)
<2>C parent (2)
<2>C parent (parent 2)
<3><4>F parent 2
<5>F child 1
<2>C parent (parent 1)
C parent (parent 1)
<3><4>F parent 1
<5>F child 1

ちなみに3項演算子を以下のように参照に先にcastすると
cout<<"<2>";parent &c=(i)? static_cast<parent&>(a):b;

<1>C parent (1)
C child (1)
<2>C parent (2)
<2><3><4>F parent 2
<5>F child 1
<2><3><4>F child 1
<5>F child 1

>>758
> C parent (parent 1)
> C child (child 1)
> この二つの出現はありえない。

なんで？

ログ嫁

Ｃ++でマウスをプログラムで操作するにはどうすればいいんですか？

C++では出来ません。該当プラットフォームのスレに行ってください。

同じように言ってやりたい奴らが

まずマウスに車輪などの区動機をつけてください
話はそれからです

ロボットコンテストを目指してるのか

GCCもISOC++100%取れてないからBoost100%じゃない
の意味すら分からない低能スレはここですか？

時間の流れが他人と半日以上もずれた超人のいるスレはここですか？

>>769
GCC擁護必死だな

↑超人がキレた

ﾜﾗﾀ

♪ﾙﾝﾙﾝ♪o(^0^o)♪~(o^0^)o ~♪♪~o(^0^o)~♪(o^0^)o~♪ﾗﾝﾗﾝ♪

家を壊すぜo(^0^o)♪　橋を壊すぜ~(o^0^)o ~♪　ビルを壊すぜ~o(^0^o)~♪　東へ西へ(o^0^)o~♪

good job

ttp://support.microsoft.com/default.aspx?scid=kb;EN-US;216715
こんなのしか見つからないな。
これをＦＩＸしてあんなコードが出来たのか？

結局VCを叩いてた555の馬鹿は論破されたので
結論としてはVCが正しかったということですか
MS叩きの厨房はしつこかったな

今回MSはLoki/boost対応に主眼を置いて実際完全対応したけど、
やれば出来るじゃんっつーか、今までやってこなかったのは怠慢も甚だしいだろっつーか。
なんで7.0->7.1で出来ることを6.0->7.0時代にやらなかったんだ？

6.0->7.0間でもテンプレートとSTL相当良くなってたじゃん。

そうそう。んで7.0のバグフィックスして7.1になったからこれだけｲｸﾅったんじゃないの？

6.0のSTLはヤバすぎるので皆STLPort使ってたしな。

std::fstream hoge;
hoge.open("aaa.txt");
std::vector<double> vec;
while(hoge){
hoge >> vec;
}
ってやったら最終行が2回読み込まれるんだけど何で？

コードが悪いから

修正。
std::fstream hoge;
hoge.open("aaa.txt");
std::vector<double> vec;
while(hoge){
double tmp;
hoge >> tmp;
vec.push_back(tmp);
}

>>782 >>784
push_back()する直前にhogeをﾁｪｷすべし。

>>784
std::istreamはCと同じで読み込んでみて初めてエラーかどうかわかる。

while (true) {
　double temp;
　hoge >> tmp;
　if (hoge) break;
　vec.push_back(tmp);
}

あらら
×temp
○tmp

>>785>>786 おお！感謝！

>>778
6.0＞7.0で対応目指したんだが間に合わなかったから7.1に回されたらしい。

while(1){
double tmp;
hoge >> tmp;
if(!hoge)break;
vec.push_back(tmp);
}
と
double tmp;
while(hoge>>tmp){
vec.push_back(tmp);
}
でwhileの外にtmpを宣言するのが気持ち悪かったので
前者で対応しました。>>785>>786さんサンクス。

その２択で前者はありえないと思た。

for (double temp; hoge >> temp; ) {
vec.push_back(temp);
}

だとダメ？

>>792 をを！いい！

>>791 理由を言ってくれるとありがたいです。.
>>792 for(double temp;hoge>>temp;vec.push_back(temp)){}
ってダメですかね？今コンパイル環境がないんでためしてないですけど。

>>794
おれは791氏じゃないけど、791が普通の感覚だとおもう。
まぁ、コンパイラの最適化次第でどうせ同じになるような気もするので、
どうでもいいっちゃどうでもいいけど。

>>795 理由を教えてください。

>>796
791でも795でもないけど、
せっかく条件を記入できるようにしてるところを殺して、わざわざ終了条件をわかりにくくすることはあるまいよ。
変数のスコープを制限したいのならその周りをさらに{}で囲めばいいだけなんだし。

>>797 言わんとする感覚は分かりました。明瞭な回答有難うございます。

なんで
for(;;){}
↑ここのスコープはブロックの中なのに
do{}while()
　　　　　↑ここはブロックの外なんだ？
わざわざ外に変数作るのすげー邪魔くさいんだけど。

プログラム中で別プログラムを実行する場合はどうしたらいいんでしょうか。

pthread_createあたりで別スレッドを起動するぐらいしか自分は思い浮かばないんですが、
他に方法は無いでしょうか。

ああースレッドでは関数は起動できるけど別プログラムは無理なのかな。
となるとfork()〜exec()をやればいいのかな・・・

別プログラムを起動して何をしたいのかにもよるけど、
system() とか popen() とか。>>800

VC6で正規表現を使いたくてBREGEXP.DLLを使ってみました。
　　char *pTarget=new char[1000];
　　char *pKey=new char[1000];
　　char *pMsg=new char[100];
　　BREGEXP *pcRegExp=NULL;
　　strcpy(pTarget, "The Test of BREGEXP.DLL 2003/10/29");
　　strcpy(pKey, "/2003/2004");
　　int iResult=BSubst(pKey, pTarget, pTarget+strlen(pTarget), &pcRegExp, pMsg);

とやってみましたが、pTarget[]の文字列は置換されていませんでした。
2003を2004に置換するにはどのように入力したらよいでしょうか？

>>799
両方とも、
{for(;;){}}
{do{}while()}
こう書いたときと等価なんだから、別におかしいとは思わない。

等価じゃありません。

VBをつかってブラウザを起動（もしくは作る）しHPのFORMタグに自動的に
ID,パスワードなどを入力させるプログラムを作りたいのですが、
資料がなく困っています。いい資料orHPなど参考になるものを
知っている方教えてください。
（ブラウザを起動することはできます。）

>>805
なんかちがうとこあるの？まさか;

>>804
おかしいかどうかは知らないけど
do
{
　bool succeeded = いろいろ;
}while(succeeded);

とか出来ないのサイアクじゃない？

すみません。書くところまちがえました。
C++のすれでしたね（T_T)

>>808
while(いろいろ(...)){} でいいじゃん。

>>810
論点ずらすくらいならレスしなほうがいいと思うよ。

アフォは、放置。

テキストファイルから1行ずつ文字列を読み込んで、特定の単語を抜き出し
配列に格納するルーチンはどう設計したらいいでしょうか？

#define UNKO 1000000000000000

Cの場合これでUNKOが100000000000000に置き換えられるのですが、
これはC++でも使えるのでしょうか？
コンパイルエラーが出るので、ひょっとしたら使えないんじゃないかと思うんですが・・・

>>814
コンパイラのunsigned long intの範囲を超えたんじゃないの？

C++ではあるクラスのstaticなメソッドからそのクラスの
インスタンスのprivate/protectedなメンバは操作できなんでしょうか？

class A{
private:
　int Val;
public:
　static void doSomething(A *a){
　　a->Val=10;
　}
};

みたいな感じで。

出来ます

>>816
そういうのは試してみてから物を言ってください。

>>817,818
いや、VC++6で試してるんだが、protectedメンバにアクセスできない、ってエラーが出る。
具体的にはclass Aのスタティックメソッドからclass Aの親の親クラスの
protectedメンバを参照してるんだけど、これは無理？

無理です

ｼｮﾎﾞｰﾝ

ありがとうございました。

http://www.shitamachi.net/ranking/cgi05/ranklink/ranklink.cgi?id=05mercur

STLを使うとビルドが遅くなってしまう。
ヘッダにそれ関連を含めただけでもビルドが遅く・・・

みんな、どのように解決してる？

>816
無理矢理、やってやれないこともない
class A
{
protected:
enum {ANUM = 10};
};
class AA : public A
{
public:
static void sf(A *a){cout << static_cast<AA *>(a)->ANUM << endl;}
};
void main()
{
A a;
AA::sf(&a);
}

>>823 pimpl

>>823
速いマシンを買え

ビルド・・・
時代だなぁ。

>>823
プリコンパイルヘッダ使え

>>827
時代だねぇ

BCCもVC7.1もプリコンパイルヘッダ標準装備だし、あとgccが
プリコンパイルヘッダを装備したら、もうコンパイルの遅さを
コンパイラのせいにはできないぞよ。

んなもん、内部処理の出来不出来でいくらでも早くも遅くも出来るじゃん。

>>823
遅くなるって、何十分も何時間も遅くなるわけじゃないから、
たいした問題ではない。

>>823
マシン買い換えるのが一番手っ取り早い。

VC++の場合、コンパイル済みヘッダを使ってもテンプレートはあまり速くならない

コンパイル速度云々という話が出るたびに
PCなんて安いんだからいいの買えよって思う。

PCなんて安いんだから・・・
時代だなぁ。

5ﾏｿもあれば、アポロにのって月へ行ったマシンよりも
良いCPUの乗ったマシンがかえるもんな。
まぁﾌｧﾐｺﾝのほうが性能がよかったらしいが

ファミコンといったら任天堂。
Play-Stationといったらsony。
次はどこのメーカーの次世代ゲーム機がヒットするのかな。

チュートリアルのテキストエディタの作成に失敗しました。

>>839
それはあなたが呪われているからです。
三日以内にテキストエディタを完成できないと(以下略

>>839
金輪際プログラミングはしないと誓って、あとはファミコンで遊んでてください。
さもなくば一生呪われるでしょう。

VCのｺﾝﾊﾟｲﾙ時間はほぼCPUのｽﾍﾟｯｸに比例
ﾒﾓﾘやHDDが貧弱すぎなければの話だが

P3/550で5分
豚25で1.5分

反比例だなｽﾏｿ

>>823 pimpl

↑めんどくさいよー。
それに外向けのサービス関数に、STLのコンテンツへの参照渡しなどに
したい場合、結局、ヘッダにSTL絡みのヘッダをincludeするはめになるし。

>>844
トレードオフってやつですよ。

>コンパイル速度云々という話が出るたびに
>PCなんて安いんだからいいの買えよって思う。
いや、だから、3.2GHz程度のPCでは速度的に足りなくて不満だから
別の解決方法を模索してるのに・・・。

完全ビルドに45分かかってる。
仮に数年後に10GHzなCPUが登場してもなお、15分前後はかかる計算に。
しかも、ソースファイル数が100にも届かない初期段階。
おそらく開発後半は2時間かかるかも。

完全ビルドになりにくいようなヘッダファイルを構築する工夫があるが
これはこれで手間時間というコストがじわりじわりと効いてくるし
そもそも本質からは離れた作業。

「じゃ、テンプレート捨てろよ」と言われても、今更捨てられない。
捨ててしまう犠牲は計り知れない。

はてさて、どうしたものか。

各ヘッダでincludeするのやめろよ。先行宣言だけにせえ。
ヘッダ間の依存関係を極力なくせよ。

>>各ヘッダでincludeするのやめろよ。先行宣言だけにせえ。
横からつっこみ入れるけど、返却値だとか引数にSTLなどの
テンプレート使った時点で、それら標準ヘッダファイルをincludeせねば
ならない。仮に参照渡しやポインタ渡しのみ必要な場面であっても
先行宣言（存在仮宣言）だけが記述されたヘッダファイルというのは
STLには存在しない。

ヘッダ間の依存関係を極力なくしても、避けられない共通モジュールで
STLを使っていたら、全ての苦労が水の泡。

CPUパワーが100倍近く足りないという感には激しく同意。

小物ツールでよいならば、それこそ500MHz程度のPCで十分んなのだが。

HDD速い方が効果的なような

>>847
> 完全ビルドに45分かかってる。
どういうコードをビルドしてるんだ？

俺が今仕事でいじってるのは C++ とアセンブラで合計 7 万行程度のプログラムだが、
これでも gcc でフルビルドに要する時間は 2 分程度だぞ。CPU 8 つ使ってるけど。

＞俺が今仕事でいじってるのは C++ とアセンブラで合計 7 万行程度のプログラムだが、
＞これでも gcc でフルビルドに要する時間は 2 分程度だぞ。CPU 8 つ使ってるけど。

ん、それ、x8なら単一CPUで流したら、16分かかるでしょ？
C++というより、テンプレ使うか否かがボーダーラインだし。
仮に847のプロジェクトが20万行程度の規模だったら丁度、45分だろ。
ありえない話でもない。

gccが異様に遅いのが悪因なわけだが。

>>852
> ん、それ、x8なら単一CPUで流したら、16分かかるでしょ？
CPU に比例してリニアには延びないよ。gcc だとリンク時間も長くなりがちだし、dual
processor のマシン一台でもせいぜい 6 分程度。コンパイルだとファイル I/O 待ち
時間がかなり多くなりがちだから、

o 複数のファイルを同時にコンパイルし、入出力をオーバーラップさせる。経験上、
　プロセッサ1つにつき 2 - 3 ファイルを並列ビルドするのが良い。
o 主記憶を多めにとって、ファイルを極力キャッシュに載せる。ディスク入出力を
　可能な限り少なくする。分散ファイルシステムを使っている場合にはパラメタ
　要調整。

といった対策を取ると、コンパイル速度が向上する。

ちなみに俺のトコロだと Athlon MP 2100+ * 2, DDR SDRAM 2100 1GB というマシンを
4 台ネットワーク上に並べて分散ビルドしてる。だいたい、各マシンで同時に 4 ファイル
並列コンパイルするように設定。

GCCなら-pipeオプションや、/tmpをメモリ上に配置するだけで
かなり速くなる。VC++でも中間ファイルをディスクに書き込まない
設定とかあるんじゃないのか？VCが遅いとか言ってるのは
使い方がおかしい気がするが。メモリを沢山積めばソースファイルは
ディスクキャッシュが効いて、メモリ上に貼り付けになるしな。
まあ、どうでもいいがスレ違いだ。

>>855
> VCが遅いとか言ってるのは使い方がおかしい気がするが。
ありがちなのが pch の設定ミスだね。

> まあ、どうでもいいがスレ違いだ。
そうかも。

とりあえず iosfwd みたいなのが STL にも欲しいよな。

>>857
同意
iosfwdしか先行宣言ヘッダがないのは標準の片手落ちな感じ。

g++ について来るヘッダには bits/stringfwd.h ってのがあるなぁ。
あとは containerfwd.h とかってモンでも自分で作ればいいか。
なんか今までは「メンドイからいいや」とか思ってたけど、ちょいと作ればいいだけじゃねぇか。

gccでおそいって言ってる人に聞きたいんですが、デバッグ情報生成させてますか？

こんぱいるor実行 速度
どっちの話だ？

ん？コンパイルの話ですよ。

g++で遅いって話はテンプレ使ってるからだろうってことでスレ違いになったよ。
>>1 周辺を読んでね

テンプレートと既成のテンプレートライブラリは別だろ。

gccはもともと速いコンパイラじゃないだろ

>>865
遅いと言うのは相対するものがないと言えないんだがなんと比べてるんだ？

>>864
別ですが。それで何？

>>866
時期時期で一般的なコンパイラ
TC/SC/MSC全盛の時代からgccが一番遅かったし
他プラットフォームの事情は知らんけど。

GCCってコンパイラの最低基準じゃないのか？
断罪されるべきはあれよりヘボイ物作っておきながら
金取ってる連中だろ。

コンパイラ間の比較はそれぞれが持っている機能に差がありすぎて
比較のしようがないような。。。

>>869
だからBCCも無料になったんだろ

>>869
> GCCってコンパイラの最低基準じゃないのか？
そういう問題じゃないだろう。

gcc はコンパイル環境・ターゲット環境ともマルチプラットホーム前提、場合によっては
コンパイルだけは gcc を使うがアセンブラやリンカは binutils を使わずベンダのものを
使う事もある、と汎用性を最重視している。

他のコンパイラは、また別のトコロに重きを置いている。プラットホーム固有の最適化
だったり、ウィンドウアプリケーション開発のための統合開発環境だったり。評価軸が
違うから、いちがいにどっちが良い悪いとは言えない。

>>868-869
香ばしすぎ！

>>873
何と比べて遅いか聞かれたから答えただけだが
どこが同おかしいのか説明してくれ

>>874
カキコしてから>>868はそうなのかもしれんとおもた。ゴメン。

同じソース行数で比較した場合、vc++がgccに比べて最低でも5倍は
速い。ただし、生成されるコードの速度に関しては特にその差は見られなかった。

Windows系はwindows.hという巨大ヘッダが立ちはだかってるから
早期からプリコンパイルヘッダが要求され、実装されてたもんな。

>>876
optimizerの設定は?

＞Windows系はwindows.hという巨大ヘッダが立ちはだかってるから
＞早期からプリコンパイルヘッダが要求され、実装されてたもんな。
そうだね。このあたり、小さなプログラムばかりをターゲットとしてた
gccは完全に遅れをとってる、というか未だに工事中な機能だしね。

インラインマクロを修正して、その挙動を確認するのに
全ビルドになってしまい、1時間かかってしまうこともあるからなぁ。
さらに、その1時間、別のことをしていて、なにを検証確認すべきかも
うっかり忘れてしまうこともあったりして。

1分なら待てるけど。
となると、やはりPen4換算で、180GHz のマシンは欲しい。
えっと、CPUパワーが60倍になるのにどれくらいだろ？
10年はかからないと思うけど、5年はかかるよね？

>>880
開発中にインラインなんて使わんだろ。何考えてんだ。
インラインにするかどうかは最終段階でプロファイル見て決めるんだよ。

Pen4の3GHｚのマシンで1時間もかかるもの書いてるならコンパイラ変えたら。

インラインマクロって何だ？

>>880
ムーアの法則 http://e-words.jp/w/E383A0E383BCE382A2E381AEE6B395E58987.html
によると、大体 21ヶ月で４倍だから...

(log 60 / log 4) * 21 ≒ 62ヶ月 ≒ 5.2年 ぐらいかな。

>>883
処理手順のマクロのことじゃね？

>>885
全然意味がわかんない。

こんなマクロの事だろ

BEGIN_MSG_MAP(CMainFrame)
MESSAGE_HANDLER(WM_CREATE, OnCreate)
COMMAND_ID_HANDLER(ID_APP_EXIT, OnFileExit)
CHAIN_MSG_MAP(CUpdateUI<CMainFrame>)
CHAIN_MSG_MAP(CFrameWindowImpl<CMainFrame>)
NOTIFY_CODE_HANDLER(LVN_COLUMNCLICK, OnListViewColumnClick)
END_MSG_MAP()

マクロっていつでもインラインでは。

>>881
インラインぐらい開発中でも使えよ。

>>889
880の例があるように、結構コストが高いのですよ。

>>890
それは各モジュールの独立性がほとんど確保できてなかったり
短くてもインラインにすべきでない関数の判断ができてないのが問題だと思うけど。

>>891
容易に判断を誤るものを「インラインぐらい」というのがおかしい。

>>892
そんなに容易に判断を誤るものなのか？

>>893
"Inlines are the third most-misused C++ feature (after inheritance and overloading),
used far more often than any practical criterion could justify,
just because it is more covenient to write them in place.
Anything that encourages their use beyond strict engineering merit is detrimental."

inline にも export みたいな仕様が欲しいな...。
そして、仕様に入ってるだけじゃなくて、ちゃんと実装してホスィ...。

>>894
どっからの引用かは知らんが、だから何？

>>896
容易に判断を誤るわけですよ。

そういうもんなのか。
漏れは最初は容易に判断を誤っても、
すぐに慣れるもんだと思ってたんだけど、
みんなは容易に判断を誤っちゃうのか。

>>898
お前も間違って判断してるだろ。そんなもんだ。

900get & さらしあげ

>>899
覚えたてのころはよく誤ってたけど、
少なくとも最近は誤った覚えはないぞ。

>>901
だから何？

>>902
「容易に判断を誤る」ってことに懐疑的なだけ。

なんで誤ってないと核心できるんだろう

>>904
主観による判断でなにかいけませんか？

>>904は釣り

漏れの1メートルが正しい！

判断基準を明記せずに「誤ってない」とかいっても無意味。

謝った結果の悪影響には、実装の変更による再ビルドの影響、
パフォーマンスの悪化、そして出力コードサイズの増大なんかが
あるが、これらをどんなバランスで重要視するかだよな。

モジュール数が多い開発になるなら、実装の変更による再ビルドの
悪影響が耐えがたいほどになるため基本は非inline。pimplにするもいい。

パフォーマンスについては、ほとんどの場面でinlineにしても大して効果がなく
実際に大きな効果がある場所の判断は熟練してても間違いやすいので計測で。

>>908
ほぼ同意するが、結局はそれも主観。

雑談するならC言語スレに逝けよ

いや、ここでいい。
inlineな話題の延長だからな。

低脳ほどくだらんネタに拘るからな。
誰かにカマって欲しいならラウンジにでもいってこいよ。

>>912
ふーん、君はラウンジにお友達がいるんだ(w

↑すげー論理の飛躍

↑行間を読めないヤシ

インライン関数は.inlに書いて、リリース時はヘッダにインクルード
デバック時はソースにインクルードする手法が一般的になりましたが
さていかがお過ごしですか、みなさま。

そんな手法は一般的じゃありません

じゃあ、今からは取り入れて快適なC++ライフをお過ごしくださいね。

だからわざわざそんな面倒くさいアプローチとらにゃならんほどは
間違えないんだって。

別に大してメンドクサクも内ですよ。一度試してみてはいかがですか？

>>920
仮に間違えたってそのロスはビルドしなおす時間分だけで済み、
且つ実際には一度も間違えないのに、無駄に作業ステップを増やすことはないだろ。
少なくとも漏れにとってそれはチャリの補助輪と同じ。
一度チャリに乗りなれたら邪魔なだけ。

C++の質問なら私にきいてもいいよ♪お兄ちゃん♪
http://www.ichigobbs.net/cgi/readres.cgi?bo=proglam&vi=0069&rm=50

>>921
> 仮に間違えたってそのロスはビルドしなおす時間分だけで済み、
それが問題だというのがスレの流れ。前提を破壊するなよ。

>>923
日本語読めない子は放っておけ。

>>923
じゃぁ、そのだけ無視すれば。

assertion系マクロを有効/無効をチェンジするにも、
全部ビルドせねばならないし。開発後半、この切り替えは
重くのしかかってくるよ。

実装判断が間違えてなくても、厳しい例があるってこと。

>>926
ビルドディレクトリ分けてないの？

>>仮に間違えたってそのロスはビルドしなおす時間分だけで済み、
えっと、2chなのでいろんな環境の人が混じってるので、前提条件も
様変わりする思うのですが〜、とりあえず、ビルドしなおす時間が
数時間にわたるケースも決して珍しくないという点。

全ビルドをなるべく避けたい現場ってのがある場合、どういう工夫がある？
というのが流れ。

>>926
コンパイルオプションで部分的に有効にできるようになってればいいのにね。
なんでそんな構造になってるの？

>>928
>>881 に過剰に反応してしまったけど、
そういう意味でなら了解。

>>926
>全部ビルドせねばならない

いたたた