■過去ログ置き場に戻る■ 1- 前250 次250 最新50


[memo] "9999999999_00.html#R20" という感じで、URLの最後に "#RレスNo" を追加すると幸せになれます。

C++相談室 part32
501 名前:デフォルトの名無しさん :04/07/05 13:28
インラインメソッドでは普通じゃないですか?

class A
{
 int a;
public:
 A() :a(0) {
 }
}
と書くよりは


class A
{
 int a;
public:
 A() :a(0) {}
}
と書くだろうし。

OOだからGetterとかSetter書かなきゃいけないのにそんな無駄に行数増やしてもしょうがないし。
cout << ; cin >> ;の方はやりすぎ。

502 名前:デフォルトの名無しさん :04/07/05 13:32
>>500
本だとページ数を抑えるためにやったりしてるのでは?
ネットの話だと、2chは投稿に行数制限あるからせざるを得なかったり。


503 名前:デフォルトの名無しさん :04/07/05 13:51
インラインで{ }はありでも、やっぱその入出力はやりすぎですか。
ではこの本のスタイルはあまり真似しないようにします。
ありがとうございます。

もし、推奨されるスタイルのコードを閲覧できるサイトがあれば紹介してもらえないでしょうか?


504 名前:デフォルトの名無しさん :04/07/05 13:57
あー、>>4からたどっていけば結構ありますね。
推奨されるスタイルかどうかはわかりませんが、見た目よさげなので参考にします。
http://www.cuj.com/code/

505 名前:デフォルトの名無しさん :04/07/05 23:22
>>501
>OOだからGetterとかSetter書かなきゃいけないのに

いらんこと書かなきゃボロが出ないのに……

506 名前:デフォルトの名無しさん :04/07/05 23:27
>>505
いらんとこに触れなきゃ、スレも荒れないかも・・・

507 名前:デフォルトの名無しさん :04/07/06 00:33
>>505 全部friendですか?

508 名前:デフォルトの名無しさん :04/07/06 00:36
>>507
いらんこと書かなきゃボロが出ないのに……


509 名前:デフォルトの名無しさん :04/07/06 00:39
>>507
「OOだから」という理由でgetter/setterを「書かなきゃいけない」というのがおかしいって話だろ。

510 名前:デフォルトの名無しさん :04/07/06 07:39
>>509
iostream系が率先して無視してることになるね。

511 名前:デフォルトの名無しさん :04/07/06 08:31
iostream系が率先して無視?

512 名前:デフォルトの名無しさん :04/07/06 08:34
>>510
どういうこと?
iostream系のgetter/setterが提供されてる理由が「OOだから」ってことか?

513 名前:510 :04/07/06 09:36
ios::flags()みたいにメンバのIn/Outが同じ名前の関数があるって意味。
ちょっと話の本題からずれてしまったみたいなので、スルーしてちょうだい。

514 名前:デフォルトの名無しさん :04/07/06 09:47
>>513 了解。

515 名前:デフォルトの名無しさん :04/07/06 15:35
char s[ 256 ];
cin >> s;

で、入力を
「a b」
とスペースを含む文にすると s に 「a」 としか読み込まれません。

この場合、s に「a b」と読み込まれるようにするにはどうすれば良いでしょうか?

516 名前:デフォルトの名無しさん :04/07/06 15:43
>>515
string s;
getline (cin, s);


517 名前:デフォルトの名無しさん :04/07/06 16:49
そのあと必要ならs.c_str()でconst char *を得られる。

518 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/07 23:33
#include <string>
#include <iostream>
namespace MyNameSpace {
class MyAbstract {
public:
  virtual ~MyAbstract(void) {};
  virtual void fooBar(void) const = 0; //1
  virtual const std::string toString(void) const { return getMark() + getName(); }; //2
protected:
  virtual const std::string getName(void) const = 0; //3
  virtual const std::string getMark(void) const = 0; //4
};
class MyImpl : public MyAbstract {
public:
  MyImpl(const std::string & name) : _name(name) {};
  virtual ~MyImpl(void) {}; //5
  virtual void fooBar(void) const { std::cout << "(^o^)" << std::endl; }; //6
protected:
  virtual inline const std::string getName(void) const { return _name; }; //7
  virtual inline const std::string getMark(void) const { return MYMARK; }; //8
private:
  const std::string _name;
  static const std::string MYMARK;
};
const std::string MyImpl::MYMARK("*");
}

519 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/07 23:33
>>518 は今ちょこちょこっと書いたものです。まあだいたいの感じだけ。

でもって質問なんですけど、あとから継承するかもしれないので
こんな風に自作クラス内のメンバ関数は全部 virtual を付けてるんですけど、
これって間違ってますか?

2 とか 7 とか 8 とか、virtual にしちゃっても問題ないんでしょうか。
こういうときは virtual をはずせ、とかいうのはありますか?

520 名前:デフォルトの名無しさん :04/07/08 00:10
>>519
> こういうときは virtual をはずせ、とかいうのはありますか?

そのクラスに仮想関数による動作がまったく必要なくて、
且つ、仮想関数テーブルの存在によって無視できない問題が発生するとき。

521 名前:デフォルトの名無しさん :04/07/08 00:19
>virtual inline
ってあるけど仮想関数はinline展開されねーぞ

522 名前:デフォルトの名無しさん :04/07/08 00:22
>>521
されるよ。

523 名前:デフォルトの名無しさん :04/07/08 00:25
>>522
MyImpl mi;
mi.fooBar();

と書いたときしかされないだろ。
でこんな使い方はこの場合そんなに無いだろ。
MyAbstractを定義してあるくらいだし。

524 名前:デフォルトの名無しさん :04/07/08 00:34
>>523
そりゃそうだが、知らない人が>>521を見たらそういう解釈はできないだろ。

525 名前:デフォルトの名無しさん :04/07/08 01:34
>>519
2・3・4の間でTemplate Methodパターンを成立させるつもりなら2は外す。
3と4には個別にきちんとした意味があり、
2はMyAbstractでたまたまこう実装されているだけなら外さない。
(まあtoString()ならvirtualで正しいだろう。)

7・8はvirtualと記述しなくても基底クラスの定義を受けて自動的にvirtualになる。
virtualでないときにMyImplの派生クラスをつくってgetName()をオーバーライドし、
その派生クラスのオブジェクトに対してMyImpl*経由でgetName()を呼び出したときでも、
virtual扱いで派生クラスのメンバ関数が呼ばれる。


526 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/08 08:08
>>521>>523
> 仮想関数はinline展開されねーぞ

なるほどー。MyAbstract 経由で呼んだらそうなるわけですね。。

>>525
> virtualと記述しなくても基底クラスの定義を受けて自動的にvirtualになる。

それは知りませんでした。。
てっきり派生クラスで virtual を外したら virtual じゃなくなるものかと。。

C++ Primer の virtual 関連のあたりをもう一度読んでみます。
ほんじゃあ、行ってきまーす☆

527 名前:デフォルトの名無しさん :04/07/08 14:20
BCC551を使っています。
仮想関数がインライン関数になれないことは理屈でわかるのですが、
例えば

 virtual void foo() {}

このような書き方をしても、普段口うるさいBCCでさえ特に何も
文句を言ってきません。他の処理系ではどうか分からないですが、
ネット上に置かれているソースでも、結構このような書き方を
見かけます。このような書き方に対して、C++処理系がどう振舞う
べきか規格では明確に触れられているのでしょうか

528 名前:デフォルトの名無しさん :04/07/08 14:32
クラス定義中に本体を実装してもインライン展開されるとは限らない。
inline付けてもインライン展開されるとは限らない。
virtual メソッドが絶対にインライン展開されないとも限らない。

529 名前:デフォルトの名無しさん :04/07/08 14:38
>>528
そうなんですよね
インライン展開できないケースでは、BCC は丁寧に展開できない
理由まで述べて、その旨の警告を発するので、あえて出さない
のには、何か規格上の理由があるからなのだろうかと思ったので。

530 名前:デフォルトの名無しさん :04/07/08 14:40
>>527
もちろん明確に触れられている。
インライン展開が可能であれば、インライン展開しても良いし、しなくても良い。

>仮想関数がインライン関数になれないことは理屈でわかるのですが、
なれないことは無い。例えば:

class base {
 public: virtual void run() {};
};

class derived : public base {
 public: virtual void run() { if (...) base::run(); };
};

というような、ごくありがちでかつインライン展開可能な例なんかもある。

531 名前:デフォルトの名無しさん :04/07/08 14:44
ああ根本的なところで誤解してたんですね…
納得がいきました。

≫virtual メソッドが絶対にインライン展開されないとも限らない。

≫>仮想関数がインライン関数になれないことは理屈でわかるのですが、
≫なれないことは無い。

532 名前:デフォルトの名無しさん :04/07/11 01:26
hoshu

533 名前:デフォルトの名無しさん :04/07/11 04:39
プログラムを書くときUML等を使って設計していますか?
ここの住人的UMLの重要性を教えていただけません?

534 名前:デフォルトの名無しさん :04/07/11 06:34
>>533
客への納品物の一種。
紙数を稼ぐのに使う。
設計書と同様、ハッタリ。

535 名前:名無しさん@そうだ選挙に行こう :04/07/11 11:57
>>533
ユースケースは絶対に書く、
これ顧客の要望の確認でもあるので必須

536 名前:名無しさん@そうだ選挙に行こう :04/07/11 16:14
あるファイルと同じディレクトリにあるファイル全てに対して同じ操作(具体的にはテキストファイル中の
単語の出現頻度を調べる)をしたいのですが、何かいい方法はありませんか?

537 名前:名無しさん@そうだ選挙に行こう :04/07/11 16:28
boost::filesystemとかどうよ

538 名前:名無しさん@そうだ選挙に行こう :04/07/11 16:29
>>536
いい方法の基準がわからん

539 名前:名無しさん@そうだ選挙に行こう :04/07/11 16:31
思いっきり環境依存だしC++よりスクリプト書いたほうが早そうだな

540 名前:536 :04/07/11 16:40
>>537
ググってもよくわかりませんでした。すみません。
>>538
とりあえずVisual C++で作れればどんな方法でも構わないです。
>>539
やはり環境依存ですか。UNIXのシェルスクリプトなら少しは書けるから、
できればそちらでやりたいんですけど、VC++でWindows用に作るように言われてまして…

541 名前:名無しさん@そうだ選挙に行こう :04/07/11 16:40
リナならシェルスクリプトで簡単に書けるな

542 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 20:38
Singleton パターンを使いたいんですけど、
static MyClass * getSingleton() で
static MyClass * m_inst を返すようにすると、
だれも delete する人がいませんよね?

static void deleteSingleton() とか作って
使った人が自分で消すようにしちゃうと、
じゃあ他の人が使ってたらどうするの?
ってことになっちゃうし・・・

参照カウンタとか shared_ptr とか使わないと
まともな Singleton 実装はできないんでしょうか?

それともプログラム実行中はずっと生かしておくのが
普通の使い方なんでしょうか?

酒が入ってるのでうまく伝わらないかも知れませんが、
よろしくね♪ 以上、高卒童貞22歳サラリーマンでした☆

543 名前:デフォルトの名無しさん :04/07/11 20:53
>>542
参照カウンタはシングルトンに使えない。

{
SmartPtr p=Singleton::inst();
p->foo();
}

{
SmartPtr p=Singleton::inst();
p->bar();
}

こういう使い方されたら生成->破棄->生成->破棄と忙しい。

544 名前:デフォルトの名無しさん :04/07/11 20:55
>>542
キャップがないと削除できないよね?
でも削除人をこき使っちゃうと
じゃあ削除権持ってるのと同じになるの?

たらこが削除人をうまく教育すればいいだけだろ

おめーが書いたクラスに対してはおめーがたらこだ
別に荒らされたまま放っとくのが普通の管理じゃねーべよ

545 名前:543 :04/07/11 20:56
ゴメン、やっぱ↑の嘘。聞き流して。

546 名前:デフォルトの名無しさん :04/07/11 20:59
>>542
全メンバが static で main が friend なんて見かけたことあるが・・・。

547 名前:デフォルトの名無しさん :04/07/11 21:02
>>542
逃げ方としてはvirtualなデストラクタを持つクラスを一個つくってそれを継承したシングルトンにしておく
んでもってグローバル変数で定義した後始末クラスのインスタンスにSingleton生成時に登録しておく
プログラム終了時にグローバル変数のデストラクタが呼ばれるのでそのなかでdeleteする。


548 名前:デフォルトの名無しさん :04/07/11 21:23
>>542
newしなきゃいいじゃない
static MyClass * getSingleton()
{
static MyClass instance;
return &instance;
}
じゃいかんか?
マルチスレッド対策はおくとして。

549 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 21:25
ご回答ありがとうございます!

>>543
>参照カウンタはシングルトンに使えない
>生成->破棄->生成->破棄と忙しい

理論的に使えないってわけじゃなくって
効率の問題ですよね?

漏れさんはときどきまとめて

String name = MyClass::getSingleton()->getName();
String mark = MyClass::getSingleton()->getMark();
String uhi = MyClass::getSingleton()->getUhi();

とかしたいだけなんです。。。

>>547
>プログラム終了時に

ってことなら明示的に delete する必要ってあるんでしょうか。。

まあ大したことないインスタンスだから最後まで
生き残ってたっていいんですけどー、
果たして C++ 的にそれが真っ当なことなのか
疑問だったわけです。

550 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 21:28
あ、新しいご回答を見落としてました。

>>548
C/C++ は始めたばっかりで、関数の中の static 変数なんて
使ったことありませんでした。
Singleton の実装ってそういう風にしてもいいんですか。

・・・でも結局インスタンスはプログラムの最後まで
消えないと理解していいんでしょうか。。

551 名前:デフォルトの名無しさん :04/07/11 21:31
> String name = MyClass::getSingleton()->getName();
> String mark = MyClass::getSingleton()->getMark();
> String uhi = MyClass::getSingleton()->getUhi();
> とかしたいだけなんです。。。

なんでgetSingleton()を繰り返したいの?
ローカルに参照置いてほしいなぁ。

552 名前:デフォルトの名無しさん :04/07/11 21:32
>>547
>んでもってグローバル変数で定義した後始末クラスのインスタンスにSingleton生成時に登録しておく
後始末クラスの変わりにatexit使うのものもいいかも.


553 名前:デフォルトの名無しさん :04/07/11 21:34
>>550
>>548の場合なら関数呼出時からプログラムの最後まで残る
寿命を管理したいなら明示的にcreate&destroyすればよい
寿命がいつ切れるかわからないけど切れたときにはdestroyしたいってのは
Singletonには向かないだろう

554 名前:デフォルトの名無しさん :04/07/11 22:47
Exceptionクラスの設計しているんだけど、スタック関係の設計とライン行、ファイル名の出力が上手くいかないんす。
わからないところ
 1)スタックはどこで管理するの? 個々のExceptionクラスにあったらダメだし・・・。
 今はなぜかリスト構造になってる。JavaのThrowableみたいなクラスが管理するのかなぁ?
 2)Exceptionを呼ぶ側が__LINE__とか__FILE__とか意識せずに呼び出して、あとは
 トレースかけたときに全て出力されるような実装にしたい。
教えてエロイ人。
(今はオーバーロードしてガンがってたんだけど、少しも美しくない上にこの先
Exceptionの継承先で困るだろうから・・・)

555 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 22:47
>>553
>寿命がいつ切れるかわからないけど切れたときにはdestroyしたいってのは
>Singletonには向かないだろう

ふーん、じゃあやっぱり C++ は Java には勝てないんですね。

酔っぱらってるからもう寝ちゃいます。おやすみねー♪

556 名前:554 :04/07/11 22:48
sageで質問してまった、ageます。

557 名前:デフォルトの名無しさん :04/07/11 22:49

なにをいまさら・・・

558 名前:デフォルトの名無しさん :04/07/11 22:51
>>557
なにが今更だよ。1分しか経っていないだろ。

559 名前:デフォルトの名無しさん :04/07/11 22:54

アフォハケーン

560 名前:デフォルトの名無しさん :04/07/11 22:58
ああ、>>557>>555にレスしたつもりなのか。
2chで矢印なんか使うなよ。

561 名前:デフォルトの名無しさん :04/07/11 23:02
>>553
まぁ、敢えてやるなら boost::shared_ptr とか。お勧めはしないが。

562 名前:デフォルトの名無しさん :04/07/11 23:03
Javaだって消える保証あるの?
JavaのGCは参照カウント方式って聞いたけど

563 名前:554 :04/07/11 23:06
>>562
http://www.netgene.co.jp/java/technicalTerms.html#gcAlgorithm

564 名前:デフォルトの名無しさん :04/07/11 23:09
>>562
いまどき参照カウントですかおい。

565 名前:デフォルトの名無しさん :04/07/11 23:10
>>554
スタックの管理って何するの?
ふつうのC++例外クラスを設計するときには、はスタックのことなんか意識しないよ。
あと、「トレースかけたとき」も何のことだかよくわからない。

566 名前:554 :04/07/11 23:15
>>565
まあ、実はJavaのExceptionクラスをC++に移植しようと思ってるんです。
最初は俺様設計だったんですけど、まあ勉強と言う事で。

スタックはExceptionを呼んでcatchしてまた呼んで・・・とやるときに
呼ばれたException順に分るようにする設計思想です。
「トレースかけたとき」と言うのはExceptionの種類・メッセージ・ファイル名・行の情報を
コンソールなり、デバッガなりに出力する事です。

567 名前:デフォルトの名無しさん :04/07/11 23:17
>>562
多分>>542はぼけだからJavaもよく分かってないんでしょう
コレクションされるためには
m_inst = null;
としなければならない。
そうでなければプログラムの最後まで消えない。
もしどこかでそうするなら、それはC++でdeleteを呼んでいるのと同じ。

結局Javaのほうがぼけが育ちやすいということで了。

568 名前:デフォルトの名無しさん :04/07/11 23:18
>>564
今のトレンドはなんですか?

569 名前:デフォルトの名無しさん :04/07/11 23:22
>>565
printStackTrace()とかのことっしょ。
呼出スタックはC++としては持ってないんじゃないの?
持ってるとしたら実行環境でしょう。
Javaは言語と実行環境が一体化してるからその違いを見極められんのかもしれんが。

570 名前:554 :04/07/11 23:27
>>569
そこを何とかC++に移植したいんですけど・・・(^^;
スタックの方はおそらくExceptionクラスの親クラスを作ってやる必要があることが分ってきました。

あとはファイル名・行番号出力なんですけど・・・。
オーバーロードと関数の初期引数に指定して何とかするぐらいしか思いつかない。後はマクロですか・・・?

571 名前:デフォルトの名無しさん :04/07/11 23:28
>>568
incrementalか世代別コピー

572 名前:デフォルトの名無しさん :04/07/11 23:29
>>570 あとはファイル名・行番号出力なんですけど・・・。
あきらめろ。
処理系依存なら、できる奴もあるかもしれないけど。

573 名前:デフォルトの名無しさん :04/07/11 23:32
>>572
処理系依存処理系依存ってうるせーんだよ。
てめーはCスレに逝けバーカ。

574 名前:デフォルトの名無しさん :04/07/11 23:32
class base{
public: virtual a( char c )=0;
public: a( int i );
};

class foo{
public: a( char c );
};

void main()
{
  foo f;
}

こうするとベースクラスの純粋仮想関数じゃないほうの
a( int i )が見えなくなっちゃうんだけど、どうにもならん?

575 名前:554 :04/07/11 23:34
>>572
処理系はVC++です。
かなり重要な部分なのでそう簡単に諦めれませんけど(^^;
まあ、最悪Exception投げるタイミングで__LINE__と__FILE__を記述するのか・・・(泣

576 名前:デフォルトの名無しさん :04/07/11 23:34
>>570
行番号、ファイル名を使うならマクロを使うことになるだろう。
マクロを使うことになると、派生した例外クラスをどう扱うかが問題になるだろう。

C++はJavaではないということを受け入れたほうが楽になれるだろう。

577 名前:デフォルトの名無しさん :04/07/11 23:35
>>573
お前はHSPスレに行きなさい。そこがお似合い。

578 名前:デフォルトの名無しさん :04/07/11 23:36
>>576
よくいるよな、ちょっと似てるからって継承にしたがる単純ヴァカ

579 名前:デフォルトの名無しさん :04/07/11 23:38
>>566
>スタックはExceptionを呼んでcatchしてまた呼んで・・・とやるときに
>呼ばれたException順に分るようにする設計思想です。
この部分に非常にひっかかるんだが。
それはスタックじゃなくて「発生源となったException」のほうじゃないか?
フィールド名称は忘れたが、Exceptionを引数にとるコンストラクタが関係するやつ。

580 名前:デフォルトの名無しさん :04/07/11 23:39
#define THROW(exception_type) throw exeption_type(__FILE__,__LINE__)

581 名前:デフォルトの名無しさん :04/07/11 23:39
http://www5.hokkaido-np.co.jp/sports/fs_fight/files/20040116.html

582 名前:デフォルトの名無しさん :04/07/11 23:40
>>574

  ∧ ∧     ┌─────────────
  ( ´ー`)   < ミエネーヨ
   \ <     └───/|────────
    \.\______//
      \       /
       ∪∪ ̄∪∪

何の関係もねーだろ、てりめーだヴァカ

# 言い方キツい理由わかるかな?

583 名前:デフォルトの名無しさん :04/07/11 23:41
>>580
それダメ。

584 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 23:41
まだ寝ないで小泉自民の逆転劇を見ようとしています。

>>567
>多分>>542はぼけだからJavaもよく分かってないんでしょう
>コレクションされるためには
>m_inst = null;
>としなければならない。

なるほどね! C++ (1ヶ月学習で実戦配備中) は
最後に delete しなきゃいけなくて、
Java (半年学習。実務経験なし) に比べると
マンドクサイと思ってましたが、Singleton に関しては
別に大差なかったんですね。

とにかく今は delete が嫌いでして、

try {
  array<MyClass *> uhi = createMyClasses();
  for (int i = 0, n = uhi.size(); i < n; i++) {
    uhi[i].uhirinko();
  }
} catch (...)
  for (int i = 0, n = uhi.size(); i < n; i++) {
    delete uhi[i];
  }
  throw;
}
for (int i = 0, n = uhi.size(); i < n; i++) {
  delete uhi[i];
}


585 名前:デフォルトの名無しさん :04/07/11 23:43
http://homepage.mac.com/ma_kyow/shinjo.gif

586 名前:554 :04/07/11 23:44
>>576
そうでつか・・・、まあ、地道に呼び出し側で書いておきます・・・

>>578
単純ヴァカか・・・。単純ヴァカは良いぞ。色々得するから。

>>579
それです(w
おそらくJavaではExceptionをスタックに詰めていると思われたんで。
説明下手でスマソ。

587 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 23:44
あ、途中で書き込んでしまった。

>>584 とかみたいに書かなくて済むようにするために
デストラクタで for ... { delete uhi[i]; } する
MyArray を作って

MyArray<MyClass *> uhi = createMyClasses();
for (int i = 0, n = uhi.size(); i < n; i++) {
  uhi[i].uhirinko();
}

コードをこれだけに抑えてたりしてるんですけどね。
あとは boostとか使えないから auto_ptr だけ自作したりもしてます。

ほんじゃあ、今度こそおやすみね〜♪

588 名前:デフォルトの名無しさん :04/07/11 23:45
>>584
そういうときはスマートポインタかなんか使ってくれ。
普通のC++使いから見たら身の毛がよだつぞ。
なんのためにデストラクタがあるか考えてくれ。

589 名前:588 :04/07/11 23:46
>>587
してんのかよ!

590 名前:デフォルトの名無しさん :04/07/11 23:46
auto_ptr。。。

591 名前:デフォルトの名無しさん :04/07/11 23:50
>>582
記述ミスくらい許したれよ

usingでどうにかならんかったっけか?

592 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 23:50
>>590
なんか文句でも?

shared_ptr なんて高級なもんは作れねーよ、バーロー!

明日から会社かー、もういやだよー。

593 名前:デフォルトの名無しさん :04/07/11 23:50
>>584
そのdeleteは使えねーだろ

594 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 23:51
あ、うそうそ。>>592は取り消します。
みんな忘れてね。ほんじゃあ、おやすみね〜♪(三回目)

595 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 23:52
>>593
あー、ちょっと間違えただけ。
ほんとは try の前で array だけ宣言してるの。。

596 名前:デフォルトの名無しさん :04/07/11 23:52
>>592
辞めちまえ。楽になるぞ♪

597 名前:デフォルトの名無しさん :04/07/11 23:54
>>592
そのaut_ptrはコンテナにいれるんだぞ。
約束だぞ(はぁと

598 名前:デフォルトの名無しさん :04/07/11 23:56
>>591
記述ミスは許してるよ
記述ミスに至る過程を責めている

599 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/11 23:57
>>597
コンテナってなあに?【ピュア】(←古っ!)

600 名前:デフォルトの名無しさん :04/07/11 23:59
vectorやmapとか

601 名前:デフォルトの名無しさん :04/07/12 00:00
>>599
中華がよく入ってる奴

602 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/12 00:01
>>600
あそっか。

てか、>>597の意味がまだ理解できないのは
漏れの脳みそが非可逆的に腐っているからでしょうか。。
可逆も何も元からという説もありますが、、、

だれか教えてね(はぁと

603 名前:デフォルトの名無しさん :04/07/12 00:05
いつになったら去ってくれるんだろう・・・

604 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/12 00:06
>>603
もうちょっとだけ!
>>597の意味が分からないと気になって
眠れなくて明日会社に行けません。

よろしくお願いします!!

605 名前:デフォルトの名無しさん :04/07/12 00:08
>>604
だ、か、ら、>>596 (はぁと

606 名前:デフォルトの名無しさん :04/07/12 00:09
MyArray< std::auto_ptr<MyClass> > uhi;
つーことだな

607 名前:デフォルトの名無しさん :04/07/12 00:09
落とし穴があるから気をつけて使わないとハマるな。

608 名前:デフォルトの名無しさん :04/07/12 00:11
>>604
C++標準化委員会が不正としている
詳しくはEfffective STL を嫁

609 名前:(・∀・)ニヤニヤ ◆SKjzm2Ah6. :04/07/12 00:14
>>605
うひ〜ん。だってPCと洗濯乾燥機のリボ払いが残ってるんだもん。。。

>>606
漏れには↓を読んでもよく分からないんですけど、それって
http://homepage1.nifty.com/munepi/articles/20020826.html
で否定されてることじゃなくて・・・?

>>608
何を不正としているんですか?

てか、このスレでだけは嫌われないようにしようとしてたんですが、
お酒を飲んだせいで本性が出てしまいました。ごめんなさい。
今夜限り (part32には) 来ませんから許してね♪

610 名前:デフォルトの名無しさん :04/07/12 00:15
こいつ((・∀・)ニヤニヤ ◆SKjzm2Ah6.)が言ってる「auto_ptr」は自作のやつだからな〜。
そのギャグは通じんかもしれん。

参照カウンタとか上手く使ってれば耐えられるだろうな。
STLのコピーのセマンティクスを理解してるかどうかが鍵。あとauto_ptrのそれと。

611 名前:デフォルトの名無しさん :04/07/12 00:22
>>575
スタックフレームポインタを最適化で消さないこと前提なら、%ebp レジスタから
スタックフレームアドレスを順に取り出していき、スタック先頭までさかのぼる。
で、あとはデバッグ用のシンボルテーブルファイルと照らし合わせて解析。

っつーか VC 使うなら、デバッガの機能使えば自前で書く必要ないはずだが。

612 名前:デフォルトの名無しさん :04/07/12 00:22
自分は自作の参照カウンタつきポインタ使ってるけど、auto_ptr使ってる奴の気がしれん。
あんなのスコープ内でしか使えないじゃない(実質的に)

613 名前:デフォルトの名無しさん :04/07/12 00:33
ソース関数から所有権もらうときとか,
シンク関数へ所有権放り投げるときとか使いません?
(というかそういう所有権が移動する使い方を本来想定しているはず・・・多分)
スコープで自動deleteして欲しいだけなら
それこそscoped_ptrってそのまんまの名前のヤツがboostに・・・

614 名前:デフォルトの名無しさん :04/07/12 00:39
>613
基本的にすべてオブジェクト作るときに参照カウントにぶっこんでたんで、その辺は普段まったく気にしないで使ってた。
し気にしないで使えてる。

615 名前:デフォルトの名無しさん :04/07/12 00:50
参照カウントあるならそれで全然問題無しですねぇ・・・
やっぱauto_ptrは不要って思っている人多いのかな?

616 名前:JavaLikeExceptionBase.hpp :04/07/12 00:51
#include <exception>
#include <iosfwd>

#include "boost/shared_ptr.hpp"

class JavaLikeExceptionBase : public std::exception
{
public:
  typedef boost::shared_ptr< std::exception > native_type;

  JavaLikeExceptionBase( native_type native , char const file[] , int line );
  JavaLikeExceptionBase( native_type native , char const file[] , int line , JavaLikeExceptionBase const& wrapping );
  ~JavaLikeExceptionBase() throw();

  virtual char const* what() const throw();
  void trace( std::ostream& out ) const;

private:
  native_type m_native;
  char const* m_file;
  int m_line;
  boost::shared_ptr< JavaLikeExceptionBase > m_wrapping;
};

617 名前:JavaLikeExceptionBase.cpp :04/07/12 00:53
#include "JavaLikeExceptionBase.hpp"

#include <ostream>

JavaLikeExceptionBase::JavaLikeExceptionBase( native_type native , char const file[] , int line )
: m_native( native ) , m_file( file ) , m_line( line ) , m_wrapping()
{
}

JavaLikeExceptionBase::JavaLikeExceptionBase( native_type native , char const file[] , int line , JavaLikeExceptionBase const& wrapping )
: m_native( native ) , m_file( file ) , m_line( line )
, m_wrapping( new JavaLikeExceptionBase( wrapping ) )
{
}

JavaLikeExceptionBase::~JavaLikeExceptionBase() throw()
{
}

char const* JavaLikeExceptionBase::what() const throw()
{
  return m_native->what();
}

void JavaLikeExceptionBase::trace( std::ostream& out ) const
{
  out << m_file << "(" << m_line << "): " << what() << std::endl;
  if( m_wrapping ) m_wrapping->trace( out );
}


618 名前:デフォルトの名無しさん :04/07/12 00:53
scoped_ptr代わりにしか使わないな>auto_ptr


619 名前:JavaLikeException.hpp :04/07/12 00:54
#include "JavaLikeExceptionBase.hpp"

template< typename CplusplusException >
class JavaLikeException : public JavaLikeExceptionBase
{
public:
  JavaLikeException( JavaLikeExceptionBase const& base ) : JavaLikeExceptionBase( base ) {}
};

template< typename CplusplusException >
JavaLikeException< CplusplusException >
makeJavaLikeException( CplusplusException* native , char const file[] , int line )
{
  boost::shared_ptr< std::exception > const safe( native );
  return JavaLikeException< CplusplusException >( JavaLikeExceptionBase( safe , file , line ) );
}

template< typename CplusplusException >
JavaLikeException< CplusplusException >
makeJavaLikeException( CplusplusException* native , char const file[] , int line , JavaLikeExceptionBase const& wrapping )
{
  boost::shared_ptr< std::exception > const safe( native );
  return JavaLikeException< CplusplusException >( JavaLikeExceptionBase( safe , file , line , wrapping ) );
}

#define THROW_JAVA_LIKE_EXCEPTION( newCplusplusExceotion ) \
  throw makeJavaLikeException( newCplusplusExceotion , __FILE__ , __LINE__ )
#define RETHROW_JAVA_LIKE_EXCEPTION( newCplusplusExceotion , wrappedJavaLikeException ) \
  throw makeJavaLikeException( newCplusplusExceotion , __FILE__ , __LINE__ , wrappedJavaLikeException )


620 名前:デフォルトの名無しさん :04/07/12 00:55
#include <exception>
#include <stdexcept>
#include <iostream>

#include "JavaLikeException.hpp"

int main()
{
  try
  {
    try
    {
      THROW_JAVA_LIKE_EXCEPTION( new std::runtime_error( "origin" ) );
    }
    catch( JavaLikeException< std::runtime_error > e )
    {
      RETHROW_JAVA_LIKE_EXCEPTION( new std::runtime_error( "wrap" ) , e );
    }
  }
  catch( JavaLikeExceptionBase e )
  {
    e.trace( std::cerr );
  }
}


621 名前:620 :04/07/12 00:56
むしゃくしゃしてやった。
別にJavaっぽくなくてもよかった。
今は反省している。

622 名前:デフォルトの名無しさん :04/07/12 00:56
>JavaLike
スレ違い
JavaでもC++でもない独自言語はスレ立てるべきでもない
自前のサーバーでやってろ

623 名前:デフォルトの名無しさん :04/07/12 00:56
例外ってconst参照で受けなくて言いの?

624 名前:デフォルトの名無しさん :04/07/12 01:02
>>623 Javaではそんなことしませんw

625 名前:デフォルトの名無しさん :04/07/12 01:04
Javaかよw

626 名前:デフォルトの名無しさん :04/07/12 01:46
>>623
参照では受けるがconstである必要はない。
回復情報や追加情報をのせて再送することも、もしかすると、あるかも知れん。

627 名前:デフォルトの名無しさん :04/07/12 09:01
参照でなくてもいいじゃん

628 名前:デフォルトの名無しさん :04/07/12 09:45
auto_ptr は関数の戻り値に使うことが多いし、
const つけて、scoped_ptr の代わりにも使う。
shred_ptr のコンストラクタに auto_ptr を受け取るものもあるし。

結構便利に使ってる。

629 名前:デフォルトの名無しさん :04/07/12 10:13
>>44
そうだよ。マナーの問題だから。

630 名前:デフォルトの名無しさん :04/07/12 16:09
>>574,591
fooに
using base:a;


631 名前:デフォルトの名無しさん :04/07/12 16:17
>>630
using base::a;


632 名前:デフォルトの名無しさん :04/07/12 16:28
class foo: public base {

633 名前:デフォルトの名無しさん :04/07/12 20:59
listとvectorってみんなどっち使ってます?
もちろん、適切な方がある場合はそっちを使うべきだけど
どっちでもいい場合はどっち使う人がおおいのかなーと。

634 名前:デフォルトの名無しさん :04/07/12 21:02
>>633
どっちでも良けりゃ配列

635 名前:deque :04/07/12 21:02
>>633
わたしゃ無視ですかい?


636 名前:デフォルトの名無しさん :04/07/12 21:20
速度面で末尾での追加削除が起こるだけでもvectorよりdequeの方が速い事実は知らない人が多い。

637 名前:デフォルトの名無しさん :04/07/12 21:23
>>636
そうなの?なんで?

638 名前:デフォルトの名無しさん :04/07/12 21:23
>>636
知らなかった。


639 名前:デフォルトの名無しさん :04/07/12 21:23
じゃあvectorって何?

640 名前:デフォルトの名無しさん :04/07/12 21:25
複数のコンテナに共通する機能しか使わないときに vector もクソもあるか ぼけ

641 名前:デフォルトの名無しさん :04/07/12 21:26
vectorの方が消費メモリが少ない事がある。
vectorはCAPIと互換性がある。

642 名前:デフォルトの名無しさん :04/07/12 21:27
>CAPIと互換性がある。
たまにcharのバッファとして使ってるの見るとちょっとびっくりする。
どうもなれないな。

643 名前:デフォルトの名無しさん :04/07/12 21:30
VC6+STLPortだと2倍くらいvectorのほうが速いよ

644 名前:デフォルトの名無しさん :04/07/12 21:32
vectorもちゃんとreserveすればdequeと変わらないよ。
要素数が予測できない時はdequeのが全然速いよ。

645 名前:デフォルトの名無しさん :04/07/12 21:44
定数オーダーでランダムアクセスしたいときと、あらかじめ個数が分かってて
明らかにコスト低そうなときしか vector は使わないな・・・


646 名前:デフォルトの名無しさん :04/07/12 21:45
dequeも定数オーダーでランダムアクセスできるよ

647 名前:デフォルトの名無しさん :04/07/12 21:47
だからコンテナくらい自分で作ってチューニングしろと。

648 名前:デフォルトの名無しさん :04/07/12 21:49
そんな無意味な事しないよ・・STLになかったらboost探すし

649 名前:デフォルトの名無しさん :04/07/12 21:54
treeコンテナも標準で付いてねえのかよC++は

650 名前:デフォルトの名無しさん :04/07/12 21:57
>>647 allocatorだけじゃなくてコンテナも自前で作るの?

651 名前:デフォルトの名無しさん :04/07/12 21:58
プロなら当然だろ

652 名前:デフォルトの名無しさん :04/07/12 21:59
コンテナなんていってないでコンパイラも作ってくださいよ

653 名前:デフォルトの名無しさん :04/07/12 22:00
スレ違いでし
「コンパイラ・スクリプトエンジン」相談室 3
http://pc5.2ch.net/test/read.cgi/tech/1070089173/

654 名前:デフォルトの名無しさん :04/07/12 22:04
現場で「オレの作ったコンテナの方がスゴイから俺コンテナを使ってくれ」
と言えればねぇ

655 名前:デフォルトの名無しさん :04/07/12 22:08
>654
問答無用で却下ですね。
俺参照カウントつきポインターは使わしてるが

656 名前:デフォルトの名無しさん :04/07/12 22:44
deque のメモリレイアウトが未だに分からないオレ。
vector 見たいに一直線に並んでるわけじゃなさそうだし…

deque の中の人は何やってるんだ?

657 名前:574 :04/07/12 23:13
>>582 きもい。

class base{
public: virtual void a( char c )=0;
public: void a( int i );
};

class foo : public base{
public: void a( char c );
};

void main()
{
  foo f;
}

これでいいか?

658 名前:デフォルトの名無しさん :04/07/12 23:17
-public: virtual void a( char c )=0;

+using base::a;

659 名前:574 :04/07/12 23:18
>>630 サンクス!

660 名前:574 :04/07/12 23:19
>>658 もサンクス!
試してみる!

661 名前:デフォルトの名無しさん :04/07/13 00:04
class A
{
// 省略
public:
template<class T>
T foo() { return reinterpret_cast<T>(hoge); }
};


A a;
a.foo<int>();

これがコンパイルできないのはVC6.0のせいですか?

662 名前:デフォルトの名無しさん :04/07/13 00:05
>>661
エラーメッセージ貼ってみな。

663 名前:661 :04/07/13 00:09
>>662
error C2062: 型 'int' は不要です。

664 名前:661 :04/07/13 00:11
失礼
>>663が出るのは a.foo<int>(); のところです。

665 名前:デフォルトの名無しさん :04/07/13 00:14
>>661
yes



666 名前:デフォルトの名無しさん :04/07/13 00:19
>>661
class A
{
// 省略
public:
template<class T>
T foo(T) { return reinterpret_cast<T>(hoge); }
};
A a;
a.foo(int ());

VC6.0持ってないんだけど
じゃだめかい?


667 名前:661 :04/07/13 00:28
>>666
fooのキャストのところで
error C2440: 'reinterpret_cast' : 'int' から 'int' に変換することはできません。
がでましたが、Cスタイルのキャストにすることで通りました。
つかintからintに変換できないなんて…
.NET欲しいです。

668 名前:デフォルトの名無しさん :04/07/13 00:47
reinterpret_castってポインタにしか使えないんじゃなかったっけ?

669 名前:デフォルトの名無しさん :04/07/13 00:58
文 reinterpret_cast< T >(arg)で は,
ポインタ,参照,算術型,関数へのポインタ,またはメンバーへのポインタでなければなりません。

ポインタは整数型に明示的に変換できます。

整数 arg はポインタに変換できます。ポインタを整数型に変換した後,
同じポインタ型に変換しなおすと結果は元の値になります。

未定義のクラスをポインタ変換あるいは参照変換で使えます。

関数へのポインタは,オブジェクトのポインタ型が関数ポインタを保持するのに必要なビットを持つ場合,
明示的にオブジェクト型へのポインタに変換できます。オブジェクト型へのポインタは,
関数のポインタ型がオブジェクトポインタを保持できる大きさである場合にのみ,
明示的に関数へのポインタに変換できます。

670 名前:666 :04/07/13 00:58
>>668
本当だ.
661にはhogeの型が書いてなかったので,
適当にprivateセクションに
int hoge;
を補ってやってた.
g++だと
reinterpret_cast <int> (double ());
はエラー出すけど,
reinterpret_cast <int> (int ());
は出さない.
668の見解だと後者はエラー出すべきなのかな?


671 名前:デフォルトの名無しさん :04/07/13 01:06
呼び出し側のテストなら
 template<class T> T foo();
で十分だろ。

672 名前:デフォルトの名無しさん :04/07/13 01:08
>>668
そんなことないよ。

673 名前:666 :04/07/13 01:13
>>661
667をみるにhogeがintなら,
そこは何故reinterpret_castなの?
static_castのような気がするんだけど.


674 名前:デフォルトの名無しさん :04/07/13 12:52
STLは今後死滅しますか?
死滅しないまでもアルゴリズム一般の勉強をしたほうがマシですか?

675 名前:デフォルトの名無しさん :04/07/13 12:53
STLの死滅とC++の死滅は同時だろうな。

676 名前:デフォルトの名無しさん :04/07/13 12:57
>>674
STLの命運はC++の命運より長い気はする。
二行目は文の接続が変じゃない?


677 名前:デフォルトの名無しさん :04/07/13 12:59
>>675
結婚と思いきや意見が分かれますね。
離婚?!


678 名前:デフォルトの名無しさん :04/07/13 13:39
void f() throw();
のthrow()って何ですか

関数の中で例外投げますよって意味?
それとも関数の中で処理しなかった例外は呼び出し元に任せますよって意味??

679 名前:デフォルトの名無しさん :04/07/13 13:40
C++では意味無いから覚えても意味無い

680 名前:デフォルトの名無しさん :04/07/13 13:44
>>678
例外投げませんよ。

681 名前:デフォルトの名無しさん :04/07/13 13:45
ありがとうございます
まるっきり逆だったのか…


682 名前:デフォルトの名無しさん :04/07/13 14:17
>>675-677
性格の不一致ですね。

683 名前:デフォルトの名無しさん :04/07/13 19:03
>>678
それを付けると例外クリーンアップコードを挿入しなくなるので速度&サイズ共に
わずかに上がるはず。しかし実際に試してみたら差がなかった。環境にもよると
思うが。組み込みに使う時は付けろ付けろとうるさい。

684 名前:デフォルトの名無しさん :04/07/13 19:29
>組み込みに使う時は付けろ付けろとうるさい。

コンパイラが?

685 名前:デフォルトの名無しさん :04/07/13 21:01
>>684
資材部だと思われ

686 名前:デフォルトの名無しさん :04/07/13 21:30
operatorの継承ってできないのでしょうか?


687 名前:デフォルトの名無しさん :04/07/13 21:33
operatorはオブジェクトじゃないからな。

688 名前:デフォルトの名無しさん :04/07/13 21:40
>>686はたぶんoperator=が継承されなくて悩んでるんだと思われ。
=は出来ないのが仕様。


689 名前:デフォルトの名無しさん :04/07/13 21:40
>>688はエスパー


690 名前:デフォルトの名無しさん :04/07/13 21:41
>>686
operator=は定義しなくてもデフォルトの関数が暗黙に定義されるよな?
それで継承したやつが隠されてるんだよ

691 名前:デフォルトの名無しさん :04/07/13 21:51
double と float ってどっちの方が高速に計算できますか?

692 名前:デフォルトの名無しさん :04/07/13 21:53
旧処理系ならdoubleの方が速いが、今はどちらも同じ
ってとこかな

693 名前:デフォルトの名無しさん :04/07/13 21:57
>>691
処理系による
処理系Aでの結果を処理系Bでの必然と錯覚するアフォが後を絶たない

694 名前:デフォルトの名無しさん :04/07/13 21:59
>>693
ソレハネタデスカ?

695 名前:デフォルトの名無しさん :04/07/13 22:01
>>683
パフォーマンスが落ちることもあるよ。「上がるはず」とは言えない。

696 名前:デフォルトの名無しさん :04/07/13 22:05
効果は同じでもfloatを引数に取る関数とfloatを引数に取る関数とがあったら
そこをちゃんと区別しないといちいち変換が掛かって効率が悪くなる。
ただしどれぐらい違ってくるかはわからないが。

697 名前:デフォルトの名無しさん :04/07/13 22:10
>>696
同じジャン

698 名前:デフォルトの名無しさん :04/07/13 22:10
>>690
隠されないようにするには?


699 名前:デフォルトの名無しさん :04/07/13 22:22
CMyClass& operator=(int i)
{
CSuperClass::operator=(i);
return *this;
}


700 名前:デフォルトの名無しさん :04/07/13 22:29
700get

701 名前:デフォルトの名無しさん :04/07/13 22:55
猫    動物    哺乳類
桃    植物
蛇    動物    爬虫類
犬    動物    哺乳類
・・・
・・・
・・・

mona.txtというファイルにこのようなTABおよび改行で
区切られた文字列が存在する場合、


a[0][0] 猫
a[0][1] 動物
a[0][2] 哺乳類
a[1][0] 桃 
a[1][1] 植物
a[2][0] 蛇
a[2][1] 動物
a[2][2] 爬虫類
・・・
・・・
・・・

のように2次元配列にするには、どうすればいいですか。

702 名前:デフォルトの名無しさん :04/07/13 22:57
>>698
strcut Derived: Base
{
using Base::operator=;
};


703 名前:デフォルトの名無しさん :04/07/13 22:58
>>701
一生懸命読み込んでください。


704 名前:デフォルトの名無しさん :04/07/13 22:59
>>701
宿題?


705 名前:デフォルトの名無しさん :04/07/13 23:21
Cでは、出力するとき、
printf("");
を使って、C++では、
cout << "" ;
を使うことを最近知ったんですが、
microsoft visual C++ 6.0を使っていたのでC++でプログラミング
していると思っていました。
けど、printfを使っています。
これはCを使っていると言うことなんでしょうか??

706 名前:デフォルトの名無しさん :04/07/13 23:26
C++はCのライブラリも使えるということはご存知?


707 名前:デフォルトの名無しさん :04/07/13 23:28
いや知らないです。
と言うことは、coutでもprintfでもつかえるということですか?

708 名前:デフォルトの名無しさん :04/07/13 23:37
>>707

double d=1.23;
printf( "%4.2f", d);

をcoutでやろうとしたらどうなるか知ってますか?

709 名前:デフォルトの名無しさん :04/07/13 23:48
すいませんよく分からないです。
ためしにやってみたけどcoutが使えなかったです。

710 名前:デフォルトの名無しさん :04/07/13 23:50
>>709
VCなら
std::cout

711 名前:デフォルトの名無しさん :04/07/14 00:03
・・・分からなかったです。

712 名前:デフォルトの名無しさん :04/07/14 00:08
実は私も知らない...orz

713 名前:デフォルトの名無しさん :04/07/14 00:13
>>708
どうやってやるんですか?

714 名前:デフォルトの名無しさん :04/07/14 00:13
拡張子

715 名前:デフォルトの名無しさん :04/07/14 00:38
double d=1.23;
char s[ 64];
sprintf( s, "%4.2f", d);
cout << s;

違うかな?
私ならはじめからprintf()使います...orz

716 名前:デフォルトの名無しさん :04/07/14 00:42
>>715
かろうじてprintf()使ってない感じで
ワロタ

717 名前:デフォルトの名無しさん :04/07/14 00:45
>>716
ちょっと狙ってはいましたが光栄です。

718 名前:デフォルトの名無しさん :04/07/14 01:02
>>708
まじめにやるとこんな感じかな(boost使う場合と使わない場合の両方で)
#include <iostream>
#include <iomanip> 
#include <boost/format.hpp>
int main(){
    double d=1.23;
    std::cout << std::fixed<<std::setw(4)<<std::setprecision(2) << d << std::endl;
    std::cout << boost::format("%4.2f\n") % d;
    return 0;
}


719 名前:デフォルトの名無しさん :04/07/14 01:09
まぁprintfマンセーということで。

720 名前:デフォルトの名無しさん :04/07/14 01:14
型安全じゃないとか、欠点も数多いが、なんだかんだ言っても、
やっぱり単純に便利なんだよprintfは。

721 名前:デフォルトの名無しさん :04/07/14 01:23
私はやっぱりprintf()使うことにします。

722 名前:デフォルトの名無しさん :04/07/14 01:33
boostなんて糞
遅すぎてつかいものにならん

723 名前:デフォルトの名無しさん :04/07/14 01:53
使いどころを見つけるのがめちゃくちゃ下手糞なんですね ;-)

724 名前:デフォルトの名無しさん :04/07/14 01:57
boostが、遅い?
・・・あぁ、リリーススケジュールのことか。

725 名前:デフォルトの名無しさん :04/07/14 02:12
稲葉さんこんばんわ

726 名前:デフォルトの名無しさん :04/07/14 02:31
boost::spiritはコンパイルが遅すぎだね。

727 名前:デフォルトの名無しさん :04/07/14 09:16
boostはどこまで巨大化していくんだろう?
10年後にはえらいことになってそうな気が。

728 名前:デフォルトの名無しさん :04/07/14 09:22
前、cppll BBS で、こんなの見つけた。

double d = 1.23;
cout << ( "d = " % _f["4.2"] )( d ) << endl;

729 名前:デフォルトの名無しさん :04/07/14 10:25
>>727
ライブラリの巨大さとバイナリ出力ファイルのサイズへの影響を誤解する馬鹿も増えてそう。

730 名前:デフォルトの名無しさん :04/07/14 11:58
そんな馬鹿が増えると心配する馬鹿は>>729だけ。

731 名前:デフォルトの名無しさん :04/07/14 15:10
や、やっぱりprintf()が最強でしゅね。

732 名前:デフォルトの名無しさん :04/07/14 15:22
>>730
現時点でも多いけどな、テンプレートの特性を知らないアフォ。

733 名前:デフォルトの名無しさん :04/07/14 15:48
export

734 名前:デフォルトの名無しさん :04/07/14 15:51
すげえ。ダイナミックリンク(ry

735 名前:デフォルトの名無しさん :04/07/14 20:05
import

736 名前:デフォルトの名無しさん :04/07/14 22:26
impo orz

737 名前:デフォルトの名無しさん :04/07/14 22:51
>>692
あとはハードウェアにもよる。PlayStation 2 なんかだとコストを削減するため
数値演算コプロセッサは単精度浮動小数点演算のみのサポート。倍精度は
ソフトウェア的に処理するからムチャクチャ遅い。

738 名前:デフォルトの名無しさん :04/07/15 02:42
クラスAを
グローバルとクラスBのメンバとして宣言するために

クラスAの定義を書いたヘッダーを
main.cppとクラスBの定義を書いたヘッダーでインクルードすると
もう定義されてると言われますが

こういう場合どうすればいいんでしょうか?

739 名前:デフォルトの名無しさん :04/07/15 02:46
>>738
インクルードガード
意味がわからんかったらググれカレー

740 名前:デフォルトの名無しさん :04/07/15 02:47
>>738 ヘッダファイルにインクルードガードをつける

741 名前:デフォルトの名無しさん :04/07/15 03:03
>>739-740
どうもでした

742 名前:デフォルトの名無しさん :04/07/15 05:15
冗長インクルードガードってやるに越したことはないでしょうけど、
実際やってる人ってどのくらいいるのでしょう。
私はせいぜい内部インクルードガードで済ましちゃってます。
実際、コンパイル時間とかそんなに変わるものですか?
10年前のマシンならあったほうがいいのかも。。。

743 名前:デフォルトの名無しさん :04/07/15 05:31
>>742
新規ヘッダはすべてやってるよ

744 名前:デフォルトの名無しさん :04/07/15 06:45
VCのクラスウィザード使うとインクルードガードが記述されるじゃん。
インクルードガードって単語知らなかったよ。
名前を知らなくても自然に習得するような希ガス。

745 名前:デフォルトの名無しさん :04/07/15 07:04
そんな言葉は始めて聞いた。ただのいふでふじゃねーか

746 名前:デフォルトの名無しさん :04/07/15 07:07
お前らの使ってるインクルードガードは偽物。
本物のプログラマーが使うのはこれ。
#ifdef MYHEADER_H
#error MYHEADER_H
#endif
#define MYHEADER_H

747 名前:デフォルトの名無しさん :04/07/15 08:09
http://www.open-std.org/jtc1/sc22/wg21/
> News 2004-07-14: The C++ Standard Library Issues List (Revision 30) is available.

748 名前:デフォルトの名無しさん :04/07/15 08:46
>>742
冗長インクルードガードはやってるのを見たこと無いな。
実際言葉も知らなかったし。
ググッた先のページ見たらコンパイル時間もほとんど変わらないようだ。

749 名前:デフォルトの名無しさん :04/07/15 11:30
インクルードガードって用語初めて知って、
早速今日、会社で使っている香具師いるだろ。
なっ、そこのもまえw

750 名前:デフォルトの名無しさん :04/07/15 11:32
#pragma once使えよぼけ


■過去ログ置き場に戻る■ 1- 前250 次250 最新50
DAT2HTML 0.33f Converted.