1 ：
デフォルトの名無しさん ：
04/06/02 23:08 C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
テンプレートライブラリ(STL含む)に関する質問は
専用の別スレにお願いッス。
過去スレ、関連スレ、関連リンクなどは
>>2-9 あたり
4 G E T
6 G E T
8 G E T
Z
14 ：
デフォルトの名無しさん ：04/06/02 23:51
前スレのclassとstructだけど、javaからきた人(?)はinterfaceのかわりにstructとか
15 ：
デフォルトの名無しさん ：04/06/02 23:53
>>14 逆に聞くがインターフェイスでprivateにすべきメンバとは？
17 ：
デフォルトの名無しさん ：04/06/03 00:20
以下のコードをコンパイルすると、
ごめんなさい。
>>19 改行が多すぎるといわれたので、つめてしまってました。
実際には、以下の行でエラーになってました。
acc_vcl_delete(NULL, (chpiPliValueCBFT*)chpiPliValueCBF, ch, 2); }
STLつかうと一気に実行ファイルサイズが10倍に?！
>>22 環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。
>>1 すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
はいはい、スレ1つにつき1回だけだよ。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
>>27 #include "stdafx.h"
後死ね。
>>28 言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
つりはよそでやれ。あとググれ。
ググレカレー
32 ：
デフォルトの名無しさん ：04/06/04 01:32
ファイルからMD5ハッシュ値を計算して１６進表示させたいんですが
>>32 このスレのタイトルを声に出して10回嫁。
>>32 そのファイルが読み込めるだけの記憶域を取得できれば可能。
だがその前にスレタイ読んで回線切って（tbs
35 ：
デフォルトの名無しさん ：04/06/04 07:45
fopen系、fstream系、CreateFile系
>>35 そりゃ、fstream。C++スレだしな。
個人的にはCStdioFileがおすすめだよ。
>>35 iostreamが楽
#DirectXのファイル入力これにしてくれよ～>MS
>>35 ライブラリを使わない時は API。それ以外は fstream。
fopen は間違っても使わない。
取り合えず禿になる前に慣れろ。
便乗で質問なんですが
>>40 手の出せない領域ってなんだ？
例えばVC++6.0の標準ライブラリならソース追っかければ分かるが、最終的にFILE構造体を
確保してるのはただのmallocだが。
はじめまして、こんにちは！
>>42 このスレのタイトルを声に出して10回嫁。
と言っても理解できそうにないな。
スレ違いだ。VCスレに逝け。
>>11
Win32APIスレだと思うが
意外とfstream使ってる人多いんだな！
>>43 お口は悪いようですが、親切なんですね。
教えていただいたところを見てみます。
ありがとうございます。
>>45 int basic_istream::gcount( );
>>40 C++ の場合、basic_filebuf がソレ
>>45 fstreamなんて糞だから間違っても使うな。
fopen系で処理しとけば問題ない。
std::stringの後ろ1文字削るのにresizeとeraseどっちがいいと思う？
どちらも使わずそのまま使う。
例外について教えてください。とある関数が
53 ：
デフォルトの名無しさん ：04/06/05 08:11
>>52 ISOでもJISでもいいが規格票の 15.4 の 8 を読んでみれ
横槍でスマンがもまいらひとつ教えてくれ。
>>52 >とあったとすると、int型は関数の例外指定に無いので、throwすると
>代わりにbad_exceptionが投げられると本にあったのですが、
どんな本だ？(((( ;゜Д゜)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
>>57 こういう事だろう。VC++6.0のような古い処理系では動くかどうか知らんが。
#include <iostream>
#include <exception>
void my_unexpected_handler()
{
throw 1234;
}
void f() throw(std::bad_exception)
{
throw int();
}
int main()
{
std::set_unexpected(my_unexpected_handler);
try {
f();
}
catch (const std::bad_exception& e) {
std::cout << e.what() << std::endl;
}
catch (int i) {
std::cout << "User defined unexpected hadler threw " << i << std::endl;
}
}
>>50 pop_backみたいな、ぴったり合う操作が無いな。push_backはあるのに。
resize(size()-1)のほうが効率はよさそう。
erase(end()-1)のほうがソース上に突然現れたときに意味がとりやすそう。
まじめなソースなら、
inline void pop_back(std::string& s){ resize(s.size()-1); }
と定義してしまうのが最善手かと思う。
レスありがとうございます。
>>54 俺は買ってるが。プログラミング言語 C++ は言語制作者の手による本だとは
言っても、結局、微妙なところになると載ってないし。
JIS から買うと高いが ANSI から PDF で買えば US$20 しないぞ。
ISO で規格制定した C++ をJIS/ANSIから買えるって？
1000ページの解説本ですら解説しきれない仕様そのものが問題だな。
>>60 違う。unexpected()関数はデフォルトでは常にterminate()しか呼び出さない。
set_unexpected()でunexpected()の代わりに呼び出す関数を入れ替えた時のみ、
その入れ替えられた関数がstd::bad_exceptionを投入する。§15.5.2.2
66 ：
デフォルトの名無しさん ：04/06/05 14:37
あるクラスＡが、別のクラスＢのインスタンスへのポインタを
>>67 サンクスコ。2003の最新のですた。
でも1998のpdfは今はもうタダなんでつか？>61さんは
$20って書いてましたが。。。
>>66 それだけじゃだれにもわからない。
自分で使っている「シングルトン」の実装を調べれ。
質問おながいします。
>>70 C++なら<cstdio>をインクルードしてstd::getcharが正解。
でも、VC6では通らないかもしれない。
>>71 レスどうもです。
#include <cstdio> はできないんでつ。というかなぜか
全部のコードがstdio.hなんでつ。（単に古いからだと思うんでつが）
先輩はgetchar()でええやないかって言うんですけど、なんで
::が付けられないのか気になって仕方ないもんで。
>>70 ごめんVCのgetcharはマクロでも定義されてるみたい。
#include <cstdio>
#ifdef getchar
#undef getchar
#endif
これでstd::getcharでいけるようになる。
どっちがいいかは微妙。
規格はこのマクロ定義を許しているんだろうか？
gccのcstdioでstdio.hのマクロは全部#undefされてた。
>>71 調べててレス遅れました。
「VCのgetcharはマクロでも定義されてるみたい」でハッとして
VCのソース見たら
#define getchar() getc(stdin)
とされてて、これはまあいいのですが、次に
#define getc(_stream) (--(_stream)->_cnt >= 0 ? 0xff & *(_stream)->_ptr++ : _filbuf(_stream))
とマクロ展開されてました。
これでは ::getchar() が通るわけないでつ。スッキリしますた（´･∀･`）
どうもありがとう。。。 それにしてもvcってへんな実装でつ。
getcはマクロで実装してもよかったような希ガス。
>>77 たった今DLしますた。なんかわからんけど
ディスカウントが効いて$13.5ですた。
サンクスコですた(･∀･)！！
runtime_errorクラスの派生クラスでrange_errorっていうのが
vector<int> v(10);
81 ：
デフォルトの名無しさん ：04/06/05 19:45
>>54 52のような質問をする必要がなくなるという事例を現に目撃しながら、何が聞きたいんだ？
>>80 それっていわゆるout_of_rangeという例外クラスにあたるんじゃ
ないですかね・・。つまりロジックで回避できるものという。
runtime_errorというのは、プログラムのスコープの外で単純に回避
できないイベントを通知するのだそうです。
派生クラスは
range_error
overflow_error
underflow_error
このrange_errorというのがよくわからないんです。
>>82 overflow, underflow と並んでるってことは、その手の「範囲外」を通知するのに
使うことを想定してるんじゃないの？
有効な値の範囲が連続なら underflow, overflow だけで表現できるけど、
とびとびだったりすると、どっちとも言えんよね。
84 ：
デフォルトの名無しさん ：04/06/05 20:37
85 ：
デフォルトの名無しさん ：04/06/05 20:53
>>84 vtblは関係ないよ
いいから、言うとおりの順に紙に図かいてみろ
・Object型のオブジェクト１個（仮にaと名づける）
・aへのポインタ１個（仮にpaと名づける）
・paへのポインタ１個（仮にppaと名づける）
・Test型オブジェクト１個（仮にbと名づけ、aがbの部分オブジェクトになるように）
・bへのポインタ１個（仮にpbと名づける）
・pbへのポインタ１個（仮にppbと名づける）
おまいさんがやろうとしていることは、
reinterpret_cast<Object**>(ppb)だ
>>84 Test **t=0;
Object **o=t;
これが出来ないから
>>85 指摘ありがとうございます。
ネットで調べたら
reinterpret_castは単なる型変更であり、たとえ派生関係があったとしてもポインタのアドレス自体はキャスト前と変わりません。
その意味でreinterpret_castは非常に危険なキャストといえるでしょう。
とありました。正直Castについて、完全に理解してないもので、とりあえずCastの部分が私が間違っていたということでしか、まだ理解できてません
が、返事が遅くなるといけないから、一応レスを書きました。Castについて勉強して、もう一度検討してみたいと思います。
せっかくレスを頂いたのに、まだ理解できなくてすいません。
>>86 なるほど、わたしのしてたことは、それに似たことだったのですね、上で書いたように、もう一度じっくり検討してみます。
どこに着目すればよいかわかりましたので、大変助かりました。ありがとうございます
>>80 vectorは確かoperator[]で範囲外アクセスした場合、未定義だったと思う。
vector<int> v(10);
v[15]=5;
v.at(15);
でatの方は例外を投げたと思うけど。
bitsetの方は覚えてない。
>>88 std::bitsetも[]による範囲外アクセスは未定義のふるまい。
90 ：
デフォルトの名無しさん ：04/06/06 00:56
std::bitsetの要素は1bitですが、要素がN bitのものはありませんか？
93 ：
デフォルトの名無しさん ：04/06/06 10:59
Nの大きさに合わせてvectorを使ったりbitsetを使ったりする
ちょっと質問なんですが、
>>95 ポインタを返す関数の戻り値に、
その関数のローカル変数のポインタを使うようなもんだ
>>96 >>97 やっぱそうですか。
じゃあ int& を const int& にした場合どうなりますかね?
一時オブジェクトをconstリファレンスで受けると寿命が延びますよね。
その例として型がintなのはよろしくないかもしれませんが。
>一時オブジェクトをconstリファレンスで受けると寿命が延びますよね。
コンストラクタ抜けた時点でデストラクタ呼ばれてるようですorz。
>>95 コードブロックの最後にデストラクトするのは、実装依存ではなくて
仕様。それにコンパイラは、ブロック外でアクセスされるのを
検知して、寿命を延ばすことはしない。（警告を出すことはありうる
だろうけど）
ARMに書かれているのは、テンポラリがconst参照されている場合
、その参照の寿命にしたがうということで、ここではcはテンポラリ
じゃないからね。
>>103 というか cのとこがテンポラリだったとしても直接受けるのはコンストラクタの引数なので
コンストラクタ抜けた時点でデストラクタ呼ばれるんですよね。
＞コンストラクタ抜けた時点でデストラクタ呼ばれるんですよね。
>>105 cのとこが一時オブジェクトだった場合、Aのコンストラクタが終了した時点で一時オブジェクトのデストラクタが呼ばれます。
>>106 p = new A(C());
こんな事やってんじゃね？
>>95 == 104
>というか cのとこがテンポラリだったとしても直接受けるのはコンストラクタの引数なので
>コンストラクタ抜けた時点でデストラクタ呼ばれるんですよね。
レス遅れてすまそ。そうだった。漏れも勘違いしてた。
そのテンポラリで初期化されたのなら、参照変数に束縛（？）されるだろうけど、
変数として渡されたのなら束縛できないね。（コンパイル時に値（テンポラリ）が
確定しないから、C++が寿命管理できない）
で、誰にも束縛されてないから、すぐに（この例だとコンストラクタ抜けたあと）
削除されちゃうね。束縛されてれば最大テンポラリの作成されたスコープいっぱい
生きられるみたいだけど。
>>110 A(int& a):test(a){}; を
A(int& a):test(int(a)){};
みたくしたらテンポラリで初期化するから生き続けるかなあと思ったけど
(もちろんこんなことするくらいなら値渡しすればいいんだけど)
コンストラクタ抜けたらやっぱり死にました。そういうもんなんですかね。
ところで参照のメンバを使う時ってどんなときですか?
>>111 > ところで参照のメンバを使う時ってどんなときですか?
生成順序、破棄順序に明確な親子関係がある時かな。
被参照クラスは参照するクラスのコンストラクタで渡さなきゃいけないし、
参照するクラスのデストラクタが呼ばれる前に非参照クラスが破棄されると
普通は困るから。
ところでみなさん、C++ のソースファイルの拡張子は、何にしてますか？
cxx
.cpp
VC++だと拡張子つけないと勝手にcppだからcpp。
zshでは、cpp は、C++ の拡張子としては、扱われてなかった。
え、設定変更できないの？
zstyle を使えば、変更できます。
ちょいと本読んでたら気になる表現があったのですが
int i;
123 ：
デフォルトの名無しさん ：04/06/06 20:10
>>121 もしかして「デストラクタの明示的な呼び出し」の間違いか？
全然関係ないが
A c; はオブジェクトの定義
A c(); は関数の宣言
たぶん、explicit の話だろう。
>>114 .EXTENSIONOFC++SOURCEFILE
あ、
読み間違いの予感
だから、「explicit+コンストラクタ」でぐぐってこい
>>128 デフォルトコンストラクタにexplicitもクソもあるか。
明示かどうかで挙動が変わるのは組み込み型のデフォルトコンストラクタ。
その明示的と明示的じゃないというのは、表現方法はどう違うのでしょうか？
131 ：
デフォルトの名無しさん ：04/06/06 22:59
>>130 例えば、デストラクタなら
{
hage stroustrup;
} // 暗黙の呼び出し
this->stroustrup::~stsoustrup(); //明示的な呼び出し
132 ：
デフォルトの名無しさん ：04/06/06 23:08
const hage& hage::operator = (const hage& BullShit)
s/stsoustrup/stroustrup/
135 ：
デフォルトの名無しさん ：04/06/07 01:55
A.h (class Aを定義)
>>135 色々自分でいじくってたら自己解決しました。
すんまそん。
>>133 吊るより
9階からああ飛び降りろ。
間違っても芝生のないところでやれ。
できるなら30階以上のところでやれ。
確実に死ねる
141 ：
デフォルトの名無しさん ：04/06/07 11:45
C++ では類の実体を函数の返値にできるよね？
C++には自信があったのですが、141の日本語が理解できない漏れは、９Fからフェンスめがけて飛び降りるべきでしょうか。
「クラスのインスタンスを関数の返値にできるか？」
144 ：
デフォルトの名無しさん ：04/06/07 13:05
カタガナ語？？？
>>144 そんなにｵﾅﾆｰ好きなのに
よりよいｵﾅり方を人に訊くのか…
入門書買え、読め、と叩かれそうなぐらい初歩の初歩の質問を、
必死な低学歴が大量なスレですね
149 ：
デフォルトの名無しさん ：04/06/07 17:51
>>142 カッターで頚動脈切ってもらった上で15Fぐらいからダイブしたほうがいいぞ。
今は9Fからダイブするのがナウイ
今死ぬなら60F。
C++はCに比べて遅いというのは良く聞く話ですが、具体的にどれくらいですか？
具体的に聞きたいならどういったコードの実行性能かを具体的に書け
>>153 科学計算用途です。行列演算とか、フーリエ変換とかが入った計算。
C++の既存の科学計算ライブラリ >>>>>>>>>>>>> 152の書いたCの科学計算コード
>>155 ライブラリ呼び出しだけで書けると思ってるの？ｳﾞｧｶ？
>>152 処理系もライブラリもコードも示さないで比較もくそもないと思う。
そして処理系もライブラリもコードも示せるなら自分で計測すれ。
純粋な数値計算でC/C++の差が出ることってある？
>>158 数値計算はライブラリの質が大きいが、シミュレーションとか、
もっと一般的に言って物理エンジンなんかはどうなのさ？
>>152 全く聞かないけど？
実際は、C≒C++>>>>Java ぐらいじゃないか？
CとC++とJavaで同じ処理を試すということは、
クラスライブラリなどを一切使わないってことだよね？
> C≒C++>>>>Java
>>158 あるよ。
expression template などを使わず。単純に見易さとか書きやすさだけを求めると
遅くなるよ。もっともC++ではそういう書き方もできるという意味で、C流に書けば
いいだけなんだけどね。
#expression templateも+,-,*などの単純計算ならなんとかなっても逆行列なんかには
#無力だけど。
継承レベルを出来るだけ浅くして、オブジェクトの生成も出来るだけしないようにすれば遅くならないよね。
164 ：
デフォルトの名無しさん ：04/06/08 22:53
>>164 162 じゃないけどMATRIX operator+(MATRIX const&, MATRIX const&) とか。
何も考えずに書くと、戻り値で値のコピーが発生して遅くなりがち。
>>163 君にはきっと C のほうが向いていると思う。
結局書き方の問題であって、生成されるオブジェクトの
>>165 その計算はCだろうが戻り値のコピーは避けられないと思うが？
戻り値最適化を前提にしちゃいかんのはわかるが
Cで書けば同等の役割を持った上で高速に動作するコードを示してほしい
つーか expression template の話してるところで
「何も考えずに書くと」のケースの話されても一体何と何を比べてるんだって感じなんだけど
>>164 一番速度差が出やすいと言われるのはこんな場合。C++だと、
Matrix a,b,c,d,e;
for(int i = 0; i < takusan; i++){
a = b*c+d-e;
}
ってな計算。
なーんにも考えず二項計算だけ定義すると、
b*cの結果、それと+dの結果、
-eの結果、それぞれを確保、開放
繰り返してたらそりゃ遅くなるでしょ。
C流に書けば、a.b,c,d,e,tmp,tmp2,tmp3は適当に定義してあって、
関数にはポインタで渡すとして
tmp =(XXX &)malloc(sizeof(datasize) * matrixsize);
tmp2 =(XXX &)malloc(sizeof(datasize) * matrixsize);
tmp3 =(XXX &)malloc(sizeof(datasize) * matrixsize);
for( i = 0; i < takusan; i++ ){
mul(b,c,tmp);
add(tmp,d,tmp2);
sub(tmp2,e,tmp3)
}
で作業域は一回だけ確保しとけばいいってこと。
でも、計算式そのまま書けば計算できるC++流の関数と
C流の関数両方用意しとけばいいからC++が遅いってことにはならないよ。
Cだと見にくい書き方しかできないけど。
あと、式テンプレートは結果の作業域は用意しなくてもいいんだが、
結局計算式そのものをどっかに格納しとかなきゃいけなかったりする。
(XXX *)
C++は速度を犠牲にして保守性を向上させているというのは都市伝説の類ですか？
>>169 言いたいことは分かるんだけれども
その例はC++でも
結果を格納するためのオブジェクトと op= の形式の演算子使うだけで
C流の関数なんて使わなくともそこそこ可読性を保ったままパフォーマンスを同等にまで上げられる。
しかもこれ、割とよく知られている最適化テクニックなんであまり適切な例ではないような。
速度求めるならSSE2命令使ってコーディングしてるatlas + fortranが速い。
>>173 Intel系ならそうですね。WSやマックは切り捨てですか？
atlasが速いのは、出来るだけキャッシュに入るように工夫してるのが大きいと思うのですが…。
InterlのMKLなんかはP4のパイプラインの分岐予測を乱さないように最適化されているみたいですし。
そこまで行ったら、言語の問題じゃないような気がする。
175 ：
デフォルトの名無しさん ：04/06/08 23:55
ちと気になったので質問します。
fortranの場合並列処理に分割し易いとかそういった理由で科学計算の
>>175 std::stringとかstd::vector<char>とか使え。C++なんだし。
>>175 char** filenames = (char**)malloc(sizeof(char*)*n);
じゃだめなのかね。
>>175 つ[std::vector<std::string>]
しまった、C++スレでした。鬱山車脳。
というか構造体を定義することと動的配列の実装に何ら関連性がないのだが。
char (*files)[MAX_PATH];
>結果を格納するためのオブジェクトと op= の形式の演算子使うだけで
> 誰でもすぐに書ける
>>183 何言ってんのかわかんない。
void add(MATRIX&, const MATRIX&, const MATRIX&);
みたいなC式のスタイルはC++でもできる。
C++式のスタイルは使いかたによってはパフォーマンスが悪い、それだけだろ。
>>174 >Intel系ならそうですね。WSやマックは切り捨てですか？
Pen4 に atlas 使って遅い用途ならWSも糞マックも役にたたんだろうからどうぞ捨ててくれ。
故意にC++を難しくみせようとしているヤツがいるな。
op= と op じゃ実装も記述の手間もろくすっぽ変わらん。
問題なのは可読性が下がることだけ。
>>169 が言ってるのは、
a = sub(add(mul(b,c), d), e);
より mul_assign(b,c, tmp); ...（以下略） とする方が早いという以上の何者でもない。
それをC++の演算子オーバーロードに置き換えれば op と op= の違いになる、というだけ。
可読性と保守性と速度を全て満たした言語は無いのか？
>op= の形式の演算子使うだけで
おおっと、定数には使えるよ
浅はかな
>>172 ,
>>187 は、
A *= Bの計算を作業域使わずダイレクトにできると思ってるんだろうね。
おめでたいこった。
>>190 話のポイントのつかめんやつだな。
CとC++でどこが違うかって言ってるんだ。
>>166 でも一時オブジェクトは確保してるだろ。
どこで一時オブジェクトがいらないなんて話になったんだ？
＃さらに言うと *= の場合、
中途で確保する一時領域は行単位で済むから * よりも
オーバーヘッドは小さくできるぞ。
>>191 Cでは作業域使わずダイレクトにできるのか？
出来ないよな。なら特に今回の話に関係無いよな。
で？
>>192 >>193 作業領域を中で確保して値渡しで返す(もしくはswapする)のと、
外から作業用兼結果用の領域をもらうのとは結構違うと思うよ。
>>192 おつむの悪い僕ちゃんだな。
いいかい。
op= を遣う理由で一時作業領域を省略できる以外になにかあるのかい？
Matrixの*=の場合はそうならないから指摘してるんだよ。
#＃さらに言うと *= の場合、
# 中途で確保する一時領域は行単位で済むから * よりも
# オーバーヘッドは小さくできるぞ。
ハイハイ。がんばれよ。頭だけじゃなく往生際も悪いようだ。
void mul(Matrix *ret,const Matrix *a,const Matrix *b);
>>195 いいでしょう。
*= については、a *= b ではさらに新たな一時オブジェクトを作る tmp2 = a * b; に対して改善が見込めないという部分は認めよう。
でも、Cでこの書き方より速くできるかという部分については納得する意見をもらってないよね。
>>196 だーかーらー ret,a,bが全部違った時は作業領域いらないでしょ。
その恩恵はC++のoperatorじゃあずかれないでしょ。
>>197 さっきからでてる三項の関数使えばいいじゃん。
C++だからってoperatorにこだわることないんだよ。
実際に数値計算のライブラリも三項引数の関数用意してるよ。
>>198 いや、全部違うかどうかは関数内部でわからないでしょ？
まさかポインタが違うかどうかifでチェックするの？なわけないよね？
え？ ifでチェックすればいいじゃん。
速度云々とかいいながら条件分岐なんか使う気なのか。
通りすがりの横レスだけど
確かにC++使ってるとoperatorとかtemplate使いたくなるよね。
そんな事やってる間にチューンを忘れるとか疎かになりがち。
そう言いつつET使ってキャッシュも意識して頑張るんだけど。
>>199 restrictって言おうとしたけどCだな。それに保証も出来んか。
ifチェックすんのかよ！
>>197 結局、出力パラメータに対して
operator の戻り値コピーの部分（最適化してくれないとして）がネックになるって話なのね。
>>200 expression template はないって前提でしょ。
一応、それならパフォーマンスをある程度保ったまま
はるかに直感的に式書けるんだからまあ文句は出ないと思う。
もちろん式格納領域はいるけど今問題の一時オブジェクトのオーバーヘッドはなくなるわけだし
式テンプレート使ってメリットあるのははせいぜい乗算ぐらいまででしょ。
>>201 >>203 バカかおまえらは？
気になるならチェックしないバージョンつくって使いわければいいだろ。
operatorにこだわるならそういうことすらできないんだよ。
>>206 お前にバカっていわれたくないなぁ。
つか、お前のレスは人格攻撃、見下しばかりでつまらん。
そんなヤツとは議論しても実りがない。お前パスな。
どうぞ、勝利宣言でもなんでもしてくださいな。
>>204 式テンプレート一時期凝った時があるが
4x4のMatrix値返しした時のほうが早くなって愕然とした記憶がある。
あまりに凝ると最適化が効かなくなるんかいな？？もしくは単にミスってたかな。
>>205 そこはそれでかまわないと思うんだけど、、、
まあ俺が実際に使うのは乗算と加算ばっかりだから要望ないだけかも。
数値計算屋さん（なの？）としてはどういう風にしてほしいものなのかな
>>196 ちょっとまってチェックするっていっても関数の頭でポインタのチェックするだけだろ？
ループ内部で条件判断するわけじゃないの無視できるでしょ？
ふつう行列演算C++でかくなら演算できるかどうかの行、列数のチェックはするだろうし。
一般にoperator=でもソースとデスティネーションの同一性のチェックはふつーするでしょ？
#行き着く先のET使っても、保守性が向上するとは言いがたいと思うのだが。
#blitz 見やすいか？使いやすいか？
>>207 あ、ごめん。ちなみに俺は194=198=200=206で189とは違うから。
勝利宣言はしますけど。
まともな行列ライブラリなら行列の乗算は式テンプレート使うんだろうね。
LiDIAってライブラリには3引数の関数あったけど。
211 ：
デフォルトの名無しさん ：04/06/09 02:38
こうしてみると、人は説得力のあることを言えないときに
あ、185も僕でした。
>>211 つまんない揚げ足とられたから腹立っただけだよ。
213 ：
デフォルトの名無しさん ：04/06/09 03:01
いや、罵倒と質問ばっかで、肝心の自論については
雰囲気しか示していない
>>189 =
>>195 が主な対象。
最後に、
>>204 > operator の戻り値コピーの部分（最適化してくれないとして）がネックになるって話なのね。
最適化なんてしようがないと思う。
ホント、カッターで刺した小学生の気持ちがよくわかる。
>>210 3引数の関数とは例えば
A * B * C
を計算するような関数かな？
でもこれを計算する場合でもtmp領域は必要だよ。
数学上、2項演算しか定義されてないから(それで十分だから)
2項の計算結果をどっかに保存しないと次項の演算に移れない。
ただし、3項以上の演算を定義することでtmp領域の確保回数を
減ずることはできる。
実際、newmatなんかは行列計算の開始宣言、終了宣言して2項毎の
tmp確保を避けてたと思う(随分前に使ってたので記憶が定かでない)。
>>181 そんなとこです。
>>182 なるほど、()で括ってやれば良かったんですね。
どもでした。
220 ：
デフォルトの名無しさん ：04/06/09 11:46
結局 C だとどんな魔法を使って C++ より高速に算術演算を行えるのか、誰か分かった？
OOP機能を駆使すると遅くなるので、Cの機能しか使いません。
>>221 こんな感じ？
struct Matrix matrix_mul(struct Matrix a, struct Matrix b) { ... }
C++はinline使いまくれるからCより速い
>>223 inline にすれば100％早くなるってもんでもない。
無駄にプログラムサイズが大きくなると、キャッシュミスが多くなるし。
inline があれば、高速化のために手動で関数を展開しちゃうという
愚行に走らなくて済むのは確かだけど。
あと、C言語でもコンパイラによっては inline 展開するようになってるし。
227 ：
デフォルトの名無しさん ：04/06/09 15:14
do{
> キチンと表示
cout << "終了しますか？ Yes = y, No = n" << endl;
do {
ごめん わすれて
これでどうだ?
>>230 ああ、要するにコレ、バッファに「\n」が溜まってたって事なんですね…
なるほど、良く分かりました。
>226
きっとこうなってるんだよ。
すいません．蒸し返すようで悪いですが少しだけ．
>>169 ＞結局計算式そのものをどっかに格納しとかなきゃいけなかったりする。
そのような式オブジェクトは理想的な最適化の結果
コードから排除されるだろうというのがET支持者の一応の主張ではあるんですが・・・．
>>172 三項以上の演算，例えば行列におけるa + b + cなどにおいては
op=の形式では抽象化によるペナルティを喰らう可能性は残ると思います．
>>195 以下のようなコード（中途半端な擬似コードで申し訳ない）だと192さんの指摘するように，
一時オブジェクトは1行分だけで済むように思えるのですが違うのでしょうか？
Matrix &Matrix::operator*=(Matrix const &rhs)
{
assert(*thisの列数==rhsの行数 && rhsの行数==rhsの列数);
Row tmp;
for(size_t i = 0; i < *thisの行数; ++i){
tmp = *thisのi行;
for(size_t j = 0; j < *thisの列数; ++j){
*this(i, j) = 0;
for(size_t k = 0; k < *thisの列数; ++k){
*this(i, j) += tmp(k) * rhs(k, j);
}
}
}
return *this;
}
>>200 式テンプレートでは左辺と右辺の依存関係の問題は
代入メソッドの選択に一任される形になるかと思います．
通常の代入operator=では一時オブジェクトに結果を保存してから代入（swap）する形を取り，
ユーザが代入による依存関係の問題が発生しないことを保証できる場合のために
式オブジェクトから直接代入するための関数を別途用意する，とか．
>>205 通常，線形代数の数値計算では逆行列を陽に求めるのは最終手段（通常はご法度）なので
blitzやublasのスタンスは適切だと思います．
>>239 「俺は俺のやり方がなぜうまくいかなかったかが知りてーんだ。
そんな安易な解決策はとっくに思いついてんだよゴミクズどもが！」
ってちゃんと言わないと駄目だよ。
>>237 rhsが正方行列じゃなかったら困らない?
あと、rhsってなんの略?
>>241 なんで正方行列である必要があると思うの？
rhs = right hand side
>>242 列数が変っちゃうから。
なるほど。right(left) hand valueしか知らなかった。
返事がないな。
>>243 237のままだと正方行列である必要があります．
なので，237のコード中のassertで一応そのことを表明しているつもりです．
>>245 ほんとだ。よく見てなかった。でもそうじゃない場合は困るよね。
Matrixの乗算っていうのはたまたま出た例で、op=で一時オブジェクトが必要なときは
C式のスタイルよりパフォーマンスが悪くなるっていうのがもともとの議論。
大きな行列の場合にはデータ本体はシェアしておいて
>通常，線形代数の数値計算では逆行列を陽に求めるのは最終手段（通常はご法度）なので
249 ：
デフォルトの名無しさん ：04/06/09 23:07
逆行列の計算はもとのマトリックスを破壊してもいいなら、
つまりは行列に限らず、巨大なデータを何段階にも扱う計算はC++は苦手と考えてよろしいか？
>>250 C++ が苦手というか、operator overload で「数式っぽい見た目」でプログラミング
するのと相性悪いんだと思うよ。
これが 4x4 行列と 4 次ベクトル限定で、ベクトル演算用のレジスタ積んでる
プロセッサだと話が変わってくるけど。演算子オーバーロードを使う場合でも、
o 演算子に対応する関数をインライン展開
o 行列やベクトルの要素がコンパイラ最適化によってうまくレジスタに乗る
と、陽に関数呼び出しを行う C スタイルの書き方より早くなることもある。
>>250 C++でもCのような書き方をするなら別に苦手ではない。
それでも効率より見やすさや安全性を考えてクラス化してるんだと思う。
Adobeのソフトや、Windowsなんかは全部C++使ってるんでしょうか？
254 ：
デフォルトの名無しさん ：04/06/10 00:02
最近C++を始めたばかりです。
4X4ぐらいの小さい配列だとだとpure C に比べてETのオーバーヘッドが目立つだけだよ。
>>254 コメントを日本語で書くのはやめることだな
>>256 言わんとしているのは
「監視」を英語に直して＋パターン
ということかな
s/監視/監視側/
説明用のコメントだろ。アフォだね。
Observer Pattern?
>>259 じゃあ、おまえは「ひまわり」でも使ってろ（ﾌﾟ
さぁ盛り上がってまいりますか
>>246 237は行列同士の*=で1行分しか一時領域が要らないのではないか，
という疑問を単に投げただけのもので，議論の本筋からそれたものでした．すいません．
＞でもそうじゃない場合は困るよね。
はい困ります．ただ，困るのはCでもC++でも同じことだと思います．
＞op=で一時オブジェクトが必要なときはC式のスタイルよりパフォーマンスが悪くなる
というのは，上の議論において未だ論拠が指摘されていないように見えます．
自分としても，Cスタイルにおけるmultiply_assign(Matrix &a, Matrix const &b)という記述と
operator+=の記述との間にパフォーマンスの差を生じさせるものがあるとは思えないです．
>>248 いえ，私が指摘したいのは，
「ETを実装{しない/できない} -> 数値演算で逆行列を使うのはおかしい」
ではないです．
数値演算で逆行列を使うことは悪いとするスタンスは適切ではないか，ということだけです．
ただ，これは数値計算の一般論の指摘でこのスレで書くべきことではなかったです．すいません．
>>249 ＞式テンプレートを使わず逆行列のメソッドを提供すればいいのになんでblitz++はやらないのかね？
以下は私の中途半端な知識による考えです．適当に流してください．
通常，行列の逆行列が真に必要となる場面は非常に限られ，ほとんどの場合，
逆行列を陽に計算するよりも適切なアルゴリズムを選択する方が
計算量・精度双方の観点から圧倒的に有利になります．
例えば，行列の逆行列と{ベクトル/行列}との乗算では直接逆行列を計算することは論外で，
通常はLU分解法で行列を三角化してから計算します．
なので，あえて逆行列を陽に求めるメソッドを提供せず，逆行列を表す式オブジェクトとの演算を
適切なアルゴリズムにdispatchしているのではないかと愚考します．あくまで私見です．
265 ：
デフォルトの名無しさん ：04/06/10 00:49
みなさんはbad_alloc例外ってどう扱ってますか？
>>264 ＞例えば，行列の逆行列と{ベクトル/行列}との乗算では直接逆行列を計算することは論外で，
＞通常はLU分解法で行列を三角化してから計算します．
LU分解は大規模疎行列には使わない。逆行列を陽に求めないというのは同意。
>>266 LU分解は密行列にしか使いませんね．舌足らずでした．すいません．
>>265 > みなさんはbad_alloc例外ってどう扱ってますか？
即興プログラムなら放置してabort()逝き。
まともなプログラムなら適切にcatchを配備。
> delete [ ] buf; ← 例外の場合も開放しなきゃだめ？
まずは、コンパイル通してから出直せ。
>>264 >はい困ります．ただ，困るのはCでもC++でも同じことだと思います．
>というのは，上の議論において未だ論拠が指摘されていないように見えます．
>自分としても，Cスタイルにおけるmultiply_assign(Matrix &a, Matrix const &b)という記述と
>operator+=の記述との間にパフォーマンスの差を生じさせるものがあるとは思えないです．
過去ログちゃんと読めよ。昨日さんざん話したっていうのに。
A *= B の場合、一行分の作業領域もしくは行列1個分の作業領域とコンストラクタ、swapの呼び出しが必要。
C = A * B の場合、行列一個分の作業領域とコンストラクタ、コピーコンストラクタの呼び出しが必要(RVOが使えなければそれ以上)。
multiply(Matrix& C, const Matrix& A, const Matrix& B) を使った場合、
&C == &A の場合、A *= Bと一緒、
&C == &B の場合、一列分の作業領域もしくは行列1個分の作業領域とコンストラクタ、swapの呼び出しが必要。
&C != &A && &C != &B の場合、領域もコンストラクタもswapもいらない。
三番目のパターンはoperatorでは実現できない。受ける変数のために行列一個分の作業領域とコンストラクタが必要でも、
コピーコンストラクタ分は得する。あと変数を使い回せるという利点もある。
Matrix A = ...;
Matrix B = ...;
Matrix C = ...;
Matrix D = ...;
Matrix E;
//E = A * B * C * D;
multiply(E, A, B);
multiply(A, E, C);
multiply(E, A, D);
>>265 VCに限定していいなら__try～__finallyを使う。
ちょっとしたものを書くときにクラス化しなくていいのは便利なんだけどな。
標準にして欲しい。
>>264 議論を理解してないようだけど、
multiply_assign(Matrix &a, Matrix const &b)とoperator+=を比較してるんじゃないよ。
>>187 参照。
スマン。265の回答にはなってない。
>>271 自分の理解が浅く，議論を蒸し返しただけでした．申し訳ないです．
finally使うんじゃもうC#つかった方がいいんじゃないの？
>>264 >例えば，行列の逆行列と{ベクトル/行列}との乗算では直接逆行列を計算することは論外で，
論外かどうかは用途とか行列サイズによる。理論式上では多用する分野もある。現実問題にアプローチ
する前に理論検証したい場合だってある。
あるいは自分が作った疑似逆行列アルゴリズムと理論式どおりの逆行列アルゴリズム間で精度や速度がどれだけ違うか
比較したい場合もある。
うまくいかなかった場合、元の理論がわるいのか、誤差が利いてきてるのか切り分けたい場合だってある。
そんなもんはケースバイケース。論外とするのはサイズの大きいマトリックスで実行時間もかかるし、求めたところで
誤差が大きくなって使い物にならないって言う場合。
事実、数値計算電卓のMATLAB/Octaveでは用意はしてる。
除算は理論的にワンショット(最小システムクロック)で算出できないから用意しませんでした。というプロセッサより
用意したがそれなりに実行コストはかかります。というのがユーザとしてはありがたいと思う。
ただ、逆行列のET実際はほとんど不可能だ。
>>274 C#なんていうクソ遅い言語は問題外。ベンチマーク取ってもVC7.1の１／２以下
の速度しか出ない。
>>276 それをいうなら
見やすいC++のコードを書いたら同機能のCの1/4の速度になったことあるよ。
もっというと、Cだと遅すぎるのでasmでチューンしたら3倍速くなったことがあるよ。
全部Verilogで書き直して組み合わせロジックだけで実現できたので1クロックで
処理できるようになったことがあるよ。
必要に応じて開発手段を選択するのが設計。
>>257 Observer Patternを調べてみて、だいたいどのようなものかは
分かったのですが、実際に監視側と表示側のソースをちょっと
書いていただけないでしょうか？
初心者なもんでそういう設計自体の方法がよく分からなくって･･･
>>263 こちらもできればお願いします。
>>265 bad_allocはnew演算子内から投げられる
bufには値は代入されていない
解放する必要がある／ないの前に
どこを解放するつもり？
解放はできるけれど、解放した段階で未定義動作になります。
283 ：
デフォルトの名無しさん ：04/06/10 08:42
s/解放は/解放しようとすることは/
>>277 どうもよくわかんないんだけど、このレスで "C++" っていうとテンプレートや
オペレータの再定義等の C にない機能を使ったコードに限定されるの？
漏れはクラス一切無しのコードでも C++ で書くけど。
ネームスペースとか C99 風のいつでも出来る変数宣言とかありがたいし。
それで別に C より遅くなってる気もしないけど・・・
C 相当のコードで速度差がないのは自明なので議論の対象にならないだけ。
例えばg++, gccでC相当のコードのアセンブラが同一になるのは自明なの？
このケースで「当然同じような速度になるはず」と思えないようだった
289 ：
デフォルトの名無しさん ：04/06/10 14:03
全く同じプログラミング言語非依存の形式になるかどうか。
290 ：
デフォルトの名無しさん ：04/06/10 16:26
227で質問した者ですけど、
291 ：
デフォルトの名無しさん ：04/06/10 17:04
>>291 でも、象徴的に書ける「>>」が好きなんですよ。
「getline()」だと、Cと変わらないですし…
293 ：
デフォルトの名無しさん ：04/06/10 17:46
>>292 string使うから、それだけでも大きく違う。と、思う。
少なくとも、Ｃと変わらない、は偏見じゃないか？
>>293 Cと変わらないはちょっと言い過ぎでしたが…
それと、stringつかうというのはどういう事ですか？
本を持ってる人にしか分からない質問で申し訳ないのですが
296 ：
デフォルトの名無しさん ：04/06/10 19:18
>>294 char[]じゃなくstd::stringが使えるからって事でしょ。
改行残るのは、なんかflushとかしたらよかった気がする。
環境依存かもしれんしうろ覚えだから違うかもしれんけど。
297 ：
デフォルトの名無しさん ：04/06/10 19:39
120 名前：番組の途中ですが名無しです[] 投稿日：04/06/10 02:39 ID:DlgC++i0
>>116 「かわいい彼女」といっても三日で飽きるわけだが。
121 名前：番組の途中ですが名無しです[sage] 投稿日：04/06/10 02:40 ID:Qn1mrozU
>>120 3日で飽きても
なにもないより全然マシじゃないのこのC++野郎
あともう一つ。swapが例外を投げないことを強調していますが、
>>298 標準化委員会でそう決定したからです。理由は標準化委員会に問い合わせて下さい。
>>299 こちらに聞かれてもこまります。
禿げに聞いてください。
>>299 どういうことですか?
コンテナとかの swapも throw()宣言されてませんが。
>>295 ん～、科学的には説明できないけど、感覚として。
Cでも関数がエラーを返したのにポインタ経由で渡した引数を
ぐちゃぐちゃにされたらムカつくしな～。
sturct Nanka iremono;
iremono.sono1 = saisyokarahaitteitamono;
if(ERROR == NannkaChoudai(&iremono)) {
assert(iremono.sono1 == saisyokarahaitteitamono);
}
これでassert()に失敗したらムカつく。
それと同じようなものを感じる。
もしoperator=( )が例外を投げたのに中途半端にオブジェクトが
変わっていたらきっとムカつくな。
>>287 $gcc -dr hoge.c
$g++ -dr hoge.cc
とした時の出力はちょっと違うんだよねえ。
しかし最終的なアセンブラコードはほぼ同じ。どうしてでしょう。
わざわざCとC++で分けないでしょってのは概ね同意だけど、
>>304 例外に対処するためのコードが埋め込まれたりして？
スレの流れを折ってしまって申し訳ないですが、
不定値とだけ言われても困るけど
erase(vec.begin() + n) ってやれば？
つーかvectorならbegin() + NでN番目を指すiteratorが帰ってくるはずだが
>>304 >なんで誰も指摘しないのかな。
ヴァカなお前に付き合うの嫌だから。
>>306 とりあえず、その関数は
引数で Cont c ってやってるから、コンテナがコピーされ、コピーされた方の要素を指すイテレータが返るからダメになる。
Cont &cなら思ったとおりにいくんじゃね？まc.begin()+Nの方が断然いいが
ファンクタ書く時に、
>>312 privateインスタンスのほうがstaticよりマシ。
>>296 それは分かるんですが…
「cin.getline()」使用時に「std::string」をどの様に利用するのですか？
たぶん、そっちじゃなくてstd::getline()のことを言ってるんだと思うよ。
>>316 なるほど。「std::getline()」だったのですね。
良く分かりました。
>>301 throw() 宣言すると、コンパイラが例外処理のためのコードを追加するから、
パフォーマンスを考えれたら、throw() は入れない。
あと、operator= が例外安全でなければいけない理由は、
simpleDBTable.Current["NAME"] = "MONA";
のような簡易データベース中の項目を置き換えるコードがあったとして、
この中で例外が発生したとき、すでにある項目が消されたら困るでしょ?
>>318 >パフォーマンスを考えれたら、throw() は入れない。
なるほどパフォーマンスの問題ですか。
>この中で例外が発生したとき、すでにある項目が消されたら困るでしょ?
そんなことは分かっているのですが(基本的に全ての関数はアトミックにすべき)、
この文脈でその必要はないのではと。例外投げられたら deleteされるので。
>>319 > 例外投げられたら deleteされるので。
そうは言えない。
T x = initial_value;
try
{
x = new_value;
}
catch( ... )
{
}
// x はまだ生きている。
// ここで x の値は initial_value か new_value か、どちらかであると言えなければ、
// 以降、 x へアクセスしたときの動作が把握できない。
>>318 > 例外投げられたら delete される
誰が delete するのさ？
君はデータベースの更新に失敗したら即座にテーブルを破棄するのか？
何らかの例外が発生したときに、
1. その例外を呼び出し元に正しく通知する。（例外中立）
2. 例外が発生しても、オブジェクトの状態は変化しない。
もしくは例外を出さない。（例外安全）
というのが、例外安全の基本。これを
>>295 は理解しているのだろうか？
コンストラクタで例外が発生した場合、そもそもオブジェクトそのものが作成されないが、
代入処理の場合、例外が発生しても依然としてオブジェクトは存在している。
例外から回復して、オブジェクトを再度いじろうとしたときに内容が不定では話にならない。
>>320 >>321 >>322 おんなじこと何度も何度も書きやがって。んなこたー分かってる。
Exceptional C++ 33,34ページの話だYO!
catch してから deleteしてるだろ。
だからクラスTにアトミックな代入演算子は要求しないと思うんだよ。
あと swapについて。
確かに例外を投げないほうがいいときもある。
例えば73ページの第二の試み。最後に代入演算子使ってるけど、例外を投げない swapがあればそれで解決する。
でも Stackの例だとアトミックであれば例外は投げともよいと思うんだよ。
そこらへんどーよ。
>>295 まあ、おちついて。
"代入しようとしていたTオブジェクト"
とはコピー元をさしてっるて解釈はどお？
コピー元がconstでもmutable変数含んでりゃ
同にでも出来るし。
swapについてだけど、逆にswapが例外を投げる可能性がある場合、
swap(v1,src.v1);
swap(v2,src.v2);
swap(v3,src.v3);
見たいなメンバ関数を例外安全にするのは大変だYO!みたいな事が
言いたかったって解釈はどお？
>>323 > Exceptional C++ 33,34ページの話だYO!
そんなコード片の話をしてたのか、そりゃ気付かなかった。
例外発生したときの対応がdelete一択なら、たしかに、そんな要求はないよ。
でも、
>>295 で引用された２行が、より一般的なケースでの指針である可能性はないのかい？
本読んでないからわかんないだけかもしれないけど。
>>324 > "代入しようとしていたTオブジェクト"
> とはコピー元をさしてっるて解釈はどお？
明らかに問題外。
>>326 そお？例えばCOWな実装のstringの場合
代入時にコピー元にも影響ありそうだけど
>>324 よく分からんけど自己代入ってこと?
でもコピー先は newしたばっかの領域だし。
swap についてはその通りですね。
でも Stackの例は適切ではないと思います。
>>325 >でも、
>>295 で引用された２行が、より一般的なケースでの指針である可能性はないのかい？
そう読めなくもありません。訳の問題なのかも。
でも 58ページに
Stack を例外安全にするために、唯一例外安全にしなければならないTのメンバ関数
なんて書いてます。
>>323 そういうことかよ。まぁ、悪かった。
でも今は会社だから手元に本がないんだよなー。
ただ、すこし言わせてもらえば、
アノ本は 代入処理は以下の形式にしなさいというのがキモで、
途中のイロイロは、すべて以下のコードにもっていくための「布石」だと思う。
this_type & this_type::operator=( this_type const & rhs )
{
this_type( rhs ).swap( *this );
return *this;
}
だから、途中のコード云々で話をするのはまったくもって無意味だと思うのだが、どうか？
状態が「不定」なオブジェクトは delete 出来るの？
>>331 できないかもしれない。
けど、最低限それだけは保証してもらわないと、どうやっても回復できなくなってしまう。
例外に対する対応がプログラムの終了以外ほぼ選択肢がなくなってしまうだろう。
（ほかには、そのオブジェクトに２度と触らないようにするくらい？）
解体すらできなくなってしまうような仕様のクラスは作らないのが常識だろう。
>>332 > その swapは例外を投げない保証をする必要ありますか?
this_type::operator=()への要求として例外安全性が必要なければ、
必要ない。
this_type::operator=()への要求として"no-throw gurantee"が必要ならば、
swapへの要求として引数に対する"no-throw gurantee"が必要。
this_type::operator=()への要求として"strong gurantee"が必要ならば、
swapへの要求として引数に対する"strong gurantee"が必要。
this_type::operator=()への要求として"basic（以下略）
s/引数に対する//
>>334 まあつまり例外を投げない保証をする必要はないですよね。
この本 swapが例外を投げないことをやたら強調してますが、その理由が示されていないように思えます。
>>330 > その swapは例外を投げない保証をする必要ありますか?
ある。
>>330 のコードにおいて、swap が例外を発生させる場合を考えると、
>>322 の 2. を満たすためには、
operator= は以下のように直す必要があるが …
this_type & operator=( this_type const & rhs )
{
this_type temp( rhs );
... // this の状態を保存する。※1
try { temp.swap( *this ); }
catch( ... )
{
... // this の状態をもとにもどすコードを入れる ※2
throw;
}
return *this;
}
ここで、※ にどのようなコードを入れればいいかを考えるといい。
さらに、A.swap( B ) において、A のメンバの一部と、Bのメンバの1部だけが
入れ替わった状態で例外が発生すると、
>>322 の 2. を満たせなくなる。
面倒なことをイロイロ考えなくてもいいように、swap は例外を出しちゃ駄目ってことになってるの。
>>336 例外が発生したときには、内部状態が変更されていないことを保証するクラス（群）を
構築する際には、例外安全な swap を用意すると便利だよ、STLもそうしてるよ、
っていう話だと思うけど。boost も同じ方針ですよね。
>>313 何故なんでしょうか？
また、マシって事は他にお勧めがあるんですか？
>>337 だーかーらー swapはアトミック性だけ保証してればいいんじゃないですか? アフォ?
>>338 あなたの言う例外安全っていうのは例外を投げないって意味ですか?
例外を投げないことがアトミック性を実現する一番簡単な方法ってなら分かりますが、
Exceptional C++ は swapが例外を投げないってことを強調しておきながら
そのちゃんとした説明がなされていないと思うんですよ。
>>340 swap がけして例外を投げないわけではない。
ポインタのスワッピングだから例外を投げないのだよ。わかるか？
>>341 ？？？
組み込み型のスワッピングは例外を投げませんね。
再帰的に全てのスワッピングは例外を投げませんね。
swapは例外を投げないものだってのは分かります。
例外投げたらなんか無理してるってのも分かります。
でも Exceptional C++ 48ページに
> Swap() はどんな状況下であっても例外を投げない。
> Swap() のこの特徴こそが、Stack自身の例外安全に関する論証の要なのだ。
って書いてます。
Stack 内で StackImpl::Swap()は2回使われていますが、
これらが例外を投げたとしても Stackの例外安全性は損なわれないと思うんです。
そもそもＣ＋＋の例外処理ってプロの方々は積極的に使っているので
>>342 StackImpl::Swap のコードは、3つの std::swap から成り立っていて、
そのすべてが組込型に対するスワッピングである以上、StackImpl::Swap は
決して例外をスローしない。ここまではいいと思う。
そして、Swap が例外を投げない以上、これを積極的に使わない手はない。
で、それをふまえた上で、
>>342 は、次のどちらを言いたいのか？
1. Swap が無くても例外安全に出来るじゃないか。
2. Swap が決して例外を投げないというその理由がわからない。
どうも、あなたの言いたいことがピンとこない…
>>344 僕が言いたいのは、Exceptional C++ の48ページの主張の真意を教えてくれ(Stackの例、間違ってんじゃねーの？)ってことです。
Stack がアトミックなのは Swapが例外を投げないからじゃなくて Swapがアトミックだからだ。
Swapが例外を投げないのはただの結果であって、この場合必要ではない。
と、僕は思うんです。
あー同じこと何回書いただろう。
C++で、継承についてわからないことがあります。
必要な関数だけのクラスを作りましょう。
>>346 class A : public B, public C {};
なんじゃないのか？
>>346 struct afo { virtual SetOne() = 0; };
struct sine { virtual SetTwo() = 0; };
class black { /* ry */ };
class c { /* ry */ };
class A : public afo, public sine { black b; c dakko; /* ry */ };
class B : public afo { black b; /* ry */ };
class C : public sine { c dakko; /* ry */ };
>>345 Swapは絶対に例外を投げない を
Swapは絶対に失敗しない に読み替えれば納得いくんでない？
>>350 もったいぶらないではっきり言えよ。
なにが言いたいのか全くわからねえよ。
それぞれ関数の中で、同じ構造体に値を渡すのですが、この場合多重継承で考えると
346です。
355 ：
デフォルトの名無しさん ：04/06/11 22:07
JAVAのStringTokenizerと同じような機能を持つ関数って
>>351 それで理解できないなら、その程度の頭ってことだ。
>>357 考えてみても分からん。まじで分からん。
教えてくれ。たのむ。
ソースはかなり長くなってしまうので無理ぽいです。
よーやくわかったよ。だからこれで最後。
あ、360 = 342 ね。
362 ：
デフォルトの名無しさん ：04/06/11 22:32
>>360 あっはっはー
やーい逃げた逃げた
何が宗教だ ぼけ
例外を投げるくせにアトミックというのがよくわからん。
>>359 struct PointLight : D3DLIGHT9 {
ポイント用セッター
};
としておいて、生の変数には直接触らないと誓う。
もしくは、AbstructLightクラスのメンバにD3DLIGHT9を持たせて、外からは触らないようにするか。
どっちにしろ、あんまりこだわっても大して嬉しくはならないので、適当なところで妥協することを薦める。
そもそも例外安全な代入をやりたいのに、代入とは別の処理であるSwap()が失敗されちゃあ、たまらん。
>>360 >>361 >>362 え？ 騙られてんの？
>>360 なるほどねえ。そう考えればつじつまは合わなくもない。
例はあくまで例というけれど、そんな破綻した例を持ち出して 48ページのような強い物言いをするかな？
信念があるのはよいけれど全く例が伴ってないよ。
>>323 に書いたように swapが例外を投げちゃいけない例ってのがあって、しかもその信念にぴったりなのにね。
本の内容に納得いかないのなら、著者に文句を言うべきだ。
>>364 >>生の変数には直接触らないと誓う。
誓うというのは、基本的に自分ならば大丈夫ですが、それ以外となると不可能なので。
妥協して無駄に同じ処理を記述するようにします。
ありがとうございました。
>>365 そんなレベルの話をしてるんじゃねえよボケ、と言いたいところだけど
著者の真意は案外そんなとこかもしれない。
>>367 そうですね。これだけ粘っても誰も説明できなかったので、著者は電波ってことで納得します。
スレ汚しスマソ。
370 ：
デフォルトの名無しさん ：04/06/11 22:59
295の態度が徐々に変わってゆく姿が笑える。
>>369 >>363 の質問にも答えてやってくれ。
例外を出して、かつアトミックな処理の例とか出してくれると助かる。
>>371 そんなもん try,catch 使えばいくらでも書けると思うけど、好みじゃないので。
例えば
>>330 最初のコピーコンストラクタが失敗しても、状態は変化していない。
その後の swapは例外を投げない、もしくはアトミックなので例外が起きても大丈夫。
最後の returnは参照渡しだから例外を投げない。
より一般化すると
>>314 template <class Container, class BasicOp>
void MakeOperationStrong( Container& c, const BasicOp& op )
{
Container tmp(c); // Copy c
op(tmp); // Work on the copy
c.swap(tmp); // Cannot fail
}
op() がアトミックじゃなくても swap()がアトミックであれば、副作用が一つの処理なら
どんな処理でもアトミックにできると思う。
副作用が二つあったりすると、例外を投げない swap() が必要になると思う。
まあ swap()は例外を投げないべきだけどね。
文章いじったらおかしくなった。
あぁ、アトミックってそっちかYO!
>>295 は釣り師だったということで、終わりにしようぜ。
>>339 staticインスタンス
×寿命が（おそらく）不必要に長くて、さらにその寿命はほぼ制御不能。
×さらに関数内staticは関数外からのアクセスは不可能。
○毎回作り直さないので、生成、破棄のコストがかからない。
×マルチスレッドに対応不可能。
privateインスタンス
○寿命はファンクタの寿命を超えない範囲で自由に制御できる。
○メンバ関数を通してアクセスが可能。
×毎回作り直すので、生成、破棄のコストがかかる。
○マルチスレッドに対応可能。
お勧めは、ファンクタのコンストラクタでstd::vector<double>への参照を受け取り、
メンバにポインタを保持する方法。
アルゴリズムのファンクタ引数は値渡しで実装されている可能性が高いので、
コピーのコストを抑えた方がいいケースが多い。
>>355 boost::tokenizerでかなりの事はできない？
>>368 ポイントライトの位置設定とスポットライトの位置設定が同じ処理になることが偶然
と考えれば、別の関数としておくことに意義を見出せないか？
>>376 それを指針に考え直してみます。
詳しい説明有難うございました。
380 ：
デフォルトの名無しさん ：04/06/12 08:57
EUCからShift Jisに変換するにはどうしたらいいでしょうか？
nkf
382 ：
デフォルトの名無しさん ：04/06/12 10:45
>>376 特徴としてあげている箇条は大筋いいが
目的が示されていない以上そこまでだろ
どっちがお勧めという根拠がないぜ
383 ：
デフォルトの名無しさん ：04/06/12 10:55
>>380 EUC2SJISを使えば変換してくれるよ♪
384 ：
デフォルトの名無しさん ：04/06/12 10:57
visual cとturbo cとc言語とc++との
385 ：
デフォルトの名無しさん ：04/06/12 10:59
>>384 区別をつけられなくて困っていることがあるのか？
386 ：
デフォルトの名無しさん ：04/06/12 11:00
小文字厨らしいな
387 ：
デフォルトの名無しさん ：04/06/12 11:04
>>384 >(visual cとturbo c)と(c言語とc++)との
E-mailとインターネットはどっちがいいですか？
ってのと同じくらい的外れな質問だぞ
>>380 EUCコード&0x7f7fしてからwctombs()だっけ?
390 ：
デフォルトの名無しさん ：04/06/12 12:16
小文字厨なんてのもいるのか
いるようだ。
wcstombs()か。つーか寧ろmbcjistojms()で一文字ずつ変換した方が楽か。
>>390 それが何か?
まぁ実際には、自分でコーディングしちゃうんだけどね。
395 ：
デフォルトの名無しさん ：04/06/12 12:46
>>394 &0x7f7fしたら1バイト目の8ビット目まで0になってしまうと思うんだけど。
396 ：
デフォルトの名無しさん ：04/06/12 12:51
>>395 それがなにか? EUCの最上位ビットなんて(コードページを切り替えるための)飾りですよ。
飾りを取れば只のJISですから。
#但し、所謂1バイトかなの判定はそれ以前に行う必要があるけど。
>>397 私にはあなたの言いたいことが判らない。
380 ：デフォルトの名無しさん ：04/06/12 08:57
度々スマソ。
setlocale(LC_ALL, "jpn");
文字コードの変換じゃなくて、表現形式の変換。
C+++++++++++++++++++++++++++++++++++++++
EUC-KR からだったらどうするよ
CreditCard *card = new CreditCard("岸部四郎")
???
えっと、
>>406 class CreditCard{
CreditCard(const char *);
public:
static CreditCard *New(const char *name){
if(name in list){
return 0;
}
return new CreditCard(name);
}
};
CreditCard *card = CreditCard::New("岸部四郎")
if( ! card ){
printf("ブラックリストに載っています");
return 0;
}
card.buy(1000000);
delete card;
return 0;
意味が分からないというか、
>>409 ありがとうございます。
ただ、やはり特殊な書き方になってしまうので避けたいです…。
>>410 ・初期化失敗時にnullを返したい
・普通にnew CLASS(引数)を使いたい//こっち重視
です。
newをオーバーロードして new(引数) CLASS() でも、
>>409 さんのCLASS::New(引数)でも、
一つ目をクリアする代わりちょっと浮いちゃうので…。
一つ目を諦めると例外を使うことになりますが、あまり失敗の多いところで使うと良くない気がして…。
他に解決方法はあるでしょうか。(例外で問題なければそうします)
滅多に失敗しないのなら、なおさら例外を使うべきでは？
>>409 はファクトリちっくだしそんなに特殊な書き方だとは思わないけど。
>>411 >他に解決方法はあるでしょうか。
無い。
相談の範囲を多少逸脱するかもしれないけど。
チェックしたいのがブラックリストのみで、
それに必要なのがコンストラクタで与える名前だけなら、
ブラックリストをメンバ変数としてもち
内部で
>>409 のような処理を行うメンバ関数をもつ発行者クラスを
別に用意してチェックを分離したほうがスマートだと思う。
>>412 失敗はそれほど多くは無いと思います。が、後学のためにと思って。
>>413 そうですか…。勝手に CLASS.Create() はdelphiスタイルと思い込んでいました。
>>414 分かりました、ありがとうございます。他の方法をとります。
>>415 なるほど…。今回の場合ですが、例が不適切でした。
実は一段下でそれに似たことを行っており、(例？ Deal *deal = card.startDeal() )、
かつcardを多数作るわけではなかったので三重は大げさかなと思った次第です。
今回は例外で行きますが、今後三種類の方法を適宜使い分けることにします。ありがとうございました。
情報が小出しになった&長文失礼しました。
417 ：
デフォルトの名無しさん ：04/06/13 00:08
Cスレより誘導されてまいりました。同じことを質問しますがお許しください。
418 ：
デフォルトの名無しさん ：04/06/13 00:11
グローバルなクラスオブジェクト
enum Type
あ～、間違えてら。
いろいろ調べてみましたがどうやらVCはC99に対応していないようなので
>418の方法は無理みたいですね。
それにC99を使うとなるとC++は使えなくなるようなのでこれも問題です。
とりあえず今回は勉強になったのでこれで良しとします。
有難うございました。
>>420 ここまでやるぐらいなら最初にmainで定義したほうが良さげです。
これはこれで面白いのですが。
423 ：
デフォルトの名無しさん ：04/06/13 08:40
Javaで言うとことのプロパティファイルを読みこむ自社製ライブラリがあります。
>>423 どうすれば「よい」とみなすのか示せボケ
CBaseを基底クラスとしたCAとCBと言うクラスが有ります。
>>426 typedef CBase* NewFunction();
template< typename T > CBase* New(){ return new T; }
NewFunction* const table[] = { &New<CA>, &New<CB> };
pBase = table[i]();
428 ：
デフォルトの名無しさん ：04/06/13 16:35
>>427 うーん、色々やって見ましたが上手く行かないです。
これをどこら辺に定義すれば良いのでしょうか。
とりあえず、こんな感じじゃ無理でした。
#include <windows.h>
typedef CBase* NewFunction();
template< typename T > CBase* New(){ return new T; }
CBase* const table[] = { &New<CA>, &New<CB> }; // エラー
CTest::CTest()
{
int i = 1;
CBase* pBase = table[i]();
}
エラーメッセージ
error C2440: 'initializing' : '' から 'class CBase *const ' に変換することはできません。(新しい動作 ; ﾍﾙﾌﾟを参照)
ｺﾝﾃｷｽﾄはｵｰﾊﾞｰﾛｰﾄﾞされた関数の非不明瞭を考慮しません。
っと、上のままの場合だと以下でした。
>>429 class CBase{};
class CA : public CBase{};
class CB : public CBase{};
typedef CBase* (*NewFunction)();
template< typename T > struct NewT{ static CBase* New(){ return new T; } };
NewFunction table[]={&NewT<CA>::New,&NewT<CB>::New};
int main(){
CBase *p=table[0]();
>>431 上手く出来ました。有難うございました。
constは捨てろってことだな
VS2002にVCToolKit2003をいれてstlport4.6.2でboostコンパイルできた人いる?
変な組み合わせすんなよ
ｱｶﾃﾞﾐｯｸだったり(泣
439 ：
デフォルトの名無しさん ：04/06/14 02:23
コンストラクタにテンプレート引数を渡したいのですが引数を使って
何で、
ちょっとした型推論ですよ。ありがたく省略しないと。
442 ：
デフォルトの名無しさん ：04/06/14 05:57
>>439 もしかしてVCか？
明示的なテンプレート実引数の
正当な形を撥ねるケースよくあるぞ
コンストラクタで、そういったことがしたいなら、以下のような手を使うとかね。
444 ：
デフォルトの名無しさん ：04/06/14 14:16
>>377 そんなものがあったんですね。ありがとうございました。
で、さっそく使ってみたのですが、
tokenizer.hppをincludeしてビルドしたところ、以下のようなビルドエラーが出ました。
boost\tokenizer.hpp(60) : error C2039: 'begin' : 'CString' のﾒﾝﾊﾞではありません。
c:\program files\microsoft visual studio\vc98\mfc\include\afx.h(368) :
'CString' の宣言を確認してください。
C:\VC_PROJECT\0806\01\Main1.0β_0806\SetUserEntryDlg.cpp(310) :
ｺﾝﾊﾟｲﾙされたｸﾗｽのﾃﾝﾌﾟﾚｰﾄのｲﾝｽﾀﾝｽ化 '__thiscall boost::tokenizer<class boost::char_delimiters_separator<char,struct std::char_traits<char> >,char const *,class std::basic_string<
char,struct std::char_traits<char>,class std::allocator<char> > >
::boost::tokenizer<class boost::char_delimiters_separator<char,struct std::char_traits<char> >,char const *,class std::basic_string<char,struct std::char_traits<char>
,class std::alloca
tor<char> > >(const class CString &)' の参照を確認してください
問題の個所は
template <typename Container>
tokenizer(const Container& c)
: first_(c.begin()), last_(c.end()), f_() { }
となっています。これってboostのバグなのでしょうか。それともこちらの設定か何かが悪いのでしょうか。
長くてすみません。
>>444 CString じゃなくて std::string を使うべき。
すみません。
boost::functionにtemplate関数を代入したいのですが、
>>448 boost::function<void (const int)> f; // constはなくても変わらない。
f = static_cast<void (&)(const int)>(testFunc); // void (*)(const int)でも良い。
キャストすれば良かったのか…
本番が出来ませんでした…orz
関数の戻り値の型（？）がoperatorとなっているものを
>>449 ふつうは、キャストを嫌ってこっちだとおもうが。
boost::function< void (int) > f = testFunc< int >;
455 ：
デフォルトの名無しさん ：04/06/15 00:18
newで作った配列の初期化はどのようにすればいいのでしょうか？
>>456 ｶﾞ━━━━━━∑(ﾟдﾟlll)━━━━━━ﾝ
>>455 #include <vector>
static int const initial[3] = {1,2,3};
std::vector<int> v(&initial[0],&initial[3]);
459 ：
デフォルトの名無しさん ：04/06/15 03:16
class A
>>459 C++のポリモはポインタが指してる先のオブジェクトへの操作
( *ptrか ptr ->mem_function() )についてだけで
ポインタそのものの操作(この場合、++ptr)に対しては
ポリモではないから。
つまり++ptrが間違い。
>>459 ポリモーフィックなクラスを配列にしてはいけない。
参考：More Effective C++ の
「項目３: 配列をポリモルフィズム的には扱わない」
462 ：
デフォルトの名無しさん ：04/06/15 03:48
>>460 そういうものなのですね。ありがとうございました。
>「項目３: 配列をポリモルフィズム的には扱わない」
そうでもないよ。
やっぱり
ポリモーフィックなクラスへのポインタ配列を使えばいい。
467 ：
デフォルトの名無しさん ：04/06/15 07:32
>>452 struct mona { operator giko (); };
なら、mona型からgiko型へのキャスト
mona c;
(giko)c;
ポリモーフィックはJavaでは良く使うんだがC++ではちょっと難しいね
469 ：
デフォルトの名無しさん ：04/06/15 09:44
boost::tokenizerについて2つ質問です！
単なるポインタの理解の問題に見えるけど？
>>468 Java や C# のようにいちいち new するやり方なら、C++ も似た様な動きをすると思うけど。
>>470 関係ないですね。
C++ 的にはこの場合ポインタじゃなくて iterator をつかうべし、ということになるんでしょうね。
アドホックに済ませるならポインタ進めるための Next とかいうメンバ関数を用意するとか。
C++のごちゃごちゃな仕様を組み合わせた結果
すみません。質問ですー
475 ：
デフォルトの名無しさん ：04/06/15 15:39
C++のときはnewは滅多に使わないな。
>>474 つーか、そのコードじゃコンパイル通らんぞ普通。
フリーのコンパイラを入れて、とりあえず何か作って練習しようと思ってるんですが
>>478 Win32APIに触って窓出したりする必要ないならCygwinのgccが無難なんじゃないの。
フリーのbccは進歩止まってるし。
>>479 フリーのBuilderXに新しいBCCついてるよ
>>474 x < it->end() って意味あんの？
x != it->end()じゃね？
すみません。解決しました。
>>483 さんの助言で見直したところ
表示ルーチンはまったく関係なかったようです。
mapを作るときにどうやらスコープを考えてなくつくったようで
内容がすべておかしくなってました。
お騒がせしました。
487 ：
デフォルトの名無しさん ：04/06/15 19:37
>>478 フリーって時点で「初心者向き」は消えたも同然
ベテランにとって必要な機能に限定した軽快な味が売りだからね
手取り足取りのサポートが欲しければ金がかかるのは世の常だよ
>>478 gcc しかないと思う。
風変わりな拡張を多用しないし、処理系固有のクラスライブラリとか覚えなくて済むし。
あと、コンパイラに「使いやすい・使いにくい」っていう差は特にないと思う。
あまり古いものだと規格準拠度が落ちて問題あるかも知れないけど。
>>488 ＞処理系固有のクラスライブラリとか覚えなくて済むし。
は？ 別に付属してるもの全部覚える必要なんぞ無いだろ？
オーバーライド可能な演算子にカンマがあるのですが
>>492 とはいえ、無理に使わないほうがイロイロな意味で幸せな気もする。
495 ：
デフォルトの名無しさん ：04/06/15 23:11
ま、そんくらいでトリッキーとか言い出す人の発言としては嘘じゃあんめえな
>>495 一見してデフォルトとまったく違う動きをするようなコードは、避けたほうが
良いと思うけどな。演算子オーバーロードにせよプリプロセッサのマクロに
せよ。
ネタとしては面白いけど。
>>467 レスありがとうございます。なんとなくそんな気がするのですが、
(giko)c
というより
giko(c)
ではないのでしょうか・・・それともどっちでもいいんですかね。
498 ：
デフォルトの名無しさん ：04/06/15 23:17
>>497 いてっ
おめーに突っ込まれるとな・・・
俺もヤキ回ったな
499 ：
デフォルトの名無しさん ：04/06/15 23:20
>>499 昔ハマったのは operator&& のオーバーロード。C/C++ だと組み込み演算子の && は
短絡評価できることが保証されているから
return foo() && bar();
だと foo() が真なら bar() は評価されない。しかし operator&& オーバーロードして
あると bar() も評価されちゃうので、意味合いがまったく違ってしまう。
字面が同じで一見してバグを発見できずに数人が半日無駄にした覚えあり。この
オーバーロードをしたヤツが、その後どうなったかはとても言えない。
501 ：
デフォルトの名無しさん ：04/06/15 23:31
>>500 >return foo() && bar();
こんなんでハマんなや
C++じゃねぇが、Pikeの組み込みstring型の算術演算子オーバーロードは流石にやりすぎだろと思ったな。
503 ：
デフォルトの名無しさん ：04/06/15 23:34
極論するとoperatorはまったくいらない（代入でさえも）
504 ：
デフォルトの名無しさん ：04/06/15 23:52
>foo() が真なら bar() は評価されない
>>484 コンテナのiteratorがRandomAccessIteratorなら、あり。
それ以外のイテレータなら、なし。
最近、「実装とインタフェースの分離」を耳にする事が多いのですが、
>>506 ごく簡単な例だと、例えば簡単な html パーサを書いていて、タグの情報をクラス化するとしたとき、
インタフェイス IHtmlTag を
class IHtmlTag {
public:
virtual const string& get_Name() const = 0;
virtual const HtmlAttr& get_Attributes() const = 0;
};
と定義し、実装は
class CHtmlImpl : public IHtmlTag
{
string m_strTag;
HtmlAttr m_attributes;
virtual const string& get_Name() const { return m_strTag;};
virtual const HtmlAttr& get_Attributes() const { return m_attributes;};
};
なんてしておく。
多重継承やcontainment で複数のインタフェイスを持つクラスなんかも作れる。
利点はイロイロあるけど、産業的にはクローズドソースでクラスライブラリを公開できる点が重要。
>>507 ほほ～。多重継承の場合は、LokiのGenLinearHierarchy等で複数のインタフェースを突っ込んだら
いい訳ですな。containmentは初めて聞くのでちょっと分かりません。後、
クローズドソースでクラスライブラリを公開できるって言うのと、.cppは公開せずに.hppのみの
公開の違いが分かりません。良かったらフォローお願いします。
>>508 C++ はたとえ private なものでもメンバ変数ひとつ増えるとオブジェクトサイズが
変わってしまう。インターフェースと実装を分離しない場合、内部的な改修で
あってもバイナリ互換性が崩れる可能性があるのでマズい。
以前は Microsoft の DLL でも、この手の変更が合ってとつぜん動かなくなる、
なんつー問題がしばしば発生してた。
510 ：
デフォルトの名無しさん ：04/06/16 22:48
>>506 Ｃで言うところのソースとヘッダの分離におけるヘッダにあたる。
ヘッダだけ公開しといて、ソースはそれに合うように作れと。
標準化委員会なんかが好むやり方を想像すればいい。
インタフェイスだけのクラスでも、そのサイズは最低１だったと思ったのですが、
512 ：
デフォルトの名無しさん ：04/06/16 23:02
>>511 １バイト？
確かに実装は未規定だが
さすがにそれは難しそうだな
>>510 実装とインタフェースを分離した場合でも、実装とインタフェースのヘッダファイルは
両方とも公開しますよね？分離した場合何か特に利点となる場合があるのですか？
514 ：
デフォルトの名無しさん ：04/06/16 23:06
>>513 実装については一切公開しないのがインターフェイスというやり方。
現実には実装も公開しちゃってるケースよくあるけど、それは妥協の産物。
>>511 1 バイトなのはポリシークラスでしょ。仮想関数あったら、最低ポインタ 1 個分は
必要。
継承した場合は単一敬称なら相変わらずポインタ 1 個分。多重継承すると
ポインタ n 個分になる実装が一般的。あと仮想継承は話が別。
>>514 それでは自分で独自のインタフェースを書く場合困らないのですか？
>>513 実装側のヘッダは公開する必要ないけど。コンストラクタを陽に呼び出すのではなく、
インターフェースに従ったオブジェクトを作成する関数や、あるいはファクトリクラス
を公開する。
// 公開ヘッダ
struct IFoo {}; // 純粋仮想関数いろいろ
IFoo* CreateIFoo(); //
// 非公開ヘッダ
class CFoo : public IFoo {};
// 非公開実装
IFoo* CreateIFoo() { return new CFoo; }
Microsoft の COM まわりのドキュメントが参考になると思うぞ。
518 ：
デフォルトの名無しさん ：04/06/16 23:12
>>516 もしかして
#define インターフェース 実装
状態か？
あー、すいません、勝手に、
520 ：
デフォルトの名無しさん ：04/06/16 23:26
>>519 Impl* pObj; ってやろーとしたろ？
Interface* pObj = new Impl; もダメ
さあどうする？
522 ：
デフォルトの名無しさん ：04/06/17 00:14
string型をchar型へのポインタに変換するにはどうしたらいいのでしょうか。
c_str
524 ：
デフォルトの名無しさん ：04/06/17 05:28
標準コンテナってデストラクタが仮想関数じゃないから
>>525 機能拡張したい場合は、
できないよりできた方がイイと思うんだが...
完成されたものであれば、その必要はないだろうねぇ。
そもそもコンテナをポリモフィックにdeleteする場面ってあるんだろうか?
>>526 10中ハック、526がタコ。
といったところ本人がそれに気づくはずもなし。
まぁ、気がむいたら問題を書いてみな。
このスレの前の方にいた、継承するときには必ずデストラクタをvirtualにしなければならないと思い込んでるヤシだったりして。
つーか、STLコンテナにPolicyがあればいいだけなんだがな。
>>527 のような場合に
virtualじゃなかったら欠陥になりうるじゃん。
気を付けろといえばそれまでだけどw。
(だから、自分が管理してないコードに使うときはこわくて使えない。)
一般にポリモフィックな動作であれば問題ないコードで問題に
なるわけで、たぶんこれは継承じゃないんだなと邪推。
struct NV{~NV(){}};
struct EX :public NV{~EX(){}};
boost::scoped_ptr<NV> p(new EX);
とか？
・virtualメソッドを持つクラスを定義する場合、デストラクタもvirtualにする。
>>532 それはそうかもしれないが、重要なのはなぜそうなのか？ということだ。
>>526 にも理解できるよう説明すること。(20点)
>531
>>535 #include<iostream>
#include<boost/scoped_ptr.hpp>
struct NV{~NV()//virtual をあえてつけてない
{std::cout << "~NV" << std::endl;}
};
struct EX :public NV{
~EX()//virtualにすると呼ばれないだけでなく、下記の呼び出しでアボーンしちゃう
{std::cout << "~EX" << std::endl;}
};
int main()
{
{boost::scoped_ptr<NV> p(new EX);}//~NV
}
>>530 その通りですね。(以下はイメージ的なもの)
#include<iostream>
#include<boost/scoped_ptr.hpp>
struct Virtual{virtual ~Virtual(){} };
struct Non_Virtual{};
template<typename T,typename P_V=Non_Virtual> struct SEL{
SEL(){}
~SEL(){ std::cout << "~SEL<T,Non_Virtual>" << std::endl; }
};
template<typename T> struct SEL<T,Virtual>{
SEL(){}
virtual ~SEL(){ std::cout << "~SEL<T,Virtual>" << std::endl; }
};
template <typename T,typename P_V=Virtual> struct SEL_EX :public SEL<T,P_V>{
SEL_EX(){}
~SEL_EX(){ std::cout << "~SEL_EX" << std::endl;}
};
int main(){
{boost::scoped_ptr< SEL<int,Non_Virtual> > p(new SEL_EX<int,Non_Virtual>);}std::cout << std::endl;
{boost::scoped_ptr< SEL<int,Virtual> > p(new SEL_EX<int,Virtual>);}
}
>>535-536 メモリリークしないのは shared_ptr
ためしに、
>>536 の main を以下のように書き換えて見れ。
int main()
{
boost::shared_ptr< void > p( new EX );
return 0;
}
標準ライブラリとかAPI的なものは普通は継承しないんだから
>>538 ほんとだ。
{boost::shared_ptr<NV> p(new EX);}//~EX~NV
shared_ptrのコンストラクタってメンバtemplateになってるから
指定した型(NV)から推測されるポインタに代入しないで、
実際にコンストラクタに引き渡された型で
削除用の関数オブジェクトも生成しちゃって処理してるのか...。(頭イイ)
だからvirtual付けてない場合は、
{boost::shared_ptr<NV> p(dynamic_cast<NV*>(new EX));}//~NV
としちゃうと意図的にメモリリークを起こせると...
>>539 C++ で継承禁止クラスを作ることは可能だよ。
どやって？
>>543 ええと、これ仮想継承で実現するのか。
デストラクタをvirtualにするよりメモリ食うのではなかろうか。
デストラクタvirtualよりパフォーマンスが良いなら考えるけどな。
>>543 以下のコードでどれだけメモリを食うか調べた。
（VC++2003）
struct A : public nonderivable< A > { int a; };
struct B { virtual ~B(){} int b; };
struct C : public B, public nonderivable< C > {};
int main()
{
cout << sizeof(A) << endl;
cout << sizeof(B) << endl;
cout << sizeof(C) << endl;
}
結果は A, B は 8 、C は 12 と出た。
パフォーマンスにはあまり影響はなさそうだけど…、ようわからん。
で、けっきょくいえることは、Policy として使うだけのクラスは、protected なデストラクタにするか、
>>524 STLコンテナの継承にはprivate継承がお薦めですよ．
使うメンバー関数だけusingするといいです．
#include <deque>
using namespace std;
class A: private deque <int>
{
typedef deque <int> Base_;
public:
A (): Base_ () {}
A (const A &p): Base_ (p) {}
A &operator = (const A &p) {if (&p != this) {Base_::operator = (p);} return *this;}
virtual ~A () {}
using Base_::push_back;
};
int main () {
A a0;
a0.push_back (0);
return 0;
}
>>547 usingでそんなことできたんだ。
知らなかった。
>>547 で基底クラスのデストラクタは呼ばれる事が保証されるの？
>>549 よくわからんが、
private継承だから、基底クラスのポインタにすることはできない
>>549 基底クラスのポインタでインスタンスを保持できないんだから
デストラクタは必ず呼ばれると思う。
> virtual ~A () {}
>>550 ,551
そういう意図です．
>>552 混乱させたようですが，
デストラクタのvirtualはなくてもOKです．
これがなくても，先祖クラスのデストラクタを呼び忘れるなんてシチュエーションは起き得ないです．
Aをpublic継承する可能性があるなら付けておきましょう．
sed 's/先祖クラス/派生クラス/'
>>543 >ここまでするメリットを感じない。デメリットのほうが大きそうだしね。
「デメリット＝無駄にメモリ喰う」って類のことを言ってんなら
デバッグ版の時だけギミックを仕掛けといて
リリース版の時にはギミックを外すようにしとけばいいんじゃない？
STLコンテナにvirtualなデストラクタがないことが心配っていう人は、
557 ：
デフォルトの名無しさん ：04/06/18 06:56
EffectiveC++に確かこんな記述があったはず。
>>536 微妙にうそついてすまんかった。
>>538 scoped_ptrだとリークするんだねぇ。
scoped_ptrリークする可能性のあるコード書いたこと無かったから知らなかったよ。
560 ：
デフォルトの名無しさん ：04/06/18 20:07
>>557 基底クラスオブジェクトへのポインタって考え方に固執することないじゃん
テンプレートあるんだし
>>557 そもそも仮想関数が1つも無いクラスのオブジェクトを
ポリモフィックに使わない。というか使えない。
そんなクラスに仮想デストラクタが必要なんだろうか？
他のメンバ関数は仮想で無いのに。
と、ひさびさに小一時間問い詰めたい。
562 ：
デフォルトの名無しさん ：04/06/18 21:37
あの非常に初歩的なことかも知れません、いいですか？
>>563 #include <iostream.h>
はものすごく古い
デストラクタでぐちゃぐちゃうざい。
古いのは分かるんですが、何かが劣ってるとか
568 ：
デフォルトの名無しさん ：04/06/19 00:49
C#じゃなくても __gc あるもん～。
>>567 劣っているというか、
string.h が困るよね。
古くて規格外というのは、大きな欠点だと思うが。
>>572 ＞あんまり良く分かりません
「まったく分かりません」だろ？
名前空間について調べてみ
>>573 古いかもしれないけど規格外ではないだろ？
>>575 1998年の時点でdeprecatedなんだから、そろそろアウトにしたいなぁ。
まつまり基本的に古いものは排せってことですね。
578 ：
デフォルトの名無しさん ：04/06/19 01:18
古いiostreamの実装ってよく知らないんだよなー。
580 ：
デフォルトの名無しさん ：04/06/19 01:21
これはiostreamそのものとは関係無いか。
つまり、賞味期限きれたものと、きれてないものどっちがいいかというと
iostream.hって規格内なの？
いまだかつてiostream.hがC++の規格に存在したことはない
586 ：
デフォルトの名無しさん ：04/06/19 09:07
ライブラリの作りの良し悪しは、規格化されているか否かとは無関係
規格化されていても問題ある定義体はいくらでもある（例： gets）
>>573 にﾌﾟと言ったのはﾏｼﾞﾚｽだよ
ﾌﾟ
>>586 実際にそうした定義が山ほどあるとしたところで、
数があるから問題じゃないというわけじゃなし…
えーと、悪い奴はだれだ！
誰が悪いのかは知らんが「規格外」ってことは
590 ：
デフォルトの名無しさん ：04/06/19 15:42
わたくしJava厨なのですが、最近 C++ の勉強をはじめました。
>>561 抜け道(非仮想デストラクタを持つ基底ポインタで派生クラスを削除)塞いどくのは，
別に悪いことではないのではないでしょうか．
そのままでは警告なりエラーなりはでないんですし．
ただ561は，確かにそうかもしれないと思った．
立て札たてとかなくても抜け道通る奴はあんまりいないかな．
>>590 知らんけど、EclipseライクがいいんならEclipse自身のC++サポートは駄目なの?
593 ：
デフォルトの名無しさん ：04/06/19 16:50
>>589 得られる保証も得られない保証もない
ISO/IEC14882が規定しないライブラリは
ISO/IEC14882ではユーザ定義であって
正しいか正しくないかを論じることができない
おまえさんの口ぶりから察するに
言いたそうなことは痛そうだが・・・w
Realメディアファイルを再生するプログラムを書きたいのですが、
>>591 派生クラスを作るだろう人の実力によるよな。
初心者に毛が生えたような人だとすると
「どーあっても安全にしたい。効率なんか二の次だ」って
考えてvirtualつけることもあるだろう。
10659氏が言ってくれているように仕掛けを付けとくのも強力。
継承可能かどうかドキュメントに記しておくことも手助けにはなる。
デストラクタprotectedもある。ケースバイケースだな。
>>561 そういわれてみればそうですね。
仮想関数をなくしてデストラクタを非仮想関数にしてしまう
クラス設計もそれはそれでいいのですが、
本来継承するべきでないのか、
あるいはそれを断念せざるを得ない状況を生み出すという見方もないでしょうか？
(使用者側からはPolicyで選択できるのがいいです。)
まぁC++の場合、C#のsealedやJAVAのfinalのように継承を禁止されない分、
自由度が高いという見方もあるのかもしれません。
宗教論争みたいになってきたんでこれくらいでやめにしておきます。w
つきあってくださった方、ありがとうございました。
>>596 > 派生クラスを作るだろう人の実力によるよな。
同意．
私は(未来の自分も含め)派生クラスを作る人(以後，利用者)を信用しないほうですから，
安全性を優先してます．
作成者が利用者をコントロールする手段を提供するのは重要なことだと思います．
(そういう意味では543，555は私的にはヒットでした．)
次の言語規格改定では，この辺をもう少し頑張って欲しいですね．
599 ：
デフォルトの名無しさん ：04/06/19 20:53
int* abc
600 ：
デフォルトの名無しさん ：04/06/19 21:02
>>599 見た目だけ。
みにくいし
int* a, b;
とかしてはまるからそういう記述はやめとけ。
* = asterisk
* = 菊門
602 ：
デフォルトの名無しさん ：04/06/19 21:06
規格上違いが無いのですが、実際に出力されるオブジェクトに違いが出ることがあります。
603 ：
デフォルトの名無しさん ：04/06/19 21:07
base* でdeleteする時点でデストラクタがvirtualかどうかくらい点検しろよ
605 ：
デフォルトの名無しさん ：04/06/19 21:12
>>604 いろいろ試してみてください。
結構予想と違う振る舞いが多いですよ。
>>603 利用者の点検を言語レベルで強制できればいいんですけどね．
607 ：
デフォルトの名無しさん ：04/06/19 21:30
ださげんご
はげんご
>>603 「base* でdeleteする」のが利用者でない場合ってのはありえないでしょうか?
極端な例を出すと，
// designer.h
struct Must_Not_Derive {void memfun0 () {} ~Must_Not_Derive () {}};
void func (Must_Not_Derive *p);
// designer.cpp
void func (Must_Not_Derive *p) {delete p; p = new Must_Not_Derive;}
// user.cpp
struct Derived: public Must_Not_Derive {~Derived () {}};
int main () {
Derived *p (new Derived);
func (p);
return 0;
}
で，利用者がdesigner.cppを閲覧できない場合．
設計者は利用者がよもやMust_Not_Deriveを継承するとは考えてない．
一方，利用者はMust_Not_Derive::memfun0を使いたいのだか，
コンポジットあるいはpriavete継承が面倒臭いので，
funcでdeleteされることとは知らずにpublic継承してしまった．
例が極端だけどこういうはまり方はないでしょうか?
612 ：
デフォルトの名無しさん ：04/06/19 23:04
>>600 int* a, b;
とかしてはまるからそういう記述はやめとけ。
この場合は、ａもｂも、ポインターになるのですか？それとも、bは整数？。
614 ：
デフォルトの名無しさん ：04/06/19 23:08
>>610 引数が非constのfuncが何をする関数かを知らずに使うわけか
答えられないなら黙ってていいよ。
617 ：
デフォルトの名無しさん ：04/06/19 23:13
>>612 自助努力をしろ
初心者であろうがベテランであろうが関係ない
これは人間性の問題
スレ荒らして楽しいかい？
619 ：
デフォルトの名無しさん ：04/06/19 23:18
int* a, b;
>>620 その前に、
int* a,b;
と
int *a;
int *b;
は意味が違う
622 ：
デフォルトの名無しさん ：04/06/20 00:11
>>620 a と b が
・同型でなければならないとき
・たまたま同型なだけのとき
で書き方わけてるよ
漏れは int* a; 派だな
int * w ;
int * (a,b);
626 ：
デフォルトの名無しさん ：04/06/20 00:27
>>623 そんなのは伺いをたてること
こっちから押し売りすることじゃない
LPINT
628 ：
デフォルトの名無しさん ：04/06/20 00:31
>>626 文盲か？
とりあえず馬鹿は引っ込んでてくださいな。
int *a,*b;
631 ：
デフォルトの名無しさん ：04/06/20 00:35
>>629 コーディング基準は俺ルールじゃないってことだよ
こうやって不毛なコーディングスタイル論争が始まるんだな
633 ：
デフォルトの名無しさん ：04/06/20 00:38
>>632 ム板ではなくマ板でやれば
少しは実りがあるはずだ
635 ：
デフォルトの名無しさん ：04/06/20 00:42
>>634 そういう意図はない
スタイルはプログラム技術じゃない
ＰＧの社会に関することだ
>>621 そうです。
つまり、勘違いや間違いを起こさないように、と言う意味です。
int* p1,*p2;
はぁ、またこれか。
640 ：
デフォルトの名無しさん ：04/06/20 05:26
double ** m_tblに領域をnewしたいのですがどうすればよいですか？
641 ：
デフォルトの名無しさん ：04/06/20 05:33
>>640 *m_tblの型はdouble *だろ。
642 ：
デフォルトの名無しさん ：04/06/20 05:39
そうでした
あともう一つ。
たびたびありがとうございます。
>>598 でも、543の仕掛けでエラーになったとして、
派生クラス作る人がヘボだと、ただ悩むだけになってしまったり。
ドキュメントちゃんと書けよってことか。
やっぱりこういうの綺麗にコンパイルエラーにする仕組みは欲しいよな。
これスレのFAQに入れておこう。
647 ：
デフォルトの名無しさん ：04/06/20 09:29
>>645 最後の一行を除き激しく同意
小技に凝る前に大きな忘れ物だ
648 ：
デフォルトの名無しさん ：04/06/20 09:30
>>647 > 小技に凝る前に大きな忘れ物だ
具体的にはどういう意味？
ドキュメントを書くってことだろ。
651 ：
デフォルトの名無しさん ：04/06/20 13:42
ソースツリーはどうやって決めてますか？
C++ スタイルのキャストを使えと良く聞きますが、やっぱり C スタイルより C++ スタイルでキャストした方が良いのでしょうか？
安全性を考えるならC++キャストのほうが良いだろうな。
Cスタイルのキャストを禁止にするようなコンパイルオプションとかあったらいいな。
655 ：
デフォルトの名無しさん ：04/06/20 13:56
>>652 const_castやreinterpret_cast, mona(giko, c)はともかく
(char *)0を(char*)(0)と書けという根拠は希薄
>>655 漏れは精神衛生上C++にしてる。
混ざってると気持ち悪い。
>655
659 ：
デフォルトの名無しさん ：04/06/20 15:06
>>655 (char *)(0)はCスタイルじゃないか？
static_cast<char *>(0)
または
template<typename T> struct id{typedef T type;};
id<char *>::type(0)
かと。
そこでEffective C++ですよ
661 ：
デフォルトの名無しさん ：04/06/20 15:10
>>658 いいたいことはわかるが
reinterpret_castでないあたりから
耐え難い腐臭が・・・
>>614 利用者のスキルが低い場合にはありえることじゃないでしょうか?
funcは今回は適当に名前を付けましたが，
その中でdeleteしてることを全く連想させない名前である可能性はあるわけです．
これを否定するために，私としても561みたいにこの状況が起こり得ないことを示したいですね．
>>645 ,647
「ドキュメントちゃんと書けよ」ってのには異論の余地は無いですが，
設計者が利用者とコミュニケーションが取れないことを仮定して，
対策を講じておくのはいいことだと思います．
また，利用者が設計者を信用しないことも同様に安全性を高めると思います．
私に反論して下さる方には，利用者と設計者の立場を分けて考える視点が欠落していると思います．
どうでしょうか．(煽ってなんかないですよ．念のため．)
皆さんそれぞれ作ってるものが違うでしょうから一概には言えませんけど，
virtualディストラクタが(ディストラクタに限らなくてもいいですが．)
全体のパフォーマンスに影響与えてる局面って，
結構少なくないですか?
663 ：
デフォルトの名無しさん ：04/06/20 15:33
>>662 >利用者が設計者を信用しないことも同様に安全性を高めると思います
では、STLもコンパイラもCPUも信用せずに何ができるのか聞こうか。
664 ：
デフォルトの名無しさん ：04/06/20 15:37
プログラミングができる。
>>659 float(0) はC++タイプ、同様に(char*)(0) もC++タイプ
>>660 reinterpret_cast<char*>(0)
↑間違い
666 ：
デフォルトの名無しさん ：04/06/20 15:39
背後が壁の席でしか仕事をしない俺だって愛用の道具はあるさ
reinterpret_cast<char*>(0)
>>663 ここでいう，安全性とは
利用者と設計者の意志疎通がうまく行ってないことに起因する危険に対する安全性です．
そういう意味ではSTLもコンパイラも自前で設計した方が安全ですよ．
ただ，私にはその能力も時間も無いので機能的規模が小さくなっちゃうでしょうけど．
669 ：
デフォルトの名無しさん ：04/06/20 15:51
>>668 >利用者と設計者の意志疎通がうまく行ってないことに起因する危険に対する安全性です．
ここまではいいが
>そういう意味ではSTLもコンパイラも自前で設計した方が安全ですよ．
なんでそうなるんだよw
おまえさん、プロのコンパイラ屋よりもマシなコンパイラ作れるのか？
>>669 利用者と設計者が同一人物であるほうが利用者と設計者の誤解が少ないと言いたいのです．
> おまえさん、プロのコンパイラ屋よりもマシなコンパイラ作れるのか？
そんなの無理です(笑)．
だから「機能的規模が小さくなっちゃう」と書いてるんですよ．
まぁそんなのは最早STLとは呼べないんでしょうが．
>>670 >利用者と設計者が同一人物であるほうが利用者と設計者の誤解が少ないと言いたいのです．
・・・・・・
>>670 大体同じ意見。細かいところに話が行き過ぎてる気がするな。
ライブラリ作成者と利用者という立場で分けて考えると
ライブラリ作成者が課した決まりで利用者を縛りたいのは当然。
今話題になっている継承可能か否かという条件に関しては、それを行う時に
1. もしJavaのfinalのような言語仕様があれば、
利用者にも原因がわかりやすいコンパイルエラーにできる。
2.
>>543 のような仕掛けを用意して、とりあえずコンパイルエラーにする。
3. 継承不可能とドキュメントに書いておく。
4. （別の解法だが）効率無視してデストラクタvirtualで好きに継承させてしまう。
これくらいの選択肢があるぞと。
で、最もスマートなのは1。ドキュメントもほとんどいらないが今のC++では現実的じゃない。
2、3はドキュメント化して、利用者に守らせることが必須になる。
（2の場合は違反して継承した場合のコンパイルエラーを示しておかないと混乱の元）
4をやるかどうかはライブラリ作成者のポリシーによる。
俺は一連の流れからこんなふうに感じた。
>>665 g++3.3ではポインタに関してコンストラクタ記法はCスタイルキャストと全く同じ挙動を取るから、
(char *)(0)がどちらと等価かは実験では判断できない様だ。
従って、実際上どうでも良い事になるな。
文法上はどうなんだろう。
>>672 中点を幾つも書きたいだけなら、いちいち引用とかしなくていいです ;-)
>>673 Great! 私の意見はこの中にまとまってます．
>>547 は潔癖の傾向があって
自分が提供したライブラリを利用した場合、
どんなヘボプログラマが利用者でも可能な限り問題が起きないように
したいと思っているんだろうな。気持ちはよくわかる。
virtualの効率に関して言えば、最近だとケータイアプリの
ゲームなんかを作っている人は気にするんではなかろうか。
こういう環境で汎用的なライブラリを作ろうとすると、
「何でもvirtual付けとけ」とはならないような気がする。
>>673 あぁ，しまった．「private，protected継承」ってのも入れて下さい．
安全性を第一に優先する私としては，
1. Javaのfinalのような言語仕様
2.
>>543 のような仕掛けを用意して、とりあえずコンパイルエラーにする。
3. private，protected継承を検討する．
4. 効率無視してデストラクタvirtualで好きに継承させてしまう。
5. 継承不可能とドキュメントに書いておく。
の順でしょうか．
デストラクタがvirtualでないクラスを継承したら警告するコンパイラってないの？
>>678 よく考えると，「private，protected継承」するのは利用者で，
他の項目は設計者ですね．
すみません．
>>678 俺の見た感じこの話にはいくつか段階があって
Q. ヘボ利用者にポリモーフィズム周りで安全なライブラリを提供するには？
A1. デストラクタproteccted
A2. デストラクタvirtual
A3. 継承禁止
A3-1. Javaのfinalのような言語仕様
A3-2.
>>543 のような仕掛けを用意して、とりあえずコンパイルエラーにする。
A3-3. 継承不可能とドキュメントに書いておく。
のような形だろうか。
> 3. private，protected継承を検討する．
これはライブラリ作成者側から縛れないので疑問符。
>>673 で 4に関して別の解法と記したのはA3の実現方法を論じているのに
それより上位の解法を出すのは反則かなと考えていた。
C++な人はdelphiを馬鹿にしますがdelphi->c++
突然、何の脈絡もなくそんなこと言うヤツの精神構造がいまひとつわかりません。
>>679 g++だと，
-Wnon-virtual-dtor 非仮想デストラクタについて警告する
ってのがあるけど，なんだか効いていないようです．
あと，
-Weffc++ Effective C++ 式の指針からはずれるものについて警告する
ってのがあって，これはbase class `class Hoge' has a non-virtual destructor
と警告してくれます．
>>547 話し続けてくれてありがとう。この話題はすごく楽しめた。
>>543 のような手法を知るきっかけにもなったし。では撤収。
喧嘩するなおまいら仲良くしろ（´☻ω☻`）
689 ：
デフォルトの名無しさん ：04/06/20 20:42
Λ＿Λ ＼＼
（ ・∀・） | | ｶﾞｯ
と ） | |
Ｙ /ノ 人
/ ） < >__Λ∩
＿/し' ／／. Ｖ｀Д´）/
>>688 （＿フ彡 /
s/ヌルポ/空ポ/
690 ：
デフォルトの名無しさん ：04/06/21 00:07
g++って、using namespace stdなしでcout使っても怒られない。
>688
>>690 間違って iosteram.h をインクルードしてない？
693 ：
デフォルトの名無しさん ：04/06/21 00:14
>>692 そんな奇妙な名前のものはインクルードしていません。
まずこんな関数が有るとして
('A`)＜ヒロシです…
>>696 B のほうは
if (偽 && 偽 || Foo()) // B
なんだから、
if (偽 || Foo()) // B
と同値で、まだ Foo() によって真になる可能性がある。
>a=1になってる為に最初のa == 0で偽になり、その後の条件は実行されないと思っていましたが・・・。
おっと間違い、最初のは
>>696 &&と || の優先順位の仕様を確認しよう。
MSDNだと、「優先順位と評価順序」という項目があるはずです。
初心者ほどわざと難しく書いて自分を混乱させるのが得意だからなぁ。
「難解な書き方するのがプロ」とかは、思わない方がいい。
素直に括弧つけてれば避けられるようなヒューマンエラーは自力で避けよう。
>>691 ごめん。調べてみたら、まだ結論が出てない話みたい。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#463 漏れの意見は"SUGGESTED RESOLUTION"と同じく、
reinterpret_cast<T*>(0)は実装定義の変換であるべきだと思う。
そして、null pointer（これならｶﾞｯてされない？）を取得する方法として
reinterpret_cast<T*>(0)としない理由を、「間違い」ではなくて
「static_cast<T*>(0)のほうが良い」と訂正しておく。
あと、
s/値0のビットパターンによる/値0から実装定義の変換によって得られる/
これでいいかな？
s/ってなんでつか(´･ω･`)
ヒューマンエラーのリスクを極力減らしてこそ、プロだ罠。
>>704 swap（文字列置換）
viエディタやPerl言語などで用いる有名な正規表現
>>704 sedスクリプトの置換コマンド。たぶんsubstituteの略。
>>706 ありがとう（´･∀･`）
ぐぐっても出てこなかたーYO！
>>707 同じくサンクスコ(･∀･)
なんかのスイッチかと思いまつた
あ、そうか、||の方を括弧で括らなきゃ駄目でしたね。
>>710 自分のソースなら間違いと気付けるけど、
他人のソースだった場合は、間違いなのか意図的なものなのか、
分からない事が多い。
あるなあ、それ。
714 ：
デフォルトの名無しさん ：04/06/21 06:18
>>690 歴史的な事情により、そういうバージョンも残っている
STLも初期のバージョンではstdで囲われていなかった
715 ：
デフォルトの名無しさん ：04/06/21 06:20
>>702 そーゆーことを言いながら
素直に憶えれば避けられるようなヒューマンエラーは放置か
他ＰＧの文法理解度に依存した（もしくは、甘えた）記述を
避けてこそ堅牢な開発が可能。
「素直に憶えれば避けられる」とか、気合とか、修行とか、
精神論まがいな言動をカマす人間は、
一生、独りでソース管理やってればいいだけのこと。
先入観が大きいほどに見逃す危険も大きくなるという
人間の心理を理解できない、
>>715 が実に憐れだ。
ぶっちゃけ、「自分以外のPGはアホだから配慮してやる」でも構わん。
718 ：
デフォルトの名無しさん ：04/06/21 09:09
ポインタとオーバーロードと標準変換のからみってどう思う？
>>718 > fc(char*) or fc(char* const)
これ、オーバーロードじゃないよ。同じ関数。
>>718 > fc(bool) or fc(const bool) or fc(volatile bool) or fc(const volatile bool)
これも全部同じだな。
fc(char*) or fc(char[])
>>681 Java や C# じゃないんだから、非ポインタで普通に（ポリモじゃなく）クラスとして便利に使える
場面も多々あるわけで、ポリフォできないから継承ダメ、っていうのは方向性として漏れはすきじゃないなー。
派生クラスから基底クラスへのポインタに変換するトコがあればエラーなり警告なり出してくれる程度でいいや。
連想配列を使おうと boost を導入したのですが、
>>723 連想配列なら標準のstd::mapがお勧め。
ちなみにboostのProperty Mapはmapっぽいものに対する
共通のインターフェースであって、連想配列そのものではない。
725 ：
デフォルトの名無しさん ：04/06/21 18:15
【教えてください】
>>719-721 フォローどうもです。
fc(char*) = fc(char[]) = fc(char* const)
fc(const char*) = fc(const char[]) = fc(char const*)
ですね。
後から関数が加わったときに呼び出し先が変わると困る場合は
標準変換に頼って関数を呼びださないで
きっちりキャストしとかないとまずいってことなのかな。
>後から関数が加わったときに呼び出し先が変わると困る場合は
delete [] a, b;
730 ：
デフォルトの名無しさん ：04/06/21 19:59
>>716 甘ったれはそっちだろ
規格票を読んでない人がそのことの正当性を強弁する姿は
マニュアルを読んでないユーザが直情で当たり散らす姿とそっくりだ
無知そのものに罪はないが、居直りが加われば間違いなく足手まとい
初心者には厳しさの中に優しさを持って接するが
周囲の足をひっぱるお荷物は叩き出すのが唯一の正当防衛
自分の仕事に関わる規格に精通しようと勉強する人の
やる気をくじくような毒電波をまき散らすな
あんた１人の甘ったれじゃ済まされない威力業務妨害なんだよ
先輩から吹き込まれたならアフォの伝統は浄化しろ
731 ：
デフォルトの名無しさん ：04/06/21 20:05
質問があります。（next = NULL)っていうのが
>>731 0に展開されるマクロ。
ポインタに変換される事を意図していると表明するために使われる事がある。
>>729 delete [] a; b;
となる
734 ：
デフォルトの名無しさん ：04/06/21 20:24
735 ：
デフォルトの名無しさん ：04/06/21 20:25
えっと、あのＣ＋＋を始めたばかりで、
736 ：
デフォルトの名無しさん ：04/06/21 20:27
電車ガール
>>735 そのレベルの質問だと初心者スレのほうがいいでしょ。
ただし、そっちでも「自分で調べろ」「入門書嫁」で終わる
可能性が高いですが。
>>730 ＞周囲の足をひっぱるお荷物は叩き出すのが唯一の正当防衛
「言うは易し、行うは難し」だよ。
ネットで怪気炎あげるのは構わんが実際に叩き出すにしても、
そのための労力・時間も馬鹿にならん。
むしろ、甘ったれてるのは君だろ？
＞自分の仕事に関わる規格に精通しようと勉強する人のやる気をくじく
そのくらいで挫けるならさっさと挫けてしまえばいい。
職人的な聖域を徹底排除することがＰＭにとって重要。
よし!
742 ：
デフォルトの名無しさん ：04/06/21 22:56
>>740 >「言うは易し、行うは難し」だよ。
行えない香具師からのインカムでおまんま食えてるわけだがw
職人やりたくない奴の侵入社員が何物よりも迷惑なんだよ
や る 気 ね ー や つ は 出 て け
どこの職場にも通じる鉄則だ
またスレ違いの話題で盛り上がる
「言語の規格」と、「人間にとって理解しやすい規格」はイコールじゃない。
>>742 人事にかかわったことがない万年下っ端は楽でいいな。
>>742 の職場は、職人的な高い技術が求められているにも関わらず、
新入社員がスタッフとして送り込まれてくるらしい。可哀相に（ｗ
大した仕事でもないのに職人気取るヤシって邪魔だよな。
747 ：
デフォルトの名無しさん ：04/06/21 23:07
>>744 無能PGの理解レベルを優先して何の勝負をしてるんだ、おまえんとこわw
投稿者について言及してもヒートアップするだけで実りはないですよ．
「人妻にかかわったことがない…」と語読。
どっちの主張もうなずけるんだがな。
あえて思い切って、高度で煩雑な規格の使用を制限して、
752 ：
デフォルトの名無しさん ：04/06/21 23:15
>>751 規格票が理解できねって？ ああ、そりゃお気の毒に・・・
だったらわざわざここに来る必要は無い。
>>752 ネタにマジ煽りされても困るなぁ。
なんつーかさぁ、もうちょっと心に余裕持てよ。
でもさ、いまどき C++ で能無しがこなせる業務あるかな。
３日前からずっとやってない？
>>753 大人しく教えて下さい
で、何を教えてくれるの？そもそもお前はどのレスに言ってるの？
C++やると性格が歪むって本当らしいですね？
>>759 あるひとつの問題に対してアプローチがいくつもあり、
それらひとつひとつが曲者だからね。
追いかけるのに疲れ果てて性格が歪むのも無理はない。
これは、C/C++をマスターしていると思っている人間ほど顕著である。
いちいち他人のコードを自分流に修正せずには
いられない脅迫観念にとりつかれているからだ。合掌。
>>759 規格票が理解できねって？ ああ、そりゃお気の毒に・・・
>>760 ひとつしかない方が異常だとおもうけど。
763 ：
デフォルトの名無しさん ：04/06/21 23:42
よっぽど悔しかったらしいなw
>>742 は、問題が起きたら俺が泥をかぶればいいという気質の人間だろう。
さもなくば、事情を知らない煽りか？
前者であれば、口は悪いが心の熱い人間であるといえよう。
実際問題、無能ＰＧが配置されてしまったとして、
そのフォローに奔走するのは結局
>>742 自身だからである。
>>740 は、意外と冷酷な人間だろう。
途上国の安価ＰＧに下請け発注することを専らとしているに違いない。
742も740も俺の自演ですが何か？
>>725 私は直前のＩＰを保持して同値ならカウントアップしないようにしています。
クッキーは好きじゃない。
自分自身が参照したときもカウントアップしないようにするといいかも。
こっちは自分なのでクッキーでもいいかな。
それよりもC++でCGI作らせてくれることがうらまやしい。
SAKURAはC止まりなので。
delete [] a, b;
>>768 >>733 delete a,b; とし、a,bをクラスにして、
bのデストラクタが呼ばれない事を確認してみろ。
770 ：
デフォルトの名無しさん ：04/06/22 20:03
delete [] (a,b)としたところで何の問題の解決にもならん気がするが。
772 ：
デフォルトの名無しさん ：04/06/22 20:24
>>771 768は何かの「解決」を求めているか？
deleteといえば、プログラムが終了になるときは、
774 ：
デフォルトの名無しさん ：04/06/22 21:47
>>773 絶対されるとも言えないし、絶対されないとも言えない
処理系によってはやばいってことですか？
777 ：
デフォルトの名無しさん ：04/06/22 22:01
>>776 >後処理やってくれるようですが
このへん全然ダメ
ちゃんと調べろ
>>773 OS依存。まぁ、普通はプログラム終了時に
リソースは全て回収される罠。
>>773 メモリに関して言えば、多くのOSや環境でその通り。
デストラクタは走らないので、例えばテンポラリファイルを作るクラスなど開放時に
処理が必要なオブジェクトはちゃんと delete する必要がある。
780 ：
デフォルトの名無しさん ：04/06/22 22:03
>>778 >OS依存。まぁ、普通はプログラム終了時に
このへん全然ダメ
ちゃんと調べろ
>>776 デストラクタを動作させる必要があるなら、ちゃんと delete する。
「～ほうがいい」とか言うより、仕様や期待する動作の通りに動くように
プログラムを書けばいいだけだと思うけど。
exitは単に静的オブジェの破棄、バッファフラッシュ、クローズ処理を
783 ：
デフォルトの名無しさん ：04/06/23 00:35
どなたか CINT
ttp://root.cern.ch/root/Cint.html の日本語でのマトモな解説サイトとか御存知だったら教えて下さい。
google先生にお伺いしても大したサイトは引っかからないし、
本は絶版になっちゃってるみたいだし。
このソフトすごいと思うんですけど、マイナーなんですかね。
C++インタープリターってここにいる人達なんかにとってはちょっとしたスク
リプト感覚でC++が使えて非常に便利だと思うのですが。
日本人の作者がいるからメールしてみたら？
>>784 そこ行ったらspybotが喚き出した。
787 ：
デフォルトの名無しさん ：04/06/23 11:09
ご教授お願いします。
LPTSTR szHoge = new TCHAR(MAX_PATH);
>>767 サンクスです。
その方法でやってみます。
790 ：
デフォルトの名無しさん ：04/06/23 11:53
>>788 ｸﾞﾊ orz
ｻﾝｸｽ。もう仕事辞めます。
>>787 誤：LPTSTR szHoge = new TCHAR(MAX_PATH); // 値MAX_PATHで初期化された 1 つの TCHAR を newする
誤：LPTSTR lpTgzPath = new TCHAR( nRtn + 1 ); // 値nRtn+1で初期化された 1 つの TCHAR を newする
正：LPTSTR szHoge = new TCHAR[MAX_PATH]; // MAX_PATH個のTCHARの配列をnewする
正：LPTSTR lpTgzPath = new TCHAR[ nRtn + 1]; // nRtn+1個のTCHARの配列をnewする
だら～っとで良いので、もういっぺん C++ の本とか読み直しておいた方が余計な苦労せずに済むかも。
あと、szHoge みたいなのはいちいち new しないで、ローカル変数の方が良いと思う。
っていうか、スマートポインタ使えよ
なんでもスマートポインタを使えばいいわけじゃないし、この処理では明らかに不要だろ。
この処理とやらの外側でWin32構造化例外を拾っている可能性はあるからスマートポインタが不要とはいえんな。
>>787 GetWindowTextやCopyMemoryで中身は上書きされるんだからZeroMemoryはいらない
テキストの長さだったらGetWindowTextLengthでわかる
int nSize = (GetDlgItem( IDC_EDIT_HOGE ))->GetWindowTextLength();
LPTSTR szHoge = new TCHAR(nSize);
(GetDlgItem( IDC_EDIT_HOGE ))->GetWindowText(szHoge, nSize);
>>794 deleteミスるぐらいならスマートポインタ使えってことだよ。
っていうか今どきnewとかつかわんよ
スマートポインタ使えとだけ言っても何の疑問も解決しねえだろカス
>>797 >っていうか今どきnewとかつかわんよ
はいはい、脳内「今どき」はあんたの頭の中だけにしときな( ´,_ゝ｀)ﾌﾟｯ
800 ：
デフォルトの名無しさん ：04/06/23 14:22
素で質問です。
801 ：
デフォルトの名無しさん ：04/06/23 14:23
前もって全部staticで宣言しておけばいい。
動的に増やさなくちゃいけないから new があるんじゃ
またC厨が暴れているのか。
mallocで十分
ただ騒ぎたい奴が8割
ポインタの参照 *& ってどんな意味があるのでしょうか？
>>808 void func( char **&p)
だとしたら、funcでpをいじるんじゃないですか?
*pではなく、**pでもなく。
>>808 普通の参照と同じだが？
void func(char *&rp)
{
static char c = 'd';
rp = &c;
}
char *p;
func(p);
811 ：
デフォルトの名無しさん ：04/06/23 17:44
ダイアログ上のフォーカスをTABで移動していって、ボタンにフォーカスが来ると
>>811 キミはそれをC++の話題だと思うのか?
813 ：
デフォルトの名無しさん ：04/06/23 17:51
>>812 VC++やらMFCの話をここでしてはいけないのですか？
・::std::vector< TCHAR > を使う。
815 ：
デフォルトの名無しさん ：04/06/23 17:52
あ、VCのスレがあるんですね。失礼しました。
ポインタと参照ってほとんど同じものだと思ってました…orz
>>811 Microsoft の Windows の話だと仮定して返事してみる。
黒い影は「デフォルトボタン」の印で、フォーカスとは必ずしも関係ない。
あとはWin32 API スレで続けた方がいいよ。C++ と関係ないし。
>>813 811 はおそらく Windows の UI の仕様に関する質問で、別に MFC も VC++ も関係ないみたいだけど・・・
ん～、以下のrfuncとpfuncの違いは何なのでしょうか？
>>820 リファレンスを取る時は実体が必要。aaaは単なるポインタに変換され、それは
実体がない(変数に入っていない)のでリファレンスを取ることはできない。
無理に取ろうとすると一時変数が作られる。
>>820 rfuncもpfuncも引数(この例ではそれぞれrpとpp)に対して操作を行っていないので、
違いが大きく現れない。
rfuncでは、例えばrp = 0;とすると、これがmainのbbbに反映される。
pfuncではこれは起こらない。
このあたりはポインタとの絡みは関係なく参照という物の性質なので、
参照渡しについて復習してみる事をお勧めする。
rfunc(aaa)と書けないのは、aaaがポインタ変数でないから。(ポインタに変換可能であるに過ぎない)
ポインタのリファレンスはむしろこっちの使い方の方が多いな。&pとして呼び出す
関数の中で引数に対してnewとかしちゃうと、
ていうかね
>>826 わかってるけどその説明じゃ分からない香具師がいるんだよ。頭の固い香具師が。
>>827 >頭の固い香具師が。
下らん質問にしか回答できない半端もんのくせに、
初心者に対してはびっくりするほど態度でかいな。お前。
>>828 >下らん質問にしか回答できない半端もんのくせに、
どうやって俺が下らん質問にしか回答してないとわかるんだ？エスパーか？
830 ：
デフォルトの名無しさん ：04/06/23 21:35
s/しか/も/
831 ：
デフォルトの名無しさん ：04/06/23 21:41
C++（プログラム）が早く身に付く方法はないですか？
検索エンジンとかで出てくる%83%82%83E%83_%83%81%83%7Cとかいったコードを
>>829 恐らくエスパーではなく「こわがり」なのでしょう ;-)
>>831 プリンタで大きく「Ｃ＋＋」と印刷した紙を糊で体に貼り付けろ。
836 ：
デフォルトの名無しさん ：04/06/23 22:11
>>831 パイロットに早くなれる方法はないかというのと同じくらい果てしない質問だ
837 ：
デフォルトの名無しさん ：04/06/23 22:11
給料はパイロットの５分の１くらいしか貰えんが
パイロットって月給手取り300万近いのか？
もらう奴はそれ以上。
840 ：
デフォルトの名無しさん ：04/06/23 22:32
Cからのステップアップに最も適した本は何ですか？
842 ：
デフォルトの名無しさん ：04/06/23 22:40
char *pp で ppは、*bbbのアドレスのコピーが入った入れ物で、
845 ：
デフォルトの名無しさん ：04/06/24 01:38
コンストラクタの初期化リストで配列を初期化することはできるの？
誰かお知恵は有りませんか、、、
>>847 JavaScriptなら変換関数あるから簡単だよ。
C++なら自分で作ればいいし。アルゴリズムも何も、先頭から順に見て%見つけたら変換するだけだしね。
>>848 いや、出来るというか出来てるんですが結構遅くて。
こういうものは結構昔から使われているだろうから
何か良いアルゴリズムは無いかなぁと思う次第です。
>>848 相手にすんな。
「自作だと遅い」とか言ってるが、Ｃ言語で遅く作る方が難しい。
本当は作ってもいないのに知恵を拝借したいだけだろう。
あるいは過去ログコピペ荒しかもしれない。
自作コードのパフォーマンスについて評価する術を知る者が、
>>849 その遅いコードとやらはどうせ8,9行だろ貼って見せろ。
851=852=853
これです。もっと良い方法あると思うんですけどね。
url エンコード define
url エンコード include
デコードだった
なんだ、真性だったか。
>>832 何と比較して遅いのかが知りたいところだな。
>>855 URLdecode って名前つけてるな
それで検索しなかったのか？
Cから始めて15年、strtol() なんて使ってるプログラムは初めて見た。
>>856 幾つか見て見ましたが定石みたいな物は無いみたいですね。
それでも自分の作ったやつよりは速そうなのでそれを使ってみることにします。
てか、URLdecodeで調べれば一発だったんだ。
文字変換で調べまくってたのはあほだった。。。
関数名に同じの使ってるのもあるし、、、orz
>>855 ifの比較は遅すぎ。テーブル検索するように変更。
strtolは遅すぎ。自前で書き換え。
テーブル検索って何だ？
>>864 isdigit()などの実装しらんのか？
BOOL URLdecode(const char *in, char* out)
C++と関係ないじゃん。Cスレに逝ってくれよ！
>>865 isdigit()などの実装がひとつだとでも言うのか？
>>865 ひょっとして、char型の256個配列を用意するとか？
const char codetbl[] = "0123456789ABCDEF";
>>872 ( ´,_ゝ｀)ﾌﾟｯ
嘘つきはお前だよ
そんなの、CPUとメモリやキャッシュ速度によって如何様にも変わるから
>>873 そんなの何の意味も無い。
VC6のランタイムだと、
#define isdigit(_c) (MB_CUR_MAX > 1 ? _isctype(_c,_DIGIT) : _pctype[_c] & _DIGIT)
こんな実装になってる。_isctypeもまたシンプルでない実装になってるし。
>>874 いいから試せ。
漏れは、GCCとVC6で逆転を確認している。VC7は試してない。
>>877 だから試してから書いてんだよ。激遅。CPUの違いぐらいで吸収できる差とは
思えん。
相変わらず、C++の領分から外れたり、話題の程度が低くなったりすると
低レベルな争い
関数内で宣言した変数ってスコープの関係で、関数から出ると使えなくなるんでしょ？
>>878 ちゃんとinline関数とかマクロにしたか？
漏れの環境だと、isdigit()：自作コード=5：1だぞ（VC6）。
>>883 それぐらいちゃんとしてるっつーに。しつこいな。
>>884 俺がどのスレのどのレスで煽ってるかはどこにも書いてないのだが・・・・
またエスパーか？
>>878 コンパイル環境と所要時間の比ぐらい示したらどうか？
劇遅でも数値ぐらい示せるだろ。
こまかいけど訂正
>>881 ダメ。すぐもなにも元よりスコープ外の物に保障はない。
class cTemp{
また、virtualに戻るのか…
>>889 isa1>isa2=isalpha
#include <stdio.h>
#include <ctype.h>
#include <assert.h>
const int alpha = 1;
int table[256];
maketable()
{ int i;
for (i = 'A'; i <= 'Z'; i++) table[i] |= alpha;
for (i = 'a'; i <= 'z'; i++) table[i] |= alpha;
}
int isa1(int c)
{ return table[c] & alpha; }
int isa2(int c)
{ return ((c >= 'A') && (c <= 'Z')) || ((c >= 'a') && (c <= 'z')); }
int measure(int(*f)(int), int times)
{ char s[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
int i, j, t = clock();
for (i = 0; i < times; i++) for (j = 0; j < sizeof(s) - 1; j++) assert( f(s[j]) );
return clock() - t;
}
main()
{ maketable();
printf("%dms.\n%dms.\n%dms.\n", measure(isa1, 1000000), measure(isa2, 1000000), measure(isalpha, 1000000));
}
>>880 ＞低レベルな争い
そうだ。
低レベルで、かつ、ループの中で何千・何万回も行うかもしれない重要な処理だ。
スレ違いなのは認めるが、if構文や自作コードが遅いかどうかは極めて重要だろ？
>>895 センスが無いのか読解力がないのか微妙な1～2行目はともかく、
> スレ違いなのは認めるが
わかっているようなので終了ですね ;-)
>>894 は、
>>878 .
>>885 とは別人かな？
inline関数やマクロを使ってないみたいだし。
それはそうと、
>>894 のコードを自環境（VC6）でやってみた。
（一部コンパイルが通らない部分やassert()除外などの修正した。）
297ms.
360ms.
343ms.
自環境ではテーブル検索型が最も速かった（isa2>isalpha>isa1）。
述語関数的な用途だと確かに標準ライブラリ関数が威力を発揮する。
自分が
>>883 で使ったソースでも非インライン・非マクロの場合、
標準のisalpha()に惜敗だった。差は5～10%ほど。
いずれにせよ、
>>878 が触れたような【CPUの違いぐらいで吸収できない格差】が得られなかった。
>>878 の劇遅に関するレポートが見たいところだな。
VC6なら-Ob2かな、これでインライン展開されたはず。
>>898 なぬ？
関数アドレス渡しでもinline処理が使えるとは知らなかった。・・・orz
0ms.
0ms.
265ms.
・・・アレ？スマソ。ソース修正の仕方が悪く余計な最適化されてしまってたみたい。
そんなわけで余計な最適化されないように修正した。
～最終結果～
●非インライン・非マクロ（Ob2なし）
281ms.
375ms.
359ms.
>>897 とほとんど同じ。
●インライン（Ob2あり）
78ms.
141ms.
500ms.
これも、テーブル検索型が最速だ。
興味深いのは、Ob2指定でisalpha()がかえって遅くなっているところだ。
cygwin + gcc3.4.0 （-O3）だとこうなった。
俺もやってみた。
漏れは以前、このスレに、「車輪の再発明はよくない」とか書き込んた者なのだが、
車輪を再発明する必要はないが、出来の悪い車輪を改善する必要は時としてある。
まあ、今回のケースはisxdigitを迂回する必要があるかどうか疑問だけどな
907 ：
デフォルトの名無しさん ：04/06/24 16:59
例外規則って何かに使われてるんですか？
デザインパターンのStateパターンって、
isalphaはロケールを見て適したテーブルを引く、ということをVCはやってたから (間違ってたらゴメン)
*BaseState に代入できませんな…orz
912 ：
デフォルトの名無しさん ：04/06/24 20:21
>>910 テストしてみたけど、isalphaだけだとうまくいかない。
(下記の後者のどこがいけないのでしょうか？)
setlocale(LC_CTYPE,"japanese");
//これはOK
for(int i=0;i<=0xFF;i++){
if( !( isa2(i) == ( (isascii(i & 0xFF) != 0) ? (isalpha(i & 0xFF) != 0 ) : (false) ) ) )
printf("isa2(%d)=%d,isalpha(i)=%d\n",i,isa2(i),i,isalpha(i));
}
//これだとなぜかうまくいかない
for(int i=0;i<=0xFF;i++){
if( !( isa2(i) == (isalpha(i & 0xFF) != 0 ) ) )
printf("isa2(%d)=%d,isalpha(i)=%d\n",i,isa2(i),i,isalpha(i));
}
なんで戻り値を比較してるんだ？
>>890 じゃあ、どうやって戻り値を利用するの？
ローカル変数のコピーを返せばいい
>>912 つうか、プログラムもうちょっとちゃんと書け
ifの条件をすっきりさせて、printfの引数の数を数えなおせ
>>915 関数の引数に変数を渡したらコピーされるのは知ってるけど、
returnの場合もコピーされた変数が戻る？
>>916 ほんとだね。全然見てなかった...orz
setlocale(LC_CTYPE,"japanese");//これがないときは両方うまくいく
//これはOK
//asciiか判断してからalphaかを確認
for(int i=0;i<=0xFF;i++){
if( isa2(i) != ( (isascii(i) != 0) ? (isalpha(i) != 0 ) : (false) ) )//一致しないとき
printf("isa2(%d)=%d,isalpha(%d)=%d\n",i,isa2(i),i,isalpha(i));
}
//これだとlocale変えてるときに一致しないときがある
//alphaかだけを確認
for(int i=0;i<=0xFF;i++){
if( isa2(i) != (isalpha(i) != 0 ) )//一致しないとき
printf("isa2(%d)=%d,isalpha(%d)=%d\n",i,isa2(i),i,isalpha(i));
}
921 ：
デフォルトの名無しさん ：04/06/24 21:46
ctype.hのisalphaとlocaleのisalphaは別物だぞ。
922 ：
デフォルトの名無しさん ：04/06/24 21:46
つまりC++はCより遅い
ついでに俺も正直者という事にしておいてください。
>>919 一致しない範囲は半角ｶﾅなんだってば。
この辺？
> _ismbcalpha
> 英字 c がシングルバイト ASCII 英字(0x41<=c<=0x5A または 0x61<=c<=0x7A)
> または半角カタカナ文字(0xA6<=c<=0xDF)の場合だけ真を返します。
>>918 もどらない。戻り値は使わないようにすべき
927 ：
デフォルトの名無しさん ：04/06/25 07:40
すみません、質問があります
はい次の質問どうぞ
"C++"を二文字動かして"C#"にしろといわれましたがよく分かりません。
931 ：
デフォルトの名無しさん ：04/06/25 09:20
>>930 二文字動かすの部分がわかりません。出力例をください
VC++つかってるんですが
933 ：
デフォルトの名無しさん ：04/06/25 09:32
>>932 文字通りメモリリークしている。
たぶんdelete忘れ。
VCスレで発見方法教えてもらえ。
（ 'ｰ' ）ｲｲ!
938 ：
デフォルトの名無しさん ：04/06/25 18:51
質問でございます
939 ：
デフォルトの名無しさん ：04/06/25 20:26
>>928 ISO/IEC 14882:2003，Information Technology―Programming languages―C++
では、アニメーションについて規定していない。
よって、このスレのスコープ外である。
処理系別のスレで質問されるがよい。
>>938 できるだろ。もしかして
int x;
} ←ここに ; が抜けてるだけ、とかいうオチじゃないだろうな？
今晩は厨房いないのかツマラン
↑初登場
944 ：
デフォルトの名無しさん ：04/06/26 00:38
iostreamについて質問です。
istream* pistr;
(argc > 1)って常に真だと思うが。
訂正。
>>946 マジで言ってるんだとしたら、相当痛い。もう寝とけ。
>>944 こんなところで。
#include <iostream>
#include <fstream>
int mainfunc(std::istream & stream){
int i;
stream >> i;
std::cout << i;
}
int main(int argc,char *argv[]){
if(argc>1){
std::ifstream stream(argv[1]);
mainfunc(stream);
}else{
mainfunc(std::cin);
}
return 0;
}
さらに訂正。
>>945 ,949
なるほど･･･理解しました!
ありがとうございました。
クラスのプライベートで、
>>952 これでいいか
class name{
private:
static char *dogs[];
};
char *name::dogs[] = {"Afghan Hound", "Beagle", "Border Collie", "Dalmation"};
954 ：
デフォルトの名無しさん ：04/06/26 11:01
>>952 class name{
private:
char *dogs[4];
public:
name()
{
dogs[0] = "Afghan Hound";
dogs[1] = "Beagle";
dogs[2] = "Border Collie";
dogs[3] = "Dalmation";
}
};
>>953 これだと結局はグローバルで初期化することになるよね？
できればコンストラクタ内で初期化したいんだよ。
>>954 それは俺も考えたんだけど、そんな面倒くさいことしないといけないの？
本当に使おうと思ってる配列の数は28個なんだけど。。。。
956 ：
デフォルトの名無しさん ：04/06/26 11:16
>>955 class name{
private:
char *dogs[4];
public:
name()
{
ifstream f("dogs.txt");
for(int i = 0; i < 4; i++) {
//ma, ganbareya...
}
}
};
class name {
>>955 > できればコンストラクタ内で初期化したいんだよ。
ならコンストラクタの中に書けばいいじゃないか。
>>955 ＞そんな面倒くさいことしないといけないの？
古今稀に見るワガママ君だな、キミ（ｗ
クラス関係ないじゃん。
>>955 コンストラクタ内で初期化したいということは、インスタンス毎に配列を
持っていたいということ?そうだとしたら、そもそも
>>953 の方法は適さない。
その配列を書き換えるつもりが無いのなら、staticなメンバとして宣言して、
クラス定義の外で一度だけ初期化するの(つまり、
>>953 の方法)が自然だと思う。
その配列の用途が判らないことには答えようがないよ。
>>961 >インスタンス変数とクラス変数
お前の造語か？( ´,_ゝ｀)
わかったとしてもわがまま言うだろうから、ここは素直に「できない仕様」と言って放置しよう。
965 ：
デフォルトの名無しさん ：04/06/26 13:22
>>963 まずググってから発言するべきだったな
( ´,_ゝ｀)ｽｹﾞｰﾊﾞｶﾊｯｹﾝｼﾏｽﾀ！
>>966 まあ、クラス変数作るのにstaticなんてキーワード使うC++系言語が悪いといえば悪いんだけど。
ググってから発言すべきってのには同意。
グローバル変数、メンバ変数と言ってくれなきゃわからん。
そして誰も相手しなくなった・・・
>>968 それもクラス変数、インスタンス変数とは微妙に違う。
C++では、両方とも「メンバ変数」で、static付いてるのが「静的メンバ変数」だ。
稲垣メンバ変数
Javaの用語をC++スレで言われてもなぁ・・・・・
じゃあ変数の呼び方で1000目指します。
それじゃおまえら女性にはちんちんのこと何て呼んで欲しいよ。
個人的にはインスタンス変数って言葉が何となく気持ち悪い。
俺もおちんちん派
インスタンスおちんちん
じゃあ非staticメンバ変数をおちんちん変数と呼ぼう。
Visualおちんちん++
おちんちん++;
違うだろ++はイテレータだ。隣のﾏﾑｺに移動するんだよ。
++は必ずﾌﾟﾗﾌﾟﾗと発音する様に
C++の相談を・・・・
>>986 におちんちんをいじってる姿を見られた感じがするんだが
>>984 型が違うから同じコンテナに入れて走査できないだろ？
ぬルポに決まってるだろうが！
ちんぽいんたー
あとは次スレ立てて現スレ埋めるだけだから、
ﾂﾂﾞｷﾏﾀﾞｰ?
埋め
で、どういう流れでそうなったのかは忘れたが、
産め
梅
埋め
生め
1000 ：
デフォルトの名無しさん ：04/06/26 15:52
1000おちんちん ぬるぽ
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。
