C++相談室 part69at TECH
C++相談室 part69 - 暇つぶし2ch175:デフォルトの名無しさん
09/05/13 21:47:28
わざわざしなくていいと思うよ
意識せずとも、いずれ自然に必要になって自然に勉強してる

176:174
09/05/13 21:52:03
>>175
ほほう、そんなもんなのか。ありがとう。
むしろもうちょっと高級言語も知っとこうかなぁ。。。

177:デフォルトの名無しさん
09/05/13 23:27:37
C/C++をやると平気でインラインアセンブラを書くようになるよな
特にSSE2/SSE3関連は

178:デフォルトの名無しさん
09/05/14 00:48:26
>>171,172
クラスの関連が複雑になるのと、オブジェクトの寿命管理の点が気になりました。

> 履歴一覧を表示する元に戻すボタンでも実装するのか?
これも1つです。
ソースの見通しが悪くなり、あとで機能を追加したいと思った時に困るのではないかと思いました。

179:デフォルトの名無しさん
09/05/14 01:13:32
ササビーってIntelから出るけどあれどうなの?

180:デフォルトの名無しさん
09/05/14 01:53:25
俺、趣味でオセロプログラム書いてるけど、>>177みたいなことに手を出してみた。
最初は難しいイメージがあったが、やってみるとそうでもなかった。

181:デフォルトの名無しさん
09/05/14 02:25:47
0から1の乱数を表示させるプログラムがほしいんですがわかる人いますか?
調べてみてはいるのですが、なかなかうまく動きません。
乱数生成のためのソフトとかはいるのでしょうか?

もしお暇がありましたらよろしくおねがいします。


182:デフォルトの名無しさん
09/05/14 02:30:59
>>181
今、どれくらいの知識を持ってるの? どんなコード書いてみたの?
とりあえず、標準Cライブラリの rand っていう関数は知ってる?

183:デフォルトの名無しさん
09/05/14 02:31:35
double r;
srand((unsigned int)time(0));
r = rand() / RAND_MAX;
printf("%lf", r);

184:デフォルトの名無しさん
09/05/14 02:44:00
static_cast<double>(rand()) / RAND_MAX;だろとツッコミがほしいんだろ

185:デフォルトの名無しさん
09/05/14 02:54:43
>>183
きっと0か1しか返さないぞ。

>>178
>ボタンが親子関係でもないオブジェクトの参照を持つ
ここでいってるオブジェクトってコマンドクラスのこと?
同じボタンの機能がころころ変化するのでもなければ
参照を持つ必要なんて無いと思うけど?
どうしてもUIにヘルプ文字列を埋め込みたくないのなら
コントロールクラスに自分(ボタン)が今どんな機能なのか
問い合わせるメソッドでも作ったら?


186:デフォルトの名無しさん
09/05/14 03:34:01
>>182
rand関数はさっきから学びはじめたばかりです。
知識は基本的なプログラムならつくれる程度です。

187:デフォルトの名無しさん
09/05/14 03:38:42
randは本格用途では使い物にならんぞ
ゲームのサイコロ振るくらいに使うならいいけど

188:デフォルトの名無しさん
09/05/14 03:40:12
>>186
rand関数は、0 から RAND_MAX までの範囲の整数を返す。
(RAND_MAX は実際にはある特定の数値であり、コード中に RAND_MAX と書けばその数値として扱われる)

後は、0 から RAND_MAX までの範囲の整数を、0 から 1 までの間の小数の値に変換すればよい。
>>183-185あたりを参考に。まだ分からんところがあったら聞いてくれ。

もし本格的な乱数を使用したいなら、boostのrandomってのを調べてみるといいが、
まあそこまでする気がないならrandでいいよ。

189:デフォルトの名無しさん
09/05/14 03:43:14
>>187
本格用途ではなくごく簡単なプログラムで、サイコロを振る程度です。

>>188
rand関数について自分でも調べていたところです。
丁寧におしえていただきありがとうございます。
もしわからないことがあったら書き込みたいと思います。
ありがとうございました!

190:189
09/05/14 04:34:11
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
double random;

srand((unsigned) time(NULL)); // rand関数による乱数生成を不規則にする
for(int i=0; i<20; i++){
random = (double)rand()/RAND_MAX; // 0から1までの乱数の生成
printf("%f\n",random); // 表示する
}
}

ここでのアドバイスなどをもとにして自分でつくりました。
コメントは自分でつけたので語弊があるかもしれません。


191:189
09/05/14 05:08:06
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void)
{
double random;

srand((unsigned) time(NULL)); // rand関数による乱数生成を不規則にする
for(int i=0; i<20; i++){
random = (double)rand()/RAND_MAX; // 0から1までの乱数の生成
printf("%f\n",random); // 表示する
}
}

ここでのアドバイスなどをもとにして自分でつくりました。
コメントは自分でつけたので語弊があるかもしれません。


192:189
09/05/14 05:11:06
すみません一つはまちがいです。

上のプログラムだと乱数表示はされるのですが
一個だけ乱数表示するプログラムを実行すると、何度実行してもほとんど変わらない乱数
(例えば、0.963742 ⇒0.972378 ⇒0.981201など)
になってしまいます。

良い解決方法はないでしょうか?

193:デフォルトの名無しさん
09/05/14 05:37:58
win32環境ならtime()をGetTickCount()なりQueryPerformanceCounter()なりで置き換えるとか。

194:デフォルトの名無しさん
09/05/14 06:28:58
>>185
> ここでいってるオブジェクトってコマンドクラスのこと?
> 同じボタンの機能がころころ変化するのでもなければ
> 参照を持つ必要なんて無いと思うけど?
ヘルプメッセージを表示するクラスのメンバ関数をboost::functionに入れてボタンクラスに渡すという意味です。
Clickなど他のイベントも同様に「他のクラスのメンバ関数をboost::functionに入れて~」とやっていったらクラスの関連が複雑になるのではないのかと。
また、boost::functionの中で保持されているポインタの寿命(有効か)の不安を感じます。

195:デフォルトの名無しさん
09/05/14 06:33:38
random = (double)rand()/(RAND_MAX+1.0); // に、しとけ。

196:デフォルトの名無しさん
09/05/14 07:42:43
struct A{virtual void operator()()=0;};
struct B:A{virtual int operator()(int)=0;};
struct C{A&x;C(A&a):x(a){} int operator()(int i){return static_cast<B&>(x)(i);}};
struct D:A{void operator()(){}} d;

int f(){
C c(d);
c();
return c(1u); // これ・・・
}
コンパイルを通ってしまわない様にするにはどう改造すればいいのでしょう?

197:デフォルトの名無しさん
09/05/14 08:01:28
>>196
コンパイルが通らないようにする方法ならいくらでもわるわけで、
何がしたいのか挙げてもらわないと望む答えは得られないでしょう。

198:196
09/05/14 08:10:12
void operator()(){x();} を書き忘れ
struct C{A&x;C(A&a):x(a){} int operator()(int i){return static_cast<B&>(x)(i);} void operator()(){x();}};

199:デフォルトの名無しさん
09/05/14 09:03:46
>>195
なんのために+1.0するの?

200:デフォルトの名無しさん
09/05/14 09:06:17
>>199
結果に整数 N をかけることで、簡単に N とおりの選択に使う乱数が得られる。
「0 から 1 の乱数」が 1.0 を含んでいると、こうはいかない。

201:デフォルトの名無しさん
09/05/14 09:12:53
>>200
今回の目的は
「0から1の乱数を表示させる」
だけど、いいの?

202:デフォルトの名無しさん
09/05/14 09:20:22
>>201
日本語だけでは閉区間なのか開区間なのか、区別がつかないんで、
質問者に判別してもらうしかないな。

簡単なサイコロの用途であれば 200 の性質が役に立つはずなんだけど。

203:デフォルトの名無しさん
09/05/14 09:22:50
簡単なサイコロの用途であれば、
random = rand()%6; // で、十分。

204:189
09/05/14 11:12:04
>>193
「GetTickCount()識別子が見つかりませんでした」とでます。
変数として扱われているのですかね・・・
他のプログラムをみてみたのですが使い方がわかりません
勉強不足ですよねスミマセン

>>195
お返事ありがとうございます
プログラムの下から4行目のことですよね?
してみたのですがほとんど値がかわりませんでした
何かまちがっているでしょうか

205:189
09/05/14 11:13:50
>>193
「GetTickCount()識別子が見つかりませんでした」とでます。
変数として扱われているのですかね・・・
他のプログラムをみてみたのですが使い方がわかりません
勉強不足ですよねスミマセン

>>195
お返事ありがとうございます
プログラムの下から4行目のことですよね?
してみたのですがほとんど値がかわりませんでした
何かまちがっているでしょうか


206:189
09/05/14 12:43:26
>>193
GetTickCount()は識別子が定義されてませんとでてしまいます
変数としてあつかわれてしまっているようです

>>195
お返事ありがとうございます
1を足したのですがあまり乱数はかわらなかったのですが
何かまちがっているのでしょうか

207:195
09/05/14 12:45:45
コンパイラは Borland だろ。

208:189
09/05/14 12:49:10
>>193
GetTickCount()は識別子が定義されてませんとでてしまいます
変数としてあつかわれてしまっているようです

>>195
お返事ありがとうございます
1を足したのですがあまり乱数はかわらなかったのですが
何かまちがっているのでしょうか

209:189
09/05/14 12:51:07
すみません何度もかきこんでしまいました

210:189
09/05/14 12:55:04
>>202
[0,1)区間となっています。0以上1未満ということです。
サイコロの乱数程度といってしまいましたが
サイコロは関係ありません

211:デフォルトの名無しさん
09/05/14 13:25:26
>>208
windows.hをインクルードしてないとか言うなよ

212:デフォルトの名無しさん
09/05/14 13:29:26
だって、それを書けなんて誰も言ってないじゃないですか。

213:189
09/05/14 13:30:44
>>211
ご指摘ありがとうございます。
してませんでした。

214:195
09/05/14 13:41:16
>>212 コンパイラの名前とバージョンは?

215:デフォルトの名無しさん
09/05/14 23:50:55
すごく初歩的な質問ですが、C++で数字の小数点以下を
繰り上げるには何をつけたらいいんですか?

216:デフォルトの名無しさん
09/05/14 23:53:45
std::ceil()だろ
Cにもある

217:デフォルトの名無しさん
09/05/14 23:55:09
つceil

218:デフォルトの名無しさん
09/05/15 00:16:28
それは「切り上げ」じゃん。ちゃんと答えてやれよ
因みに俺は小数点以下の「繰り上げ」なる概念について知らないので答えられん

219:デフォルトの名無しさん
09/05/15 00:17:50
くだらねえ…

220:215
09/05/15 00:21:12
おかげさまで解決しました。どうもありがとうございましたm(_ _)m

221:デフォルトの名無しさん
09/05/15 00:25:23
ちなみにceil()は負の数は0から離れる方向になるからな

222:デフォルトの名無しさん
09/05/15 09:52:02
>>203
それって偏りが出るよね。

223:デフォルトの名無しさん
09/05/15 10:02:11
RAND_MAXが極端に小さい環境ならね。
32767程度あれば、5461回が5462回になる程度のばらつきだよ。

224:デフォルトの名無しさん
09/05/15 10:22:09
マジで⁉

225:デフォルトの名無しさん
09/05/15 10:23:33
>>222
サイコロに偏りが無いとでも?

226:デフォルトの名無しさん
09/05/15 10:45:40
線型合同法は下位ビットの周期性が

227:デフォルトの名無しさん
09/05/15 12:14:07
テンプレートのテクニックをまとめた、テンプレートの著書を教えてください。
知っているのは、modern C++ と、テンプレートテクニックという本です。

良いサイトや良い本の情報ください。

228:デフォルトの名無しさん
09/05/15 12:26:08
C++ Template Metaprogramming: Concepts, Tools, And Techniques From Boost And Beyond

229:デフォルトの名無しさん
09/05/15 12:53:18
マウスでいまクリック、もしくはドラッグしているファイルやディレクトリのパスを
取得する方法ってありますか?常駐ソフトのような形で、起動してからクリック、ドラッグ
したファイルのパスをテキストログとして、出力するようなものを作りたいのですが・・・。

230:デフォルトの名無しさん
09/05/15 12:56:30
なんでこっちに来たんですか?

231:デフォルトの名無しさん
09/05/15 13:00:38
>>226
そんな乱数でもない数列をrand()という名前の関数の出力にする処理系が悪い。
ゴミだから早急に廃棄しろ。

232:デフォルトの名無しさん
09/05/15 13:39:39
>>225
製作工程の都合で、1,6の面積が微妙に大きいという話しか?
それとも、くりぬかれた目による重心のずれ、密度の偏りの方か?

233:デフォルトの名無しさん
09/05/15 13:55:52
>>228
ありがとうございます。
翻訳出てないんですかね……残念です。

C++の一番の特徴であるテンプレート関係の本が少ないのは何故?
わかりやすくテクニックを知りたいのに

234:デフォルトの名無しさん
09/05/15 15:54:15
すみませぬ JAVAから入っていまC++を勉強し始めたのですが、
C++で、配列で宣言した変数は、跡になってから自らがいくつの要素を持つ配列なのかチェックする方法ってありますか?


Javaだと、
String str[] = new String[3]
のように宣言した場合、
str.length を見れば要素数を見ることができますが、C++の場合は方法ありますか?

235:デフォルトの名無しさん
09/05/15 15:56:52
>>234
ないから素直にstd::vector使っとけ

236:デフォルトの名無しさん
09/05/15 15:57:32
>>234
sizeof(str) / sizeof(str[0]) で自分は調べてる

237:デフォルトの名無しさん
09/05/15 15:58:40
>>236
アホか

238:デフォルトの名無しさん
09/05/15 16:03:46
え?駄目なの
俺も>>236を常用してるけど・・

239:デフォルトの名無しさん
09/05/15 16:07:00
大丈夫、話が噛み合ってないだけだ。
char * foo = new char[3];
した場合は要素数を知る手段はない。
char foo[] = "abc";
した場合は要素数(≠文字数)を>236で得られる。

240:234
09/05/15 16:20:29
ありがとうございます。
C言語の場合、
配列を作ったら作りっぱなし、メモリのどこまでがその配列に割り当てられた場所かという情報はどこにもないという認識で良いですか?

たとえば10要素の配列を作ったあとに20番目の要素にアクセスしようとすると、JAVAだとぬるぽが出て教えてくれますが、
Cの場合はシステムから見てそれが分からずに、20番(に相当する場所)を読みに行ったり、書き込んでしまう という理解で良いですか?

241:デフォルトの名無しさん
09/05/15 16:25:57
良いです。
ちなみにここはC++のスレです。

242:デフォルトの名無しさん
09/05/15 16:39:03
>>240
そうです
運が良ければアプリ自体が吹っ飛んでくれますが運が悪いとそのままメモリ破壊して動き続けます
なのでJavaしかできない人が集まってC++案件とかやるととても楽しいことになります

243:デフォルトの名無しさん
09/05/15 16:41:59
そもそも、10要素の配列を作ったあとに20番目の要素にアクセスしようとするような奴は
「Javaしかできない人」ではなく、「Javaもできない人」

244:デフォルトの名無しさん
09/05/15 16:47:00
>>240
大きな勘違いをしている。
>配列を作ったら作りっぱなし、メモリのどこまでがその配列に割り当てられた場所かという情報はどこにもないという認識で良いですか?
配列は、>36でサイズを得ることができる。
つまり、newなんていう外道なモノを使わずに、(昔なつかしの)固定長配列を使うかstd::vectorを使えと言うことだ。

245:デフォルトの名無しさん
09/05/15 20:48:50
Cに配列なんてなかった

246:デフォルトの名無しさん
09/05/15 21:16:41
>>245
何??

247:デフォルトの名無しさん
09/05/15 21:18:10
何の話?

248:デフォルトの名無しさん
09/05/15 21:19:50
ついに狂ったか?

249:デフォルトの名無しさん
09/05/15 21:22:37
Cなんてなかった

250:デフォルトの名無しさん
09/05/15 21:50:31
コンピュータなんてなかった

251:デフォルトの名無しさん
09/05/15 21:52:47
平行世界とつながったな

252:デフォルトの名無しさん
09/05/15 22:09:27
仕事なんてなかった

253:デフォルトの名無しさん
09/05/16 22:00:39
ISOのC++の2003年の規格のJISは訳がひどいですね。
原文の構成もひどいけど。
規格をもっと読みやすくしたような、同じだけ詳しい本ってあるんでしょうか?

254:デフォルトの名無しさん
09/05/16 22:06:55
無いから我慢して読め

255:デフォルトの名無しさん
09/05/16 22:15:03
規格書の文章なんてどれもああいうもんだよ。
訳が酷いわけじゃない。

256:デフォルトの名無しさん
09/05/17 01:01:57
C++は規格自体がひどいから文章もひどくなる

257:デフォルトの名無しさん
09/05/17 01:56:44
C++の文法があまりに酷いもんで翻訳者もイライラしながら
訳してたんじゃないか?w

258:デフォルトの名無しさん
09/05/17 02:35:49
どのくらいメモリを使っているかという情報は型が持っているのだから
例えば、char[3] 型の最初の要素のアドレスをchar*型に代入したら
もうメモリサイズがわからなくなるのは当然といえば当然。
char[3] 型を char[3] 型に代入する分にはちゃんとサイズがわかる。

という感じかしら

259:デフォルトの名無しさん
09/05/17 04:11:03
変数の型も含めてすべてをクラスにってのがJava以降に導入されたもんだからね

260:デフォルトの名無しさん
09/05/17 04:25:19
それは別にJavaで初めてというわけじゃないだろ。


261:デフォルトの名無しさん
09/05/17 08:18:01
Javaも全てがクラスというわけでもないし。

262:デフォルトの名無しさん
09/05/17 08:57:46
全てがクラスになる


unlambdaやれば全てが関数だからオススメ。

263:デフォルトの名無しさん
09/05/17 09:49:55
C++の一行の文字数って標準仕様上、制限ありますか?
またあるとして、現実的に気にした方が良いですか?


264:デフォルトの名無しさん
09/05/17 10:53:44
>>263
言語仕様としてはメモリの許す限りおk

265:デフォルトの名無しさん
09/05/17 10:56:29
メモリの許す限りという制限すらない無制限

266:デフォルトの名無しさん
09/05/17 11:16:18
ありがとうございます。
じゃあ気にせず行きます!

267:デフォルトの名無しさん
09/05/17 11:29:51
80文字が一つの目安だな。
120文字超えてたらちょっとイラッとする。

268:デフォルトの名無しさん
09/05/17 11:32:26
クラスのメンバ関数の返り値は
コピー返しでも可能ならconstにしろ

とEffective C++で言われていましたが、
なぜか返り値がbool型だけはconst付けない風習がありません?
例: bool is_valid() const {return member?true:false;}
この場合も返り値にconst付けた方が良いのでしょうか?

269:デフォルトの名無しさん
09/05/17 11:34:17
付けた方がいいよ。

270:デフォルトの名無しさん
09/05/17 11:54:31
>>268
メリットはなに?

271:268
09/05/17 11:58:07
>>269
そうですよね。ありがとうございます。

>>270
組み込み型の返り値を万が一変更するバカが居た場合の予防です。

272:デフォルトの名無しさん
09/05/17 12:12:37
>組み込み型の返り値を万が一変更する
なんてできません。

馬鹿って言う人が馬鹿なんだぞw
ちゃんと読もうぜ。

273:デフォルトの名無しさん
09/05/17 12:25:20
メリットは記述の統一感かな?
テンプレート引数にするときにいいことってある?

自分は組み込み型にはconst付けない派だな

274:デフォルトの名無しさん
09/05/17 12:34:53
それ書いてあるのってEffecitve C++だっけ? Exceptionalかなんかのほうだった気がするが。

275:デフォルトの名無しさん
09/05/17 12:35:35
> テンプレート引数にするときにいいことってある?
全くない。

むしろ
組み込み型戻り値のconstは
環境によってはwarningやerrorになるから
うっとうしいことこの上ない。




276:デフォルトの名無しさん
09/05/17 13:02:35
constな自クラス型参照メンバなんか使いだすと有りとあらゆる宣言にconstが波及して`err passing~'の楽しい事になるんだよね。

277:271
09/05/17 13:06:18
>>272
> >組み込み型の返り値を万が一変更する
> なんてできません。
有名どころのコンパイラならちゃんとコンパイルエラー出してくれるみたいですが
環境が違っても確実に予防してくれるのでしょうかね?

>>274
Exceptional C++だったかもしれません。


>>275
gccやboostの実装でも確かに組み込み型の戻り値にconstは付いていないようですね。



278:デフォルトの名無しさん
09/05/17 13:59:47
そもそも「組み込み型の返り値を万が一変更する」って
どういう意味なの?

279:デフォルトの名無しさん
09/05/17 14:00:46
public継承は分かる。
private継承も分かる。

ではprotected継承は?
使ったことある人います?(遊びじゃなく実用で。)

280:デフォルトの名無しさん
09/05/17 14:17:27
だからちゃんと嫁ってば。

Effecitve C++ 2ndの21節と29節に書いてあるのは、
非組み込み型のコピーを返す関数を左辺値として使われないように、
左辺値になり得る型が戻り値の場合はconst付けよーねってことと、
const宣言したメソッドがデータのハンドル(stringクラスのcharポインタとか)を
返却するときは戻り値にconst付けよーねってこと。

わざわざ押し入れからEffectiveC++取り出してきた俺に
プッチンプリン買ってこいw

>環境が違っても確実に予防してくれるのでしょうかね?
ぶっ壊れたコンパイラの話をされても困る。

281:デフォルトの名無しさん
09/05/17 14:18:55
じゃあ俺はなめらかプリンでよろしく

282:271
09/05/17 14:33:58
>>280
サーセン。吊って来ます。

ありがとうございました。

283:デフォルトの名無しさん
09/05/17 14:35:03
constの同音異義語っぷりもなかなか見事なものだ

284:デフォルトの名無しさん
09/05/17 17:10:42
>>280
非組み込み型の戻り値について const つけてあると、右辺値参照として取れなくなっちゃいそう。
この指針は将来的に非推奨になるんじゃなかろうか?

285:デフォルトの名無しさん
09/05/17 17:52:26
そもそも右辺値参照自体が、
Effective C++で問題が広く知れ渡ったことで
実装されることになったんじゃないかな。

ぷらぷら界に多大な影響を与えた引き替えに、
次の版は全面改定だな。

286:デフォルトの名無しさん
09/05/17 17:55:23
cppunitに関する質問ってありですか?

287:デフォルトの名無しさん
09/05/17 17:56:06
>>286
専用スレがあるから、まずはそっちで。

CPPUnitについて少し話そうかい
スレリンク(tech板)

288:デフォルトの名無しさん
09/05/17 18:07:21
互換性考えたら右辺const値のオブジェクト代入は右辺値参照を無視してコピー噛ますんじゃないかな

289:デフォルトの名無しさん
09/05/17 18:09:03
そう。だから右辺値参照を使って最適化しているつもりが、うっかり今までどおりの
コピーになったりすることが考えられる。まぁ最適化の範疇と認識する分には問題には
ならないんだろうけど。

290:デフォルトの名無しさん
09/05/17 19:44:11
右辺値参照って、なんだかよく分からない。
C++0xが出れば解説も増えるかな?

291:デフォルトの名無しさん
09/05/17 20:32:36
僕もよく解らないけど、関数の返すオブジェクトがコピーされるとき、
もとのオブジェクトが捨てられる場面で、
コピーコンストラクタを呼ばないでよりコストの低い破壊的なコピー、
つまりオブジェクトのメンバを移動することをするってことなんでしょ?
ただそれだけでしょ?

292:290
09/05/17 21:12:34
現在 標準C++のコンパイラの最適化機能として実装されている
 戻値最適化
とは違うのかいな?

C++ ラビリンス Return value and constructor
URLリンク(www.fides.dti.ne.jp)


293:デフォルトの名無しさん
09/05/17 21:12:36
そうそう、「移動」の概念(ムーブセマンティクス)を容易に実現するための言語仕様として考え出されたのが右辺値参照。
ほかに分かりやすい例を挙げるとしたらauto_ptr(の後継)がvectorに入れられるようになることとか、
functionやbindなどで各引数のconstや参照の有無の挙動を完全に再現したoperator ()を実現できるなんて効果がある。

294:デフォルトの名無しさん
09/05/17 21:27:43
多次元配列の要素全てを任意の値で埋めたい場合
どう書くのが良いでしょうか。
1次元の場合は std::fill や std::fill_n が使えるのですが。

int a[10][10];
for(int i=0; i < 10; i++)
for(int j=0; j < 10; j++)
a[i][j] = 42;

ということをしたいわけです。

295:デフォルトの名無しさん
09/05/17 21:28:25
>>292
最初の例や2番目のコピーコンストラクタ・代入演算子が呼ばれる例でもムーブセマンティクスは効く。
そこのコピーコンストラクタ・代入演算子の呼出が、ムーブコンストラクタ・代入演算子の呼出になる。
一般にムーブコンストラクタ代入演算子はコピーコンストラクタと違って、
それより遙かに低コストで例外の投げようもない実装になるので、より最適なコードになるとされる。

296:デフォルトの名無しさん
09/05/17 21:31:12
>>294
自分で書いてるじゃねーか。何が不満なの?

297:デフォルトの名無しさん
09/05/17 21:34:04
酒鬼薔薇

298:290
09/05/17 21:34:39
>>295
ほっほー。
そうなのかぁ。
ありがとう。C++0xが楽しみになって来たんだぜ。

299:デフォルトの名無しさん
09/05/17 21:46:45
いや普通に

 memset(a, 42, 100);

で、いいんでない。string.h が使える環境なら



それより最近、スザンヌとギャル曽根の区別が付かなくて困ってます
見分け方を教えてください

300:デフォルトの名無しさん
09/05/17 21:47:47
>>299
int に memset() して 42 になるとでも思ってんのか?

301:299
09/05/17 21:47:53
アンカー忘れ。>>294 な

302:デフォルトの名無しさん
09/05/17 21:51:12
>>299
これはひどい。

303:299
09/05/17 21:52:38
すまん。レス取り消し。int だったね

回線切って(ry


304:299
09/05/17 21:53:52
>>301-302
仕事速いな。暇人

305:デフォルトの名無しさん
09/05/17 22:04:38
>>304
お前の方がよっぽど暇人に見えるんだが

306:デフォルトの名無しさん
09/05/17 22:11:27
>>294
その配列だったら連続性が保証されてるから
std::fill_n(&a[0][0], 100, 42)
でいいだろ。

307:デフォルトの名無しさん
09/05/17 22:12:15
>>294
お好きなほうをどうぞ。
std::fill_n(&a[0][0], sizeof a / sizeof a[0][0], 42);

namespace bll = boost::bind;
std::for_each(a, a + sizeof a / sizeof a[0], bll::bind(std::fill_n<int*, std::size_t, int>, bll::_1, sizeof a[0] / sizeof a[0][0], 42));

308:デフォルトの名無しさん
09/05/17 22:23:24
>>307
std::fill_n(first, n, val) は [first, first + n) に対しての操作だから
要素数でOK。sizeof a / sizeof a[0][0] は冗長。

309:デフォルトの名無しさん
09/05/17 22:26:42
それも要素数・・・

310:デフォルトの名無しさん
09/05/17 22:28:14
g++にてテンプレートに暗黙の型変換を絡めたら分からなくなったので教えてください。

C++ code - 60 lines - codepad
URLリンク(codepad.org)
このソースコードでは50行目hoge < short(1)の部分で
error: no match for 'operator<' in 'hoge < 1'
と言われてしまいます。どうやら暗黙の型変換がうまくいかないようです。

これを改変してForward declarationを無くして代わりにクラステンプレートの内部で friend 関数を定義することで回避できます。
C++ code - 49 lines - codepad
URLリンク(codepad.org)

しかし、どうして前者のソースコードでは暗黙の型変換がうまくいかないのでしょうか?



311:294
09/05/17 22:30:18
みなさまありがとうございます。

std::fill_n(&a[0][0], sizeof a / sizeof a[0][0], 42)

がよさそうですね。勉強になりました。



312:デフォルトの名無しさん
09/05/17 22:39:30
>>309
だから、要素数が既知なのに一々冗長に書くことないってこと。

313:デフォルトの名無しさん
09/05/17 22:42:54
>>312
「要素数が既知」ということに依存したコードにするほうが面倒なこともあると覚えておけ。

一般的には、保守性のほうが一回だけの記述の利便よりも重要だ。

314:デフォルトの名無しさん
09/05/17 22:45:14
>>313
何頭に血を登らせてるの?
質問者が提示したコードで要素数が定数になってたんだからそれでいいだろ。
不明な場合に要素数を計算するのは当然のこと。

315:デフォルトの名無しさん
09/05/17 22:45:22
>>312
マジックナンバーは避けるべきだろjk
const N = 10;
int a[N][N];
なんてしているならsizeofを使わずにNと書いてもいいとは思うけど。

316:デフォルトの名無しさん
09/05/17 23:08:17
そういう本質でない話はもういい

317:デフォルトの名無しさん
09/05/18 01:54:38
template<T,U>void fill(T (&d)[U],T v){for(unsigned i=0;i<U;++i)d[i]=v;}
template<T,U0,U1>void fill(T (&d)[U0][U1],T v){for(unsigned i=0;i<U0;++i)for(unsigned j=0;j<U1;++j)d[i][j]=v;}

マジックナンバーイラズサイテキ化キタイダイ
int a[10][10];
double b[10];
fill(a,0);
fill(b,0.0);

318:デフォルトの名無しさん
09/05/18 02:07:27
オナニーレスうぜえな
ループを書きたくないってのが本題なのに、それじゃ本末転倒だろうが

319:デフォルトの名無しさん
09/05/18 02:22:32
>>318
何いってんの?
ライブラリって知ってる?

320:デフォルトの名無しさん
09/05/18 02:57:44
>>310
暗黙の型変換はテンプレートを具象化しなければならない時には行われないから
んで、どうすればいいかというと後者のようにすればいい
Effective C++の46項に詳しく書いてあるよ

321:デフォルトの名無しさん
09/05/18 03:25:03
>>284,285,288,289
C++0x の話としては,戻り値の型が const 修飾されていると
move 出来ない (immutable な右辺値になる) ので,
Effective C++ の記述がやや古くなるのはその通りだと思います.

C++0x 的には, EC++ のこの記述は
恐らく "Extending move semantics to *this" と
"Defaulted and Deleted Functions" との組み合わせに置き換わるべき話だと思います.

322:デフォルトの名無しさん
09/05/18 03:56:14
C++が苦手なCプログラマなのですが、ちょっと質問です。
ファイル内の文字列を探すプログラムです。
これをC++で書くとしたらこの程度でもクラスを作るのですか?
#include <stdio.h>
#include <string.h>
int main(int ac, char * av[])
{
 //ファイルからメモリーに読み込み
 FILE * fp = fopen("文字列が入ったファイル", "r");
 fseek(fp, 0, SEEK_END);
 int fSize = ftell(fp);
 fseek(fp, 0, SEEK_SET);
 char * buf = (char *)malloc(fSize);
 fread(buf, 1, fSize, fp);
 fclose(fp);
 //さがす
 char ss = "abcde";
 int ss_len = strlen(ss);
char * p = buf;
 for (int i = 0; i < fSize - ss_len; i++) {
  if (strncmp(ss, p, ss_len) == 0) {
   printf("%d番目に見つかりましたよ\n", i);
   return 0;
  }
  p++;
 }
 free(buf);
 return 0;
}



323:デフォルトの名無しさん
09/05/18 04:00:29
おれはc++のOOP が標準だから、特別な理由が無い限りOOPで書く。
英語で育った人は、特に何も考えずに英語会話するのと同じ

324:デフォルトの名無しさん
09/05/18 04:03:57
その程度だと、既存のクラスを使うだけで出来上がるね。つまり、クラスを作る出番ではないと。

極論すればクラスってのは作るものというより使うもの。

325:デフォルトの名無しさん
09/05/18 04:09:51
それに、mallocをfreeしてないでしょ、終われば開放するけど、
それはたまたま短いプログラムだから、OOPだと、明示的にディストラクタがある。
まあ使わなきゃ意味無いけど、私はこれも標準で書いてしまう。だから少し安心なわけ。
それに、そのプログラムはバッファーオーバランしないようだけど、それも、保護されやすい。
ただし、標準でOOPが身についてるからであって、人によってはOOPでもいくらでも汚くかける。

326:デフォルトの名無しさん
09/05/18 04:13:16
あ、ごめ freeしてた orz

327:デフォルトの名無しさん
09/05/18 04:14:40
いや…、Cはもう、身についてないから…と言い訳する  orz orz orz

328:デフォルトの名無しさん
09/05/18 04:16:55
一人で無駄に4レスも使いやがって

329:デフォルトの名無しさん
09/05/18 04:17:57
俺はその程度ならclass内でやったりしないな。FILEも普通に使うし。

ただ、バッファはvector<char>で確保するし
探索も文字列探索クラス(BM法とか)を作って実行するね。

処理自体は(mainには限らないが)普通の関数に置く。
ただこれは当然「ファイル内の文字列探索が処理の全て」の場合。
何らかのclassの処理の中でファイル内探索を必要とする時は、当然そのように書く。

330:310
09/05/18 05:52:46
>>320
Effective C++では後者の方式が天下りに与えられていました。

あくまで前者のような方式(実装をクラス宣言部分に書かない)
で解決する方法はありませんか?
(後者の方式でprivate宣言されたヘルパー関数を呼び出すという回避策もありますけれど。)


331:デフォルトの名無しさん
09/05/18 05:56:50
>>325
destructor
はディストラクタではなくデストラクタね。発音的にも用語的にも。
ディスクトップでなくデスクトップなのと同じで。



332:デフォルトの名無しさん
09/05/18 10:51:25
>>330
関数が2つになっちゃうけど、
クラス内に
template<typename T> friend bool operator <(const Hoge &lhs, T rhs);
template<typename T> friend bool operator <(T lhs, const Hoge &rhs);
って書けば、関数テンプレートの定義を外に書けると思う…たぶん

それか、関数テンプレートをやめて定義を特殊化して書いてもいけるんじゃないかな。

間違ってたらサーセン

333:デフォルトの名無しさん
09/05/18 16:13:37
>>322 を見て思ったんですが、
ファイルを読み込み文字列検索するだけでこんな長く分り難いにコードにえーって感じなんですが、
C++を使って書くとこれより短く解りやすいコードになるんですか?
それはどんな感じになるんですか?

>>322 で
printf("%d番目に見つかりましたよ\n", i);
return 0;
ここでreturnしているんですが、ここではfreeしなくて良いんですか?

334:デフォルトの名無しさん
09/05/18 16:41:01
>333
main() {system("grep abcde 文字列が入ったファイル");}

>free
リークしていないので問題ないが、姑に目を付けられる。

335:デフォルトの名無しさん
09/05/18 16:53:00
でも突然サブルーチンに昇格する可能性もあるから、
常にfreeした方がいいよ。

336:デフォルトの名無しさん
09/05/18 17:02:55
>>334
>free
見つかった時、見つからない時の両方でfreeしないなら良いけど
片方しかしてないって、C使いらしくないんじゃない?
短いコードでたった2箇所を管理するだけなのに、それすら出来ないなんて

337:デフォルトの名無しさん
09/05/18 17:55:44
freeの仕様について言及しただけで、
>>322のソース自体に文句付けるなら
もっといろいろあるだろ。

338:デフォルトの名無しさん
09/05/18 21:07:11
return 0; を break; に置き換えるとか?

339:デフォルトの名無しさん
09/05/18 21:14:11
ファイルを一気に読むのが好きになれない、俺なら1行ずつの処理にする。

340:デフォルトの名無しさん
09/05/18 21:15:00
配列まではすんなり頭に入ったけど、ポインタとかクラスのメンバ関数とかわけわかんねー・・
なんにしても作りたい物が無ければ頭に入らない気がしてきたんだけど、ドリルみたいなものって無いですか


341:デフォルトの名無しさん
09/05/18 21:16:19
宿題スレに山ほど

342:デフォルトの名無しさん
09/05/18 21:19:51
こんなスレあったのか、ありがとう

343:デフォルトの名無しさん
09/05/18 21:35:44
>>341
宿題スレはいいよな
糞問ばっかりだけど最初のうちは数こなす方が大事だし

344:310
09/05/18 23:20:37
>>332
なるほど。
やはり関数を1つにまとめ、かつ
(特殊化をすると妨げられる)汎用性を保とうとするならば
Dan Saksの
More C++ Idioms/friend 関数の生成(Making New Friends) - Wikibooks
URLリンク(ja.wikibooks.org)(Making_New_Friends)
すなわちEffective C++でいう後者の方式しかないようですね。

ありがとうございました。

345:デフォルトの名無しさん
09/05/18 23:30:53
次はコナン風で頼む。

346:デフォルトの名無しさん
09/05/18 23:32:24
どっちのコナンだよ

347:デフォルトの名無しさん
09/05/18 23:43:35
やってくれるのか?
わくわく

348:デフォルトの名無しさん
09/05/19 01:23:32
コナン・ザ・グレート風で頼む。

349:デフォルトの名無しさん
09/05/22 23:15:48
クラス中の宣言の中でメンバ関数の定義をした場合、
自動的にinline展開要請になるんだよね?

では
クラス中の宣言の中でfriend関数の定義を記述した場合、
inline展開要請になるのかい?


350:デフォルトの名無しさん
09/05/22 23:32:49
^^

351:デフォルトの名無しさん
09/05/22 23:35:26
inline展開陳情のほうがいいかも。

352:デフォルトの名無しさん
09/05/22 23:49:36
俺のBCC 6.1.0ではオプションを付けない限り inline は全部無視される\(^o^)/

デバッグの時の事を考えてだと

353:デフォルトの名無しさん
09/05/23 00:48:25
>>352
BCC以外でもみんなそうだけど……。

354:デフォルトの名無しさん
09/05/23 15:44:38
同じ質問になるのですが、86とは別人です。
コンストラクタで例外を投げるな、というのをかなり以前Cマガジンで読みました。
その後、Google や >>93 で、コンストラクタ内で例外を投げる時に
適切にリソースを解放すれば問題ない、というのが多かったのですが、
以下のサイトに気になる記述も見つけました。

URLリンク(www.geocities.jp)
newで作ったときにオブジェクト自体がリークしてしまう

URLリンク(monoist.atmarkit.co.jp)
ポインタが返ってこない。知らないポインタは消せない

コンストラクタで例外を発生させてもよいが、その場合は new するな、
という理解でよいでしょうか。

355:デフォルトの名無しさん
09/05/23 16:19:13
>>354
Symbianは組込だからそうなっていないのかもしれないが、普通はその心配は要らない。

その場合は確かにプログラムで対処できないので、言語が面倒を見てdeleteしてくれる。
規格では15.2にそう定められている。

ちなみに、そういうわけでnewを定義するときには必ず対応するdeleteを定義しないといけない。
URLリンク(www.fides.dti.ne.jp)

356:デフォルトの名無しさん
09/05/23 17:13:34
>>355
規格での項番まで示していただきまして、有難う御座います。
15.2/2 の箇所ですね。
規格に正しく準拠した処理系であれば問題ないとことで、懸念なく利用したいと思います。
有難うございました。

357:デフォルトの名無しさん
09/05/23 22:49:39
初心者ではないと思っていたのですが、初心者からこんな質問を受けて
的確に答えられなかった自分が恥ずかしいです。どなたか、模範解答を教えてください。

「ヘッダファイルの用途と、使用によるメリットは理解できました。
ただ、cpp ファイルを分ける目的がわかりません。
また、cpp ファイルを複数持たせた場合、ビルド順はどうなるのですか?」

宜しくお願いします。

358:デフォルトの名無しさん
09/05/23 23:01:32
むしろcppファイルを分けないでどうやってまともに開発しているのか分からないぐらいだが。

分割コンパイルすることで仕様変更に伴う再コンパイル時間の短縮とかも見込めるけど、
それ以上にそもそも他人が作ったクラスとかを使いたい(再利用したい)場合とか
cppファイルが分かれてなかったら再利用できないだろ。

359:デフォルトの名無しさん
09/05/23 23:06:45
>>358
その観点で考えると、うちのプロジェクトは基本的にほどんどがヘッダファイルで構成されていて、
クラスは基本的に .h で作って #include で取り込む、っていう方法を取っています。
なので、再利用には困りません。
ほとんどがヘッダっていう考え方がNG?
あと、ビルド順序はどうなるものですか?やってみたんですが分かりませんでした。


360:デフォルトの名無しさん
09/05/23 23:07:48
いやまて。ヘッダファイルに直接定義を書き込んでいるのか?
そんなことできないだろ。

361:デフォルトの名無しさん
09/05/23 23:10:52
出来るだろ。じゃないとboostのビルド不要なライブラリは実現できないよ。

362:デフォルトの名無しさん
09/05/23 23:12:36
「ビルド順はどうなるか」って、質問者はもちろん、>>357自身も理解してない気配。
分割コンパイルやリンクについてわかってないまま脱初心者とは。

ちなみに、グローバルやclass-staticな変数の初期化順については
何も規定されていないことが規定されている。
ということは、リンク順についてそれが当てはまることを意味するが
規格に「リンク」という単語が出ているかは知らない。

cppの分割については>>358と同じ。
classにわけたり、意味的なまとまりにわけたりして
まともなものを作るのなら分割するのが当然。

>>359
Javaチックな書き方ってことかね。
別にそれならそれで良いんじゃないの。
.hに全部書く、ということは、「ビルド(コンパイル)時間の短縮」なんて
露ほどにも考えていないということだから、
再利用もできるし分割コンパイルなんて必要無いかもね。

363:デフォルトの名無しさん
09/05/23 23:13:20
言い方がまずかったか。「できないものがある」。こうだな。
もしかして、全部 inline にしたり、あらかじめ obj にしたりしてあるのだろうか。

364:デフォルトの名無しさん
09/05/23 23:17:24
>>359
>クラスは基本的に .h で作って #include で取り込む、っていう方法を取っています。
>なので、再利用には困りません。
>ほとんどがヘッダっていう考え方がNG?
マジ??
その会社 大丈夫???

考えて見ればcppファイルが1つだけなら関数の定義とかを.hに書き込んでも
バイナリの時点で重複は起らないが(hでインクルードガードしていること前提ね。)
それにしても、、、ねぇ。。。


365:デフォルトの名無しさん
09/05/23 23:18:54
>>360
dllexport が必要な時と、main() 系、コールバック系以外はすべてヘッダファイルなんです。
クラスの定義や構造体など、ほとんど。
ヘッダファイルの考え方が違うのかな…

>>362
規定が無い点について理解しました。
確かにうちのプロジェクトのソースはビルド時間かなりかかるんです…
.cpp で書くと分割コンパイルされて速度が向上するということですね。
まったく知りませんでした。。

まさに java チックです。
なので、include 順序がかなり大事で問題も結構起きるんですよね。
でも私個人的には、c++ で開発しているので、c++ の基本を知りたいです。

>>363
全然、そんなことないんです><
おまけに、プリコンパイルヘッダもないので時間ばかりが掛かって…


366:デフォルトの名無しさん
09/05/23 23:21:28
>>365
ヘッダに定義を全部書いたら、クラスのインタフェースに全く影響を及ぼさない
変更であっても、そのヘッダに依存するソースファイルすべてが再コンパイル
されるじゃないか。その程度も分かってない会社って一体・・・

367:デフォルトの名無しさん
09/05/23 23:22:39
>>364
インクルードガードしてもできないよ。
インクルードガードは同一翻訳単位内でしか有効ではないから。

368:デフォルトの名無しさん
09/05/23 23:25:16
>>364
そうなんですよ!!
.cpp ファイルは main 用に1つだけあって、あとは .h の処理を呼び出したり、
クラスを生成してクラスに処理を任せたり、、、
グローバル関数までもが .h に居る始末です。

>>366
まさにその通りですね。
これでも一部上場なのですが、本当にお恥ずかしいです。


369:364
09/05/23 23:25:54
>>367
いやできるでしょ。
cppが1つしかないんだぜ?
ってことは翻訳単位も(恐ろしいことだが)一つってことじゃん。

370:デフォルトの名無しさん
09/05/23 23:27:17
すでに拡張子の意味を逸脱した使い方なのはわかった

371:デフォルトの名無しさん
09/05/23 23:29:20
>>369
あぁ、そういうことか。理解したw
すごいな。

372:357
09/05/23 23:33:35
結論としては、>>370 がおっしゃっているように、
拡張子の意味を確実に逸脱しているのですね。

みなさんがおっしゃったように、リンクの意味を理解していなかったようです。
分割ビルドは十分理解できました。

今一度教えてください。みなさんは .h を基本的にどのような用途で利用されていますか?
また、現状のように .cpp を1つだけもち、ほとんどすべてを .h に置くことで発生しうる
考えられる問題がありましたら教えてください。

>>369
すみません、私は理解できませんでした。
まだ初心者であることを思い知りました。
翻訳単位が1つだと、恐ろしいものですか?時間が掛かる、という観点でしょうか。


373:369
09/05/23 23:40:35
>>372
>翻訳単位が1つだと、恐ろしいものですか?
そんな開発者見たことないから、恐ろしいと形容した。
>今一度教えてください。みなさんは .h を基本的にどのような用途で利用されていますか?
あくまで宣言だけを書いておく。
MyClassを使う必要があればMyClass.hをインクルードする。
一方MyClass.cppにもMyClass.hをインクルードしておいて、別途コンパイルしておく。
こうすることで、MyClass.cppが変更されても他の大部分のcppは再コンパイルしないで済む。
あるいはMyClass.cppをコンパイルしてライブラリとして公開する場合、
他社には.hだけを見せるわけだから実装を隠せるとか。

>また、現状のように .cpp を1つだけもち、ほとんどすべてを .h に置くことで発生しうる
>考えられる問題がありましたら教えてください。
他の会社や組織に公開する時に実装がだだ漏れになるとか


374:デフォルトの名無しさん
09/05/23 23:46:19
つか、どんな教科書で勉強したんだよ。
大概の教科書は分割の仕方書いてあるだろ^^

375:デフォルトの名無しさん
09/05/23 23:49:36
>>372
ビルドに時間が掛かって仕方がないだろう

376:357
09/05/23 23:54:38
>>323
なるほど、、、将来を見据えた設計をしながら開発してるんですね。
なんかもう、うちの会社が悩ましいです。

>>374
会社の研修では一切…
ちなみにほとんどのプロジェクトがそんな感じです。
java と COBOL 人間ばかりなので、include = そこにそのファイル内容を挿入、っていう
意味合いだけしか着目していないんだと思います。

>>375
その通りですね。勉強になりました。


今日皆さんにご指導いただいた内容を以って、会社の開発体制の改善を
促して以降と思います。
ありがとうございました。


377:デフォルトの名無しさん
09/05/23 23:55:23
まて、>>357は本当にC++を扱う一部上場企業に勤めているのか?

例えば、分割コンパイルには関係ないようなC++の問題だしても解けるか?


378:357
09/05/23 23:55:32
>>376

>>323
× >>373

379:デフォルトの名無しさん
09/05/23 23:56:27
どうせ元ABCのあそこだろ?

380:デフォルトの名無しさん
09/05/23 23:59:44
>>377
私も信じられなくなってきましたが、こんな開発者ばかりながらも、
一部上場です。

私はアセンブル系のドライバ開発あがりで、ウィザードを利用して ATL/WTL アプリケーションの
開発をやっているので、一から自分でファイルを作ってプロジェクトを構成したことがありませんでした。
20年弱もプログラミングをして来ましたが、初心者からはなかなか抜け出せませんね。

大変勉強になりました。

381:デフォルトの名無しさん
09/05/24 00:06:46
>>380
そうなのか。
じゃあもういっそC++やめて、各自が得意なCOBOLとかアセンブラやればいいのではないでしょうかね。。。

少なくとも一人、C++の知識がある人が居ないととんでもないことになるのでは。

まああなたがその一人になれば良いだけだが。
頑張ってください。

382:デフォルトの名無しさん
09/05/24 00:07:00
>>380
大丈夫。そのやり方で会社が回っているならそれで正しい。
開発の仕方に正解なんてないんだし、そもそも他と同じことをやっていたらこのご時世生き残れない。

君の会社は君の会社なりのやり方を見つけたんだと思う。だから生き残っているんだろう。
もっと、堂々としていいよ。

383:デフォルトの名無しさん
09/05/24 00:16:10
>>381
なかなか COBOL やアセンブルの案件が見つからなくなってきたんですよね。。
でも、頑張ります!ありがとうございます。

>>382
ありがとうございます。
基本をしっかり抑えた上で、スタイルを大事にして行くことにします。


384:デフォルトの名無しさん
09/05/24 00:37:07
>>380
優秀であってもドカタ企業のドカタじゃどうしよもないよ
一部上場の正社員とドカタ企業のドカタじゃ霄壌の差

385:デフォルトの名無しさん
09/05/24 02:15:34
言わなくてもわかってるからもうドカタに触れるのやめようよ
可哀想だろ俺が

386:デフォルトの名無しさん
09/05/24 02:27:32
一部上場ならお給金もそれなりでしょ
まともな本買いましょうよ


387:デフォルトの名無しさん
09/05/24 02:39:06
初心者にまともな本買えって言っても、
どれがまともな本なのかわからんでしょ
まともな本教えましょうよ

388:デフォルトの名無しさん
09/05/24 02:54:41
学生の勉強じゃない仕事の事なんだから、休みの日にでも本屋に出向いて
中を見て初心者なりでも”自分”で選ぶべきだと、俺は思う
で、幾つかの本を読破してこそ、まともな本かどうかの判断が付く脱初心者になって行くんだと思う

その最初のステップを”初心者”と言う理屈で飛ばすような奴が
プログラムの本を読んで技術力を上げていくなんて出来ないだろ

そもそも、本人が教えてと言ってるならともかく
初心者なんだから教えるべき、と言って自分は教えてない奴は好きじゃないw

389:デフォルトの名無しさん
09/05/24 02:59:18
兎にも角にも禿本は重要だよな。
特に後半の設計に関する部分を読んでない人は多いと思うけど、色々含蓄あるし。

390:デフォルトの名無しさん
09/05/24 03:02:13
俺が書いたネタレスに入魂レスとは....
ネタと分かるように語尾を>>386と同じにしたのに
釣られる奴居るんだな

391:デフォルトの名無しさん
09/05/24 03:05:39
>>388
長々と小言を言う暇があるなら、自分が薦める本を挙げればいいのに。

>>390
釣りならVIPでも行ってやれば?

392:デフォルトの名無しさん
09/05/24 03:15:54
だから最初の理解なんて人それぞれ
俺が良いと言ったって、合う合わないがある、だから教えないし、
自分でググるなり、本を手に取れって言ってるじゃん

アンタゆとり?


393:デフォルトの名無しさん
09/05/24 03:25:13
釣りに延々とマジレスしてきもいな

394:デフォルトの名無しさん
09/05/24 03:25:14
以下のプログラムがうまく行かないのですが、
解決方法を教えて下さい。

 5 class B;
 6
 7 class A{
 8  public:
 9   int hoge;
10   A(int i){ i = hoge; }
11
12   B conv(){ return B(hoge); }
13 };
14
15 class B{
16  public:
17   int hoge;
18   B(int i){ i = hoge; }
19
20   A conv(){ return A(hoge); }
21 };


-------------------

エラー
test.cpp: In member function ‘B A::conv()’:
test.cpp:12: error: return type ‘struct B’ is incomplete
test.cpp:12: error: invalid use of incomplete type ‘struct B’
test.cpp:5: error: forward declaration of ‘struct B’


395:デフォルトの名無しさん
09/05/24 04:39:09
Bの定義より後にA::convの定義を置けば上手くいく。
class B;

class A {
public:
int hoge;
    A(int i) { i = hoge; }

    B conv();
};

class B {
public:
int hoge;
    B(int i) { i = hoge; }

    A conv() { return A(hoge); }
};

B A::conv(){ return B(hoge); }

396:デフォルトの名無しさん
09/05/24 04:40:16
class B;
class A {
 ...
 B conv();
 ...
};
class B {
 ...
};

B A::conv() {
 return B(...);
}

397:デフォルトの名無しさん
09/05/24 04:45:07
>>395
>>396
ありがとうございます。


398:デフォルトの名無しさん
09/05/24 05:36:49
complexは実数、虚数にreal()、imag()でアクセスするわけですが、
この関数って参照返すだけだから、
それだったら内部の実数、虚数変数に直接アクセスした方が関数呼び出し無い分早いだろうし、
ソースコードも見やすく(多分)なると思うのですが、
これには何か理由があるのでしょうか?

399:デフォルトの名無しさん
09/05/24 08:12:11
URLリンク(ja.wikipedia.org)

400:デフォルトの名無しさん
09/05/24 10:53:54
>>398
基本的に内部の実装に触れられるようにしちゃうと
いざインターフェースは変わらないが実装が変わるような仕様変更をするときに
悲劇がおこるからとか。

401:デフォルトの名無しさん
09/05/24 14:06:24
あと、関数呼出のオーバーヘッドなんてないと思っていいよ。
それくらいコンパイラの最適化でいともたやすく消え去るられる。

402:デフォルトの名無しさん
09/05/24 14:11:10
そんなことはない
だったらなぜわざわざinlineなんて予約語が用意されてるんだ?

関数呼び出しを減らすのは高速化の基本のキだ
ウソを教えるのはやめろ

403:デフォルトの名無しさん
09/05/24 14:15:36
>>402 の年齢が気になる


404:デフォルトの名無しさん
09/05/24 14:15:42
現在は なんでもかんでもゲッタセッタ教 の勢が強いから
狂信者の戯言は聞き流して己が道を進めばいいと思うよ

405:デフォルトの名無しさん
09/05/24 14:20:59
下駄雪駄教徒だって、下駄雪駄は基本的にインライン関数にするだろう
アウトラインの下駄雪駄なんておぞましいものは狂信者でも書くわけがない

少なくとも長いループ内では、アウトライン関数を呼んではいけない
これは今も重要なガイドラインだ

406:デフォルトの名無しさん
09/05/24 15:01:18
少なくともC++でフィールド変数直接アクセスするのは
百害あって一利なしだな。

>>402
>>401が言ってるのはreal/imagの話だろ。
言葉足らずならそう指摘すればいいのに。力抜けよ。


407:デフォルトの名無しさん
09/05/24 15:05:37
URLリンク(ja.wikipedia.org)(%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6)
下の方のアクセサの項目

408:デフォルトの名無しさん
09/05/24 15:06:24
せったげったって言うけどさ

hoge.hage.foo.bar.set_value(0); とかはあったとしても
hoge.get_hage().get_foo().get_bar().set_value(0); なんてことはしないよね

この辺みんなどうしてるんだろ。
hage や foo は public なメンバにするよね?でもそれだと統一感ないよね?

409:デフォルトの名無しさん
09/05/24 15:08:19
どっちもねーよ

410:デフォルトの名無しさん
09/05/24 15:12:41
データ主体なものは構造体にしている
メンバ関数はコンストラクタ、コピー、シライライズ、ダンプ、アサートぐらいしか定義しない

それと同じ目的の変数は構造体にまとめる

class A

411:デフォルトの名無しさん
09/05/24 15:15:28
途中で送ってしまったぜ
後ろの段落は class の中で struct xxx_param とか struct xxx_item, xxx_state とかを定義して
まとめてあつかう

412:デフォルトの名無しさん
09/05/24 15:18:06
おなじくどっちもねーよ

> hoge.hage.foo
この辺までですでに内部状態の一貫性を壊していると思われ(setの場合)。
設計が悪いから作り直せ。

413:デフォルトの名無しさん
09/05/24 15:38:47
え?でもさ、よくしらないけど、フォームアプリなんて
System.Form.SetValue() みたいにどんどん深くなっていってない?

実モデルでたとえても、例えば
部屋A.本棚B.本C.ページD.GetText();
みたいな例は十分にありえるんじゃないの?

414:デフォルトの名無しさん
09/05/24 15:39:02
>>402は今でもregisterを使っているのだろうか。

415:デフォルトの名無しさん
09/05/24 16:02:00
せめてこうだろ
void foo::set_bar_value(int n) { bar.set_value(n); }
void hage::set_bar_value(int n) { foo.set_bar_value(n); }
void hoge::set_bar_value(int n) { hage.set_bar_value(n); }
hoge.set_bar_value(0);

俺はvector3やmatrix44みたいなのは公開してるなあ。
あとは、クラスとして独立させるほどでもないが、関連のあるメンバ変数をグループ化したいときに
structを使ってる。

416:デフォルトの名無しさん
09/05/24 16:05:06
>>413
System.Form.SetValue()
どこのC#?

あとそれ名前空間と混ざってるから。

417:デフォルトの名無しさん
09/05/24 16:13:50
でも名前空間って要するに全メンバがpublic静的なクラスのことだろ

418:デフォルトの名無しさん
09/05/24 16:21:41
>>415
それはない

419:デフォルトの名無しさん
09/05/24 16:38:05
しょぼい設計でなければ
名前空間で内部状態を壊されることはないから問題ない。

420:デフォルトの名無しさん
09/05/24 17:11:46
class A{
  B* get();
}

というクラスで、get()メソッドをインライン関数にしたい
テンプレートクラスと同様に同じヘッダファイルに実装を書く場合、
inline B* A::get(){
  コード
}
の「inline」は意味があるのでしょうか?

421:デフォルトの名無しさん
09/05/24 17:15:11
ない
というか意味があるかないかで言うなら、inlineは常に意味がない
コンパイラは自由にインライン化要請を無視できるし、要請されてない関数をインライン化することが出来る

422:デフォルトの名無しさん
09/05/24 17:25:36
規格上はそうだが、一応現実的には意味はあるから、意味なしと言い切ってしまうのは誤解を招くのでは。
例えば俺が使っているコンパイラは「inline指定に従う/無視する」「inline指定がなくても勝手にinline化する/しない」
などの指示を自分で出すことができる。

423:422
09/05/24 17:26:22
もちろん環境依存の話だから、詳しくは「自分が使ってるコンパイラについて調べてね」ってことだけど。

424:デフォルトの名無しさん
09/05/24 17:33:39
inlineは、コンパイラの最適化云々ではなく、
ヘッダに直接(= インラインで)定義するぞ、という意味だと思えばいい。

425:デフォルトの名無しさん
09/05/24 17:53:20
>>424
変な誤解を生むから詳しく知らないなら
黙ってるか断定的に書くな。

426:デフォルトの名無しさん
09/05/24 18:02:20
>>424
適当なこと書くなよ。
cppファイルにてもinlineは書けるわけだし
もう何が何なのかw


427:デフォルトの名無しさん
09/05/24 18:05:30
>>424
インラインに”ヘッダに直接”という意味があったなんて白なkったおれはどうすればいい?

428:デフォルトの名無しさん
09/05/24 18:06:30
 "C++" "ヘッダに直接" "インライン"の検索結果 5 件中 1 - 5 件目 (0.33 秒)

429:426
09/05/24 18:08:40
>>428
よくやったwww

430:デフォルトの名無しさん
09/05/24 18:35:56
ところで>>420でinlineを付けなかったらリンカエラーにならない?
そういう意味でinlineはいると思うんだけど。

431:デフォルトの名無しさん
09/05/24 18:37:06
んなわけない。

432:デフォルトの名無しさん
09/05/24 18:38:13
>>430
よくわからないけどオブジェクトコードにクロージャっぽいのがつくられるきがするぅ

433:デフォルトの名無しさん
09/05/24 18:53:52
int DLLAPI (*mcOpenDevice ) (void) = NULL;

あるDLLについてたヘッダ内の記載なんですがVCで「構文エラー : '('」が出ます
カッコの数は合ってるし、関数ポインタの宣言としてもおかしくないように見えるのですが
詳しい方から見て何か違和感はありますでしょうか?

ちなみに #define DLLAPI WINAPI されてます

434:デフォルトの名無しさん
09/05/24 18:55:29
ん、俺の環境(gcc 3.4.5)だと、ヘッダファイルのクラス定義内部じゃないところにinlineがついてない関数定義があって
それを複数の翻訳単位でインクルードしてコンパイルしてリンクすると、多重定義エラーでるなぁ。

435:デフォルトの名無しさん
09/05/24 18:56:14
問題ないと思う
多分その直前に何かおかしい所がありそう

436:デフォルトの名無しさん
09/05/24 18:58:40
WINAPIを関数名と勘違いしちゃったんだろうな。

437:デフォルトの名無しさん
09/05/24 19:02:20
>>435 ありがとうございます
自分の作ったのでも結構悩むのに、さらに人の作ったのだと難度高いです・・・
もうちょっと見直してきます

438:デフォルトの名無しさん
09/05/24 19:18:02
プリプロセスだけ通してみるとか

439:デフォルトの名無しさん
09/05/24 19:19:27
先に<windows.h>をインクルードしたらいいと思う。

440:デフォルトの名無しさん
09/05/24 19:30:27
>>438
プリプロセッサ以外の記述を削除ってことですか?

>>439
<windows.h>とかメジャー系はいくつか試したんですがダメでした・・・

441:433
09/05/24 19:35:13
>>433のはMCRWwinというツールのです
URLリンク(www.geocities.jp)

どなたかVC使いの方でビルド通るか実験して頂ける方はおりますでしょうか
最近入れなおしたので、私のVCの設定が悪いのかもしれない

442:デフォルトの名無しさん
09/05/24 19:37:14
とりあえず
#define WINAPI

#define WINAPI __stdcall
って書いとけ。


443:433
09/05/24 19:52:22
>>438
すんません、勘違いしてました
/E /Pで.i吐かせて該当行見ましたら

int __stdcall (*mcOpenDevice ) (void) = ((void *)0);
と展開されてました、他の箇所も見た感じ悪くはなさげなのです

444:デフォルトの名無しさん
09/05/24 20:09:04
>>443
おお、それはエラーになる。
int (DLLAPI *mcOpenDevice)(void) = NULL;としてみるんだ。

URLリンク(msdn.microsoft.com)
一番最後のExampleでもそうなっている。

445:420
09/05/24 20:19:30
>>421-434
VC++2003を使っていて、今のところ1つのcppファイルからしかインクルードしてないので
inlineを付けても付けなくても問題はなかったのですが、
付けないとcppファイル毎に関数が定義されているとみなされる=>>430>>434
ということなんでしょうね。
どうもありがとうございました。

446:433
09/05/24 20:19:42
>>444
ありがとうございます、無事ビルド通りました
>>436さんも多分同じこと指摘してくれてたんですよね、分からなくて申し訳ないです

みなさんのおかげで先に進めそうです
本当にありがとうございました。

447:デフォルトの名無しさん
09/05/24 21:06:14
超初心者ですがコンパイラ何使ったらいでしょう?

448:デフォルトの名無しさん
09/05/24 21:06:41
gcc

449:デフォルトの名無しさん
09/05/24 21:09:35
書き忘れました
windowsで使えるものをお願いします

450:デフォルトの名無しさん
09/05/24 21:10:55
>>448
よくわからないのでとりあえずぐぐってみます
ありがとうございます

451:デフォルトの名無しさん
09/05/24 21:13:22
>450
WinならMinGW
まあgccなんだけどな

452:デフォルトの名無しさん
09/05/24 21:13:37
>>447
Visual C++ Express 2008

URLリンク(www.microsoft.com)

453:デフォルトの名無しさん
09/05/24 21:15:33
>>451-452
レスありがとうございます

454:デフォルトの名無しさん
09/05/24 21:35:25
Toubo C++

455:デフォルトの名無しさん
09/05/25 01:23:27
>>454
初めて聞いた。
そしてググってみてちょっと面白かった。

456:デフォルトの名無しさん
09/05/25 01:28:58
7件しかヒットしないぞ?
しかも全部中国。

457:デフォルトの名無しさん
09/05/25 02:44:48
昔はTurboCといえば、M$としのぎを削った人気コンパイラだったのだよ。

458:デフォルトの名無しさん
09/05/25 04:02:59
いやTouboだし。

459:デフォルトの名無しさん
09/05/25 05:23:12
Toubo C++

検索したら漢字ばっかで
いじる勇気がでない。

460:デフォルトの名無しさん
09/05/25 06:40:45
JIS X3014 6.6.3 return の 2 の最終行、「未定」が「末定」になってるw

461:デフォルトの名無しさん
09/05/25 07:46:16
しばらくVBAばっかりいじってたから、C++のウィンドウの扱いが面倒に思えて困る

いつもVCの空のプロジェクトにダイアログリソース突っ込んで出してるんだが
ひょっとして空のプロジェクト使わなければC#とかみたいに簡単に扱えるのかな?
空じゃないプロジェクトって最初からコードいっぱい書いてて抵抗あったから今まで触ったこと無いんだ

462:デフォルトの名無しさん
09/05/25 07:48:25
スレ違いすぎるだろ…

463:デフォルトの名無しさん
09/05/25 08:31:50
>>461
vcでポトペタできるのはダイアログだけだよ
ウィンドウはムリポ
スケルトンコードは慣れかな
どうせ似たようなコード書くんだし

続きはVSスレかWinAPIスレかMFCスレで

464:デフォルトの名無しさん
09/05/25 08:46:11
461です、スレ違いすまんかった
覗いてみた感じここの奴は視野が広そうだったから、ここで聞いてしまった

数年前に比べて大して便利になってないという事だな
昔作ったスケルトン掃除して使ってみるよ、ありがとう

465:デフォルトの名無しさん
09/05/25 19:30:32
blitz::Arrayって何を意味してる? ググってもわからんかった

466:デフォルトの名無しさん
09/05/25 19:46:06
>>465
C++の言語に関する話としては
blitzというクラスの、Arrayというメンバ。もしくは、blitzという名前空間に含まれる Array というもの。

実際ぐぐってみたところ、Blitz++というライブラリがあるみたいだね。
このライブラリでblitzという名前空間を使っているようだ。

467:466
09/05/25 19:47:15
英語が苦手で無いなら以下をどうぞ。
URLリンク(www.oonumerics.org)

468:デフォルトの名無しさん
09/05/25 20:11:46
>>467
回答どうも 軽く読んでみた。
じゃあどうやら 『blitz::Array< int, 2 > A 』 って宣言だと
『中に整数値の入る2次元の行列式の定義をbiltzっていう名前空間でやってる』って感じでいいのかね
Arrayは直訳で行列じゃなくて配列なのが気になるんだけどね・・・

469:デフォルトの名無しさん
09/05/25 20:15:59
>>468
細かいとこちょっと違うけど概ねそんな感じ。

470:デフォルトの名無しさん
09/05/25 20:21:33
>>469
ごめん Cは前々からやってたんだけどC++は最近独学で始めたばっかりなんだわ…
で、違うところって? (俺の知識が浅いから、伝わらなそうだったらスルーしてくれ)

471:デフォルトの名無しさん
09/05/25 20:24:23
>>470
ごめん、ちょっと忙しくなるから、後でまた来るわ
そのときまでに他のレスがついてなかったら書くよ

472:471
09/05/25 21:07:14
まず、blitz::Array そのものは blitz名前空間の中に入ってるが、
blitz::Array< int, 2 > A;
とした場合、(これ自体をblitz名前空間の中に書かない限り)このAはblitz名前空間には入らない。

あと、「行列式」じゃなくて「行列」だな。(似てるけど意味が違う)

473:デフォルトの名無しさん
09/05/25 21:10:27
行列式でいいだろ
行列を表すexpressionなんだから

determinantのことを言いたいなら、それは揚げ足取りと言うものだ
感心しない

474:デフォルトの名無しさん
09/05/25 21:10:55
C++始めたばかりなら名前空間をよく分かってないかもしれんが
まあ、ちょっと語弊があるけど “blitz::Array<int,2>” で1つのクラス名だと思ってしまってもよい。
int a;
がint型の変数aであるのと同じように
blitz::Array<int,2> a;
は blitz::Array<int,2> 型の変数aだ。

名前空間ってのは、例えばライブラリ作成者がArrayっていう名前のものを提供している場合、
利用者のコードにもArrayってのがあると名前が衝突してしまって不都合だから、
名前がぶつからないように blitz:: という修飾をつけてるんだと思えばよい。

475:デフォルトの名無しさん
09/05/25 21:12:06
>>473
そうか? 俺はどうしても気になるし明確に誤りだと思うが、まあ揚げ足取りと取られるならこれ以上は言うまい。

476:デフォルトの名無しさん
09/05/25 21:14:04
>>473
アホだろお前。

477:デフォルトの名無しさん
09/05/25 21:55:28
行列式は駄目でしょ

478:470
09/05/25 22:04:48
なんか複数人からレスもらってるみたいで、皆さんどうもありがとう
blitz::Array<int,2> 型の変数aって感じは掴めてたんだけど、そもそもblitz::Arrayは何を表現するのかが不明で困ってたのよ

それはそうとプログラム板って初めて来たけどID表示ないんだな、不便じゃない?

479:デフォルトの名無しさん
09/05/25 22:13:22
>>476
そういう言い方はたとえ2chでもどうかと思うぞ

まぁでも
行列と行列式は…何と何くらい違うんだろ。ブドウとグレープフルーツくらい?

480:デフォルトの名無しさん
09/05/25 22:16:39
>>478
スクリプト書けばID丸わかりだから不便じゃないよ。

481:デフォルトの名無しさん
09/05/25 22:53:31
IDが分からなくても別に不便を感じたことない。

482:デフォルトの名無しさん
09/05/25 23:01:25
Win32APIスレはなりすましで大変なことに…

483:デフォルトの名無しさん
09/05/25 23:06:44
別に大変じゃないし

484:デフォルトの名無しさん
09/05/26 10:34:48
>>395

A(int i) { i = hoge; }

↑ は何をしたいの?

485:デフォルトの名無しさん
09/05/26 15:55:38
とてもサイズの大きなメンバ変数があったとき、
「そのメンバ変数のポインタを返すようなメンバ関数を作る」か、
「そのメンバ変数のコピーを返すようなメンバ関数を作る」か、
どちらがオブジェクト指向としてはよろしいのでしょうか?
前者だと、privateなメンバ変数に対して外部からタッチしてしまうことになりますが、
無駄が少ないように思えます。
後者だとprivateなメンバ変数を保護(?)できるというか、そういう考え方に則しているような気がしますが、
無駄にメモリを食ってしまう気がします。
完全に独学のため、ちょっと意味不明な単語が混じっているかもしれませんが、
教えてください。よろしくお願いします。

486:デフォルトの名無しさん
09/05/26 16:03:49
>>485
どちらも問題外
クラスの設計をし直せ

487:デフォルトの名無しさん
09/05/26 16:11:05
int gethoge();のような関数を作るのはよろしくないということなんでしょうか?
↑だとintのコピーを返す関数に当たると思うのですが、問題外となると、ちょっと目の前が真っ暗になってきました…。

488:デフォルトの名無しさん
09/05/26 16:49:15
privateな構造がしゃしゃり出てくるクラス設計が間違い
最初からpublicに分類すべき
それで問題が出るなら普通の人なら根本から作り直すね

489:デフォルトの名無しさん
09/05/26 16:54:31
すみません、現段階ではちょっと理解できないのですが、文献を漁ってなんとかしてみます。
貴重なアドバイスありがとうございます。

490:デフォルトの名無しさん
09/05/26 16:55:12
>>485
const なポインタ or 参照を返せば、他から変更はできないけど、
他の部分がそのオブジェクトの構造に依存することになるね

491:デフォルトの名無しさん
09/05/26 19:08:44
アクセス制御がなんのためにあるのかという根本が分かってないように見える

492:デフォルトの名無しさん
09/05/26 19:49:43
>>485
まあ要するに、

クラスのクライアント(使う人)が
privateなメンバ変数(およびprivateメンバ関数)
については何も知らなくても
publicなメンバ関数を見るだけで
使えるように設計すべき

ということだよ。
これはすなわち、public/protectedなメンバ関数以外が変わっても
クライアントが書いたコードには影響がないということ。

ちなみにpublicなメンバ変数なんて大抵はクソ設計の証。


493:デフォルトの名無しさん
09/05/26 20:06:47
485じゃないけど
>>492
それは基本的にはカプセル化に重点を置いてコードを書いた方が良い、ということで良いんでしょうか?

494:492
09/05/26 20:41:33
>>493
そう。基本的にはね。
オブジェクト指向プログラミング (OOP; object-oriented programming)
においてカプセル化はとーーっても大事。

たまにいっそ全部publicにということで構造体structを使うことがあるけど
基本的にはそういうこと。


495:デフォルトの名無しさん
09/05/26 21:29:31
なんとなく分かってきました、ありがとうございます

496:デフォルトの名無しさん
09/05/26 21:44:30
まあ現実的にはpublic変数だの参照返しも使うことはあるけどね

497:デフォルトの名無しさん
09/05/26 21:47:56
ねえよ

498:デフォルトの名無しさん
09/05/26 21:52:34
無意味な隠ぺい無意味な複スレッドは考える力が足りない人が一度はハマる道程だからね

499:492
09/05/26 21:54:08
現実にはそういう場合もあるかもしれないけど、
「良いクラス設計」の話に限った場合、フツーはない。

「全部publicにということで構造体struct」
は返り値に複数の情報を持たせたい時とかにありえる。
ただ複数の型を束ねただけ。


500:デフォルトの名無しさん
09/05/26 21:57:34
GetとSetがズラリと並んだクラスは結構見るな

501:デフォルトの名無しさん
09/05/26 22:00:53
ねえよ

502:デフォルトの名無しさん
09/05/26 22:04:41
>>500
学生の頃作ったプログラム見直してみるとGetとSet多用しててえらいことになってた
今でもうまい設計はできないけど、他で使うならpublicでいいよねって話だよな

503:デフォルトの名無しさん
09/05/26 23:46:22
Effective C++には最悪でもget()とset()用意しろって書いてあるよ^^

structでメンバ変数をpublicにするのは
>>499の言うとおり、値を束ねただけのものとして、
構造体を値として扱う場合にだけ許される。

Effective C++やC++ Coding Standards、Google Coding Standardsなんかを
ひとつも読んでいない人間はC++触らないでください

504:デフォルトの名無しさん
09/05/27 00:14:57
>>503センセー俺1つも読んだことないんですけどー

505:デフォルトの名無しさん
09/05/27 00:21:02
読むだけなら馬鹿でもできるから気にする必要無い

506:デフォルトの名無しさん
09/05/27 00:43:52
class A{
int a;
public:
int get(){return a;}
void set(int i){a = i;}
};

こういうのはさすがにpublic派のほうが多い気がする

507:デフォルトの名無しさん
09/05/27 00:53:05
宗教になぞらえられたりする理由なんだろうけど本人が気付くまで周りが何を言っても無駄なんだよね
距離を置いて厄災に巻き込まれないようにするだけ

508:デフォルトの名無しさん
09/05/27 01:15:12
>>506 が「何を」 public にするのかは知らないけど、
もし int a を public にする気なら、豆腐の角に頭をぶつけて死ねといいたい

509:デフォルトの名無しさん
09/05/27 01:27:16
メンバ変数をpublicに置くような人間は抽象化には興味ないんだろうな。
C++使う理由がないよ。多分。

510:デフォルトの名無しさん
09/05/27 01:33:51
aがクラスや配列やポインタなら全くもってその通りだがintだぜ?
こんなプリミティブなメンバまで変更しなきゃならない時にはどうせインターフェースも変更入るよ
そこまでいちいちgetset噛ませと言い出すとちょっと原理主義すぎて現実的でない

511:デフォルトの名無しさん
09/05/27 01:49:08
こういうとき、プロパティのある言語がうらやましいと思う。

512:デフォルトの名無しさん
09/05/27 01:50:40
もしgetterやsetterで参照する対象が巨大な配列やクラスだったら
重いコピーが発生する事を覚悟しなければならない

つまり巨大な配列やクラスはgetterやsetterの対象にはならない

513:デフォルトの名無しさん
09/05/27 01:55:01
>>510
返すのがintだからどうだって話じゃないだろ。たとえば
class A{
int a,b,c,d,e,f,g,h,i,j,k,l,m,n;
以下略
};
こんなのの実装をimplイディオムに変えたいと思ったときどうすんだよって話。


514:デフォルトの名無しさん
09/05/27 01:55:07
どこの世界も原理主義には付き合ってられない

515:デフォルトの名無しさん
09/05/27 02:00:14
getとsetをpublicで公開するということは、
「いつでも誰でも見ていいし好き勝手に変えてもいい『何か』を持ってますよ」ということを
外部に向けて大っぴらに公開しているということです
したがって、そのセマンティクスを変更するのはインターフェースの変更なんだから
getとsetを使っている全ての箇所に影響が出てしまいます

これってよく見ると『何か』を変数としてpublicで公開した時と状況はまったく変わりませんね
publicなgetとsetを両方用意するというのは、同じ事を回りくどく書かせるだけであって
可読性も保守性も一切上がりません

intだろうと何だろうと何でもかんでもgetsetというのは罠であり、有害な迷信です
public変数のセマンティクスを持つものはpublic変数でいいんです

516:デフォルトの名無しさん
09/05/27 02:10:14
わずかなタイプ数の増加が"現実的"でない理由って何よ?

517:デフォルトの名無しさん
09/05/27 02:13:29
privateに固執するおまえはマダマダ無能と言われてるんだよ。

518:デフォルトの名無しさん
09/05/27 02:14:45
無意味なget setで行が肥大化するのはプログラムを見づらくするだけ。
原理主義的には、カプセル化した気分に浸れていい

519:デフォルトの名無しさん
09/05/27 02:14:47
現実には、そのセッタでだた代入するだけなんてことはなくて、
たいてい、ついでにどこかに値の変更を通知したり、
入力値が範囲外なら例外投げるようにしたりしていて、
単純にメンバ変数をpublicにできる場合なんて全然ないと思うんだけど。

そんな場合の話はしていないって?

520:デフォルトの名無しさん
09/05/27 02:18:11
今回の基準は>>506だろ。ただ代入するだけ。

521:デフォルトの名無しさん
09/05/27 02:18:39
今話題に上がっているのは、ただのset get。
意味があるのは問題なし。

522:デフォルトの名無しさん
09/05/27 02:27:02
マルチスレッドから操作されるようになったので、
aを防御したくなったらどうするの?
aが頻繁に変更されるようになったので、
毎回最新の値をサーバから取得したくなったらどうするの?
aに連動してbも変更したくなったらどうするの?
正当な値だけ受け付けるようにしたくなったらどうするの?
aが更新されたことをBに通知してあげたくなったらどうするの?
将来行われる変更を全部見通すことができるの?

523:デフォルトの名無しさん
09/05/27 02:31:06
>>519
そういう色んなことをする関数は単純なsetではなく、もっと意味のある名前を付けられるはず
なんかの大きさならresizeとか、通知するんだったらnoticeとか
その相方はgetとしか言い様がないこともあるだろうけどさ

両方とも本当にget,setとしか名付けようもないようなものは、その意味合いは内部的にも外部的にも
ただのpublicメンバ変数だと思うんだけどなぁ

>>522
排他制御はともかく、他はgetXXだのsetXXだのという名前を付けるべき操作ではない

524:デフォルトの名無しさん
09/05/27 02:36:49
>>523
何を根拠に。
ちょっとした処理付きのgetXX/setXXなんて普通に使うぞ?

525:デフォルトの名無しさん
09/05/27 02:41:39
お行儀の悪いプログラムってやつだな

526:デフォルトの名無しさん
09/05/27 02:46:21
>>525
アホは黙ってろ

527:デフォルトの名無しさん
09/05/27 02:54:33
もういいからsetしようとしたら強制的に例外投げろよ

528:デフォルトの名無しさん
09/05/27 02:59:26
>>527
それもpublicメンバ変数じゃできないな。
アクセス違反がせいぜい。

529:デフォルトの名無しさん
09/05/27 03:00:35
>>524
例えば「正当な値だけ受け付ける」ようにsetXXを変更したとしようか
そうなると不当な値が入ってきたらエラーなり例外なりを返すんだろうが、
旧バージョンのsetXXを使ったコードは当然そのエラーに対応する処理をしていないので問題が起こる

つまり、この変更はインターフェースの変更であって、全てのsetXXを使用するコードに修正を迫るものであるわけだ
素直にsetXXの呼び出しを全部修正してもいいし、旧setXXとは機能が違う新setXXを(機能に見合った名前で)
新しく別に作って適宜置き換えるのでもいいが、結局はsetXXの呼び出しは全てチェックする必要がある

でも、どうせset箇所を全部見直す必要がある変更なんだから
最初からpublic変数で書いて、必要になってからset関数を書いてもまったく同じだろ?

530:デフォルトの名無しさん
09/05/27 03:05:45
>>529
確かに、エラーの追加はインターフェースの変更だ。
そこは全面同意。

でも1つしか答えてないぞ。

531:デフォルトの名無しさん
09/05/27 03:56:00
> getとsetをpublicで公開するということは、
> 「いつでも誰でも見ていいし好き勝手に変えてもいい『何か』を持ってますよ」ということを
> 外部に向けて大っぴらに公開しているということです
この認識は間違い。
getとsetをpublicで公開するということは誰でも自由に行ってもいいのはただセッタゲッタの呼び出しだけで
その結果は呼び出し側の都合ではなくクラスの都合で決定されます。
クラスの都合を無視してクラスの状態の参照や変更を行うことはできませんということをいっている。

> 例えば「正当な値だけ受け付ける」ようにsetXXを変更したとしようか
> そうなると不当な値が入ってきたらエラーなり例外なりを返すんだろうが、
> 旧バージョンのsetXXを使ったコードは当然そのエラーに対応する処理をしていないので問題が起こる
こうした場合は実装の変更ではなく仕様の変更なのでセッタゲッタによるカプセル化(=実装の隠蔽)のメリットとは無関係。


532:デフォルトの名無しさん
09/05/27 04:06:47
個人的には自由変数を1個インターフェースとして公開するごとに
そのクラスの内部設計の自由度が減るのがいやだな

あとは>>519と同じ意見でただ代入するってのはあまりない
たいていマルチスレッド用の排他処理がくっついたりする

533:デフォルトの名無しさん
09/05/27 08:09:58
メソッドとメンバしかないC++が全て悪い。

object.set_value2( object.get_value0()->get_value1() );
こう書くより、

object.value2 = object.value0->value1;
こう書いた方が、見やすいものなぁ。

534:デフォルトの名無しさん
09/05/27 08:13:32
>>533
operator =で見やすいほうの書き方にできるのでは?

535:デフォルトの名無しさん
09/05/27 08:34:48
>>533
10年前に作られた言語だからな…

>>534
できなくもないけど結構面倒だよ

536:デフォルトの名無しさん
09/05/27 08:51:13
C++知らない俺が言うのもなんだけど、set/getなんていう
低レベルのインタフェース作るのが間違ってるんだよ。
もっと抽象化された機能のメソッドを作るべき

537:デフォルトの名無しさん
09/05/27 09:24:08
>>535
>10年前に作られた言語
wikipediaによると標準化からは10年だが、C++2.0から20年、前身のC with Classesから30年のようだ
D&Eなんかで示された考え方も今では古くなりつつあるのかと思うと少し寂しくなる


538:デフォルトの名無しさん
09/05/27 09:28:03
何でさっき知ったばかりなのに寂しがってんだよw

539:デフォルトの名無しさん
09/05/27 10:04:33
>>536
get/set全てが低レベルなインターフェースとも限らないけどね
2,3行目は俺も同じ意見だ

540:デフォルトの名無しさん
09/05/27 12:02:18
結局、変数をpublicに置くような連中に何を言っても無駄ということが証明された様子。
>>515に対する反論はEffective C++にずばり書かれてる。
ちなみに、Effective C++の著者であるメイヤーは別の書物、
Effective STLの中でそういう連中とは距離を取れと書いている。
まさに>>507の予言どおりだ。

541:デフォルトの名無しさん
09/05/27 12:26:20
ところで、メンバ変数をpublicにおく場合ももちろんある。
議論の冒頭、>>499はちゃんとそういう例外事項があることを認めている。
C++ Coding Standardsの第41項でも例外事項を設けているし、
setとgetの功罪(設計の過ち)についても言及している。

だから、「原理主義」でくくるのは議論の前提を無視している。

542:デフォルトの名無しさん
09/05/27 12:36:27
C++ Coding StandardsはC++関係の本の中でも厚さが特に薄い本だが
内容は濃いな

543:デフォルトの名無しさん
09/05/27 12:54:51
wikipediaのメソッドの記事にアクセサ論争って項目があるんだな
やっぱ昔から争ってる内容なのか

544:デフォルトの名無しさん
09/05/27 13:34:11
boost::arrayはpublicにメンバ変数を置いてるけどなぁ・・・。
これもだめなのか?

545:デフォルトの名無しさん
09/05/27 15:18:29
安全性を重視するか、高速性を重視するかは、設計者に委ねられてる
どっちが正解とかいうものではない

546:デフォルトの名無しさん
09/05/27 15:31:38
ときどき「高速化するため」といって安全性をスポイルすることを正当化する人間が出てくるが
そういう人間もCoding Standardsを読むべきだな。
高速化が正当化されるには「時期」があることが説明されている。
アジャイルプラクティスとかもあわせて読んでおきたい。

547:デフォルトの名無しさん
09/05/27 15:59:17
性的な意味で

548:デフォルトの名無しさん
09/05/27 18:00:17
>>544
PODにするためだから仕方ない

549:デフォルトの名無しさん
09/05/27 22:36:05
>>545
だから詳しく知らないなら断言するなよ。

getter/setterの速度がどうとか言ってる奴は
議論に参加する資格すらないから。

550:デフォルトの名無しさん
09/05/28 00:07:33
なんじゃこりゃ。
>>485の質問からなんでこんな流れになるのかさっぱりわからん。
ここは聞かれてもいない知識をひけらかす似非回答者たちのオナニー相談室ですか?


551:デフォルトの名無しさん
09/05/28 00:07:56
はいそうです

552:デフォルトの名無しさん
09/05/28 00:25:57
>>550
申し訳ありません。
ここは質問に淡々と答えるだけの
ボランティアたちによる慈善スレでした。
以後気をつけます。


でいいですか?

553:デフォルトの名無しさん
09/05/28 00:31:45
結局 >>485 に対する解答が1つも見当たらないんだが…
そもそも質問には、public なんて単語すら全く出てきてないよ?

>とてもサイズの大きなメンバ変数があったとき、
>「そのメンバ変数のポインタを返すようなメンバ関数を作る」か、
>「そのメンバ変数のコピーを返すようなメンバ関数を作る」か、
>どちらがオブジェクト指向としてはよろしいのでしょうか?

結局どうすればいいのよこれ?俺も知りたいよ

554:デフォルトの名無しさん
09/05/28 00:40:02
たぶん、オブジェクト指向の観点からは「どうでもいい」。
実際には実行速度とかconstnessとかあるだろうが、オブジェクト指向の問題ではないかと。

555:デフォルトの名無しさん
09/05/28 00:50:44
え、まじでいいの?
質問者の書き方だと、その巨大なメンバ変数は外部からは readonly にしたいんだと思うけど、
ポインタを返すと write できちゃうってのはオブジェクト指向からすると問題なんじゃないの?
俺の理解不足なのか…すまない

556:デフォルトの名無しさん
09/05/28 01:08:45
問題な事もあれば問題でない事もある。全てのパターンに付いて書いていたらきりがない。
その場その場で最も適当(若しくは、それなりに妥当)な方法を選ぶのがC++。

557:デフォルトの名無しさん
09/05/28 01:12:23
なるほどね

オブジェクト指向的には値を返すべきだが、
実行速度が必要な場合などは、オブジェクト指向に捕らわれるよりも処理速度を優先させてもいい

的な答えだと思ってた。そうでもないのか。さんきゅー。

558:デフォルトの名無しさん
09/05/28 01:19:01
以後、大きなサイズのメンバ変数を持っているクラスをA、メンバ変数をaとする。
1. 本当にaを外部に晒す必要があるのかよく考える。
2. Aに処理を任せられないかよく考える。
3. Aの名前を変えてみて、やっぱりAに任せられないかよく考える。
4. aの要素をすべて晒す必要があるのかよく考える。

それでもだめなら、

返却するメンバ変数も安全に作られているなら、
constのポインタか参照を返すようにすればそれで十分。
呼ばれるたびに新たなオブジェクトの生成が必要なら躊躇せずコピーする。

悪意あるプログラムから保護する必要がある場合も躊躇せずコピーするが、
たいていはそれだけでは不十分だと思われ。


90点回答だ。おまいらひれ伏せ。
異論はオカマ言葉で行うこと。

559:デフォルトの名無しさん
09/05/28 01:23:50
>>558
あたしの身体はひれ伏してるのに、あたしの息子が……どうしてくれんのよ! もう!

560:デフォルトの名無しさん
09/05/28 07:46:40
>>553
>>486が答えだろ
それ以降は雑談

561:デフォルトの名無しさん
09/05/28 09:38:38
参照するだけで値はいじらせない参照ができればいいんですよね
イテレータ的なものを使うという案は出ていないようですが
この方法はそれほどスマートな解決策ではないということでしょうか

562:デフォルトの名無しさん
09/05/28 09:40:03
えっと、参照するだけで値をいじらせないなら、const参照を使えばいいわけだが。

563:デフォルトの名無しさん
09/05/28 09:41:42
>>485って、例えば
class Person{
std::string name_;
public:
std::string *name() const { return &name_;} //A
std::string name() const { return name_;} //B
const std::string &name() const { return name_;} //C
const std::string *name() const { return &name_;} //D
};
みたいなのでAにするかBにするかってことだよね。
「とてもサイズの大きな」ってのが曖昧だけど、つまりコピーにコストがかか
るものってことだろう。
つまり回答は>>490だな(C,D)。
もちろんクラスやメンバの意味が変われば>>486もあるだろうけど、頭ごなしに
「問題外」というのは何か勘違いや思い込みがあるのだろう。


564:563
09/05/28 09:43:56
ああ、constを打つクセが……
- std::string *name() const { return &name_;} //A
+ std::string *name() { return &name_;} //A


565:デフォルトの名無しさん
09/05/28 11:37:19
>>563
そうかな
俺も
「データメンバAがあったとき、それを扱うメンバ関数Bはどう作ればオブジェクト指向っぽいでしょうか」
という質問はおかしいと思う

nameの例はあくまでnameがあってこそのname_でしょ?

566:デフォルトの名無しさん
09/05/28 11:42:58
nameっていっぱい書くとなめなめみたいでいやだよね

567:デフォルトの名無しさん
09/05/28 12:22:56
なるほどね
「とてもサイズの大きな」ってのが、そもそもおかしいよな。
大きかろうが小さかろうが、オブジェクト指向な振る舞いは同じはず。

568:デフォルトの名無しさん
09/05/28 15:32:14
実用上の振る舞いに問題が出るだろう。

569:デフォルトの名無しさん
09/05/28 15:46:30
タイ米はたいて買ったのに
古米に違いが出たら
悲しいやね

570:デフォルトの名無しさん
09/05/28 16:51:43
うん

571:デフォルトの名無しさん
09/05/28 18:31:51
ふ、古米・・・

572:デフォルトの名無しさん
09/05/28 21:12:43
(環境はcygwin) Blitz++のインストールエラーについて質問。
URLリンク(island.geocities.jp) のページに従ってBlitz++をインストールしようとしたんだけど、

cygwinの場合
"blitz-0.9"フォルダで以下を実行
$ ./configure
$ make install

の最後の行のmake install をコマンドしたら、
延々インストール文流したあとにエラー吐いて止まるのよ。
で、最後のエラー文をググったら、Blitz++のメールサポートページ
URLリンク(www.oonumerics.org)
にたどり着いてどうやら俺と同じエラーみたいなんだけど、
回答者は「gccのバージョン古いんじゃねーのー?」みたいなことしか答えてない。

誰か分かるひといたら助けてくれ


573:デフォルトの名無しさん
09/05/28 22:24:39
cygwinのgccは3.45だっけ?
後何カ所止まるか想像もできないのに
全部この板で聞いて解決するつもり?

無駄な努力はやめてgccバージョンあげとけ。
あと質問の仕方の問題点について20字以内で述べなさい。

574:デフォルトの名無しさん
09/05/29 01:51:39
環境依存で標準C++に何の関係もない。スレ違い

575:デフォルトの名無しさん
09/05/29 05:03:48
Effective C++を買おうと思うんだが、原著三版ってやつで大丈夫?

576:デフォルトの名無しさん
09/05/29 05:50:52
>>575
俺はそれ買ってみた。
とても良かった。

577:デフォルトの名無しさん
09/05/29 07:09:15
vsいれたほうがいいんちゃうんかと

578:デフォルトの名無しさん
09/05/29 13:43:45
じゃあ原著vs三版買うよ
改訂2版とか言うのがあるから、どっちにしたらいいのか迷ったんだけど
発売日で比べりゃ一目瞭然だったわ
サンクス

579:デフォルトの名無しさん
09/05/29 14:37:17
俺は両方買った

というか最初改訂2版しかなくて買ったら次本屋に行ったら
第3版があって俺涙目orz

580:デフォルトの名無しさん
09/05/29 21:23:58
Visual C++ 入れたいんだけど、Express Editionてやつだと
インスコ先にDドラ指定してもCドラを800MBぐらい食うのよ(今Cドラは1.5GBぐらいしか空きない)
スリム版みたいなのってないんですかね

581:デフォルトの名無しさん
09/05/29 21:59:08
ないよ

582:デフォルトの名無しさん
09/05/29 22:00:41
ぽいね

583:デフォルトの名無しさん
09/05/29 22:01:49
Cドライブを空けろ

584:デフォルトの名無しさん
09/05/29 22:14:07
新しくプロジェクトを作った後ソースやヘッダファイルを丸々コピーしてフォルダに移した後、既成項目の追加をして同じものを作ったつもりなのですが

アプリケーション更生が正しくないためアプリケーションの開始に失敗しました
マニフェストファイルを参照してエラーの原因を調べてください

と出ます、何がおかしいのでしょうか?DXUTを使っています


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch