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

C++相談室 part61 ..

446:デフォルトの名無しさん
08/04/09 19:32:09
>>443
ゲームとかms単位が命取り
ms以下単位だったら考えてやる

447:デフォルトの名無しさん
08/04/09 19:34:04
μに縮まったとしてもまだでかいだろ。

448:デフォルトの名無しさん
08/04/09 19:42:54
数値計算とかやったことないんだろうなあ。

449:デフォルトの名無しさん
08/04/09 19:48:47
>>441
そういうファイル構成はC++では一般的。
その同名のヘッダーを読み込みば、十分アクセスできるはず。その前任者のソースをよく読んでC++を勉強すること。
C++はexternを滅多に使わないからね。

450:デフォルトの名無しさん
08/04/09 19:55:45
XBOX３６０のゲームは全部C#で書かれてるだろ

451:デフォルトの名無しさん
08/04/09 19:57:04
>>443
全然やばくない。世界はもっと広い。

452:デフォルトの名無しさん
08/04/09 20:26:56
>>439
T::something が型でも値でもコンパイルできてしまう場合は困るでしょう?
多分どちらかは間違っているんだから

453:デフォルトの名無しさん
08/04/09 21:06:55
>>450
んなわけないだろ

プロがXNAで開発してるとでも思ってるのか？

454:デフォルトの名無しさん
08/04/09 21:56:02
思ったｗ

455:デフォルトの名無しさん
08/04/09 22:26:41
.netフレームワークを要求する商用アプリで動きが機敏なアプリをいまだかつて見たことないな。

456:デフォルトの名無しさん
08/04/09 23:32:25
多言語からc++を呼ぶインターフェイスで
std::cout
がおかしくなる原因になってるらしくなんとかしたい
#define __streambuf なにか
にできればいいのだけど voidに置き換えるとコンパイルとおらない
何か適当なクラスでもないでしょうか？

457:デフォルトの名無しさん
08/04/09 23:38:17
ios::sync_with_stdio で解決されるような問題じゃなくて？

458:456
08/04/10 00:12:16
他言語の処理系がstdcoutをすでにリンクしているのに
さらにその処理系から呼び出すcのプログラム中でもリンクしてるのが
問題なってる可能性があるような気がしています

なので
#define __streambuf Hoge
できると多分うまくいくのではないかと

459:デフォルトの名無しさん
08/04/10 00:17:47
XNAなめんな

460:デフォルトの名無しさん
08/04/10 00:22:13
>>456
多言語から呼び出すってっ、もしかすると他言語からDLL呼び出しすることってことかな？
だったらライブラリの初期化がうまく言ってないんじゃないか？dllmainはこねこねした？

461:デフォルトの名無しさん
08/04/10 00:23:42
あと、DLLはマルチスレッドライブラリでコンパイルだよ。

462:456
08/04/10 00:24:19
>>460
正確にはlibhoge.soを呼んでます
libhoge.soがstd::stream関係をリンクしてます

463:460
08/04/10 00:27:49
linuxでしたか。>>460はwinの場合の注意事項でした。

464:デフォルトの名無しさん
08/04/10 07:50:43
>>461
MTでコンパイルしないといけない決まりでもあるの？

465:デフォルトの名無しさん
08/04/10 08:21:08
>>464
ある。
DLLをコンパイルするときはMTでする必要がある。プロジェクトの作成でDLLを選択すると自動的にマルチスレッドランタイムライブラリが選択される。
呼ぶ側はどっちでもいい。

466:デフォルトの名無しさん
08/04/10 11:49:02
>>465
何の処理系の話か知らないがVisualC++なら
シングルスレッドのランタイムの静的ライブラリをリンクしたシングルスレッド専用のDLLを普通に作れる

467:デフォルトの名無しさん
08/04/10 11:57:21
端で見てて想像した通りの食い違い方ｗ

468:デフォルトの名無しさん
08/04/10 12:10:14
初歩的な質問で申し訳ないんだが、他言語から C++ の
ライブラリを使って問題無いはず、という保証はあるんだろうか？

あと、普通に C++ で呼び出すとかなぜしないのだろうか。
（これは状況がわからんとなんとも言えないけど）

469:デフォルトの名無しさん
08/04/10 14:18:03
operator==() の定義はクラスの中とクラスの外に置けますがどのように
使い分けるのでしょうか?

std::type_info はクラスの中でその他はクラスの外が多いのですが。

470:デフォルトの名無しさん
08/04/10 15:34:04
別にoperator==()に限らずメンバ関数は中にも外にも置けるけど。

471:デフォルトの名無しさん
08/04/10 17:04:36
ﾌﾟﾌﾟ

472:デフォルトの名無しさん
08/04/10 17:05:09
ﾍﾟﾍﾟ

473:デフォルトの名無しさん
08/04/10 17:30:44
== どうするかは状況によるんでは。無理無く member にしないで
いいならそうすればいいような気がするが。中身の情報が必要な
場合に member にしてるんじゃないの？普通に生じる状況だと思うけど。

474:デフォルトの名無しさん
08/04/10 17:43:05
メンバに出来るものは中に書く。
メンバに出来ないものは外に書く。
以上。

475:デフォルトの名無しさん
08/04/10 18:05:52
c++のエラー出力の文字コードがutf-8になっているのですが、
euc-jpにする方法ありますか？
Linuxのeuc-jp環境でプログラミング行っており、
gcc version 4.1.2 です。

476:デフォルトの名無しさん
08/04/10 18:18:07
iconv

477:デフォルトの名無しさん
08/04/10 18:40:50
ロケール切り替えろとしか

478:デフォルトの名無しさん
08/04/10 19:06:32
public 関数だけで実装できる場合は非メンバーにする。
friend を使って非メンバーにすることもある。

479:デフォルトの名無しさん
08/04/10 20:50:36
式の対称性が必要なら非メンバー

480:デフォルトの名無しさん
08/04/10 20:59:53
自身への参照を返すことが期待されるか、自身を変更する場合は、メンバーにすることが漏れは多いな。
operator=, +=等はメンバに。operator==, <<, +等は非メンバ（場合によってはfriend）にしてる。

481:デフォルトの名無しさん
08/04/10 21:08:54
op == あたりの話はeffective C++に書いてなかった？
もう忘れちゃったけど。
グローバルにop ==を置くことでカプセル化が上がるとか
その話とはまた別？

482:デフォルトの名無しさん
08/04/10 21:20:10
friend はできれば避けた方が良いというの無かったっけ？

483:デフォルトの名無しさん
08/04/10 22:12:02
C++ Coding Standards の 44 には
「できるだけ非メンバーかつ非 friend の関数を書くようにしよう」
というのがありました。

484:デフォルトの名無しさん
08/04/10 22:19:02
C++の本質はやっぱプリプロセッサとテンプレートだろ･･･
オブジェクト指向なんてうんこ

485:デフォルトの名無しさん
08/04/10 23:00:41
プリプロセッサはちょっと違うだろ・・・
現実的にメタプログラミングするのには必要だけど。
個人的にはデストラクタを推すね。

２行目は同意。

486:デフォルトの名無しさん
08/04/10 23:08:04
デストラクタとはいいところをつくね。
RAII 万歳！

487:デフォルトの名無しさん
08/04/10 23:25:35
friendかな

488:デフォルトの名無しさん
08/04/10 23:58:56
>>485 == >>486 ??

489:デフォルトの名無しさん
08/04/11 00:01:31
デストラクタの価値が分からないうちは
プログラマの資格なしだぜ

490:485
08/04/11 00:03:01
>>488
ID出ない板だからどうしようも無いけど、
違うとだけ。

491:デフォルトの名無しさん
08/04/11 00:14:49
デストラクタはクリティカルセクション解除するのに使ってる。
メモリリークどころの騒ぎじゃない

492:デフォルトの名無しさん
08/04/11 00:17:31
Javaとかどーやってんだ？
デストラクタ

493:デフォルトの名無しさん
08/04/11 00:20:23
Javaはcloseとかdisposeとかメソッド作って
呼び出さないといけないんじゃなかったっけ？

494:デフォルトの名無しさん
08/04/11 00:25:56
Javaはデストラクタ勝手に作ってくれるから。
DB接続とかファイルハンドルにクリティカルセクションだの
なんでも閉じてくれる。

495:デフォルトの名無しさん
08/04/11 00:28:48
前スレから
ｽﾚﾘﾝｸ(tech板:496-番)

496 ：デフォルトの名無しさん [sage] ：2008/02/15(金) 14:44:30
　　つまるところc++ではデストラクタに頼るべき。

497 ：デフォルトの名無しさん [sage] ：2008/02/15(金) 14:54:04
　　C++はつまるところデストラクタのことだからな
　　closeさせといてガベージコレクタがあるとか抜かす言語は笑えるな
　　intは回収できるが巨大なファイルリソースはリークするわけだ

498 ：デフォルトの名無しさん [sage] ：2008/02/15(金) 15:06:22
　　日本語でおk

499 ：デフォルトの名無しさん [sage] ：2008/02/15(金) 15:08:34
　　＞closeさせといてガベージコレクタがあるとか
　　禿げあがる程同意。
　　
　　C#はusing(o1,o2,...){}があるから多少マシだけど、
　　forみたいにusing用のスコープ作るから
　　スコープ違いが混じるとネストして見辛くなる。
　　どう考えてもc++みたいに対象の変数のスコープでDisposeした方が良いと思う。
　　
　　javaのtry-finally-closeに至っては論外。
　　しかもcloseで例外出たらfinally内で潰さないと
　　try内で発生したより重要な例外が消されるし・・・。

500 ：デフォルトの名無しさん [sage] ：2008/02/15(金) 16:33:04
　　＞どう考えてもc++みたいに対象の変数のスコープでDisposeした方が良いと思う。
　　そして言語はC++/CLIへと進化するのであった、まる

496:デフォルトの名無しさん
08/04/11 00:34:08
Javaをはじめ、メジャーな言語のGCはメモリ不足しか認識しないから、
明示的にcloseしない場合、メモリに余裕があればfinalizeは呼ばれず、
DB接続も閉じられない

そしてコネクションプールのタイムアウトで死に始める業務アプリ
鳴り始めるサポートデスクの電話機達

497:デフォルトの名無しさん
08/04/11 00:39:21
まぁJavaなんてマーケット戦略で広まっただけのうんこ言語だからな･･･
プログラマと名乗るくらいならC++くらいできる頭を持って欲しい･･

498:デフォルトの名無しさん
08/04/11 00:59:54
finalize()でリソース解放なんて保険でしかないからな

499:デフォルトの名無しさん
08/04/11 01:00:32
リソース管理で似た話を読んだことある気がしてたけど思い出せた
URLﾘﾝｸ(mag.autumn.org)

500:デフォルトの名無しさん
08/04/11 01:00:40
でもね、C++は巨大で複雑怪奇だからね。Cを引きずってる面もあるし。
無駄を削ぎ落として細部を明確にした言語が望まれるというのもわかるよ。
それとGCの有用性とは別の話だが。

501:デフォルトの名無しさん
08/04/11 01:03:52
実はVBなんかも
リソース周りは優秀だったりする

502:デフォルトの名無しさん
08/04/11 01:26:11
continuationを明示的に扱えない言語はうんこ

503:デフォルトの名無しさん
08/04/11 01:26:35
scheme習いたてですか？

504:デフォルトの名無しさん
08/04/11 01:55:30
>>503
C++習いたてです。

505:デフォルトの名無しさん
08/04/11 07:46:34
C#のusingの使いづらさは異常
scopedとでもして識別子が入ってるブロックの最後でdisposeしてくれたほうがよかった

506:デフォルトの名無しさん
08/04/11 08:50:00
素朴な疑問です。

#include <iostream>
struct S { virtual void hoge() = 0; // 純粋仮想のみ };
struct S1 : public S { void hoge() { std::cout << "S1" << std::endl; }};
struct S2 : public S { void hoge() { std::cout << "S2" << std::endl; }};
int main()
{
　S1 s1;
　S2 s2;
　S& r1 = s1;
　S& r2 = s2;
　r1.hoge();
　r2.hoge();
　r1 = r2; // 基本クラスの参照を代入
　r1.hoge();
　r2.hoge();
　return 0;
}

VC8で上記のコードを実行すると
S1
S2
S1
S2
と表示されました。
r1 = r2;はS::operator=を呼ぶだけなので何も変わらない、と理解したのですが、
これはC++的に正しい挙動なのでしょうか？
それとも未定義でたまたまこうなっているだけなのでしょうか？

507:デフォルトの名無しさん
08/04/11 08:55:40
あ、改行を削ったらコメントをミスりました。
> struct S { virtual void hoge() = 0; // 純粋仮想のみ };
は
> struct S { virtual void hoge() = 0; /* 純粋仮想のみ */ };
です。

508:デフォルトの名無しさん
08/04/11 08:56:43
単純に、自動生成されたoperator=(S, S)で仮想関数テーブルが書き換わらないようになってるだけ。

509:デフォルトの名無しさん
08/04/11 08:57:18
s1, s2のうちSの部分だけがコピーされた、と解釈すればわからんでもない

510:デフォルトの名無しさん
08/04/11 09:00:15
とりあえず解決するには自分でS2 operator=(S, S)を定義すればいいように思えるが、
それはS = Sの一般的な代入に関して考えるとかなり狂っているから諦めろって言う話でっていう

511:デフォルトの名無しさん
08/04/11 12:27:47
>>498
同意。finalizeって呼ばれるとは限らないとか。ほんとに気休め程度だね。

512:デフォルトの名無しさん
08/04/11 13:29:20
>>506
代入や他オブジェクトでの初期化でvptrは変更されない。

513:デフォルトの名無しさん
08/04/11 15:56:17
class A { friend class B; int x; };
class B { class C {}; };

VC8.0 では class C から class A の x が参照できますがこれは C++ の仕様ですか?

514:デフォルトの名無しさん
08/04/11 19:00:01
Cのreadableなプログラムを自動生成するメタ言語みたいなの
ないでしょうか？
readableじゃないのならあるのですが、読めないと意味ないのです

515:デフォルトの名無しさん
08/04/12 16:01:17
具体例を。

516:デフォルトの名無しさん
08/04/12 16:08:22
まともなＣソースも >>514 には、readable じゃなさそうだ...。

517:デフォルトの名無しさん
08/04/13 23:17:27
vector<int>で何個か反復子を進めたあと、
それが今何番目の要素なのかを知る関数はないですか？

518:デフォルトの名無しさん
08/04/13 23:20:51
>>517
std::distance

519:デフォルトの名無しさん
08/04/13 23:21:19
i - v.begin();

520:デフォルトの名無しさん
08/04/13 23:55:08
できました、ありがとうございます。

521:デフォルトの名無しさん
08/04/14 01:34:09
URLﾘﾝｸ(mag.autumn.org)
ここ読むとC++よりもJAVAのほうがリソース管理に関して
優れているように思えるんだけど

522:デフォルトの名無しさん
08/04/14 01:42:17
だから何だよ

523:デフォルトの名無しさん
08/04/14 01:46:30
優れているというかパフォーマンスを犠牲にしてリソース管理の安全性を高めたという方が近いかな。
そんな事いったらC++も保守性を犠牲にパフォーマンスを高める余地のある言語と言えるけど。
ただJavaの場合は“余地”どころかプログラマに選択をさせない完全な“切捨て”であるけどね。
だからプログラマが手段を選択できる余地の残っているC++の方が優れている。終了。

524:デフォルトの名無しさん
08/04/14 01:49:22
手段を選択する必要のある場面においては、だけどな。

525:デフォルトの名無しさん
08/04/14 02:15:33
javaってfinallyの書き方間違えると死ねるしなあ
という話が >>495 にあるよ

jdbcでoracle使ったことがある人は知ってると思うけど、
closeし損ねるとリークしてそのうち動かなくなるんだよね

これを注意深く追ってると、「なんだかCでやってんのと変わらんなあ」
と思うぜ、実際。

526:デフォルトの名無しさん
08/04/14 02:27:32
だってメモリしか管理してくれないもの

527:デフォルトの名無しさん
08/04/14 07:08:37
>521
「RAIIが発明されるまでのC++」については、Javaのほうが
リソース管理が優れていた、と云わざるを得ない、けどねぇ。

528:デフォルトの名無しさん
08/04/14 07:25:04
他のリソースも管理してくれればいいのになあ。
ファイルハンドルが足りない時には
ファイルクラスのインスタンスへのガベコレを
優先的にやってくれるとか。

529:デフォルトの名無しさん
08/04/14 10:47:50
>>527
> 「RAIIが発明されるまでのC++」

って具体的に何を指すの？ RAII ってプログラミング
ポリシーだと思うんだけど。「発明」されたっていまいちピンと来ない。

530:デフォルトの名無しさん
08/04/14 11:04:02
RAII が浸透してない C++ って感じのことを言いたいんじゃないか？
未だに RAII を取り入れない C++ があるとは信じられないのかもしれないが。

531:デフォルトの名無しさん
08/04/14 12:21:55
>>528
デストラクタを活用するべき

532:デフォルトの名無しさん
08/04/14 12:25:18
javaの話だろ

533:デフォルトの名無しさん
08/04/14 12:50:09
>>527
C with class の話ですか？
C++は初期のARMがかかれた頃から散々言われていますけど。

534:デフォルトの名無しさん
08/04/14 18:05:47
>>529
強いて言えば、テンプレートがなかった頃には、
auto_ptrや（削除子付きの）boost::shared_ptrのような
汎用的なものは作りづらかったと思う。

それでも、fstreamみたいに個別に作っていく手があったはずだけど。

535:デフォルトの名無しさん
08/04/14 21:38:58
なんでそこで糞設計のstreamを持ち出すかなー

536:デフォルトの名無しさん
08/04/14 22:33:50
とりあえずデストラクタでcloseしてくれるからいいだろ。
今は糞設計かどうかなんて関係ない。

537:デフォルトの名無しさん
08/04/14 23:13:37
自分のクラスにiteratorをアタッチ
するにはどうすればよいの？

538:デフォルトの名無しさん
08/04/15 00:45:20
>>537
クラスって新しい container 作ってんの？
普通に vector とかにオブジェクト入れて iterator 使うとかいう話
じゃないんだよね？

539:デフォルトの名無しさん
08/04/15 02:36:34
>>537 アタッチの意味がわからん。

540:デフォルトの名無しさん
08/04/15 07:56:33
Rubyみたいにアタッチしたいんだけど
なんでできないの？

541:デフォルトの名無しさん
08/04/15 08:59:06
だからアタッチって何だよ

542:デフォルトの名無しさん
08/04/15 09:20:53
ウラララララーって叫ぶやつじゃね？

543:デフォルトの名無しさん
08/04/15 16:55:57
それは、アパッチ

544:デフォルトの名無しさん
08/04/15 16:56:46
>>543
叫ぶやつはジェロニモだ

545:デフォルトの名無しさん
08/04/15 17:24:27
だってオラは人間だから

546:デフォルトの名無しさん
08/04/15 21:52:48
テンプレートクラスとクラステンプレートの違いを教えてエロい人！！

547:デフォルトの名無しさん
08/04/15 21:58:18
クラステンプレートを使って作られたクラスがテンプレートクラス

548:デフォルトの名無しさん
08/04/15 22:09:23
何か詳しく書かれたサイトがあれば貼っていただきたいです。

549:デフォルトの名無しさん
08/04/15 22:14:51
お前誰だよ

550:デフォルトの名無しさん
08/04/15 22:20:43
つーか言葉にこだわってどーすんの
テンプレート勉強すりゃわかることだろうに

551:デフォルトの名無しさん
08/04/15 22:32:59
ヒントがあれば十分だろ。
自分で考えて解決する楽しさを知らないやつは(ry

552:551
08/04/15 22:33:53
>>551
誤爆しました。ごめんなさい、

553:デフォルトの名無しさん
08/04/15 22:36:31
輪講で必要なんです。
わかりにくかったので聞いてみました。

554:デフォルトの名無しさん
08/04/15 22:43:22
>>552
流れとしてはわりと的を射ている気がするｗ

555:デフォルトの名無しさん
08/04/15 23:01:58
テンプレートクラスはただの間違いだと思う
クラステンプレートが正しい。だってあれはテンプレートだから

クラステンプレートをテンプレートクラスというのは
鉄パイプをパイプ鉄というようなもの

556:デフォルトの名無しさん
08/04/15 23:16:18
>>555さん
わかりやすい表現ありがとうございます。

教科書には
クラステンプレートはテンプレートクラスから導出できる。
クラステンプレートは非テンプレートクラスから導出できる。
テンプレートクラスはクラステンプレートから導出できる。
非テンプレートクラスはクラステンプレートから導出できる。
と書いてあるのですが・・・

557:デフォルトの名無しさん
08/04/15 23:24:08
まずは本の名前を晒してみれ。

558:デフォルトの名無しさん
08/04/15 23:25:34
なんの哲学書だよｗ

559:デフォルトの名無しさん
08/04/15 23:26:56
こんにゃくゼリーに使うこんにゃくをゼリーこんにゃくって呼んでる類だろ。

560:デフォルトの名無しさん
08/04/15 23:26:59
ぐぐってでてきた。これは比較的納得できるかんじ
＞URLﾘﾝｸ(www.ed.kuki.tus.ac.jp)
クラス・テンプレート（class template）
暗黙的にまたは明示的にインスタンスを生成されるか、または特殊化されると、クラス型を作成するテンプレート。

テンプレート・クラス（template class）
クラス・テンプレート（class template）によって生成されるクラス・インスタンス。

561:デフォルトの名無しさん
08/04/16 00:01:31
ソースで出てくる順がtemplate classだから間違えやすいな

562:デフォルトの名無しさん
08/04/16 00:03:46
typename

563:デフォルトの名無しさん
08/04/16 00:49:24
STLに
boost::any相当のものってないよね？

困った困った

564:デフォルトの名無しさん
08/04/16 01:41:23
普通にboost::any使ったら？

565:デフォルトの名無しさん
08/04/16 01:51:09
vectorにデータを追加した時にメモリ確保に失敗した場合、検出する方法ってありませんか？
newでいうbad_allocの例外をキャッチするような感じ。

566:565
08/04/16 02:26:50
解決しました。orz
bad_alloc使えた...

567:デフォルトの名無しさん
08/04/16 03:21:12
>>563
無いなら作れば？
大したもんでもないっしょ。

568:デフォルトの名無しさん
08/04/16 13:24:51
あるアクションゲームをCとC++両方で作りました。
プレイする上で、まったく同じ動作をするものです。

Cでは主に構造体で、C++ではVectorで管理していました。
C++で作ったほうがプログラム実行時のメモリ消費量が多いのですが、
そんなもんでしょうか？

569:デフォルトの名無しさん
08/04/16 13:41:18
そんなもん
完全に同一ソースでもバイナリレベルでは例外処理が入ったり、実行時型判定が入ったりする

570:デフォルトの名無しさん
08/04/16 13:42:03
>>568
Vector は std::vector のこと？
そうなると構造体と std::vector とでは役割が違うので、置き換えれるわけ無いんだけど。

・・・もしかして
struct S { int a, b, c } s;
s.a = s.b + s.c;
これを
std::vector<int> s(3);
s[0] = s[1] + s[2];
にしたってこと？

まぁプログラムが違うんならメモリ消費量が違うのはあたりまえなんで、
あんまり気にしてもしょうがないと思う。同じになるはずっていう根拠でもなければ。

571:デフォルトの名無しさん
08/04/16 13:49:57
配列のことを構造体といい間違えたのではないか。

572:568
08/04/16 14:33:50
配列ですね、すみません。
消費メモリが数十MByte単位で変わってくると、さすがに気になったので質問しました。
C++の設計に改善点がまだあるような気もします。

573:デフォルトの名無しさん
08/04/16 16:51:23
数十MBって、それってC/C++以前にプログラムの構造がおかしいだろ常考

574:デフォルトの名無しさん
08/04/16 17:15:02
> C++で作ったほうがプログラム実行時のメモリ消費量が多いのですが、
これだけ読んだら、普通はもうちょっとささやかな差を想像するよね。
その想像をベースにして皆が一般的なことを回答したところで、いきなり
> 消費メモリが数十MByte単位で変わってくると、
っていう、量に関する新情報を出すっていうのは、広義の「情報小出し質問」だと思うよ。

自分だけが知っている状況を他人に説明するときは、発信する前に
「相手はこの説明に触れて、真っ先にどんなものを想像するだろうか？」
っていう思考を巡らせるべき。

で回答だけど、「構造体とvector」以外に両者のソースがどう違ってるかがわからないと、何とも言えない。
質問文に登場した要素だけで考えるなら、STLの使い方をどこかで根本的に間違えているんじゃないか
って気がするけども。

575:デフォルトの名無しさん
08/04/16 18:22:21
前方反復子のクラスはデフォルトコンストラクタが必要ですけど、
デフォルトコンストラクタで生成した反復子やそれを代入した
反復子に対する操作の結果は定義されているでしょうか?

576:デフォルトの名無しさん
08/04/16 20:42:11
URLﾘﾝｸ(www.asahi-net.or.jp)
このサイトを見ながらC++の基礎を勉強しているのですが、このページのデストラクタのサンプルプログラムを
VC++2008EEに打ち込んでも「消滅しました」のメッセージが出ないのですが、
これはVC++側の処理の問題でしょうか？

577:デフォルトの名無しさん
08/04/16 20:44:49
詳しく読んでないからわからんが、派生クラスで基底クラスのデストラクタが呼び出されないとかなら
virtualが抜けてるからとかそんなんじゃね？

578:デフォルトの名無しさん
08/04/16 20:51:17
まだ始めたばかりの初心者です。。
あまりを出さなくてよい、簡単な割り勘のようなのを作っているのですが、
-
#include<stdio.h>

int main(void)
{
int a,b,c;

/*計算の入力　金額*/
printf("金額を入力してください");
scanf("d%",&a);
/*人数*/
printf("人数を入力してください");
scanf("%d",&b);

/*計算と結果の表示*/
c=a/b;
printf("%d/%d=\t%d\n",a,b,c);

return 0;
}
-
これを実行させると、金額を入力してEnterキーを押した時点で変な数字が出てきてしまいます…
なにか足りない気がしますが、何処がおかしいのでしょうか…？
ご教授よろしくお願いします。

579:デフォルトの名無しさん
08/04/16 20:51:27
どのコードを書いて、どういうメッセージは出たのか、
情報が足りなさ過ぎる。

580:デフォルトの名無しさん
08/04/16 20:52:05
>>579 は >>576 へ

581:デフォルトの名無しさん
08/04/16 20:53:09
>>578
d%

582:デフォルトの名無しさん
08/04/16 20:53:29
scanf("d%",&a);
打ち間違い？

583:576
08/04/16 21:15:39
>>580
スミマセン。。。
//dest_sample.cppのコードをまるっきりそのまま書いて実行したところ、
実行結果例の下２行の「消滅しました」のつく文だけ表示されません。
問題なくコンパイルできますし、上４行の「生成されました」と「呼び出されました」
の付く文は正常に表示されます。
試しに、筆者が書いたものをコピー＆ペーストして実行してみましたが、
やはり「消滅しました」のつく、下２行の文が表示されません。
~Nanika(){
cout << "Nanikaのインスタンス" << datum << "が消滅しました。" << endl;
が完全に無視されているような状態です。

宜しくお願いします。

584:デフォルトの名無しさん
08/04/16 21:29:48
コンパイラは何？

585:デフォルトの名無しさん
08/04/16 21:39:59
namespaceにはまっています。
あるソースファイルのnamespaceで囲まれた関数を別のソースファイルでexternしたいのですが、
どうすればいいかわかりません。コンパイルエラーになります。
名前空間名を付けて呼び出してもだめで・・・。
aaa.cpp-----------------------------------
#include <stdio.h>

namespace hoge
{
void Func()
{
printf("HELLO\n");
return 0;
}
}
bbb.cpp------------------------------------

extern void hoge::Func(); ←コンパイルエラー

void main()
{
hoge::Func() ← コンパイルエラー
Func(); ← コンパイルエラー

return;
}
-----------------------------------------
bbb.cppからaaa.cppの名前空間が見えてないっぽいんですがこんな場合どうしたらいいのかわかりません。
ネットでも検索したのですが、複数ファイルに分ける事ができる記述はあっても
やり方が乗ってないので困ってます。どなたかお願いします。

586:デフォルトの名無しさん
08/04/16 21:41:05
namespace hoge{ extereeeen void Func(); }

587:デフォルトの名無しさん
08/04/16 21:41:27
namespace hoge {
　void Func();
}

int main()
{
　hoge::Func();
}

588:デフォルトの名無しさん
08/04/16 21:45:14
ああ、コンパイラはVC++2008EEか。

589:デフォルトの名無しさん
08/04/16 22:00:46
>>586
bbb.cppでexternする場合はコレもnamespaceで囲んであげないといけないと言うことでしょうか！？
やってみたのですがVC++6.0なせいか hogeがシンタックスエラーを起こしてます。
VC++対応していない？明日会社でやってみます。

>>587
586さんと似てるのですが、externしなくてもよいと言うことでしょうか？
これまたVC++6.0ではhogeがシンタックエラーを起こしています。
明日やってみます。

590:デフォルトの名無しさん
08/04/16 22:56:43
VC6 でも問題はないはずなんだが・・・

591:デフォルトの名無しさん
08/04/16 22:57:30
関数プロトタイプはデフォルトで extern ってのは常識だろ？

592:デフォルトの名無しさん
08/04/16 22:59:45
>>583
VC++2008でやってみたけど、ちゃんと表示されたよ。

593:デフォルトの名無しさん
08/04/16 23:09:05
ひょっとしてNanikaのインスタンスを
グローバルで生成したというオチではないだろうなｗ

594:デフォルトの名無しさん
08/04/16 23:12:02
外部ライブラリのデストラクタの方が後に走るから
グローバル変数にしても cout に問題はないと思う。
というか、グローバルにしても表示された。

595:デフォルトの名無しさん
08/04/17 01:48:09
#include <boost/regex.hpp>

template<typename TChar>
class TCHoge
{
public:
　　typedef boost::basic_regex<TChar>　 regex_type;
　　static int Func(regex_type reg){ return 0; }//ok
　　//static int Func(regex_type::flag_type flag){ return 0; }　　　　　　　　　　 // NG1
　　//static int Func(boost::basic_regex<TChar>::flag_type flag){ return 0; } // NG2
　　static int Func2(boost::basic_regex<char>::flag_type flag){ return 0; }　　 //OK
};

Window2000
Visual C++ 2005 express edition
boost 1.34.1

　NG1 のように記述したいのですが，以下のようなエラーとなってしまいます．

warning C4346: 'boost::basic_regex<charT>::flag_type' : 依存名は型ではありません。
error C2061: 構文エラー : 識別子 'flag_type'

VC6.0 では問題なかったのですが，どのように記述すれば良いでしょうか？

596:デフォルトの名無しさん
08/04/17 02:07:22
×boost::basic_regex<TChar>::flag_type
○typename boost::basic_regex<TChar>::flag_type

だっけ？あまり自信ないや

597:595
08/04/17 03:25:08
>>596 さん，有難う御座います．教えていただいた方法でうまくいきました．

これから typename をつけまくる作業に戻ります…

それでは．

598:デフォルトの名無しさん
08/04/17 03:48:20
>>575
基本的には全部未定義。唯一、デフォルトコンストラクタで初期化したイテレータに、
そうではない値を代入することができる、ってことになるみたい。
24.1p5 の "Iterators can also have singular values ..." あたりにそんなことが
書いてあって、デフォルトコンストラクタで作った Forward iterator は singular value を
持つ（ことがある）とされている。

要するに未初期化のポインタやヌルポインタと同じ扱いってことね。

599:デフォルトの名無しさん
08/04/17 07:27:26
>>597
VC6 だと逆にエラーになるから
もし VC6 でもコンパイルしたいということになりそうなら
後で切り替えられるようにマクロにしといた方がいい。

600:デフォルトの名無しさん
08/04/17 08:28:19
VC6を窓から捨てるのが正解かと
boostでもVC6は切ってるし

601:デフォルトの名無しさん
08/04/17 10:52:55
>>589
プロトタイプ宣言したヘッダファイルを作れ。
つーか、チミのやりかたではnamespaceつくらなくてもアウチなんだけど

602:デフォルトの名無しさん
08/04/17 12:52:38
stlやboostを使っていると、typedefを書く場所に悩みます。
class ClassA { HogePtr pHoge_; };
class ClassB { HogePtr pHoge_; };
この時、typedef boost::shared_ptr<Hoge> HogePtr;はどこに書くのが理にかなっているのでしょうか？
Hoge.h？それともClassA.hとClassB.h？

603:デフォルトの名無しさん
08/04/17 12:56:08
>>602
typedef しないという選択肢は無いのかね？
ほんとに HogePtr に意味があるなら Hoge.h だろうね。

604:602
08/04/17 13:00:36
>>603
すみませんtypedefしない選択肢もありました。
Hoge.hでtypedefするか、typedefしないかの2択ですね。
ありがとうございました。

605:デフォルトの名無しさん
08/04/17 21:40:19
class Hoge {
public:
typedef boost::shared_ptr<Hoge> ptr_t;
};
というのはどうですか?

606:デフォルトの名無しさん
08/04/17 23:27:03
ClassA や ClassB の実装部分を HogePtr の実体から分離するために
typedef 名をつかうってんなら、いっそ
template class <T> class ClassAImpl { typedef boost::shared_ptr<T> Ptr; ... };
で、
typedef ClassAImpl<Hoge> ClassA;
あたりまでやっちゃうのも悪くないと思うよ。

607:デフォルトの名無しさん
08/04/18 01:14:56
inline std::string Reverse( const std::string & src ){
return std::string( src.rbegin( ), std::rend( ) );
}
これくらいシンプルな感じで実装する方法ないですか？

608:デフォルトの名無しさん
08/04/18 01:21:01
ごめん誰か>>607を翻訳して

609:デフォルトの名無しさん
08/04/18 01:29:32
ようするに逆順でイテレーションしたいんだろうさ

610:デフォルトの名無しさん
08/04/18 01:32:28
実装する手間を惜しんでシンプルな設計を考えることは良いことだが、
人に説明する手間を惜しむのは（・Ａ・）ｲｸﾅｲ!!

611:デフォルトの名無しさん
08/04/18 01:40:34
>>608
すいません。>>609ってことです。しかもstd::rend( )って何だよ・・・orz

当然できんだろ、って思ってたらコンパイルエラーになるんすね。
やっぱcopy使うのが一番まともでしょうか？

612:602
08/04/18 01:45:35
>>605
なるほど、それもありましたか。

>>606
ClassAとHogeの分離は考えてなかったです。
考えていたのは、
１、クラステンプレート実体化のコードが長くなるので、stlやboostはtypedefして使うものだと思っていた。
２、shared_ptrを使うという事は、2つ以上のクラス(スコープ)で型を使う事になるので、typedefを1箇所(Hoge.h)にだけ書いて、参照したほうがいいのではないか？
３、しかし、shared_ptrに入れて使うかどうかは、Hoge.hをインクルードして使う側の選択肢であって、使う側の可能性をHoge.hに書いてしまうのはどうか？
といったことで悩んでいました。

613:デフォルトの名無しさん
08/04/18 02:14:07
>>611
よくわからんが std::reverse でも使っとけ

614:デフォルトの名無しさん
08/04/18 02:24:36
世の中にはある程度の割り切りが必要な時だってあるのさ・・・

615:デフォルトの名無しさん
08/04/18 11:03:18
>>611
make_reverse_range(src) // boost::range_ex
src|reversed // pstade::oven

非標準のライブラリ使ってもいいならこんな感じで簡単に書ける

>>612
HogePtrをtemplateにして
template template parameterでboost::shared_ptr等を与える

// hoge.h
struct Hoge { ... };
template< template<typename T> class Pointer >
struct HogePtr {
　typedef Pointer<Hoge> type;
};

// client code
#include "hoge.h"
template< typename T > struct raw_pointer { typedef T *type; };
HogePtr<raw_ptr> raw;

#include <boost/shared_ptr.hpp>
HogePtr<boost::shared_ptr> shared;

これならhoge.hppで#includeしなくてもよくなる筈

616:デフォルトの名無しさん
08/04/18 13:57:34
>>615
×HogePtr<raw_ptr> raw;
○HogePtr<raw_ptr>::type::type raw;
×HogePtr<boost::shared_ptr> shared;
○HogePtr<boost::shared_ptr>::type shared;
ではなくて？

そもそもhoge.hppでshared_ptr.hppの#includeを避けるなら
// client code
Hoge* raw;
boost::shared_ptr<Hoge> shared;
でいいじゃん？

617:デフォルトの名無しさん
08/04/18 22:57:32
>>581
>>582
返信遅くなってしまいました…
そんな単純なミスだったんですね…
ありがとうございました。

618:デフォルトの名無しさん
08/04/19 15:15:17
ベースメンバ初期化で"this"を使用すると警告がでますが、
コンストラクタ内で"this"を使っても警告も何も出ないけど大丈夫なんですか？

警告が出てるのはインスタンスが生成されていることが保証されて無い状態で
そのポインタを読んでいることが原因になっていると考えているのですが、
だとすると、コンストラクタ内で使っても同じことですよね。

警告が出ないのは、そのポインタの先を使用しなければおｋって事なんですかね・・。

619:デフォルトの名無しさん
08/04/19 15:20:45
コンストラクタ内ではメンバの実体は既に生成されているから問題ない
どんな値がはいってるかは知らないけどね

620:618
08/04/19 15:58:08
>>619
>>コンストラクタ内ではメンバの実体は既に生成されているから問題ない
なのに
>>どんな値がはいってるかは知らないけどね
とは？

実体は生成されているけど、thisが指しているのはどこか分からないよ
ってことですか？
それとも、実体の中身に何が入っているか分からないよってことですか？

621:デフォルトの名無しさん
08/04/19 16:00:42
ポインタの先を使用しなけりゃ大丈夫。

622:618
08/04/19 16:12:46
>>621
ってことは、コンストラクタでメンバ関数のアドレスを引き渡すのも危ないってことですよね。

623:デフォルトの名無しさん
08/04/19 16:14:00
コンストラクタ内でそのメンバ関数のアドレスを使わなければ大丈夫。

624:618
08/04/19 16:18:31
>>623
なるほど。理解しました。
どうもありがとうございました。

625:デフォルトの名無しさん
08/04/19 16:18:41
実体は生成される途中にある。
だから、this は存在する。
存在するが、その実体は完全に生成されていないので、
その実体を操作しようとすると色々な不具合が生じる。

1. メンバ変数が全て生成されている保証は無い。
　　→ メンバ変数に触る関数を呼ぶとヤバい。

2. 仮想関数の呼び出しが正常に働かない。
　　→ class B : public A { B() : c(this) { } void hoge(); C c; };
　　　　とした時、B のコンストラクタ内から仮想関数 hoge を呼ぶと
　　　　どんな状況であろうが B::hoge が呼ばれるが、
　　　　C のコンストラクタ内から渡されたポインタを使って仮想関数 hoge を呼ぼうとすると
　　　　どんな状況であろうが A::hoge が呼ばれる。
　　　　B の基本的な初期化が済んでないので、B::hoge を呼ぶ事は非常に危険ということでそうなるのだが、
　　　　もちろん A::hoge が呼ばれてしまう事も危険っちゃ危険だ。

626:618
08/04/19 16:37:18
ん...また混乱..

>>1. メンバ変数が全て生成されている保証は無い。
>>　　→ メンバ変数に触る関数を呼ぶとヤバい。
これだと、例えば,
class AAA {
public:
　 // 危険?
　 AAA(){
　　 this->value = 5;
　 };
　
　 // こちらにしなくてはならない?
　 AAA():value( 5 ){
　 };
　
　 void test(){
　　 cout<<value<<endl;
　 };
private:
　 int value;
}
ということ？

627:デフォルトの名無しさん
08/04/19 16:55:31
ここで言っているのは、コンストラクタ以外のメンバ関数のことでしょ。
普通、メンバ関数は、コンストラクタによって適切に初期化済みであることを
前提にして書かれているから、
コンストラクタの途中で呼び出すのは、一般的には危険ということ。

628:デフォルトの名無しさん
08/04/19 17:18:51
GCC でやってみたら C::C 内でも B::hoge が呼ばれた。未定義なのかな？
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)

629:デフォルトの名無しさん
08/04/19 18:02:59
vptrは初期化リストに先立って初期化されてるはずだから、
実装的には値が不定なだけだと思うけど、
未定義ではあると思うよ。

630:デフォルトの名無しさん
08/04/19 18:04:28
補足。this->nとかの値が不定って意味ね。

631:デフォルトの名無しさん
08/04/19 18:08:30
前に VC6 でやった時は仮想関数テーブルの初期化は最後だったけど、
どっちの仮想関数が呼ばれるかって仕様で決まってんのか？

632:デフォルトの名無しさん
08/04/19 18:15:06
え～うそ～！？
基底のコンストラクタから、
派生の仮想関数が呼ばれない、とかの話と勘違いしてない？

633:デフォルトの名無しさん
08/04/19 18:17:17
基底に this は流石に渡さんぜよ。

634:デフォルトの名無しさん
08/04/19 18:32:06
>>631
VC++だと__declspec(novtable)を付けたクラスでは
vtblの初期化が行われないなんて独自拡張がある。
（最派生クラスだけnovtable無しにして使う）

これ使っていないか？

635:デフォルトの名無しさん
08/04/19 19:41:56
novtableいいよねー
コード縮むし

636:デフォルトの名無しさん
08/04/19 20:55:37
　　　　|┃三　　　　　　　　　　　　
　　　　|┃　　　　　　　　　　　
　　　　|┃　≡　　　_、_　　　
＿＿__.|ミ＼＿＿_（　<_,`　）　
　　　　|┃=＿＿＿　　　　＼　　　
　　　　|┃　≡　　　）ATL 人＼ガラッ

637:デフォルトの名無しさん
08/04/19 21:20:55
class Derived : Base {...}

void f(){
　　Derived v;
}

this->vptr = &Base::vtbl → Base::メンバ初期化 → Base::ctor
→ this->vptr = &Derived::vtbl → Derived::メンバ初期化(定義順にctor) → Derived::ctor

Derived::dtor → Derived::メンバ破棄(定義逆順にdtor) → this->vptr = &Base::vtbl
→ Base::dtor → Base::メンバ破棄(定義逆順にdtor) → this->vptr = 不定値

こういう流れになるはず。VC6も。

638:637
08/04/19 21:28:41
表現がおかしかったので訂正。

× Base::メンバ初期化
○ Base::定義順にメンバ初期化
× Derived::メンバ初期化(定義順にctor)
○ Derived::定義順にメンバ初期化

ctorは「メンバの暗黙の初期化・初期化リストによる初期化」を含まないコンストラクタの中身。
dtorは「メンバのデストラクタ呼び出し」を含まないデストラクタの中身。

639:デフォルトの名無しさん
08/04/19 23:10:47
VCの実装を見る限りcinやcoutはextern修飾されてるみたいですが、
宣言のみの必要な定義のいらないこれらの様なものを自分でも書くとき、
一般的にどのコンパイラでも単にexternを付けておけば良いんでしょうか？

640:デフォルトの名無しさん
08/04/19 23:21:00
externが、必要がでるまでどこかで定義された実体を探す事がないという保証があるかどうか？

641:デフォルトの名無しさん
08/04/19 23:25:46
日ｈ（ｒｙ

642:デフォルトの名無しさん
08/04/22 15:26:08
template<class T> struct A { struct B {}; };
template<class T> void f( typename A<T>::B ) {}
と定義して
f( A<int>::B() );
とすると

'void f(A<T>::B)' : テンプレート引数を 'T' に対して減少できませんでした

というエラーが出るのですが、入れ子クラスではテンプレートの引数を推測でき
ないのでしょうか?

643:デフォルトの名無しさん
08/04/22 15:49:31
f( A<int>::B() );
を
f<int>( A<int>::B() );
と推測できないかってこと？

それは無理がありすぎるな。

644:デフォルトの名無しさん
08/04/22 17:09:44
逆にboost::implicit_castがこれを使っていて、
推論を抑えるため、引数の型をtypename mpl::identity<T>::typeにしている。

645:デフォルトの名無しさん
08/04/22 19:09:03
BがAのテンプレートパラメータTの値をtypedefの形で保持してそれをf側で参照するようにしてやれば可能になりそうだけど
そうするとfを関数オブジェクトにしないといけなくなってC++の暗黒面に突入する…と
本当にunk言語だな

646:デフォルトの名無しさん
08/04/23 17:10:39
何で
std::auto_ptr<char> x( new int );
はコンパイルエラーにならないんですか?

647:デフォルトの名無しさん
08/04/23 17:19:09
おまえがどんなコンパイラと、どんなSTLの実装使っているのか非常に気になる。

648:デフォルトの名無しさん
08/04/23 17:23:34
コンパイラは VC8 SP1 で STL はコンパイラ付属です。

649:デフォルトの名無しさん
08/04/23 22:11:04
VC8って2005だっけ?
2008ではエラーになったぞ。

650:デフォルトの名無しさん
08/04/24 00:38:29
8は2005

651:デフォルトの名無しさん
08/04/24 09:47:20
VC++2005Expressではエラーになった

652:デフォルトの名無しさん
08/04/24 12:12:58
VC7.1 だとエラーになりました。

Microsoft Visual Studio 2005
Version 8.0.50727.762 (SP.050727-7600)
だとなぜかエラーになりません。

もしかして C++ コンパイラはエラーを出す義務はないのかな?

653:デフォルトの名無しさん
08/04/24 13:26:29
多分それはない。
コンパイラのバグか、誰かがヘッダ書き換えちゃったとか。

654:デフォルトの名無しさん
08/04/24 15:07:19
デバッガで追いかけたら new int が一旦 std::auto_ptr_ref<char> に
変換されてから std::auto_ptr<char> に変換されていました。
std::auto_ptr_ref<T> は void* 型でポインタを記憶しているので
int 型は消えていました。
memory ヘッダーを確かめると確かにエラーが出ないはずです。
この動作は std::auto_ptr の仕様でしょうか?

655:デフォルトの名無しさん
08/04/24 15:34:39
これと同じみたいだね
URLﾘﾝｸ(connect.microsoft.com)

656:デフォルトの名無しさん
08/04/24 15:45:29
いまだに信じられんな。もうすでにVC8なんて使っていないんだが、
それほど悪いコンパイラとSTLじゃなかったはずだが。

とりあえず>>654の話から想像すると、
rvalueとlvalueの境を越えるための、あまり汎用的に使い道のない、
汚いトリックを使ってauto_ptrを実装しているが（オーバーロードとtemplate argument deductionのわずかな違いを利用するやつ）
普通に使う際にも、そのトリックが働いてしまうって事かな。
STLの実装の問題っぽいかなぁ。
ふつうauto_ptr_refのメンバをvoid *にしなければならない理由はないよな。

657:デフォルトの名無しさん
08/04/24 15:48:53
>>655
あ、>>656に加えて、auto_ptr_refのコンストラクタがexplicitじゃないのか。
だめじゃん、P.J. Plaugerさん。

658:デフォルトの名無しさん
08/04/24 19:51:53
失礼
リソースの切り離し / 復元を実行するメソッドの命名に困っているのですが
この意味に近くて使いやすい単語のペアはありませんかね？
機能的に必ず対になるものです。

候補としては
[Detach / Restore]　Detach の対義語は Attach だしな
[Detach / Attach]　Attach は「復元」では無い気がする
[Destruction / Resotre]　Destが長い
[Destroy / Restore]　Destory は Create のペアとして使ってきたので控えたい
ですが、どうも腑に落ちません。

659:デフォルトの名無しさん
08/04/24 19:58:10
日本語の「切り離し」と「復元」はそもそも対義語じゃないよね・・・
切り離しとその反対なら、Detach / Attach だろうし、
復元とその反対なら、Save / Restore だろう。

Destruction なんて破壊しちゃうわけでさ、英語以前に日本語の
「切り離し」「復元」ってのがそもそも違うんじゃないか？

660:658
08/04/24 20:08:51
>> 659
> 英語以前に日本語の「切り離し」「復元」ってのがそもそも違うんじゃないか？
うーむ・・仰るとおりですね

切り離しを実行すると消失という状態になる処理だったので
それを元に戻す意味で復元と考えていたのですが
もう少し考え直してみます。　ありがとうございました

661:デフォルトの名無しさん
08/04/24 20:12:44
漏れはホンちゃんの処理の準備のためのナニにはPrepareXXXを結構使うな。
オフスクリーンビットマップやら何やらの準備とか。

662:デフォルトの名無しさん
08/04/24 21:22:36
release / acquire

663:デフォルトの名無しさん
08/04/24 22:20:14
>>660
Disconnect / ReConnect とか、Detach / ReAttach とかは？

664:658
08/04/24 22:43:04
>>661
Prepare
今回は使いそうに無いけど、ひとつ賢くなりました

>>662
そういえば DirectInput に Acquire / UnAcquire （だったかな）ってのがありますね
これ良いかも

>>663
Disconnect / ReConnect
接続とはちょっと違うんですわ

ありがとうございました
スマートに命名出来るように、もうすこし設計から見直すことにします

次ページ