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

C++相談室 part69 ..

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 の最終行、「未定」が「末定」になってるｗ

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 』　って宣言だと
『中に整数値の入る２次元の行列式の定義を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
＞＞３９５

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
＞＞４８５
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 に対する解答が１つも見当たらないんだが…
そもそも質問には、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てやつだと
インスコ先にＤドラ指定してもＣドラを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を使っています

585:デフォルトの名無しさん
09/05/29 22:14:46
了解、といっても残り1GBからCCleanerかけてやっと1.5GBなんだよね・・
正直もう消すものないんだけどね　使ってない付属ソフトでも消そうかな・・・

答えてくれた人ありがとう！

586:デフォルトの名無しさん
09/05/29 22:25:14
>>585
Dドライブには空きがあるのなら、
ジャンクションやシンボリックリンク使ってDドライブにファイルを移せばいい。

587:デフォルトの名無しさん
09/05/29 23:20:46
>>586
ジャンクションやシンボリックリンクって
もしかしてXPだと無理？　ググったらなんかVistaで使用可能とかでてきたんだけど

588:デフォルトの名無しさん
09/05/29 23:37:05
マウントのことなら別にWindows 2000でも出来てたが。

589:デフォルトの名無しさん
09/05/29 23:57:22
URLﾘﾝｸ(d.hatena.ne.jp)

590:デフォルトの名無しさん
09/05/29 23:59:50
００？

591:デフォルトの名無しさん
09/05/30 00:11:10
>>587
たしかできるはずー
EeePC901で容量稼ぐためにがんばったことがあった

592:デフォルトの名無しさん
09/05/30 00:57:10
今、フリーのBCCでWindowsのコンソールのプログラム書いてたんだが、
アラインメント関係がわからない。
とりあえず、現状を書くとある大きい処理がmain関数中に埋まってたんだが、
やたら遅いから（まぁ、処理量もあるんだが）なんとなく関数化してソースの先頭に
移動させたら早くなって、アラインメントが原因だと思うんだ。

で、ものとしては
for(i = 0; i<32*32*32; i++)for(i2 = 0; i2<32*32*32; i2++);
だけなんだが、原因は何だろう？
（関数の位置なのか、変数の位置なのか。
アラインメントがどのように影響するか分からないので、
どの辺に注意したらいいかおしえてほしい）

へたくそな文章でごめんなさい。。。分かる人お願いします。

593:デフォルトの名無しさん
09/05/30 01:26:05
本当にアラインメントなのか？
map出力して確かめてみたらどうよ(bcc32なら-M)

594:デフォルトの名無しさん
09/05/30 01:49:07
>関数化してソースの先頭に
>移動させたら

レジスタ割付されただけじゃねーの

595:デフォルトの名無しさん
09/05/30 03:11:59
このスレに書くべき話題かどうか分からないのだが、static_castってかなり誤解を受けてない？
俺もいくつかの入門向けサイトを見て「暗黙の変換を明示的に書くというだけの意味しかないのかな？」
と勘違いしていたが、実際には暗黙の変換が認められないいくつかのケースでもstatic_castができる。
このことってどれくらい知られてるんだろ。

596:デフォルトの名無しさん
09/05/30 03:20:57
そうかな？俺はdynamic⇔staticで対称になってて
static_castはコンパイル時にキャストに問題がないか判断するもの、って覚えてたが

むしろ「暗黙の変換を明示的に書く」って解説してるサイトがあるのか？
それは問題がある解説に見えるなぁ

597:デフォルトの名無しさん
09/05/30 03:24:33
自分は、static_castで可能なのは暗黙の変換とその逆向き、そしてユーザ定義変換と覚えていた。

598:595
09/05/30 03:25:48
うーん、改めて見てみると、俺が初心者時代に変な思い込みしただけかもしれん。まあいいや。

599:デフォルトの名無しさん
09/05/30 08:16:34
（なんかVC++から派生してC++の話と離れてきてる感じですいません・・・）
URLﾘﾝｸ(www.forest.impress.co.jp) ここによると、
＞また、本ソフトは“ジャンクション”や“ハードリンク”なども作成可能。
＞Windows Vistaでは多くの場合、シンボリックリンク以外を利用する必要はないが、
＞Windows XP以下のバージョンのWindowsではシンボリックリンクが利用できないので、
＞これらで代用しよう。
ってあるからシンボリックリンクはだめだけどジャンクションはいいみたいです

で、つまりCドラのファイルをDドラに移して、CドラにはDドラの移転先へのリンクだけ残しておけばいい
みたいな感じでいいんでしょうかね？

600:デフォルトの名無しさん
09/05/30 09:47:49
std::vector<double> a;
std::vector<double> b = a;

この場合って、
コピーコンストラクタが呼ばれるのか、代入演算子が呼ばれるのか
コンパイラによって違うんだっけ？

どこかに書いてあった気がするんだが忘れてしまった。

601:デフォルトの名無しさん
09/05/30 10:01:08
>>600
必ずコピーコンストラクタ。

602:デフォルトの名無しさん
09/05/30 10:01:48
const_cast…cv修飾子を除去するのに使う。
reinterpret_cast…ポインタと整数型の変換に使う。
dynamic_cast…略。滅多に使わず事足りる。
static_cast…以上3つ以外

っていう認識でいるわ。

603:デフォルトの名無しさん
09/05/30 10:04:10
>>600
カンチガイしているな

std::vector<double> a;//デフォルトコンストラクタ
std::vector<double> b = a;//コピーコンストラクタ
これらは「新しいオブジェクトを作る(construct)」なのだから
呼ばれるのは両方ともconstructor。
そして呼ばれるのは当然
前者はデフォルトコンストラクタ、後者はコピーコンストラクタ。

一方、
std::vector<double> x;//デフォルトコンストラクタ
このとき
x=b;
としたら、これは新しいオブジェクトを作るわけではないのだから
代入演算子operator =
が呼ばれる。

604:デフォルトの名無しさん
09/05/30 10:15:58
>>601,603
ありがと！

605:デフォルトの名無しさん
09/05/30 15:07:01
>>602
君はキャストしない方がいい。いつか死ぬ。

606:デフォルトの名無しさん
09/05/30 15:15:03
>>605
どこが間違い？

607:デフォルトの名無しさん
09/05/30 15:27:56
>>606
>>605ではないが、禿本のキャストに関する部分を読んでこい。

608:デフォルトの名無しさん
09/05/30 15:40:16
>>607
禿本持ってないが、今度勉強してみるわ。

んで
>>605さん、>>602のどこが間違い？

609:デフォルトの名無しさん
09/05/30 15:49:27
dynamic_castを多用するようになってきたら設計ミスを疑った方がいい。

610:デフォルトの名無しさん
09/05/30 15:53:01
俺はクロスキャストの時だけdynamic_castを使っているけどな

611:デフォルトの名無しさん
09/05/30 15:54:56
やむを得ない場合もあるけど、クロスキャストを多用するのも以下略

612:デフォルトの名無しさん
09/05/30 15:58:07
クロスキャストは仮想関数では解決できないだろ

613:デフォルトの名無しさん
09/05/30 15:59:31
そういう状況が多数生まれる時点で糞設計ってことを言いたかったんだけど。

614:デフォルトの名無しさん
09/05/30 16:04:06
誰も「多数」とは言ってないわけだが

615:デフォルトの名無しさん
09/05/30 16:07:31
>>614
>そういう状況が多数生まれる
の多数ってのは
>クロスキャストを多用する
の意味なんじゃないの？
なんで分からないの？w

616:デフォルトの名無しさん
09/05/30 16:22:24
全くの初心者でお聞きしたいんですが、C++の講義ではTurboCというソフトを使って講義が進められるのですが
自宅のPCで同じことをするにはどういったソフトを使えば良いのでしょうか？
講義も全くわからずコンパイルという意味も全くわからずソフトを探すこともままなりません。どうかご教授ください。

617:デフォルトの名無しさん
09/05/30 16:22:51
誰もクロスキャストを「多用する」とは言ってないわけだが

618:デフォルトの名無しさん
09/05/30 16:26:17
>>617
は>>612と同一人物？
そうだとしたら、>>612は誰に対するレス？

619:デフォルトの名無しさん
09/05/30 16:27:30
何一人でエキサイトしてんの？

620:デフォルトの名無しさん
09/05/30 16:30:20
>>619
お前は誰に対するレス？
安価つけてくれ、分からないから。

621:デフォルトの名無しさん
09/05/30 16:32:15
>>620
断る
それ位自分で見抜け

622:デフォルトの名無しさん
09/05/30 16:34:06
>>621
いや、それを明らかにしておかないと、
俺が論破してもはぐらかされるだろ。

そういうヤツが多すぎるから、はっきりさせないと不毛な書き込みになる。

623:デフォルトの名無しさん
09/05/30 16:34:32
初めから不毛だと気づいてないのかこの馬鹿は

624:デフォルトの名無しさん
09/05/30 16:36:34
2chで議論すること自体不毛だよな。

625:デフォルトの名無しさん
09/05/30 16:41:11
まあせめてID付きの板でやるとか、コテハン付けるとかね。

626:デフォルトの名無しさん
09/05/30 16:44:20
>>622
顔真っ赤

627:デフォルトの名無しさん
09/05/30 16:47:07
>>626
鏡見て言ってるんだよね？

628:デフォルトの名無しさん
09/05/30 17:02:09
鏡？ディスプレイで十分なのに鏡？なぜに？

629:デフォルトの名無しさん
09/05/30 17:02:51
dynamic_castよりconst_castやreinterpret_castの方が多用したらまずいと思うんだけどどうだろうか
const_castなんかいまだに使いどこがわからん

630:デフォルトの名無しさん
09/05/30 17:08:12
const_castはsetの要素を変更するのに使う

631:デフォルトの名無しさん
09/05/30 17:09:15
>>630
そりゃまずいんじゃね？
木構造が壊れそうだが

632:デフォルトの名無しさん
09/05/30 17:18:40
>>629
const_castを使う主なケースは、糞なCのライブラリ関数の引数に
constな変数を渡すときだな。例を挙げるとこんな感じ。

void stupid_func(char *filename); // prototype

void Foo::some_method(const std::string& filename)
{
stupid_func(const_cast<char*>(filename.c_str()));
}

633:デフォルトの名無しさん
09/05/30 17:22:24
>>631
もちろん比較に影響及ぼすような変更はダメだぞ
構造体とかを入れたsetで、メンバの一つをキーに使ってるような場合があるだろう
そういう時にキー以外のメンバを変更するために使う

634:デフォルトの名無しさん
09/05/30 17:30:54
>>632
なるほど、ライブラリに渡すときなんかに使うのか
いくら糞でもライブラリ側を修正するわけにいかないもんな

635:デフォルトの名無しさん
09/05/30 17:55:27
volatile、組み込みでは見かけるがそれ以外では見かけたことがないんだが
おまいらはvolatileってどんな時(除く組み込み用途)使っている？
あと、const_castでvolatileを取るとる時ってどんな時？

636:デフォルトの名無しさん
09/05/30 17:55:44
>>633
俺はそういうのはmutableでやるなぁ。
const_castでやると、keyも含めて全て変更可能な「状態」になってしまうし。

637:デフォルトの名無しさん
09/05/30 18:09:49
>>583
aliceとかいう名前の開発ツールがたくさん入ってるから㍉

638:デフォルトの名無しさん
09/05/30 18:27:09
>>635
デバイスドライバを書く時には当然使う必要あるよね。

あとは、インラインアセンブリでローカル変数を上書きする時とか。
こんなことめったにやらないが。

639:デフォルトの名無しさん
09/05/30 18:48:24
>>636
mutableにすると、本当にキー以外もconstにしたいときに困るだろう
あくまでsetに入れたときの制約であって、そのためにmutableにするのは乱暴すぎる

640:デフォルトの名無しさん
09/05/30 19:11:35
キーがあるようなのはmapを使うなぁ
setの要素を変更とかやったことないな
今度やってみるか

641:デフォルトの名無しさん
09/05/30 21:11:30
>>635
VC++ではマルチスレッド対策の効果を独自に付加している。
URLﾘﾝｸ(msdn.microsoft.com)
Unixだとマルチスレッドでvolatileなんて使うなボケらしいが。

const_castで外したくなる状況は分からない。

642:デフォルトの名無しさん
09/05/30 22:40:15
誰も答えてやらない>>616のために
Visual C++ Express Editionでぐぐれ

643:デフォルトの名無しさん
09/05/30 22:44:10
Visual C++ Express Editionを知った後にTurbo Cを使うなんて、、、地獄だ。。

644:デフォルトの名無しさん
09/05/30 22:45:14
>>638, >>641
どうも、ほとんどアプリ系じゃ使わんということですな

>>641 の例じゃ普通はmutexやクリティカルセクション使うんじゃないの
それでvolatileを使うメリットがよく分らん,orz. コードが簡単になるがメリット？

645:デフォルトの名無しさん
09/05/30 23:24:24
Effective C++でconst_castはoperator[]の定義で使うことがあるみたいに書いてあったよね？
URLﾘﾝｸ(ritaz.blog64.fc2.com)
より引用。

class sample
{
public:
...;
const char& operator[](unsigned int position) const
{
...;
return dat[position];
}
char& operator[](unsigned int position)
{
return const_cast<char&>(static_cast<const sample&>(*this)[position]);
}
...;
};

646:デフォルトの名無しさん
09/05/30 23:32:43
>>645
blogにも書いてあるが、やりすぎな工夫の一例だな

647:デフォルトの名無しさん
09/05/30 23:44:12
>>644
どちらかというと、そういう排他制御の仕組みを自分で作るときに使う。

例えば下のコードをコンパイラが最適化した結果、
ロック確保する前や解放した後にhogeへ読み書きするコードが生成されたらシャレにならない。
MS仕様では、volatileなデータに読み書きするとそこを境界として、それより前後に読み書き処理が
ずらされないように最適化を抑えると言っている。

void f(hoge_t* hoge) //hogeを使うには排他制御でロックが必要とする
{
// ...
ロック確保

hogeを使う

ロック解放
// ...
}

648:デフォルトの名無しさん
09/05/30 23:48:16
>ロック確保する前や解放した後にhogeへ読み書きするコードが生成されたらシャレにならない。

意味が分からん。

最適化によって、「hogeを使う」に相当するコードが、「ロック確保」の前や「ロック解放」の後に配置されたらシャレにならないってこと？

649:デフォルトの名無しさん
09/05/30 23:50:52
>>648
ああ、ごめん。そういうこと。
携帯から打つのが面倒でいろいろ略した。

650:デフォルトの名無しさん
09/05/31 00:34:14
>>642
ありがとうございます。探してみます。

651:デフォルトの名無しさん
09/05/31 00:44:58
>>645
それ第何版の何節に書いてあるの？

652:デフォルトの名無しさん
09/05/31 01:30:20
>>644
そういう用途にも使えるってだけでWindowsでもマルチスレッドでvolatileなんて使わない
mutexなりクリティカルセクションなりInterlocked-系関数なり使えばそこでフェンス張られるし
(Interlocked-系関数でvolatile使われてるけどね。間接的には使うことになるのかな)

やっぱり組み込みとかドライバ以外で使うことはないと思うな

653:デフォルトの名無しさん
09/05/31 17:24:40
>>647, >>652
どうも、どうも

>>647
>そういう排他制御の仕組みを自分で作るときに使う
ずばり、自分でそういう仕組みは作ることないです

654:645
09/05/31 20:04:50
>>651
忘れた。
原著第3版に書いてあった。
確か、最初の方の章に。

655:デフォルトの名無しさん
09/05/31 21:20:51
改訂2版にはどこにも書いていないんだが、
第3版には本当に書いてあるのか？

第4版まであと2年はかかりそうな気がするし、
第3版買ってくるか・・・

656:645
09/05/31 21:28:28
>>655
第3版には本当に書いてある。
厳密に同じコードかどうが覚えてないが、
const版をnon-const版にて呼び出してconst_castでconst属性を外す
という方式であることは本当。
俺もそんなことして良いの！？と思ったから信じられなくても無理はない。

次ページ