C++相談室 part25

んー、
さんざん論議されてきたことだと思うけど、一つ思ふことあり。

例えば、
bool sw;
というメンバがあったとする。これはprivateなメンバに配置するのが
望ましい。だが、これを一度、privateな場所へ置いてしまうと
set_sw() unset_sw() というような対となるメンバ関数を書かねばならない。

これは非常に疲れる作業であるばかりか、ソースコードの見通しを
悪くしているような気がしてならないのだ。

そこで、なんとかいい方法はないもんかと・・・
うーむ

13 ：デフォルトの名無しさん：03/11/05 06:55

enumを、ずっとエニュームって読んでた＿|￣|○

14 ：デフォルトの名無しさん：03/11/05 07:07

> set_sw() unset_sw() というような対となるメンバ関数を書かねばならない。

これが間違いだろ。

15 ：デフォルトの名無しさん：03/11/05 07:44

bool get_sw();
void put_sw(bool value);
__declspec(property(get=get_sw, put=put_sw)) bool sw;

16 ：デフォルトの名無しさん：03/11/05 07:49

>>15
標準C++じゃないだろそれ・・・

17 ：デフォルトの名無しさん：03/11/05 08:46

> set_sw() unset_sw() というような対となるメンバ関数を書かねばならない。
さんざん議論されたことだが、「メンバ変数を置いたらそれに対応する
アクセサを書く」という謎な習慣はやめた方がいい。単なるアクセサは
基本的に書いてはならん。

・クラスの設計の上で「スイッチをONする」「スイッチをOFFする」というメソッドが
必要になったのなら、まず最初に set_sw() と unset_sw() が設計として
登場してくるはずだ。その後で、その実装の詳細として、bool sw; が出てくる…
という順序なら自然ではある。この場合必然なのはset_sw()とunset_sw()の
方なので、見通しが悪くなるとか良くなるとかいう話にはならんだろう。

・あるいはオブジェクトの振る舞い全体に関わる設定項目として
bool sw; があるのなら、set_config() なりなんなりの言わば facade 的な
メソッドを用意して、"sw" という細かな実体を直接いじるインターフェイスは
提供しないようにする。

18 ：17：03/11/05 08:50

でなけりゃ
> そこで、なんとかいい方法はないもんかと・・・
C#やDをつかってbool swを最初publicにしとく。
あとで必要になったらプロパティに変更すればいい。

19 ：デフォルトの名無しさん：03/11/05 09:38

>>17
アクセス方法を後で変えたくなっても
すでにそのクラスをあちこちで使用してたら
そう簡単には変えられないことがあるよ。
bool sw メンバーが true から false に変わったタイミングで
何かの処理をやらせたくなっても
最初に public bool sw にしていて直接変数を触らせる方式を採用してたら
もう手が出せない。
アクセサーを用意しないというのは、
表面上の仕様を変えずに内部動作を変える余地を無くしてしまうので
「はじめにpublicメンバーありき」
とメンバー変数を露出させてるとあとで泣くことになる。

20 ：デフォルトの名無しさん：03/11/05 09:45

for文内でnewしたオブジェクトは放置するとまずいですか
やはり、for文でdeleteしないと駄目ですか

21 ：デフォルトの名無しさん：03/11/05 09:46

>>19 的外れ

22 ：デフォルトの名無しさん：03/11/05 09:47

>>20
newしてるんだったらdeleteする場所はあんたの責任で、場所やタイミングはあんたの自由。

23 ：デフォルトの名無しさん：03/11/05 09:48

>>20
newしたアドレスを全部覚えていれば
ループの外でdeleteしてもいい

24 ：デフォルトの名無しさん：03/11/05 09:53

>>17
> クラスの設計の上で「スイッチをONする」「スイッチをOFFする」というメソッドが
> 必要になったのなら、まず最初に set_sw() と unset_sw() が設計として
> 登場してくるはずだ。その後で、その実装の詳細として、bool sw; が出てくる…
> という順序なら自然ではある。

まるで漢字の書き順を指摘しているようだ。
先にメソッドから用意されても、先にメンバー変数から用意されても、
結果が同じコードになるなら、先にどちらが用意されようがどちらも自然。

だいたい bool sw; のようなメンバーを用意すること無く
set_sw() と unset_sw() というメソッドだけが存在することはありえないのだから
set_sw() と unset_sw() が設計として登場してる時点で
bool sw; の存在が前堤となり、存在してくれていることに依存している。
その結果メソッドとメンバー変数が相互依存の形を取れば、
最初にメンバー変数から用意しているのと何ら変わりはない。

25 ：デフォルトの名無しさん：03/11/05 09:58

> だいたい bool sw; のようなメンバーを用意すること無く
> set_sw() と unset_sw() というメソッドだけが存在することはありえないのだから

んなこたぁない。

26 ：デフォルトの名無しさん：03/11/05 10:07

>>24
Program to an interface, not an implementation.

27 ：デフォルトの名無しさん：03/11/05 11:18

>>13
エニュームじゃねぇの！Σ(ﾟДﾟ )

28 ：デフォルトの名無しさん：03/11/05 12:02

STLつかうと一気に実行ファイルサイズが10倍に?！

29 ：デフォルトの名無しさん：03/11/05 12:04

>>28
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。

30 ：デフォルトの名無しさん：03/11/05 12:06

>>29
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

31 ：デフォルトの名無しさん：03/11/05 12:07

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

32 ：デフォルトの名無しさん：03/11/05 12:07

ソースコードのサイズが同じならバイナリのサイズが10倍になってもおかしくは無い。
が、同じことをSTLを使わずに書けばソースコードのサイズが10倍以上になるだけだ。

最もsizeof(int) == sizeof(long)な環境でもstd::vector<int>とstd::vector<long>を別個に
確保してしまうとかその種の問題は存在するが。

33 ：デフォルトの名無しさん：03/11/05 12:07

>>31
VC++スレにいけ

34 ：デフォルトの名無しさん：03/11/05 12:08

>>31
#include <stdafx.h>

後死ね。

35 ：デフォルトの名無しさん：03/11/05 12:09

>>34
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

36 ：デフォルトの名無しさん：03/11/05 12:14

>>32 >>33
>>28～の一群のレスはデジャ・ブだと思うよ。

37 ：デフォルトの名無しさん：03/11/05 13:24

>>24みたいなアフォがいるからクソコードが蔓延するんだな

38 ：デフォルトの名無しさん：03/11/05 13:38

実行時クラスを生成する機能ってあったっけ？

class2はclass1を継承していて、
class1 *cls = class2へのポインタ

・Javaなら（上と同等なコードをJavaで書いたとして）
cls.getClass.newInstance()
でclass2のデフォルトコンストラクタが呼ばれる

関係するすべてのクラスで、
実行時クラスを返すメソッドを定義するのは面倒なの

39 ：template<>：03/11/05 13:44

なんだか俺の出番のような気がするな

40 ：デフォルトの名無しさん：03/11/05 13:51

エニュム

41 ：13：03/11/05 14:04

>>27
あれ？いいのかな、確かにenumerateだもんなぁ
いやネットで見てたらエナムが正しいようなので

42 ：デフォルトの名無しさん：03/11/05 14:11

>>41
ネット見てる暇があったら辞書引けや。このバカチンが。
オマエみたいな馬鹿はenableをエナブレと発音するからうざい

43 ：デフォルトの名無しさん：03/11/05 14:15

enable いねいぶる
enumerate いにゅーまれいと
enum いにゅーむ

44 ：38：03/11/05 14:31

分かったよ
ttp://tt.sakura.ne.jp/~suzu/tips/copy.html
無理だってことが

45 ：デフォルトの名無しさん：03/11/05 14:39

>>42
アホ、辞書引いてたから迷ったんじゃい
結構有名なサイトでエナムってあったから、そうなのかなと

46 ：45：03/11/05 14:54

ああでもあれだな
enumerateから類推するとenumをイニュームって読んじゃうけど
-erateが消えて、uの長母音が短母音になり、エナムになるのかもな

47 ：デフォルトの名無しさん：03/11/05 15:03

>>46
するどい！runとruneの発音変化みたいなもんか

48 ：デフォルトの名無しさん：03/11/05 15:05

イには聞こえない

49 ：デフォルトの名無しさん：03/11/05 17:06

ヰヌム、ってあたりで。

50 ：デフォルトの名無しさん：03/11/05 17:15

メンバ関数で、ちょっとした大きさのオブジェクトを返す場合、

const Object& GetObject(void) const;
void GetObject(Object&) const;
Object GetObject(void) const;

の、どれを採用してますか？
１番目はコピーコンストラクタなどで利用できるけど、計算結果は返せない。
２番目は計算結果を返せるけどコピーコンストラクタなどで利用できない。
３番目は利便性は最高だけど、コストがかかる。

今のところ１番目と２番目を、オブジェクトに応じて使ってますけど、
なんだかすごく保守性に欠けてる気がして……。

ちなみに、実際に悩んでるのは、行列クラス、ベクトルクラスです。
サイズ的には、それぞれfloat[4][4],float[4]です。
すべて３番目のコードにしといて、実行速度が問題になってから１と２を
検討するのがいいでしょうか？

51 ：デフォルトの名無しさん：03/11/05 18:18

Object operator * (const Object&, const Object&);
こんなのをどうやって１や２で返すんだよ >>50

52 ：デフォルトの名無しさん：03/11/05 18:25

>>50
Object GetObject(void) const;

const Object& ref = GetObject();

53 ：デフォルトの名無しさん：03/11/05 19:32

>>13
遅レスすまそ
http://dictionary.goo.ne.jp/voice/e/01011190.wav

54 ：デフォルトの名無しさん：03/11/05 19:41

>>50
実装の内部ではどれも同じように効率的な欠き方がされているものとして、
実際に利用されるコンパイラで速度を測ってみるべきだと思いますよ。
案外3も遅くないかもしれないから。

エラー値とか返す場合には 2 みたいなのも良いと思う。。

55 ：デフォルトの名無しさん：03/11/05 19:51

>>51 >>52
あああああ。そ、そうかー。
結局のところ、operator* と同じ問題に帰結するんですね。
記述法が統一できなくなるから、２が論外ですね。
ありがとうございましたー。

56 ：デフォルトの名無しさん：03/11/05 21:49

>>53
それは関係無しにenumを単体で見たらエナムと呼ぶっていう話では？>>46

57 ：デフォルトの名無しさん：03/11/05 22:53

Object a,b,c,d;

if( (a*b)==(c*d));//...

58 ：デフォルトの名無しさん：03/11/05 23:11

なんだよ

59 ：デフォルトの名無しさん：03/11/06 00:15

>>55
２も使う

つーか、おまえさんまだ論外とか常識とか言い出す時期じゃないぜ？
変に先入観持たずに納得いくまで色々書きまくってみろよ自分で。
すぐ上の先輩の言う「常識」なんか覆してやる！　くらいのパワーがなくてどうする。

60 ：デフォルトの名無しさん：03/11/06 01:15

(-人- ) ﾅﾑﾅﾑｲﾅﾑ

61 ：デフォルトの名無しさん：03/11/06 06:59

class A
{
void func()
{
}
};
class B
{
void func()
{
}
};
の中で直接定義していくような記述をしてきたいのだけど
それだと、class A の中から class B のメンバ関数を呼び出したいとき
名称前方参照のため、コンパイルができない。
結局、ヘッダに型宣言をせざるを得なくなる。

これってC++の欠陥だよー。Cのときからもそうだったけど。
仮宣言が必要なのってウザい。複数ファイル行き来して編集せねば
ならないし。

なにかしらの対処工夫ってないものだろうか？（解決は言語仕様からして
無理だとは思うけど）

62 ：デフォルトの名無しさん：03/11/06 07:09

class Dog : class Animal;
class Cat : class Animal;
class Hoge : class Animal;

とあって、Animal* a[10];
という配列があったとします。
で、この中は、Animalからの派生物のインスタンスが
入ってることは分かっているのだけど、

「鳴け」というメンバ関数を持っているもののみ「鳴け」と
できないものだろうか？

Dog と Cat は鳴くメンバ関数があるのだけど、
Hogeは鳴くメンバ関数はない。もちろんAnimalにも鳴くメンバ関数はない。

配列に格納されてるクラスを無作為に「鳴け」と呼び出し、
該当メンバ関数を持っていなかった場合は、「なにもしない」と
したい場合、どうすればよいだろうか？

ちなみにHogeクラスにダミーとなる鳴きメンバ関数を追加するという
方法はNGなんです・・・

63 ：62：03/11/06 07:13

追記ですが、「鳴ける動物クラス」を新規設置して
その配列にすればよいというのもNG。

というのは、個別名前検索でヒットしたAnimalをa[]に列挙し、
そいつに対して一斉に「鳴け」とせざるをえない状況だからです。

要は、指定したインスタンス（ポインタ）に対して
「このメンバ関数、ある？」と聴いて回れる手段が欲しいのですー

むむむ

64 ：62：03/11/06 07:23

たびたびすまんです、RTTIが使えない環境下です。

65 ：デフォルトの名無しさん：03/11/06 08:30

>>63
「このメンバ関数、ある？」という質問に回答してくれる
関数を作って下さい。各classのvirtual methodとして。

66 ：デフォルトの名無しさん：03/11/06 08:40

メンバ関数の有無がわかっただけじゃAnimal*から呼び出せない。
結局ダウンキャストが必要になり、それにはRTTIが必須（普通は）。
Animalに鳴けというvirtualメンバ関数を追加するのがまっとうなやり方でしょ。

67 ：デフォルトの名無しさん：03/11/06 11:33

>61
Aの前にBをもってくればいいじゃん。

と、冗談は程々にして、
そんな相互参照な構造にコストがかかると思って諦めろ。
ていうか、ヘッダに納めたいだけなら、ちょっと下に定義を書くだけやん。

>62
>66に同意で無理。
AnimalにRTTIもどきvirtual関数があるなら、力業で出来るかもしれんが、
無いだろうし、そもそもそんなのC++じゃねぇ。

68 ：デフォルトの名無しさん：03/11/06 12:02

69 ：デフォルトの名無しさん：03/11/06 12:16

class VoiceSimulator : public Nakeru
{
　void naku();
};
class RoboCat : public Animal
{
　VoiceSimulator cat_voice;
　Nakeru* nakeru() { return &cat_voice; }
};

70 ：デフォルトの名無しさん：03/11/06 13:16

>>61
>>67が言ってるけど
class A
{
void func();
};
class B
{
void func()
{
}
};

void A::func()
{
}

でええやん。

71 ：デフォルトの名無しさん：03/11/06 14:41

>>67 >>70
>>61では「複数ファイル」って言ってるけど、実際は「宣言」と「定義」の２箇所で
整合性を取らなければいけないのがいやだ、ってことではなかろうか？
非constメンバ関数をconstメンバ関数にしたとき、宣言と定義の両方に
constつけんとあかんでしょ？　そういうことではないかと思う。
……うまいこと編集してくれる統合環境がありゃいい話ではあるけどね。

72 ：デフォルトの名無しさん：03/11/06 15:14

>>62
COM とか CORBA 風にすれば？

73 ：デフォルトの名無しさん：03/11/06 20:08

age

74 ：デフォルトの名無しさん：03/11/06 20:24

class A
{
void func()
{
}
};

こんなんやってたら全部インラインになって大変なことになるよ。

75 ：デフォルトの名無しさん：03/11/06 22:49

DelphiからCに移ったﾔｼいる？

76 ：デフォルトの名無しさん：03/11/06 22:51

超スレ違い質問ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

77 ：デフォルトの名無しさん：03/11/06 22:57

テキストファイルを読み込んで、その中から「abc」という単語を含む
文を抜き出すコードってどう書けばいいですか？

ifstream fin("テキストファイル.txt");

fout.close();

文を抜き出すいいコードが思い浮かばないんですが・・・

78 ：デフォルトの名無しさん：03/11/06 22:59

あ、
fin.close();
でした。

79 ：デフォルトの名無しさん：03/11/06 23:02

文の定義をして下さい。

80 ：デフォルトの名無しさん：03/11/07 01:39

チンチンシュッシュッ

81 ：デフォルトの名無しさん：03/11/07 02:29

>>77
抜き出すって、具体的にはどうするの？
出力すればそれでいいのか、それともメモリ上に持っておきたいのか。

82 ：デフォルトの名無しさん：03/11/07 02:43

>>81
的外れだな
出力先はFDなのかCD-ROMなのかHDDなのか尋ねているようなものだ

memory上に格納しておけば
> 出力すればそれでいいのか、それともメモリ上に持っておきたいのか。
いずれの要求でも満たせる

83 ：デフォルトの名無しさん：03/11/07 05:10

class Nakeru { public: virtual void naku() = 0; };
class Animal { public: virtual Nakeru* nakeru() { return 0; } };

class Dog : public Animal , public Nakeru
{
　void naku();
　Nakeru* nakeru() { return this; }
};
class Cat : public Animal , public Nakeru
{
　void naku();
　Nakeru* nakeru() { return this; }
};
class Hoge : public Animal
{
};

void naku( Animal* a[10] )
{
　for( int i = 0 ; i < 10 ; ++i )
　　if( Nakeru* nakeru = a[i]->nakeru() ) nakeru->naku();
}
----
↑それじゃ解答になってないよ。
「鳴く」メンバ関数を持ってないHogeも配列に動的に混在する
ケースが問題になっているので。Nakeru*配列である以上、
鳴けて当たり前のインスタンスしか格納されてないので、
そもそも選別不要。

84 ：デフォルトの名無しさん：03/11/07 05:23

つーかAnimalクラスに何もしない「鳴け」仮想関数を置いておくという解決法の
なにが不満なのかがさっぱりだ。

85 ：デフォルトの名無しさん：03/11/07 05:53

＞つーかAnimalクラスに何もしない「鳴け」仮想関数を置いておくという
＞解決法のなにが不満なのかがさっぱりだ。

その方針で基底クラスに仮想関数をほいほい追加していったら、
おそよ継承先の末端メンバ関数全てを追加せねばならぬので現実的な
解決策ではないのでは？

というか、「鳴く」という例が一般的すぎる動詞で例が悪くね↑

「オナニーする」「2chでカキコする」だとか、
わりとマニアックなメンバ関数だったりすると
問題が分かりやすくなるのでは？
すると、基底クラスには、おそらく動物学的には稀な動作である
全ての動物の挙動が辞書のごとく膨れ上がってしまうかと。

そうではないでしょ。
やはり基底クラスというのは、最低限のメンバ関数（仮想関数ふくむ）
のみを追加するべき、小さなクラスであるべき。

継承先で枝となる詳細なクラスが追加されていくと。

86 ：デフォルトの名無しさん：03/11/07 05:56

>>85
そういう場合はdynamic_cast使えばいいだろ？

87 ：デフォルトの名無しさん：03/11/07 09:25

>>83
Nakeru*配列じゃなくてAnimal*配列だって。コードよくみろよ。ちゃんと動く解答だぞ。

>>86
この話題の前提である「RTTIが使えない環境下(>>64)」を覆えして反論することに意味はないだろう。

なんにしても、Animal*配列である以上、Animalに何か追加しないことにはどうしようもないっぽい。

88 ：デフォルトの名無しさん：03/11/07 09:38

RTTIが使えなくてもクラスメンバに型識別用の情報突っ込んで
擬似dynamic_castを行うことは充分可能だと思うが。

89 ：デフォルトの名無しさん：03/11/07 12:00

RTTI使わなくてもある程度はできるけど
多重継承を考えると死ぬぞ

90 ：デフォルトの名無しさん：03/11/07 12:06

>>85
基底クラスに対して「鳴け」といいたいのだから
鳴けというメンバ関数は最低限のメンバ関数だろ

91 ：デフォルトの名無しさん：03/11/07 12:32

やっぱり、62の言うとおり、
IBeeper *ibp;
if SUCCEEDED( animal[i]->QueryInterface( __uuidof(IBeeper),(void**)&ibp) )
{ ibp->beep(); ibp->Release(); }
か。

92 ：デフォルトの名無しさん：03/11/07 15:44

鳴けるクラスが自クラスのインスタンスのセットをスタティックに持っていれば基底クラスは一切変更しなくてもイケる。
パフォーマンスに多少の影響はあるが。

93 ：デフォルトの名無しさん：03/11/07 18:50

これがうまくコンパイルできない理由ってわかりますか？
コンパイラはgcc3.3.1(MinGW)及びVC7.1です。

#include <iostream>

namespace hoge {
　void f(const char*) { std::cout << "hoge::f\n"; }
}

namespace piyo {
　using namespace hoge;
　void f(int) { std::cout << "piyo::f\n"; }
}

int main()
{
　piyo::f("ABC"); // エラー
}

94 ：デフォルトの名無しさん：03/11/07 19:03

void piyo::f(int)だから当たり前じゃないの？

95 ：94：03/11/07 19:13

触発されて思いつき
namespace hoge {
void f(const char*) { std::cout << "hoge::f\n"; }
}
namespace piyo {
void f(int) { std::cout << "piyo::f\n";}
void b()
{
using namespace hoge;
f("ABC");
}
}
他の名前空間の関数とはオーバーロード出来ないのか？

96 ：デフォルトの名無しさん：03/11/07 19:14

>>94
using namespace hoge; で取り込んでも関数のオーバーロードは解決
してくれないのでしょうか。それで悩んでいるのです。

ちなみに

#include <iostream>

namespace hoge {
　void f(const char*) { std::cout << "hoge::f\n"; }
}

namespace piyo {
　void f(int) { std::cout << "piyo::f\n"; }
}

namespace hage {
　using namespace hoge;
　using namespace piyo;
}

int main()
{
　hage::f("ABC");
}

とやったら通るんですよね。

97 ：デフォルトの名無しさん：03/11/07 19:17

>>95
それもダメみたいっすね。

98 ：94：03/11/07 19:29

なんか期せずしてcppllで同じような内容が。
答も出ていて
namespace piyo {
using hoge::f;
略
}
ときっちり指定すれば、出来た。

99 ：デフォルトの名無しさん：03/11/07 19:35

>>98
実は(^^;)cppllで答えが出なかったから2chに投げてみたんです。

そうです。using-declarationはうまく行くのにusing-directiveは
うまく行かないんで悩んでいたんです。規格書読んでもそれらしき
例は載っていないし。namespaceスコープ中のusing-directiveは
関数のオーバーロードを解決しないという文が規格書のどこかに
あれば納得するんですが。うむむむ。

100 ：デフォルトの名無しさん：03/11/07 19:37

でも、そんな文があったら>>96が通るのも変な話ですよね。
namespaceスコープ中で関数が定義されていたら、using-directive
による関数のオーバーロードは解決しない、という所でしょうか。

101 ：94：03/11/07 19:37

って、そういうことか。＜今最後まで読んだ

102 ：デフォルトの名無しさん：03/11/07 19:43

>>99
PLC++3rdの8.2.8.2がそれっぽい・・・。

103 ：デフォルトの名無しさん：03/11/07 19:48

>>102
ありがとうございます！！確かにこの通りです。
ではコンパイラの動作は正しいみたいですね。後は規格書から
それらしい文を見つけ出せばいいだけです。これで半分解決
したも同然です。

104 ：デフォルトの名無しさん：03/11/07 19:51

そのへんの問題は、Exceptional C++ の第５章「名前の自動照合とインターフェース原則」に詳しく載ってるよん。

105 ：デフォルトの名無しさん：03/11/07 20:27

>>104
今Exceptional C++を読んでいます。ちょっとusing-directiveに
関する話題は見つからないようです。

規格書の7.3.4の5ですがちょっと意味が違うみたい。

[Note: in particular, the order in which namespaces were considered
and the relationships among the namespaces implied by the using-directives
do not cause preference to be given to any of the declarations found by the search. ]

[注:優先権は、探索によって見つかった宣言のうちのどれにでもnamespacesが考慮された
順序、およびusing-directiveによって暗黙に意味されたnamespacesの関係によって特に
与えられません。]

自動翻訳に味付けしただけですが、これでは明示的に宣言されたものがusing-
directiveより優先するかどうか微妙な所です。

106 ：デフォルトの名無しさん：03/11/07 23:56

void naku( Animal* a[10] )
{
　for( int i = 0 ; i < 10 ; ++i )
　　if( Nakeru* nakeru = a[i]->nakeru() ) nakeru->naku();
}

↑a[i] の中に Hoge が入っていて、それに対して
a[i]->nakeru() が NULL が返ってなければという前提は
RTTI前提になってしまうのでは？

107 ：デフォルトの名無しさん：03/11/08 00:44

>>106
どこにRTTIが使われてると思ってんの？

108 ：デフォルトの名無しさん：03/11/08 00:54

>>107と同意見
vtblもRTTIだと言いたいのか？

109 ：デフォルトの名無しさん：03/11/08 04:21

質問です。
汎用クラスを通常のクラスで継承するということは可能ですか？

template<class X> class hanyou_class
{
public:
hanyou_class();
`hanyou_class(); // `はチルダのつもりです
}

コンストラクタ・デストラクタは略

class normal:hanyou_class<int>,sonota_no_class
{
//中身
}

とやってみたところ、汎用クラスのコンストラクタが参照エラーになってしまいました。
継承しなければエラーも出ませんし使えます。

初心者質問で申し訳ありませんがどなたかご教授願えないでしょうか？

110 ：デフォルトの名無しさん：03/11/08 04:25

>>109
普通に出来ます。
ちゃんとコンストラクタの実態はありますか？
C++のtemplateは実体が同一の翻訳単位に含まれるか、export（ほとんどのコンパイラで使えない）しないと駄目ですよ。

111 ：デフォルトの名無しさん：03/11/08 04:41

>>109
関係ないけどチルダが入力できない環境なのか?

112 ：デフォルトの名無しさん：03/11/08 04:57

>>111
US配列だと[~]の位置が[Shift+`]だからtypoしてるんじゃないか？

113 ：デフォルトの名無しさん：03/11/08 05:15

継承するときには public 書かないと
private 継承されちゃうぞ。

114 ：109：03/11/08 05:21

詳しく書きます。（関数の中身は要約します）

//汎用クラス
template <class X> class image_base_class
{
public:
X * mPixels;
};
//コンストラクタ
template <class X> image_base_class<X>::image_base_class(){

mPixels = new X[SIZE];

}
//デストラクタ
template <class X> image_base_class<X>::~image_base_class(){

delete iImage->mPixels;

}

115 ：109：03/11/08 05:21

//普通のクラス (上の汎用クラスを継承）
class tools_class:image_base_class<double>
{
public:
　　　　　　int dx,dy;
tools_class();//このクラスのコンストラクタ
int draw_nanika(image_base_class<double> * iImage);//適当な関数

};
//コンストラクタ
tools_class::tools_class()
{
dx = 0;
dy = 0;
}

このようなソースで、汎用クラスのコンストラクタで外部参照エラーがおきました。
派生クラス（普通のクラス）のコンストラクタをコメントアウトしてやるとエラーがでません。
環境はwindowsXpでVC++.netです。

解決策があればお願いします。

116 ：デフォルトの名無しさん：03/11/08 05:22

iImage-> って？

117 ：109：03/11/08 05:22

続き

//普通のクラス (上の汎用クラスを継承）
class tools_class:image_base_class<double>
{
public:
　　　　　　int dx,dy;
tools_class();//このクラスのコンストラクタ
int draw_nanika(image_base_class<double> * iImage);//適当な関数

};
//コンストラクタ
tools_class::tools_class()
{
dx = 0;
dy = 0;
}

このようなソースで、汎用クラスのコンストラクタで外部参照エラーがおきました。
派生クラス（普通のクラス）のコンストラクタをコメントアウトしてやるとエラーがでません。
環境はwindowsXpでVC++.netです。

解決策があればお願いします。

118 ：デフォルトの名無しさん：03/11/08 05:25

エラーメッセージも書いてホスィ。

119 ：109：03/11/08 05:36

すいません。iImage->ってのは無視してください＾＾；

エラーメッセージは
cap error LNK2001: 外部シンボル ""public: __thiscall image_base_class<unsigned char>::~image_base_class<unsigned char>(void)" (??1?$t2_image_base_class@E@@QAE@XZ)" は未解決です。
や
cap error LNK2019: 未解決の外部シンボル "public: __thiscall image_base_class<unsigned char>::~image_base_class<unsigned char>(void)" (??1?$image_base_class@E@@QAE@XZ)
が関数 "public: int __thiscall dshow_class::dshow_init(void)" (?t2_dshow_init@dshow_class@@QAEHXZ) で参照されました。
といったものです。（書いてない関数がありますが気にしないでください）

これらエラーは汎用クラスのコンストラクタとデストラクタをコメントアウトするか、派生クラスのコンストラクタ、デストラクタをコメントアウトすれば解消します。
わかりにくい質問で申し訳ありません。

120 ：デフォルトの名無しさん：03/11/08 05:45

なんでテンプレートクラスのコンストラクタ、デストラクタは定義だけして宣言してないの？

121 ：デフォルトの名無しさん：03/11/08 05:45

うーん。
>>110 >>113 をやってもダメ？

122 ：デフォルトの名無しさん：03/11/08 05:46

×class tools_class:image_base_class<double>
○class tools_class:public image_base_class<double>

123 ：デフォルトの名無しさん：03/11/08 05:49

んーあと考えられるのは、テンプレートが後方定義されてしまってる
ことくらいか。あるいは、そもそもinclude忘れてるとか。

でもvc++のエラーメッセージ見る限り、
なぜか、テンプレート引数が double ではなく unsigned char になってる
のが気になる。

124 ：デフォルトの名無しさん：03/11/08 11:03

これじゃだめなん？

const int SIZE = 1111;

//汎用クラス
template <class X>
class image_base_class
{
public:
image_base_class();
~image_base_class();
X* mPixels;
};
//コンストラクタ
template <class X>
image_base_class<X>::image_base_class() {
mPixels = new X[SIZE];
}
//デストラクタ
template <class X>
image_base_class<X>::~image_base_class() {
delete mPixels;
}

125 ：デフォルトの名無しさん：03/11/08 11:04

続き

class tools_class : public image_base_class<double>
{
int dx,dy;
public:
tools_class();//このクラスのコンストラクタ
int draw_nanika(image_base_class<double>* iImage);//適当な関数
};
//コンストラクタ
tools_class::tools_class()
{
dx = 0;
dy = 0;
}

int main()
{
tools_class A;
}

126 ：デフォルトの名無しさん：03/11/08 11:32

>>109
問題が再現する最小限のソースを作って貼ってみな。

いまままでの書き込みとか、エラーメッセージとか見る限りでは、
たぶん再現できないと思ってるけどナー。

127 ：Ｃ++初心者：03/11/08 13:10

突然ですがどなたか回答お願いします。

VC++6使ってるんですが、個人でゲームなんか作る時は、
メッセージループの中で処理をするような物を使いますよね？
この様な手続き型プログラムの場合、
ＭＦＣを使わないプロジェクトを使わないとダメなんでしょうか？

この場合だとサブルーチンを別のファイルにて開発したいのですが旨くいきません。
プログラムが長くなってきて、見渡し難いんです。
クラスビューで目的のルーチンに飛べれば楽なんですが・・。
そもそも、ゲームタイプの物はクラス作ったりしない物なのでしょうか？
皆さんどうされてるのでしょう？

128 ：109：03/11/08 13:25

みなさん　ありがとうございます。
126さんのご指摘通り、最小限で再現しようとしたのですが、124-125さんのように書くとエラーになりませんでした。
エラーが起きる元のプログラムでも文法は同様なのですが、違いがあるとすればファイルがわかれています。
汎用クラスのコンストラクタとデストラクタを消すか、継承を削除すればエラーになりません。
publicは試してみましたが状況変わらずでした。
123のおっしゃる「後方定義されてしまってる」というのはどういうことでしょうか？

129 ：109：03/11/08 14:12

汎用クラスのクラス定義内にコンストラクタとデストラクタを書いてみたところエラーがなくなりました。
やはり、宣言（定義？）している場所が悪いようなのですが、何かルールみたいなものがあるのでしょうか？

130 ：デフォルトの名無しさん：03/11/08 14:21

>>127
＞メッセージループの中で処理をするような物を使いますよね？

アプリと違ってメッセージドリブンだと作りづらいと思うけど
独自でループ組むほうが多いんじゃないかな

クラスは普通につかってる。便利だし

131 ：デフォルトの名無しさん：03/11/08 15:09

>129
大半のコンパイラでは、テンプレートクラスは定義内に、
メソッド定義がある必要があるけど。

132 ：Ｃ++初心者：03/11/08 15:12

>>130
早速ご返答ありがとうございます。
やっぱり独自のループに入った途端マウスや、キーを自分で監視していかなければ
いけないんでしょうねえ。

独自のループはどこらへんのクラスに作成したら良さげでしょう。
ウインドウズの前処理が整った後だろうと予想しますが。

133 ：Ｃ++初心者：03/11/08 15:20

>>127
>ＭＦＣを使わないプロジェクトを使わないとダメなんでしょうか？
は間違いで、ドキュメントビューを使わないでした。

134 ：デフォルトの名無しさん：03/11/08 17:14

ダイアログクラスでイベントドリブンでアクションゲーム作ってますが。
キャラクタやフィールドの描画はタイマーで描いてるし。

135 ：デフォルトの名無しさん：03/11/08 19:13

while( TRUE ){
if( PeekMessage( &msg , 0 , 0 , 0 , PM_REMOVE ) ){
if( msg.message == WM_QUIT ){
return(msg.wParam);
}
TranslateMessage( &msg );
DispatchMessage( &msg );
} else {
あなたのmain関数()
}
}

イベントドリブンは、Win3.1時代のように、各アプリ間で調停するための
前時代的な方法で、プログラマーにはむしろハンデであり、また足かせ。
Win95以降では可能なかぎり無視することができ、
上記のような記述でなんら問題ありません。
「あなたのmain関数」の中で、無限Loopするような重い処理しても
Win3.1時代とは違い、現行のWindowsはきちんと他のアプリにも適切な
処理権利を分配してくれます。

つまりイベントドリブンは、可能なかぎり無視し、
DOS時代のように我が物顔で、俺Loopを勝手に構築しても、
OSは不安定にもならず、また他のアプリにも迷惑をかけないことを
Windowsが保障しています。

136 ：デフォルトの名無しさん：03/11/08 19:24

>>135
>「あなたのmain関数」の中で、無限Loopするような重い処理しても
>Win3.1時代とは違い、現行のWindowsはきちんと他のアプリにも適切な
>処理権利を分配してくれます。

無限ループしてるスレッドよりも低い優先順位のスレッドは実行機会がなくなるし
ループしてる間はCPUも食うよ。

137 ：デフォルトの名無しさん：03/11/08 19:31

無限ループに入る前にこの行実行しとくといいよ。
SetPriorityClass(GetCurrentProcess(), 0x100);

138 ：デフォルトの名無しさん：03/11/08 19:34

>>137
これと同じことか。asm挟んでいて無限ループに陥った時は
さすがにリセットしかなかった。2CPUなら回避できたのかも。

SetPriorityClass(hprocess, REALTIME_PRIORITY_CLASS);

139 ：デフォルトの名無しさん：03/11/08 19:35

>>135
136の１行目のみ同意見
I/Oﾊﾞｳﾝﾄﾞなﾌﾟﾛｸﾞﾗﾑでそれをやるとﾕｰｻﾞの目が三角になる
ここで言うI/Oにはﾍﾟｰｼﾞﾝｸﾞも含むわけだが．．．

140 ：質問：03/11/08 21:01

クラス用の構造体、共用体の宣言が出来るのはわかるのですが
クラス用の列挙型は出来ないのでしょうか？

141 ：デフォルトの名無しさん：03/11/08 21:19

>140

質問の意味がわからないんですけど。
「クラス用の」って何のことですか？

142 ：デフォルトの名無しさん：03/11/08 22:41

C++ の入門サイト教えてください

143 ：デフォルトの名無しさん：03/11/08 22:56

>>142
本買え

144 ：デフォルトの名無しさん：03/11/08 22:58

>>142
ここのC言語スレ

145 ：デフォルトの名無しさん：03/11/08 23:31

142に>>2嫁って言うつもりで確認に行ったら不意打ちで藁わされた

146 ：デフォルトの名無しさん：03/11/09 00:02

int以外の型、たとえばcomplexとか、を列挙したいのだろうか

147 ：デフォルトの名無しさん：03/11/09 00:42

>>105
見つけたっぽい。
「3.4.3.2 Namespace members」の 2 曰く、その namespace で直接宣言されたものが
見つかった段階で、using-directive は無視されるってことのようだ。

>>141
>>140 を俺的に翻訳してみる。
struct, union は class と同様にメンバ(関数)を持てますが、enum は無理なのでしょうか？
答え：できません

148 ：デフォルトの名無しさん：03/11/09 01:08

>>140 の質問内容は定かではないが、いずれにしろ
試しもしないで聞いてるような雰囲気。

149 ：デフォルトの名無しさん：03/11/09 01:15

＞これと同じことか。asm挟んでいて無限ループに陥った時は
？？
asm挟むとか挟まないとか関係ないです

150 ：デフォルトの名無しさん：03/11/09 03:26

>>無限ループしてるスレッドよりも低い優先順位のスレッドは実行機会がなくなるし
>>ループしてる間はCPUも食うよ。

SystemIdleでループするか、自アプリでループするかの違いでしか
ないので問題ないかと。

151 ：デフォルトの名無しさん：03/11/09 03:32

SystemIdleProcessがループだって？

152 ：デフォルトの名無しさん：03/11/09 03:33

×ループ
○busyループ

だな。

153 ：デフォルトの名無しさん：03/11/09 04:00

>>150
昔似たような発想の頑固親父がいて手こずりました。
いくら言ってもCPU使用率を理解してもらえない。
そんなものは初めから存在しない（だから自アプリがいくらヘビーな処理をしても関係ない）の一点張りで・・・。

154 ：デフォルトの名無しさん：03/11/09 04:40

NT系のWindowsは暇なときはHLTしてるので大違いだ。
ノートとかPentium4だと特にな。

155 ：デフォルトの名無しさん：03/11/09 10:24

for(int i)
{
for(int j)
{
for(int k)
{
if()
{
goto a;
}
}
} a:
}

これだとifの条件が満たされた時点でjとkの部分を飛ばして
次のiに行くけど、gotoを使ってるからダメですか？
これをgotoを使わずに同じ内容にするにはどうしたらいい？

156 ：デフォルトの名無しさん：03/11/09 10:41

>>155
それを無理にやるとしたら
(inline) void inner_loop(int i)
{
for (int j) { for ( int k ) { if () return; } }
}
に分離して、
for (int i) { inner_loop(i); }

157 ：デフォルトの名無しさん：03/11/09 10:43

>>155
それはgotoを使っていい例の一つではないかと思う。

> これをgotoを使わずに同じ内容にするにはどうしたらいい？
for(int j=0, continue_i=0; !continue_i && j<end; ++j )
　for(int k=0; !continue_i && k<end; ++k )
　　if(){ continue_i=1; continue; }
か例外を使うか。

158 ：デフォルトの名無しさん：03/11/09 11:02

あるいは、jkのループを直列化して一本のループにする。

class jk_iterator {
operator ++() {..}
operator void* () const {...}
int j() const {...}
int k() const {...}
};
というようなものを作って
for ( jk_iterator jk; jk ; ++jk ) {
if () break;
}
なんて手もあるけど。

159 ：デフォルトの名無しさん：03/11/09 11:11

ちょっと質問
class{
public:
int a;
int b;
int c;
};
なんてコードを見つけたんだけど
これって
typedef struct{
int a;
int b;
int c;
}
じゃだめなの？
わざわざclassにするメリットがあるのでしょうか？

160 ：デフォルトの名無しさん：03/11/09 11:24

>>159
typedefは不要だが、ともかく特にメリットはないかな。

161 ：デフォルトの名無しさん：03/11/09 11:25

>>159
好みの問題、どっちでもいいよ

162 ：デフォルトの名無しさん：03/11/09 12:39

漏れはprivate:を明示的に書くからclassいらん

163 ：デフォルトの名無しさん：03/11/09 13:38

Cとして利用されるのを防止するためにstructを嫌ったってことはない?

164 ：デフォルトの名無しさん：03/11/09 13:45

無い。
ファンクタなんかはpublicメンバしか無いのが普通だからstructにもメンバ関数を書けるようにしたんだね。

165 ：デフォルトの名無しさん：03/11/09 13:52

>>164
「無い」はなんに対して?

166 ：デフォルトの名無しさん：03/11/09 15:41

あるクラスのprivateメンバに標準コンテナが２つあるとします。
これらのコンテナに対するアクセッサは一般的にどうあるべきなのでしょうか？

とりあえず、外部からは参照だけできればよいものとします。
効率を無視して、普通にコンテナのコピーを返すのがいいでしょうか？
それとも各コンテナのconst_iteratorを提供するのがいいでしょうか？
あるいは、必要になる度に、個別の要素へのアクセス関数を付け加えていくべきでしょうか？

167 ：デフォルトの名無しさん：03/11/09 15:45

>>159
「わざわざclass」って
視点変えれば「わざわざstruct」という考えもある

168 ：デフォルトの名無しさん：03/11/09 15:47

>>166
constな参照を返すのは？

169 ：デフォルトの名無しさん：03/11/09 15:55

>>156-158
ありがとうございます

独学なもんで、こういう「状況に応じた判断」の基準が
よくわからないんですよね。gotoは極力使うな！と、
どこを見ても書いてあるので、どういうときに使っていいものか
迷っていました。
でもこの例なら使ってもそれほど悪くはなさそうってこと納得しました。

170 ：デフォルトの名無しさん：03/11/09 16:01

>>166
「一般的には」どちらでもいいので
そのクラスの事情に応じて決めて下さい

ちなみに
確保しているメンバーと同じ値を見せれば良いとき
一般的にはconstの参照が多いです
途中でフックかけて、状況に応じて改変や生成をした値を返す必要があるならば
一時オブジェクトを返すことが多いです

class range
{
int start;int length;int end;/*end==start+length*/
public:
int get_start()const{return start;}
int const& get_length()const{return length;}
int get_end()const{return end;}
...
};
...
for(int i=r.get_start();i<r.get_end();i++) ...

こういうので int end; を除去して
int range::get_end()const{return start+len;}
に変更しても表面上の仕様は変わらないように
アクセサーは内部仕様そのもの及びその変化を表面に出さない長所あり

171 ：デフォルトの名無しさん：03/11/09 16:09

プリミティブ型のconst参照を返すのは馬鹿だろ

172 ：デフォルトの名無しさん：03/11/09 16:14

>>171
class range
を
template<class T>class range
に変えたとき
Tがプリミティブ型のときスペシャライズしてアクセサの仕様を変える馬鹿

173 ：デフォルトの名無しさん：03/11/09 16:17

template<class T>class range
を
class range
に変えたわけでもないのにint const& を返すようにしてる奴はﾊﾞｶでしょ

174 ：デフォルトの名無しさん：03/11/09 16:20

>>169
ただし、C++の場合はやむを得ずgotoを使うけれど、
JavaとかC#とかDとか後発の言語では、breakやcontinueで
多重ループ脱出ができるようになってる、ってことも
覚えておいて損はない。

175 ：デフォルトの名無しさん：03/11/09 16:21

>>173
流れをよく読め。
>>166が標準コンテナを問題にしているから
>>170はconst参照を返す例を挙げたんじゃないか。

176 ：デフォルトの名無しさん：03/11/09 16:32

>>173
int限定の話題じゃなくて
型を問わずアクセサーの話題でアクセサーには一時オブジェクト
かconst参照かどちらを返した方がいいかという話題

一時オブジェクトを返さなければならない場面もある例として
偶然intがでてきたからといって
intを前堤にして一時オブジェクトを返すのは馬鹿だとか言ってたら
論点ずれすぎ

177 ：デフォルトの名無しさん：03/11/09 16:34

>>171
電話帳プログラムのサンプルの中に「太郎」って名前があったとき
「太郎なんて名前は今どきいないだろ。
サンプル書いたプログラマーはいると思ってるから馬鹿だろ」
とつっこみ入れたのは君か

178 ：デフォルトの名無しさん：03/11/09 16:37

>>174
死者ぷーにはそんなすぐれた機能ありませんよ。

179 ：166：03/11/09 16:39

ご助言ありがとうございます。
もう少し具体的に書きます。

class Node {
public:
...
private:
list<Node *> link;
list<short> attr;
};

のような、複数のノードリンクを持つノードクラスとします。
前処理でノードの木構造は確定するものし、同時にattrも必要な値が格納されます。

後処理では、この木構造を「トラバース」し、ノードごとにattrを回収したりその他の処理をしたいのです。
今はlinkのconst_iteratorを提供し、外部で走査しています。

関数オブジェクトを受け取ってfor_eachするメンバ関数も検討しましたが、
イテレータの他にユーザ引数を複数取る関数オブジェクトが作れない。
また関数オブジェクトから再度for_eachを呼び出すような再帰構造が作れない。

以上の理由で、今のところlinkコンテナに直接アクセスする方法しか思いつかないのですが、
もっとエレガントな方法はないものでしょうか。
attrに関しては、168さんの言うとおりconst参照で十分ですね。失礼しました。

180 ：デフォルトの名無しさん：03/11/09 16:58

>>179
>イテレータの他にユーザ引数を複数取る関数オブジェクトが作れない。
これについては、関数オブジェクトのなかに引数を持ってしまえば解決できるんじゃない？

181 ：デフォルトの名無しさん：03/11/09 17:04

前処理とか後処理とかが通じるのは
その間に挟まれた本処理が明確になっているとき

182 ：デフォルトの名無しさん：03/11/09 17:06

>>179
＞ユーザ引数を複数取る関数オブジェクトが作れない
これの意味を明確にして、そして理由を言って下さい

183 ：デフォルトの名無しさん：03/11/09 17:07

std::pairやboost::tupleを使えば良いんじゃないの？

184 ：デフォルトの名無しさん：03/11/09 17:38

どっちかっつーとboost::bindでは

185 ：166：03/11/09 18:03

えっとですね、
外部で走査する場合は

void traverser(_SomeType &val, const Node *node, int level)
{
　for (Node::link_const_iter it = node->begin_of_link(); it != node->end_of_link(); ++it)
　　if (探索を続けるとき)
　　　traverser(val, *it, ++level);
}

てな感じになりますね。
ただしtypedef list<Node *>::const_iterator link_const_iterです。

恥ずかしながら関数オブジェクトは勉強中で経験が無いのですが、
struct NodeTraverserFunc : unary_function {
　bool operator()(const Node *);
　_SomeType val;
　int level;
};

こんな感じでしょうか？

186 ：166：03/11/09 18:04

（続き）
で、Nodeクラスに

traverser(_Function func)
{
　for_each(link.begin(), link.end(), func);
}

みたいな感じでトラバーサ専用メンバ関数を追加すると。

ただ、このoperator()()からNode::traverser(*this)みたいに再帰的に
呼び出すことは可能なんでしょうか？？

っていうかやってみりゃいいんですね．．．

187 ：デフォルトの名無しさん：03/11/09 18:21

for_eachから離れろよバカ

188 ：デフォルトの名無しさん：03/11/09 18:44

いいじゃん。for_eachでできる事は、iterator走査するよりfor_eachでやった方がいい。

189 ：166：03/11/09 20:17

>>187
別にfor_eachに拘ってるわけじゃないですよ。
他の方法でもいいです。
privateメンバのイテレータやらtypenameを多数publiｃにちりばめなくてすむよい方法について、
あなたの実践方法をよかったら教えてください。

190 ：デフォルトの名無しさん：03/11/09 20:27

void traverser( Functor f )
{
　f(this);

　for (Node::link_const_iter it = node->begin_of_link(); it != node->end_of_link(); ++it)
　　if (探索を続けるとき)
　　　traverser( f );
}

これでいいじゃん

191 ：デフォルトの名無しさん：03/11/09 20:33

>>185
class Node {
　...
　template<class F>
　void traverse( F& f ) { // fは子も探索したいならtrueを返す
　　if( f(*this) )
　　　std::for_each( link.begin(), link.end(), boost::bind(&Node::traverse,_1,f) );
　}
};

bind周りはオーバーロードの都合で実際は汚いキャストが必要だが。

192 ：191：03/11/09 20:34

かぶつた？

193 ：166：03/11/09 22:32

>>190 >>191
ありがとうございます。
>>190さんのはFunctor型を決めないといけないですね。
>>191さんのはテンプレートなのでその必要ないけど、boost判らない．．．＿|￣|○

でもできることは判りました。
もう少し試行錯誤してみます。

194 ：190：03/11/09 22:58

>>193
template< Functor >付けるだけだろ、アホみたいな突っ込みいれるなよ。
お前のコードにtemplateがなかったから省略したんだと思ってそのまま使っただけ。

195 ：デフォルトの名無しさん：03/11/09 23:11

C++というかdoxygenの質問です。

root-dir/A/include/*.h
/src/*.cc
root-dir/B/include/*.h
/src/*.cc
root-dir/C/include/*.h
/src/*.cc

のような階層でsourceが置かれていて、
このroot-dirで
% doxygen doxygen.conf
を実行すると、
（略）
No input read, no output generated!
と出ます。
恐らく深い階層まで覗きに行ってないんだと思いますが、
深いところまで覗きに行かせる設定ってありますか？

196 ：166：03/11/09 23:52

>>190
すんません、その通りです。
クラスのメンバをテンプレートにできることを知らなかっただけです。
その程度のスキルなので許してください。

とりあえず上手くいきました。
あと、>>187のおっしゃることがよく判りました。
for_eachは第三引数をコピーで受けるので、関数オブジェクトの状態を返せないのです。
従って、traverserは参照で受けて、その中で自分でループを回さないといけないですね。

今回もいろいろ勉強になりました。どうもありがとうございました。

197 ：デフォルトの名無しさん：03/11/09 23:58

> for_eachは第三引数をコピーで受けるので、関数オブジェクトの状態を返せないのです。
> 従って、traverserは参照で受けて、その中で自分でループを回さないといけないですね。

そんなこともないと思う。

198 ：デフォルトの名無しさん：03/11/10 00:10

for_eachは、走査対象がconst参照で使い物にならなかったような記憶がある

199 ：166：03/11/10 00:29

>>197
あああ、いまヘッダファイル見てきたら、for_eachは受け取った関数を返してますね。
でも今回のような再帰呼び出しだと、やはり参照の方がコスト的によいかも．．．

200 ：デフォルトの名無しさん：03/11/10 01:04

> for_eachは、走査対象がconst参照
んなこたぁない。

201 ：デフォルトの名無しさん：03/11/10 01:38

% doxygen doxygen.conf

そもそも -g で doxygen.conf は出したの？

202 ：デフォルトの名無しさん：03/11/10 01:48

-gで作ったの見ればすぐわかるよね。

203 ：デフォルトの名無しさん：03/11/10 01:57

>>195
> 恐らく深い階層まで覗きに行ってないんだと思いますが
なんでそう思うんだ。
INPUTとFILE_PATTERNSにどういう値を設定したのか書いてみろ。

どうせ空っぽだろ

204 ：デフォルトの名無しさん：03/11/10 02:02

>>195 >>201-203
誘導→http://pc2.2ch.net/test/read.cgi/tech/1065364445/l50

205 ：デフォルトの名無しさん：03/11/10 03:11

ところで、C++のクラス継承図ってみんなどうやって管理してる？
自分の場合、doxygenで生成させて、そのTreeで継承元クラスを
参照していたりするんだけど、ブラウザとエディタとの連携が
いまいちで、もうちょっと上手な工夫がないものか？と
悩んでいる。

206 ：デフォルトの名無しさん：03/11/10 03:14

「クラス継承図を管理する」ってのがピンとこないのですが、どんなことするのですか？
継承グラフを見るだけならdoxgygenで生成させるだけですけど、そうじゃないんですよね？

207 ：195：03/11/10 05:03

>201-203

% doxygen -g doxygen.conf

で作成した後doxygen.confを編集。
INPUT = .　（つまりroot-dir）
FILE_PATTERNS = *.cc *.h
に書き換え。

それで、例えば同様の作業を
root-dir/A/src/
の中でやればちゃんとHTMLが生成されるものの、
root-dirの中でやると
No input read, no output generated!
となるのです。
つまり、深いところを覗けていないのではないかと推測。

これ、いかに？

208 ：デフォルトの名無しさん：03/11/10 05:06

>>207
スレ違いだっつってんダロ。

209 ：デフォルトの名無しさん：03/11/10 05:10

>>207
その設定で「深いところを覗」きにいくのを期待できると申すかRECURSIVE

210 ：デフォルトの名無しさん：03/11/10 15:40

>205
doxygenの吐くHTMLを.chmに変換したらどう？

211 ：デフォルトの名無しさん：03/11/10 17:04

>>207
＞ INPUT = .　（つまりroot-dir）
バカ。.はカレントディレクトリだろ。何が「つまりroot-dir」だ。氏ね

212 ：デフォルトの名無しさん：03/11/10 17:16

class A
{
private:
int m;
friend class BinA;
class BinA
{
BinA(A &a)
{
a.m;
}
};
};
と
class A
{
private:
int m;
class BinA
{
BinA(A &a)
{
a.m;
}
};
friend class BinA;
};
でコンパイル結果が変わるんだけど、VC++6.0だから？

213 ：デフォルトの名無しさん：03/11/10 17:35

>>212
俺、VC++6.0持ってないからコンパイル結果がどう変わるのか言ってみて。

214 ：デフォルトの名無しさん：03/11/10 17:44

上だとfriendが効かなくて、「mにアクセス出来ない」とエラーになる。
下だと通る。

215 ：デフォルトの名無しさん：03/11/10 17:46

あぁ。なるほど。
ちなみに俺のVC7.1はぜんぜんもんだいない。

216 ：デフォルトの名無しさん：03/11/10 17:58

しかしこうするとどちらもエラーが出て通らない罠。

#if 0 // or 1
class A
{
private:
int m;
friend class BinA;
class BinA {
BinA(A &a) {
a.m;
}
};
public:
f(const A& a) {
BinA(a);
}
};

217 ：デフォルトの名無しさん：03/11/10 17:58

続き

#else
class A
{
private:
int m;
class BinA {
BinA(A &a) {
a.m;
}
};
friend class BinA;
f(const A& a) {
BinA(a);
}
};
#endif

int main()
{
A a;
a.f(a);
}

218 ：デフォルトの名無しさん：03/11/10 18:10

>215
やっぱ6.0の不具合か。情報サンクス

>216
それは単に必要な部分にpublicやconstがないからじゃないかな？

219 ：デフォルトの名無しさん：03/11/10 18:46

クラスのメンバ関数の定義で「クラス名：：」を省略する書き方ってないの？

class A
{
　A();
};

A::A(){}
↑
いちいちこの部分書くのがメンドクサイよ

220 ：デフォルトの名無しさん：03/11/10 18:59

>>219
class Aのスコープ中でコンストラクタの実体を定義してしまえ。

221 ：デフォルトの名無しさん：03/11/10 22:54

外部DLLとのインターフェースに抽象クラスを使ったCOMライクな
インターフェースを使おうと思ってます。VC++6.0です。
こんなかんじ

struct IHoge
{
virtual void WINAPI Foo(int&) = 0;
};

疑問なんですが、VC++以外のコンパイラでも同じバイナリ構造を作ってくれるかどうか
また、メンバ関数の引数に参照を使いたいのですが
これも他のコンパイラと互換性があるかどうかなんですが
どうなんでしょ?

222 ：デフォルトの名無しさん：03/11/10 23:27

>>221
COM使えよ

223 ：デフォルトの名無しさん：03/11/10 23:36

工エエェェ(´Д｀)ェェエエ工

224 ：212：03/11/10 23:39

もう一つ、以前どこかで見た気もしたけど
class B
{
protected: int m;
};
class D : public B
{
void f(B &b){b.m;}
};
D内でBのインターフェイスからBのprotectedにアクセス出来ないのは言語仕様？

225 ：デフォルトの名無しさん：03/11/10 23:43

>>221
gccはvtableの持ちかたがVCと違うから上手く動かない、とどっかで聞いた気がする。

226 ：デフォルトの名無しさん：03/11/10 23:48

>>224
仕様でふ

thisがDを知らない

227 ：226：03/11/10 23:49

失礼、bがDの中とは限らない

228 ：デフォルトの名無しさん：03/11/11 00:03

拡張子がexeなものをコンパイルしたいのですが　-etest
でやっても出来ない..｡ﾟ(ﾟ´Д｀ﾟ)ﾟ｡
どうしたらいいでしょう？

229 ：デフォルトの名無しさん：03/11/11 00:07

>>221
　Intel Compiler は ABI だかなんだかが同じで VC とは互換性があるみたい。
でも COM の interface 考えると、Windows 用の普通のコンパイラならどれでも
そういった単純な vtbl 参照は普通にできそうだけど。。。

230 ：221：03/11/11 00:08

>>225
gccで調べてみたらこんなの見つかりました。
ttp://www.tietew.jp/cppll/archive/1907
gcc以外のコンパイラなら大丈夫っぽい

231 ：221：03/11/11 00:16

>>229
どうもです。どうやら大丈夫っぽいっす。

参照引数の方はどうなんでしょうかね?
アセンブラで見てみたらVC++はポインタを渡してるみたい。
他はどうなのかな?
ポインタ渡しにした方が無難ですかね?

232 ：デフォルトの名無しさん：03/11/11 00:18

なんでCOMにしない？

233 ：221：03/11/11 00:27

>>232
そんな大袈裟にするほどの物ではないから。
っていうか作り方よくわからん。

234 ：デフォルトの名無しさん：03/11/11 00:27

>>232
COMの肝を押さえときたいんだろ
わかるよ気持ち

235 ：デフォルトの名無しさん：03/11/11 00:32

今時COMの肝を抑えても無駄な気がするけど

236 ：デフォルトの名無しさん：03/11/11 00:37

>>219
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1420.pdf

237 ：219：03/11/11 02:20

すばらしい！

でもVC6じゃダメっぽいですよ！

238 ：デフォルトの名無しさん：03/11/11 03:19

前スレ終了 age

239 ：デフォルトの名無しさん：03/11/11 04:51

前スレ>>999ﾜﾛﾀ氏ね

240 ：デフォルトの名無しさん：03/11/11 04:56

>>237
まだ提案の段階だからね。

241 ：デフォルトの名無しさん：03/11/11 12:59

書式付きの文字列が欲しいのですが、どうするのがC++っぽいですか？
たとえばHogeXX (XXは数字)という文字列を欲しいとき、
漏れが危険を承知でやったのが次の通り。
string *st = new string(16);
sprintf(const_cast<char *>(st->c_str()), "Hoge%02d", num);

242 ：デフォルトの名無しさん：03/11/11 13:12

>>241
char st[7]; でいいじゃねーか。なんでわざわざ危険を冒すのかね？

// C++
std::ostringstream formatter;
formatter << "Hoge" << std::setw(2) << std::setfill('0') << num;
std::string st = formatter.str();

// C++ boost
std::string st boost::io::str( boost::format( "Hoge%1$02d" ) % num );

243 ：デフォルトの名無しさん：03/11/11 13:23

// C++ boost
std::string st = boost::io::str( boost::format( "Hoge%02d" ) % num );

244 ：デフォルトの名無しさん：03/11/11 13:38

gcc3.3ではmakeできるのですが、Solaris CC ですと ios_base.h がないため
_Ios_Fmtflags が使えません。多分 int を使えば良いと思うのですが、
コンパイラーごとに型を変えるプログラムってどうやって書けばいいのでしょうか

245 ：デフォルトの名無しさん：03/11/11 13:46

ageわすれた

246 ：デフォルトの名無しさん：03/11/11 16:18

>>244
普通 ios_base::fmtflags で使うと思うけど？
_ で始まる奴は環境依存だから無くて当たり前（ある時もあるけど）。

247 ：デフォルトの名無しさん：03/11/11 16:38

つぅかいまどき.hつきのヘッダなんぞ使うな

248 ：肉 ◆KZBEEFEAtA ：03/11/11 17:23

>>246
そうなんですか。Solaris だと ios_base という

249 ：248：03/11/11 17:28

とちゅうで送ってしまった。

そうなんですか。Solaris だと ios_base という header はなくて他のところに
あるんですね。

>>247
確かに、.h つきはもう使ってはだめですね。

ところでもう一つ質問ですが、gcc3.3 では setiosflags がコンパイル通るのですが
CC ですと

Error: The function "setiosflags" must have a prototype.

とエラーがでて使えません。ちゃんと header file を <iomanip> を読んでいるのですが
なぜダメなんでしょうか？

250 ：デフォルトの名無しさん：03/11/11 18:18

>>249
grep して setiosflags がどのファイルにもないなら、
コンパイラが古くて setiosflags マニピュレータが
実装されてないんじゃないかな。
だから、setf を使うか、自分でマニピュレータを実装するか、やね。

>>247
gcc だと bits/ios_base.h で定義されてるのね。
で、ios は bits/ios_base.h をインクルードしてる。
ios_base.h を直接使うわけじゃない。

251 ：デフォルトの名無しさん：03/11/11 18:28

>>250
もしかして　namespace が原因かも！
std::着け忘れてた

252 ：デフォルトの名無しさん：03/11/11 19:05

>>251
やっちゃったかも！

253 ：デフォルトの名無しさん：03/11/11 23:35

>>251
うにょ～ん。

254 ：デフォルトの名無しさん：03/11/11 23:37

うー、おいらもその手のケアレスミス、多いくて悩んでるぞ～

255 ：デフォルトの名無しさん：03/11/11 23:50

けあれすういすぱー

256 ：デフォルトの名無しさん：03/11/12 00:23

うぉううぉうぉー

257 ：デフォルトの名無しさん：03/11/12 00:33

ガオーガオー

258 ：デフォルトの名無しさん：03/11/12 02:28

ｵｶﾞｰｻﾞｰｰﾝ

259 ：デフォルトの名無しさん：03/11/12 04:04

うちのチームにもいるよ。その手のニアミス・バカが。
でも安心しろ。そいつは東大卒だ。（マジネタ）

260 ：デフォルトの名無しさん：03/11/12 08:26

↑真ニアミス・バカ

【名-1】ニアミス、（航空機の）異常接近、衝突危険、危機一髪、至近弾、目標に極めて近い成果
【名-2】成功の一歩手前、いま一歩、もう一歩のところ、惜しい失敗

261 ：デフォルトの名無しさん：03/11/12 11:07

別に間違ってないような。

262 ：デフォルトの名無しさん：03/11/12 11:10

CCで Member templates not implemented ってでるんですか
これってなんなんですか？

何がエラーなのかさっぱりわかりません

263 ：デフォルトの名無しさん：03/11/12 11:26

>>262
メンバ関数テンプレートは（このコンパイラは）実装していません、ってことなんじゃ？

264 ：デフォルトの名無しさん：03/11/12 11:50

>>263
じゃあ、そのクラスを継承してすべての型に対してメンバー関数を定義しなくちゃいけないの？
そんなめんどい事をCCではやらなきゃいけないのか…

265 ：デフォルトの名無しさん：03/11/12 12:30

>>264
>そんなめんどい事をCCではやらなきゃいけないのか
>そんなめんどい事をCCではやらなきゃいけないのか
>そんなめんどい事をCCではやらなきゃいけないのか
>そんなめんどい事をCCではやらなきゃいけないのか

266 ：デフォルトの名無しさん：03/11/12 13:53

>>265 言いたい事があるのならはっきりいえよ。臆病者。

267 ：デフォルトの名無しさん：03/11/12 19:26

>>262
Member templates not implemented というと、こういうのか？

class ogrish
{
template <class green> void trainhit(green);
};

M$のｺﾝﾊﾟｲﾗだと
template <class green> void ogrish::trainhit(green neesan)
{
}

ができないのがある。（詳しくはリリースノートを見れ）

268 ：デフォルトの名無しさん：03/11/12 19:29

>>266
自分で考えろ

269 ：デフォルトの名無しさん：03/11/12 19:57

>>268
>自分で考えろ
>自分で考えろ
>自分で考えろ
>自分で考えろ

270 ：デフォルトの名無しさん：03/11/12 20:29

#include<iostream>
using namespace std;

int main(){
unsigned char *p;
//unsigned char cell[256][256][256];
unsigned char nx,ny,nz;
p= new cell[256][256][256];
if(p){
cout << "Memory was allocated.\n";
}else{
cout << "Can't allocate memory.\n";
}
delete p;
return 0;
}

これをコンパイルすると、
:8: parse error before `['
とでてきます。なぜだか全くわかりません。どなたか教えてください。
ちなみに、エラーはここだけです…

271 ：デフォルトの名無しさん：03/11/12 20:39

>>270
p= new cell[256*256*256];

272 ：デフォルトの名無しさん：03/11/12 20:40

>>270
cellの宣言がないだろ(ﾟДﾟ)ｺﾞﾙｧ!!

273 ：デフォルトの名無しさん：03/11/12 20:40

>>270
newは失敗してもNULLを返さないぞ

274 ：デフォルトの名無しさん：03/11/12 20:41

>>271thx!なんか殺伐としてますけど、相談室として活用させて下さいまし…

275 ：デフォルトの名無しさん：03/11/12 20:41

newがNULLを返すようにするにはnew (nothrow) とする必要がある。

276 ：デフォルトの名無しさん：03/11/12 20:48

>>270
cell (*p)[256][256];
p = new cell[256][256][256];
delete[] p;

277 ：デフォルトの名無しさん：03/11/12 20:49

p= new cell[256][256][256];
これを
p= new(nothrow) unsigned int[256*256*256];
としたらうまくいきました。ちょっと急ぎなもので…こんなことに
みなさまのお知恵をお借りして済みません。
ありがとうございます。

278 ：270：03/11/12 20:54

やっぱりうまくいきませんです…もうすこし頑張ってみます…

279 ：270：03/11/12 21:02

#include<iostream>
using namespace std;

int main(){
unsigned char *cell;
unsigned char nx,ny,nz;
cell=new unsigned char [256*256*256];
if(cell){
cout << "Memory was allocated.\n";
}else{
cout << "Can't allocate memory.\n";
}
delete cell;
return 0;
}

うまく逝きました。

280 ：デフォルトの名無しさん：03/11/12 21:57

>>270
delete[] cell;
つってんだろｺﾞﾙｱ!!

281 ：デフォルトの名無しさん：03/11/12 21:57

確かに逝ってる。
delete[] cell;

>273
VC++6.0ですが何か。

282 ：デフォルトの名無しさん：03/11/12 22:05

VC++6.0 is not C++ Compiler.

283 ：デフォルトの名無しさん：03/11/12 22:13

冠詞のない英文は違和感が残るのう。

284 ：デフォルトの名無しさん：03/11/12 22:13

cfront is not C++ translator.

285 ：デフォルトの名無しさん：03/11/12 22:14

GNU is not UNIX

286 ：デフォルトの名無しさん：03/11/12 22:18

My father is my mother.

287 ：デフォルトの名無しさん：03/11/12 22:22

チンコ is very strong.

288 ：デフォルトの名無しさん：03/11/12 23:12

>>281
ちょっとVC++6.0と言うのが遅い。もう古いし。

289 ：デフォルトの名無しさん：03/11/12 23:44

typedef cell cellarray[256][256]
cellarray* p = new cellarray[256];

これでもダメ？

290 ：デフォルトの名無しさん：03/11/12 23:54

XINA is not assembler

291 ：デフォルトの名無しさん：03/11/12 23:55

>>265はCCが何のことなのか知らないだけだろ。

292 ：デフォルトの名無しさん：03/11/13 00:04

>>290
XINA知ってる人は少ないと思うぞ…

293 ：デフォルトの名無しさん：03/11/13 14:16

class C {
// : いろいろ定義
};
つーのがあるときに
C* p = new C; // って言う記述と、
C* p = new C(); // って言う記述は、等価?

struct S {
// : いろいろ定義
};
つーのがあるとき、
S* p = new S; // って言う記述と、
S* p = new S(); // って言う記述は、等価?

294 ：デフォルトの名無しさん：03/11/13 14:25

>>293
等価。

ついでにいうと、class と struct はデフォルトでメンバが
public になるか private になるかの違いがあるだけで、後は全く同じもの。

295 ：デフォルトの名無しさん：03/11/13 14:36

>>294
structってメンバ関数定義できたっけ？

296 ：デフォルトの名無しさん：03/11/13 14:39

出来る、294が書いてるようにアクセス制御が違うだけ。

297 ：デフォルトの名無しさん：03/11/13 15:54

>>293
非等価。
初期化されていない POD 型メンバの扱いが変わる。
( ) を付けると初期化されていない POD 型メンバの
デフォルトコンストラクタも呼ばれ、
例えば int a; というメンバがあれば、0 で初期化される。
( ) を付けないと 0 で初期化されない。
また、new int と new int() など、
POD 型を直接 new する場合も同様になる。

でも、実用上、初期化していない POD メンバは
初期化しなくても動作するように組まれている筈なので
等価と言っても構わない。

>>294
他には
　○ template<class TYPE>
　× template<struct TYPE>
という違いも。

298 ：デフォルトの名無しさん：03/11/13 15:56

補足
　POD 型を直接 new する場合には、
　この違いを意識する場合があるかもしれない。

299 ：デフォルトの名無しさん：03/11/13 15:58

>>297
二つ目の指摘はclassキーワードを使いまわしただけなのでこの場合は不適かと。
ただし、以前のVC++ではtemplate<class T>に対してstructを渡すことが出来なかった。

300 ：デフォルトの名無しさん：03/11/13 16:04

>>297
手元の VC7.1 では class でも struct でも同様の結果だったけどこれは単に VC7.1 が不適合なだけ？

301 ：デフォルトの名無しさん：03/11/13 16:08

>>297
( ・∀・)つ〃∩ﾍｪｰﾍｪｰﾍｪｰ

いやごめん。ちょっと役立ちそうな知識だから、
( ・∀・)つ〃∩ ｶﾞｯﾃﾝ!ｶﾞｯﾃﾝ!ｶﾞｯﾃﾝ!
にしとくわ。

302 ：デフォルトの名無しさん：03/11/13 16:12

テンプレートで使うことがたまにあるぽ。
new TYPE() って感じに。

303 ：デフォルトの名無しさん：03/11/13 16:29

>>297
new S と new S() の違いは知らなかった。
確かに G++3.2 では違うコードが出力されている。
（でもどう違うかはわからん）
g++2.91 と 2.95 では全く同じコードが生成された。
うーん、何のためにこんな仕様になってるんだろう。
int() なんかは理解できるけど。

304 ：300：03/11/13 16:31

ゴファッ！
元質の意味を勘違いしてた。
struct/classの違いかとおもてたーよ。

>>303
>>302参照

305 ：デフォルトの名無しさん：03/11/13 17:07

>>297
>例えば int a; というメンバがあれば、0 で初期化される。
>でも、実用上、初期化していない POD メンバは
>初期化しなくても動作するように組まれている筈なので

つまり()付きは実行速度上不利でつか？（現実問題として無視できる処理時間だったとしても）

306 ：デフォルトの名無しさん：03/11/13 18:39

C++のソースファイルやヘッダファイルのファイル間の
依存関係を出力してくれるツールってありませんか?

307 ：デフォルトの名無しさん：03/11/13 18:42

>>305
つうかそれ位asmコード吐かせればすぐ分かるだろ

308 ：デフォルトの名無しさん：03/11/13 18:42

>>306
doxygen

309 ：デフォルトの名無しさん：03/11/13 18:52

>>297
それは脳内仕様ではなく、ANSIか何かの規定ですか？
少なくとも bcc 5.5.1 では、>>297はダウトでした。

310 ：306：03/11/13 19:01

>308
doxygenで解決できそうです
ありがとうございました

311 ：デフォルトの名無しさん：03/11/13 19:55

もし、仕様上 new S() と new S の動作に>>297のような違いがあるとする。
ならば、ヒープではなくスタックやグローバル領域に確保したオブジェクトにも
同様な使い分けが出来るはず。(メンバ初期化動作の違いなのだから)

S obj;　これはいい。
S obj();　こうは書けない。

どう書けばPOD初期化を伴うコンストラクタを呼び出せるのだろうか。

312 ：デフォルトの名無しさん：03/11/13 20:25

struct A{
int a;
};

int main(){

A *a=new A();
printf("%d\n",a->a);
}

VC7.0での結果

-842150451

>>297は大法螺吹きの予感・・・

313 ：デフォルトの名無しさん：03/11/13 20:28

>>311

>>297がウソテクかどうかは置いておくとして、

S obj=S();

と書けば呼べると思う。

314 ：デフォルトの名無しさん：03/11/13 20:29

コンパイラが用意したデフォルトコンストラクタは「何もしない」んじゃなかったっけ？
だから>>312は正解だと思う。

315 ：デフォルトの名無しさん：03/11/13 20:30

ちょっと質問なんだけど。
C++でconst変数を定数として使う時
複数のﾌｧｲﾙで使い回したい時はどうすればよいのでしょうか。

316 ：デフォルトの名無しさん：03/11/13 20:31

>>315
ヘッダファイルに書け

317 ：デフォルトの名無しさん：03/11/13 20:32

>>315
ふつうにヘッダに
static const int HOGE = 100;
とか書いておけば。

318 ：デフォルトの名無しさん：03/11/13 20:35

本当に仕様で決まっているのか、それとも
gccの処理系固有動作(確かにgcc3.xxでは初期化された)を
まるで言語仕様であるかのごとく言い放っているだけなのか。

だいたい、引数付きのコンストラクタはどうやって使い分けるんだろ。

319 ：デフォルトの名無しさん：03/11/13 20:35

>>317
それで複数のﾌｧｲﾙからそのﾍｯﾀﾞ読んだ時
多重定義とならない？
後、ｸﾗｽのﾒﾝﾊﾞ変数の配列の宣言とかもその定数？でやりたいんだけど。

320 ：デフォルトの名無しさん：03/11/13 20:37

>>319
const付けてるとならない

321 ：デフォルトの名無しさん：03/11/13 20:38

>>319
static の文字が見えないのかい？

322 ：デフォルトの名無しさん：03/11/13 20:38

>>319
じゃあヘッダのにはextern付けて、どっかのcppに一つだけ実体化されるように書けば

323 ：デフォルトの名無しさん：03/11/13 20:43

>319
static無しの
const int HOGE = 100;
で行けるはずだけど？
ただし浮動小数点定数はヘッダで初期化できないんだっけ？

324 ：デフォルトの名無しさん：03/11/13 20:46

コンパイラにとってヘッダなんぞ存在しないはずだが。

325 ：315：03/11/13 20:49

>>320
ヘッダを複数のファイルで読んでもconst変数だと、怒られませんですた。
どうも失礼しマスタ。

326 ：デフォルトの名無しさん：03/11/13 20:49

>>311
>S obj();　こうは書けない。

プロトタイプ宣言だな（藁

327 ：323：03/11/13 20:53

あー浮動小数点が使えないのはクラス内定数だったっけ。

328 ：デフォルトの名無しさん：03/11/13 21:04

int i = int();// i = 0に初期化
POD s = POD(); //sは初期化されないまま

329 ：デフォルトの名無しさん：03/11/13 22:17

それ自体には、ユニークな識別子がないデータがあります。
これを何通りかに並び替えて、さらにその並び順をそれぞれ
記憶しておく必要があるのですが、どういう風に実現するのが一番良いでしょうか？

今はデータに後からIDを振っておいて、並び順はそのIDのみ保存しているのですが
初期化したり、データを削除するたびに大げさな事になりまして…。

330 ：デフォルトの名無しさん：03/11/13 22:22

>>312
一瞬、>>312 が釣りでもしてるのかと思ったけど、
>>297 をよく読んでみたら確かに >>297 が知ったかぶってアホな事書いてるｗ

331 ：デフォルトの名無しさん：03/11/13 22:22

>>329
並び順保持するためのコンテナいくつか作って
データ自体はshared_ptrで共有したら？

332 ：デフォルトの名無しさん：03/11/13 22:36

>>331
レスありがとうございます。
どちらかというと、データが消えたことをデータを参照している方へ
通知する必要がありまして…逆shared_ptrがあればなぁ。

そしてすいません、大事な所が抜け落ちてました。
並び順をファイルに保存しておく方法でも悩んでいます。
やはりIDを振る方法が、一番得策なのでしょうか？

333 ：デフォルトの名無しさん：03/11/13 22:45

大法螺吹きは312だぞお前ら。
この問題は7.1で標準準拠になった点、ヘルプにも書いてある。
7.1ではちゃんと初期化される。

334 ：デフォルトの名無しさん：03/11/13 22:52

>>333
という事はデフォルトコンストラクタは変数は初期化してくれるけど、
初期化用の関数は呼んでくれない(newで動的に確保しなければならない
など)わけだよな。やっぱり明示的に書いた方が良くない？

335 ：デフォルトの名無しさん：03/11/13 23:00

>>334
初期化用の関数って何？

336 ：デフォルトの名無しさん：03/11/13 23:02

>>334
>デフォルトコンストラクタは変数は初期化してくれる
>初期化用の関数

意味がさっぱりわかりません。

(初期化用の関数って、もしかしてコンストラクタのことか？)

337 ：デフォルトの名無しさん：03/11/13 23:15

・コンパイラが提供するデフォルトコンストラクタは、メンバ変数を初期化してくれる。
・ただしあからさまにコンストラクタから明示的に呼び出さなければならない関数
があっても、デフォルトコンストラクタはそれを呼んでくれない。

以上。

338 ：デフォルトの名無しさん：03/11/13 23:18

>>332
weak_ptr使ったら？
保存するならid振るべきだね。正規化とか勉強したら？

339 ：デフォルトの名無しさん：03/11/13 23:40

>>338
キーワードありがとうございました。
早速正規化について勉強してみます。ようやく前に進める…。

ID振る方法もベターな様でこちらもホッとしています。

340 ：デフォルトの名無しさん：03/11/14 00:05

>>337
>ただしあからさまにコンストラクタから明示的に呼び出さなければならない関数

ってなんのことですか？

341 ：デフォルトの名無しさん：03/11/14 00:21

>>337
せっかく297でPODってキーワードが出てるんだから、調べてみれば？
自分語で説明しようとしても、泥沼にはまっていくばかり。

342 ：デフォルトの名無しさん：03/11/14 00:27

C++よりまず日本語を

343 ：デフォルトの名無しさん：03/11/14 00:29

>自分語で説明
>>337のことですね。

344 ：デフォルトの名無しさん：03/11/14 00:39

>>340
知ってて嫌がらせしてるのが見え見え。

345 ：デフォルトの名無しさん：03/11/14 01:02

>>344
わからないからきいてるんですけど。
２ちゃんねるだからって穿った見方し過ぎ。

346 ：デフォルトの名無しさん：03/11/14 01:45

>>333
>>312は大法螺なんて全然吹いてないぞ。よく読んでみろ。どこにホラがある？
で、>>333が正しかったとして（すまんが確かめようがない）>>297は不親切だな。

347 ：デフォルトの名無しさん：03/11/14 03:48

細かいところは省略して、規格から抜粋。

5.3.4.15

T のオブジェクトを作る new-expression は、オブジェクトを次のように初期化する。
・new-initializer が省略された場合
　・T が non-POD クラス型（もしくはその配列。cv-修飾子がついてても良い）の場合
　　オブジェクトはデフォルト初期化される。
　・その他の型の場合
　　未定義になる。
・new-initializer として () がつけられたら、デフォルト初期化される。

8.5.5

デフォルト初期化は次のような処理である。
・non-POD クラス型の場合、デフォルトコンストラクタが呼ばれる。
・配列の場合は、各要素がデフォルト初期化される。
・それ以外の場合は０で初期化される。

つまり、
・POD クラス型や POD 型なら >>297 は合っている。
・non-POD クラス型なら >>297 は間違っている。

でファイナルアンサー？

348 ：デフォルトの名無しさん：03/11/14 10:43

>>347
>>297は元々PODについてのみの言及なので、その理屈では間違いじゃないでしょう。
問題（？）なのは、その仕様に沿ってないコンパイラもまだ多くあるので注意、ってことでFA?

349 ：デフォルトの名無しさん：03/11/14 10:50

> >>297は元々PODについてのみの言及なので、
どこが？

350 ：デフォルトの名無しさん：03/11/14 13:03

PODふかして急上昇
高く尾を引くヒコーキ雲ねー

351 ：デフォルトの名無しさん：03/11/14 14:03

POD == Plain Old Data

352 ：デフォルトの名無しさん：03/11/14 14:15

POD == Perl Old Document

353 ：デフォルトの名無しさん：03/11/14 14:26

PODの定義って、

・ユーザー定義のコンストラクタ・デストラクタ・代入演算子を持つものは
non-PODである
・non-PODのメンバを持つものはnon-PODである
・non-PODでないものはPODである

こんな感じ？

354 ：デフォルトの名無しさん：03/11/14 17:11

>>353
・メンバへのポインタはnon-PODである。
・参照はnon-PODである。

ユーザー定義のコンストラクタは持っててもOKだった記憶が。

355 ：デフォルトの名無しさん：03/11/14 17:41

>>349
一貫してPOD、PODって言ってるじゃん

356 ：デフォルトの名無しさん：03/11/14 18:02

>>355
「POD class」について確かに言及されているが、それより広い
「PODメンバを持つclass」についても(間違った)言及をしてるように
読めるのだが。

357 ：デフォルトの名無しさん：03/11/14 18:03

vectorってeraseしただけじゃメモリ解放されないんですか？
自分で作ったクラスをvector型で定義してるんですけど、
push_backとeraseを繰り返しているうちに使用メモリ量が増えていってるっぽいんですけど・・・

358 ：デフォルトの名無しさん：03/11/14 18:06

もっと詳しく書いて。
多分あんたのクラスの開放の仕方が悪いだけ。

359 ：デフォルトの名無しさん：03/11/14 18:19

std::vectorのeraseがメモリを開放しないのはとても有名な話だが、
自作クラスのデストラクタが腐ってる可能性のほうが高そうだな。

360 ：デフォルトの名無しさん：03/11/14 18:38

VC6のstd::queue::eraseが腐っててこまったことはあるので、
同じ現象かも。環境は？>>357

361 ：３５７：03/11/14 19:27

環境は、
Solaris2.6
gccは2.8.1
です。

InfoクラスとPeerクラスという二つの自作クラスがあります。
Peerクラスの中でInfoクラスをvectorで宣言しています。

Infoクラスではint型を2つ宣言しています。
デストラクタも宣言していますが、中では何も行っていません。

といった感じです・・・

362 ：デフォルトの名無しさん：03/11/14 20:23

コードさらさなきゃ、何も言えんな。
脳内でSTLのバグってことにしたいなら別だが。

363 ：デフォルトの名無しさん：03/11/14 20:39

vectorの宣言と、erase周りの数行だけ見てみたいかな

364 ：デフォルトの名無しさん：03/11/14 20:58

>>359
仕様とバグのクベツワカリマスカ？

365 ：３５７：03/11/14 21:01

これがInfoクラスです

class Info
{
int ip;
int id;

public:

Info();
Info(int p, int d);
~Info();

void set_ip(int p);
void set_id(int d);

int get_ip();
int get_id();
};

366 ：３５７：03/11/14 21:08

これがMobile_peerクラスです。
（さっきはPeerクラスって言いましたけどすいません）

class Mobile_peer
{
Info peer_me; //自分のIPとID

Info peer_parent; //親ピア
vector<Info> peer_child; //子ピア
vector<Info> peer_in_area; //同エリアにいるピア
vector<Info> peer_in_other; //外部から接続してきているピア

　　　　　　　　　　：
　　　　　　　　　　：

てな感じでvectorを宣言してます

367 ：デフォルトの名無しさん：03/11/14 21:12

なんかinfoがクラスである必然性が薄い気もするが。
それはともかく、swap技法使っても肥大化するのか？

368 ：３５７：03/11/14 21:14

で、Mobile_peerクラスの関数内でデータの追加、削除を行うようにしてます。

void Mobile_peer::set_peer_child(Info info)
{
peer_child.push_back(info);
}

ｖoid Mobile_peer::remove_peer_child_by_id(int id)
{
vector<Info> ::iterator p;
p = peer_child.begin();

for(int index = 0; index < peer_child.size(); index++)
{
if(id == peer_child[index].get_id())
{
p += index;
delete *p;
peer_child.erase(p);
break;
}
}
}

369 ：３５７：03/11/14 21:16

>>367
swap技法とは？
すいません、ほんと何も知らないもので・・・

370 ：デフォルトの名無しさん：03/11/14 21:20

>>369
Effective STL日本版P76を見よ。

371 ：デフォルトの名無しさん：03/11/14 21:21

>delete *p;

？？？

372 ：デフォルトの名無しさん：03/11/14 21:25

具体例を挙げれば、例えば

std::vector<Hoge> v;
v.reserve(10000);

とした時、v.erase()を実行しても予約済みの領域は開放されない。
そこで、
vector<Hoge>(v).swap(v);

とやって、v.capacity()を見てごらん。

373 ：３５７：03/11/14 21:28

>>370
ありがとうございます！

374 ：３５７：03/11/14 21:30

>>371
あ～それは、そうやれば領域をデリートできるかなと思って書いた行です。
コンパイルできませんでした。

>>372
試してみます。
ありがとうございます

375 ：デフォルトの名無しさん：03/11/14 21:30

え？swap技法で解決するような問題か？

376 ：デフォルトの名無しさん：03/11/14 22:03

>>372
すいません。それは何をやってるんですか？

377 ：デフォルトの名無しさん：03/11/14 22:44

>>376
Effective STL日本語版に詳しく書いてあるのですが、持っておられない
ようなので、簡単に書きます。

std::vector<Hoge>(v) とすると、std::vectorのコピーコンストラクタが呼び
出され、「コピー対象に必要な分だけのメモリ」を割り当てます。この一時
vectorとガラガラに空きがあるvectorを交換すると、vectorは余分な領域が
無くなり、余分な領域は一時vectorの方に移動します。この後一時vector
は破棄され、その時に余分な領域も一緒に消滅します。

378 ：デフォルトの名無しさん：03/11/14 22:51

>>377
ありがとうございます。すごいですね。

379 ：デフォルトの名無しさん：03/11/14 22:57

>>378
std::vectorのreserve領域を簡単に削れるメンバ関数がない方が問題。

380 ：デフォルトの名無しさん：03/11/15 02:56

EUC<->SJIS変換を行うコンパクトなライブラリって何ですか？
iconvはでかいしWindowsに標準で付いて無いので却下。

381 ：デフォルトの名無しさん：03/11/15 03:00

作れば？
SJIS<->JISの変換は難しくないし
JISの上位ビットを立てればEUCでしょ(半角かな以外)

382 ：381：03/11/15 03:06

std::string KanjiCodeConvertor::euc2Sjis(const std::string &str)
{
　BYTE c1, c2 = 0;
　std::string ret(str);
　
　std::string::const_iterator it = str.begin();
　std::string::iterator itDest = ret.begin();

　std::string::const_iterator end = str.end();
　while(it != end)
　{
　　c1 = *it++;
　　if(c1 < 0x80)
　　{
　　　++itDest;
　　　continue;
　　}
　　else if(it == end)
　　　break;
　　c2 = *it++;
　　if(c1 == 0x8E)
　　{
　　　++itDest;
　　　continue;
　　}
　　eucToSjisSub(&c1, &c2);
　　*itDest++ = c1;
　　*itDest++ = c2;
　}
　return ret;
}

383 ：380：03/11/15 03:07

inline void eucToSjisSub(BYTE *kj1, BYTE *kj2)
{
　if (*kj1 & 0x01) {
　　*kj1 >>= 1;
　　if (*kj1 < 0x6F)
　　　*kj1 += 0x31;
　　else
　　　*kj1 += 0x71;
　　if (*kj2 > 0xDF)
　　　*kj2 -= 0x60;
　　else
　　　*kj2 -= 0x61;
　} else {
　　*kj1 >>= 1;
　　if (*kj1 < 0x6F)
　　　*kj1 += 0x30;
　　else
　　　*kj1 += 0x70;
　　*kj2 -= 0x02;
　}
}

384 ：380：03/11/15 03:07

一応>>381-382のように自分で書いてみたんですが強烈に重いんです…

385 ：380：03/11/15 03:08

×>>381-382
○>>382-383

386 ：デフォルトの名無しさん：03/11/15 03:14

string::iteratorやstring::begin()はかなり重い処理をしていた気がする。
一度vector<char>にコピーしてからやってみては？

387 ：デフォルトの名無しさん：03/11/15 03:18

あと、細かいことだけど。
BYTE型の変数のアドレスを取って渡してるけど
こうするとレジスタ変数にならなくなる。
もしかしたらシフトしてint１つ渡し、戻り値もintにして、
受け取った側でシフトとマスクで展開した方が速くなるかもしれないよ。

388 ：デフォルトの名無しさん：03/11/15 03:20

あ、inline指定してあるから
アドレスを受け取るんじゃなくて参照で受け取るなら
コンパイラが最適化してくれるかも。

389 ：380：03/11/15 03:38

ありがとうございます。眠いので明日試してみます

390 ：デフォルトの名無しさん：03/11/15 04:29

c1 = *it++;
　　↓
c1 = *it;
++it;

とか、前置の方がコピー作らなくていいから速いんじゃないの？

391 ：デフォルトの名無しさん：03/11/15 05:16

BYTE c1, c2 = 0;
std::vector<char> ret;
ret.reserve(str.length());// SJIS->EUCなら２倍確保
const char *it = str.c_str();
const char *end = it + str.length();
char *itDest = &ret[0];
// 中略
return std::string(&ret[0], itDest - &ret[0]);

こうするだけで全然違うと思う。
ただ、このままだと「現実的に問題になる実装はないけど、厳密には未定義」な動作になる。
速度最優先ならこのまま、規格厳守なら
reserve()->resize(), c_str()->vector+copy()+begin()等の修正を。

392 ：デフォルトの名無しさん：03/11/15 06:11

そこまでして string をメリットってあるかな。
char 配列でいいじゃん。

393 ：デフォルトの名無しさん：03/11/15 08:46

>>380
http://tricklib.com/cxx/ex/babel/

そのまま使うとデカイので参考までに。
>>383 の処理だけではちゃんと変換できない部分を
正しく変換する為に変換テーブルが使用されています。

394 ：デフォルトの名無しさん：03/11/15 09:33

for(it = v.begin(); it != v.end(); ++it)

とかする場合の前置++。
みなさんはint等の組み込み型も前置に統一してますか?

395 ：デフォルトの名無しさん：03/11/15 10:07

>>394
統一しない理由がないので統一してます。

396 ：デフォルトの名無しさん：03/11/15 11:03

統一しない理由が無いので統一してません。

397 ：デフォルトの名無しさん：03/11/15 11:26

>>392
例外安全にならないんで

398 ：デフォルトの名無しさん：03/11/15 12:40

>>394
operatorなら当然前置だが
ポインタの++が前置になってるの見ると違和感を覚える
アセンブラっぽい考え方してると、そんなのねえよって

399 ：デフォルトの名無しさん：03/11/15 13:08

>>398
> アセンブラっぽい考え方してると、そんなのねえよって
PDP-11 のアセンブラに従って，インクリメントは後置，デクリメントは前置で統一してるのか？

400 ：デフォルトの名無しさん：03/11/15 14:07

>>397
そんなことはねぇぞ。

401 ：デフォルトの名無しさん：03/11/15 15:48

なんかこのスレ最近俺C言語スレに似てきたな。。。

402 ：デフォルトの名無しさん：03/11/15 16:45

>>401
C++は母胎がCだからしょうがない。でもC++独特の話題にしたいねえ。

403 ：デフォルトの名無しさん：03/11/15 19:25

静的変数を使用するとき、staticメンバ変数を使うのと、
無名namespaceのファイルスコープ変数を使うのと、どっちがいいだろう？

どうせgetter/setter経由でしかアクセスしないから、staticメンバにしても無名namespace内に置いても外側からの見た目は変わらないのよ。
んで、
staticにすることのメリット＝クラスとの関連付けが明確。
デメリット＝クラスの定義内に書かないといけないのでヘッダに余計な依存が発生する＆宣言と定義が分離される。
無名namespaceにすることのメリット、デメリット＝上の逆。

404 ：デフォルトの名無しさん：03/11/15 19:55

そのまんまじゃん。何を悩む必要があるのか

405 ：デフォルトの名無しさん：03/11/15 20:22

>どうせgetter/setter経由でしかアクセスしないから

あまいんだよ

406 ：デフォルトの名無しさん：03/11/15 20:24

>>398
vectorのiteratorみたいに、ほとんどの実装でポインタだけど、
規格上はポインタとは限らない、って場合はどうするんですか？

407 ：デフォルトの名無しさん：03/11/15 23:42

signal と throw について悩んでおります。

現在、ソケット通信の受信クラスを作成していまして、タイムアウト処理を実装しようとしています。
とりあえず、alarm で時間分経過したら signal で関数を呼び出し、その中で処理をしようとしています。
自分としては、その後に色々と例外処理をしようとしたので throw を使おうとしているのですが、
なぜか throw した時点でアボートしてしまいます。
幾つか試作の関数も作成して見ましたが、どれもうまくいかないようです。
signal で呼び出した関数内では、throw は使えないのでしょうか？

408 ：デフォルトの名無しさん：03/11/15 23:54

特殊な理由でもない限り、
そのクラスが持ってるものは
そのクラス内で定義した方がいいよ。
無名 namespace にしたら、
インライン関数からアクセスしたいときに
アクセスできなくなっちゃうよ。

409 ：デフォルトの名無しさん：03/11/16 00:14

>>407
そのsignalで呼び出された関数は、別スレッドだったりしますか？

410 ：デフォルトの名無しさん：03/11/16 01:10

vector< int >v;
for(int i=0 ; i<100 ; i++)v.push_back(i*i);
vector< int >::iterator it;
for(it=v.begin() ; it!=v.end() ; ++it ) // or it++
{
printf( "test:%d\n" , *it );
}
-------------------
とりあえず、for loopのイレテータを ++it にしても it++ にしても
全く同じバイナリが出た。

411 ：↑ちなみに：03/11/16 01:18

環境は、cygwin(NT^5.1 1.3.17) でgcc　3.2.20020927
おそらくgcc環境なら、全く同じコード吐き出すんでないかなー？
多分、vc++もこの程度なら、最適化を期待して構わないんでは？
手元にvc++がないので確かめられないですがー

412 ：デフォルトの名無しさん：03/11/16 01:25

>>411
その環境だと vector<T>::iterator は T* だから，差がないんじゃないの？
list や deque で追試よろしく．

413 ：デフォルトの名無しさん：03/11/16 01:42

>>412
差が出ても出なくっても、++itのほうが有利なのは確実なので、
それ以上調べても意味無いと思う。

414 ：list版：03/11/16 02:31

679,688c679,687
< 6e6:89 45 d8 mov %eax,0xffffffd8(%ebp)
< 6e9:83 c4 10 add $0x10,%esp
< 6ec:8b 10 mov (%eax),%edx
< 6ee:8b 45 e8 mov 0xffffffe8(%ebp),%eax
< 6f1:89 55 c8 mov %edx,0xffffffc8(%ebp)
< 6f4:89 45 d8 mov %eax,0xffffffd8(%ebp)
< 6f7:39 c2 cmp %eax,%edx
< 6f9:75 d5 jne 6d0 <hoge+0xa0>
< 6fb:eb b3 jmp 6b0 <hoge+0x80>
< 6fd:8d 76 00 lea 0x0(%esi),%esi
---
> 6e6:83 c4 10 add $0x10,%esp
> 6e9:8b 10 mov (%eax),%edx
> 6eb:8b 45 e8 mov 0xffffffe8(%ebp),%eax
> 6ee:89 55 c8 mov %edx,0xffffffc8(%ebp)
> 6f1:89 45 d8 mov %eax,0xffffffd8(%ebp)
> 6f4:39 c2 cmp %eax,%edx
> 6f6:75 d8 jne 6d0 <hoge+0xa0>
> 6f8:eb b6 jmp 6b0 <hoge+0x80>
> 6fa:8d b6 00 00 00 00 lea 0x0(%esi),%esi

上が it++ 下が it--

415 ：デフォルトの名無しさん：03/11/16 02:36

413 が言うように for 内のインクリなら ++it が確実なんだけど
for外で it のインクリをすることもある。

foo = *it++;
foo = *++it;

の両方のケースに遭遇する可能性があるのだけど、
この場合、どちらもコードの質に変化がないということは
何かの役に立つと思う。

少なくとも EffecitiveSTL に書かれてるような危惧は見当たらない。
つまり、実体が作成されてからコピーされるから性能に変化がある
うんぬんは、実際にダンプしてみると心配に値するtipsでもないということ。

416 ：あ、：03/11/16 02:38

×上が it++ 下が it--
○上が it++ 下が ++it

417 ：デフォルトの名無しさん：03/11/16 02:42

VC7.1 /Ox

for(it=v.begin() ; it!=v.end() ; ++it ) // or it++
00415026 mov eax,dword ptr [ebp-1Ch]
00415029 mov dword ptr [ebp-64h],eax
0041502C mov ecx,dword ptr [ebp-64h]
0041502F mov dword ptr [ebp-3Ch],ecx
00415032 mov edx,dword ptr [ebp-3Ch]
00415035 mov dword ptr [it],edx
00415038 jmp main+93h (415043h)
0041503A mov eax,dword ptr [it]
0041503D add eax,4
00415040 mov dword ptr [it],eax
00415043 mov ecx,dword ptr [ebp-18h]
00415046 mov dword ptr [ebp-68h],ecx
00415049 mov edx,dword ptr [ebp-68h]
0041504C mov dword ptr [ebp-40h],edx
0041504F mov eax,dword ptr [it]
00415052 sub eax,dword ptr [ebp-40h]
00415055 neg eax
00415057 sbb eax,eax
00415059 inc eax
0041505A movzx ecx,al
0041505D neg ecx
0041505F sbb ecx,ecx
00415061 inc ecx
00415062 movzx edx,cl
00415065 test edx,edx
00415067 je main+0CEh (41507Eh)

418 ：デフォルトの名無しさん：03/11/16 02:43

for(it=v.begin() ; it!=v.end() ; it++ ) // or it++
0041507E mov edx,dword ptr [ebp-1Ch]
00415081 mov dword ptr [ebp-6Ch],edx
00415084 mov eax,dword ptr [ebp-6Ch]
00415087 mov dword ptr [ebp-44h],eax
0041508A mov ecx,dword ptr [ebp-44h]
0041508D mov dword ptr [it],ecx
00415090 jmp main+0F7h (4150A7h)
00415092 mov edx,dword ptr [it]
00415095 mov dword ptr [ebp-74h],edx
00415098 mov eax,dword ptr [it]
0041509B add eax,4
0041509E mov dword ptr [it],eax
004150A1 mov ecx,dword ptr [ebp-74h]
004150A4 mov dword ptr [ebp-48h],ecx
004150A7 mov edx,dword ptr [ebp-18h]
004150AA mov dword ptr [ebp-7Ch],edx
004150AD mov eax,dword ptr [ebp-7Ch]
004150B0 mov dword ptr [ebp-4Ch],eax
004150B3 mov ecx,dword ptr [it]
004150B6 sub ecx,dword ptr [ebp-4Ch]
004150B9 neg ecx
004150BB sbb ecx,ecx
004150BD inc ecx
004150BE movzx edx,cl
004150C1 neg edx
004150C3 sbb edx,edx
004150C5 inc edx
004150C6 movzx eax,dl
004150C9 test eax,eax
004150CB je main+132h (4150E2h)

419 ：デフォルトの名無しさん：03/11/16 02:45

STLのスレってどこですか？

420 ：デフォルトの名無しさん：03/11/16 02:45

VC7.1 list /Ox

for(it=v.begin() ; it!=v.end() ; ++it ) // or it++
004142D7 mov eax,dword ptr [ebp-18h]
004142DA mov dword ptr [ebp-5Ch],eax
004142DD mov ecx,dword ptr [ebp-5Ch]
004142E0 mov edx,dword ptr [ecx]
004142E2 mov dword ptr [ebp-60h],edx
004142E5 mov eax,dword ptr [ebp-60h]
004142E8 mov dword ptr [ebp-38h],eax
004142EB mov ecx,dword ptr [ebp-38h]
004142EE mov dword ptr [it],ecx
004142F1 jmp main+0ABh (4142FBh)
004142F3 mov edx,dword ptr [it]
004142F6 mov eax,dword ptr [edx]
004142F8 mov dword ptr [it],eax
004142FB mov ecx,dword ptr [ebp-18h]
004142FE mov dword ptr [ebp-64h],ecx
00414301 mov edx,dword ptr [ebp-64h]
00414304 mov dword ptr [ebp-3Ch],edx
00414307 mov eax,dword ptr [it]
0041430A sub eax,dword ptr [ebp-3Ch]
0041430D neg eax
0041430F sbb eax,eax
00414311 inc eax
00414312 movzx ecx,al
00414315 neg ecx
00414317 sbb ecx,ecx
00414319 inc ecx
0041431A movzx edx,cl
0041431D test edx,edx
0041431F je main+0E7h (414337h)

421 ：デフォルトの名無しさん：03/11/16 02:47

for(it=v.begin() ; it!=v.end() ; it++ ) // or it++
00414337 mov edx,dword ptr [ebp-18h]
0041433A mov dword ptr [ebp-68h],edx
0041433D mov eax,dword ptr [ebp-68h]
00414340 mov ecx,dword ptr [eax]
00414342 mov dword ptr [ebp-6Ch],ecx
00414345 mov edx,dword ptr [ebp-6Ch]
00414348 mov dword ptr [ebp-40h],edx
0041434B mov eax,dword ptr [ebp-40h]
0041434E mov dword ptr [it],eax
00414351 jmp main+117h (414367h)
00414353 mov ecx,dword ptr [it]
00414356 mov dword ptr [ebp-74h],ecx
00414359 mov edx,dword ptr [it]
0041435C mov eax,dword ptr [edx]
0041435E mov dword ptr [it],eax
00414361 mov ecx,dword ptr [ebp-74h]
00414364 mov dword ptr [ebp-44h],ecx
00414367 mov edx,dword ptr [ebp-18h]
0041436A mov dword ptr [ebp-7Ch],edx
0041436D mov eax,dword ptr [ebp-7Ch]
00414370 mov dword ptr [ebp-48h],eax
00414373 mov ecx,dword ptr [it]
00414376 sub ecx,dword ptr [ebp-48h]
00414379 neg ecx

422 ：デフォルトの名無しさん：03/11/16 02:47

0041437B sbb ecx,ecx
0041437D inc ecx
0041437E movzx edx,cl
00414381 neg edx
00414383 sbb edx,edx
00414385 inc edx
00414386 movzx eax,dl
00414389 test eax,eax
0041438B je main+153h (4143A3h)

423 ：デフォルトの名無しさん：03/11/16 02:49

>>419
【C++】template 統合スレ -- Part3
http://pc2.2ch.net/test/read.cgi/tech/1066493064/

統合しすぎてもはやSTLの話題はほとんどないが。この際分離したら。

424 ：デフォルトの名無しさん：03/11/16 02:49

リスティングうざい。
時間測れ。それが一番だ。

425 ：デフォルトの名無しさん：03/11/16 02:59

どっちにしても言語スレでやることじゃねぇ

426 ：デフォルトの名無しさん：03/11/16 03:05

++it と it++ とでカウンターに使ってるレジスタが変化しているものの、
大差ないですね・・・ >>vc7.1

結論は、後置・前置、大差なし。
for()の中であれば、確実な前置を使うべきだが、
その他の場合は、その状況に有利な選択をしても構わないかと。

427 ：デフォルトの名無しさん：03/11/16 03:08

>>どっちにしても言語スレでやることじゃねぇ
そうムキに分類しなくても良いではないですか？
STLはC++の公式かつ標準ライブラリである以上、言語スレでもOKかと。

428 ：デフォルトの名無しさん：03/11/16 03:08

>>424 >>425
正直、すまんかった。
>>426
最適化するとVC7.1はいろいろやってくれるようだ。ループのアンロール
もしてくれる事がある。その時はBCCと4倍ほどの時間の差が出た。
BCCを手動でアンロールしたらほとんど差がなくなった。

429 ：デフォルトの名無しさん：03/11/16 03:25

> for()の中であれば、確実な前置を使うべきだが、
> その他の場合は、その状況に有利な選択をしても構わないかと。
どんな場合でも「その状況に有利な選択」をするもんだ。

430 ：デフォルトの名無しさん：03/11/16 03:59

前置と後置で意味の変わる文は
慣れてる人は別に気にならんけど、
分からん人はパッと見で理解できんので、
そういう文は俺は書かんな。
そういうわけで常に単独で書くから
前置と後置を使い分ける必要がなく、
いつも前置で統一している。

431 ：デフォルトの名無しさん：03/11/16 04:30

>>413

確実という根拠を得るには調べることが必要と違うのか？
現に412の調査では++itがit++よりも有利ではないという結果を得ている。
つまり412はキミの言う説にあてはまらない環境を現認しているわけだが
そのうえでのキミの発言は非科学的と言わざるを得まい。

432 ：413：03/11/16 04:42

>>431
後置インクリメントは本質的にコピーが必要なのだから、
効率的な利点を見れば常に前置>=後置になる。
「++itのほうが有利」ってのは、特定の環境に依らずに
こういうことが言えるって事。

前置<後置になるようなケースを示してくれるってんなら、それは興味深い。

433 ：デフォルトの名無しさん：03/11/16 04:44

>>431
「有利ではない」≠「不利である」
「有利ではない」は「等価」を含むのだよ。

前置 ++ のオーバーロードで意図的に無茶苦茶重い処理を入れない限り、
原理的に考えて有利性は ++it ≧ it++ だろ。
いくら最適化が効いてもせいぜいイコールだ（それが >>412 の例だ）。
そして、その最適化はコンパイラによってまちまち。
なら ++it の方が有利と結論付けるのは当たり前だろ。

434 ：デフォルトの名無しさん：03/11/16 05:32

前置と後置のどちらが有利かなんて
コンパイラによる。
議論するだけ無駄。

435 ：デフォルトの名無しさん：03/11/16 05:35

>>434
頭悪い人がわざわざ締めに来なくていいですｗ

436 ：デフォルトの名無しさん：03/11/16 05:48

>>433
先に言ってりゃまだよかったんだよ

437 ：デフォルトの名無しさん：03/11/16 06:01

>>436
はあ？

438 ：デフォルトの名無しさん：03/11/16 06:10

朝っぱらから煽りあいとはおめでてーな

439 ：デフォルトの名無しさん：03/11/16 06:16

>>436
日本語が不自由な方のようですね。
どうぞ無理せず母国の掲示板で議論を続けてください。

440 ：デフォルトの名無しさん：03/11/16 07:06

>>434
前置>=後置

441 ：デフォルトの名無しさん：03/11/16 07:20

まぁ、C ならよほどヘボいコンパイラ使わない限り等価だろうけどね。
いかんせんここは C++ スレだから演算子のオーバーロードが...。

442 ：デフォルトの名無しさん：03/11/16 07:56

そもそも、「++it;ｏｒit++;」だけの場合
インラインなのだから前置も後置も変わらないだろう。

443 ：デフォルトの名無しさん：03/11/16 08:40

前置>=後置　

という簡素な結論が出てなおグタグタ逝ってるヤシは
頭がピンボケてる。
そういう人はちょっとだけ、冷静天秤を買うのだ。

444 ：デフォルトの名無しさん：03/11/16 09:51

おまえモナ♥

445 ：デフォルトの名無しさん：03/11/16 11:23

ここは純粋なC++について語るスレなので、
イテレータのインクリメント等機種依存・実装依存・環境依存の話がしたければこちらでどうぞ。

【初心者歓迎】C/C++室 Ver.2【環境依存OK】
http://pc2.2ch.net/test/read.cgi/tech/1067189450/

446 ：デフォルトの名無しさん：03/11/16 11:58

インクリメントは機種依存なのか。
仕様上は後置インクリメントではコピーが生成されるので
特に理由の無い限りは前置が望ましいと言う結論を出すのも、依存の話題なのか？

447 ：デフォルトの名無しさん：03/11/16 12:05

>>446
どういう風にコンパイルされるかは環境依存。
前置≧後置になることが、規格で決まっているわけじゃない。

448 ：デフォルトの名無しさん：03/11/16 12:15

>>447
後置はコピーが生成される分要求が多いので
論理的に前置≧後置だとしか思えないが・・

要求が多くてもそれにマッチした機能を持つハードウェアだと速くなるとかあるから
速度についてはもちろん実装依存だが。

449 ：デフォルトの名無しさん：03/11/16 12:25

>>448
コピーが生成される方が遅い　←これが環境依存なんでしょ

450 ：デフォルトの名無しさん：03/11/16 12:25

ごめん、あとの2行読んでなかった。。。

451 ：デフォルトの名無しさん：03/11/16 12:26

文脈的にコピーを生成する必要がないと判断すれば生成しないのが普通だが、
かといってそれを期待しすぎるのもどうよ、ぐらいだと思うが。

452 ：デフォルトの名無しさん：03/11/16 12:41

はっきりしているのは、++i が i++ より優速なのはたしかだけど、
プログラム中での時間の差は、掲示板に投稿するのにかかる時間や、
他の連中を説伏するのにかかる時間よりずーっと短いので、
結局どーでもいい、ってことさ。

453 ：デフォルトの名無しさん：03/11/16 12:46

フレームバッファを弄繰り回すループでも
その速度差は重要ではないのか。
結局はケースバイケースだろ
どーでもいいなんて切り捨てられる問題でもない

454 ：デフォルトの名無しさん：03/11/16 12:47

>>447
コンパイル結果は確かに環境依存で否定の仕様も無いが
結局はすべてのプログラムがいずれかの環境に依存するんだから
それもある程度考慮した上で望ましいスタイルを模索するのは
本ヌレの範疇じゃないのか？

455 ：デフォルトの名無しさん：03/11/16 12:47

80-20の法則を忘れてはいかんな。
++iとi++の違いが重要になるようなフレームバッファの弄くり方って何だよ？

456 ：デフォルトの名無しさん：03/11/16 13:00

>>452
どーでも良くないアプリ書いたことないって正直に言いな

457 ：デフォルトの名無しさん：03/11/16 13:00

トリプルバッファ
1280(W)*960(H)*85(R)*3(B)=313344000/s
これくらいの頻度のインクリメントなら差も出ると思うが。

458 ：デフォルトの名無しさん：03/11/16 13:06

planはそれ自体が正しくてもdoとseeが続かなければ机上の空論。
実装依存をネガティブなキーワードに使っている風潮が見られるが
そういうあんたらは、どこの実装で良い結果が得たいんだ？
無目的な者ほど不毛な抽象論しかすることがないわけだが。

459 ：デフォルトの名無しさん：03/11/16 13:08

メモリが律速するって。それともなにか、最近のメモリは
1280(w)*960(h)*85(r)*4(c)*3(tri)=1.2GB/sくらい楽々ですか。

460 ：デフォルトの名無しさん：03/11/16 13:09

461 ：デフォルトの名無しさん：03/11/16 13:10

来年の今ごろはその1.5倍くらいじゃないか？

462 ：デフォルトの名無しさん：03/11/16 13:18

あと、457の回数は、４で割るべきだと思う。

463 ：デフォルトの名無しさん：03/11/16 13:20

464 ：デフォルトの名無しさん：03/11/16 14:20

>>458
新生のヴァカ ?

> 実装依存をネガティブなキーワードに使っている風潮が見られるが

どこにそんな風潮が見られるんだ ? お得意のデムパか ?

実行速度の話は、実装依存。
ここは、実装依存の話をするスレじゃない。

ただそれだけ。

465 ：デフォルトの名無しさん：03/11/16 14:30

お得意の、ほとぼりが冷めてから突然ぶり返し煽りｷﾀー

466 ：デフォルトの名無しさん：03/11/16 14:34

前置/後置なんてのはC言語スレにまかせよう:-)

467 ：デフォルトの名無しさん：03/11/16 14:34

>>432
> 前置<後置になるようなケースを示してくれるってんなら、それは興味深い。
まあｘ，

x = i, ++i;
x = i++;

どっちが書きやすいか，という程度の話だと思うよ．

468 ：デフォルトの名無しさん：03/11/16 14:36

>>466
演算子を再定義できない言語だと，それこそ「環境依存」で終わりなんだが．

469 ：デフォルトの名無しさん：03/11/16 14:42

470 ：デフォルトの名無しさん：03/11/16 16:27

>>469
お前いい加減ウザイ

471 ：デフォルトの名無しさん：03/11/16 17:49

>>464

>実行速度の話は、実装依存。
まあそうだが

だからといって
>ここは、実装依存の話をするスレじゃない。

これは変だろう

C++を選択する理由の中に
速度やらワーキングセットやらは
成果物の性能を実測する前に出てくる

間違いなくC++は性能を意識して使うものだ

割と色々な環境で同じ実験ができる題材について
実測結果や考察を発表しあうことまで
スレ違いと言って排除するのには反対だ

VCしか使っとらん者がgccでの測定値に難癖つけるような
ヘボい考察さえ締め出せれば十分だと思う

472 ：デフォルトの名無しさん：03/11/16 19:55

分割コンパイルについての質問です。
Cpad for Borland C++Compiler を使っています。

例えば

#include <iostream.h>

int func(int x);

void main(void)
{
int x;
cin>>x;

int y=func(x);
cout<<y;
}

int func (int x)
{
return x*x;
}

これを分割コンパイルするには

473 ：デフォルトの名無しさん：03/11/16 19:55

(1) func.h ファイル
int func(int x);

(2) func.cpp ファイル
#include <iostream.h>
#include "func.h"
int func(int x)
{
return x*x;
}

(3) main.cpp ファイル
#include "func.h"
void main(void)
{
int x;
cin>>x;

int y=func(x);
cout<<y;
}

をそれぞれ作成して、(3)をコンパイルする、のではダメなようなのですが
どのようにすれば正常に分割コンパイル出来るのかよくわかりません。
他にどういう作業を行えばよいのでしょうか。

474 ：デフォルトの名無しさん：03/11/16 19:59

bcc32 main.cpp func.cpp
↑
しかし、これでは面倒見がよすぎて
リンク絡みでエラーこいたときの
対応力がつかない

475 ：413：03/11/16 20:31

>>467
あー。
書き込んだ後にそう読み違える人がいるかと思ったけど、
まぁいいか、と思って放っておいた。ごめん。

> 前置<後置になるようなケースを示してくれるってんなら、それは興味深い。
↑ここにも「効率的な利点を見れば」がかかってる。

476 ：413：03/11/16 20:46

> 割と色々な環境で同じ実験ができる題材について
> 実測結果や考察を発表しあうことまで

「コピーする必要がある」ものと、
「コピーする必要が無い」ものを比べるのに、
実測結果など不要だと思う。
不要な実測結果を以って本質を霞ませるのも歓迎できない。

静的確保で済むところを動的確保で置き換えることは大抵の場合可能だが、
ベンチマークを取った結果、
「なんと、ほぼ等速だ。最近のヒープ管理は賢いねぇ。」
だったとしても、無駄な動的確保を容認する根拠にはならない。

477 ：デフォルトの名無しさん：03/11/16 21:14

>>476
> 無駄な動的確保を容認する根拠にはならない。
それは極論だろう．ホントに等速で，断片化などの問題も完全に回避できるなら
許容するって．

478 ：デフォルトの名無しさん：03/11/16 21:25

問題は多くの環境で、どうなるかだ

479 ：413：03/11/16 21:26

>>477
だからどうした？例え話にだけ突っ込むなよ。

本質を見て判断すれば問題ないのに、
見極めが面倒で局所的な条件をつけて「容認できる」と主張することに
何の価値があるというのか。

480 ：デフォルトの名無しさん：03/11/16 21:58

ここのところ、毎週日曜に必ず論争が起きるな
同じ人達なんだろうか

481 ：デフォルトの名無しさん：03/11/16 22:46

>不要な実測結果
^^^^^^
ｲﾀﾀﾀ

482 ：デフォルトの名無しさん：03/11/17 00:14

>>464
> ここは、実装依存の話をするスレじゃない。

嘘つくなよ。Cスレじゃあるまいし。

483 ：デフォルトの名無しさん：03/11/17 00:20

484 ：デフォルトの名無しさん：03/11/17 00:44

純粋なC++についてのみ語るとしたら
後置はコピーが作成されることになっているので遅い。

485 ：デフォルトの名無しさん：03/11/17 01:12

>>483
しつこいうるせーだまれ

486 ：デフォルトの名無しさん：03/11/17 02:28

まだやってんの？

487 ：デフォルトの名無しさん：03/11/17 02:33

>>486
そのようです。
C++厨の頭の悪さがこれでもかというほど出ていて、正直まいりますよねｗ

488 ：デフォルトの名無しさん：03/11/17 08:08

↑ﾅﾆｺｲﾂ？本物の池沼だな

489 ：デフォルトの名無しさん：03/11/17 09:53

>>488
よくそんなストレートに悔しがれますね。
つくづく頭が悪いなぁｗ

490 ：デフォルトの名無しさん：03/11/17 18:57

typedef int HOGE;

try {
　throw static_cast<HOGE>(10);
}
catch(int)
{
　 cout << "exception" << endl;
}

これで例外をキャッチしてしまうのはC++の仕様でしょうか?
それともVC++6.0だけでしょうか?

491 ：デフォルトの名無しさん：03/11/17 19:03

C++の仕様。

C++ の typedef は「弱いtypedef」だから、
throw static_cast<HOGE>(10); と throw static_cast<int>(10); とか、
catch(int) と catch(HOGE) とかは寸分違わず全く同じ意味だ。

492 ：デフォルトの名無しさん：03/11/17 19:07

強いtypedefってものがあるなら、
それはまったく別の型とみなされるんですか？

493 ：デフォルトの名無しさん：03/11/17 19:12

>>492
んです。
Dがそう。

494 ：デフォルトの名無しさん：03/11/17 19:42

struct HOGE { int value;}

495 ：デフォルトの名無しさん：03/11/17 20:33

template <typename Src> class Strong_typedef;

496 ：デフォルトの名無しさん：03/11/17 21:26

>>493
Dってなに？

497 ：デフォルトの名無しさん：03/11/17 21:27

>>496
http://www.digitalmars.com/d/

498 ：デフォルトの名無しさん：03/11/17 21:29

み、みんな、わりーな。おいらが、最初に前置・後置の疑問を
提示してしまったばかりに、スレが荒れてしまって。

というか、まさか、こんな些細な疑問が、こんなに荒れると
思わんかったよ

499 ：デフォルトの名無しさん：03/11/17 21:56

謝って済めばFOX ★はいらねぇ

500 ：デフォルトの名無しさん：03/11/17 22:34

>>498
蒸し返すな。どうせ荒れが収まってつまらなくなったんだろ。

501 ：釣り氏：03/11/17 23:59

前置・後置で水掛け論が白熱するあたり、
いかに2chのC++ユーザーが水面下レブェルで
あることが明らかになってしまったわけだが。

502 ：デフォルトの名無しさん：03/11/18 00:04

↑国語の成績5段階で1

503 ：デフォルトの名無しさん：03/11/18 00:09

>>495
これはどう使うのですか?

504 ：デフォルトの名無しさん：03/11/18 00:32

template <typename Src> class Strong_typedef{
Src src_;
public:
Strong_typedef(const Src &src):src_(src){}
operator Src&(){ return *this; }
operator const Src&()const{ return *this; }
};

typedef Strong_typedef<int> new_int_type;

505 ：デフォルトの名無しさん：03/11/18 00:49

typedef Strong_typedef<int> new_int_type;
typedef String_typedef<int> other_int_type;

この二つがいっしょになる時点でダメポ

506 ：デフォルトの名無しさん：03/11/18 05:44

C++相談室か･･･、C++に移行してからはや10年経過したけど、
C時代から生産性がまるであがってない気がするって相談はだめ？

アセンブラからCへ移行した時は、明らかな生産性向上が見受けられた
のだが

507 ：デフォルトの名無しさん：03/11/18 06:53

>>506
アセンブラ、Cは使いこなせたが、
C++は使えこなせてないってことではないですか？

508 ：デフォルトの名無しさん：03/11/18 08:05

>>505
template <typename Src,int> class Strong_typedef

typedef Strong_typedef<int,__LINE__> new_int_type;
typedef String_typedef<int,__LINE__> other_int_type;

509 ：デフォルトの名無しさん：03/11/18 08:06

>>508
そんなのつかいたくない

510 ：デフォルトの名無しさん：03/11/18 19:53

偶然同じ名前・型の関数を持つインターフェースクラスがあるとします。

struct IA
{
　virtual void func() = 0; // これと
　virtual void hoge() = 0;
};

struct IB
{
　virtual void func() = 0; // これが同じ
　virtual void foo() = 0;
};

この2つのインターフェースを継承する実装クラスがあります。
IA::funcとIB::funcで別の実装を行いたいのですが
どう書いたらいいのでしょうか?

class C : public IA, public IB
{
　void func() { /* 何かの処理 */ }
};

こう書くと同じ実装になってしまいます。
別々のクラスで実装するしかないのでしょうか?

511 ：デフォルトの名無しさん：03/11/18 20:09

struct A : public IA
{
　virtual void func(){}
};

struct B : public IB
{
　virtual void func(){}
};

struct C : public A, public B{};

512 ：わむて ◆wamuteW7DE ：03/11/18 20:15

①　　＿＿　　みるまらーー！　　　　　　　　　　　.／￣￣￣￣￣￣￣＼
　　＜_葱看〉，　　　　　　　　　　　　　　　　　　　　　|　　　　#7Hjj9qn$　　　｜
／　i　lﾚノ）))ヽ.__∧　　　　　　　　　　　② 　＿＿_　＼　　　＿＿＿＿＿／
　/人 il.ﾟヮﾉヽД｀；)　　ｳｯ　　　　　　　　＜_葱看＞　|／
　　　 ui Y つ,.:'　と)　　　　　　　　　　　／　i　lﾚノ）))ヽ___∧
　　　〈|: _ﾌつ (　　(　　ドスッ　　　　　　　/人 il.ﾟヮﾉヽД .ﾟ；)　ｱ･･ｱｳｱｳｱｱ･･
　　（/　　(____(_____)　　　　　　　　　　　　　　 u~~ iつ葱看葱看
　　　　　　　　　　　　　　　　　　　　　　　　　　く_　:|〉葱看葱看葱看
③　　　　　　　　　　　　　　　　　　　　　　　　　し'Ｊ葱看葱看葱看
　　　＿＿_
　　＜_葱看＞　　みるまらーーーっ　　　　　　④
／ i　ﾚノﾉ）)）＼　　葱看葱看葱看　　　　　　＿＿_　　　　　　＿＿
　(人il.ﾟヮﾟﾉ人　葱看葱看葱看葱看　　　　＜_葱看＞　　　＜_葱看＞、
　　ヽ Yi/　　　葱看葱看葱看葱看　　　／ i　ﾚノﾉ）)）＼／.(ﾊ(（iヽl,　i　＼
　　　く_ :|〉　　葱看葱看葱看葱看　　　　　(人il.ﾟヮﾟﾉ人　　　人ﾟヮﾟ∠ｲ)
　　　し'ﾉ　　　葱看葱看葱看　　　　　　　　　ヽ Yi/　　　　　　ヽiY　/
　　　　　　　　　　　　　　　　　　　　　　　　　　　　く_ :|〉　　　　　　〈|: _>
　　　　　　　　　　　　　　　　　　　　　　　　　　　　し'ﾉ　　　　　　　.ヽ∪

513 ：デフォルトの名無しさん：03/11/18 20:27

多態が参照で受けたときだけになるけど。

class C: public IA {
public:
　class C_B: public IB {
　　C * parent_;
　　public:
　　C_B(C * parent):parent_(parent) {}
　　virtual void func() { std::cout << "IB::func" << endl; }
　　operator C&() { return *parent_; }
　};
private:
　C_B b_;
public:
　C():b_(this) {}
　virtual void func() { std::cout << "IC::func" << endl; }
　operator C_B&() { return b_; }
};

514 ：デフォルトの名無しさん：03/11/18 21:01

>偶然同じ名前・型の関数を持つインターフェースクラスがあるとします。

意図的ではなく「偶然」って時点で事故だな（合掌

515 ：わむて ◆wamuteW7DE ：03/11/18 21:31

　＜_葱看＞、
／.(ﾊ(（iヽl,　i　＼みるまらーーーっ
　人ﾟヮﾟ∠ｲ)
　　ヽiY　/
　　〈|: _>
　　　.ヽ∪

516 ：510：03/11/18 21:57

>>511
その方法、実は既に思い付いていました。

class C : IA, IB
{
　void IA::func() {}
　void IB::func() {}
};

さっきこんな方法を思いついたのですが構文エラーでした。
どうやらひとつのクラスで解決する方法はないようですね。
>>511の方法でやることにしました。
皆さんどうもでした。

517 ：デフォルトの名無しさん：03/11/18 22:23

人をむかつかせるのも一つの才能だな。

518 ：デフォルトの名無しさん：03/11/18 22:44

質問です。
Ｃは始めたばかりなので馬鹿みたいな質問かもしれませんが・・・。

１つのプロジェクト内で全ての「○○.cpp」間で共通する変数を使いたいのですが、どうすればよいのでしょう？
ご指導お願いします。

519 ：デフォルトの名無しさん：03/11/18 22:51

>510
Effective C++ 43項

>518
>Ｃは始めたばかり
C言語なら俺に聞け! Part 67
http://pc2.2ch.net/test/read.cgi/tech/1068464309/

520 ：デフォルトの名無しさん：03/11/18 22:56

>>518
＞１つのプロジェクト内で

【初心者歓迎】C/C++室 Ver.2【環境依存OK】
http://pc2.2ch.net/test/read.cgi/tech/1067189450/

521 ：デフォルトの名無しさん：03/11/19 00:59

C++相談。

よく巷の書で「多重継承は控えろ」とあります。
が、なぜに言語使用として実装されてるこの機能を
控えるべきなのか、いまだ分からない。

522 ：デフォルトの名無しさん：03/11/19 01:04

・おばかさんが糞コードを書くから
・おばかさんがコードを読めなくなるから
・メソッドのリネームが無いから

523 ：デフォルトの名無しさん：03/11/19 01:46

なぁ、最近気が付いたんだけどさ、オブジェクト指向の概念を
理解するのは簡単でも、それを実践するのって、難しくないか？

丁寧にコーディング進めていっても、途中で収支がつかなくなってしまう。

524 ：デフォルトの名無しさん：03/11/19 01:47

>>521
その昔、多重継承をサポートするかどうか、かなりもめた。
結局、サポートすることに決めたけど 522 見たいな問題があった。
インタフェースのない C++ では体重継承が無かったら無かったで困るんだけど、
Java とか C# みたいにインタフェースのみ多重継承可能にするのがベスト。

525 ：デフォルトの名無しさん：03/11/19 01:53

>>524
スレ違いなのかもしれないけど…
C++でインタフェースの多重継承をすると、（大抵の実装では）vtableエントリが増えることになるよね？
Java/C# のように「多重継承はインタフェースのみ」って制限をつけると、このデメリットは軽減されますか？

526 ：デフォルトの名無しさん：03/11/19 02:42

>>524
ベストっていうより 522 的なことに対する妥協策のような。。。
実装の多重継承もまぁまぁコアなところでは使われてるし。
Symbian OS とか Windows だと ATL / WTL とか。

トイプログラムに毛の生えたような業務SEの設計する
業務APに多重継承使い出したらきっとバグでまくって死むと思うけど。

527 ：デフォルトの名無しさん：03/11/19 02:51

グローバル変数だって言語仕様として実装されてるが、濫用しないのは当然だろうが。

つーか、C++の多重継承って「C++では多重継承できない」っていわれてカチンと来た
禿が意地でつっこんだんじゃなかったか？

528 ：デフォルトの名無しさん：03/11/19 03:08

多重継承を濫用するスタイル(mix-in)ってのもアリだと思うけど。
でもまぁ確かに流行ではないよね。
最近は継承じゃなくて template でクラス合成できるし。

529 ：デフォルトの名無しさん：03/11/19 04:21

>>グローバル変数だって言語仕様として実装されてるが、濫用しないのは当然だろうが。
しかし、例えばそのアプリでの唯一のグローバルクラスがあったとして
そのグローバルクラスにメンバ変数を追記していく手法では、
その本質はグローバル変数の濫用と同一なのではないだろうか？

530 ：デフォルトの名無しさん：03/11/19 04:25

>>529
書き換えできるクラスを限定すればいいんでは？他のクラスからはリードオンリー

531 ：デフォルトの名無しさん：03/11/19 04:53

＞アセンブラ、Cは使いこなせたが、
＞C++は使えこなせてないってことではないですか？
じゃ、例えば、貴方の場合、
自分を振り返ってみて
今のC++時代の自分は、C時代の自分に比べて生産性は何倍ですか？

自分の場合、1.1倍かなー？場合によっては、1.0倍切ってることもある。

532 ：デフォルトの名無しさん：03/11/19 05:09

一太郎はC言語で書かれていたらしいけどさ、
実際、国内の目だったソフトでC++化による
著しいソフトウェアの生産性・質的向上のサンプルってあるのかなー？

533 ：デフォルトの名無しさん：03/11/19 08:36

俺はSTLだけで生産性は大幅にアップしたけど。
Cで同じようなもの作ってもすごい醜悪で使いづらいし。

534 ：デフォルトの名無しさん：03/11/19 11:45

STLつかうと一気に実行ファイルサイズが10倍に?！

535 ：デフォルトの名無しさん：03/11/19 17:44

>>534
>>28

536 ：デフォルトの名無しさん：03/11/19 18:07

>>534
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。

537 ：デフォルトの名無しさん：03/11/19 18:13

>>536
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

538 ：デフォルトの名無しさん：03/11/19 18:14

template
<
　class CreationPolicy = using_new,
　class ThreadingModel = single_threaded
>
class widget : public CreationPolicy, public ThreadingModel
{
　...
　
};

みたいなことがしたいから、多重継承なきゃやだ。

539 ：デフォルトの名無しさん：03/11/19 18:41

>>538
同意だが、これって多重継承というよりはmix-inだよね。
mixinがあれば十分な気はする。

540 ：デフォルトの名無しさん：03/11/19 18:42

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

541 ：デフォルトの名無しさん：03/11/19 18:55

>>540
#include <stdafx.h>

後死ね。

542 ：デフォルトの名無しさん：03/11/19 19:05

>>541
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

543 ：デフォルトの名無しさん：03/11/19 20:52

>>534-542
またデジャヴ？

544 ：デフォルトの名無しさん：03/11/19 23:43

STLつかうと一気に生産性が10倍に?！

545 ：デフォルトの名無しさん：03/11/20 00:13

1.2倍くらいじゃね？

546 ：デフォルトの名無しさん：03/11/20 00:28

Microsoft Visual C++をインストールしたいのですが、
どうすればよいのでしょうか？
馬鹿にも分かるように教えてください。
よろしくお願いします。

547 ：デフォルトの名無しさん：03/11/20 00:29

CDをPCに入れる

はい、次。

548 ：デフォルトの名無しさん：03/11/20 00:31

>>547
そのCDはどこにあるの？

549 ：デフォルトの名無しさん：03/11/20 00:32

1.1倍とか、1.2倍とか、お前らC++の何を使っているんだ、と。

550 ：デフォルトの名無しさん：03/11/20 00:32

ソフトの販売店

551 ：デフォルトの名無しさん：03/11/20 00:33

C--

552 ：デフォルトの名無しさん：03/11/20 00:38

C++でマクロツールを作ろうと思ってるのですが、
参考文献、参考URL等を教えてください。
ロケットマウスやFree Macro!のようなツールを作りたいのですが。
主な使用目的はネットゲームの作業の自動化等です。

553 ：デフォルトの名無しさん：03/11/20 00:38

>>548
nyでおとして、焼いてください。

554 ：nanasi：03/11/20 00:42

質問があります

#include <stdio.h>
int add(int n);
void main(void)
{
int i= 1;
printf("1st time ; i=%d,address=%x\n",i,&i);
i = add(i);
printf("2nd time ; i=%d,address=%x\n",i,&i);
i = add(i);
printf("3rd time ; i=%d,address=%x\n",i,&i);
}
int add(int n)
{
int i=0;
printf("add function; i=%d,address=%x\n",i,&i);
i+=n;←なんでここにnを代入するのかわかりません教えてください・・ほんとに・
ここにnを代入する必要があるのでしょうか？
nを代入する意味が知りたいのです
このプログラムの意味は１つの引数を与えて加算する関数ですちなみに自動変数です
return i;

555 ：デフォルトの名無しさん：03/11/20 00:44

マルチ市ね

556 ：デフォルトの名無しさん：03/11/20 00:49

>>554
さぁなんでだろうね？
ところで、アドレスの出力は正しくは%pだよ

557 ：デフォルトの名無しさん：03/11/20 01:04

多重継承なくせばiostreamがなくなるよな

抽象クラス山盛りにして悦にひたってる自分としては
多重継承は存在していて当然というか
これ無しでコーディングハイにはなれないしモチベーションも出ない

558 ：デフォルトの名無しさん：03/11/20 01:12

仮想継承したクラスから親クラスを見ると何もかもがすべて
間接的にアクセスされていると初めて知った・・・・・

それじゃ速度が遅くなってしまうじゃん！と思わず叫びたくなった。
仮想継承を10段ほど重ねたらどうなってしまうんだろう。

559 ：デフォルトの名無しさん：03/11/20 01:22

とりあえず設計者を殴ったらどうだ？

560 ：デフォルトの名無しさん：03/11/20 01:25

ＶＣ6.0です。
newで作成したchar配列の途中の文字からそれ以降の全ての文字列を破棄しようとしました。
この配列の先頭のポインタはchar*のベクターの中に入れています。（vector<char*>Cvec）

delete &((Cvec[i])[j]);

↑だとなんかダイアログ付きのエラーが出ます（デバッグモード）
どうなってるんでしょか？

561 ：560：03/11/20 01:27

すいません。嘘を書いていました。
↓がエラーの出るコードです。

delete[] &((Cvec[i])[j]);

562 ：デフォルトの名無しさん：03/11/20 01:29

>>561
オモロイ事やってるな

563 ：デフォルトの名無しさん：03/11/20 01:30

え～と、何から何まで間違ってるように思う。
そういう用途なら、vector<char>にしといたほうがいいよ。

564 ：560：03/11/20 01:40

配列の途中から破棄して先頭からそこまでの部分は残す、というのは無理なんでしょうか？

565 ：デフォルトの名無しさん：03/11/20 01:45

>>564
ムリですよ。とりあえず、長さを切り詰めるだけなら
pointer = Cvec[i];
*(pointer + i) = '\0';
しとけば？

破棄するときは delete Cvec[i] したあとで vector からはずす。

566 ：デフォルトの名無しさん：03/11/20 01:46

いちおー効果も
delete [] Cvec[i]

567 ：560：03/11/20 01:50

>>565
>>566
ありがとうございます。
そうしてみます。

568 ：デフォルトの名無しさん：03/11/20 01:52

>>564
vector 使ってるなら resize() で終わりだが．

569 ：デフォルトの名無しさん：03/11/20 01:53

メモリは解放しないけどな．

570 ：デフォルトの名無しさん：03/11/20 01:53

そんなに切りつめたいなら、
Cvec[i] = realloc(Cvec[i], j);
おっとnewは使っちゃだめよん。

571 ：デフォルトの名無しさん：03/11/20 06:25

>>1.1倍とか、1.2倍とか、お前らC++の何を使っているんだ、と。
けど、一般ソフトの規模って、C時代もC++時代も大して変化ないよね？
例えばMIFESだとか、MS-DOS時代からあったけど
機能としては劇的な差というのはない。おそらくC++でリライトしてるにも
かかわらず。

MIFESに限らず、他のソフトもそんな感じ。一太郎forWinだとかも、
DOS時代と大差ないし。

572 ：デフォルトの名無しさん：03/11/20 06:39

このスレ読んで、思った疑問。

C++がもっとも活用された、
もしくはC++でなければ、現実的に完成しなかったであろう
プロダクトってあるのか？

Cであれば、腐るほどあるのだが・・・

573 ：デフォルトの名無しさん：03/11/20 07:12

>>571
> 機能としては劇的な差というのはない。おそらくC++でリライトしてるにも
> かかわらず。

「リライト」で機能が追加されるわけ無いだろ。

574 ：デフォルトの名無しさん：03/11/20 07:23

おそらくC++でコンパイルしただけで、C++の機能を積極的に利用しているわけではないと思う。

575 ：デフォルトの名無しさん：03/11/20 07:26

Cで巨大なプロダクトを成し遂げた人（組織）ほど、
C++の機能には懐疑的になり、"Effective"な利用は遅れるのではないか？

576 ：デフォルトの名無しさん：03/11/20 08:10

新しい道具の使い方を覚えるのが嫌いな人っているからね。
C++は変な言語だし。

うちの会社にもいるけど、Cで十分だと思っているならそれでいいじゃん。
Cに不満がない人間がCを使いこなせてるとは思わないけど。

577 ：デフォルトの名無しさん：03/11/20 08:18

そいつらのせいでC++を何時までたっても使用できないんすけど。
C++は確かに変な言語だけど、Cよりかはいい。

578 ：デフォルトの名無しさん：03/11/20 09:41

>>572
Microsoft Office, Internet Explorer, ...

あれ COM の塊だから，書く気になれば C で書けないこともないが，C++ の方が
圧倒的に楽．

579 ：デフォルトの名無しさん：03/11/20 10:02

そうだな。COMは使用だけでも、
lpObj->lpVtbl->Func(lpObj, Arg1, Arg2);
とかいろいろ面倒だからなぁ。

580 ：デフォルトの名無しさん：03/11/20 10:05

M$はまともなコンパイラ作れと言いたい

581 ：デフォルトの名無しさん：03/11/20 15:00

>>579

タイプライブラリから自動生成されるヘッダファイルがあれば、some->Method(foo, bar) を
C から SomeObject_Method(come, foo, bar) みたいに使えるマクロが定義されるんで、
そこまで使いにくくはならないと思う。

582 ：デフォルトの名無しさん：03/11/20 17:10

並を食べるときは吉野家、大盛りを食べるときは松屋にしています。

583 ：デフォルトの名無しさん：03/11/20 19:04

_UNICODEが定義されているかどうかで
std::stringとstd::wstringを切り替えるようなものは用意されてないんでしょうか?

584 ：デフォルトの名無しさん：03/11/20 20:09

>>580
VC6 の時代はともかく VC7.1 は，かなりまともだと思うぞ．

585 ：デフォルトの名無しさん：03/11/20 20:38

C++の規格を完璧に満たすコンパイラって存在するんですか?

586 ：デフォルトの名無しさん：03/11/20 20:49

>>583
自分で定義しる

587 ：デフォルトの名無しさん：03/11/20 21:03

>>586
typedef std::basic_string<TCHAR> tstring;
とすることにしました。

588 ：デフォルトの名無しさん：03/11/20 21:12

// Aはクラス
A a1;
A a2;
A a3;

と書いた場合、VC++6.0ではこれらが破棄される順番は
構築の逆順(a3→a2→a1)になりました。
このことはC++の規格として保障されているのでしょうか?

589 ：デフォルトの名無しさん：03/11/20 21:35

されてる

590 ：デフォルトの名無しさん：03/11/20 22:00

>>587
coutうまくいってる？

591 ：デフォルトの名無しさん：03/11/20 22:38

>>590
問題ないようです。VC++6.0標準STL、非UNICODEで確認。

592 ：588：03/11/20 22:42

>>589
ありがとう

593 ：デフォルトの名無しさん：03/11/20 23:01

>>588
規格票もってないだろ？
・金がない　・・・そりゃお気の毒
・脳がない　・・・氏ね

594 ：デフォルトの名無しさん：03/11/20 23:43

>>593
規格「票」だとﾌﾟﾌﾟﾌﾟ

595 ：デフォルトの名無しさん：03/11/21 00:09

>>594
JIS 用語だと、それが正解だったりする。

596 ：デフォルトの名無しさん：03/11/21 00:19

>>593
金なんか無くても、これで十分だろ。
http://www.kuzbass.ru/docs/ansi_iso_iec_14882_1998.pdf

597 ：デフォルトの名無しさん：03/11/21 00:24

>>591
そりゃ非 UNICODE なら cout でエラーでないの当たり前じゃ。
tstring が string と同じになるんだから。
UNICODE なら tstring が wstring と同じになるから、
wcout を使わないといけなくなる。
だから、

#ifdef _UNICODE
std::wostream& tcout = wcout;
#else
std::ostream& tcout = cout;
#endif

とか汁。

598 ：デフォルトの名無しさん：03/11/21 00:37

>>597
591じゃないけど、勉強になった。ありがとう。

599 ：デフォルトの名無しさん：03/11/21 02:27

>>596
氏ね...っていいたいところだけど、
最近の値段はいくらなんでも高すぎるので、
ISO、氏ね。

600 ：591：03/11/21 02:30

>>597
coutもUNICODEで変えなきゃならんのか…
まぁ今回はGUIアプリだからいいけど。

601 ：デフォルトの名無しさん：03/11/21 03:21

UNICODE の切り替えが必要になるのは
大抵 GUI というか、Windows プログラミングの時だから、
別に tcout 作る必要性が出てくる状況は殆どないと思うけどね。
マイナーな COM とか使ってると A/W のどちらか片方しか使えないことがあるけど、
そうでもなければ態々こんな切り替えを気にする必要性はない。

602 ：デフォルトの名無しさん：03/11/21 04:01

やっぱさ、C++って大して効率上がってないよ。
Cで書かれたソースをC++で書き直したくなる衝動ってのは
５～１０年前は、みんな躍起になってたけどさ、
書き換えてみて大して変わらなかったもん。

当社比　＋２０％ってとこかな。

オブジェクト指向って、C言語のころから存在してたものだし
プロならそのようなワークをしていた。

どちらかというと、ジェネッリク（STLのようなテンプレートライブラリ）
のほうが、C++を使うありがたみとして大きい。

このスレの住人のみんなって、例えばC++のコードを月間、何行くらい
書いてるの？

603 ：デフォルトの名無しさん：03/11/21 05:27

>>601
ですね。
あえて言うなら ofstream とか ifstream のファイル名のところが UNICODE になる版が欲しいかも。

604 ：デフォルトの名無しさん：03/11/21 11:49

>>602
> 書き換えてみて大して変わらなかったもん。

書き換えただけで何がどう変わることを期待してるの？

605 ：デフォルトの名無しさん：03/11/21 17:41

stringとvectorを使うだけで俺は幸せ。

606 ：デフォルトの名無しさん：03/11/21 18:44

例外も便利だ

607 ：デフォルトの名無しさん：03/11/21 18:51

for_each copy replace accumulate ... ｱﾙｺﾞﾘｽﾞﾑ便利

608 ：デフォルトの名無しさん：03/11/21 19:04

map,set,list便利

609 ：デフォルトの名無しさん：03/11/21 20:04

std::auto_ptr、boost::shared_ptr……スマートポインタ便利便利

610 ：デフォルトの名無しさん：03/11/21 20:10

main()の最後にreturn 0;を自動的に書いてくれる・・・・便利便利

611 ：デフォルトの名無しさん：03/11/21 21:25

void main() も使える・・・・便利便利

612 ：デフォルトの名無しさん：03/11/21 21:42

６０５～６１１

やっぱ、STL頼みのようだな。
で、それら便利ツール使っても、劇的には便利にならなかった。
C++への移行コストは、それほど高くなかったけど
だとしても、それに見合うメリットがユーザーに降り注いでない
気がする。

以上

613 ：デフォルトの名無しさん：03/11/21 21:48

そりゃあんたがC++的なプログラミングをしてないだけじゃないか。

614 ：611：03/11/21 21:49

>>612
ボケにボケ返しされた。
＿|￣|○

615 ：デフォルトの名無しさん：03/11/21 21:51

ポリモーフィズムでプログラムが楽チン

616 ：デフォルトの名無しさん：03/11/21 21:56

>>612が自分のアホさ加減を自慢していますが、どうしましょう。

617 ：デフォルトの名無しさん：03/11/21 22:30

ポリモーフィズム
コンストラクタ、デストラクタ
アクセス制限
参照
整数定数の静的リンケージ化＋配列サイズ指定可
関数の途中や for の ( ) の中などで変数宣言可
インライン関数
テンプレート
STL
例外

618 ：デフォルトの名無しさん：03/11/21 23:17

クラスの設計がうまくいくとちょっとうれしい

619 ：デフォルトの名無しさん：03/11/22 00:42

>>612が自分のアホさ加減を自慢していますが、どうしましょう。
↑荒れるから止めろ、抵学歴厨が。

620 ：デフォルトの名無しさん：03/11/22 00:42

>>618
Bjarneしく同意

クラス化することにより注意点が増えるばかりで逆効果な
ヘボクラスが世の中多すぎるし自分も書いてしまいがち

完璧に隠さなければならないことはいいんだが
逆に隠してはならないことを
もっとうまく分けられる方法がないものかとよく思う

621 ：デフォルトの名無しさん：03/11/22 01:57

>>クラスの設計がうまくいくとちょっとうれしい
はげ藁同。うむうむ分かる！
でも、オナニーに似た感覚でもあるんだよな。出来上がったものの品質には
なんら変化がないことも・・・

622 ：デフォルトの名無しさん：03/11/22 05:05

>>619
学歴コンプレックス丸出しでなに興奮してんの？ｗ

623 ：デフォルトの名無しさん：03/11/22 07:55

>>620
> Bjarneしく同意
わらた

624 ：デフォルトの名無しさん：03/11/22 07:56

cppllの連中、ｷﾓｲ香具師おおすぎ
いつ初心者をぶったたこうか、うずうずしてるやつとかいるし。
脱退しますた。

ﾉｼ

625 ：デフォルトの名無しさん：03/11/22 09:03

>>624
最近なんかあったっけ？

626 ：デフォルトの名無しさん：03/11/22 09:11

ｴﾋﾞｽﾃｰﾒｰとか？

627 ：デフォルトの名無しさん：03/11/22 09:53

うーん…
質問の内容をだす前後で、うざい文章がでる時があるけど
(へりくだり杉)
まぁ礼儀のうちじゃ？

628 ：デフォルトの名無しさん：03/11/22 10:35

確かにcppllはキモイね

629 ：デフォルトの名無しさん：03/11/22 11:15

>>628
肝委。非常に閉鎖的だよな。まあ見てるけど。
ここのスレの方がまだ有意義。にたようなもんだけど。

エピって、初期のころ2ch嫌いって言ってたのに、
一時期2ch語使いまくってたよな。そういえば。

630 ：デフォルトの名無しさん：03/11/22 11:30

>>602

いまさら蒸し返すほどのコトじゃないけど、ひょっとして論理的な思考ってのを誰からも教えてもらってないのかと思うと
ちょっとかわいそうになってきたので、ちょっとフォローを。単なる煽りのつもりで書いたんだったらごめんね。

僕はC++マンセー派だけど、別にC派は否定しないので、あくまでも内容ではなくて、文章力と論理力についてのコメントです。

> やっぱさ、C++って大して効率上がってないよ。

効率ってのは開発効率のことだよね？
開発効率って観点だと、躍起になって書き直すってこと自体あんまりしないと思うんだけど、どう？

> 当社比　＋２０％ってとこかな。

20%も上がっているなら非常に効率がいいと思うんだけど。他のところと論点が違うのかな？

631 ：デフォルトの名無しさん：03/11/22 11:30

>>602

> オブジェクト指向って、C言語のころから存在してたものだし

オブジェクト指向の優位性とC++の優位性は関係ないと思う。
C++をオブジェクト指向開発をしやすくする言語だと思えば少なくともCには劣らないと思うんだけど。

> どちらかというと、ジェネッリク（STLのようなテンプレートライブラリ）

ここも意味がよくわからないんだけど。
・オブジェクト指向開発はもともとしている。
・ジェネリックプログラミングのほうが便利。
・C++はそんなに開発効率が高くない。
ってなにか関係がある？

> このスレの住人のみんなって、例えばC++のコードを月間、何行くらい
> 書いてるの？

開発効率とコーディング量の関係がよくわからないんだけど。
タイピング量って意味なら言語によらず一定だと思うし、開発効率が高い言語ならコード量は少なくなるよね。
でもここで「月に数百行かな？」って書いても、開発効率に関してはなんの参考にもならないと思うんだけど。

632 ：デフォルトの名無しさん：03/11/22 11:47

>>630-631

ｷﾓｲ

633 ：デフォルトの名無しさん：03/11/22 13:35

>>619=>>612 （ｗ

634 ：デフォルトの名無しさん：03/11/22 14:06

>>624,626-629
最近なにかあったの？なかったの？
cppll BBS のほうでも似たような書き込みがあって
具体的にどのことを言ってるのかきかれても答えねぇし、
ただの私怨厨か？

635 ：デフォルトの名無しさん：03/11/22 15:17

わからないって言ってるﾔｼちゃんと読んでるのか？
たしかにｷﾓｲがboost訳などたまーーに訳にたつ両刃のr

636 ：デフォルトの名無しさん：03/11/22 15:37

>>635
誰がわからないなんて言った？
ちゃんと読んでないのはおｍ（ｒｙ

637 ：デフォルトの名無しさん：03/11/22 16:04

>>636
ちゃんと読んで欲しいなら
最後まで書k(ry

638 ：デフォルトの名無しさん：03/11/22 16:08

(ryとかwとかキモすぎ
cppllとスラドは二大キモヲタコミュニティ

639 ：デフォルトの名無しさん：03/11/22 16:28

つーか、cppllに初心者で足を踏み入れる者がいるのがすごいかも。

640 ：デフォルトの名無しさん：03/11/22 16:54

cppll の話ならこっちでしれ。
http://jbbs.shitaraba.com/computer/5651/cppll.html

641 ：デフォルトの名無しさん：03/11/22 16:54

多いときは月5000から一万行ぐらい。
Cだと作業的にオーバーフローするなぁ。
ミドルウェアとか商用のライブラリパッケージ使わんから自作多いよ。

642 ：デフォルトの名無しさん：03/11/22 17:10

一日で1000行くらい書くけどなぁ。
#コメントなどを含む
20日毎日書くわけじゃないけどコーディング中心の月は10kじゃ利かないな。

643 ：デフォルトの名無しさん：03/11/22 17:38

凄く初歩的な質問で申し訳ないのですが
人まとまりの処理を、ヘッダーファイルに関数として書いて
ソースからインクルードして関数を使うのと
クラスに書いて使うのとでは、どのようなメリット・デメリットがあるのでしょうか？
特に処理速度の点から考えると差はあるのでしょうか？

644 ：デフォルトの名無しさん：03/11/22 17:41

>>643
Inside C++ Object Model という書籍を買ってきて読め．

645 ：デフォルトの名無しさん：03/11/22 18:33

>>643
クラスにまとめるメリットは、処理のまとまりを意味付けて伝えることができること。
デメリットは、きっちりクラス分けできてないとロクでもないことになる。
処理速度の点でのデメリットは一般的には無い。

646 ：デフォルトの名無しさん：03/11/22 19:42

>>643
>特に処理速度の点から考えると差はあるのでしょうか？
おすすめbook

C++オブジェクトモデル
内部メカニズムの詳細
S.B.リップマン著
三橋二彩子，佐治信之，原田曄訳
トッパン
ISBN4-8101-8101-4

647 ：デフォルトの名無しさん：03/11/22 20:22

>>20%も上がっているなら非常に効率がいいと思うんだけど。他のところと論点が違うのかな？
その「20%上昇」とやらが良いか悪いかはキミも含めて、
主観では判断できないものでしょ？

648 ：デフォルトの名無しさん：03/11/22 20:25

＞オブジェクト指向の優位性とC++の優位性は関係ないと思う。
＞C++をオブジェクト指向開発をしやすくする言語だと思えば少なくともCには劣らないと思うんだけど。
なんか、良く読むと、
上行と下行とで矛盾してるな。ひょっとして二人がかりのカキコか？

649 ：デフォルトの名無しさん：03/11/22 20:39

cppll でなにかあったのかとの問いには返事がないままだし、
>>638 とか見てるとやっぱりただの私怨厨か。

650 ：デフォルトの名無しさん：03/11/22 21:40

>>648
C でもオブジェクト指向をしようとすればできるが、
継承とかいろいろやろうと思うと C++ に比べてコードが汚くなってしまう。
ということ。

651 ：デフォルトの名無しさん：03/11/22 21:50

コードが汚くなる程度ならいいが、C++ならコンパイラが弾いてくれるような
些細なバグでも自力で検出せざるをえないのが致命的だと思うんだが。

652 ：デフォルトの名無しさん：03/11/22 21:53

>>648
いや、これはパラドックスだろ
見方によっては禿に対する煽り

653 ：635：03/11/22 21:54

漏れがさす「わからない」人っていうのは、
C++のことがわからないってことじゃなくて、
cppllのどこがきもいかわからない人のことね。

つまり６４９おまえさんの事だ。
そんなに人あおってまで、知りたい事なら、
ｃｐｐｌｌ過去ログでもよめばよかろう。

cppllの雰囲気が苦手なら、参加しなきゃよし。
べつにあのメーリングリストにはいってなきゃ、
「もぐり」になるってわけでもないし。

654 ：デフォルトの名無しさん：03/11/22 22:20

>>651
それも含めて「汚い」と言ったんだけどね。
まぁ、俺も端折り過ぎたな。

655 ：デフォルトの名無しさん：03/11/22 22:25

＞６５０
Cで多重継承のやり方をおしえてくらはい。

656 ：デフォルトの名無しさん：03/11/22 22:52

>>655
struct A{};
struct B{};

struct C{/* 継承 */
struct A a;
};

struct D{/* 多重継承 */
struct A a;
struct B b;
};

657 ：デフォルトの名無しさん：03/11/22 23:16

>>653
お前こそよく読め。誰も cppll のきもさがわからないなんて言っとらんぞ。

658 ：デフォルトの名無しさん：03/11/23 00:01

>>655
仮想継承もできるぞ

659 ：デフォルトの名無しさん：03/11/23 00:06

>>656
それはコンポジションでは。(敢えて誰も言わないのだろうが)

660 ：デフォルトの名無しさん：03/11/23 00:08

>>659は勘違いをしてそうだ

661 ：デフォルトの名無しさん：03/11/23 00:12

>>659
先生！激しく>>655嫁！

662 ：デフォルトの名無しさん：03/11/23 00:13

>>659
ちがうよ。

663 ：デフォルトの名無しさん：03/11/23 00:31

>>659の継承はおそらくunionだろう

664 ：生殖活動：03/11/23 00:47

C++なプログラマーさんは頭脳職なのでしょうか？

なぜ、幼いころにセックスをしてはいけいないのか？
http://www.so-net.ne.jp/renaikagaku/news/content/020520.html]

↑長文だけど、読んで味噌。

665 ：デフォルトの名無しさん：03/11/23 01:21

>>660-663
なーんだ、Cかよ。まさかC++のスレにCが書いてあるとは・・・
でもメンバ関数を持ったりしたらさすがに苦しいだろ。書けない
事はないだろうが。仮想関数なんか面倒そう。

666 ：デフォルトの名無しさん：03/11/23 01:24

>>665
>>655 ぐらい嫁よ。

667 ：デフォルトの名無しさん：03/11/23 01:39

>>665は関数ポインタも使えない低脳かｗ
配列･･･いやそれは禁句だろうな

668 ：デフォルトの名無しさん：03/11/23 01:39

>>665
gtk見たこと無いのか？

669 ：デフォルトの名無しさん：03/11/23 01:41

>>665
いつも空気読めなくて友達の中で一人だけ浮いてるだろ。
>>650 → >>655 → >>656

670 ：デフォルトの名無しさん：03/11/23 04:11

>>665
#include <stdio.h>

typedef struct A_ A;
struct A_ {
　int x;
　void (*foo)(const A* v);
};

void A_foo(const A* a) {
　printf("A: %d\n", a->x);
}

void A_constructor(A* a, int x) {
　a->foo = A_foo;
　a->x = x;
}

typedef struct B_ {
A a;
} B;

void B_constructor(B* b, int x) {
A_constructor(&b->a, x);
}

671 ：デフォルトの名無しさん：03/11/23 04:12

typedef struct C_ {
B b;
int y;
} C;

void C_foo(const A* a) {
const C* c = (const C*)a;
printf("C: %d + %d = %d\n", c->b.a.x, c->y, c->b.a.x + c->y);
}

void C_constructor(C* c, int x, int y) {
B_constructor(&c->b, x);
c->b.a.foo = C_foo;
c->y = y;
}

typedef struct D_ D;
struct D_ {
int z;
void (*bar)(const D* v);
};

void D_bar(const D* d) {
printf("D: %d\n", d->z);
}

void D_constructor(D* d, int z) {
d->bar = D_bar;
d->z = z;
}

672 ：デフォルトの名無しさん：03/11/23 04:12

typedef struct E_ {
　C c;
　D d;
} E;

void E_constructor(E* e, int x, int y, int z) {
　C_constructor(&e->c, x, y);
　D_constructor(&e->d, z);
}

void test_foo(const char* s, const A* a) {
　printf("%s::foo: ", s);
　a->foo(a);
}

void test_bar(const char* s, const D* d) {
　printf("%s::bar: ", s);
　d->bar(d);
}

673 ：デフォルトの名無しさん：03/11/23 04:13

int main() {
　A a;
　B b;
　C c;
　D d;
　E e;

　A_constructor(&a, 10);
　B_constructor(&b, 20);
　C_constructor(&c, 30, 40);
　D_constructor(&d, 50);
　E_constructor(&e, 60, 70, 80);

　test_foo("A", &a);
　test_foo("B", &b.a);
　test_foo("C", &c.b.a);
　test_bar("D", &d);
　test_foo("E", &e.c.b.a);
　test_bar("E", &e.d);

　return 0;
}

674 ：デフォルトの名無しさん：03/11/23 04:26

息をするのもメンドクセェ
って感じだな。

675 ：デフォルトの名無しさん：03/11/23 04:29

ゲイラは帰っていいよ

676 ：デフォルトの名無しさん：03/11/23 04:31

構造体をメンバーに含むと継承になるのか。

677 ：デフォルトの名無しさん：03/11/23 04:59

だからこその C++ だな。

678 ：デフォルトの名無しさん：03/11/23 05:23

>>676
「どうやって"模して"いるのか」って話なんだから、
微妙に成立していない点があっても、それは深く突っ込む所じゃ
ないのではないかと。

679 ：デフォルトの名無しさん：03/11/23 05:38

C++ もコンパイルすればアセンブリ言語（マシン語）なわけだから、
極論すればアセンブリ言語（マシン語）でもオブジェクト指向は可能。
要するに言語の違いはどこまでオブジェクト指向のプログラムが組みやすいかの違いに過ぎない。

でも、実用上それはクリティカルに効いてくるんだけどね。

680 ：デフォルトの名無しさん：03/11/23 08:13

>>679
そういったことはできてから言うね
可能、不可能の問題ではないんだよ、ボンクラ君ｗ

681 ：デフォルトの名無しさん：03/11/23 08:32

>>680
>>679の最後の行はまさにそう言ってるんだと思うが。

682 ：デフォルトの名無しさん：03/11/23 09:21

>>679
て言うか、C++ → C のトランスレータがあったんだから、C で C++ の機能が実現できるのは当たり前。
(もちろん、コンパイラって言うのは C++ → アセンブリ言語/マシン語へのトランスレータだから、アセンブリ言語でオブジェクト指向が可能なのも当たり前。)

> 要するに言語の違いはどこまでオブジェクト指向のプログラムが組みやすいかの違いに過ぎない。

FORTRAN で、多重継承を実現してみてください。

683 ：デフォルトの名無しさん：03/11/23 10:07

全ての言語はチューリング等価であるという意味で同等の力を持つ
って誰かが言ってたよ

684 ：デフォルトの名無しさん：03/11/23 10:21

>>682
まず、オブジェクト指向＝多重継承が出来なくてはならないという
勘違いから直してはどうだ？

685 ：デフォルトの名無しさん：03/11/23 10:26

実装はともかくインターフェースの多重継承もできないのはつらいと思うが。

686 ：デフォルトの名無しさん：03/11/23 10:30

>>683
そりゃそうだ。
例えばでかい配列作ってそこで仮想機械動かすと言うアプローチはありうる。

>>684
別にオブジェクト指向 = 多重継承ができることと思ってるわけじゃないよ。
単に、>>655 に倣っただけだよ。

で、あんたは「何ができればオブジェクト指向ができる」と言えると思ってるんだ ?
で、それは FORTRAN で実現できるのか ?

687 ：デフォルトの名無しさん：03/11/23 12:44

>>673
なるほど、thisの代わりに自分のアドレスを持たせればいいのか。

688 ：デフォルトの名無しさん：03/11/23 12:47

>>687
新しい勘違いですか？

689 ：デフォルトの名無しさん：03/11/23 13:26

>>688
だってC++なら不要な&aとか&bという引数がことごとく付いてるじゃん。

690 ：デフォルトの名無しさん：03/11/23 15:04

>>673
それだと既定クラスのインターフェース経由で、派生クラスのメンバを触れなくなる。

struct Base1 { virtual void add() = 0; };
struct Base2 { virtual void dec() = 0; };
struct Deriv : public Base1, public Base2 {
　　int n_;
　　void add() { ++n_; }
　　void dec() { --n_; }
};

void func(Base2* p) { p->dec(); }

Deriv d;
func(&d);

たとえば、こんな状況を考える。func() 関数中では p は Deriv の先頭ではなく、
Deriv 中に含まれる Base2 部分オブジェクトの先頭を指す必要がある。一方、
Deriv::dec() が呼ばれた直後には this ポインタは Deriv 先頭を指してる
必要がある。

その調整も自前でやらないと。

691 ：デフォルトの名無しさん：03/11/23 19:51

>>682
>FORTRAN で、多重継承を実現してみてください。

だから、やればできるよ。

できないのはキミくらいのものだろう。
多重継承とは : と , を使うことという理解では不可能だからだ。

>「何ができればオブジェクト指向ができる」と言えると思ってるんだ ?

データ構造とサブルーチンを、意味づけに基づいてグループ化すること。
継承は付加的な考え方で、オブジェクト指向の本質ではない。

従来製品に上位互換の新製品を作ること、それが継承だ。
複数の従来製品に上位互換の新製品を作ること、それが多重継承だ。
どうやって実現しているかという手段の詳細は本質ではない。

繰り返すが、FORTRANならFORTRANで、できないのはキミだけだ。

692 ：デフォルトの名無しさん：03/11/23 21:32

>>691
> だから、やればできるよ。
コード示さないと説得力ゼロだぞ。

693 ：デフォルトの名無しさん：03/11/23 21:43

>>692
そうかもしれんが、ここは C++ のスレなんだからそれ以上は他所でやれ。

694 ：デフォルトの名無しさん：03/11/23 22:28

>>692
ニホンゴワカリマスカ？

>複数の従来製品に上位互換の新製品を作ること、それが多重継承だ。
>どうやって実現しているかという手段の詳細は本質ではない。

695 ：デフォルトの名無しさん：03/11/23 22:53

C++ だと多重継承時のオフセット調整問題は、

1. オフセットを調整したうえで実際の関数を呼び出す thunk と呼ばれる関数を
　コンパイラが自動生成する
2. オフセット調整値を仮想関数テーブル (vtbl) に記録しておく

いずれかの手法を用いるのが一般的。どちらもコンパイル時に解決する
アプローチだが、まったく別の手法として個々のインターフェースに
固有の ID 値を割り振り、インスタンス側に ID を渡すとオフセット
調整を済ませたポインタを返す関数の実装を強制するっつーのもある。
(Win32 で使われている COM 方式)

実行時効率は 1, 2 最後に COM 方式。プログラマから見た利用の手間は
1 = 2 で、COM 方式はかなり面倒。Microsoft もそれは分かっていて、
COM では ID 値の管理のためにツール・ライブラリを提供した上で、
さらに言語毎とのサポートも提供している。

そこまでやらないと、現実問題として使い物にならんよ。

696 ：デフォルトの名無しさん：03/11/23 23:13

>>691
例えば、
> データ構造とサブルーチンを、意味づけに基づいてグループ化すること。
をやろうとしたら、サブルーチンをなんかの方法でデータと結びつけることが必要だと思う。
C なんかだと、関数ポインタでやってるけど、最近の FORTRAN は関数/手続きポインタが使えるようになったのか ?
もしそうなら、俺の無恥と言うことで忘れてくれ。
また、関数/手続きポインタなんかなくても実現できると言うなら、その手段を晒してくれ。

697 ：デフォルトの名無しさん：03/11/23 23:16

FORTRAN なら、配列を構造体とみなして
>>670-673 と同じようなことをすればいけるね。
関数の呼びわけをする関数を用意して、
どの関数を呼ぶかを示すインデックスを保持しとけば
ポリモーフィズムも実現できる。
嫌んなるほどメンドクセェが、できないわけではない。

698 ：デフォルトの名無しさん：03/11/23 23:25

>>697
>>690 の問題が解決してないぞ。

699 ：デフォルトの名無しさん：03/11/23 23:28

>>698
もう少し考えてからものを言ったほうがいいと思います。

700 ：デフォルトの名無しさん：03/11/23 23:33

>>696
関数ポインタがどうしたって？？？？
多態ならswitchでもできるぞ

701 ：デフォルトの名無しさん：03/11/23 23:34

>>698
実装したけりゃ自分で勝手に実装すりゃええやろ。
もう、そこまでやってられんわ。

702 ：やねうらを氏はどう？：03/11/24 00:18

http://www.sun-inet.or.jp/~yaneurao/nlog/

一見、シモネタ話のようで
氏のページはC++、JAVAなどの弱点と長点を客観的な視点で述べ
とても参考になるTOPICが豊富だと思う。

C++相談といえば、まずは氏のページへ足を運ぶことを強く
お奨めする。

703 ：デフォルトの名無しさん：03/11/24 00:22

>>702
その名は禁句だ。

704 ：デフォルトの名無しさん：03/11/24 00:26

>>702
きもい。

705 ：デフォルトの名無しさん：03/11/24 00:36

>>700
そもそも、歴史的には switch - case をソースコード中にばら撒くと
保守性が落ちる、どうする？　ってことで多態が出てきたんじゃ？

706 ：デフォルトの名無しさん：03/11/24 00:38

>>705
そうだけど、何か？

707 ：デフォルトの名無しさん：03/11/24 00:47

それでは「多態できる」とは言えない気が。

708 ：デフォルトの名無しさん：03/11/24 00:53

>>707
気のせいだ。もう寝ろ。

709 ：デフォルトの名無しさん：03/11/24 00:56

そこかしこで、たまに聞きますね、彼の名前。

エピステーメー氏もやねうらお氏の書籍を薦めていた。
国内でのC++の普及に最も貢献している人の一人では？

710 ：デフォルトの名無しさん：03/11/24 01:08

キャラはイタいかもしれんし、たまに変なことも言うけど、
まともなことも沢山言ってるしな。
まともと思ったところだけを拾い聞きしときゃええっしょ。
むしろ、もっとイタい信者やアンチがいる方が困りもんだな...。

711 ：デフォルトの名無しさん：03/11/24 01:11

国内で最初に、
STLの必要性というか、噛み砕いた説明をしたのも、うらお氏だったかと。

C++まわりのネタなら、うらお氏のHPにたくさんあるんで、
とりあえずここで質問する前に、FAQがわりにチェックすると良いかも。

712 ：デフォルトの名無しさん：03/11/24 01:14

ネタはもうお腹いっぱいだって……

713 ：デフォルトの名無しさん：03/11/24 01:17

mapやmulitimapにて
iterator を順にたぐってる最中に、ある条件を満たしてeraseをかけたとき
そのiteratorは無効になってしまうのだろうか？

714 ：デフォルトの名無しさん：03/11/24 01:21

うらお信者が混ざりこんだようだな。

715 ：デフォルトの名無しさん：03/11/24 01:21

delete this;ってやっていいの？

716 ：デフォルトの名無しさん：03/11/24 01:21

つまらんギャグ書き散らしてしょーもないキャラだとは思うが、
抑えるべき要所はしっかり抑えているというか、
C++の近代的な機能を真っ先に実際に使ってみて、その落とし穴や
実際にぶつかる具体的な問題を提示した点で高く評価できると思うな。

717 ：デフォルトの名無しさん：03/11/24 01:23

BM98の作者だよね？KONAMI相手にいろいろ揉め事があったようだが？

718 ：デフォルトの名無しさん：03/11/24 01:27

>>715
いいよ。delete this;した後にメンバ変数に触るのはダメだよ

719 ：デフォルトの名無しさん：03/11/24 01:28

あと仮想関数も呼んだらダメ。

720 ：デフォルトの名無しさん：03/11/24 01:33

>>716
> C++の近代的な機能を真っ先に実際に使ってみて
古いって。英語読めるプログラマは、とっくに CUJ とか Modern C++
Programming, Gems などで情報を仕入れて試してる。

自分でやねうらおと同じ情報リソースにアクセスできないようだと、
先が暗いぞ。

721 ：デフォルトの名無しさん：03/11/24 01:41

>>719
ちゅーか、static でないメンバ関数は全部呼んじゃダメ。
static でないメンバ変数を使ってるからこそ
static なメンバ関数にしてないわけだし。

>>715
メンバ変数に触るなって、そんなん当たり前だし、そんなことしないよ、
と思うかもしれないけど、
コールバックする場合には気づきにくいこともある。

void Foo::foo() {
　delete this;
}
void Foo::bar() {
　m_hoge.callback(this);
　cout << m_y << endl;　// 下の m_x を表示するコードが無くても、ここでエラーが発生
}
void Hoge::callback(const Foo* f) {
　f->foo();
　cout << m_x << endl;　// foo で f が破棄されるので f.m_hoge も破棄されており、ここでエラーが発生
}

722 ：デフォルトの名無しさん：03/11/24 02:05

>>715
そのオブジェクトが必ずnewで生成されてる必要もある。
必ずnewでないと生成出来ないようにもできる。

723 ：デフォルトの名無しさん：03/11/24 03:48

class A
private:
　A() { ... }
public:
　static A* create() { return new A; }
};

724 ：デフォルトの名無しさん：03/11/24 04:46

>>711
トップページから見る気が失せたよ。。。

725 ：デフォルトの名無しさん：03/11/24 05:02

>>トップページから見る気が失せたよ。。。
中身を見ろよ。

726 ：デフォルトの名無しさん：03/11/24 05:06

○○言語でオブジェクト指向はできるか？
って話になるとなぜ変換できるかどうかの話になるの？

727 ：デフォルトの名無しさん：03/11/24 05:06

>古いって。英語読めるプログラマは、とっくに CUJ とか Modern C++
>Programming, Gems などで情報を仕入れて試してる。
とりあえず、713のイテレータ絡みの質問に答えてやれよ。

728 ：デフォルトの名無しさん：03/11/24 05:20

>>714
奴がきもいのは奴のＨＰとか見に行かなけりゃ済む話だけど、
きもい信者はどうしたらいいもんでしょう？

貢献度や人格を考えたらエピたんが叩かれた時にもう少し擁護する奴がいてもいいとは思うけど、
奴の信者はあきらかにきもい。・・・本人が信者を演じてるのか？

729 ：デフォルトの名無しさん：03/11/24 05:56

いや、キモいか否か？の問題ではないのだが・・・。
なんか、こうピント外してる人、多いね。休日だから頭も休めてるのかな？

730 ：デフォルトの名無しさん：03/11/24 07:02

eraseしたiteratorって無効なのでは？たしか

731 ：デフォルトの名無しさん：03/11/24 09:19

アンチも度が過ぎると信者とキモさは変わんないよ。
注意だ。

732 ：デフォルトの名無しさん：03/11/24 09:56

>>722
>必ずnewでないと生成出来ないようにもできる。

漏れは715じゃないんすけど、、
More Effective C++ にあるコンストラクタで例外とばすやつ？
new Foo [x] がいまいち合理的に解決できなくて悩み厨。

new Foo [x] で生成したオブジェクトの場合 delete this は
危険な香りがするんだけど、、。

733 ：デフォルトの名無しさん：03/11/24 10:11

>>732
>723

734 ：732：03/11/24 11:15

>>733
気づかなかった。。(よく見ろ＞漏れ)
ありがとう。

735 ：デフォルトの名無しさん：03/11/24 12:22

>>727
Effective STL に、そのものずばりの解答があるぞ。確か Item 9 だったと
思うが。

vector, deque では erase したら iterator は全て無効になる。それ以外
では erase したオブジェクトをさしていた iterator は無効になるが、
それ以外のオブジェクトをさしていた iterator は依然として有効。

736 ：デフォルトの名無しさん：03/11/24 12:38

型Tに対して、
　&T(...);
という式は有効なのだろうか？

5.2.3.2 によると、 T(...) は右辺値であり、
5.3.1.2 によると、演算子 & のオペランドは左辺値でなければならない。
この二つを見る限り、無効だと思うのだが、
g++(3.3.1)では"warning: taking address of temporary"
ということで、警告止まり。

737 ：デフォルトの名無しさん：03/11/24 13:05

738 ：デフォルトの名無しさん：03/11/24 13:09

739 ：デフォルトの名無しさん：03/11/24 13:26

740 ：デフォルトの名無しさん：03/11/24 13:52

>>738
じゃあ「age」と。

741 ：デフォルトの名無しさん：03/11/24 15:21

STLが新種のOTLに見えたよﾏﾏﾝ･ﾟ･(ﾉД`)･ﾟ･
漏れもうダメだ吊ってくる…

742 ：デフォルトの名無しさん：03/11/24 15:41

>>741
OTLって何? C++と関係あるもの?

743 ：デフォルトの名無しさん：03/11/24 15:52

>>742
＿|￣|○
↓
OTL

744 ：デフォルトの名無しさん：03/11/24 16:24

>>741-743
なるほど。STLは象が鬱になってるみたいだな

745 ：デフォルトの名無しさん：03/11/24 17:38

>古いって。英語読めるプログラマは、とっくに CUJ とか Modern C++
>Programming, Gems などで情報を仕入れて試してる。
とりあえず、713のイテレータ絡みの質問に答えてやれよ。
-----------------------------------------------------
やねうらお氏のページに、EffectiveSTLよりも詳細かつ具体的な
解答が掲載されている。
erase()が削除した次のiteratorを返す仕様になっていることが望ましいが
C++標準委員会では、パフォーマンスに問題があるとし、erase()の
返却はvoidである。したがって、eraseした場合は、また最初からiterator
を回さねばならない。

しかし、

vc++6.0やvc++.netの実装では、eraseは次に有効なiteratorを返却する
仕様になっている。

STLPortを含む標準STLと、VC++付属のSTLとで、このあたりに大きな仕様差
があることを、やねうらお氏は指摘している。
http://www.sun-inet.or.jp/~yaneurao/cppmaniax/chap0004.html

746 ：デフォルトの名無しさん：03/11/24 17:54

やね信者だー
たすけてー

747 ：デフォルトの名無しさん：03/11/24 19:48

>>745
なにが言いたいのかよくわからないんだけど。
やねがじゃなくて、745が。

748 ：デフォルトの名無しさん：03/11/24 22:25

C++を初めて間もない入門者なんですが...

テンプレートってやつを使おうと思って、
hoge.hppで

template <class T>
class fraction{
T numerator, denominator;
double value;
public:
fraction (T numerator_, T denominator_);
};

とし、hoge.cppという別ファイルで

#include "hoge.hpp"
template <class T> fraction<T>::fraction(T numerator_, T denominator_)
{
numerator = numerator_;
denominator = denominator_;
}

とコンストラクタを作りました。

749 ：デフォルトの名無しさん：03/11/24 22:25

そしてmain関数のファイルで

#include "hoge.hpp"

int main (void)
{
fraction<int> frac(1, 1);
return 0;
}

としてg++でコンパイルすると、
"fraction<int>::fractionがundefined referenceです"
と怒られてしまいます。

テンプレートにしなかったり、hoge.cppをhoge.hppに含めてしまうと
上手くコンパイル/動作するのですが...

よろしくお願いします。

750 ：デフォルトの名無しさん：03/11/24 22:29

>>748
> とコンストラクタを作りました。

作られるわけないだろ。
どんな型かもしれないのに、どうやってコード生成するんだよ。

それは、テンプレートの定義だけだから、hoge.hpp に入れないと当然ダメだよ。

751 ：デフォルトの名無しさん：03/11/24 22:35

＞なにが言いたいのかよくわからないんだけど。
＞やねがじゃなくて、745が。

漏れは分かったけど。

752 ：748：03/11/24 22:38

>>750
つまり「Tにintが入る」ということを
コンパイラに伝えてクラスを生成してもらう為にはヘッダに
書かねばならないということでしょうか?
なんだか不思議な気分ですが、確かに生成って感じがします。

素早い解説、ありがとうございました!

753 ：デフォルトの名無しさん：03/11/24 22:41

>>752
テンプレートはコード実体ではなく、
パラメータを与えられて初めてコードが生成される条件が揃うからね。

754 ：748：03/11/24 22:45

>>753
♂。それを初めて体で理解しました。
でも、なんか気持ち悪い気もしますが...

*.cppの方に書くやり方というのはないのでしょうか?

755 ：デフォルトの名無しさん：03/11/24 22:49

>>748
*.hppの最後に*.cppをインクルードする
ただこのとこ拡張子をcppからimpとかimplに変えたりする。

756 ：755：03/11/24 22:51

ただこのとこ->ただ、このとき

つーか、別に変えなくてもいいんだけどさ。

757 ：748：03/11/24 22:54

あ、そういう手がありましたね!
ありがとうございます。

いやー、なんか「コードの生成」ってかっこいいですね。
C++が好きになりました。

758 ：デフォルトの名無しさん：03/11/24 23:19

>>754
export という cpp の方に書くやり方はあるんだが、
実装がメンドくてコンパイラメーカーがなかなか
実装してくれないので、事実上使えなかったりする。

759 ：デフォルトの名無しさん：03/11/24 23:22

オーバーライドって必ずシグニチャを合わせないといけないんですか？
引数なし戻り値なしの純粋仮想関数を、引数あり戻り値ありの関数にオーバーライドしたいのですが、何か手はあるのでしょうか？
純粋仮想関数に環境依存した引数や戻り値を加えたくないのです

760 ：デフォルトの名無しさん：03/11/24 23:31

>>759
不可能。
つか、仮想関数って何か一から勉強しなおせ。

761 ：デフォルトの名無しさん：03/11/24 23:32

>>759
class Base {
　virtual void methodA() = 0;
};
class Derived : public Base {
　int methodA( int x ) { ... }
};

////////

Base* p;
...
p->methodA( ここをどう記述する気？ );

762 ：759：03/11/25 00:06

>>760
やはり無理ですか。仮想関数は一応わかってはいるつもりなんですが。

>>761
たとえば抽象ウィンドウクラスがあって、それを特化させてWindows用ウィンドウクラスを作りたいとします。

class Window {　//抽象ウィンドウクラス
　virtual ? Initialize( ? ) = 0;　//?の部分をどうしよう
};

class WindowsWindow : public Window {　//Windows用ウィンドウクラス
　int Initialize( HINSTANCE ... )　//環境依存
};

という事なんですが、何かおかしいでしょうか。たぶんおかしいと思いますが。

763 ：デフォルトの名無しさん：03/11/25 00:12

>>762
それをどうやって呼び出す気だ？

764 ：762：03/11/25 00:14

>>763
呼び出せないですよね。俺って何がしたいんだろう・・・sage

765 ：762：03/11/25 00:16

つまり特化で継承するときはオーバーライドじゃなくてオーバーロードしろということですね？

766 ：762：03/11/25 00:20

ていうか継承は特化なわけですが。
やっぱり一から出直してきます。ありがとうございました。

767 ：デフォルトの名無しさん：03/11/25 00:21

まぁ、Visitorパターンとか使えば全く関係のない関数呼ばせることもできるが。

768 ：デフォルトの名無しさん：03/11/25 00:23

>>765
分かってないのは仮想関数でなくてC++そのものだな。

769 ：762：03/11/25 00:29

ああ、多態するためにあるんでしたね仮想関数は。

>>768
オーバーライド時のシグニチャの問題がEffectiveC++か何かに載っていたような気がしたのでそれも復習します

770 ：デフォルトの名無しさん：03/11/25 00:40

>>762

とりあえず、やねうらお氏の過去日記を一通り読むことを
お奨めする。その中の一つに、ずばり解答があるよ。

って書くと、また「信者きもい」とか言われるんだろうな。

771 ：デフォルトの名無しさん：03/11/25 00:51

「その中の一つ」の URL を黙って貼ればいいのに。

772 ：デフォルトの名無しさん：03/11/25 00:53

>>770
別にそこでなくともよかろうに、わざわざやねやね言うな。
ご希望通り言っておくよ、信者きもい。

773 ：デフォルトの名無しさん：03/11/25 00:57

>>767
プラットホーム依存部分を分離したいって話だと、むしろ Builder か
Bridge の出番かと。ダブルディスパッチっぽいことをやりたいなら
Visitor がピッタリだけど。

774 ：762：03/11/25 01:11

やね氏の本の1と2買ったんですが、あれは酷いと思いました。
真面目に理解しようと読んでるのに、すぐつまらない事言って茶化す。
「何馬鹿な事言ってんだこいつ？」というのと、相手が実力者でこちらが教えを乞うているという立場にあるという葛藤。
とてもイライラしました。馬鹿なDQNヲタにとってはすごく楽しいんでしょうね。嫌味でなく羨ましい。

ま、無能の負け惜しみです。くたばれシャーマンやねアンチ信者
もう疲た

775 ：デフォルトの名無しさん：03/11/25 01:13

>>774
すごいイタいアンチだな。

776 ：デフォルトの名無しさん：03/11/25 01:14

買う前にチェックしろよ…
人を罵倒する前に自分の愚かさを改めなさい。

777 ：デフォルトの名無しさん：03/11/25 01:21

>>774
痛さが感染してるぞ。

778 ：デフォルトの名無しさん：03/11/25 01:21

>>762
デザパタ用語に反応しないってことは知らないってことかな?
そっちも知っとくと良いよ。

779 ：デフォルトの名無しさん：03/11/25 01:31

やね氏のつまらないギャグがｲﾀｲのは分かるが、
場を和ませるための挿入だったりするので、そこ突っ込みすぎると
かえって揚げ足どりになるかも。

肝を読んでみては？

780 ：デフォルトの名無しさん：03/11/25 01:34

その名は禁句だと言ってるだろ。
いったい何の話がしたいんだ？

781 ：デフォルトの名無しさん：03/11/25 01:36

プログラミング関係の書籍の寒いギャグは翻訳もので慣れた。

782 ：デフォルトの名無しさん：03/11/25 02:04

>>781

ははは。禿同。
なんで海外モノの技術書って、寒すぎるギャグが連発するんだろ？
日本人のギャグのレベルが高すぎるのだろうか？

少なくとも、向こうでは「ｲﾀｲ」と認識されてないから止まないんだよな？

783 ：デフォルトの名無しさん：03/11/25 02:13

アメリカンジョークなんてたいがいそんなものだよ

784 ：デフォルトの名無しさん：03/11/25 02:14

寒いだけならましで、理解できないのもたまにある。

785 ：デフォルトの名無しさん：03/11/25 02:16

>>782
ジョークってのはかなり文化に根ざしてるから翻訳すると寒いのが普通。
ましてや書いてる人間も笑いのプロじゃないわけだし。

786 ：デフォルトの名無しさん：03/11/25 02:16

>>アメリカンジョークなんてたいがいそんなものだよ
けど、映画やなんかだと、そんな寒いギャグってないんだよなぁ。

787 ：デフォルトの名無しさん：03/11/25 02:19

>>786
ものにもよるけど、
プログラミング本のギャグ→笑いのプロが書いてない
映画のギャグ→笑いのプロが書いてる
が前提だし。

788 ：デフォルトの名無しさん：03/11/25 02:23

それ以上は他所でやれ。ここは C++ のスレ。

789 ：デフォルトの名無しさん：03/11/25 03:56

>>782
つーか文化の違いによるセンスの差をそのまま優劣に変えて、
しかも何の疑問もなく自分を上に置くお前のほうが寒い。

790 ：デフォルトの名無しさん：03/11/25 05:46

＞プログラミング本のギャグ→笑いのプロが書いてない
＞映画のギャグ→笑いのプロが書いてる
でも、それって日本でも当てはまる前提条件なんだよなー。
そもそも日本の場合、プログラミングの本にギャグなんか載せないし。
たまに例外があったとしても、やねうらお本くらいだし。

＞つーか文化の違いによるセンスの差をそのまま優劣に変えて、
確かに優劣うんぬんをつけるものではないと思うけど、
アメリカンジョークってまじで寒くてｲﾀｲかと。
文化に根ざしているものの違いうんぬん以前に。価値観の違いの問題ではないと思うな。

791 ：デフォルトの名無しさん：03/11/25 05:52

＞「何馬鹿な事言ってんだこいつ？」
＞というのと、相手が実力者でこちらが教えを乞うているという立場にあるという葛藤。
ぶはははははははは。
キミ、意外と正直者だね。このスレの住人も素直になれば
キミに激しく同意する人も少なくないんじゃないかな？

つまらんギャグはノイズとして目をそらして、中身を見るようにすれば
それなりに有用な著だと思う。

実際、「C++に関して、やねうらをよりも博識で経験も豊富である」と
自信もって言える人、少ないでしょ？

792 ：デフォルトの名無しさん：03/11/25 06:28

ここはやねうらおスレッドではない。
信者もアンチも他所でやってくれ。

793 ：デフォルトの名無しさん：03/11/25 07:15

旗色悪くなるとすぐスレ違いとか言い出すなあ。

794 ：デフォルトの名無しさん：03/11/25 07:16

それまで乗り気なくせに。

795 ：デフォルトの名無しさん：03/11/25 07:24

お前らさてはゲーラボ読んでるな！

796 ：デフォルトの名無しさん：03/11/25 07:32

>>793
旗色って？だれか言い争ってるの？
妄想もたいがいにしといてくださいよ。

797 ：デフォルトの名無しさん：03/11/25 09:14

そんな議論よっか、せっかくだから>>762の解答ズバリのページを教えてくれよ。

798 ：デフォルトの名無しさん：03/11/25 09:22

あのさ、俺ダブルディスパッチってなんだか理解できないんだけど、
言葉が出てきたから質問してもいいかな？

要するに、俺が相手にに仕事しろって命じたら、
相手がその詳細を知らなくて、俺に仕事をそのまま回すことだよな。

なんでそれだけのことにダブルディスパッチなんて仰々しい名前がついてるんだ？
インタプリタのソースとか読んでるとこの名前が出てきて
いきなり尻込みするんだが。

799 ：デフォルトの名無しさん：03/11/25 10:21

>>798
ダブルディスパッチは、Modern C++ Degisnに出てくる
二つの異なるクラスの関係に対応した処理を選択する手法。

例は、形状クラス同士の重なりを判定するときに
形状には円クラスや四角形クラス、多角形クラスがあるとして
それぞれの組み合わせに最適な処理を選択する方法が出ている。
テンプレートを使ってね。

この言葉が>>773ででてきたのは、Window作成パラメータ型が
環境固有の型だとして、それを渡すと勝手に対応する環境の
Window派生クラスが選択されるという仕組みを指してるんだろう。

800 ：デフォルトの名無しさん：03/11/25 12:25

最近VC++の勉強を始めた者ですが、教材にVC++6.0を使ってます。
VC++.NETにするべきですか？
個人的には変えたほうがいいかとも思いますが、
いまいち分からないので。

801 ：デフォルトの名無しさん：03/11/25 13:02

C++でリフレクションって使えますか？
できれば環境依存せずに。

802 ：デフォルトの名無しさん：03/11/25 13:05

>>801
使えない

803 ：デフォルトの名無しさん：03/11/25 14:04

>>800
VC++6.0 は C++ の仕様がちと古いので
欲を言えば VC++.net 2003 の方がいい。
ただ、金がなければ無理して買うまでもない。

804 ：デフォルトの名無しさん：03/11/25 14:45

new可能な最大メモリサイズを知りたかったので

MEMORYSTATUS.dwAvailPhys を使って
現在の未使用物理メモリを求めた後に new をしています。
dwAvailPhys=500MBの時に500MBを new した場合に
メモリ不足エラーになるのはしょうがないと思うのですが
400MBや450MBくらいを new した場合でも
「メモリが不足しています」
と表示される事がよくあります。

この原因はメモリ断片化／ページングなどのせいで
実際は500MB余っているが、この500MBはあくまで合計で
連続した領域ではない場合に発生するのでしょうか？
（newは連続した領域を取るのでそう思いました。）

もしこれが原因ならば（全然違ってたらすみません。。）
純粋に現在new可能なサイズを知るにはどうすればよいのでしょうか？
もしくはメモリ断片化をnew直前に最適化できたりするのでしょうか？

OSはWin2000/XPです。
よろしくお願いします。

805 ：801：03/11/25 16:40

リフレクションなんとかなりませんか？

806 ：デフォルトの名無しさん：03/11/25 17:02

>>805
変数なら、map<string, variant> に全メンバを格納するとか。
関数は難しいと思う。

807 ：800：03/11/25 17:04

>>803
では、変えなくていいということでFA？

808 ：デフォルトの名無しさん：03/11/25 18:33

>>807
http://www.microsoft.com/japan/msdn/visualc/productinfo/topten/upgrade60.asp
このあたりでも見て自分で考えろ。

809 ：デフォルトの名無しさん：03/11/25 18:40

とりあえず.NETが捨てられることは確定したわけだから
6.0持っていて2003買うくらいなら次のまで待ったほうがいいと思うけど。

810 ：デフォルトの名無しさん：03/11/25 18:52

templateとかきっちり使いたい or 使ったライブラリを使いたいなら
2003にすべき。

811 ：デフォルトの名無しさん：03/11/25 19:04

>>810
それだけならgccにしたほうがいいと思うが

812 ：デフォルトの名無しさん：03/11/25 19:16

＞＞お前らさてはゲーラボ読んでるな！
はて？なんで、そう思ったの？

＞＞dwAvailPhys=500MBの時に500MBを new した場合に
どういう用途かは知らないけど、まず、500MBをnewするのではなく
staticな配列にしてみてはどうだろう？

813 ：やね信者：03/11/25 19:22

＞純粋に現在new可能なサイズを知るにはどうすればよいのでしょうか？
＞もしくはメモリ断片化をnew直前に最適化できたりするのでしょうか？
一応、環境非依存な方法を教えてあげるよ。
まず、2Gバイト確保要求。で、mallocが確保に失敗すればNULLを返却する。
で、失敗したら半分の1Gバイト確保。
それでも、失敗したら次はさらに半分の512MB確保要求。
でも、失敗したら、256MBで。
成功したら、256+256/2=384MB確保。

以下、繰り返すと、最悪でも28回程度で、正確な確保限界サイズが
判明する。（確保に成功したら、即座に解放するのもお忘れなく）

なんらかのステータス取得すれば、あっさり求まるとは思うけど、
一応、どんな環境でも適応できるので、一度組むと重宝すると思うよ。

814 ：デフォルトの名無しさん：03/11/25 19:31

>>813
それじゃだめじゃん。
アドレスだけ予約してページ違反が発生するまで実際に確保しない可能性だってあるんだし。

815 ：デフォルトの名無しさん：03/11/25 19:44

std::exceptionの実装が見つかりません。
includeフォルダにあるファイルexceptionには定義しか書いてありません。
includeフォルダを検索しても見つからず、CRTのソースフォルダにも見あたりません。
いったいどこにあるのでしょうか?

VC++6.0 SP5

816 ：デフォルトの名無しさん：03/11/25 20:12

ないね。
コンパイラが内蔵してるんじゃないの？

817 ：デフォルトの名無しさん：03/11/25 20:39

liboctave + atlas 使って数値計算してる香具師いる？
blitzとの比較教えて

818 ：デフォルトの名無しさん：03/11/25 21:30

>>813
漏れはアンチ派だが、ちゃんと名乗っていることにはとっても好感が持てる。
ただ、その案はとてもオススメできる話じゃないぞ。
「free 関数 == ランタイムルーチンがシステムにメモリを開放」ってわけじゃないからな。
(そういう実装の環境・処理系も存在はするだろうが。)

819 ：デフォルトの名無しさん：03/11/25 21:53

>>818
>「free 関数 == ランタイムルーチンがシステムにメモリを開放」ってわけじゃないからな。

どうせ、ある特定のソースが根拠だろ。
仕様と実装の区別がつかない痛厨。

820 ：デフォルトの名無しさん：03/11/25 22:04

>>819

>>813
>一応、どんな環境でも適応できるので、一度組むと重宝すると思うよ。

821 ：デフォルトの名無しさん：03/11/25 22:05

>>819
システムにメモリを返却することが保証されているわけじゃないんだから
それに期待した実装をするほうが厨だと思うんだが、どうよ？
特に今回のケースのように他へ影響を及ぼす場合は特に。

822 ：デフォルトの名無しさん：03/11/25 22:07

16bit環境下でのエクステンダーなんてものもあるしねぇ。

823 ：デフォルトの名無しさん：03/11/25 22:25

最近始めて、なぜVC6を使ってるのかがギモン

824 ：やね信者：03/11/25 23:01

>それじゃだめじゃん。
>アドレスだけ予約してページ違反が発生するまで実際に確保しない可能性だってあるんだし。
んむ、一応その可能性も考えた上なのだ。っていうのも

>dwAvailPhys=500MBの時に500MBを new した場合に
>メモリ不足エラーになるのはしょうがないと思うのですが
という質問の文脈からして、newした時点での問題だと思うから。

>「free 関数 == ランタイムルーチンがシステムにメモリを開放」ってわけじゃないからな。
次の確保に備えて、そのような実装もあるとは思うけど、
一般的なヒープでは、free()した直後は、確保領域もそのぶん解放される
と考えて良いのでは？と思う。

825 ：800：03/11/25 23:03

いろいろな意見ありがとうございます。
参考にさせていただきます。

>>823
おそらく私に対してのレスだと思いますので説明させてもらうと、
仕事場にあったやつです。
それを捨てるって言うんで、もらってきただけの事。
他にもVB6.0とかVJ(だったっけ？)があったけど、
VC++にした。
そういうことです。

826 ：デフォルトの名無しさん：03/11/25 23:14

プログラマーに知能指数は必要ですか？

827 ：デフォルトの名無しさん：03/11/25 23:15

>>824
>>「free 関数 == ランタイムルーチンがシステムにメモリを開放」ってわけじゃないからな。
>次の確保に備えて、そのような実装もあるとは思うけど、
>一般的なヒープでは、free()した直後は、確保領域もそのぶん解放される
>と考えて良いのでは？と思う。

百歩譲って、その主張が全面的に正しいかったとしても、
そのタイミングで別プロセスが無駄にメモリの確保に失敗することになるぞ。

>>819
氏ね。

828 ：デフォルトの名無しさん：03/11/25 23:20

>>824
環境非依存を謳い文句にするなら
環境依存の書き込みを基準にしちゃダメじゃん。
一般的な環境を基準にしちゃダメじゃん。

829 ：デフォルトの名無しさん：03/11/25 23:39

別に他のプロセスがどれだけメモリ確保してようが、
該当プロセスの仮想メモリアドレス空間が足りてれば
確保に成功するはずだが。

830 ：デフォルトの名無しさん：03/11/25 23:47

>>829
仮想メモリの総量には限界があるだろ。

831 ：デフォルトの名無しさん：03/11/25 23:48

環境非依存でお願いします。

832 ：デフォルトの名無しさん：03/11/25 23:57

問題になるのは仮想メモリと実装メモリだけじゃないしな。
windowsだとプロセスに割り当てられるヒープサイズにも影響している。
初期だと200MB位じゃなかったか？

833 ：デフォルトの名無しさん：03/11/26 00:56

unixだと確保できるけど、実際に代入開始するといきなりswapはじめるんだよなぁ。

834 ：デフォルトの名無しさん：03/11/26 04:22

400MB も連続したメモリを扱おうとしている事自体を
やめた方がええんでなかろうか。
いくつかに分割して扱うようにして。

835 ：やね信者：03/11/26 04:52

＞百歩譲って、その主張が全面的に正しいかったとしても、
＞そのタイミングで別プロセスが無駄にメモリの確保に失敗することになるぞ。
なりません。あるプロセス内のヒープの成否は、他プロセスのヒープの成否に
なんら影響を与えません。

ちなみにですが、Windows環境にせよunix環境にせよ
いきなり malloc( 256メガバイト ) としても、実際に消費される
物理メモリはたったの4kb～8kbです。実際にアクセスしてみるまでは
swapだとか発生しないのです。

ただ833さんの指摘するような現象が発生する危険性はありますが。
だとしてもメモリ確保の失敗か成功かは、全く別の話題になるかと。

836 ：デフォルトの名無しさん：03/11/26 07:57

>>835
グローバルヒープとローカルヒープの違いわかってる？

837 ：デフォルトの名無しさん：03/11/26 08:22

これだからやね信者は困る、と言われそう

838 ：デフォルトの名無しさん：03/11/26 15:47

>>836
http://www.nifty.com/webapp/digitalword/word/014/01479.htm

WindowsNT系ではグローバルヒープとローカルヒープの実質的
違いはない。APIは残されてるけど。

839 ：やね信者：03/11/26 18:41

>>グローバルヒープとローカルヒープの違いわかってる？

えっと、
環境非依存といいつつ、実質、32bitポインター以上の環境であることを
前提に話を進めてます。だって、C++相談室なスレで
16Bitな環境を考慮に入れてもなにかと現実的でないでしょ？

で、Win95以降な32Bitな場合（もちWinNTも含めて）、
グローバルヒープだとかローカルヒープだとかの概念がそもそもないです。
なので、

>>違いわかってる？
違いがないので、わかりません。

840 ：やね信者：03/11/26 18:43

例えば、vc++.netであれば、\Vc7\include にあるmalloc.hを
見れば分かるですよ。

841 ：デフォルトの名無しさん：03/11/26 22:01

>>838
勉強し直せ。

>>839
>環境非依存といいつつ、実質、32bitポインター以上の環境であることを
>前提に話を進めてます。

勝手に前提を崩すな。
そんなこと言うなら初めから「どんな環境でも適応できる」なんて軽々しく言うなよ。

>>840
環境非依存の話なのに特定の処理系を持ちだしてそれでヨシとするなよ。
お前はそれで満足なのかもしれんがそれじゃ他人を説得できんぞ。

842 ：デフォルトの名無しさん：03/11/26 22:05

グローバルヒープとか言い出した時点で、環境非依存ではないし、
そもそもの804自体、MEMORYSTATUS.dwAvailPhysとかいって
環境依存だし、あんたは人を論難するだけで建設的なことを言わないし。

843 ：デフォルトの名無しさん：03/11/26 22:29

未来永劫一切freeすんな
メモリ枯渇が心配なら買え
PetaSiteでスワップしろ

844 ：デフォルトの名無しさん：03/11/26 22:54

>>842
>グローバルヒープとか言い出した時点で、環境非依存ではないし、

環境非依存というのはいろんな環境で問題がないことを示す必要が
あることは理解できますか？

>あんたは人を論難するだけで建設的なことを言わないし。

代案無き批判がすべて価値のないものだとでも思ってるのですか？
もし、そう思ってるんなら無視すりゃいいだけ。いちいち相手にすんな。

845 ：デフォルトの名無しさん：03/11/26 23:43

C++超初心者ですが、質問です。
現在hashとqueueを組み合わせたようなデータ構造をrubyで作成しました。
idとdataが入力されたら、idごとに分けてqueueに格納していきます。

rubyだと、
hashqueue = Hash.new
hashqueue[id].push(data)
のように書きましたが、C++だとどのように書くのでしょう？

std::map<int, std::queue<int> > hashqueue;
hashqueue.insert(pair<int, std::queue<int> >(id, c));
と書いてみましたが、エラーがでます。式の構文エラーと、未定義のシンボルpairと表示されます。
何か根本的に間違っているのでしょうか？
馬鹿な私にどうか教えてください。

846 ：デフォルトの名無しさん：03/11/26 23:48

std::map は hash とは限らない。
STL じゃないけど、最近は std::hash_map が付いてることが多いんで、
こっちを使った方がいいかも。

で、std::map にしろ、std::hash_map にしろ、
　hash[id].push(data);
という風に使えるはず。

847 ：デフォルトの名無しさん：03/11/26 23:49

>>845
>超初心者

「初心者」を「超」えている・・・つまるところ、中級者ですね。

848 ：デフォルトの名無しさん：03/11/26 23:50

とりあえず、pair は std::pairだから。

849 ：デフォルトの名無しさん：03/11/27 00:06

>>844
>環境非依存というのはいろんな環境で問題がないことを示す必要が
>あることは理解できますか？

「問題がある環境」がconforming implemenationであることの証明は？

850 ：デフォルトの名無しさん：03/11/27 00:07

↑
「問題がない環境」がconforming implemenationであることの証明も必要

851 ：デフォルトの名無しさん：03/11/27 00:08

conforming implementationでない環境を非難する意図は毛頭ないが

852 ：デフォルトの名無しさん：03/11/27 00:20

>>849
>「問題がある環境」がconforming implemenationであることの証明は？

必要ありません。

853 ：デフォルトの名無しさん：03/11/27 00:25

>>845
std::map<int, std::queue<int> >型が扱うのは
pair<int, std::queue<int> >じゃなくてpair<const int, std::queue<int> >です。

854 ：デフォルトの名無しさん：03/11/27 00:41

>>853
そこはどうでもいい。
pair<int, std::queue<int> > は pair<const int, std::queue<int> > に暗黙的に変換できる。

855 ：デフォルトの名無しさん：03/11/27 00:50

>>852
どっちにでも取れる玉虫色だなｗ

856 ：デフォルトの名無しさん：03/11/27 01:07

いい加減に非を認めろよー。
認めたくないなら、それはそれでとっととケツまくれ。
いつまでもウジウジ、うざい。

857 ：やね信者：03/11/27 01:32

＞環境非依存の話なのに特定の処理系を持ちだしてそれでヨシとするなよ。
＞お前はそれで満足なのかもしれんがそれじゃ他人を説得できんぞ。

いや、だからおいらが813で示した方法は環境非依存だよ。
Win32、cygwin、linux、solaris、mac(OS9)はもちろん。
ARMを乗せたDVD操作リモコンで
32キロバイトのメモリしか積んでないケースでもいけたんだから。
（ヒープ容量は16kb）

逆に聞きたいけど、おいらが、813で示した方法でヒープの残りサイズが
正しく求めることができない環境の具体例を挙げてみてよ。

そんで、16Bit環境のmallocの引数は当然、16Bitだから2Gバイトなんで
数値渡せないけどさ、それでも813の方法で求められるんだよ。
最初に調査する2Gの数値を32768に置き換えるだけで。
MS-DOSでもこれでいける筈。

とりあえず、具体的な例外環境を挙げておくれ。
これといって、挙げられないなら、環境非依存だよ。

858 ：デフォルトの名無しさん：03/11/27 01:37

>>857
>正しく求めることができない環境の具体例を挙げてみてよ。

初めから誰もその点については否定してませんが。
問題をすり替えちゃダメ。

859 ：デフォルトの名無しさん：03/11/27 01:41

#include <iostream>

template <typename A,typename B>
class hoge
{
　　friend std::ostream& operator<<(std::ostream&,const hoge&);
　　A a;
　　B b;
public:
　　hoge(A a_,B b_):a(a_),b(b_){}
};

template <typename A,typename B>
std::ostream& operator<<(std::ostream& out,const hoge<A,B>& h)
{
　　out << '(' << h.a << ',' << h.b << ')' << std::endl;
}

int main()
{
　　hoge<int,int> h(1,2);
　　std::cout << h;
　　return 0;
}

860 ：デフォルトの名無しさん：03/11/27 01:41

↑こんなかんじのファイルをコンパイルすると
hoge.obj : error LNK2019: 未解決の外部シンボル
"class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl operator<<(
class std::basic_ostream<char,struct std::char_traits<char> > &
,class hoge<int,int> const &)"
(??6@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@AAV01@ABV?$hoge@HH@@@Z)
が関数 _main で参照されました。
hoge.exe : fatal error LNK1120: 外部参照 1 が未解決です。
といったエラーが出てしまうのですがどうしてでしょうか?
環境はVC++7.1です。

861 ：デフォルトの名無しさん：03/11/27 01:46

>>857
STLportのノードアロケータは、標準に適合したmalloc/newの実装となり得るが、
813の方法ではヒープの残りサイズを正しく求めることができない。

862 ：デフォルトの名無しさん：03/11/27 01:47

operator << は何も返さなくてもコンパイルできるん？

863 ：デフォルトの名無しさん：03/11/27 01:47

>>857 これといって、挙げられないなら、環境非依存だよ。

使用にあたって実害がないというだけ。
これはイコール環境比依存とはならない
以前どこかのスレで話に出た浮動少数型をゼロでメモリクリアする問題も
IEEE754を採用してない例を誰もあげていなかったが、
環境非依存ではなく、実害がないという結論に落ち着いたはず。

あなたの言い分だと、上の問題も環境非依存であるというのと同じ。

864 ：デフォルトの名無しさん：03/11/27 01:51

>>860
template class hoge<A,B> で friend として宣言されている関数は
std::ostream& operator<<(std::ostream&,const hoge<A,B>&);
であって、
template std::ostream& operator<< <A,B>(std::ostream&,const hoge<A,B>&);
ではない。

865 ：デフォルトの名無しさん：03/11/27 02:00

>>863
だから、害ならあるんだって。
Win3.1 でそんな方法をとったら他のプロセスに実害がでるの。

もう、いい加減に非を認めるかケツまくれって。ホント、うざいぞ。

866 ：デフォルトの名無しさん：03/11/27 02:06

実はアロケートされたメモリでも書き込みがあるまで割り当てが遅延される。
moatの範囲を知ったところで、残りメモリ量を知ることは無理。

867 ：デフォルトの名無しさん：03/11/27 02:06

>>865
ん？何をそんなに怒ってるのかわからんのだが。

挙げられないのなら、を受けて
（挙げられなかったとしても）使用にあたって実害がないというだけ。

と返したかっただけだよ。
>>857の書き込みは環境に依存していないということを証明してないぞってね。

868 ：859：03/11/27 02:07

>>862
return out;
を書き忘れていました。

<<864
テンプレート関数のfriend宣言はどう書いたらいいのでしょうか?
friend template std::ostream& operator<< <A,B>(std::ostream&,const hoge<A,B>&);
ではエラーになってしまいます。

869 ：デフォルトの名無しさん：03/11/27 02:14

>>868
friend std::ostream& operator<< <>(std::ostream&,const hoge&);
ちょっとキモイけど。

870 ：859：03/11/27 02:22

>>869
それでもエラーになってしまいます。

871 ：デフォルトの名無しさん：03/11/27 02:26

>>867
文意を履き違えますた。すまそ。

>>857
>>813 の方法にダメ出ししとくと、atomic な処理じゃないからやってる最中に
他プロセスがメモリの確保・解放をするだけで影響を受けて明後日な結果になるぞ。
まぁ、仮に atomic に処理できて正確なサイズが手に入っても他プロセスのメモリ操作で
無効な数値になるから所詮、目安の域をでないけどな。

872 ：デフォルトの名無しさん：03/11/27 02:36

>>870
エラーメッセージは？

873 ：859：03/11/27 02:45

>>872

(6): error C2143: 構文エラー : ';' が '<' の前にありません。
コンパイルされたクラスのテンプレートのインスタンス化 'hoge<A,B>' の参照を確認してください
(6): error C2433: 'operator`<<'' : 'friend' はデータ宣言をするのに使用できません。
(6): error C2530: 'operator`<<'' : 参照が初期化されずに宣言されています。
(6): error C2238: ';' の前に無効なトークンがあります。
(18): error C2904: '<<' : 名前は、現在のスコープで、テンプレートに対して既に使用されています。
'operator`<<'' の宣言を確認してください。

こんなかんじです

874 ：デフォルトの名無しさん：03/11/27 02:57

うーん。gccならとおったんだけど。もうわかんないや。

875 ：859：03/11/27 03:14

>>874
operator<<のプロトタイプ宣言が抜けてるだけでした。
それで869のfriend宣言でうまくいきました。
ありがとうございました。

876 ：デフォルトの名無しさん：03/11/27 03:17

>>875
あれ？
friend 宣言は名前空間スコープでの宣言を兼ねるはず。
ちょっと気になるので、うまくいったソース貼ってほしいなぁ。

877 ：859：03/11/27 03:38

>>876
#include <iostream>

template <typename A,typename B> class hoge;

template <typename A,typename B>
std::ostream& operator<<(std::ostream& out,const hoge<A,B>& h)
{
　　out << '(' << h.a << ',' << h.b << ')' << std::endl;
　　return out;
}

template <typename A,typename B>
class hoge
{
　　friend std::ostream& operator<< <>(std::ostream&,const hoge&);
　　A a;
　　B b;
public:
　　hoge(A a_,B b_):a(a_),b(b_){}
};

int main()
{
　　hoge<int,int> h(1,2);
　　std::cout << h;
　　return 0;
}
です。

878 ：859：03/11/27 03:45

>>877
こっちでした。
#include <iostream>

template <typename A,typename B> class hoge;
template <typename A,typename B> std::ostream& operator<<(std::ostream&,const hoge<A,B>&);

template <typename A,typename B>
class hoge
{
friend std::ostream& operator<< <>(std::ostream&,const hoge&);
A a;
B b;
public:
hoge(A a_,B b_):a(a_),b(b_){}
};

template <typename A,typename B>
std::ostream& operator<<(std::ostream& out,const hoge<A,B>& h)
{
out << '(' << h.a << ',' << h.b << ')' << std::endl;
return out;
}

int main()
{
hoge<int,int> h(1,2);
std::cout << h;
return 0;
}

879 ：845：03/11/27 14:15

>>846,848,853,854
どうもありがとうございます。がんばってみます。

880 ：デフォルトの名無しさん：03/11/27 20:09

質問させてください
今、stringクラスで"4-5-34-2"のように、数字と"-"からなる文字列を持っています。
ここから数字だけを取り出したいんですが、いい方法はありますか？
rubyとかだと、split(/-/)があるので簡単なんですけど・・

881 ：デフォルトの名無しさん：03/11/27 20:10

remove_ifとisdigitかな。

882 ：デフォルトの名無しさん：03/11/27 20:23

>>880
boost::RegEx("-").Split();

883 ：デフォルトの名無しさん：03/11/27 20:37

なんかおまいらの議論は、思いっきり基本的なところでズレてるな。

>ヒープの残りサイズが正しく求めることができない

そもそも正しい値なんかあるのか？
x = coreleft(); // 仮にこいつが「正しい値」を返しても
p = new char[x]; // この時点で既にあてにならん
処理系非依存でクリティカルセクションが書けるものなら書いて見ろ。

しかもそれ以前の問題でメモリ管理に特殊機能が必要な場合は
operator new を自作して、そいつとペアで残量問い合わせ関数やら
用意するのが C++ のど基本だろうがよ。　違うか？　てめーら

884 ：デフォルトの名無しさん：03/11/27 20:56

>>883
そういう風に構ってあげると「漏れは賢いんだから何でも論破する」君が騒ぐから、
みんなわかってて傍観してるんだと思う。

885 ：デフォルトの名無しさん：03/11/27 21:12

>>883

なにをいまさら？

886 ：デフォルトの名無しさん：03/11/27 21:34

>>884
そういう煽りは他所でやれ。

887 ：デフォルトの名無しさん：03/11/27 22:34

>>885
昨日の話だ
逃げたければ逃げろ

888 ：デフォルトの名無しさん：03/11/27 22:42

ε--==≡≡┌（×o×）┘887

889 ：デフォルトの名無しさん：03/11/27 22:49

885==888

そんなに悔しがらなくてもいいじゃん。

890 ：デフォルトの名無しさん：03/11/27 22:54

このスレの連中、ｷﾓｲ香具師おおすぎ
いつ初心者をぶったたこうか、うずうずしてるやつとかいるし。

891 ：デフォルトの名無しさん：03/11/28 06:59

やね信者が現実的なラインで環境非依存な方法を示しているのに、
証明したことにはならないだの、Win3.1ではそれでは困るだの言い出す厨
ってキモい通り越して藁族かも。

この厨、多分、手元にWin3.1が起動するPCがないってのもお約束だったりｗ
コーディング時間よりも2ch閲覧時間のほうが長い人種。
ぶはははははははは。

892 ：デフォルトの名無しさん：03/11/28 07:08

>>891
やね信者さんおはようございます。
環境非依存と実質非依存の大きな隔たりについて
よく勉強してみてください。
それでは失礼します。

かしこ

893 ：デフォルトの名無しさん：03/11/28 07:19

お前らみんなやねスレへ行け。
そして二度と戻ってくるな。

894 ：デフォルトの名無しさん：03/11/28 12:16

浦島太郎の天然ボケのせいでまた荒れてるのね

895 ：デフォルトの名無しさん：03/11/28 19:12

>>浦島太郎の天然ボケ
ま、このスレにはWin3.1な住人がいるみたいだし。

896 ：デフォルトの名無しさん：03/11/28 19:31

>>環境非依存と実質非依存の大きな隔たりについて
なんか、まだ粘着がいるな。
そもそも両者に大きな隔たりあるのだろうか？

じゃ、例えば、
（A)「C++は環境非依存である」
（B)「C++は実質環境非依存である」

のどっち？A宗？B宗？
俺はどっちも大差ないと思うし、議論の余地ないほど些細だと思う。
だとすれば、大きな隔たりなどないのでは？

897 ：デフォルトの名無しさん：03/11/28 20:38

>>896
大きさは関係ない
== と != でしかない

898 ：デフォルトの名無しさん：03/11/28 21:01

もう興奮しまくり

899 ：デフォルトの名無しさん：03/11/28 21:02

>>896
そもそも、そういう問題じゃないと思うんだが。

>>813
>環境非依存な方法を教えてあげるよ

このへんはまぁ、ヨシとしよう。

>>813
>どんな環境でも適応できる

ポイントはここですな。
こんなこと言っておいて後から、16bit は知らんだの、
実質環境非依存なんだと言ったって恥ずかしいだけ。

900 ：デフォルトの名無しさん：03/11/28 21:11

C++ってやって見ないと分からないことって結構あるね。
void func(int a = (MessageBox(NULL, "省略するな！", NULL, MB_OK), 0) ) {}
こんなこと出来るとはおもわなんだ。

901 ：デフォルトの名無しさん：03/11/28 21:24

>>900
ttp://www.tietew.jp/cppll/archive/2711

902 ：デフォルトの名無しさん：03/11/28 21:36

>>900
優先順位おぼえような

903 ：デフォルトの名無しさん：03/11/28 21:41

>>902
よく見れ。

904 ：900：03/11/28 21:48

既出でしたかやっぱり。
今まで定数しか駄目だと思い込んでもんで。
これ使えば引数だけでプログラム組めそうですなぁ。
カンマ演算子同様出来ないと思い込んでること多いねぇ。

905 ：901：03/11/28 21:56

>>904
既出ってんじゃなく、単に類似したものを参考までにと。

906 ：900：03/11/28 22:27

>>905
よく見たらちょっと違ってました。
関数の戻り値をデフォルト引数に指定できるとは！
ということがただ単に言いたかっただけでして。

907 ：デフォルトの名無しさん：03/11/28 22:35

>>906
知ってる鴨しれへんけど、
あと、(一時？)オブジェクトや、
グローバル変数なんかもイケるよ。

908 ：900：03/11/28 23:24

>>907
外部から関数の振る舞いを変えてしまう変なプログラムが組めますな。
知ると知るほどスゲー言語だなぁと思ってしまう。
自由度が高すぎるというかなんと言うか…

909 ：デフォルトの名無しさん：03/11/28 23:31

>>908
無理やりその様を例えると「 C 言語が石製の鈍器だったのに対し、
C++ は金属製の鈍器だと思って使ってたら、実は銃器だった。」みたいな感じだよね。

910 ：デフォルトの名無しさん：03/11/28 23:41

>>908
その自由度を生かすも殺すもプログラマ次第

911 ：デフォルトの名無しさん：03/11/29 00:36

>>896
俺は 892 じゃないが、ほとんどの人は(A)でも(B)でもないと答えるだろうな。
（A)「C++は環境非依存である」
（B)「C++は実質環境非依存である」
(C++) 「C++は実質環境依存である」

912 ：900：03/11/29 00:43

>>909-910
これはできないか、あれはできないかと試してばかりいて全然プログラムが前に・・・
逆に自由度という銃に狙われて逃げ惑っております。

templateにも参照であればグローバル変数渡せるみたいです
文字列定数素直に渡せればこんなまどろっこしいことしなくてすむんですけどねぇ

TCHAR *g_msg1 = _T("逝ってよし");
TCHAR *g_msg2 = _T("オマエモナー");
template<const TCHAR *& str = g_msg1>
struct msg
{
　msg() { MessageBox(NULL, str, NULL, MB_OK); }
};

main()
{
　msg<>(); // 逝ってよし
　msg<g_msg2>(); // 逝ってよし
　g_msg1 = _T("ｳﾝｺｰ");
　msg<>(); // ｳﾝｺｰ
}

913 ：デフォルトの名無しさん：03/11/29 00:49

>>909
> 「 C 言語が石製の鈍器だったのに対し、
>　　C++ は金属製の鈍器だと思って使ってたら、
>　　実は銃器だった。」

ふむふむ。
けっこう的を射てる観察だと思う。

俺としては
「 C 言語は横暴な行動が許される発展途上文明の世界、
　Java は全ての犯罪が法によって抑止される"理想的な"法治世界
　(マイノリティ・リポートの世界)、
　C++ は法規は整っているがそれを守るか否かは各人に委ねられている自由世界」
だと思う。
(長くて申し訳ない)
現実の世界では、時に法を犯すことが最善の解に成り得る。

914 ：デフォルトの名無しさん：03/11/29 01:05

>>912
今まで手の届くような距離のものしか叩けなかったのに
飛び道具を手に入れたことで必要もないのに思わず
なんでも遠くにあるものを打って遊んでたり、
射撃に慣れてないことでなかなか的に当たらないといったところでしょうかね。

915 ：デフォルトの名無しさん：03/11/29 02:07

今日の名言。
C++で自分の脚を撃ち抜くのは大変だがやれば大変なことになる。

なるほど、Cなら所詮ナイフを突き刺す程度だ。

916 ：デフォルトの名無しさん：03/11/29 02:10

C++で自分の脚を撃ち抜くのは簡単だがやれば大変なことになる。

では？

917 ：デフォルトの名無しさん：03/11/29 02:26

>>916
もっと簡単なのはクマと間違えて人を撃つことだが

918 ：デフォルトの名無しさん：03/11/29 03:13

もっと難しいのは銀の弾を撃つことだが

919 ：デフォルトの名無しさん：03/11/29 03:52

この弾丸は、大聖堂の銀の十字架を溶かして作ったものだ。
The bullet was made by melting the silver cross from the cathedral.

920 ：デフォルトの名無しさん：03/11/29 04:23

銃を手にしたのに、実際に取れた獲物というか成果は少ないよね。
10年前に実際に市販されてるソフトと、今日のそれと、大差ないし。

921 ：920：03/11/29 04:27

この歳になって気が付いたけど、やっぱプログラマにとって重要なのは
使用している言語とか環境ではなく、コーディングに対する
モチベーションというか、完成形に対するビジョンをどれだけ
明確に持っているか？だと思う。

c++でお洒落なコーディングを楽しむのも、まぁ、若気の至りで
俺も楽しんでたけど、結局、生産しないし、しても、しょーもない
もの生産してたり。

銃を手に入れて、いたずらに遠くにあるものを無駄に
撃ってるという前の発言を見て、ちょっとビクっときたね。

922 ：デフォルトの名無しさん：03/11/29 04:30

銃を使いこなすにはそれなりの技量が必要なのです...。

923 ：デフォルトの名無しさん：03/11/29 04:38

漏れは手に入れた銃に短剣を取り付けて狩りをしようと思う。

924 ：デフォルトの名無しさん：03/11/29 04:41

10年前とは大違いだろ。10年前ってWindows3.1だよ？ちゃんとそれなりに進化してるよ。

925 ：デフォルトの名無しさん：03/11/29 06:12

>>920
昔のソフトは自動認識のたぐいが全滅に近かったな。
C++的に見ると=0とdynamic_castか。
今でもGUIDがないから結局QueryInterfaceみたいなハメになって
Cでへこへこ等価コード書いてるのと大差なくなってる。
色んなブツが相乗りできるキャパをハードが持ち始めたとき
C++ではサポートしきれなかったわけか。

926 ：デフォルトの名無しさん：03/11/29 15:22

>>10年前とは大違いだろ。10年前ってWindows3.1だよ？
>>ちゃんとそれなりに進化してるよ。
じゃ、10年前のWordだとかExcel製品群を見てみろよ。
驚くほど、今と大差ない。
うざいイルカだとかイヌだとかが進化か？

927 ：デフォルトの名無しさん：03/11/29 15:29

>>926
馬鹿馬鹿しい。

表計算ソフトや文書作成ソフトに、一体どのような進化を望んでんだ、お前は？

928 ：デフォルトの名無しさん：03/11/29 15:33

つーか見た目が今と大差ないとか言ってそう。一般ユーザーと変わらんな。

929 ：デフォルトの名無しさん：03/11/29 16:02

>>表計算ソフトや文書作成ソフトに、一体どのような進化を望んでんだ、お前は？
そうだな、WORDであれば、
リアルタイム自動スペルチェッカ、リアルタイム自動段落作成機能、
文書整形機能。カーソル位置にある単語を切り出して、文書内を
ハイライトで示してくれる機能などが「欲しかった」
あと、テンプレート文書機能だとかね。
異アプリ間の複合ドキュメントなんてのも欲しかった。
ワード中の絵をクリックしたら、その絵を編集するソフトが起動するだとか
表をクリックしたらエクセルが起動するなど。
あと、動的リンクか。エクセルで表を更新したら、その他のアプリで
参照されている表も全て自動更新されるだとか。

けど、これらの機能は全て、
Win3.1時代の一太郎やワードで既に実装されていた。

930 ：デフォルトの名無しさん：03/11/29 16:10

>>929
> けど、これらの機能は全て、
> Win3.1時代の一太郎やワードで既に実装されていた。
つまり君的には、進化しなくてはならないのに進化できないのではなく、
望むものはもう全てあるから進化しないだけってことなんだね。
表計算ソフトや文書作成ソフトについては。

じゃあ何の問題もないし、ソフトウェア全般の何かを語る例にならないじゃん。

931 ：デフォルトの名無しさん：03/11/29 16:36

>>929
お前相当馬鹿だな。

>この歳になって気が付いたけど

どの歳かわからんけど、一体今まで何してきたんだ？

932 ：デフォルトの名無しさん：03/11/29 16:39

というか、DOS の時代から C++ は使われてたわけですが。

933 ：デフォルトの名無しさん：03/11/29 16:50

>>932
DOSはVer7じゃねえだろなｗ

DOS用C++で古顔つーとMiwa, Zortechあたりか
あの頃、C++で開発されていたソフトって何だ？

934 ：デフォルトの名無しさん：03/11/29 16:59

Turbo C++は比較的メジャーだったような。
Microsoft C/C++は7.0からだっけ?

935 ：デフォルトの名無しさん：03/11/29 18:24

質問ですが、fmtflags って gcc3 だと ios_base::fmtflags で gcc2　だと ios::fmtflags 何ですか？
コンパイラーの version でコードを変更しなくてはいけないのでしょうか？
それとも何か回避策があるのでしょうか？

936 ：デフォルトの名無しさん：03/11/29 18:41

VisualStudio.NET 2003を使い、C#の勉強をしてます。
一通りできるようになってきたので、今度はWindowsAPIの勉強を始めようと思ったんだけど・・・

とりあえず、ペゾルド本の最初に載っているプログラムを打ち込んで、

#include <windows.h>

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
　　　　　　　　　　　　　　　PSTR szCmdLine, int iCmdShow)
{
　　　　MessageBox (NULL, TEXT("Hello, Windows98"), TEXT("HelloMsg"), 0);
　　　　return 0;
}

cl hello.cpp とやってみたんですが、
「window.obj : error LNK2019: 未解決の外部シンボル __imp__MessageBoxA@16 が
　関数 _WinMain@16 で参照されました。
　window.exe : fatal error LNK1120: 外部参照 1 が未解決です。」
と出てしまいます。
これって、何かコンパイルオプションをつける必要があるんでしょうか？

937 ：デフォルトの名無しさん：03/11/29 18:49

#include "stdafx.h"　　　　←入れたかな？
#include <windows.h>

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
MessageBox (NULL, TEXT("Hello, Windows98"), TEXT("HelloMsg"), 0);
return 0;
}

938 ：デフォルトの名無しさん：03/11/29 18:51

いや#include "stdafx.h"はいらないね。

939 ：デフォルトの名無しさん：03/11/29 19:31

>>936

#include <windows.h>
#pragma comment (lib, "user32")

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
　　MessageBox (NULL, TEXT("Hello, Windows98"), TEXT("HelloMsg"), 0);
　　return 0;
}

としてみたら？

940 ：デフォルトの名無しさん：03/11/29 19:34

>>936
多分、環境の問題。
VC6 なら vcvar32.bat を実行しとけばいいんだけど、.Net 2003 は知らん。

941 ：デフォルトの名無しさん：03/11/29 19:35

.NET 2003 は vcvars32 です。

942 ：デフォルトの名無しさん：03/11/29 19:35

C++のプログラミングって無料で出来るソフトってあるの？

943 ：デフォルトの名無しさん：03/11/29 19:36

>>942
>>8 の最後

944 ：940：03/11/29 19:38

あ、間違えた。
VC6 でも vcvars32.bat 。

945 ：デフォルトの名無しさん：03/11/29 21:40

>>940
ごくふつーにインスコすればスタートメニューに
[Visual Studio .NET 2003 コマンドプロンプト]
ってアイテムができてるよ

946 ：デフォルトの名無しさん：03/11/29 22:04

これがc++であるからこそ完成できた！っていう具体例を、
誰ひとり何ひとつ出せない・・・

でFA?

947 ：デフォルトの名無しさん：03/11/29 22:12

>>946 は馬鹿。

でFA?

948 ：デフォルトの名無しさん：03/11/29 22:15

946=947

おまえら二人とも（ｼﾞｻｸｼﾞｴﾝ？）、C++ならではの具体例を一つも
挙げられないから、馬鹿

でFA?

949 ：デフォルトの名無しさん：03/11/29 22:17

>>947
OK。

950 ：デフォルトの名無しさん：03/11/29 22:21

946～949でスレのレヴェルが一気に萎えたな

951 ：デフォルトの名無しさん：03/11/29 22:52

「レヴェルが萎える」
どこの方言だこれｗ

952 ：デフォルトの名無しさん：03/11/29 23:10

>>951
英語という方言です

おっとマジレスは気体じゃなかったか？
じゃあ固体でこたいよう(ﾌﾟ

953 ：デフォルトの名無しさん：03/11/29 23:12

>>952
w

954 ：デフォルトの名無しさん：03/11/29 23:31

>>952
萎えるは英語じゃないよ。馬鹿だね。

955 ：デフォルトの名無しさん：03/11/29 23:37

カナや漢字で表記してる限り日本語

956 ：デフォルトの名無しさん：03/11/29 23:42

いいからC++の話しろよ池沼どもが

957 ：デフォルトの名無しさん：03/11/29 23:57

>>954
ネタにマジレスしてるのｶｯｺﾜﾙｲ

958 ：954：03/11/30 00:00

Human* poor = new Human(954,"バカ");
while( true )
{
int err =poor->GetMyStick()->Shake( VERY_FAST );
if( err ) break;
}
delete poor;

959 ：デフォルトの名無しさん：03/11/30 01:08

>>957
マジレスしてるのはお前だけだと思うですわ

960 ：デフォルトの名無しさん：03/11/30 01:32

以下のソースをVC++6.0でコンパイルするとエラーになって
BC++5.5でコンパイルすると正常にコンパイルできるんですけど
言語仕様としては、どちらが正しいのでしょうか？

961 ：デフォルトの名無しさん：03/11/30 01:34

で、これがそのソース

#include <cstdio>
#include <cstring>
using namespace std ;
class Cparent
{
public :
　　classCchild
　　{
　　private :
　　　　structtag_child
　　　　{
　　　　　　char *name ;
　　　　　　int id ;
　　　　} ;
　　　　static struct tag_child ent ;
　　public :
　　　　char *getname(int i)　　　{　return ent.name ;　　　　}
　　　　int getid()　　　　{　　return ent.id ;　　}
　　} ;
　　Cchild child ;
} ;
Cparent::Cchild::tag_child Cparent::Cchild::ent={ "MANKO",100 } ;
int main( int ac , char **av )
{
　　Cparent p ;
　　printf("p.child.getname()=[%s]\n" , p.child.getname()) ;
　　printf("p.child.getid()=[%d]\n" , p.child.getid()) ;
　　return 0 ;
}

962 ：デフォルトの名無しさん：03/11/30 01:43

>>960-961
そのソースがコンパイルできるコンパイラがあるとはとても思えんのだが。
あと、どーゆーエラーが出たかくらいは書いた方がいいぞ。

> char *getname(int i)　　　{　return ent.name ;　　　　}
char *getname() { return ent.name; } か？

963 ：デフォルトの名無しさん：03/11/30 02:03

ごめんなさい
問題のある個所を絞り込む為に少し変更しました。
ご指摘の通り　getname( int i ) は getname() に読み替えてください

964 ：デフォルトの名無しさん：03/11/30 02:08

エラーは、こんなのがでてます。

nest.cpp(29) : error C2248: 'tag_child' : private struct
(ｸﾗｽ 'Cparent::Cchild' で宣言されている）にｱｸｾｽできません。
nest.cpp(11) : 'tag_child' の宣言を確認してください。

965 ：デフォルトの名無しさん：03/11/30 03:47

いまベクトルをあらわす構造体を
struct tag_vect
{
　int m_x;
　int m_y;
};

とします。これに定数を掛けれるように演算子をオーバーロードしました
const struct tag_vect & operator * (int i)
{
　m_x *= i;
　m_y *= i;
　return *this;
}

これだと
struct tag_vect v1, v2;
v1 = v2 * 10;
などとしたときにv2は10倍されてしまいます。
どうすればよいでしょうか？？

966 ：デフォルトの名無しさん：03/11/30 03:54

return tag_struct(m_x * i, m_y * i);
かな。
自分自身に掛けるんじゃなくて、新しいインスタンスを作って返す。

967 ：デフォルトの名無しさん：03/11/30 03:55

>>965
const tag_vect operator *(const tag_vect &val,int scale){
tag_vect tv;
tv.m_x=val.x*scale;
tv.m_y=val.y*scale;
return tv;
}

968 ：デフォルトの名無しさん：03/11/30 04:06

>>966-967
ありがとうございました。m(__)m

969 ：デフォルトの名無しさん：03/11/30 04:13

と思ったらだめでした。
>>966
新しいインスタンスを返すとローカルアドレスをリターンしているという警告がでますm(__)m
(warning C4172: ﾛｰｶﾙ変数またはﾃﾝﾎﾟﾗﾘのｱﾄﾞﾚｽを返します。)

>>967
引数が多いといわれてしまいました。m(__)m
（error C2804: binary 'operator *' に引数が多すぎます。）

970 ：デフォルトの名無しさん：03/11/30 04:16

>>969
コンパイラはなんなんだ？

971 ：デフォルトの名無しさん：03/11/30 04:18

VC++6.0です。

972 ：デフォルトの名無しさん：03/11/30 04:20

>>967を変更して
const tag_vect operator *(int scale){
tag_vect tv;
tv.m_x=this->x*scale;
tv.m_y=this->y*scale;
return tv;
}
とすると？

973 ：デフォルトの名無しさん：03/11/30 04:22

>>972
warning C4172: ﾛｰｶﾙ変数またはﾃﾝﾎﾟﾗﾘのｱﾄﾞﾚｽを返します。
となってしまいました。

974 ：デフォルトの名無しさん：03/11/30 04:30

ちなみに全ソースは
typedef struct tag_vect
{
　tag_vect()
　{
　　m_x = 0;
　　m_y = 0;
　};
　tag_vect(int x, int y)
　{
　　m_x = x;
　　m_y = y;
　};
　struct tag_vect & operator * (int i)
　{
　　struct tag_vect v;
　　v.m_x = this->m_x * i;
　　v.m_y = this->m_y * i;
　　return v;
　};
　int m_x;
　int m_y;
}VECTOR;
でMytestDlg.hファイルに記述してます。

975 ：デフォルトの名無しさん：03/11/30 04:35

struct tag_vect & operator * (int i)

だから & はずしてよ・・・

976 ：デフォルトの名無しさん：03/11/30 04:38

あ。。失礼しました。
＆をとったらうまくいきました。ありがとうございます。
でもなんでかわからない。奥が深いですね

977 ：デフォルトの名無しさん：03/11/30 04:41

>>976
参照の勉強をしてね・・・

978 ：デフォルトの名無しさん：03/11/30 07:35

次スレ
http://pc2.2ch.net/test/read.cgi/tech/1065535118/

979 ：デフォルトの名無しさん：03/11/30 08:38

Hashのインデックスを算出するのに、テーブルサイズ10万個に
対して500個くらいのインデックス（アドレス？）に収束してしまうことって
よくあるんでしょうか？ほとんどのハッシュキーがかち合って
しまっていて、ほかのスペースはほとんど無駄になっている
状態です。

980 ：デフォルトの名無しさん：03/11/30 08:46

>>979
質の悪いハッシュ関数を使えばそうなる。
プログラミング言語C++第3版に載っていた方法はなかなか質が良かったな。90%以上は使ってくれた。

981 ：デフォルトの名無しさん：03/11/30 08:52

ちなみにサンプル数はテーブルサイズの十倍

982 ：デフォルトの名無しさん：03/11/30 09:11

>>980
90%とは・・・。500/100kだと0.5% _|￣|○
サンプル数とは試したハッシュキーの数ですか？

自分の場合16バイトの文字列からかち合わない
組み合わせを探そうとしたんですが、組み合わせの
総数が28桁以上もある中から探そうというのがそもそも
アフォなんでせうか・・・

983 ：デフォルトの名無しさん：03/11/30 09:31

>>983
なんかハッシュについて勘違いしてる気がする。。。
「どんな入力達に対しても絶対バラける」ハッシュ関数なんてのは、
よほど入力パターンが少なくない限り不可能だ。16バイトの文字列なら
3.4*10^38通りも入力パターンがあるわけだから絶対無理だ。

「想定される一般的な入力」がバラけりゃそれでいい。例えば
　int hash(char* p) {
　　int h=0;
　　for(int i=0;i<=12;++i) h^= *(int*)(p+i)<<i;
　　return h % 100000;
　}
みたいな何も考えてない方式でも、大抵の場合0.5%なんてことにはならんはずだが。

入力される可能性のある文字列を全部並べ上げられるなら、
http://burtleburtle.net/bob/hash/perfect.html
Perfect Hashing なんてものある。

984 ：デフォルトの名無しさん：03/11/30 09:45

>>982
> サンプル数とは試したハッシュキーの数ですか？

そう。パス付きzip書庫のパスワードを解析するのに使う辞書を使った。

985 ：デフォルトの名無しさん：03/11/30 10:02

>>983
古いJavaの腐ったハッシュ実装の例がプログラミング作法にあったな。
あれなら0.5%も夢じゃない。

986 ：982：03/11/30 10:07

>>983
>「どんな入力達に対しても絶対バラける」ハッシュ関数なんてのは、
いえいえ、今回の場合は目的が逆なだけなんです。普通は文字列
からインデックスを探しますが、今回はインデックスに対応する文字列を
探そうとしたんです。もちろんかち合いがありますから文字列を総当たりで
試していって、それぞれのインデックスに最初に対応する文字列を
見つけていこうと。

合い言葉みたいな物を想定してやってるので寧ろかち合いを
期待しています。

>>984
あ、それいいですね。参考にさせてもらいます。φ(..)メモメモ

987 ：982：03/11/30 10:13

ただ今更ながら気がついたのですが
ハッシュ関数内で、BCDを使ってまともに30桁近くを
計算してたんで、これをお手本通りにdoubleなんかにして
もういちど試してみます

（昔作ったBCDクラスを使ってみたかったってのもありまつ（汁）

988 ：v(^・^)v：03/11/30 12:58

C++相談室 part26
http://pc2.2ch.net/test/read.cgi/tech/1070164402/l50

989 ：GETクラスメンバ：03/11/30 13:30

typeinfoクラスで、実行時にclassの名前を取り出せますが、
同じように、実行時にメンバの一覧を取得することはできないものでしょうか?

990 ：GETクラスメンバ：03/11/30 13:41

おっと、スレ閉じてましたね。
しかも、テンプレートスレに行った方がよさそうかな。

991 ：デフォルトの名無しさん：03/11/30 14:28

レスキュー991

992 ：デフォルトの名無しさん：03/11/30 14:32

日本の119番はレスキュー991を逆にしたものでありゅ