【初心者歓迎】C/C++室 Ver.72【環境依存OK】

【初心者歓迎】C/C++� ..

53:デフォルトの名無しさん
10/03/14 14:09:54
>>51
そう

hoge.cpp
int g_val;//実体はコレ
hoge.h
extern int g_val;

使う人
foo.cpp extern int g_valするかhoge.hをインクルード
hage.cpp 以下同様

54:48
10/03/14 14:19:47
>>53
そうと言われても、>>49なのか>>50か分からないんですけど...

・1つの*.hを2つの*.cppで共有している
・しかし2つも*.hに変数を2つ書くのが(考えるのが)面倒い
・それじゃ、*.hに1つだけ変数を宣言して、あたかも2つ宣言したようしよう
ってのがexternですね

55:デフォルトの名無しさん
10/03/14 14:26:46
とりあえず宣言と定義の違い、翻訳単位やリンケージについて調べてください

56:デフォルトの名無しさん
10/03/14 20:27:08
URLﾘﾝｸ(wisdom.sakura.ne.jp)
の一番下のmain関数
Neko obj(::obj);
の ::obj は何を指すんですか？

57:デフォルトの名無しさん
10/03/14 20:29:45
グローバル変数のobj。クラスの宣言と同時に定義してるやつ

58:デフォルトの名無しさん
10/03/14 20:53:19
>>57
ありがとうございます

59:デフォルトの名無しさん
10/03/14 20:59:28
friendって使い道あるの？
ネストクラスとかstaticメンバ関数つかえばよくね？

60:デフォルトの名無しさん
10/03/14 21:01:41
>>59
テンプレートが絡んでくるとそう簡単じゃないんだよ。
Effective C++ぐらい嫁。

61:デフォルトの名無しさん
10/03/14 23:32:10
iostreamやstdioなどの標準的なライブラリは
/usr/includeの下にヘッダファイルが保存されています

標準的なライブラリの実態はどこにあるのですか
OS or コンパイラ?

62:デフォルトの名無しさん
10/03/14 23:33:33
大抵ファイルシステム上のどこかです

63:デフォルトの名無しさん
10/03/15 00:00:06
>>61
ものによる。
/usr/include ってことはUNIX系だろうから、たいていOS付属で
/usr/lib など。

64:61
10/03/15 00:11:33
>>63
普通に考えてみれば、/usr/lib/以下にありますよね
/usr/libはソフトの実体が入っているな～程度の事しか思っていませんでした
/usr/libの中のデータは*.soが多いわけですし

わかりました、ありがとうございます

65:デフォルトの名無しさん
10/03/15 02:10:20
>>61,64
もしかして、実体ってライブラリのことじゃなくてソースのことだった
りする?

それももちろん環境依存だけども。

66:デフォルトの名無しさん
10/03/15 12:09:33
Windowsでの話なのですが、

std::locale loc = std::locale();
loc = std::locale(loc, "japanese", std::locale::ctype);
std::locale::global(loc);

といった記述をDLLの冒頭に書いた場合、それを読み込むソフトや他のDLLにも影響は及ぶのでしょうか？

67:デフォルトの名無しさん
10/03/15 13:12:48
hoge.h
extern void hoge();
hoge.c
void hoge(){内容}

なんで、hoge.cには#include "hoge.h"と書かなくてもシンタックスエラーにならないんですか？
C++でクラスを定義する時は、#include "hoge.h"と書かないとシンタックスエラーになるのに

68:デフォルトの名無しさん
10/03/15 13:16:19
＞C++でクラスを定義する時は、#include "hoge.h"と書かないとシンタックスエラーになるのに
ならねーよ

69:デフォルトの名無しさん
10/03/15 13:21:41
>>67
何にも理解してねぇんだな。
#includeがおまじないの類だと思っている節が。

だれかおせーてやれ

70:デフォルトの名無しさん
10/03/15 13:28:23
>>66
個々のランタイムで管理しているので同じランタイムにリンクされているモジュール間で影響を受ける
VC++2005で動的リンクで作ったなら同じプロセスに読み込まれてるVC++2005で動的リンクしているDLLが影響を受ける
VC++6や2008で作ったものや2005でも静的リンクしたものは別のランタイムに属するので影響されない

71:デフォルトの名無しさん
10/03/15 13:28:54
// 関数hogeの宣言
extern void hoge();
// 関数hogeの定義
void hoge(){内容}
// 関数hogeの参照
hoge();

// クラスFooの定義
class Foo {
Foo() {}
static FOO() {}
};
// クラスFooの参照、インスタンスfooの定義
Foo foo;
// クラスFooの参照
Foo::FOO();
// インスタンスfooの参照
func(foo);

72:67
10/03/15 13:33:57
>>71
thx

でもさ、C++の時は#include "hoge.h"って書かないと
コンパイラ様が怒ってくるんだよ

73:69
10/03/15 13:42:44
>>72
それは
> C++の時は
というか、単に "hoge.h" にクラスFooの定義を書いているってだけじゃないのか？

#include "hoge.h"
の #include ってのは、"hoge.h" をその場所に取り込め（コピペ的に機械的に取り込め）
って意味だから、これがないと
"hoge.h" にクラスFooの定義を書いている場合は
クラスFooの定義が見つからないとコンパイルエラーになるだろうけど。

でも#include "hoge.h"をしなくてもソースファイルにもう一度クラスFooの定義を
書けば別に#include "hoge.h"しなくてもエラーにはならない。

意味分かってくれる？

74:69
10/03/15 13:58:57
>"hoge.h" にクラスFooの定義を書いている場合は
>クラスFooの定義が見つからないとコンパイルエラーになるだろうけど。
クラスの定義はどうやって見つけるんですか？
知りたいことは、そこなんです

75:デフォルトの名無しさん
10/03/15 15:32:51
// hoge.c

class Hoge {
};

Hoge hoge;

76:デフォルトの名無しさん
10/03/15 18:35:13
よくライブラリで構造体を
struct tagHOGE{}HOGE;
みたいにtagなんちゃらにするのは何でですか

77:デフォルトの名無しさん
10/03/15 18:44:00
>>76
慣習です。
C/C++ではstruct tagHoge {...} hage;としたときにhageの型はstruct tagHogeになります。
C++ではtagHogeのようにstructを省略できますが、Cでは省略できません。
その為、しばしばCではtypedef struct tagHoge {...} Hoge;のようにtypedefすることになります。
このとき、typedef struct Hoge {...} Hoge;とするとC++ではエラーになります。

78:デフォルトの名無しさん
10/03/15 19:09:36
了解しました

79:デフォルトの名無しさん
10/03/15 19:28:15
同じにしてもC/C++共にエラーにならない
まあそういうコンパイラもあるのかもしれないけど

80:デフォルトの名無しさん
10/03/15 19:32:54
＞typedef struct Hoge {...} Hoge;とするとC++ではエラーになります。
ならんならん
JIS X3014 附随書C 7.1.3 にも全く同じ例が載ってる

81:デフォルトの名無しさん
10/03/15 20:28:50
class Hoge{
private:
int Num;
double huga[Num];
public:

Hoge(int Num);

};

Hoge::Hoge(int Num){

this->Num = Num;
}

82:デフォルトの名無しさん
10/03/15 20:33:34
中途半端だった・・・
こういった風にhugaのサイズを宣言したいのですが、これではコンパイルができません。どういう風にかいたらいいでしょうか？

83:デフォルトの名無しさん
10/03/15 20:35:46
>>81
std::vector を使う

84:デフォルトの名無しさん
10/03/15 20:51:36
class aaa
{
static const int bbb = 100; double ccc[bbb];
};

85:デフォルトの名無しさん
10/03/15 20:54:46
struct ar{double*const p;ar(size_t a):p(new double[a]){};~ar(){delete[] p;}double&operator[](size_t a){return *(p+a);}}*huge;
// を new deleteでつかう。

86:66
10/03/16 09:18:35
>>70
詳しく説明していただき、大変参考になりました。
ありがとうございました。

87:デフォルトの名無しさん
10/03/16 09:50:03
>>85
コピーコンストラクタと代入演算子は書こうぜ

88:デフォルトの名無しさん
10/03/16 10:06:23
>>76
URLﾘﾝｸ(blogs.msdn.com)
これだな。

標準化前のCではタグ名の名前空間が分かれていなかったことが原因で、
それを受けた Windows プログラミングによってさらに広まったものだろう。

tag ならまだしも下線で始める奴が多くて困る。
URLﾘﾝｸ(www.kijineko.co.jp)

89:デフォルトの名無しさん
10/03/16 10:10:47
>>80
実はまだ active issue になってたりする。
URLﾘﾝｸ(www.open-std.org)

90:デフォルトの名無しさん
10/03/17 01:33:03
JIS版C++ではOKだがISO版C++ではNG…ということか？

91:デフォルトの名無しさん
10/03/17 02:06:50
>>90
んなこたーない。ISOもJISも内容は基本的に同じ。

元々の規格の意図としては同じ名前も使えるようにしたかったようだけど、
厳密に解釈していくとなにやら矛盾のある状態になっているようだという話。

92:デフォルトの名無しさん
10/03/17 11:36:16
VistaにVC2003をインストールしたんですが、ダイアログデザイン
編集時にプロパティウィンドの中身が一切表示されません。
サポート対象外なのはわかっていますが、解決策があれば
教えてもらえないでしょうか

93:デフォルトの名無しさん
10/03/17 18:31:40
class abc
{
abc(int);
･･･
}
---

list<abc> a1;
for (int i=0;i<10;i++){
a1.push_back( new abc(i));
}

こんな感じで作ったa1を削除する時って、
a1の要素のabcのメモリ解放は、
ループさせて、いちいち要素ごとにメモリ解放をしていかないとダメですか？
それとも、
a1.clear();で、全部やってくれるモンなのですか？

94:デフォルトの名無しさん
10/03/17 19:10:06
自分でやんないとだめ

95:デフォルトの名無しさん
10/03/17 20:44:35
>>92
好きなのを選べ
1. WindowsXPをインストールする。
2. VisualStudio2008ExpressEditionをインストールする。

96:デフォルトの名無しさん
10/03/17 22:13:41
あるクラスAがあります。

このクラスをクラスBがコンポジションします。
クラスAのprotectedメンバー変数にクラスBからアクセスしたいのですが、継承した場合と違ってアクセスできません。
どのようにアクセスすべきでしょうか？
A内にpublicな関数をつくり、その関数がprotectedメンバーの値を返すようにすればいいのでしょうか？

97:デフォルトの名無しさん
10/03/17 22:29:59
お好きにどうぞ。

98:デフォルトの名無しさん
10/03/17 22:46:37
どうするのが一般的なんでしょうか？

アクセスしたい変数は2個あって、そのために関数を2個用意するのはバカらしい感じがします。

99:デフォルトの名無しさん
10/03/17 22:49:21
friend

100:デフォルトの名無しさん
10/03/17 22:55:41
>>98
二個用意するのが馬鹿らしいなら設計を見直しましょう。

101:デフォルトの名無しさん
10/03/17 23:21:25
アクセス制御精査を心がけてるよと見せるのが主目的なら
抽出用一時オブジェクトとメンバ関数へのfriend指定を駆使して記述すれ

102:デフォルトの名無しさん
10/03/17 23:34:18
>>96
共通のメンバーを抜き出したクラスをクラスA,Bから参照すればいい。

103:デフォルトの名無しさん
10/03/17 23:42:07
＞98
このスレッドに書き込む労力を
アクセッサの実装に使ってください

104:デフォルトの名無しさん
10/03/17 23:49:32
>>98
getter setterは邪悪

105:デフォルトの名無しさん
10/03/18 00:01:52
>>93
それ、
　　a1.push_back(abc(i));
でよくない？
どうしてもnewしなきゃならないなら、shared_ptrを使うといい。

106:デフォルトの名無しさん
10/03/18 23:50:38
>>96
Bに包含されることを前提にAを設計しているなら単にfriend指定すればいい。
そうでなければアクセサを書くか、メンバ変数自体をpublicにすればいい。

107:デフォルトの名無しさん
10/03/19 08:50:01
>>105
用途によっては shared_ptr をコンテナに突っ込むより ptr_vector の方がいいかもね。

108:92
10/03/19 13:29:45
やはりそうなりますかー。
ネットで調べてもそういう現象が見つからないし、
自分の環境固有の問題なのかなぁ

ちなみに最近ではMFCが使われて無いみたいなこと聞きますが
そうなるとウィンド周りは何で作るのが主流なんでしょう？
SDK？ CLI？

109:デフォルトの名無しさん
10/03/19 16:45:15
operator boolをそのまま実装すると色々とよろしくないようでsafeboolなるテクニックがあるようですが
ググっても何をやってるのかさっぱりわかりません

どういう原理でsafeになるのでしょうか？

110:デフォルトの名無しさん
10/03/19 17:09:07
Linuxでgccを使っています。
プログラム自身が使用しているメモリ量と、システムのフリーメモリ量を取得する方法を教えてください

111:デフォルトの名無しさん
10/03/19 17:33:51
>>110
OS板、OSスレでどうぞ。

112:デフォルトの名無しさん
10/03/19 19:40:36
>>109
more c++ イディオム　safe bool でググるんだ。

普通にはアクセスできないポインタ型を変換演算子で返せば、ifで評価できるし、あれこれ暗黙な変換がされなくて済む。

113:デフォルトの名無しさん
10/03/19 19:42:30
int a=p+1;こんなのがsafeじゃない意図されない使い方

114:デフォルトの名無しさん
10/03/19 19:48:46
C++0xのexplicit conversion operatorsがあればsafe bool idiomはいらない子ですか？

115:デフォルトの名無しさん
10/03/19 19:56:24
そうだね。
でも、コンパイラの実装を待つことなく工夫してsafe boolを手に入れられる拡張性がC++のいいところだよね。

116:デフォルトの名無しさん
10/03/19 20:55:43
C++のコードをDLLにするのってめんどいな
例外出しちゃいけないからわざわざ例外捉えるだけのラッパー書かないといけないし
引数と返り値にSTL使えないし

117:デフォルトの名無しさん
10/03/19 22:58:13
それを突き詰めていくとな、いつのまにか劣化COMを作っている事に気づくのさ

118:デフォルトの名無しさん
10/03/19 23:02:59
>>116
多分、結局インタフェースコードはCかCOMにすることになると思うよ
労力ばかり無駄にかかる上に、CのDLLやCOMより相互運用性において劣る

119:デフォルトの名無しさん
10/03/19 23:06:13
WindowsならCOMでいいけど
MacやLinuxはどうすんの？

120:デフォルトの名無しさん
10/03/19 23:07:22
>>112-115
ぐぐってみてこのページを見たのですが
URLﾘﾝｸ(ja.wikibooks.org)(Safe_bool)

operator bool()ではなくoperator bool_type() constでもよいのでしょうか？

で、operator bool_type() constの挙動は
ok_がtrueであればthis_type_does_not_support_comparisons()のアドレスを返し、0以外の値なのでtrueと動作する
falseならば0をかえしfalseとなる

例文の
if (t2 == t1)や
if (t1 < 0)
のばあいはprivate関数のアドレスを比較するのでコンパイルエラーをはく
ということでしょうか

この場合なぜメンバ関数のアドレスを返り値とするのでしょうか？

質問続きで申し訳ありませんがよろしくお願いします

121:デフォルトの名無しさん
10/03/19 23:10:44
Cでいいんじゃないの
必要に応じてヘッダのみ、またはスタティックリンクのラッパーを書いて提供

つまり
ユーザーコード - C++ラッパー - DLL境界 - Cインタフェース - C++実装
こうなる
面倒すぎて反吐が出るね

122:デフォルトの名無しさん
10/03/19 23:14:39
CORBA(笑)

123:デフォルトの名無しさん
10/03/19 23:18:10
>>120
普通のポインタだったらいろいろできて副作用があるから。

124:デフォルトの名無しさん
10/03/19 23:40:28
>>120
キャストでいじってみるとわかるけどpointer to memberはキャストの制限がきつい
だからかってに暗黙変換されてコンパイルとおって変な動作したりとかがなくなって安全なわけ

125:デフォルトの名無しさん
10/03/20 13:56:08
質問です。
速度で考えると、floatとdoubleではどちらを使った方がいいのでしょうか。
最近のPCで動かす場合を考えているのですが、最近はfloatよりdoubleの方が早い、みたいな話を聞いたのですが・・・。

126:デフォルトの名無しさん
10/03/20 14:09:45
32bitCPUならfloatもdoubleもそんなに差がないだろ
x86に限定して言うならどちらもFPUにロードした時点で80bitになる
SSE使ってたらfloatの方が速いって事もあるけどな

127:デフォルトの名無しさん
10/03/20 14:15:09
>>126
64bitだと差が出ると言うことでしょうか？
そして32bitなら、精度が高い分doubleのほうがよい、という事で合っていますか？

128:デフォルトの名無しさん
10/03/20 14:22:25
>>127
ああごめん
今昼間から酒飲んでるから答え半分に聞いてくれ
32bitCPUだとdoubleのロードにメモリアクセス2回必要だわな
64bitCPUだとそんなに差がないってのが正解か

でも実測してみると分かるけどfloatでもdoubleでもそんなに差がないよ
結局FPUの演算に掛かる時間が食われてロードの時間なんて問題に
ならないんだろうな

129:デフォルトの名無しさん
10/03/20 17:12:20
>>125
あなたが究極の性能を目指しているのでもない限り、doubleを使うべきです。

理由は幾つかあります。先ずはメリットを。
・floatの方が演算処理が速い場合もある。特に、ベクタ化できる場合に2倍速くなるかもしれない。
・floatの大きな配列の方が同じ要素数のdoubleの配列よりもキャッシュヒットが期待できる。そもそもメモリ容量的にdoubleではダメかもしれない。
・三角関数などの標準関数はsin()とsinf()のようにfloat版が用意されていればそれを利用できる。

次にデメリットを。
・一部の標準関数にはfloat版が用意されていない。また、sprintf()のようにfloatを渡すことができない場合もある。
・floatとdoubleの変換は一般的にかなり遅い。
・1.5のように書いてしまうとその定数はdoubleになってしまうので、1.5fのようにfloat定数であることを明示する必要がある。
・以上のように、暗黙のdoubleへの格上げを禁止するにはアセンブリ出力を確認するような神経質な手続きが必要になる。
・そもそも実数演算以外のコストが高くてfloatのメリットが殆どないかもしれない。

尚、doubleの方が速いのはCでは20年来の話。「最近はdoubleの方が速い」なんてことはないのでその話をした人は何か勘違いをしている。

130:デフォルトの名無しさん
10/03/20 17:15:13
お前は少しでも速いからと言ってshortを多用する気になるか?
余程のことがない限り深く考えずにintを使うだろ?
floatとdoubleの関係はshortとintの関係と一緒だ。
深く考えたくなかったら黙ってdoubleを使っとけ。

簡単に纏めるとこれでいいだろw

131:デフォルトの名無しさん
10/03/20 17:18:59
>>129
メリットとデメリットの説明が逆のような気がする…。

132:デフォルトの名無しさん
10/03/20 17:22:36
>>131
いや、2行目に空白があるだろ？そこの行間を読んでみると、
彼はfloatにした場合の説明をしているんだろう。

133:デフォルトの名無しさん
10/03/20 17:28:24
>>125
とりあえず自分のマシンで実測してみれば？

134:デフォルトの名無しさん
10/03/20 17:29:16
>>133
そして/fp:fastを付けずにfloatが遅いと言い出すわけだ

135:デフォルトの名無しさん
10/03/20 17:32:47
>>132
そ、そんなところに空白が…！！！

136:デフォルトの名無しさん
10/03/20 18:26:02
GPUに仕事ぶん投げて非同期にやらせればいいじゃない

137:129
10/03/20 19:51:23
おっと、途中で構成を変えたのが裏目に出たようで。失敬。

>>136
正直、今の4coreCPUならGPUにぶん投げられるような仕事はかなり特殊と言わざるを得ません。
実装の手間を考えると、IntelCompilerで最適化する辺りが無難ですね。
いずれにしても、普通のプログラマが意識するような領域では普通にdoubleを使ってgccなりVCなりで
コンパイルするだけで充分です。

138:デフォルトの名無しさん
10/03/21 05:29:48
typedef struct tHOGE
{
int x ;
TCHAR[256] str;
}HOGE;

std:vector<HOGE> vHoge ;

見たいな感じのものをstd:sortを使ってx又はstrで
並びかえる事は出来ますか？

139:デフォルトの名無しさん
10/03/21 05:34:13
>>138
すみません
TCHAR str[256] ;です＞＜

140:デフォルトの名無しさん
10/03/21 06:51:01
>>138
比較関数を自分で書けばソートできる

141:デフォルトの名無しさん
10/03/21 09:42:10
>>138
簡単
std::sortの第三引数に叙述関数の名前を書くか、関数オブジェクトの
名前を書いて、叙述関数または関数オブジェクトを書けばソート可能

142:デフォルトの名無しさん
10/03/21 10:01:12
>>138

URLﾘﾝｸ(ideone.com)

こんな感じな

143:デフォルトの名無しさん
10/03/21 10:51:46
>>140-142
出来ましたありがとうございます
ソースわかりやすかったです

144:デフォルトの名無しさん
10/03/21 10:58:23
deprecated conversion from string constant to ‘char*’

の意味をぐぐってみたが、C++0xで廃止予定との事なので
現行標準C++では関係ない

145:デフォルトの名無しさん
10/03/21 12:26:39
>>144
というか
C++0xで廃止予定
だから
deprecated conversion
なんじゃねぇの？

146:デフォルトの名無しさん
10/03/21 12:28:17
（=ﾟωﾟ)？

147:デフォルトの名無しさん
10/03/21 12:32:22
>>146
いやだから廃止予定だから　deprecatedなんじゃね？と

148:デフォルトの名無しさん
10/03/21 12:46:23
C++0xで廃止されるかどうかは関係なく
現行のC++03でdeprecatedだから素直にconst付けろ

149:デフォルトの名無しさん
10/03/21 13:59:07
C++でatollっぽいこと（文字列→long long int）がやりたいんだけどどうやればいいの？

150:デフォルトの名無しさん
10/03/21 14:00:55
lexical_castとかstringstreamとか

151:デフォルトの名無しさん
10/03/21 14:11:20
atoll使えばいいじゃん

152:デフォルトの名無しさん
10/03/21 14:28:31
class Hoge {...}; があるとして
Hoge hoge; を禁止して
void func(Hoge hoge); func(Hoge(...)); を許可したい
つまりテンポラリなオブジェクトとしてfuncの引数に渡す時のみ生成を許可したい
こういうことは可能でしょうか？

153:デフォルトの名無しさん
10/03/21 14:31:02
>>152
Hoge のコンストラクタを private にして func を friend にして、
Hoge は func の中で生成する。

154:デフォルトの名無しさん
10/03/21 14:55:28
operator void*とoperator boolが同一の動作をするというのがよく判らない
これはどういうことでしょうか

155:デフォルトの名無しさん
10/03/21 15:00:34
>>154
if や条件演算子の条件式として使う分には同じ結果が得られる、ということ。
void* なら意図しない暗黙変換による間違いをいくらか防げる。しかし完全ではない。

156:デフォルトの名無しさん
10/03/21 15:06:07
レリーズｗｗｗｗｗってかｗｗｗうほっ

157:デフォルトの名無しさん
10/03/21 15:06:16
誤爆

158:デフォルトの名無しさん
10/03/22 16:50:36
簡単な二次元テーブルクラスを作ってみようと思ってやってみたんですが
width*heightの大きさの配列を一回で確保して、data[width*y+x]でアクセスというやり方が一般的で良いと聞いたんですが
width*heightが大きくなるとメモリを確保出来なくなってしまいませんか？
WORD最大*WORD最大ぐらいまでしか確保してくれません
こんな中途半端なやり方がほんとに一般的に見て良いものなんでしょうか？

159:デフォルトの名無しさん
10/03/22 16:53:58
>>158
無茶な釣りは結構です。

160:デフォルトの名無しさん
10/03/22 17:05:49
>>158
メモリが何メガバイト必要か計算してみよう。

161:デフォルトの名無しさん
10/03/23 00:34:26
URLﾘﾝｸ(codepad.org)

こういうのってありですか？
つうかもっと簡単にクライアントに引数の並べ替えを提供するテクってありますか？

162:デフォルトの名無しさん
10/03/23 02:15:39
>>158
> width*heightが大きくなるとメモリを確保出来なくなってしまいませんか？
当然なるでしょう

data[width*y+x] の結果に法則性は無いのか、全くのバラバラならば仕方ないけど、
たとえば、100,500 の結果から 500,100 の結果は通常計算より簡単に導き出せないか。
または、ある要素番号の結果の符号を反転すれば他の要素の結果にならないか。
そんなふうにして配列数は半分に減らせないか色々考える。
多少妥協してテーブルを正規化していくしかない。

163:デフォルトの名無しさん
10/03/23 08:38:33
>>161
Boost Parameter

164:デフォルトの名無しさん
10/03/23 12:33:53
マクロは使いたくないです

165:デフォルトの名無しさん
10/03/23 14:13:37
マクロ使いたくない？ならC使うな

166:デフォルトの名無しさん
10/03/23 14:29:24
こんなんどうよ
template <typename LHS,typename RHS,typename RET> RET argswap2(RET (*p)(LHS,RHS),LHS a,RHS b){return p(b,a);}
int sub(int a,int b){return a-b;}

cout << sub(10,2) << endl;
cout << argswap2(sub,10,2) << endl;

167:デフォルトの名無しさん
10/03/23 22:52:07
>>161
並べ替えを許可する引数の型が全部違えばできないこともない
URLﾘﾝｸ(codepad.org)
引数が多いときは大変だがTypeList使うかenable_ifを駆使すればどうにかなる。

168:デフォルトの名無しさん
10/03/23 23:24:45
その引数の並べ替えって意味あるの？

169:デフォルトの名無しさん
10/03/24 23:16:15
組み込み型のデストラクタを明示的に呼び出すことになっても問題ないのでしょうか？

170:デフォルトの名無しさん
10/03/24 23:30:51
問題無いはず。
STLのコンテナの内部で普通に行われてる。

171:デフォルトの名無しさん
10/03/24 23:31:14
>>169
どういうソースコードを組めばそうなるってこと？

172:デフォルトの名無しさん
10/03/24 23:32:57
>>169
placement newに対応するデストラクタ呼び出しなら必要だけど？
それ以外？

173:デフォルトの名無しさん
10/03/24 23:44:31
>>167
どうもです
面白いですね
templateだけで汎用化できるならそれに越したことはないんですが完全には難しいですね

>>168
fromとtoどっちが先だっけ・・・というときに明示できると助かったり（この例だけだと微妙だけど数が増えると結構便利）
あとは複数個デフォルト引数の指定があるけどひとつだけ自分で決めたいといったときに使えるかな、と
void func(A a1 = A(1), A a2 = A(2)); // a2だけ指定したいけど出来ない
void func(A1Is a1, A a2 = A(2))
{
func(a1.value, a2);
}
void func(A2Is a2, A a1 = A(1))
{
func(a1, a2.value);
}
func(A2Is(a)); // a2だけ指定できる
といった感じで組み合わせを全部スクリプトに吐かせて使う感じ
例えばWindowを生成する関数でcreate_window(TitleIs("test"), WidthIs(w), HeightIs(h));と言った感じで一部だけ決めて残りはデフォルトを使うとか考えられる

174:デフォルトの名無しさん
10/03/25 00:21:25
>>173
こんなのとか
URLﾘﾝｸ(codepad.org)

175:デフォルトの名無しさん
10/03/25 12:41:28
とあるクラスの操作で
以下のように

T* hoge = new T;
hoge->~T;
*hoge = new(hoge) T;
hoge->~T;

delete hoge;

初回のみnewで確保してその後はplacement newを利用して初回確保した領域にオブジェクトを生成し
最終的にデストラクタで領域を開放する、と言う操作を行って大丈夫なのでしょうか？

176:デフォルトの名無しさん
10/03/25 12:54:20
>>175
大丈夫かもしれないし、大丈夫じゃないかもしれない。

本当にそんなことをする必要があるのかよく確認して、その必要性を示す
コメントが添えられていれば、やってもいいかもしれない。

177:デフォルトの名無しさん
10/03/25 12:57:28
>>175
デストラクタを２回連続で呼んでる

178:デフォルトの名無しさん
10/03/25 13:10:15
クラスAを生成するファクトリがあって、

A *FactoryA::create(ArgX, ArgY, ArgZ, ...)
{
new A(ArgX, ArgY, ArgZ, ...);
}

このような形で引数をそのままnewにデリゲートしています
Aが固定ならコンストラクタの数だけオーバーロードを力任せに追加すればいいのですが、
Factory<A>のようにテンプレート引数の場合になると力任せではできません
この手の問題を回避する方法はありますか？

179:デフォルトの名無しさん
10/03/25 13:17:03
>>177
deleteのときにhogeにｵﾌﾞｼﾞｪｸﾄが存在するときのみデストラクタが呼ばれるよう工夫することは出来ないでしょうか

やはり素直に1回の処理ごとにnewとdeleteを繰り返した方が良さそうですね、ありがとう御座いました

180:デフォルトの名無しさん
10/03/25 13:34:25
void *v = ::operator new (sizeof(Hoge));

T *p = new (v) T;
p->~T();
operator delete (p, v);

p = new (p) T;
p->~T();
operator delete (p, v);

::operator delete (v);

それにしてもなんで
delete (v) p;
って書けないんだろうな
placement new/delete関係は仕様がなんか気持ち悪い

181:デフォルトの名無しさん
10/03/25 13:36:02
>>179
君が欲しいのは boost::optional かもしれない。

182:デフォルトの名無しさん
10/03/25 17:57:19
>>175
newはそんなに遅くない。

vectorがそれやってるから。

vector<T> hoge(1);//placement newされる。
hoge.resize(0); //デストラクタが呼ばれる。
hoge.resize(1);//placement newされる。
//スコープから出れば勝手にデストラクタが呼ばれる。

183:デフォルトの名無しさん
10/03/25 18:15:41
非POD型に
T *p = new (v) T;
って不味いんじゃなかった？配置構文なんてあまり使わんから勘違いだったらすまん

184:デフォルトの名無しさん
10/03/25 18:25:03
PODじゃなくても問題ないよ

185:デフォルトの名無しさん
10/03/25 18:27:38
実際placement newと普通のnewってどのくらい速度ちがうん？
誰か理論値知らない？

186:デフォルトの名無しさん
10/03/25 18:44:42
単純に考えて(placement new/deleteの回数*生メモリ確保/開放にかかる時間)の分だけ速くなる
生成破棄しまくる場合はスゲー速くなるけど、そうでない場合はほぼ無意味

187:デフォルトの名無しさん
10/03/25 18:49:22
逆に言えば生成破棄しまくるなら早くなるんだよね？
うし、ちょっと実測してくる。ありがとう。

188:デフォルトの名無しさん
10/03/25 18:49:40
>>184
あれ、どういうとき不味いんだっけ・・・

189:デフォルトの名無しさん
10/03/26 19:15:46
>>188
アライメントの問題ぐらいじゃね？

190:デフォルトの名無しさん
10/03/26 20:10:02
もしまずい点があるとしたら
配列をoperator new()と配置newを使って確保したものに対して
delete[]を使えない、とかそういう点。

191:デフォルトの名無しさん
10/03/26 20:13:46
>>190
それはnewの時も事情は同じだよね

192:デフォルトの名無しさん
10/03/26 20:28:29
C++0xのunionで非POD形が使えるようになるのはplacement newを使うためなのかな？
今まではboost::variantのようなことをするには配列で領域取ってたけどunionでアライメントの問題も無く簡単に使える様になるのか？

193:デフォルトの名無しさん
10/03/26 20:37:45
D&E第三版がC++0xが出た後で出版されるよな

194:デフォルトの名無しさん
10/03/26 20:50:24
>>191
「new演算子」は、operator new()で領域を確保し
コンストラクタを呼び出して初期化することが決まってるんじゃなかったかな。
規格読んでないから知らんけど。

もしそうなら、その方法で確保したオブジェクトをdeleteで解放することも許されそうだが。
規格読んでないから知らんけど。

また、少なくとも
p = new T();
p->~T();
new (p) T();
したものに対しては
delete p;
は大丈夫なんじゃなかったかな。
規格(ry

195:デフォルトの名無しさん
10/03/26 20:54:41
>>194
いや俺が言ってるのは「配列new」も存在しないね、という事

196:デフォルトの名無しさん
10/03/26 20:55:40
言い方がまずいな

new A[]; とかは出来るけど、呼び出せるのはデフォルトコンストラクタのみ
引数付きコンストラクタは呼び出せない

197:デフォルトの名無しさん
10/03/26 22:00:43
operator new/deleteのオーバーロードとかplacement new/deleteはたまに使うけどそれの配列版は一度も使った事ない俺ザンギュラ
というかコンパイラで挙動が違うし、ググッても仕様が良く解らんしで諦めた

198:デフォルトの名無しさん
10/03/26 22:54:00
アロケータの自作は理解が深くないと大変なことになるから怖いよね

199:デフォルトの名無しさん
10/03/26 22:56:32
VCだと要素数を格納する分だけ余分に確保して、
その次のアドレスを返すんだっけ

200:デフォルトの名無しさん
10/03/26 22:57:02
アロケータの自作なんて本当に必要かどうか
さんざん吟味して原則的に及び腰になるべし。

201:デフォルトの名無しさん
10/03/26 23:07:45
Scoped Allocatorなら組み込みでも使えそうな予感

202:デフォルトの名無しさん
10/03/27 02:28:15
>>199
gccもそんなだったはず
あとPODのときは要素数領域を確保しないとかあった気がする

203:デフォルトの名無しさん
10/03/27 06:41:37
PODじゃないけどデストラクタがない場合ってどうなんだろ？
確かめた事無いや

204:デフォルトの名無しさん
10/03/27 06:51:18
placement newのデストラクタがない場合？クラスが動的に領域を確保する
物じゃなければデストラクタを意図的に呼び出さなくても実害はなかったと思う
推奨されないけど

205:デフォルトの名無しさん
10/03/27 06:55:36
こんな感じか

class A {
int i;
};

class B {
int* p;
public:
B() : p(new int[100]) {}
~B() { delete[] p; }
};

int main()
{
char c[1000];

A* ap = new (c) A;
// ap->~A(); // 無くても実害はない

B* bp = new (c) B;
bp->~B(); // ないとメモリリークする
}

206:デフォルトの名無しさん
10/03/27 07:29:32
いや、そういう話じゃなくて、
配列newで要素数を格納するのはデストラクタ呼ぶループのためだから
（new側は要素数が分かるので特に必要はないはず）
デストラクタがなければPODじゃなくても配列newで要素数分確保する必然性はないよね、と
まあ確保しても実害は無いから自分で配列newを実装する場合は無条件で確保すればいいんだけど
デフォルトではどうなってんのかな、と

207:デフォルトの名無しさん
10/03/27 08:25:35
>>206
じゃあこういう事か
ちなみにCodeGuard掛けてみたが何のエラーも出なかったので恐らく
問題ないと思われる

class A {
int i;
};

int main()
{
char c[1000];

A* ap = new (c) A[100];
// ap->~A(); // なくても実害はない
}

208:デフォルトの名無しさん
10/03/27 14:09:46
いや、どう見ても>>203が言いたいのは
struct NonPod {
　int x;
　NonPod(): x(rand()) {}
　virtual int f() { return x; }
};
みたいなものを
new NonPod[n];
した時に、要素数を記録する領域を確保するのかどうか、だろ。

209:デフォルトの名無しさん
10/03/27 14:11:50
>>208
要素数は記録しない

placement newの配列版で確保した領域を delete[] で解放しようとすると
鼻から悪魔

210:デフォルトの名無しさん
10/03/27 14:14:01
だから、>>203の意図に placement new は関係ないっての

211:デフォルトの名無しさん
10/03/27 14:16:24
>>199,>>202-203の流れだからな

212:デフォルトの名無しさん
10/03/27 14:17:48
もうひとつ。
どの処理系かも明記せずに「記録しない」なんて言い切るな。
思いっきり処理系依存だってことは皆わかってるんだから。

213:デフォルトの名無しさん
10/03/27 14:19:30
>>212
鼻から悪魔って規格票に書いてあるじゃん
という事は要素数は記録しない

214:デフォルトの名無しさん
10/03/27 14:33:33
は？

215:デフォルトの名無しさん
10/03/27 14:35:28
>>214
>>209

お前さんも頭悪いな

216:デフォルトの名無しさん
10/03/27 14:36:15
つまり、華から悪魔と規格票に書いてない場合は
「要素数を必ず記録する」と書いてあるってーのか。

そもそも俺は「未定義」と書いてあるものは見た覚えがあるが
「華から悪魔」なんて書いてある規格は見たこと無いけどな。

217:デフォルトの名無しさん
10/03/27 14:38:35
>>216
だから「未定義の振る舞い」undefined behaviorだっつーの

218:デフォルトの名無しさん
10/03/27 14:38:59
>>213 どういう理屈だよｗ

219:デフォルトの名無しさん
10/03/27 14:39:27
つまり
int * p = new int[n];
だと、要素数がどこにも記録されない、と規格のどこかに書いてあるのか？

だから
delete p[] ではなく delete p をしても見て意義動作ではないと。

ふーん。

220:デフォルトの名無しさん
10/03/27 14:40:22
>>219
馬鹿発見
placement newの配列版だと言ってるだろーが
アホか

221:デフォルトの名無しさん
10/03/27 14:42:14
>>213 >>216

未定義の振る舞いである == 要素数を記録しない
ってか？

お花畑に住んでいるって幸せ？

222:デフォルトの名無しさん
10/03/27 14:44:24
要素数を記録したら未定義の振る舞いにならないだろうが

223:デフォルトの名無しさん
10/03/27 14:45:14
だいたいplacement newはヒープ領域とは何の関係もないだろ

224:デフォルトの名無しさん
10/03/27 14:48:42
>>222-223
>>210-211を10回読み直してみたらどう？

225:デフォルトの名無しさん
10/03/27 14:49:53
>>222
勝手に決め付けるなよ

226:デフォルトの名無しさん
10/03/27 14:54:43
知るかい
俺はあくまでもplacement newの配列版について話をしてるんだ

227:デフォルトの名無しさん
10/03/27 15:15:00
だから、てめーは「最初っからずーーっと」ズレたことしか言ってねーんだよ。
てめー「だけ」がズレてんだよ。
何が「俺はあくまでも」だ。

>>199及び>>202-203において、
「operator new[]()がPOD時は要素数の領域を確保しないが非POD時は確保する」話が出てる
で>>203が「じゃあデストラクタの無い非PODなら(operator new[]の動作は)どうなっているのか」
という疑問を出している。

なのに>>204-205だの>>207だの、完璧に論点がわかってない書き込みをしている。
>>206で「そうじゃなくて」と指摘されているにもかかわらず、ズレまくり。
(言っとくが、>>197-206の流れの中には俺の書き込みは一つも無い)

しかも、「未定義動作である」とは「要素数を記録しないことである」という
他人には理解不能な理屈まで持ち出して。
>>203はおそらく「(規格では何も決められていないだろうが)
個々の処理系ではどうなんだろう？」という疑問を出しただけなのに
勝手に「要素数を記録することが規格で決められている」ということにして。

228:デフォルトの名無しさん
10/03/27 15:17:21
あ、↑の「operator new[]()の動作」というのは違うか。
new[]演算子が「要素数分の領域を多めにoperator new()に要求する」が正しいかな。

229:デフォルトの名無しさん
10/03/27 15:19:50
>>226
今読み返してみたが、>>206が「そうじゃなくて」と言っている内容の
「配列new」を勝手に「配置new」と読み替えてないか？

230:デフォルトの名無しさん
10/03/27 17:01:50
デフォルトではどうなってんだろ、ってんだから
明らかにplacement newではないだろ

231:デフォルトの名無しさん
10/03/27 20:53:10
説明能力の無い人間がついうっかり自己評価高かったりすると、
そこら中の人間を馬鹿馬鹿言って暮らさなきゃいけないからたいへんだ。

232:デフォルトの名無しさん
10/03/27 22:35:11
理解能力が足りない奴の方が始末に負えないけど

233:デフォルトの名無しさん
10/03/27 22:38:41
どっちもどっちだ

234:デフォルトの名無しさん
10/03/27 22:48:53
無駄にプライドだけ高いから本当に邪魔

235:デフォルトの名無しさん
10/03/27 22:57:20
人を変えようと思ったらまず自分が変わらにゃならんよ
自分が変わらずに他人を変えようと思っても、百万年掛けても1ミリも変わらないと思え

236:デフォルトの名無しさん
10/03/27 23:33:49
なんかすげー必死に張り付いてる奴が居るね。

237:デフォルトの名無しさん
10/03/27 23:48:13
というか分かってない奴１人だけだろ
人のせいにする前に周りをよく見ろと

238:デフォルトの名無しさん
10/03/27 23:52:39
>>229がズバリ核心を突いてるな

239:デフォルトの名無しさん
10/03/28 01:47:39
すみません．環境依存の質問なのですが
longやintのサイズが64bitや32bitで変わる例はよく見るのですが
shortやlong longが変わる実例ってあるのでしょうか？
よろしくお願いします

240:デフォルトの名無しさん
10/03/28 02:21:23
>>239
short は -32,767 ～ +32,767 を表現できることが保証されている → 16bit 以上
long long は -9,223,372,036,854,775,807 ～ +9,223,372,036,854,775,807 を表現できることが保証されている → 64bit 以上

それ以外は決められていないから変わるかもしれない

実例は……
short が4バイトなコンパイラを自分で作ればいい

241:デフォルトの名無しさん
10/03/28 03:30:55
>>203
コンストラクタ・コピーコンストラクタ・代入演算子を定義したクラスで試してみた。
少なくともcodepadのgccは、デストラクタの有無のみ見てるみたい。
URLﾘﾝｸ(codepad.org)

242:デフォルトの名無しさん
10/03/28 03:43:49
>>239
charのサイズが9ビットとか32ビットという環境は実在するので、たぶん
shortやlong longもそれなりに変なサイズになると思う。

一般的なWindows/Linux/Macの開発環境では、64ビットターゲットであろ
うと 16bit short、64bit long long しか見たことないね。

243:デフォルトの名無しさん
10/03/28 04:29:53
>>240
>>242
これは困りました・・・
ともあれ参考になりました
ありがとうございます．

244:デフォルトの名無しさん
10/03/28 08:30:09
困る・・・のか？
stdint.h の int16_t, int64_t を使えばいいという話ではないのか

245:デフォルトの名無しさん
10/03/28 15:29:14
C++でのメモリ確保について教えて下さい。

要素数が変動する配列の塊の為の領域を膨大な数確保するとします。
データ1[70]
データ2[1]
データ3[36]
データ4[12]
・
・
・
そしてそれらを管理するアドレスの配列を作ります。
データ1の開始アドレス
データ2の開始アドレス
データ3の開始アドレス
データ4の開始アドレス
・
・
・
このとき、領域確保はひとつずつnewとかで確保したほうがいいのでしょうか？
それとも巨大な領域を自分で確保し、その中に隙間を詰めるようにデータを詰め込んでいく
管理クラスを自作するほうがいいのでしょうか？
前者のほうが簡単そうではあるんですが、C++の動作の知識があまりなくて以下の不安があります。
・膨大な数こまごまと領域確保することで何らかの処理負荷が発生しないか？
・もしも適当に確保出来る空き領域見つけて確保する場合、隙間がまばらになって
　メモリが断片化され、本来可能な確保量よりも確保出来る容量が少なくなってしまわないか？

データ領域は数万から最悪数百万個単位で確保し、頻繁に消したり、追加するとします。
宜しくお願いします。

246:245
10/03/28 15:32:43
なお、vectorなどの存在は知っているのですが、その場合、準備している容量を超えた場合、
領域の再確保によってデータのアドレスが変わってしまいます。

プログラムはデータのアドレスを記憶して情報をやり取りする部分が多いのでvectorは考えていません。

247:デフォルトの名無しさん
10/03/28 15:38:42
>>245
データは単独でnewすればかまわない。よっぽど多い場合はプールなどを使うが、たいていの場合はnewで事足りる。
そこへのポインタをvectorに保持すればいい。ポインタだけを保持するならベクターの伸張じの問題は関係なくなる。
vectorに直接ポインタを入れるとdeleteが面倒なのでshared_ptrを使うのが楽だ。

248:デフォルトの名無しさん
10/03/28 15:43:19
int main() {
int *p = new int;
cout << p << endl;
p = new int;
cout << p << endl;
delete p;
return 0;
}

は間違ってますか？
最初のpはリークになる？

249:デフォルトの名無しさん
10/03/28 15:46:00
>>248
リークする。
２回newでdelete１回だから確実。

250:デフォルトの名無しさん
10/03/28 15:49:13
>>245
データの要素数に関する統計情報がないことには、
newで十分としか言えない。
ただ、要素数より余分に確保して、決まったサイズの倍数に揃えることで、
一般的には断片化を減らすことはできると思う。

251:デフォルトの名無しさん
10/03/28 15:49:15
>>249
即レスありがとうございます。
同じ変数は使いまわししないのが基本ですか？

252:デフォルトの名無しさん
10/03/28 15:58:57
>>251
うん。
使いまわしても一切メリットがないばかりか、読みにくいし最適化の妨害になる。

253:245
10/03/28 16:10:23
>>247
有難うございます。ただやはり不安なのは、OSから見てプログラムがメモリのここからここまでを使用したいと予約（newで確保）すると思うのですが、
その予約した領域のデータ（ここからここまで）を保持しないといけないと思うのですが、最悪数百万個のデータを確保する場合、
前者では開始（アドレス＋終了アドレス）＊数百万個分のメモリを占有してしまい、後者だと（開始アドレス＋終了アドレス）の一個のみで済み
前者だとそれだけでメガ単位のメモリ消費してしまわないのでしょうか？

>>250
有難うございます。なるほど、例えば要素数を１０区切りで判定してその区切りで確保することにより、
一度開放されて歯抜けになった領域に新しいデータがすっぽりはまる可能性が高まるということですね？
参考にします。

254:デフォルトの名無しさん
10/03/28 16:17:03
>>253
ヒープの管理領域のこと？１００万でも１０数メガだしwindowsなら問題ないだろう。
それよりもヒープの最大サイズを気にしたほうが良くないかな。

255:デフォルトの名無しさん
10/03/28 16:22:51
>>253
先ずは愚直に作ってみたら?
それを動かしてみれば問題点もより判り易いだろうしデバッガで追うなどして知見を得られるチャンスも増える。
始めから高性能を目指したら、デバッグの段階で二進も三進もいかなくなるぞ。

次ページ