[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/13 19:22 / Filesize : 243 KB / Number-of Response : 945
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++相談室 part69



1 名前:デフォルトの名無しさん mailto:sage [2009/05/04(月) 21:04:54 ]
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。

前スレ
C++相談室 part66
pc12.2ch.net/test/read.cgi/tech/1231640498/

※part63, part66 が重複していたようですので part69 としました。

486 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 16:03:49 ]
>>485
どちらも問題外
クラスの設計をし直せ

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

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

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

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

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

492 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 19:49:43 ]
>>485
まあ要するに、

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

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

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


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

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

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




495 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 21:29:31 ]
なんとなく分かってきました、ありがとうございます

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

497 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 21:47:56 ]
ねえよ

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

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

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


500 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 21:57:34 ]
GetとSetがズラリと並んだクラスは結構見るな

501 名前:デフォルトの名無しさん mailto:sage [2009/05/26(火) 22:00:53 ]
ねえよ

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

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

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

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

504 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 00:14:57 ]
>>503センセー俺1つも読んだことないんですけどー



505 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 00:21:02 ]
読むだけなら馬鹿でもできるから気にする必要無い

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

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

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

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

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

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

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

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

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

513 名前:デフォルトの名無しさん mailto:sage [2009/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 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 01:55:07 ]
どこの世界も原理主義には付き合ってられない



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

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

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

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

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

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

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

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

520 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 02:18:11 ]
今回の基準は>>506だろ。ただ代入するだけ。

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

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

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

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

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

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



525 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 02:41:39 ]
お行儀の悪いプログラムってやつだな

526 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 02:46:21 ]
>>525
アホは黙ってろ

527 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 02:54:33 ]
もういいからsetしようとしたら強制的に例外投げろよ

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

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

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

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

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

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

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

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


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

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

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

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

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

534 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 08:13:32 ]
>>533
operator =で見やすいほうの書き方にできるのでは?



535 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 08:34:48 ]
>>533
10年前に作られた言語だからな…

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

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

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


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

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

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

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

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

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

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

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



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

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

547 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 15:59:17 ]
性的な意味で

548 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 18:00:17 ]
>>544
PODにするためだから仕方ない

549 名前:デフォルトの名無しさん mailto:sage [2009/05/27(水) 22:36:05 ]
>>545
だから詳しく知らないなら断言するなよ。

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

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


551 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 00:07:56 ]
はいそうです

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


でいいですか?

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

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

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

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



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

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

557 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 01:12:23 ]
なるほどね

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

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

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

それでもだめなら、

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

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


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

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

560 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 07:46:40 ]
>>553
>>486が答えだろ
それ以降は雑談

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

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

563 名前:デフォルトの名無しさん mailto:sage [2009/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 mailto:sage [2009/05/28(木) 09:43:56 ]
ああ、constを打つクセが……
- std::string *name() const { return &name_;} //A
+ std::string *name() { return &name_;} //A




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

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

566 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 11:42:58 ]
nameっていっぱい書くとなめなめみたいでいやだよね

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

568 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 15:32:14 ]
実用上の振る舞いに問題が出るだろう。

569 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 15:46:30 ]
タイ米はたいて買ったのに
古米に違いが出たら
悲しいやね

570 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 16:51:43 ]
うん

571 名前:デフォルトの名無しさん mailto:sage [2009/05/28(木) 18:31:51 ]
ふ、古米・・・

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

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

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

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


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

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

574 名前:デフォルトの名無しさん mailto:sage [2009/05/29(金) 01:51:39 ]
環境依存で標準C++に何の関係もない。スレ違い



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

576 名前:デフォルトの名無しさん mailto:sage [2009/05/29(金) 05:50:52 ]
>>575
俺はそれ買ってみた。
とても良かった。

577 名前:デフォルトの名無しさん mailto:sage [2009/05/29(金) 07:09:15 ]
vsいれたほうがいいんちゃうんかと

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

579 名前:デフォルトの名無しさん mailto:sage [2009/05/29(金) 14:37:17 ]
俺は両方買った

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

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

581 名前:デフォルトの名無しさん mailto:sage [2009/05/29(金) 21:59:08 ]
ないよ

582 名前:デフォルトの名無しさん [2009/05/29(金) 22:00:41 ]
ぽいね

583 名前:デフォルトの名無しさん mailto:sage [2009/05/29(金) 22:01:49 ]
Cドライブを空けろ

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

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

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



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

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

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






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<243KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef