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


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

C++相談室 part31
501 名前:デフォルトの名無しさん :04/06/15 23:31
>>500
>return foo() && bar();

こんなんでハマんなや

502 名前:デフォルトの名無しさん :04/06/15 23:32
C++じゃねぇが、Pikeの組み込みstring型の算術演算子オーバーロードは流石にやりすぎだろと思ったな。
わからんでもないんだが。

C++だとboostのpathあたりか。spiritあたりまでいっちまうともうどうでもいいんだが。

503 名前:デフォルトの名無しさん :04/06/15 23:34
極論するとoperatorはまったくいらない(代入でさえも)
「やりすぎ」かどうか論じるには基準が必要


504 名前:デフォルトの名無しさん :04/06/15 23:52
>foo() が真なら bar() は評価されない
foo()が偽なら bar() は評価されない
じゃない?


505 名前:デフォルトの名無しさん :04/06/16 01:00
>>484
コンテナのiteratorがRandomAccessIteratorなら、あり。
それ以外のイテレータなら、なし。

506 名前:デフォルトの名無しさん :04/06/16 10:36
最近、「実装とインタフェースの分離」を耳にする事が多いのですが、
ここでのインタフェースって何を指しているのでしょうか?
例えば、
class Implと、class Infcが在ったとき、Implの方には実装に必要な
privateインタフェースのみが定義されていて、publicインタフェースは無しで、
Impl内で、friend class Infcが記述されていて、InfcにImplのインタフェースを
移動していると言うことでしょうか?例を示して貰えないでしょうか?


507 名前:デフォルトの名無しさん :04/06/16 11:38
>>506
ごく簡単な例だと、例えば簡単な html パーサを書いていて、タグの情報をクラス化するとしたとき、
インタフェイス IHtmlTag を
class IHtmlTag {
 public:
 virtual const string& get_Name() const = 0;
 virtual const HtmlAttr& get_Attributes() const = 0;
};

と定義し、実装は
class CHtmlImpl : public IHtmlTag
{
 string m_strTag;
 HtmlAttr m_attributes;

 virtual const string& get_Name() const { return m_strTag;};
 virtual const HtmlAttr& get_Attributes() const { return m_attributes;};
};

なんてしておく。
多重継承やcontainment で複数のインタフェイスを持つクラスなんかも作れる。
利点はイロイロあるけど、産業的にはクローズドソースでクラスライブラリを公開できる点が重要。

508 名前:506 :04/06/16 13:22
>>507
ほほ〜。多重継承の場合は、LokiのGenLinearHierarchy等で複数のインタフェースを突っ込んだら
いい訳ですな。containmentは初めて聞くのでちょっと分かりません。後、
クローズドソースでクラスライブラリを公開できるって言うのと、.cppは公開せずに.hppのみの
公開の違いが分かりません。良かったらフォローお願いします。

509 名前:デフォルトの名無しさん :04/06/16 20:38
>>508
C++ はたとえ private なものでもメンバ変数ひとつ増えるとオブジェクトサイズが
変わってしまう。インターフェースと実装を分離しない場合、内部的な改修で
あってもバイナリ互換性が崩れる可能性があるのでマズい。

以前は Microsoft の DLL でも、この手の変更が合ってとつぜん動かなくなる、
なんつー問題がしばしば発生してた。

510 名前:デフォルトの名無しさん :04/06/16 22:48
>>506
Cで言うところのソースとヘッダの分離におけるヘッダにあたる。
ヘッダだけ公開しといて、ソースはそれに合うように作れと。
標準化委員会なんかが好むやり方を想像すればいい。

511 名前:デフォルトの名無しさん :04/06/16 23:01
インタフェイスだけのクラスでも、そのサイズは最低1だったと思ったのですが、
そこから継承されたクラスは、その分、大きくなるのでしょうか?

512 名前:デフォルトの名無しさん :04/06/16 23:02
>>511
1バイト?
確かに実装は未規定だが
さすがにそれは難しそうだな

513 名前:506 :04/06/16 23:03
>>510 実装とインタフェースを分離した場合でも、実装とインタフェースのヘッダファイルは
両方とも公開しますよね?分離した場合何か特に利点となる場合があるのですか?

514 名前:デフォルトの名無しさん :04/06/16 23:06
>>513
実装については一切公開しないのがインターフェイスというやり方。
現実には実装も公開しちゃってるケースよくあるけど、それは妥協の産物。

515 名前:デフォルトの名無しさん :04/06/16 23:07
>>511
1 バイトなのはポリシークラスでしょ。仮想関数あったら、最低ポインタ 1 個分は
必要。

継承した場合は単一敬称なら相変わらずポインタ 1 個分。多重継承すると
ポインタ n 個分になる実装が一般的。あと仮想継承は話が別。

516 名前:506 :04/06/16 23:10
>>514 それでは自分で独自のインタフェースを書く場合困らないのですか?

517 名前:デフォルトの名無しさん :04/06/16 23:10
>>513
実装側のヘッダは公開する必要ないけど。コンストラクタを陽に呼び出すのではなく、
インターフェースに従ったオブジェクトを作成する関数や、あるいはファクトリクラス
を公開する。

// 公開ヘッダ
struct IFoo {}; // 純粋仮想関数いろいろ
IFoo* CreateIFoo(); //

// 非公開ヘッダ
class CFoo : public IFoo {};
// 非公開実装
IFoo* CreateIFoo() { return new CFoo; }

Microsoft の COM まわりのドキュメントが参考になると思うぞ。

518 名前:デフォルトの名無しさん :04/06/16 23:12
>>516
もしかして
#define インターフェース 実装
状態か?

519 名前:506 :04/06/16 23:15
あー、すいません、勝手に、

template< typename Interface >
class Impl : public Interface { ... }

を妄想していました。

520 名前:デフォルトの名無しさん :04/06/16 23:26
>>519
Impl* pObj; ってやろーとしたろ?
Interface* pObj = new Impl; もダメ
さあどうする?

521 名前:506 :04/06/16 23:46
>>520 今日はもう寝るので明日考えてみます。

522 名前:デフォルトの名無しさん :04/06/17 00:14
string型をchar型へのポインタに変換するにはどうしたらいいのでしょうか。

523 名前:デフォルトの名無しさん :04/06/17 00:22
c_str

524 名前:デフォルトの名無しさん :04/06/17 05:28
標準コンテナってデストラクタが仮想関数じゃないから
継承できないんだよな。(パフォーマンスのためなんだろうか)
virtualって一文字追加すれば良さそうなんだが...
このためだけに2つも実装書くのも面倒そうではあるが...


525 名前:デフォルトの名無しさん :04/06/17 06:33
>>524
継承する必要ある?

526 名前:524 :04/06/17 09:56
>>525
機能拡張したい場合は、
できないよりできた方がイイと思うんだが...
完成されたものであれば、その必要はないだろうねぇ。


527 名前:デフォルトの名無しさん :04/06/17 10:03
そもそもコンテナをポリモフィックにdeleteする場面ってあるんだろうか?

528 名前:デフォルトの名無しさん :04/06/17 10:55
>>526
10中ハック、526がタコ。
といったところ本人がそれに気づくはずもなし。
まぁ、気がむいたら問題を書いてみな。

529 名前:デフォルトの名無しさん :04/06/17 10:57
このスレの前の方にいた、継承するときには必ずデストラクタをvirtualにしなければならないと思い込んでるヤシだったりして。


530 名前:デフォルトの名無しさん :04/06/17 11:11
つーか、STLコンテナにPolicyがあればいいだけなんだがな。

531 名前:524 :04/06/17 12:46
>>527
のような場合に
virtualじゃなかったら欠陥になりうるじゃん。
気を付けろといえばそれまでだけどw。
(だから、自分が管理してないコードに使うときはこわくて使えない。)

一般にポリモフィックな動作であれば問題ないコードで問題に
なるわけで、たぶんこれは継承じゃないんだなと邪推。

struct NV{~NV(){}};
struct EX :public NV{~EX(){}};
boost::scoped_ptr<NV> p(new EX);
とか?


532 名前:デフォルトの名無しさん :04/06/17 12:50
・virtualメソッドを持つクラスを定義する場合、デストラクタもvirtualにする。
・virtualメソッドをもつクラスを継承する場合、デストラクタもoverrideする。

533 名前:デフォルトの名無しさん :04/06/17 12:51
>>531
それはコンテナなのか?

534 名前:デフォルトの名無しさん :04/06/17 13:48
>>532
それはそうかもしれないが、重要なのはなぜそうなのか?ということだ。
>>526 にも理解できるよう説明すること。(20点)


535 名前:デフォルトの名無しさん :04/06/17 14:32
>531
boostのスマートポインタで扱う場合、そのケースでもメモリリーク(確か)しないよ。
試しにやってみなよ。

536 名前:524 :04/06/17 14:53
>>535
#include<iostream>
#include<boost/scoped_ptr.hpp>
struct NV{~NV()//virtual をあえてつけてない
{std::cout << "~NV" << std::endl;}
};
struct EX :public NV{
~EX()//virtualにすると呼ばれないだけでなく、下記の呼び出しでアボーンしちゃう
{std::cout << "~EX" << std::endl;}
};
int main()
{
{boost::scoped_ptr<NV> p(new EX);}//~NV
}


537 名前:524 :04/06/17 15:04
>>530
その通りですね。(以下はイメージ的なもの)
#include<iostream>
#include<boost/scoped_ptr.hpp>
struct Virtual{virtual ~Virtual(){} };
struct Non_Virtual{};
template<typename T,typename P_V=Non_Virtual> struct SEL{
SEL(){}
~SEL(){ std::cout << "~SEL<T,Non_Virtual>" << std::endl; }
};
template<typename T> struct SEL<T,Virtual>{
SEL(){}
virtual ~SEL(){ std::cout << "~SEL<T,Virtual>" << std::endl; }
};
template <typename T,typename P_V=Virtual> struct SEL_EX :public SEL<T,P_V>{
SEL_EX(){}
~SEL_EX(){ std::cout << "~SEL_EX" << std::endl;}
};
int main(){
{boost::scoped_ptr< SEL<int,Non_Virtual> > p(new SEL_EX<int,Non_Virtual>);}std::cout << std::endl;
{boost::scoped_ptr< SEL<int,Virtual> > p(new SEL_EX<int,Virtual>);}
}

538 名前:デフォルトの名無しさん :04/06/17 17:47
>>535-536
メモリリークしないのは shared_ptr
ためしに、>>536 の main を以下のように書き換えて見れ。

int main()
{
 boost::shared_ptr< void > p( new EX );
 return 0;
}



539 名前:デフォルトの名無しさん :04/06/17 17:59
標準ライブラリとかAPI的なものは普通は継承しないんだから
デストラクタにvirtual付いていなくても仕方が無いような気がするんだが。
継承しても、クラスの内部的な動作を差し替えるようなことはできないし。
単なるラップ+αなら、メンバとして持ったって同じような気がする。

ソースを見てデストラクタを確認したり、ドキュメントを見なければならないのは
確かに危険だが、Javaのfinalに相当するものが無いからなぁ。

540 名前:524 :04/06/17 18:19
>>538
ほんとだ。
{boost::shared_ptr<NV> p(new EX);}//~EX~NV

shared_ptrのコンストラクタってメンバtemplateになってるから
指定した型(NV)から推測されるポインタに代入しないで、
実際にコンストラクタに引き渡された型で
削除用の関数オブジェクトも生成しちゃって処理してるのか...。(頭イイ)
だからvirtual付けてない場合は、
{boost::shared_ptr<NV> p(dynamic_cast<NV*>(new EX));}//~NV
としちゃうと意図的にメモリリークを起こせると...


541 名前:デフォルトの名無しさん :04/06/17 18:19
>>539
C++ で継承禁止クラスを作ることは可能だよ。

542 名前:デフォルトの名無しさん :04/06/17 18:21
どやって?

543 名前:デフォルトの名無しさん :04/06/17 18:31
>>542
http://www.tietew.jp/cppll/archive/10658
あたりからの流れを参照。

早速自作ライブラリに取り込んでみたものの、結局使ったことがない。
ここまでするメリットを感じない。デメリットのほうが大きそうだしね。






544 名前:デフォルトの名無しさん :04/06/17 18:49
>>543
ええと、これ仮想継承で実現するのか。
デストラクタをvirtualにするよりメモリ食うのではなかろうか。
デストラクタvirtualよりパフォーマンスが良いなら考えるけどな。

545 名前:デフォルトの名無しさん :04/06/17 19:07
>>543
以下のコードでどれだけメモリを食うか調べた。
(VC++2003)

struct A : public nonderivable< A > { int a; };
struct B { virtual ~B(){} int b; };
struct C : public B, public nonderivable< C > {};

int main()
{
 cout << sizeof(A) << endl;
 cout << sizeof(B) << endl;
 cout << sizeof(C) << endl;
}

結果は A, B は 8 、C は 12 と出た。
パフォーマンスにはあまり影響はなさそうだけど…、ようわからん。

546 名前:デフォルトの名無しさん :04/06/17 19:09
で、けっきょくいえることは、Policy として使うだけのクラスは、protected なデストラクタにするか、
char_traits などのようにすべてのメンバを static で持つかどちらかにしろということだ。

547 名前:デフォルトの名無しさん :04/06/17 19:55
>>524
STLコンテナの継承にはprivate継承がお薦めですよ.
使うメンバー関数だけusingするといいです.
#include <deque>
using namespace std;
class A: private deque <int>
{
typedef deque <int> Base_;
public:
A (): Base_ () {}
A (const A &p): Base_ (p) {}
A &operator = (const A &p) {if (&p != this) {Base_::operator = (p);} return *this;}
virtual ~A () {}
using Base_::push_back;
};
int main () {
A a0;
a0.push_back (0);
return 0;
}


548 名前:デフォルトの名無しさん :04/06/17 21:31
>>547
usingでそんなことできたんだ。
知らなかった。

549 名前:デフォルトの名無しさん :04/06/17 23:21
>>547で基底クラスのデストラクタは呼ばれる事が保証されるの?

550 名前:デフォルトの名無しさん :04/06/17 23:30
>>549
よくわからんが、
private継承だから、基底クラスのポインタにすることはできない

551 名前:デフォルトの名無しさん :04/06/17 23:32
>>549
基底クラスのポインタでインスタンスを保持できないんだから
デストラクタは必ず呼ばれると思う。

552 名前:デフォルトの名無しさん :04/06/17 23:38
> virtual ~A () {}
ひょっとしてvirtualは不要になる?


553 名前:547 :04/06/17 23:50
>>550,551
そういう意図です.

>>552
混乱させたようですが,
デストラクタのvirtualはなくてもOKです.
これがなくても,先祖クラスのデストラクタを呼び忘れるなんてシチュエーションは起き得ないです.
Aをpublic継承する可能性があるなら付けておきましょう.


554 名前:547 :04/06/17 23:52
sed 's/先祖クラス/派生クラス/'


555 名前:10659 :04/06/18 00:02
>>543
>ここまでするメリットを感じない。デメリットのほうが大きそうだしね。

「デメリット=無駄にメモリ喰う」って類のことを言ってんなら
デバッグ版の時だけギミックを仕掛けといて
リリース版の時にはギミックを外すようにしとけばいいんじゃない?

556 名前:デフォルトの名無しさん :04/06/18 06:38
STLコンテナにvirtualなデストラクタがないことが心配っていう人は、
struct person
{
 char name[256];
 int age;
};
こんなやつも同じ理由で心配になるのかな?

557 名前:デフォルトの名無しさん :04/06/18 06:56
EffectiveC++に確かこんな記述があったはず。
(若干表現は違ったかもしれない)
>基底クラスのポインタを介して派生クラスのオブジェクトを
>削除するとき、基底クラスのデストラクタがvirtualでないと
>、その結果は不定となる。
>不定とはコンパイラはどんなコードでも好き勝手に生成しても
>よいということだ。
この記事を読んでからは
特定のコンパイラで制限付きで動いてても
virtualでない場合は(似非)継承は避けることにした。

ポリモフィックな動作を保証できなくなるなら
他のキーワードがあっても良かった気がする。


558 名前:535 :04/06/18 10:22
>>536
微妙にうそついてすまんかった。

>>538
scoped_ptrだとリークするんだねぇ。
scoped_ptrリークする可能性のあるコード書いたこと無かったから知らなかったよ。

559 名前:547 :04/06/18 12:08
>>556
?


560 名前:デフォルトの名無しさん :04/06/18 20:07
>>557
基底クラスオブジェクトへのポインタって考え方に固執することないじゃん
テンプレートあるんだし

561 名前:デフォルトの名無しさん :04/06/18 21:25
>>557
そもそも仮想関数が1つも無いクラスのオブジェクトを
ポリモフィックに使わない。というか使えない。

そんなクラスに仮想デストラクタが必要なんだろうか?
他のメンバ関数は仮想で無いのに。

と、ひさびさに小一時間問い詰めたい。

562 名前:デフォルトの名無しさん :04/06/18 21:37
>>561
まったくだ

563 名前:デフォルトの名無しさん :04/06/19 00:38
あの非常に初歩的なことかも知れません、いいですか?
#include <iostream.h>
とやるよりも、
#include <iostream>
using std::cout;
using std::cin;
using std::endl;
とかってする意義はあるのでしょうか?
<iomanip.h>とかも全て<iomanip>でわざわざ using して使われてます。

どなたか知ってる方。

564 名前:デフォルトの名無しさん :04/06/19 00:45
>>563
#include <iostream.h>
はものすごく古い

565 名前:デフォルトの名無しさん :04/06/19 00:47
デストラクタでぐちゃぐちゃうざい。
C#つかえよ。
どーでもいいよそんなもん。臨機応変にやれよ。

566 名前:デフォルトの名無しさん :04/06/19 00:48
>>563
そういう風に標準化されているんです。

567 名前:563 :04/06/19 00:48
古いのは分かるんですが、何かが劣ってるとか
<iostream>だけしかできないことがあるとかはないんでしょうか?

568 名前:デフォルトの名無しさん :04/06/19 00:49
>>567
いいとこ突いたな
返答が見ものだw

569 名前:デフォルトの名無しさん :04/06/19 00:49
C#じゃなくても __gc あるもん〜。

570 名前:デフォルトの名無しさん :04/06/19 00:50
>>567
std

571 名前:デフォルトの名無しさん :04/06/19 00:51
>>567
劣っているというか、

string.h が困るよね。

572 名前:563 :04/06/19 00:54
>>570
あんまり良く分かりません
>>571
それは cstring を使えばいいのでは?

573 名前:デフォルトの名無しさん :04/06/19 00:56
古くて規格外というのは、大きな欠点だと思うが。

574 名前:デフォルトの名無しさん :04/06/19 01:00
>>572
>あんまり良く分かりません
「まったく分かりません」だろ?
名前空間について調べてみ

575 名前:デフォルトの名無しさん :04/06/19 01:05
>>573
古いかもしれないけど規格外ではないだろ?

576 名前:デフォルトの名無しさん :04/06/19 01:08
>>575
1998年の時点でdeprecatedなんだから、そろそろアウトにしたいなぁ。

577 名前:572 :04/06/19 01:14
まつまり基本的に古いものは排せってことですね。
良く分かりました。

578 名前:デフォルトの名無しさん :04/06/19 01:18
>>573
プ

579 名前:デフォルトの名無しさん :04/06/19 01:20
古いiostreamの実装ってよく知らないんだよなー。
2000年からプログラミング始めたから。

std::stringとの連携、たとえば
ostream& operator<<(ostram&, const string&);
getline(istream&, string&);
なんかは、"iostream.h"には存在する保証が無い・・・のかな?

580 名前:デフォルトの名無しさん :04/06/19 01:21
>>573
プ

581 名前:579 :04/06/19 01:21
これはiostreamそのものとは関係無いか。

582 名前:デフォルトの名無しさん :04/06/19 01:51
つまり、賞味期限きれたものと、きれてないものどっちがいいかというと
そらー、食えるとしても新しいほうがいいじゃないかと。

583 名前:デフォルトの名無しさん :04/06/19 01:51
ttp://www.kab-studio.biz/Programing/Codian/iostream/08.html

これの末文とかかな。
名前空間の問題もそうだけど、要は古い実装は1byte lengthのcharに
べったりで用意されていて、過渡期においては、テンプレート化された
新しい実装のものとで住み分けの必要も出てきた。
新しいものがstd名前空間に置かれてるのは当然のことで、逆に置かれてない方は
歴史的な事情に配慮して(つーか放置されて)こうなってるだけ、と。

584 名前:デフォルトの名無しさん :04/06/19 08:23
iostream.hって規格内なの?
14882:1998にそんな記述見つけられなかったし、VC7.1に入ってないけど。

585 名前:デフォルトの名無しさん :04/06/19 08:31
いまだかつてiostream.hがC++の規格に存在したことはない

586 名前:デフォルトの名無しさん :04/06/19 09:07
ライブラリの作りの良し悪しは、規格化されているか否かとは無関係
規格化されていても問題ある定義体はいくらでもある(例: gets)

>>573にプと言ったのはマジレスだよ

587 名前:デフォルトの名無しさん :04/06/19 10:46
プ

588 名前:デフォルトの名無しさん :04/06/19 12:31
>>586
実際にそうした定義が山ほどあるとしたところで、
数があるから問題じゃないというわけじゃなし…

えーと、悪い奴はだれだ!

589 名前:デフォルトの名無しさん :04/06/19 12:48
誰が悪いのかは知らんが「規格外」ってことは

#include <iostream.h>
int main() { cout << "hoge" << endl; return 0; }



#include <iostream>
int main() { std::cout << "hoge" << std::endl; return 0; }

で同じ結果が得られるって保証がないんだよね?


590 名前:デフォルトの名無しさん :04/06/19 15:42
わたくしJava厨なのですが、最近 C++ の勉強をはじめました。
WindowsでもLinuxでも使えて、
フリーで使えて(業務用途不可でもいいです)、
Eclipseライクな操作性の C++ のIDEがあったら教えてください。

591 名前:547 :04/06/19 15:56
>>561
抜け道(非仮想デストラクタを持つ基底ポインタで派生クラスを削除)塞いどくのは,
別に悪いことではないのではないでしょうか.
そのままでは警告なりエラーなりはでないんですし.

ただ561は,確かにそうかもしれないと思った.
立て札たてとかなくても抜け道通る奴はあんまりいないかな.


592 名前:デフォルトの名無しさん :04/06/19 16:23
>>590
知らんけど、EclipseライクがいいんならEclipse自身のC++サポートは駄目なの?

593 名前:デフォルトの名無しさん :04/06/19 16:50
>>589
得られる保証も得られない保証もない
ISO/IEC14882が規定しないライブラリは
ISO/IEC14882ではユーザ定義であって
正しいか正しくないかを論じることができない

おまえさんの口ぶりから察するに
言いたそうなことは痛そうだが・・・w

594 名前:デフォルトの名無しさん :04/06/19 17:21
Realメディアファイルを再生するプログラムを書きたいのですが、
フィルタに何を指定したらいいのでしょうか。

ユーザに、作ったソフトに加えて、RealMediaSplitterをインストール
してもらい、それのフィルタを使って再生する方法なら分かるのですが、
RealMediaSplitterの代わりに、本家のRealPlayerをインストールしてもらうだけ
で、Realメディアファイルを再生できるようになる方法が分かりません。



595 名前:594 :04/06/19 17:26
自己解決しました。

REALSYSTEM SDK
ttp://proforma.real.com/rnforms/resources/server/realsystemsdk/index.html
を使うそうで・・・・・

板汚しすいません(´・ω・`)


596 名前:デフォルトの名無しさん :04/06/19 18:21
>>591
派生クラスを作るだろう人の実力によるよな。
初心者に毛が生えたような人だとすると
「どーあっても安全にしたい。効率なんか二の次だ」って
考えてvirtualつけることもあるだろう。
10659氏が言ってくれているように仕掛けを付けとくのも強力。
継承可能かどうかドキュメントに記しておくことも手助けにはなる。
デストラクタprotectedもある。ケースバイケースだな。

597 名前:524 :04/06/19 18:45
>>561
そういわれてみればそうですね。
仮想関数をなくしてデストラクタを非仮想関数にしてしまう
クラス設計もそれはそれでいいのですが、
本来継承するべきでないのか、
あるいはそれを断念せざるを得ない状況を生み出すという見方もないでしょうか?
(使用者側からはPolicyで選択できるのがいいです。)
まぁC++の場合、C#のsealedやJAVAのfinalのように継承を禁止されない分、
自由度が高いという見方もあるのかもしれません。

宗教論争みたいになってきたんでこれくらいでやめにしておきます。w
つきあってくださった方、ありがとうございました。


598 名前:547 :04/06/19 18:54
>>596
> 派生クラスを作るだろう人の実力によるよな。

同意.
私は(未来の自分も含め)派生クラスを作る人(以後,利用者)を信用しないほうですから,
安全性を優先してます.
作成者が利用者をコントロールする手段を提供するのは重要なことだと思います.
(そういう意味では543,555は私的にはヒットでした.)
次の言語規格改定では,この辺をもう少し頑張って欲しいですね.


599 名前:デフォルトの名無しさん :04/06/19 20:53
int* abc

int *abc の違いは何なのでしょうか?。*って、読み方なんでしたっけ?。

600 名前:デフォルトの名無しさん :04/06/19 21:02
>>599
見た目だけ。
みにくいし
int* a, b;
とかしてはまるからそういう記述はやめとけ。
* = asterisk

601 名前:デフォルトの名無しさん :04/06/19 21:04
* = 菊門


602 名前:デフォルトの名無しさん :04/06/19 21:06
規格上違いが無いのですが、実際に出力されるオブジェクトに違いが出ることがあります。
理由はわかりません。

603 名前:デフォルトの名無しさん :04/06/19 21:07
base* でdeleteする時点でデストラクタがvirtualかどうかくらい点検しろよ

604 名前:デフォルトの名無しさん :04/06/19 21:08
>>602
あなたの不注意

605 名前:デフォルトの名無しさん :04/06/19 21:12
>>604
いろいろ試してみてください。
結構予想と違う振る舞いが多いですよ。

606 名前:547 :04/06/19 21:17
>>603
利用者の点検を言語レベルで強制できればいいんですけどね.


607 名前:デフォルトの名無しさん :04/06/19 21:30
>>606
http://www.research.att.com/~bs/bs_faq2.html#virtual-dtor

C++に【も】向かない人はいるってことさ

608 名前:デフォルトの名無しさん :04/06/19 21:46
ださげんご

609 名前:デフォルトの名無しさん :04/06/19 21:53
はげんご

610 名前:547 :04/06/19 22:12
>>603
「base* でdeleteする」のが利用者でない場合ってのはありえないでしょうか?
極端な例を出すと,
// designer.h
struct Must_Not_Derive {void memfun0 () {} ~Must_Not_Derive () {}};
void func (Must_Not_Derive *p);
// designer.cpp
void func (Must_Not_Derive *p) {delete p; p = new Must_Not_Derive;}
// user.cpp
struct Derived: public Must_Not_Derive {~Derived () {}};
int main () {
Derived *p (new Derived);
func (p);
return 0;
}
で,利用者がdesigner.cppを閲覧できない場合.
設計者は利用者がよもやMust_Not_Deriveを継承するとは考えてない.
一方,利用者はMust_Not_Derive::memfun0を使いたいのだか,
コンポジットあるいはpriavete継承が面倒臭いので,
funcでdeleteされることとは知らずにpublic継承してしまった.
例が極端だけどこういうはまり方はないでしょうか?


611 名前:デフォルトの名無しさん :04/06/19 22:23
>>605
どんな場合?ぜんぜん思いつかない。


612 名前:デフォルトの名無しさん :04/06/19 23:04
>>600
int* a, b;
とかしてはまるからそういう記述はやめとけ。

この場合は、aもbも、ポインターになるのですか?それとも、bは整数?。

613 名前:デフォルトの名無しさん :04/06/19 23:06
>>612
試せば?

614 名前:デフォルトの名無しさん :04/06/19 23:08
>>610
引数が非constのfuncが何をする関数かを知らずに使うわけか


615 名前:デフォルトの名無しさん :04/06/19 23:09
答えられないなら黙ってていいよ。
レスつけるのは別に義務ってわけじゃないからね。

616 名前:デフォルトの名無しさん :04/06/19 23:11
>>615
稚拙杉

617 名前:デフォルトの名無しさん :04/06/19 23:13
>>612
自助努力をしろ
初心者であろうがベテランであろうが関係ない
これは人間性の問題

618 名前:デフォルトの名無しさん :04/06/19 23:16
スレ荒らして楽しいかい?

619 名前:デフォルトの名無しさん :04/06/19 23:18
>>618
ん、何か間違ったこと言ったか?

620 名前:デフォルトの名無しさん :04/06/20 00:07
int* a, b;
って書く人はやはり多いんですか?
私は絶対
int* a;
int* b;
と書きます。

621 名前:デフォルトの名無しさん :04/06/20 00:10
>>620
その前に、
int* a,b;

int *a;
int *b;
は意味が違う

622 名前:デフォルトの名無しさん :04/06/20 00:11
>>620
a と b が
・同型でなければならないとき
・たまたま同型なだけのとき
で書き方わけてるよ

623 名前:デフォルトの名無しさん :04/06/20 00:19
漏れは int* a; 派だな
型の記述なんだから型の方にくっつけたいよ。
ポインタ宣言は一行に一個。

624 名前:デフォルトの名無しさん :04/06/20 00:20
int * w ;

625 名前:デフォルトの名無しさん :04/06/20 00:23
int * (a,b);

626 名前:デフォルトの名無しさん :04/06/20 00:27
>>623
そんなのは伺いをたてること
こっちから押し売りすることじゃない

627 名前:デフォルトの名無しさん :04/06/20 00:27
LPINT

628 名前:デフォルトの名無しさん :04/06/20 00:31
>>625
typedef

629 名前:デフォルトの名無しさん :04/06/20 00:34
>>626
文盲か?
とりあえず馬鹿は引っ込んでてくださいな。

630 名前:デフォルトの名無しさん :04/06/20 00:34
int *a,*b;
int *c;
でFA

631 名前:デフォルトの名無しさん :04/06/20 00:35
>>629
コーディング基準は俺ルールじゃないってことだよ

632 名前:デフォルトの名無しさん :04/06/20 00:35
こうやって不毛なコーディングスタイル論争が始まるんだな

633 名前:デフォルトの名無しさん :04/06/20 00:38
>>632
ム板ではなくマ板でやれば
少しは実りがあるはずだ

634 名前:デフォルトの名無しさん :04/06/20 00:40
>>633
隔離ですかw

635 名前:デフォルトの名無しさん :04/06/20 00:42
>>634
そういう意図はない
スタイルはプログラム技術じゃない
PGの社会に関することだ

636 名前:デフォルトの名無しさん :04/06/20 00:44
>>635
マ板ってネタ系でわないのかね?

637 名前:デフォルトの名無しさん :04/06/20 02:59
>>621
そうです。
つまり、勘違いや間違いを起こさないように、と言う意味です。

638 名前:デフォルトの名無しさん :04/06/20 04:37
int* p1,*p2;



int* p1,p2;

と書き間違えたからって問題になるケースがあるかな?
大抵コンパイルエラーになって、んで訂正して終わりっしょ。

639 名前:デフォルトの名無しさん :04/06/20 04:38
はぁ、またこれか。

640 名前:デフォルトの名無しさん :04/06/20 05:26
double ** m_tblに領域をnewしたいのですがどうすればよいですか?
まず、
m_tbl = new (double *) [TBLNUM]; //TBLNUM個のdouble*型を割り当て

として次に
*m_tbl[i]=new (double *) [EACH_TBL_ARRAY];//おのおののm_tbl[i]にEACH_TBL_ARRAY個の配列へのポインタをセット

のようにしたいです。
上記だとコンパイルエラーになります。


641 名前:デフォルトの名無しさん :04/06/20 05:33
>>640
*m_tblの型はdouble *だろ。

642 名前:デフォルトの名無しさん :04/06/20 05:39
そうでした
*m_tbl[i]=new double[]ですね。
でもその前にm_tbl=new(double*)[]がエラーってしまうのですが。


643 名前:641 :04/06/20 05:40
あともう一つ。
*m_tbl[i]はm_tbl[i]の間違いだろ?

要するに
*m_tbl[i]=new (double *) [EACH_TBL_ARRAY];

m_tbl[i]=new double[EACH_TBL_ARRAY];

644 名前:デフォルトの名無しさん :04/06/20 05:45
たびたびありがとうございます。
最初の記述は
m_tbl = new double* [TBLNUM];としたらOKでした。
もっと勉強します。

645 名前:デフォルトの名無しさん :04/06/20 08:23
>>598
でも、543の仕掛けでエラーになったとして、
派生クラス作る人がヘボだと、ただ悩むだけになってしまったり。
ドキュメントちゃんと書けよってことか。
やっぱりこういうの綺麗にコンパイルエラーにする仕組みは欲しいよな。


646 名前:デフォルトの名無しさん :04/06/20 09:29
これスレのFAQに入れておこう。
int * i;
int* i;
int *i;
どれでも好きなやり方にしろって。

647 名前:デフォルトの名無しさん :04/06/20 09:29
>>645
最後の一行を除き激しく同意
小技に凝る前に大きな忘れ物だ

648 名前:デフォルトの名無しさん :04/06/20 09:30
>>646
組み合わせ1つ抜けてる

649 名前:デフォルトの名無しさん :04/06/20 09:40
>>647
> 小技に凝る前に大きな忘れ物だ
具体的にはどういう意味?

650 名前:デフォルトの名無しさん :04/06/20 12:14
ドキュメントを書くってことだろ。

651 名前:デフォルトの名無しさん :04/06/20 13:42
ソースツリーはどうやって決めてますか?
なにか良い本やWebがあれば教えて下さい。

これから作るシステム構成は
・いくつかのサブシステムからなる。
・共通のコマンドユーティリティがある。

です。

lib, src, lib/src ???


652 名前:デフォルトの名無しさん :04/06/20 13:52
C++ スタイルのキャストを使えと良く聞きますが、やっぱり C スタイルより C++ スタイルでキャストした方が良いのでしょうか?

653 名前:デフォルトの名無しさん :04/06/20 13:53
安全性を考えるならC++キャストのほうが良いだろうな。

654 名前:デフォルトの名無しさん :04/06/20 13:54
Cスタイルのキャストを禁止にするようなコンパイルオプションとかあったらいいな。
ってもうある?

655 名前:デフォルトの名無しさん :04/06/20 13:56
>>652
const_castやreinterpret_cast, mona(giko, c)はともかく
(char *)0を(char*)(0)と書けという根拠は希薄

656 名前:デフォルトの名無しさん :04/06/20 14:00
>>655 漏れは精神衛生上C++にしてる。
混ざってると気持ち悪い。

657 名前:デフォルトの名無しさん :04/06/20 14:19
>>653
安全性を考えてそうします。

658 名前:デフォルトの名無しさん :04/06/20 15:02
>655
static_cast<char *>(0)
( ゚∀゚)アヒャ

659 名前:デフォルトの名無しさん :04/06/20 15:06
>>655
(char *)(0)はCスタイルじゃないか?
static_cast<char *>(0)
または
template<typename T> struct id{typedef T type;};
id<char *>::type(0)
かと。

660 名前:デフォルトの名無しさん :04/06/20 15:08
そこでEffective C++ですよ

661 名前:デフォルトの名無しさん :04/06/20 15:10
>>658
いいたいことはわかるが
reinterpret_castでないあたりから
耐え難い腐臭が・・・

662 名前:547 :04/06/20 15:29
>>614
利用者のスキルが低い場合にはありえることじゃないでしょうか?
funcは今回は適当に名前を付けましたが,
その中でdeleteしてることを全く連想させない名前である可能性はあるわけです.
これを否定するために,私としても561みたいにこの状況が起こり得ないことを示したいですね.

>>645,647
「ドキュメントちゃんと書けよ」ってのには異論の余地は無いですが,
設計者が利用者とコミュニケーションが取れないことを仮定して,
対策を講じておくのはいいことだと思います.
また,利用者が設計者を信用しないことも同様に安全性を高めると思います.
私に反論して下さる方には,利用者と設計者の立場を分けて考える視点が欠落していると思います.
どうでしょうか.(煽ってなんかないですよ.念のため.)

皆さんそれぞれ作ってるものが違うでしょうから一概には言えませんけど,
virtualディストラクタが(ディストラクタに限らなくてもいいですが.)
全体のパフォーマンスに影響与えてる局面って,
結構少なくないですか?


663 名前:デフォルトの名無しさん :04/06/20 15:33
>>662
>利用者が設計者を信用しないことも同様に安全性を高めると思います

では、STLもコンパイラもCPUも信用せずに何ができるのか聞こうか。

664 名前:デフォルトの名無しさん :04/06/20 15:37
プログラミングができる。

665 名前:デフォルトの名無しさん :04/06/20 15:38
>>659
float(0) はC++タイプ、同様に(char*)(0) もC++タイプ


>>660
reinterpret_cast<char*>(0)
↑間違い

666 名前:デフォルトの名無しさん :04/06/20 15:39
背後が壁の席でしか仕事をしない俺だって愛用の道具はあるさ

667 名前:デフォルトの名無しさん :04/06/20 15:42
reinterpret_cast<char*>(0)
これって何で間違いなの?

668 名前:547 :04/06/20 15:45
>>663
ここでいう,安全性とは
利用者と設計者の意志疎通がうまく行ってないことに起因する危険に対する安全性です.
そういう意味ではSTLもコンパイラも自前で設計した方が安全ですよ.
ただ,私にはその能力も時間も無いので機能的規模が小さくなっちゃうでしょうけど.


669 名前:デフォルトの名無しさん :04/06/20 15:51
>>668

>利用者と設計者の意志疎通がうまく行ってないことに起因する危険に対する安全性です.
ここまではいいが

>そういう意味ではSTLもコンパイラも自前で設計した方が安全ですよ.
なんでそうなるんだよw

おまえさん、プロのコンパイラ屋よりもマシなコンパイラ作れるのか?

670 名前:547 :04/06/20 15:55
>>669
利用者と設計者が同一人物であるほうが利用者と設計者の誤解が少ないと言いたいのです.

> おまえさん、プロのコンパイラ屋よりもマシなコンパイラ作れるのか?
そんなの無理です(笑).
だから「機能的規模が小さくなっちゃう」と書いてるんですよ.
まぁそんなのは最早STLとは呼べないんでしょうが.


671 名前:デフォルトの名無しさん :04/06/20 16:24
>>669
なんでそうなるんだよw

672 名前:デフォルトの名無しさん :04/06/20 16:26
>>670
>利用者と設計者が同一人物であるほうが利用者と設計者の誤解が少ないと言いたいのです.
・・・・・・

673 名前:デフォルトの名無しさん :04/06/20 16:37
>>670
大体同じ意見。細かいところに話が行き過ぎてる気がするな。
ライブラリ作成者と利用者という立場で分けて考えると
ライブラリ作成者が課した決まりで利用者を縛りたいのは当然。
今話題になっている継承可能か否かという条件に関しては、それを行う時に
1. もしJavaのfinalのような言語仕様があれば、
利用者にも原因がわかりやすいコンパイルエラーにできる。
2. >>543のような仕掛けを用意して、とりあえずコンパイルエラーにする。
3. 継承不可能とドキュメントに書いておく。
4. (別の解法だが)効率無視してデストラクタvirtualで好きに継承させてしまう。
これくらいの選択肢があるぞと。
で、最もスマートなのは1。ドキュメントもほとんどいらないが今のC++では現実的じゃない。
2、3はドキュメント化して、利用者に守らせることが必須になる。
(2の場合は違反して継承した場合のコンパイルエラーを示しておかないと混乱の元)
4をやるかどうかはライブラリ作成者のポリシーによる。
俺は一連の流れからこんなふうに感じた。

674 名前:デフォルトの名無しさん :04/06/20 16:44
>>665
g++3.3ではポインタに関してコンストラクタ記法はCスタイルキャストと全く同じ挙動を取るから、
(char *)(0)がどちらと等価かは実験では判断できない様だ。
従って、実際上どうでも良い事になるな。
文法上はどうなんだろう。

675 名前:デフォルトの名無しさん :04/06/20 16:46
>>672
中点を幾つも書きたいだけなら、いちいち引用とかしなくていいです ;-)

676 名前:547 :04/06/20 16:51
>>673
Great! 私の意見はこの中にまとまってます.


677 名前:673 :04/06/20 16:53
>>547は潔癖の傾向があって
自分が提供したライブラリを利用した場合、
どんなヘボプログラマが利用者でも可能な限り問題が起きないように
したいと思っているんだろうな。気持ちはよくわかる。

virtualの効率に関して言えば、最近だとケータイアプリの
ゲームなんかを作っている人は気にするんではなかろうか。
こういう環境で汎用的なライブラリを作ろうとすると、
「何でもvirtual付けとけ」とはならないような気がする。

678 名前:547 :04/06/20 17:04
>>673
あぁ,しまった.「private,protected継承」ってのも入れて下さい.
安全性を第一に優先する私としては,
1. Javaのfinalのような言語仕様
2. >>543のような仕掛けを用意して、とりあえずコンパイルエラーにする。
3. private,protected継承を検討する.
4. 効率無視してデストラクタvirtualで好きに継承させてしまう。
5. 継承不可能とドキュメントに書いておく。
の順でしょうか.


679 名前:デフォルトの名無しさん :04/06/20 17:04
デストラクタがvirtualでないクラスを継承したら警告するコンパイラってないの?

680 名前:547 :04/06/20 17:07
>>678
よく考えると,「private,protected継承」するのは利用者で,
他の項目は設計者ですね.
すみません.


681 名前:673 :04/06/20 17:15
>>678
俺の見た感じこの話にはいくつか段階があって
Q. ヘボ利用者にポリモーフィズム周りで安全なライブラリを提供するには?
A1. デストラクタproteccted
A2. デストラクタvirtual
A3. 継承禁止
A3-1. Javaのfinalのような言語仕様
A3-2. >>543のような仕掛けを用意して、とりあえずコンパイルエラーにする。
A3-3. 継承不可能とドキュメントに書いておく。
のような形だろうか。

> 3. private,protected継承を検討する.
これはライブラリ作成者側から縛れないので疑問符。

>>673で 4に関して別の解法と記したのはA3の実現方法を論じているのに
それより上位の解法を出すのは反則かなと考えていた。


682 名前:デフォルトの名無しさん :04/06/20 17:16
C++な人はdelphiを馬鹿にしますがdelphi->c++
と移る人は多いと思われます。
つまり、c++の練習用ともなっているわけで
妨害する理由がいまひとつわかりません。


683 名前:デフォルトの名無しさん :04/06/20 17:19
突然、何の脈絡もなくそんなこと言うヤツの精神構造がいまひとつわかりません。

684 名前:547 :04/06/20 17:21
>>679
g++だと,
-Wnon-virtual-dtor 非仮想デストラクタについて警告する
ってのがあるけど,なんだか効いていないようです.
あと,
-Weffc++ Effective C++ 式の指針からはずれるものについて警告する
ってのがあって,これはbase class `class Hoge' has a non-virtual destructor
と警告してくれます.


685 名前:547 :04/06/20 17:23
>>681
了解しました.


686 名前:673 :04/06/20 17:27
>>547話し続けてくれてありがとう。この話題はすごく楽しめた。
>>543のような手法を知るきっかけにもなったし。では撤収。

687 名前:デフォルトの名無しさん :04/06/20 17:29
喧嘩するなおまいら仲良くしろ(´☻ω☻`)

688 名前:デフォルトの名無しさん :04/06/20 20:36
>>667
まずは前提として→http://www.kouno.jp/home/c_faq/c5.html

reinterpret_cast<char*>(0)だと、int型の値0のビットパターンによるchar*型の値になる。
static_cast<char*>(0)だと、char*型のヌルポインタになる。
ヌルポインタが欲しい場合なら、前者は間違い。

689 名前:デフォルトの名無しさん :04/06/20 20:42

  Λ_Λ  \\
  ( ・∀・)   | | ガッ
 と    )    | |
   Y /ノ    人
    / )    <  >__Λ∩
  _/し' //. V`Д´)/ >>688
 (_フ彡        /


s/ヌルポ/空ポ/

690 名前:デフォルトの名無しさん :04/06/21 00:07
g++って、using namespace stdなしでcout使っても怒られない。
-Wall使ってもだめ。
どうすれば、ちゃんと怒られるようになるの?

691 名前:デフォルトの名無しさん :04/06/21 00:08
>688
ダウト。
5.2.10-8 に明示的に書いてあるべ。
| 8 The null pointer value (4.10) is converted to the null pointer value of the destination type.
従って、reinterpret_cast<char*>(0) は char* 型のヌルポインタになる。
後、reinterpret_cast による変換は実装定義だからビットパターンが同じになるとは限らない。
サイズが十分なら「戻したとき」に同じになるだけ(5.2.10-5)。

692 名前:デフォルトの名無しさん :04/06/21 00:13
>>690
間違って iosteram.h をインクルードしてない?

693 名前:デフォルトの名無しさん :04/06/21 00:14
>>692
そんな奇妙な名前のものはインクルードしていません。

694 名前:デフォルトの名無しさん :04/06/21 00:15
>690
g++ (GCC) 3.3.1 (cygming special) だとオプションなしでしっかりと怒られますが何か?

特定の環境に依存した話題は↓の方が望ましい。

【初心者歓迎】C/C++室 Ver.7【環境依存OK】
http://pc5.2ch.net/test/read.cgi/tech/1086373839/

つか、g++ ならむしろこっちか。

GCCについて part3
http://pc5.2ch.net/test/read.cgi/tech/1072484422/

695 名前:デフォルトの名無しさん :04/06/21 00:23
>>694
Cスレに帰ってください。

696 名前:デフォルトの名無しさん :04/06/21 00:49
まずこんな関数が有るとして
bool Foo(){
return false;
}
でこの時、
main(){
 int a = 0;
 bool b = true;
 if (a == 0 && b || Foo())  // A
  a = 1;
 if (a == 0 && b || Foo())  // B
  a = 1;
}
と言う事をするとAではFoo()は呼ばれません。
これはbがtrueだからFooを実行しなくともifは真になる為、呼ばれないのは解ります。
しかしBではFoo()が呼ばれてしまいます。
漏れ的考えではa=1になってる為に最初のa == 0で偽になり、その後の条件は実行されないと思っていましたが・・・。
これは一体何故でしょう?
なお、コンパイラはVC++6.0です。

697 名前:デフォルトの名無しさん :04/06/21 00:56
('A`)<ヒロシです…

698 名前:デフォルトの名無しさん :04/06/21 00:57
>>696
B のほうは
if (偽 && 偽 || Foo()) // B
なんだから、
if (偽 || Foo()) // B
と同値で、まだ Foo() によって真になる可能性がある。


699 名前:デフォルトの名無しさん :04/06/21 00:58
>a=1になってる為に最初のa == 0で偽になり、その後の条件は実行されないと思っていましたが・・・。

左辺で偽になってるために、右辺が実行されるのでは....


700 名前:デフォルトの名無しさん :04/06/21 00:58
おっと間違い、最初のは
if (偽 && 真 || Foo()) // B
ね。結論は変わらんが。


701 名前:デフォルトの名無しさん :04/06/21 01:00
>>696 || の意味分かってるか?

702 名前:デフォルトの名無しさん :04/06/21 01:08
>>696
&&と || の優先順位の仕様を確認しよう。
MSDNだと、「優先順位と評価順序」という項目があるはずです。



初心者ほどわざと難しく書いて自分を混乱させるのが得意だからなぁ。
「難解な書き方するのがプロ」とかは、思わない方がいい。
素直に括弧つけてれば避けられるようなヒューマンエラーは自力で避けよう。

703 名前:688 :04/06/21 01:17
>>691
ごめん。調べてみたら、まだ結論が出てない話みたい。
ttp://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#463
漏れの意見は"SUGGESTED RESOLUTION"と同じく、
reinterpret_cast<T*>(0)は実装定義の変換であるべきだと思う。

そして、null pointer(これならガッてされない?)を取得する方法として
reinterpret_cast<T*>(0)としない理由を、「間違い」ではなくて
「static_cast<T*>(0)のほうが良い」と訂正しておく。

あと、
s/値0のビットパターンによる/値0から実装定義の変換によって得られる/
これでいいかな?

704 名前:デフォルトの名無しさん :04/06/21 01:20
s/ってなんでつか(´・ω・`)

705 名前:デフォルトの名無しさん :04/06/21 01:22
ヒューマンエラーのリスクを極力減らしてこそ、プロだ罠。

ポインタだろうが配列だろうが、パフォーマンスはそんなに変わらんし、
無闇にポインタ使うのは最初のうちだけに汁。
かといって無闇に関数に参照渡しするのはマズイけど。

706 名前:デフォルトの名無しさん :04/06/21 01:24
>>704
swap(文字列置換)
viエディタやPerl言語などで用いる有名な正規表現

707 名前:デフォルトの名無しさん :04/06/21 01:25
>>704
sedスクリプトの置換コマンド。たぶんsubstituteの略。

708 名前:704 :04/06/21 01:25
>>706
ありがとう(´・∀・`)
ぐぐっても出てこなかたーYO!

709 名前:704 :04/06/21 01:27
>>707
同じくサンクスコ(・∀・)
なんかのスイッチかと思いまつた


710 名前:696 :04/06/21 01:33
あ、そうか、||の方を括弧で括らなきゃ駄目でしたね。
アホだ、俺。あまりに初歩過ぎて気が付かなかった。


つか、今までコレよくまともに動いてたな。
たまたまデバッグで発見したんだけど。

711 名前:デフォルトの名無しさん :04/06/21 02:00
>>709
ちなみに>>706がネタで、>>707がマジ。

712 名前:デフォルトの名無しさん :04/06/21 02:18
>>710
自分のソースなら間違いと気付けるけど、
他人のソースだった場合は、間違いなのか意図的なものなのか、
分からない事が多い。

713 名前:デフォルトの名無しさん :04/06/21 03:07
あるなあ、それ。
しみじみ。

714 名前:デフォルトの名無しさん :04/06/21 06:18
>>690
歴史的な事情により、そういうバージョンも残っている
STLも初期のバージョンではstdで囲われていなかった


715 名前:デフォルトの名無しさん :04/06/21 06:20
>>702
そーゆーことを言いながら
素直に憶えれば避けられるようなヒューマンエラーは放置か

716 名前:デフォルトの名無しさん :04/06/21 08:38
他PGの文法理解度に依存した(もしくは、甘えた)記述を
避けてこそ堅牢な開発が可能。

「素直に憶えれば避けられる」とか、気合とか、修行とか、
精神論まがいな言動をカマす人間は、
一生、独りでソース管理やってればいいだけのこと。

先入観が大きいほどに見逃す危険も大きくなるという
人間の心理を理解できない、>>715が実に憐れだ。

717 名前:デフォルトの名無しさん :04/06/21 08:49
ぶっちゃけ、「自分以外のPGはアホだから配慮してやる」でも構わん。

718 名前:デフォルトの名無しさん :04/06/21 09:09
ポインタとオーバーロードと標準変換のからみってどう思う?
char* c;
fc(c);
の呼び出しって、void fc(char*)が存在しない場合、
だいたい次の順で呼び出されるのが決まる。

1.fc(char*) or fc(char* const)
2.fc(const char*) or fc(const char* const)
3.fc(volatile char*) or fc(volatile char* const)
4.fc(const volatile char*) or fc(const volatile char* const)
5.fc(void*) or fc(void* const)
6.fc(const void*) or fc(const void* const)
7.fc(volatile void*) or fc(volatile void* const)
8.fc(const volatile void*) or fc(const volatile void* const)
9.fc(bool) or fc(const bool) or fc(volatile bool) or fc(const volatile bool)


719 名前:デフォルトの名無しさん :04/06/21 09:27
>>718
> fc(char*) or fc(char* const)
これ、オーバーロードじゃないよ。同じ関数。

720 名前:デフォルトの名無しさん :04/06/21 09:35
>>718
> fc(bool) or fc(const bool) or fc(volatile bool) or fc(const volatile bool)
これも全部同じだな。

721 名前:デフォルトの名無しさん :04/06/21 11:56
fc(char*) or fc(char[])
これも同じだな。

722 名前:デフォルトの名無しさん :04/06/21 12:17
>>681
Java や C# じゃないんだから、非ポインタで普通に(ポリモじゃなく)クラスとして便利に使える
場面も多々あるわけで、ポリフォできないから継承ダメ、っていうのは方向性として漏れはすきじゃないなー。

派生クラスから基底クラスへのポインタに変換するトコがあればエラーなり警告なり出してくれる程度でいいや。

723 名前:デフォルトの名無しさん :04/06/21 18:05
連想配列を使おうと boost を導入したのですが、
連想配列を扱う関数名が分かりません。
知ってる方がいれば教えてほしいのですが。

724 名前:デフォルトの名無しさん :04/06/21 18:15
>>723
連想配列なら標準のstd::mapがお勧め。
ちなみにboostのProperty Mapはmapっぽいものに対する
共通のインターフェースであって、連想配列そのものではない。

725 名前:デフォルトの名無しさん :04/06/21 18:15
【教えてください】
いま、C++でカウンターCGIを作ってるんですが、
更新を押してもカウントしなようにするには
なにを使えばいいのですか?

なにかヒントになりそうなページとかあったら教えてください。


726 名前:718 :04/06/21 18:18
>>719-721
フォローどうもです。
fc(char*) = fc(char[]) = fc(char* const)
fc(const char*) = fc(const char[]) = fc(char const*)
ですね。
後から関数が加わったときに呼び出し先が変わると困る場合は
標準変換に頼って関数を呼びださないで
きっちりキャストしとかないとまずいってことなのかな。



727 名前:デフォルトの名無しさん :04/06/21 18:20
ヒントになりそうなページ
http://pc5.2ch.net/php/

728 名前:デフォルトの名無しさん :04/06/21 18:22
>後から関数が加わったときに呼び出し先が変わると困る場合は
こういう場合はオーバーロードしない方がいいんじゃないか?

729 名前:デフォルトの名無しさん :04/06/21 19:58
delete [] a, b;
とした場合ってaもbも配列扱いのdeleteになるのでしょうか?
それとも
int *a, b;
みたいになっちゃうのでしょうか?

730 名前:デフォルトの名無しさん :04/06/21 19:59
>>716
甘ったれはそっちだろ
規格票を読んでない人がそのことの正当性を強弁する姿は
マニュアルを読んでないユーザが直情で当たり散らす姿とそっくりだ

無知そのものに罪はないが、居直りが加われば間違いなく足手まとい
初心者には厳しさの中に優しさを持って接するが
周囲の足をひっぱるお荷物は叩き出すのが唯一の正当防衛

自分の仕事に関わる規格に精通しようと勉強する人の
やる気をくじくような毒電波をまき散らすな
あんた1人の甘ったれじゃ済まされない威力業務妨害なんだよ
先輩から吹き込まれたならアフォの伝統は浄化しろ

731 名前:デフォルトの名無しさん :04/06/21 20:05
質問があります。(next = NULL)っていうのが
あるサイトのプログラムにあるのですが、
NULLって一体なんでしょうか?
文字でもないみたいだし。
教えてください。お願いします。

732 名前:デフォルトの名無しさん :04/06/21 20:20
>>731
0に展開されるマクロ。
ポインタに変換される事を意図していると表明するために使われる事がある。

733 名前:デフォルトの名無しさん :04/06/21 20:22
>>729
delete [] a; b;
となる

734 名前:デフォルトの名無しさん :04/06/21 20:24
>>729
うわ、こわっ

735 名前:デフォルトの名無しさん :04/06/21 20:25
えっと、あのC++を始めたばかりで、
マクロとかよくわからないのですが・・・
もう少し簡単に説明するとどういう事なんでしょうか?
お手数ですが、お願いします

736 名前:デフォルトの名無しさん :04/06/21 20:27
電車ガール

737 名前:デフォルトの名無しさん :04/06/21 20:29
>>731,735
逃げろ!


738 名前:デフォルトの名無しさん :04/06/21 20:30
>>734
怖くない

739 名前:デフォルトの名無しさん :04/06/21 21:20
>>735
そのレベルの質問だと初心者スレのほうがいいでしょ。
ただし、そっちでも「自分で調べろ」「入門書嫁」で終わる
可能性が高いですが。

740 名前:デフォルトの名無しさん :04/06/21 22:46
>>730
>周囲の足をひっぱるお荷物は叩き出すのが唯一の正当防衛

「言うは易し、行うは難し」だよ。
ネットで怪気炎あげるのは構わんが実際に叩き出すにしても、
そのための労力・時間も馬鹿にならん。
むしろ、甘ったれてるのは君だろ?


>自分の仕事に関わる規格に精通しようと勉強する人のやる気をくじく

そのくらいで挫けるならさっさと挫けてしまえばいい。
職人的な聖域を徹底排除することがPMにとって重要。

741 名前:デフォルトの名無しさん :04/06/21 22:51
よし!
730は740に返答するんだろうけど、
言いたいこと全部書いたら敬語に変換して送信してみよう。


742 名前:デフォルトの名無しさん :04/06/21 22:56
>>740
>「言うは易し、行うは難し」だよ。

行えない香具師からのインカムでおまんま食えてるわけだがw
職人やりたくない奴の侵入社員が何物よりも迷惑なんだよ

 や る 気 ね ー や つ は 出 て け

どこの職場にも通じる鉄則だ

743 名前:デフォルトの名無しさん :04/06/21 22:58
またスレ違いの話題で盛り上がる
頭の可笑しい方々がいらっしゃいますねw

744 名前:デフォルトの名無しさん :04/06/21 22:59
「言語の規格」と、「人間にとって理解しやすい規格」はイコールじゃない。
C/C++も例外でなく、C/C++である規格が定義されているからといって
その規格を無理に使う必要はない。

あえて思い切って、高度で煩雑な規格の使用を制限して、
多数派PGの理解レベルを優先したとしても、
決して資源の無駄にはならないだろう。

745 名前:デフォルトの名無しさん :04/06/21 23:02
>>742
人事にかかわったことがない万年下っ端は楽でいいな。

746 名前:デフォルトの名無しさん :04/06/21 23:05
>>742の職場は、職人的な高い技術が求められているにも関わらず、
新入社員がスタッフとして送り込まれてくるらしい。可哀相に(w

大した仕事でもないのに職人気取るヤシって邪魔だよな。

747 名前:デフォルトの名無しさん :04/06/21 23:07
>>744
無能PGの理解レベルを優先して何の勝負をしてるんだ、おまえんとこわw

748 名前:デフォルトの名無しさん :04/06/21 23:08
投稿者について言及してもヒートアップするだけで実りはないですよ.


749 名前:デフォルトの名無しさん :04/06/21 23:08
「人妻にかかわったことがない…」と語読。
もえ。


750 名前:デフォルトの名無しさん :04/06/21 23:10
どっちの主張もうなずけるんだがな。
不特定の人と関わる仕事をしているのであれば
これからメンテするかもしれないヘボプログラマのためにわかりやすい
書き方をしてやれる能力も必要だし、素人にはぱっと見紛らわしいような
仕様を理解しておく能力も必要でしょ。
そんな一方的な見方ばかりしてないで仲良くしてくれよ。



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