C++相談室 part56 - 暇つぶし2ch

C++相談室 part56 ..

175:デフォルトの名無しさん
07/08/02 00:53:06
ﾃﾗBCB

176:174
07/08/02 00:57:40
書き込みが途中までしか出来てませんでした。
↓続き
関連する項目をググって、上記ソースを見つけたのは良いのですが、
得た値"Value"をstrcpy(a,b)のbで使おうとすると、
AnsiString型からキャストできず、エラーとなります。
AnsiString型をキャストすること自体がよろしくないようなのですが、
キャストか、他に良い方法がありましたら教えてください。

長文すみません。よろしくお願いします

177:デフォルトの名無しさん
07/08/02 01:01:43
strcpy(dst, AnsiString("あひゃ").c_str());

178:デフォルトの名無しさん
07/08/02 01:13:55
>>177は
Value.c_str()でやれということ

179:174
07/08/02 07:30:49
>>177＝>>178さん
どうもありがとうございます。
助かります。

180:デフォルトの名無しさん
07/08/02 22:26:11
プログラム中から現在のCPUのクロック数を測定したいのですが
どうすればいいでしょうか？

181:デフォルトの名無しさん
07/08/02 22:29:12
>>180
Win32APIのQueryPerformanceFrequencyは？

182:デフォルトの名無しさん
07/08/02 22:32:00
あれはかなりいい
しかしモバイル用CPUとか動的にクロックが変化するCPUだとちょっと困る

183:デフォルトの名無しさん
07/08/02 22:42:28
すいません>>182の理由により別の方法をおねがします
もしかして不可能？

184:デフォルトの名無しさん
07/08/02 22:45:00
条件があったのなら初めに言えよ

185:デフォルトの名無しさん
07/08/02 22:46:46
cpuid命令を呼ぶ
レジスタに信用なら無いモデルナンバーが返って来る
メーカーの資料と照らし合わせる
周波数を知る

186:デフォルトの名無しさん
07/08/02 22:51:17
CPUとは違う固定周波もってるハードに割り込みかけてもらうぐらいしか思いつかん……

187:デフォルトの名無しさん
07/08/02 22:56:08
＞現在のCPUのクロック数を測定
だから>>181でFA

188:デフォルトの名無しさん
07/08/02 23:08:53
>>185
ああ、その方法もありますね。しんどいけど。
どこかに cpuid　--> cpu clock 変換表みたいなのありませんか？

クロック自体はrdtscで読めるんですが、
最近のCPUは省電力モードとかで
クロック自体が落ちてることもあって
正確なクロックが取得できないんです

189:デフォルトの名無しさん
07/08/02 23:15:32
CPU毎の定格周波数が知りたかったのか？

190:デフォルトの名無しさん
07/08/02 23:24:10
CPU に意図的に負荷かけてから測定するとか。

191:デフォルトの名無しさん
07/08/02 23:40:09
asmでおｋ

192:デフォルトの名無しさん
07/08/03 16:33:06
可変長のメンバ配列変数は C99 で規格合致になったけど、
C++ だと 9.2p8 を見る限り対応されてなさそうな雰囲気を感じる。
これは、非静的メンバ配列変数のサイズは必ず指定する必要があるという記述だから
ここだけじゃ実際のところはっきりとは分からんけど。

でも、次期 C++ ドラフトを見るとこの記述が削られてる。
これは C99 と同様に可変長のメンバ配列変数に対応された現れだと見ているけど、
そのことが書いてある箇所が見つからない。

C++ での可変長のメンバ配列変数への対応具合の状況はどんな感じなんじゃろか。

193:デフォルトの名無しさん
07/08/03 20:55:47
可変長配列がないならvector使えばいいじゃない（ﾏﾘｰ

194:デフォルトの名無しさん
07/08/03 21:23:30
それなら C でも malloc 使えるしー。
でも、本気でそれでも問題ないと思うんだよな。
正直可変長メンバってどのくらい意味があるのか分かんないな。
Windows API とか可変長メンバを要求するところがあるから
しゃーなしで使わんといかんこともあるんだが。

195:デフォルトの名無しさん
07/08/03 21:33:07
ポインタ使うかわりに可変長メンバ使うとメモリ上のレイアウトがフラットに
なるから、そのままファイルに読み書きしたりできて便利な場合もあるでそ

196:デフォルトの名無しさん
07/08/03 22:04:00
stlのアロケータってrealloc操作がないのな。
vectorやstringのサイズ増加時にコピーが走りまくって参った。

197:デフォルトの名無しさん
07/08/03 22:16:19
reserveとかあるだろ
そういうハナシじゃない？

198:デフォルトの名無しさん
07/08/03 22:19:34
ふつうdeque

199:デフォルトの名無しさん
07/08/03 22:25:23
>>195
書き込みは一発だけど、
読み込む時は一旦サイズを読み出さないといかんのだよな。
状況によってサイズが分かる場合もあるけどさ。
そこまでの利点には思えんのよなあ。
昔だとその僅かな差も重要だったんだろうか。

200:デフォルトの名無しさん
07/08/03 22:27:52
>>196
<cstdlib>のreallocも、その場で拡張できなければ、
新しい領域を確保して、そこへ元の記憶域の内容をコピーすることになっている。
クラスインスタンス相手にコピーコンストラクタを使わず複写なんて
やるわけには行かないから、アロケータにrealloc相当の操作がないのも妥当な判断。

仮にやるとしたら、その場で拡張できるときだけ成功するrealloc操作
なんてことになるんだろうな。

201:デフォルトの名無しさん
07/08/03 22:33:47
>>199
malloc()/free()一発で確保・解放できるのも「Cでは」便利
で、特にデメリットも無いわけで
まあ可変長に出来るのは最後のメンバだけ、という制限があるけどな

ま、基本的に言語サポートが貧弱なCで特に生きるテクニックという気がする

202:デフォルトの名無しさん
07/08/03 22:35:49
記憶域の内容がコピーされても、
その後にちゃんとコピーコンストラクタを placement new で呼べば一応正常に動作する。

問題は二度手間になることと、
realloc による管理は C++ っぽくないってところだな。

203:デフォルトの名無しさん
07/08/03 22:36:31
PODのときはrealloc or memcpyするぐらいの配慮が欲しかったなあ
パフォーマンスに関わるんで結局手書きしちゃったよ
無駄にT()でfillするし・・・

204:デフォルトの名無しさん
07/08/03 22:37:30
>>201
どっちゃにしろ動的に確保する場合は
確かに一発で済むから便利か。なるほど。

205:デフォルトの名無しさん
07/08/03 22:40:24
でもまあバッファを拡大するときも、必要な量ぎりぎりではなく、
例えば倍々に増やしていったりする実装の存在なんかを考えれば、
やっぱりコンテナがrealloc相当のことをやっているんだよなと思う。

206:デフォルトの名無しさん
07/08/03 22:42:15
なんでC++にnew/deleteがあってrealloc()相当物が無いのかってのは
Stroustrupが説明してた気がするが、忘れた

207:デフォルトの名無しさん
07/08/03 22:45:50
placement new でコピーコンストラクタ使ってオブジェクト作ってるよ。

208:デフォルトの名無しさん
07/08/03 22:49:31
Win32 APIのVirtual Allocみたいなの使ってアドレス空間だけ予約しとけ

209:デフォルトの名無しさん
07/08/05 02:02:59
シグナルって何に使えばいいの？
中で特別な関数以外の関数呼んだら未定義とか規格に書いてるんだけど。

210:デフォルトの名無しさん
07/08/05 02:04:27
ぶっちゃけsignalがCの標準に含まれているのはどうかと思う

211:デフォルトの名無しさん
07/08/05 02:04:59
マジ？あの欠陥品が？

212:デフォルトの名無しさん
07/08/05 02:05:32
>>209　Unixの規格を読むんだ

213:デフォルトの名無しさん
07/08/05 02:09:07
Posix的にはsignal()は推奨されないでしょ
sigaction()を使うべき

Windowsのコンパイラが提供するsignal()は、規格を満たすためだけの紛い物で
何の役にも立たない

つまりsignal()なんて要らない子

214:デフォルトの名無しさん
07/08/05 02:10:34
いやシグナルという仕組み自体が正直勘弁だ

215:デフォルトの名無しさん
07/08/05 02:11:28
まあスレッド登場前の化石だよな

216:デフォルトの名無しさん
07/08/05 02:14:57
signal handlerからlongjmpがunixの作法ですが何か？

217:デフォルトの名無しさん
07/08/05 02:15:53
おk。大体分かった。

218:デフォルトの名無しさん
07/08/05 02:17:24
それが今となっては最悪の作法だよねって話でしょ
スレッドと相性が非常に悪いし
それでなくとも
シグナルハンドラが再インストールされるかどうかとか
システムコールが再送されるかどうかとか
シグナルハンドラ内であれをやってよいこれはよくないとか
バッドノウハウのすくつやん

219:デフォルトの名無しさん
07/08/05 02:23:03
write一つとっても、linux/*bsd/solaris/hp(dec)でそれぞれ挙動が違うからねえ
posixもM$がサーバ戦略に本腰いれて慌てて始めたもんだしなあ

220:デフォルトの名無しさん
07/08/05 03:22:10
set_terminate ってどういう場合に使う？
main で全ての例外補足してから異常終了した方が
ローカル変数のデストラクタが呼ばれていいと思うんだけど。

221:デフォルトの名無しさん
07/08/05 03:24:59
そういうまともな例外処理が出来ないときのためにあるのでは

例外処理中に例外が出たとか

222:デフォルトの名無しさん
07/08/05 03:27:03
>>220
２行目以降の意味がわからん。 set_terminate() 関係ないだろ。

223:デフォルトの名無しさん
07/08/05 03:36:23
>>221
ああ、二重例外に対応する場合か。なるほど。

224:デフォルトの名無しさん
07/08/05 12:41:24
VS2005 MFCなんだけど、アクセスバイオレーションの例外処理を
捕らえたいんだけど、
try{}
catch( ... ){}
この構文では捕えられないんだけど、どうしたらいい？

225:デフォルトの名無しさん
07/08/05 12:44:09
アクセスバイオレーションて単純にソフトウェアのバグじゃないか？ｗ

226:デフォルトの名無しさん
07/08/05 12:54:51
/EHaとか/EHcがらみじゃないの？

でもデフォルトから変更した場合、
ミドルウェアとか依存するライブラリ絡みの整合性が心配だな。

227:デフォルトの名無しさん
07/08/05 15:14:37
URLﾘﾝｸ(msdn.microsoft.com)
まあC++の範疇じゃないな。

228:デフォルトの名無しさん
07/08/06 06:55:48
構造化例外で捕まえた方が良いと思うヨ。

229:デフォルトの名無しさん
07/08/06 18:19:11
_set_se_translatorという手もある。
いずれにせよVC++くらいしか使えるものがないというのに変わりはないけどな。

230:デフォルトの名無しさん
07/08/06 21:25:46

スレ違いだったらすいません。

アプリ開発の依頼スレが見つからなかったのでこちらに書かせて頂きました。
当方所有のウェブアプリケーションソフト
（以前プログラマに依頼して作ってもらったものですが今は連絡が取れません）
がＵＲＬ先の変更？で突然使えなくなってしまいました。

そこで、緊急で本日中に改変が出来そうな方是非お願いできないでしょうか？
当方、全くの知識不足で言語が　Ｃ＋＋ということ以外分かりません。
ソースファイルは持っております。料金は２万円でお願いします！

seishinkeiki@hotmail.co.jp

231:デフォルトの名無しさん
07/08/06 21:29:58
マルチはよくないな

232:デフォルトの名無しさん
07/08/06 21:47:57
やすっ

233:デフォルトの名無しさん
07/08/06 23:11:47
>>230
ソースがあるならソースを晒せよ。ロハでできるぞ。
ソースを晒せないから有料でということなら、2万円なんて人を見下したようなことをするもんじゃない。

234:デフォルトの名無しさん
07/08/07 06:33:04
void foo(char *p, size_t len)
{

}

235:デフォルトの名無しさん
07/08/07 06:34:28
すみません途中で送信してしまいました。

void foo(char *p, size_t len)
{
// ここでpとlenからistreamを作りたい
}

実際には、basic_istreamの派生クラスを作るしかないのでしょうか？

236:235
07/08/07 06:44:00
最初は、std::istringstreamを使って実装していたのですが、バイナリを扱う必要があるので、見送りました。

237:デフォルトの名無しさん
07/08/07 07:39:56
俺判定

↓エスパー１級

238:デフォルトの名無しさん
07/08/07 07:48:18
>>236
ファイルストリーム以外でバイナリとテキストの問題なんて起こらないだろ？
istringstream でいいと思うよ。

239:デフォルトの名無しさん
07/08/07 07:50:42
>>236
なんでバイナリを扱う必要があったら istringstream を見送るの？

240:デフォルトの名無しさん
07/08/07 09:01:36
stringという名前が付いてるからバイナリは扱えないと思っているんだろうな

241:デフォルトの名無しさん
07/08/08 20:13:23
義務教育もしっかり受けてるのに
x = x +1
が疑問でもなんでもない俺は負け組

242:デフォルトの名無しさん
07/08/08 20:15:25
柔軟な思考は大事
固定観念はよくない

243:デフォルトの名無しさん
07/08/08 21:16:13
もう疑問を持ったかどうかすら覚えてないわ

244:デフォルトの名無しさん
07/08/08 21:57:28
>>241
x = x * x + Cならマンデルブロ集合なんだけどね。

245:デフォルトの名無しさん
07/08/09 10:46:54
>>241
むしろそのへんの切り替えが高速にできない子は算数のできない子

246:デフォルトの名無しさん
07/08/09 19:51:16
リアル演算子オーバーロードだよな。

247:デフォルトの名無しさん
07/08/09 19:59:43
要は「今まで習った常識・ルール」に囚われてしまっていて、
新しいルール、新しい前提の上でのゲームには一歩も踏み出せないってことだからな

その程度の頭の柔軟性が無いのでは算数やプログラミングに限らず
何やってもだめ

248:デフォルトの名無しさん
07/08/10 09:40:31
何でも受け入れるのもあれだけどな。
そこに疑問を持ち、考察し、納得する、というプロセスをだな・・・

249:身の程知らず
07/08/10 12:01:33
C++の文法に疑問を持つのは、よほどの天才か身の程知らずのどちらかだろ。
もちろんもっと人間にもコンパイラにも分かりやすくて、すばらしい文法は作れただろうが、
今のような位置を占めているかどうかは疑問だ。

以下、俺様演算子を定義できる機能とか、
Cのプリプロセッサなんかより、もっとプログラマブルで、文法を考慮するマクロとか、
↓禿のお気に入りだったマルチメソッドなどについて語ろう↓

250:デフォルトの名無しさん
07/08/10 12:04:48
＞以下、俺様演算子を定義できる機能とか、
演算子オーバロードではお気に召しませんか?

＞Cのプリプロセッサなんかより、もっとプログラマブルで、文法を考慮するマクロとか、
C99のプリプロセッサではお気に召しませんか?

それならDをどうぞ。

251:デフォルトの名無しさん
07/08/10 12:06:05
Lispじゃねぇの

252:デフォルトの名無しさん
07/08/10 12:10:18
開発当時はのんびり言語仕様考えるヒマなかったんだろう。
シェア争いを制するために時間を惜しんだんだろ
結局当時は高級言語に負けたが。

253:デフォルトの名無しさん
07/08/10 12:11:29
俺様演算子っていうと、Prolog みたいなやつか。

254:デフォルトの名無しさん
07/08/10 14:42:56
俺様演算子っていうと、Haskell みたいなやつか。

255:デフォルトの名無しさん
07/08/10 14:58:06
Forth なら何でもありだな

256:デフォルトの名無しさん
07/08/10 15:05:03
禿は演算子オーバーロードは必要最小限に抑えたほうが良いと言ってなかったか

257:デフォルトの名無しさん
07/08/10 15:54:28
おまいは禿が死ねって言ったら死ぬのか？

258:デフォルトの名無しさん
07/08/10 16:32:06
詭弁のガイドライン

259:デフォルトの名無しさん
07/08/10 17:05:23
おまいは「おまいは禿が死ねって言ったら死ぬのか？」ってレスを見たら詭弁だと短絡的に思うのか？

260:デフォルトの名無しさん
07/08/10 17:07:20
次の相談者の方、どうぞ↓

261:デフォルトの名無しさん
07/08/10 17:10:30
禿はC++に関しての第一人者だけど、死に関しての第一人者じゃない。
詭弁じゃないと言うなら、何をもって
「禿は演算子オーバーロードは必要最小限に抑えたほうが良いと言ってなかったか」
「おまいは禿が死ねって言ったら死ぬのか？」
というのが同じ重みがあるとするのかを明確化しろ。

262:デフォルトの名無しさん
07/08/10 17:44:52
物事の良し悪しは他人任せにせずに自分で考えましょう、
と注意する場合の定型句だと思うが。

263:デフォルトの名無しさん
07/08/10 18:16:58
ならそう書けばいいんじゃないかなw

264:デフォルトの名無しさん
07/08/10 18:21:40
なんでも平たく書き下すんじゃなく、
慣用句等あれば使うのが文化って奴だろ
その点APLなんかすごいぞ

265:デフォルトの名無しさん
07/08/10 18:26:07
論点ずらしの天才

266:デフォルトの名無しさん
07/08/10 18:34:21
演算子と人の生死を結びつけるところが正直よく分からん

267:身の程知らず
07/08/10 18:45:10
禿があれほどD&Eで多くのページを割いて、規格に入らなかったことを悔しがっているのに、
一言も突っ込まれないマルチメソッド哀れ。

まあ、正直言ってまず使わないと思うけど。

268:デフォルトの名無しさん
07/08/10 19:05:50
（動的）マルチメソッドマジ欲しい。
Lokiにもマルチディスパッチの実装あるけど、さすがに面倒だ。
でも、コンパイラの実装大変そうだよね。

演算子オーバーロードはPEGとかEBNFを実装するためにあると思うんだ。

269:デフォルトの名無しさん
07/08/11 12:00:15
質問があります。
class A
class B
class C
があるとして、class Cをclass AとBのメンバに持たす時、
class AとBのインスタンスを複数作った場合、メンバであるclass Cも
複数作成されてしまうと思います。
そこで、classA、B共に一つずつしかclass Cを作らないようにしたいのですが、
こういう場合はstaticメンバ変数にするしかないのでしょうか？
ていうのも、static変数はクラス外に宣言を書かないといけないためclass A,Bみたいなクラスを
たくさん作ると大変なんですよね・・・。
class A,Bの基底クラスに持たすことはできませんし・・・

良い方法があればご教授ください。

270:デフォルトの名無しさん
07/08/11 12:27:32
つ静的局所変数

271:デフォルトの名無しさん
07/08/11 12:45:41
>>269
CRTP が使える場面かもしれない。
でも、そんなに静的変数が要るのかどうかが疑わしい。
クラス外に定義が必要なのが嫌だというのも理解しかねる。

272:デフォルトの名無しさん
07/08/11 16:51:02
template<UINT　nID>.
class　Base
{
　static　C　s_c;
};
template<UINT　nID>
C　Base<nID>::s_c;

class　A　:　public　Base<0>
{};
class　B　:　public　Base<1>
{};

273:269
07/08/11 19:13:13
>>270-272
返事が遅れてしまい申し訳ありませんでした。
レスありがとうございます。

CRTPってデザインパターンの一種みたいですね。
>>272のソースがCRTPなのでしょうか？
面白そうなので試してしみようと思います。

274:デフォルトの名無しさん
07/08/11 19:43:47
それは全然違う。
CRTPはベースクラスが、継承クラスの型を知ること

275:269
07/08/11 19:55:41
>>274
なるほど。どもです。
ちょっとググって来ます。

276:デフォルトの名無しさん
07/08/11 23:40:11
CRTPてこんなの

　　template<class derived_t>
　　class TLogPolicy {
　　public:
　　　 void log() { log_ += (static_cast<derived_t*>(this))->data_ + "\n"; };
　　protected:
　　　 TLogPolicy() {};
　　private:
　　　 std::string log_;
　　};
　　class TManager : public TLogPolicy<TManager> {
　　public:
　　　 void test() { log(); };
　　private:
　　　 std::string data_;
　　　 friend TLogPolicy<TManager>;
　　};

けっこう有名なテクニックだとおもうけど？

277:269
07/08/12 02:50:34
>>276
ありがとうございます。
まだ、実装はしてませんが、>>276さんのソースを弄った感じ私が求めてたモノかもしれませんｗ
ただ、1行目のtemplate<class derived_t>って言うのがよく分からないのですがなんなのでしょうか？？

278:デフォルトの名無しさん
07/08/12 03:00:57
>>277
ごく普通のテンプレート宣言だよ。これぐらいは調べてくれ。

279:デフォルトの名無しさん
07/08/12 03:03:18
>>278
あ、なるほど、template<class T>みたいなもんですかｗ
てっきり、特殊なことやってるのかと思いましたｗ
すいません。

280:269
07/08/12 15:09:02
また、質問させていただきたいのですが、>>276さんのソースを簡易化して、
template<class derived_t>
class TLogPolicy {}
class TManager : public TLogPolicy<TManager> {};
class UManager : public TLogPolicy<UManager> {};
class Cont {
std::list<TLogPolicy *> cont;
template <class derived_t>
void add(TLogPolicy<derived_t> *hoge) {
cont.push_back(hoge);
}
};
として、TManager,UManagerのインスタンスを複数作り、
Contクラスのcontに格納したいのですがどうすればいいのでしょうか？
とりあえず、1つのコンテナで管理したいのです。
実際、追加しようとすると、変換できないなどとエラーがでます。
TManagerの適当なメンバ関数から、Cont::add<TManager>(this);
よろしくお願いします。

281:デフォルトの名無しさん
07/08/12 15:15:38
>>280
コンテナに入れたいだけならもういっこ基底クラスを置くだけでいいだろう。
コンテナの要素に対して何をしたいのかによっては、それじゃ不満だろうが。

ソース貼るなら、ちゃんと問題（エラー）が再現できるコード作れよ。

282:デフォルトの名無しさん
07/08/12 15:50:20
どうもtemplateとclassの関係を判っていないようだな。
テンプレートのポインタ（TLogPolicy *）なんてのは無いよ。

TLogPolicy<TManager>とTLogPolicy<UManager> は別の型だから、
同じ基底クラスとして扱うことは出来無いし。

面倒だから簡単にboost::anyのコンテナ使う手もあるかね。

283:269
07/08/12 19:54:07
>>281-282
レスありがとうございます。

>ソース貼るなら、ちゃんと問題（エラー）が再現できるコード作れよ。
申し訳ありません。以後気を付けます。

templateとclassの関係などもうちょっと勉強し、
レスを参考に少し考えてみることにします。

284:デフォルトの名無しさん
07/08/12 23:02:30
>>283
多分コンパイル通そうと尋常じゃない時間を割くと思われるので一つ教えてあげる。

テンプレート関数はこう書く。
template <class T> void foo( T param ) { ... }
テンプレートクラスはこう書く。
template <class T> class bar { T member; };

しかし、クラスにテンプレートの関数(これをメンバテンプレートという)
を書くことはできない。

class hoge {
　　template <class T> void f( T param ) { ... }　// ←コンパイルエラー
}

つまり 280 のコードでやろうとしていることは、そもそも不可能なんだよ。

285:デフォルトの名無しさん
07/08/12 23:16:39
>>284
メンバテンプレートって呼び名が付いてるのに書くことはできないんだ。ふーん。
コンパイラ何使ってるの？

286:デフォルトの名無しさん
07/08/12 23:19:40
たしかVC5か6かなんかでは出来なかっただけ。

287:デフォルトの名無しさん
07/08/12 23:45:41
vc6　では出来る。
が、一部文法が通らないな。

hoge　h;
h.f(1);　//　OK
h.f<float>(1);　//　NG

vc5　は知らん。

288:284
07/08/12 23:46:09
あ゛ぅ、手元のコンパイラでやってみたらできた・・・
>>283 すまん、284 は全くのマチガイ。忘れてくれ m(_ _)m

>>285 VC2005。
>>286 今試したら VC6 ではできた。VC 5 以前はわからんけど。

いぢめないで。。。

289:デフォルトの名無しさん
07/08/12 23:59:00
ちょっと興味が湧いたので実装してみた。

　　template<class derived_t>
　　class TClassData {
　　private:
　　　 template<typename T>
　　　 string& data(T* t) {
　　　　　static string data;
　　　　　return data;
　　　 }
　　　 friend derived_t;
　　};

　　class TManager : TClassData<TManager> {
　　public:
　　　 void set(string const& s) { data(this) = s; };
　　　 string& get() { return data(this); };
　　};

…………しかし、継承使われたりすると危なっかしくてしょうがないな。
TManagerはクラス内クラスにしてファイナル化しといた方が安全そうだ。

290:289
07/08/13 00:01:46
というよりもVC5,6はステだろ。
未だに保守でVC5,6使わされているプログラマは可哀想でしょうがない。

291:デフォルトの名無しさん
07/08/13 00:03:03
class TLogPolicy { public: void foo() { ::std::cout << "Hello"; } };
class AbstractTLogPolicyHolder { public:
TLogPolicy& policy;
AbstractTLogPolicyHolder( TLogPolicy& policy ) : policy( policy ) {}
};
template < class T >
class TLogPolicyHolder : public AbstractTLogPolicyHolder {
static TLogPolicy policy;
public: TLogPolicyHolder() : AbstractTLogPolicyHolder( policy ) {}
};
template <class T> TLogPolicy TLogPolicyHolder<T>::policy;
class Cont { ::std::list< AbstractTLogPolicyHolder* > cont;
public: void add( AbstractTLogPolicyHolder* holder ) { this->cont.push_back( holder ); }
void callAllFoo();
};
void Cont::callAllFoo() {
::std::list< AbstractTLogPolicyHolder* >::iterator i = this->cont.begin();
for( ; i != this->cont.end(); ++i ) { ( *i )->policy.foo(); }
}
class TManager : public TLogPolicyHolder< TManager > {};
class UManager : public TLogPolicyHolder< UManager > {};

void main() {
Cont cont;
TManager t1, t2, t3; // TManager::policy は 1 個だけ存在
UManager u1, u2, u3; // UManager::policy も 1 個だけ存在

cont.add( &t1 );
}

292:デフォルトの名無しさん
07/08/13 00:05:41
>>290
この前、VC3の案件が回ってきて笑った。

293:289
07/08/13 00:15:30
うわ……ありゃc++とは言えないだろう……

良く良く考えたらテンプレートメンバ関数要らんな。
ただ危険にしているだけだった。
　　template<class derived_t>
　　class TClassData {
　　protected:
　　　 TClassData() {};
　　　 string& data() {
　　　　　static string data;
　　　　　return data;
　　　 }
　　};
　　class TManager : public TClassData<TManager> {
　　public:
　　　 void set(string const& s) { data() = s; };
　　　 string& get() { return data(); };
　　};

294:デフォルトの名無しさん
07/08/13 08:35:29
>>293
TLogPolicyとContはどこいった？

295:デフォルトの名無しさん
07/08/13 11:17:36
規格読んでたらよく分かんなくなってきた。

std::complex<double> c = std::complex<double>(1, 2);

とした時、コピーコンストラクタが呼ばれるかどうかに関する規定がよく分からない。

これは「コピー初期化」であって「std::complex<double>(1, 2)がcにコピーされる」らしいんだが、
実際やってみると、どうもコピーコンストラクタは呼ばれない。
この「コピー」というのがコピーコンストラクタを呼ぶことを意味していないのか、
それともコピーコンストラクタを呼ばない最適化が規格で許されてるのか、
どうもよく分からない。

このあたりどうなってるのか詳しく知ってる人はいる？

296:デフォルトの名無しさん
07/08/13 11:22:35
>>295
URLﾘﾝｸ(www.kmonos.net)

297:デフォルトの名無しさん
07/08/13 11:27:38
1)T a = T(...)
2)T a(...)
は同じじゃなかったっけ

298:デフォルトの名無しさん
07/08/13 11:45:31
>>295
つまり、これも戻り値最適化に含まれる、というわけ？

299:デフォルトの名無しさん
07/08/13 12:05:27
>>297
いいえ。前者はコピーコンストラクタが呼ばれる可能性があります。
# >296参照。

300:デフォルトの名無しさん
07/08/13 12:06:17
>>298
正しく、RVOですね。

301:デフォルトの名無しさん
07/08/13 12:07:59
規格には何箇所かコピーコンストラクタの省略を許す箇所が挙げられている。
戻り値最適化もコピー初期化時の省略もそのひとつ。

って、他にあったっけ？

302:デフォルトの名無しさん
07/08/13 12:09:56
>>300-301
これで安心して眠れます。
まだ寝ないけど。

303:デフォルトの名無しさん
07/08/13 12:10:44
>>295
これかしらん？

URLﾘﾝｸ(web.archive.org)
ここの最後の方

＞ -15- Whenever a temporary class object is copied using a copy constructor, and this object and the copy have the same cv-unqualified type,
an implementation is permitted to treat the original and the copy as two different ways of referring to the same object and not perform a copy at all,
even if the class copy constructor or destructor have side effects.

304:デフォルトの名無しさん
07/08/13 12:22:55
>>303
おおー。それですね。完璧ですね。

305:デフォルトの名無しさん
07/08/13 12:31:03
規格 8.5.14 内のここは？

if the function is a constructor, the call initializes a temporary of the
destination type. The result of the call (which is the temporary for the
constructor case) is then used to direct-initialize, according to the rules above,
the object that is the destination of the copy-initialization. In certain cases,
an implementation is permitted to eliminate the copying inherent in this
direct-initialization by constructing the intermediate result directly into the
object being initialized;

306:デフォルトの名無しさん
07/08/13 13:07:44
>299
ええ？ >297の通りじゃ……と思ってC++STDを確認しました。
8.5 Initializers
(snip)
initializer:
　 = initializer-clause
　 ( expression-list )
initializer-clause:
　 assignment-expression
　 { initializer-list ,opt }
　 { }
initializer-list:
　 initializer-clause
　 initializer-list , initializer-clause
ということで、>297の通りじゃね？良くわからないけど。

307:デフォルトの名無しさん
07/08/13 13:12:39
>>306
「ということで」じゃねーよ。何を確認したんだよ。

= に続けて置かれた初期値の型が同じなら、動作上は direct-initialization と
同じに最適化されるが、意味上は依然として copy-initialization なので、
たとえばコピーコンストラクタが private になってたりすると >>297 の 1 は
コンパイルエラーになる。

308:306
07/08/13 14:06:53
あれ？そうだっけ？ということでもうちょっと調べてみました。
過去ログにあった。
URLﾘﾝｸ(ir9.jp)
条件付きで同じになるっつうのが正解かしらん？

copy-initializationとdirect-initializationについて纏まっている資料は無いのかね？
More Exceptional C++に載っているみたいだけど……

309:デフォルトの名無しさん
07/08/13 14:56:26
ためになるなあ

310:デフォルトの名無しさん
07/08/14 01:11:10
おもしろいな、copy constructorへのaccess checkがかかるけど、
実際にはdirect-initializationが行われる（よばれる）のか

class Nurupo
{
private:
//public:
　Nurupo(const Nurupo&) {
　　*(int*)0 = 0;
　}
public:
　Nurupo(int nurupo1, int nurupo2, int nurupo3) {
　　;
}
};

void foo() {
　Nurupo nurupo = Nurupo(1,2,3);
}

private:だとコンパイルエラーになるが、
public:にして実行しても落ちるわけではない

でさ、これもRVOって呼ぶの？returnしてないのに？

311:デフォルトの名無しさん
07/08/14 01:53:47
>>310
これは RVO とは呼ばない。

312:デフォルトの名無しさん
07/08/14 01:55:03
>>308
規格のドラフトでいいんじゃないの？ >>2

313:デフォルトの名無しさん
07/08/14 02:39:08
JIS に行けばドラフトじゃなくてちゃんとしたのを一応読める。色々と不便ではあるけど。

314:デフォルトの名無しさん
07/08/14 02:45:47
日本の未来に絶望する配布形式

315:デフォルトの名無しさん
07/08/14 08:29:54
不要なものは使いにくくなっている
C++的には正しい配布形式

316:デフォルトの名無しさん
07/08/14 10:19:47
const int i[10];
という配列をメンバーに持っていた場合、どうやって初期化すればよいのでしょうか？　

317:デフォルトの名無しさん
07/08/14 10:21:52
>>316
できません。 const 外すか、パフォーマンスに問題なければ std::vector を使うか。

318:デフォルトの名無しさん
07/08/14 10:23:08
int i[10]; という配列をメンバーに持つクラス X を作って、
const X x; として、その x のコンストラクタで初期化する。

319:デフォルトの名無しさん
07/08/14 10:40:09
残念ながらコンストラクタ内で代入することになるね。

320:デフォルトの名無しさん
07/08/14 23:11:20
ご意見伺いたいです。

C++にてシングルトンを実装するに当たって、インスタンスの解放を明示的に実装しますか？

私は、実装します。
プログラムの終了まで存在するものとしても解放するべきだと思っています。

実装しないという人の理由が、解放される順番が難しい、
というのですがそれは理由にはならないのではと。

解放しない派で、もっとこう積極的な理由があるなら教えてください。

321:デフォルトの名無しさん
07/08/14 23:19:43
明示的な解放が必要ってことは
static HogeClass *s = new HogeClass;
return s;
とかするのか？

322:デフォルトの名無しさん
07/08/14 23:25:57
Modern C++ Design読め。

言語に頼れるのならば任せるのがベターだろうと思うよ。
それができない（例外的な）ケースのときだろうね。明示的に実装することを考えるのは

323:デフォルトの名無しさん
07/08/15 02:20:59
mallocしたメモリは確実に解放しますか？

私は、解放します。
プログラムの終了まで存在するものとしても解放するべきだと思っています。

324:デフォルトの名無しさん
07/08/15 03:29:48
だからModern C++ Design読めって。そもそもmallocなんか使わないよ。
ローカル関数内のstaticオブジェクトを使うのが簡単じゃない？

325:デフォルトの名無しさん
07/08/15 04:20:38
「リソースは解放する」「順序は守る」「両方」やらなくちゃならないのがのC++のつらいところだな。

326:デフォルトの名無しさん
07/08/15 05:39:13
シングルトンの解放に関する話は結構ややこしいからな。
Modern C++ Design 読め、で済ますしかない。

327:デフォルトの名無しさん
07/08/15 07:29:15
機械翻訳のような妙な日本語。

328:デフォルトの名無しさん
07/08/15 08:00:51
>>323
C++でmalloc()使う方がどうかしている。

329:デフォルトの名無しさん
07/08/15 08:43:20
>>324 >>328
有名な「malloc/free論争」と同じ
不毛な議論だということを述べているのだと思うが

330:デフォルトの名無しさん
07/08/15 08:46:56
不毛も何も、C++ならnew/deleteがあるのだからmalloc()なんて使わないだろって話だが。
そんなに毛が欲しければCを使っていればいいだけのことだ。

331:デフォルトの名無しさん
07/08/15 09:25:19
論点はmallocかnewか、ではなく
newしたものは必ずdeleteする必要があるか、という点なのだけど。

「mallocではなくnew」などというのは、本質を外れた揚げ足取りに過ぎないと
気が付いているんだろうけど、引っ込みがつかないんだろうね。

332:デフォルトの名無しさん
07/08/15 09:33:22
相手が呆れて去っていきさえすれば勝ちだから、そりゃあ頑張るさ。

「勝者とは強い者のことを言うのではない、戦場に最後まで立っていた者のことを言う」
と、妖魔司教ザボエラ様も仰ってる。

333:デフォルトの名無しさん
07/08/15 09:48:46
deleteするか否かは時と場合による。

334:デフォルトの名無しさん
07/08/15 10:04:49
placement new なら delete しない代わりにデストラクタ呼ぶ、という話か？

335:デフォルトの名無しさん
07/08/15 10:34:09
時と場合で移り気なの

336:デフォルトの名無しさん
07/08/15 10:34:36
スマートポインタ使えよ
RAIIの原則に従っておけば何も考えなくていいんだから

337:デフォルトの名無しさん
07/08/15 10:41:01
newしたらdeleteするのは当たり前だが、mallocしたものはfreeしないと言うこともあるかも知らん。

338:デフォルトの名無しさん
07/08/15 11:10:57
あーあ、mallocやっちゃった。スレタイ読めない馬鹿発見。

339:デフォルトの名無しさん
07/08/15 11:13:18
というのは、レスが読めてない馬鹿の言うことなんだけどね、この場合。

340:デフォルトの名無しさん
07/08/15 11:20:33
delete はデストラクタ呼ぶから、free とは問題が別だよという話だろう。

341:デフォルトの名無しさん
07/08/15 12:09:46
newしたメモリは確実に解放しますか？

私は、解放します。
プログラムの終了まで存在するものとしても解放するべきだと思っています。

342:デフォルトの名無しさん
07/08/15 12:15:10
あーあ、newやっちゃった。スレタイ読めない馬鹿発見。

343:デフォルトの名無しさん
07/08/15 12:31:17
ティンコティンコティンコ

344:デフォルトの名無しさん
07/08/15 12:38:33
デストラクタでOSが自動でやる以上に何か意味のある仕事をするんなら
勿論deleteすべきだろうな

345:デフォルトの名無しさん
07/08/15 12:48:37
RAIIとかリソース所有の概念を知らないやつが混ってるな。
C++必須の概念のはずなのに、知らないやつってホント多いよな。

346:デフォルトの名無しさん
07/08/15 12:52:51
>>345
決め付けは良くないですyo

347:デフォルトの名無しさん
07/08/15 12:53:03
解放しないとデバッガがメモリリークを報告しまくってうっとうしい

348:デフォルトの名無しさん
07/08/15 12:53:52
>>347
それはデバッガがクソ

349:デフォルトの名無しさん
07/08/15 13:01:34
いずれにせよnewしたメモリは全部スマートポインタに突っ込むのが常識だろ。
今時手動deleteとかありえねえ

350:デフォルトの名無しさん
07/08/15 13:04:15
今時ガベコレも無い言語なんて時代遅れもはなはだしい

351:デフォルトの名無しさん
07/08/15 13:25:50
ライブラリでいくらでも実装できるLispとC++は最高、ということですね？

352:デフォルトの名無しさん
07/08/15 13:40:39
スマートポインタが万能だとでも思ってるんだろうか

353:デフォルトの名無しさん
07/08/15 13:42:58
RAIIあれば大抵は処理できるよ。 >350
ガベコレも結局無限リソース（メモリ）しか上手く処理できないしな……

354:デフォルトの名無しさん
07/08/15 13:44:47
循環参照があっただけでおしまいじゃん

355:デフォルトの名無しさん
07/08/15 14:01:29
シングルトンどうしが循環参照してても解放すべきです。
私はそう考えます。

356:デフォルトの名無しさん
07/08/15 14:29:38
おまえいいこと言うな

357:デフォルトの名無しさん
07/08/15 14:48:33
>354
ちゃんとリソース所有権を考えれば循環参照はめったにおこらない。
まあ、考えるのが面倒だからガベコレに頼りたくなるんだけどね。

>355
どういう状況だよ。シングルトンわかってないだろ。

358:デフォルトの名無しさん
07/08/15 14:49:34
>>355
そんなシングルトンが存在すること自体、設計が変だと思わないか

359:デフォルトの名無しさん
07/08/15 14:51:45
寝具る㌧㌧㌧

360:デフォルトの名無しさん
07/08/15 14:57:57
>>357-358
可哀相なくらい行間が読めないコンビだな。

361:デフォルトの名無しさん
07/08/15 15:35:05
読む気ねぇ。ここはマ板じゃねぇし。なんで技術的な部分以外を気にしなきゃいかんのかね？
いい加減夏厨相手にするのも飽きたなぁ

362:デフォルトの名無しさん
07/08/15 15:51:47
馬鹿を晒すぐらいなら書かなきゃいいのに

363:デフォルトの名無しさん
07/08/15 15:54:14
行間なんてものは要するに書き漏らしただけ
ちゃんと伝えたきゃ書け

364:デフォルトの名無しさん
07/08/15 15:56:26
行間っつーか、ギャグだろ。

365:デフォルトの名無しさん
07/08/16 06:38:10
>>361
日本語でコミュニケーションする能力が
技術的な部分と両輪で機能してない間抜けなぞ問題外。

366:デフォルトの名無しさん
07/08/16 14:56:08
(ﾟーﾟ*)ﾀﾞｯｺ♪

367:デフォルトの名無しさん
07/08/16 15:29:53
reddit 経由「透過的プログラマ指向ガベコレ for C++」
URLﾘﾝｸ(www.open-std.org)

Boehm らによる言語機能としてのガベコレ提案。ちょっと期待。

368:デフォルトの名無しさん
07/08/16 18:15:46
class SUBCLASS {
public:
　　LPSTR& operator[](LPCSTR);
};

class SUPERCLASS{
public:
　　SUBCLASS *subclass;
};

SUPERCLASS aaa;

int main()
{
　　aaa.subclass = new SUBCLASS(hogehoge);
　　return aaa.subclass["bbb"];
}

わけあってmapが使えないので上のようにしているのですが
「error C2107: ポインタでない式に、添字が使われました。」
というエラーが出てしまいます

どのようにすれば解決できますでしょうか？
開発環境はVS2005です
よろしくお願いします

369:デフォルトの名無しさん
07/08/16 18:30:39
あんまり真面目に読んでないけど、とりあえずこうじゃね？
　return　(*aaa.subclass)["bbb"];　

370:368
07/08/16 18:44:26
>>369
どうもー
やってみましたがだめでした

371:デフォルトの名無しさん
07/08/16 18:53:11
>>370
エラーメッセージが変わっただろ｡ちゃんとその辺を書けよ｡
で、戻り値の型がLPSTRなんだから、らreturn文で呼ばずに単独で呼んでみな｡

372:368
07/08/16 19:00:40
>>371
うーんエラーメッセージは変化なしです

373:デフォルトの名無しさん
07/08/16 19:06:17
aaa.subclass->operator[]("bbb")

374:368
07/08/16 19:08:45
>>373
コンパイル通りました
ありがとうございました

375:デフォルトの名無しさん
07/08/16 19:11:26
意味があるかは知らんが、(*aaa.subclass)["bbb"] でコンパイルは通るぞ｡

376:デフォルトの名無しさん
07/08/16 19:11:34
>>373
俺もそうだと思ったけど、関数形式で呼ぶのがなんか嫌だから書かなかった
なんか解決策ないかね

377:371
07/08/16 19:13:21
>>372
そうか? 前者は引き数が合わなくて関数が見つからないが、後者は戻り値の型が合わなくてエラーになると思うのだが｡
つーか、なんでまたmain()のreturnなんかで試すんだ? >371の後半は読んでないのか?

378:376
07/08/16 19:13:31
ああそうか、違和感の理由が分かった。
連想配列にしたくて添え字をオーバーロードしているはずなのに
opreator[]で呼んだら意味を成さなくなっちゃうからだ。

379:376
07/08/16 19:15:59
つうことで解決案

subclassをカプセル化して、参照越しにoperator[]を呼ぶ

380:デフォルトの名無しさん
07/08/16 19:23:44
(*aaa.subclass)["bbb"] でコンパイル通らず、
aaa.subclass->operator[]("bbb") でコンパイル通るってあり得ないと思うんだが。

381:368
07/08/16 19:28:22
>>375
あわわ間違って(*aaa.subclass["bbb"])としちゃってたようです

>>377
エラー部分だけ抜き出そうとして型違いのreturnになってました、ごめんなさい…

>>379
単語の意味がわかってないので検索してやってみます、ありがとうございました

382:デフォルトの名無しさん
07/08/16 19:35:38
でもなんでchar *じゃなくて、char * &なんだろう。
constでないということは、こういうことがやりたいんだろうか。

(*aaa.subclass)[''bbb"] = new char[10] ;

いや、ひょっとしたらこういうことがしたいのか

char * & ptr = (*aaa.subclass)[''bbb"] ;
ptr = static_cast<char *>( realloc(ptr) ) ;

383:デフォルトの名無しさん
07/08/16 20:59:50
class Base
{
public:
Base(int n) {}
};
class Derived : Base
{
public:
Derived(int n) {}
};
これがどうしてダメで、Base::Base()が必要なのか教えてください。

384:デフォルトの名無しさん
07/08/16 21:06:38
親クラスに n を渡すなら、それをちゃんと書かなきゃいけない。

public:
Derived(int n) :Base(n) {}

385:デフォルトの名無しさん
07/08/16 21:06:53
はい？

386:デフォルトの名無しさん
07/08/16 21:07:27
>>383
その例のDerived のコンストラクタは結局 Derived(int n) : Base() {} の省略形だから

387:デフォルトの名無しさん
07/08/16 21:21:45
そのnは親に渡さずに別に使うnかもしれないし。

388:デフォルトの名無しさん
07/08/16 23:12:17
>>383
Derived クラスのインスタンスを生成するときに
Base クラスのコンストラクタを呼び出すからなんだと思います。
コンストラクタを定義していないときはデフォルトコンストラクタが呼び出されるけど
定義してると定義されたものを呼び出すから
この場合は引数のいらないコンストラクタを定義するか
Derived クラスのコンストラクタで
Derived(int n) : base(100) {}
みたいに Base(int n) を呼び出して
引数を渡さないとだめだと思うんです。

初心者なんで間違ってるかもしれません。

っていうか STL 難しすぎでうっ！

389:デフォルトの名無しさん
07/08/16 23:20:25
Baseのコンストラクタにデフォルト値を書いておくのもいいかも

っていうか STL 関係ねー

390:デフォルトの名無しさん
07/08/17 00:01:01
>>388
＞っていうか STL 難しすぎでうっ！
でうっ?

391:デフォルトの名無しさん
07/08/17 00:20:57
唐突にこれを思い出した
URLﾘﾝｸ(www.karakuri-box.com)

392:デフォルトの名無しさん
07/08/17 00:41:05
すいません。釣りではありません。
C++ってどんな局面で使うんですか？
WinアプリならC#使ったほうが圧倒的に楽

393:デフォルトの名無しさん
07/08/17 01:00:07
脳みそ沸かしたいとき

394:デフォルトの名無しさん
07/08/17 01:24:19
Cで先頭アドレスと要素数がわかってるのですが
ForループじゃなくてC++のiteratorに変換してくれるtemplateとかないんですか？

ない場合どのiterator継承すればいいんでしょうか

395:デフォルトの名無しさん
07/08/17 01:40:46
T*head; size_t element;が既知なんでそ？
なら、&head[0]～&head[element]がiteratorの要件を満たしてくれるでそ？

396:デフォルトの名無しさん
07/08/17 01:48:01
>>392
楽かどうかなら C# が楽だろうが、
C# は Windows にしか優しくないし、
速度も C++ に劣るし、
そういうのが必要な時には C++ が圧倒的有利。

397:デフォルトの名無しさん
07/08/17 02:19:58
速度が必要になるようなミッションクリティカルな場面に出会ったことがない
最近は全部C#。

398:デフォルトの名無しさん
07/08/17 02:21:20
サーバーアプリだとC#?ﾊｧ?

399:デフォルトの名無しさん
07/08/17 02:38:29
？

400:デフォルトの名無しさん
07/08/17 03:59:53
つかここ＃かんけーねーし

401:デフォルトの名無しさん
07/08/17 05:58:45
>>392
C#を実装するのに使います

402:デフォルトの名無しさん
07/08/17 12:37:18
>>401が良い事言った

403:デフォルトの名無しさん
07/08/17 21:16:42
なぜ想像力がデスクトップとサーバー位にしか働かないんだ
プログラムが必要な場面はいろいろあるぞ

404:デフォルトの名無しさん
07/08/17 21:39:47
class CFUNC a;
の2次元配列を動的に確保する場面があって、
CFUNC ***pppa;
として使いたいですが、
pppa = new CFUNC**[y_len];
でまずy要素を確保して
pppa[0] = new CFUNC*[x_len];
各y要素のx要素を確保して
pppa[y][x] = new CFUNC();
で、各要素をインスタンス化して
(*(pppa[y][x])).hoge();
みたいに使おうと思うのですが、このpppaを破棄する場合に
deleteはどう書いたらいいのかわからなくなってしまいました。。。どなかたpppaをdeketeしてもらえませんか？
ちなみによくしらないのですが、delete[]ってなんで配列の要素数がわかるんですか？

次ページ