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


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

C++相談室 part50
751 名前:デフォルトの名無しさん :2006/07/02(日) 16:38:52
>>749
std::list::sort

752 名前:デフォルトの名無しさん :2006/07/02(日) 21:31:45
>>742,750
ヘッダで using namespace は曖昧さという危険性を
回避不能な形で強制的に埋め込む行為。禁止一択。

753 名前:デフォルトの名無しさん :2006/07/02(日) 21:52:26
>>750
その某フレームワークとはおそらくATL/WTLのことだろうが、
それらは、特定の名前のマクロを定義することによってusingディレクティブを行わないようにすることができる。

754 名前:デフォルトの名無しさん :2006/07/02(日) 23:37:56
>>742,750
エラーの場合に勝手に警告ダイアログとか出しやがる、
うんこライブラリに気持ち的に似ている感じがするので、
できればusingは辞めてほしい。

755 名前:デフォルトの名無しさん :2006/07/03(月) 00:18:23
>>753
BCBのVCLも同じことやってたな。
マクロを定義すると…ってとこも同じ。

756 名前:デフォルトの名無しさん :2006/07/03(月) 07:43:51
名前空間が無かった時代の名残かな

757 名前:デフォルトの名無しさん :2006/07/03(月) 11:37:48
va_argなどva_xxxにはANSIバージョンとUNIX互換バージョンが
あるみたいなんですが
windowsな環境ではどちらを使えばよいのですか?
ANSIバージョン?

758 名前:デフォルトの名無しさん :2006/07/03(月) 11:40:15
>>757
よくわからんが、 ANSI なり ISO なりのほうが移植性が高いといえるんじゃないか?

759 名前:デフォルトの名無しさん :2006/07/03(月) 19:49:14
>>757
たぶん「UNIX互換バージョン」と呼ばれているのは、
標準Cに入る前の古いヤツの事ね。

<varargs.h>←これが古い頃のヤツ。
<cstdarg>←これが新しいヤツ。(Cでは<stdarg.h>)

760 名前:101 :2006/07/03(月) 23:31:04
【初心者歓迎】C/C++室 Ver.28【環境依存OK】
http://pc8.2ch.net/test/read.cgi/tech/1149815331/933-935

これ見てやっと原因把握。VCとg++の挙動が全然違う。
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/2241.txt

VCだと
D:\>ref.exe
Test Constructor 1 : this=0012FF60 : a=3
Derived Constructor 1 : this=0012FF60 : a=3 : b=4
Test Constructor 1 : this=0012FF5C : a=2
0(Test) or other(Derived) : 1
Test Copy Constructor : this=0012FF54 : a=3
Test Copy Constructor : this=0012FF6C : a=3

g++だと
$ ./a
Test Constructor 1 : this=0x22eeb0 : a=3
Derived Constructor 1 : this=0x22eeb0 : a=3 : b=4
Test Constructor 1 : this=0x22eea0 : a=2
0(Test) or other(Derived) : 1

>>101のエラーはコピーコンストラクタが動くせいで
privateメンバに触ってるぞってメッセージだったらしい。
ということで解決というかなんと言うか。まあ参考までに。

761 名前:デフォルトの名無しさん :2006/07/03(月) 23:48:38
素人でスマンけど、なんで>>101でコピーコンストラクタが動くんだろう?
参照に代入してるとこ?

762 名前:デフォルトの名無しさん :2006/07/03(月) 23:58:08
バグだから。

763 名前:デフォルトの名無しさん :2006/07/04(火) 00:08:18
>>760
>std::ostream &out = fout ? fout : std::cout; 

そこは↓こうしたらVCも通るかも。
std::ostream &out( fout ? fout : std::cout );

#gccとVCの違いはRVO(Return Value Optimization)絡みな希ガス。


764 名前:デフォルトの名無しさん :2006/07/04(火) 05:08:10
あかん。VC8でSTLport5.0.2を入れても、>>760と同じ結果になる。
当然>>101はコンパイルできない。エラーメッセージは次のような感じ。
だいたい同じ事だろう。

c:\stlport-5.0.2\stlport\stl\_ios.h(131) : error C2248: 'stlp_std::ios_base::ios_base' : private メンバ (クラス 'stlp_std::ios_base' で宣言されている) にアクセスできません。
c:\stlport-5.0.2\stlport\stl\_ios_base.h(217) : 'stlp_std::ios_base::ios_base' の宣言を確認してください。
c:\stlport-5.0.2\stlport\stl\_ios_base.h(48) : 'stlp_std::ios_base' の宣言を確認してください。
コンパイラでのこの診断により関数 'stlp_std::basic_ios<_CharT,_Traits>::basic_ios(const stlp_std::basic_ios<_CharT,_Traits> &)' が生成されました。
with
[
_CharT=char,
_Traits=stlp_std::char_traits<char>
]

765 名前:デフォルトの名無しさん :2006/07/04(火) 07:32:20
>>103でコンパイルは通るだろ。

766 名前:デフォルトの名無しさん :2006/07/04(火) 08:27:52
>>760
こんなの見つけたよ。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#446

rvalue を使うとコピーによる一時オブジェクトが必要になるらしい。

struct B { B(); private: B(B const&); };
struct D : B {};
int main()
{
B const& x = 0 ? B() : D();
}

でも >>760>>101 の例では両方 lvalue で片方がもう一方の
ベースクラスになる場合だから一時オブジェクトは要らないはず。
VC はなぜか rvalue として処理してしまってる気配がする。
で、 rvalue として処理された場合は一時オブジェクトなんで
結果で非 const 参照は初期化できないはずなんだけど、
VC ではなぜか以下略

767 名前:デフォルトの名無しさん :2006/07/04(火) 10:14:12
>>766
つまり d が Test の参照に変換できて、その参照が d に直接結合も可能。
その結果 d が t に合致するように変換できたっつーことで
第2演算対象と第3演算対象が同じ型の時のルールが適用されて
結果は Test の左辺値になる。勿論コピーはされない。

これが規格上の動作ってことでいいのかな。

768 名前:デフォルトの名無しさん :2006/07/04(火) 11:12:35
>>766よりくどい言い回しにされても…

769 名前:デフォルトの名無しさん :2006/07/04(火) 11:26:04
lvalueが要求されているところで、
コピーコンストラクタ呼び出しがあるって時点でアウトだろ。> VC++8

770 名前:デフォルトの名無しさん :2006/07/04(火) 11:29:30
>>768
「規格上」なんだから回りくどいの当たり前。
つか>>766>>767の内容は別物だぞ?
>>766>>760がDefect Reportに載ってるどのケースに当るか、
VCはそれをどのように処理するかについての話だが、
>>767はlvalueだと一時オブジェクトが要らない理由の説明。

771 名前:デフォルトの名無しさん :2006/07/04(火) 12:06:16
ほんっとくどいなこいつ

772 名前:デフォルトの名無しさん :2006/07/04(火) 13:08:09
くどいついでに、

>>760
> >>101のエラーはコピーコンストラクタが動くせいで
> privateメンバに触ってるぞってメッセージだったらしい。

iosは、コピーされるとまずいから、
コピーコンストラクタをprivate宣言してあるだけ。定義なし。
>>101見た瞬間に気付くように。


773 名前:デフォルトの名無しさん :2006/07/04(火) 13:49:40
・・・くどいんじゃないくて焦点がズレてるな。

774 名前:デフォルトの名無しさん :2006/07/05(水) 00:28:21
つうか、ただのアホだろ

775 名前:デフォルトの名無しさん :2006/07/05(水) 06:39:13
vectorが空の時、
vector<...> v;
...
@
if (!v.empty()) {
    for (auto it = v.begin(); it != v.end(); ++it) {
        ....
    }
}

A
for (auto it = v.begin(); it != v.end(); ++it) {
    ....
}
は同じですか?

776 名前:デフォルトの名無しさん :2006/07/05(水) 08:21:33
馬鹿な質問多いな

777 名前:デフォルトの名無しさん :2006/07/05(水) 10:05:09
>>775
後者のほうが無駄なコードがなくていいんじゃないの?

778 名前:デフォルトの名無しさん :2006/07/05(水) 10:54:01
>>775
イタレータは問題ない。
emptyの時、v[n]するとまずい。

779 名前:デフォルトの名無しさん :2006/07/05(水) 12:00:43
>>778
なんの話をしてるんだ(´д`;

780 名前:デフォルトの名無しさん :2006/07/05(水) 14:10:25
わからんとは驚き

781 名前:デフォルトの名無しさん :2006/07/05(水) 14:30:24
いや。質問とは無関係の回答してたから何の話をしてるのかと。

782 名前:デフォルトの名無しさん :2006/07/05(水) 14:38:02
[]使ってアクセスする場合はemptyチェックが必要ってことだと思われ。


783 名前:デフォルトの名無しさん :2006/07/05(水) 14:42:08
>>781
>>778の上の行は質問への返事で、下の行は独り言なんだと思う。

784 名前:デフォルトの名無しさん :2006/07/05(水) 22:19:10
継承は継承でも「実装の継承」と「仕様(インタフェース)の継承」は別物らしいと
最近認識したのですが、webで断片的にページを読んで調べていてもいまいちよく判らないです

そこで、何ぞ詳しく説明してる本がないかと思ったのですが
どなたか心当たりはありませんでしょうか

785 名前:デフォルトの名無しさん :2006/07/05(水) 22:41:04
EffectiveC++

786 名前:デフォルトの名無しさん :2006/07/05(水) 22:59:14
質問です

Hoge hogehoge{
{hogehoge_a, hogehoge_b, hogehoge_c},
{hogehoge_a, hogehoge_b, hogehoge_d},
};

↑これっを↓みたいに置換できないでしょうか?
それかコンパイル時に↑みたく展開できるような宣言方法はないでしょうか。

#define HOGEEEE (hogehoge_a, hogehoge_b})

Hoge hogehoge{
{HOGEEEE, hogehoge_c},
{HOGEEEE, hogehoge_d},
};




787 名前:デフォルトの名無しさん :2006/07/05(水) 23:05:24
#define HOGEEEE hogehoge_a,hogehoge_b

Hoge hogehoge{
{HOGEEEE, hogehoge_c},
{HOGEEEE, hogehoge_d},
};

でいけない?

788 名前:デフォルトの名無しさん :2006/07/07(金) 12:51:19
Mingwのstd_vector.hのswapですが

void
swap(vector& __x)
{
std::swap(this->_M_impl._M_start, __x._M_impl._M_start);
std::swap(this->_M_impl._M_finish, __x._M_impl._M_finish);
std::swap(this->_M_impl._M_end_of_storage, __x._M_impl._M_end_of_storage);
}

/// See std::vector::swap().
template<typename _Tp, typename _Alloc>
inline void
swap(vector<_Tp,_Alloc>& __x, vector<_Tp,_Alloc>& __y)
{ __x.swap(__y); }

これでどうして中身の置き換えになるのか読み解けないです・・・
分かる人教えてけろ。


789 名前:デフォルトの名無しさん :2006/07/07(金) 12:59:01
struct A
{
void swap(A& x) { std::swap(this->i, x.i); }
int i;
};

inline void swap(A& x, A& y) { x.swap(y); }

と同じ事。

790 名前:デフォルトの名無しさん :2006/07/07(金) 13:20:44
>>788
中身がswapされるんじゃない。中身を挿しているポインタ、個数カウンタ、
アロケートされた領域、の3つが交換される。

791 名前:デフォルトの名無しさん :2006/07/07(金) 15:42:59
>>789,>>790
inline void
swap(vector<_Tp,_Alloc>& __x, vector<_Tp,_Alloc>& __y) のことを
std::swapと勘違いしていたようです。
どうも、お騒がせしました。

792 名前:デフォルトの名無しさん :2006/07/07(金) 18:20:19
ああstd::vectorのメンバ関数ね。shrink-to-fitによく使われる。

793 名前:デフォルトの名無しさん :2006/07/08(土) 11:35:52
また出た。聞いても居ないことをぺらぺら喋る、最近覚えた知識を披露したい厨様が。

794 名前:デフォルトの名無しさん :2006/07/08(土) 12:04:33
またしてもカスほど自己顕示欲が強い法則発動

795 名前:デフォルトの名無しさん :2006/07/08(土) 12:27:21
ただの質問箱ってのはつまんないから、
ネタフリがあったほうがいいかもしれない。

796 名前:デフォルトの名無しさん :2006/07/08(土) 12:28:26
boostの質問もここでおkでしょうか?

797 名前:デフォルトの名無しさん :2006/07/08(土) 12:59:04
>>796
つ[boostスレ]

簡単な質問なら初心者スレでもいいかも知らん。

798 名前:デフォルトの名無しさん :2006/07/08(土) 13:04:05
>>795
全然関係ないが、
http://mytown.asahi.com/kanagawa/news.php?k_id=15000000607070002

799 名前:デフォルトの名無しさん :2006/07/08(土) 16:39:38
なんだアサヒのイメージ向上作戦か

800 名前:デフォルトの名無しさん :2006/07/08(土) 19:31:37
>>799
それを言うならこうだろ↓

ああアサヒのメンバ関数ね。イメージ向上作戦によく使われる。

801 名前:デフォルトの名無しさん :2006/07/08(土) 23:58:21
質問です
template < class T > struct F
{
template < class T2 > void Func( T2 );
template <> void Func( int i );
};
こういうクラスがあって、T2を取る関数を書く場合
template < class T >
template < class T2 >
void F<T>::Func( T2 ){...}
でコンパイル通るのですが、2番目のintを取るように特殊化したものを
template < class T >
template <>
void F<T>::Func( int i){...}
とかくと
C2244:関数の定義を既存の宣言と合致させることができませんでした
となって通りません。どのように書けばいいのでしょうか?
VS2003.netを使用してます


802 名前:デフォルトの名無しさん :2006/07/09(日) 00:13:48
たしか外側を特殊化しないと内側は特殊化できないという規則があったような気がする。
規格書読んでみればわかるという回答でも無責任だしな、すまん。

803 名前:デフォルトの名無しさん :2006/07/09(日) 01:33:21
>>802
了解しました。ありがとうございます

804 名前:デフォルトの名無しさん :2006/07/09(日) 01:36:20
単純にインライン化すればコンパイルできるんだが、なんでだろうな。
こんな難しいことやろうとしたことが無いから、わからん。

template < class T >
class F
{
public:
template <class T2>
void Func(T2 a) { }

template<> void Func(int i) {}

};


805 名前:デフォルトの名無しさん :2006/07/09(日) 02:22:46
void Func( int i );

template<class T> void F<T>::Func(int i) {〜}

やりたいのはこういうこととは違うの?

806 名前:デフォルトの名無しさん :2006/07/09(日) 02:35:39
>>805
わかんないなら口を出すなよ恥ずかしいな

807 名前:デフォルトの名無しさん :2006/07/09(日) 03:34:20
>>801
<>→<int>

808 名前:デフォルトの名無しさん :2006/07/09(日) 11:12:01
using namespace std;
はusing ディレクティブ

using std::cout;
はusing宣言

で合ってる?

809 名前:デフォルトの名無しさん :2006/07/09(日) 11:50:45
7.3.3 The using declaration [namespace.udecl]
using-declaration:
using typenameopt ::opt nested-name-specifier unqualified-id ;
using :: unqualified-id ;
7.3.4 Using directive [namespace.udir]
using-directive:
using namespace ::opt nested-name-specifieropt namespace-name ;

810 名前:デフォルトの名無しさん :2006/07/09(日) 18:26:40
>>807
お、これでコンパイルできた。
だけど、実際にインスタンスを作製して、メンバを呼び出すとき


F<int> f;
f.Func(100);
f.Func<int>(100);
f.Func<>(100);

どれを呼び出しても、
template < class T >template < class T2 > void F<T>::Func(T2)
こっちが使われるみたい。

811 名前:デフォルトの名無しさん :2006/07/09(日) 18:42:57
>>801
template < class T >
struct F
{
template < class T2 > void Func( T2 );
void Func( int i );
};
じゃだめ?


812 名前:デフォルトの名無しさん :2006/07/09(日) 18:53:25
>>811
それだとテンプレートの明示化とは違った、普通のメンバになるから
呼び出すときに

Func(int)を呼び出すときは
f.Func(100);

Func(T2)を呼び出すときは
f.Func<>(100);

と使い分けなくちゃいけない。


813 名前:デフォルトの名無しさん :2006/07/09(日) 19:08:45
>>812
引数がintかint以外かでディスパッチしたいだけなんじゃないの?

f.Func(100);
f.Func(100.0);

で呼び分けるだけじゃダメなのかい?


814 名前:812 :2006/07/09(日) 20:06:49
>>813
すまん、俺が勘違いしてたみたいだ。
確かに、それでうまくいきますね。
ってことは、template 関数の特殊化って何のためにあるんだろうと。わからなくなってきた。。
半年ROMることにするorz

815 名前:デフォルトの名無しさん :2006/07/09(日) 20:27:48
>>801さんの方法試してみます。

816 名前:デフォルトの名無しさん :2006/07/09(日) 23:32:33
C++の企画書(日本語)ってどこかで手に入れられると聞いたのですが、
どこで手に入れられるのでしょうか?


817 名前:デフォルトの名無しさん :2006/07/09(日) 23:42:57
JIS

818 名前:デフォルトの名無しさん :2006/07/09(日) 23:45:50
JIS X3014で適当に調べろ。後は知らん

819 名前:デフォルトの名無しさん :2006/07/09(日) 23:46:17
>>816
http://www.google.co.jp/search?q=%22JIS+X+3014%3A2003%22
画像形式のものならダウンロードできる。

日本語っていう条件がなければ >>6
↓ここからダウンロードできるドラフトがお勧め。
> [JTC1/SC22/WG21 - C++]
>  http://www.open-std.org/jtc1/sc22/wg21/

820 名前:デフォルトの名無しさん :2006/07/09(日) 23:46:37
ttp://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=JIS+X+3014%3A2003&dantaiCd=JIS&status=1&pageNo=1

821 名前:デフォルトの名無しさん :2006/07/09(日) 23:59:22
>>817
>>818
>>819
>>820
どうもありがとうございます。

822 名前:デフォルトの名無しさん :2006/07/10(月) 00:41:10
>>821
http://www.jisc.go.jp/
ここで、「JIS検索」 → X3014 で検索 → あとはがんばれ

823 名前:デフォルトの名無しさん :2006/07/10(月) 01:13:06
winでcygwinのgccで以下のコードを

gcc -lstdc++ a.cpp

とすると

/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccfRcOaV.o:a.cpp:(.text+0xd): undefi
ned reference to `std::basic_string<char, std::char_traits<char>, std::allocator
<char> >::size() const'
/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccfRcOaV.o:a.cpp:(.text+0x60): undef
ined reference to `std::basic_string<char, std::char_traits<char>, std::allocato
r<char> >::operator[](unsigned int) const'

とずらずらとエラーが出ます

#include <string>
#include <iostream>

int main(void ) {
std::string s = "a";
std::cout << s << std::endl;
}

gccのバージョンは
gcc --version
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.

どこがまずいのでしょうか?

824 名前:デフォルトの名無しさん :2006/07/10(月) 01:41:27
>>823
gcc a.cpp -lstdc++
g++ a.cpp

825 名前:823 :2006/07/10(月) 01:49:10
>>824
僕があほでしたすいませんでした!!

826 名前:デフォルトの名無しさん :2006/07/11(火) 00:16:07
最近C++を勉強しなおしてるんですが、
ODR (One Definition Rule)違反とやらは

namespace{int val;}
template<typname T>
class A {
void foo(T t) { val = 0;}
};

テンプレートクラスAが実体化する時に
valが外部リンケージを持たないのでヤバイよ

っていう認識でいいんですかね

827 名前:デフォルトの名無しさん :2006/07/11(火) 00:25:04
>>826
なぜそうなる?
定義の重複は許しませんよっていうルールだ。
その例は確かに違反だが、 template に限ったルールじゃない。

ついでに、その例で val は外部リンケージ持ってるよね?

828 名前:デフォルトの名無しさん :2006/07/11(火) 00:41:49
>>827
レスありがとうです
templateはあくまで例なんですが、
他の翻訳単位から実体化する時にvalを参照する場合、
翻訳単位毎に違うvalを参照する→ODRの原則に違反

という認識でいいのかなと思って

思い切り言葉足らずでしたね

>ついでに、その例で val は外部リンケージ持ってるよね
すいません。static int val;と書く予定がコピペ間違えました


829 名前:デフォルトの名無しさん :2006/07/11(火) 10:40:14
>>828
SunStudio の C++ ではコンパイル時にエラーになるらしい。下記参照。
http://developers.sun.com/prodtech/cc/documentation/ss11/ja/mr/READMEs/c++.html#cUndefined

830 名前:デフォルトの名無しさん :2006/07/11(火) 14:44:29
template<typename T, size_t N>
size_t NumberOfElements(T (&)[N])
{
return N;
}

配列の要素数を取得するこんなの、標準やboostにありますか?

831 名前:デフォルトの名無しさん :2006/07/11(火) 15:17:16
----------a.h----------
template <class T>
class A {
public:
 typedef T type;
 type f();
private:
 type data;
};

----------a.cpp--------
#include "a.h"

template <class T>
type A<T>::f()
{
 return data;
}

このコードをコンパイル(VC7.1)しようとすると
a.cpp(4) : error C2143: 構文エラー : ';' が 'A<T>::f' の前にありません。
a.cpp(4) : error C2501: 'type' : 識別名を宣言するのに、型が指定されていません。
というエラーが出ますが理由がわかりません。
typedefを使わずにtypeをTに変えるとコンパイルできます。
エラーの理由を教えてください。


832 名前:デフォルトの名無しさん :2006/07/11(火) 15:24:15
A<T>::type

833 名前:デフォルトの名無しさん :2006/07/11(火) 16:04:59
c++用のgetopt的なライブラリって無いでしょうか?
手軽に使えるものがあるといんですが。。

834 名前:デフォルトの名無しさん :2006/07/11(火) 16:12:37
>>833
boost::program_options


835 名前:831 :2006/07/11(火) 16:15:33
>>832
ありがとうございました。
a.cppの4行目を
typename A<T>::type A<T>::f()に変えたらコンパイルできました。

836 名前:デフォルトの名無しさん :2006/07/11(火) 16:21:02
VC6で
for ( int i = 0; i < 3; i++ ) { }
このコードは以下と等価ですが
int i;
for ( i = 0; i < 3; i++ ) {}

このバグとも思える仕様はVC7や8
では直っているのでしょうか?


837 名前:デフォルトの名無しさん :2006/07/11(火) 16:26:02
>>836
コンパイラのオプションで指定できる。

838 名前:デフォルトの名無しさん :2006/07/11(火) 16:27:05
>>836
VC8では直ってる。
VC7は知らん。

839 名前:837 :2006/07/11(火) 16:29:56
>>836
VC7.1の話です。

840 名前:デフォルトの名無しさん :2006/07/11(火) 16:39:51
>>839
/Zc:forScope
http://msdn.microsoft.com/library/ja/vccore/html/vcrefZcforScope.asp

ちなみに昔はむしろその仕様で正しかった。
VC++はそれをいつまでもずるずる引きずっているだけで、単純にバグと言い捨てるものどうかとは思う。

841 名前:デフォルトの名無しさん :2006/07/11(火) 16:41:37
>>830
boost::size
ただし、Boost.Rangeの一部だから、コンテナに使うとメンバのsize()を呼ぶなどという具合で、適用できる幅が広い。

842 名前:デフォルトの名無しさん :2006/07/11(火) 16:48:18
>>840
それ今もひきずってんの?
838の
>VC8では直ってる。
はスコープのデフォルトを直したってことかな


843 名前:デフォルトの名無しさん :2006/07/11(火) 16:52:57
簡単なコード書いてコンパイルしてみればすぐわかるんじゃないか?

844 名前:デフォルトの名無しさん :2006/07/11(火) 16:54:43
>>843
ごめんVC手元にないんだよ


845 名前:デフォルトの名無しさん :2006/07/11(火) 16:58:20
>>842
VC8はデフォルトで/Zc:forScopeが指定された状態になっている。

846 名前:838 :2006/07/11(火) 16:59:38
俺様の言うことが信用ならんということか。
だったら最初からこんなところで聞くなヴォケ

847 名前:デフォルトの名無しさん :2006/07/11(火) 17:12:05
>>846
聞き返したぐらいで気を悪くしないでおくれ
ごめんよ

>>845
どうもありがとう


848 名前:デフォルトの名無しさん :2006/07/11(火) 17:15:18
てことは
VC7では直ってなくて
VC7.1ではデフォルトでは直ってないがオプション指定で回避可能
VC8直ってる

でOK?

849 名前:デフォルトの名無しさん :2006/07/11(火) 17:34:07
std::vectorやstd::map等のコンテナにはswapメンバ関数がありますが
これは例外を投げない事は保証されているのでしょうか?

850 名前:デフォルトの名無しさん :2006/07/11(火) 17:43:12
VC6 でも /Za でそのスコープに関しては直せる。
ほかに多くの問題が出るので、実質使えないオプションだけど。

851 名前:デフォルトの名無しさん :2006/07/11(火) 18:38:38
>>848
VC7.1では/Zc:forScopeなしでfor文の外でも使えるけど、
外で既に同名の変数が宣言されていたらそっちを優先するようになった。
例えば
void func() {
 int i;
 for(int i;;) {
 }
}
これはVC6だと宣言がダブってるってエラーが出てコンパイルできなかった。

852 名前:851 :2006/07/11(火) 18:40:28
ミスった。正しくは
-外で既に
+ローカルスコープのどこかで

853 名前:デフォルトの名無しさん :2006/07/11(火) 18:40:55
>850
#include <windows.h>
しなければ何ともないぜ。

854 名前:デフォルトの名無しさん :2006/07/11(火) 18:42:28
アラインメントが指定できなくなるのよねぇ。

855 名前:デフォルトの名無しさん :2006/07/11(火) 18:59:36
>>849
Sequence (std::vector, std::deque, std::list) については保証されています.
AssociativeContainer (std::[multi]set, std::[multi]map) に関しては,
要素比較の関数オブジェクトのコピーコンストラクタが例外を送出しない限り,
swap も例外を送出しないことを保証しています.

856 名前:849 :2006/07/11(火) 19:45:16
>>855
ありがとうございます。
比較関数オブジェクトで思いついたんですけど
アロケータが異なる場合も保証されないと思うんですけどどうなんでしょ?

857 名前:デフォルトの名無しさん :2006/07/11(火) 21:18:59
>>856
>アロケータが異なる場合も保証されないと思うんですけどどうなんでしょ?
「異なる」の意味が少なくとも2つ考えられるんですけれど,どっちでしょうか?
「型が異なる」場合の話なら,そもそも異なるアロケータ型を指定された
コンテナ同士は swap が定義されていないですし,
「オブジェクトが異なる」場合の話なら,標準の範囲では
コンテナに対して指定するアロケータのオブジェクト各々が
異なる状態を持つことを明示的に禁止しています.

858 名前:849 :2006/07/11(火) 21:46:46
>>857
「オブジェクトが異なる」場合の話です。
VC++2003付属のSTL見たら、アロケータを比較して別の処理してたので。

>コンテナに対して指定するアロケータのオブジェクト各々が
>異なる状態を持つことを明示的に禁止しています.

知りませんでした。
じゃあ何故コンストラクタでアロケータのインスタンスを取るようになっているのか
と思ったりするんですが。

859 名前:デフォルトの名無しさん :2006/07/11(火) 23:06:49
>>830
先日 boost で提案されてた。 VC6 でも使える実装とか、いろいろこねくりまわしてたが、
結局どうなったかわからん。少なくとも現時点では含まれていない。

860 名前:デフォルトの名無しさん :2006/07/11(火) 23:14:40
>>857-858
異なるアロケータインスタンスは禁止されているわけじゃない。
ライブラリの実装に対してそれらをサポートすることを要求していないだけ。

しかしサポートしようとすると難しい問題が発生するので
現存するほとんどの実装ではサポートされていない。

最近 STLport で条件付だがサポートされたらしい。

861 名前:デフォルトの名無しさん :2006/07/11(火) 23:14:54
>>859
>>841

862 名前:859 :2006/07/11(火) 23:35:53
>>861
あーごめん。見逃してた。先日提案があったのはコンパイル時定数って話ね。

863 名前:デフォルトの名無しさん :2006/07/12(水) 00:00:24
みっともないなぁ。この知識披露厨は。

864 名前:デフォルトの名無しさん :2006/07/12(水) 03:09:31
x個の要素のそれぞれの出現確率に従って、
y個の要素をランダムに選び出す高速な方法ってないでしょうか。
例えば、各アルファベットの出現確率に合わせて
y個のアルファベットを選び出すような感じです。

累積ヒストグラムを作ってやる方法位しか思いつかないんですが、
もっと高速な方法は無いでしょうか?

865 名前:デフォルトの名無しさん :2006/07/12(水) 03:25:48
>>863
お前はもっとみっともないけどな

866 名前:デフォルトの名無しさん :2006/07/12(水) 04:17:15
>>865 同意

867 名前:デフォルトの名無しさん :2006/07/12(水) 09:24:23
C++の洋書のclassesって項目の中に
post-construction
て単語があるんだけどこれはどういう意味ですか?
コンストラクタに関するうんぬんの後の処理って意味?

868 名前:デフォルトの名無しさん :2006/07/12(水) 10:05:34
文脈によると思いますが、クラスの説明のところなら、メモリアロケートして、
インスタンスにvirtual tableの設定などをした後ってことだと。
その後、ユーザ定義コンストラクタのコードが実行される。


869 名前:デフォルトの名無しさん :2006/07/12(水) 10:26:03
>>867 普通に、「コンストラクタ実行後」ってことじゃないの?

870 名前:デフォルトの名無しさん :2006/07/12(水) 11:45:47
new 演算子について質問です。

通常、
class X* ptr = new X();

という感じでインスタンスを作成してから

delete ptr;

でメモリ開放します。ですが、

new X();

という形で作成した場合は、どうやって開放すればいいでのしょうか?
よろしくお願いします。


871 名前:デフォルトの名無しさん :2006/07/12(水) 11:57:03
>>870
言ってる意味がよく分からないが、
newした結果をどこにも格納していない場合は明示的に解放はできない。
オブジェクトがdelete this;で自身を解放するようになっていない限り、リークする。

872 名前:デフォルトの名無しさん :2006/07/12(水) 12:56:17
>>870
delete new X(); でおk

873 名前:デフォルトの名無しさん :2006/07/12(水) 14:02:53
セクションごとに区切られていないiniファイルを
読み込めるような関数ってありますか?
もしくはGetPrivateProfileString()でセクションを意識しなくてもいい方法があれば
教えてください。

874 名前:デフォルトの名無しさん :2006/07/12(水) 14:08:48
Visual Studio .NET 2003 で作業をしています。
プロジェクト名:TEST1
データセット名:TestDataset1
新しい項目の追加で「データセット」を追加し、テーブルDatasetTestを作成しました。
この時点でビルドをしてもエラーは出ないのですが
Form1(デザイン)でdatasetを追加する時に
[型指定されたデータセット]にチェックを入れ作成したデータセットを指定し
ビルドすると、自動生成されたTestDataset1.hの
public: __delegate System::Void Test1RowChangeEventHandler(System::Object * sender, Test1::TestDataset1::Test1RowChangeEvent * e);
部分で「\test1\TestDataset1.h(57): fatal error C1004: 予期しない EOF が見つかりました。」
とエラーになります。
ヘルプ等を見てもどうして突然エラーになるのか分かりません。
宜しくお願いいたします。

875 名前:デフォルトの名無しさん :2006/07/12(水) 15:15:36
C++とmanaged C++は別物

876 名前:デフォルトの名無しさん :2006/07/12(水) 15:16:59
>>874
>>1読め
スレ違い

877 名前:874 :2006/07/12(水) 15:26:36
申し訳ないです。

878 名前:867 :2006/07/12(水) 16:35:50
>>868
ありがとう
そっか、コンストラクションは構築だから単純にクラスを作った
あとでよかったのか。で、そのあとにコンストラクタが起動する・・・と

879 名前:デフォルトの名無しさん :2006/07/12(水) 20:58:55
>>878
クラスを作った→インスタンスを作った

880 名前:デフォルトの名無しさん :2006/07/12(水) 22:22:44
>>878
コンストラクションのあとにコンストラクタが起動する・・・っておかしくね?

881 名前:デフォルトの名無しさん :2006/07/12(水) 23:08:44
そうだな。頭がおかしいな。

882 名前:デフォルトの名無しさん :2006/07/13(木) 01:08:21
>>881
あーごめん。見逃してた。そうだな。頭がおかしいな。


883 名前:878 :2006/07/13(木) 11:06:50
すみません
結局post-constructionの意味は
クラスのインスタンスが作成されて
そのインスタンスのコンストラクタ
が実行されたあと
ってことですか?
それともインスタンスが作成されて、
コンストラクタが実行される前のこ
とですか?

884 名前:デフォルトの名無しさん :2006/07/13(木) 11:46:25
文脈でどちらかわかるだろうが。

885 名前:デフォルトの名無しさん :2006/07/13(木) 14:15:40
誰も言わないけど、現代英語で "post construction" っていうと公共事業や
建造物や設備等の構築後の運用・管理のことを指しますよ。
いかにC++の本でも、定義等も無しでいきなり出てきたんなら
たぶん間違いなく100%こういう意味で使ってると思うけど。

886 名前:デフォルトの名無しさん :2006/07/13(木) 15:09:18
>>867
そもそも"C++の洋書"とは何という本なのか
なにも補足せずにそう書いたということは禿の原書?

887 名前:デフォルトの名無しさん :2006/07/13(木) 18:59:54
つか、文脈でわかるだろ

888 名前:デフォルトの名無しさん :2006/07/13(木) 21:14:30
いや、推測はできても確信は持てないので・・
で、禿なら邦訳あるんだから、センテンスが特定できてるんなら
どう訳されてるか見ればいいんでないのかと

889 名前:デフォルトの名無しさん :2006/07/13(木) 22:49:40
つか、その不明な単語が初出の段落読めばわかるだろ、普通。

890 名前:デフォルトの名無しさん :2006/07/14(金) 00:58:29
>>883
英語に限らず、文脈を無視して、
単語の意味が一意に決まると考えていると、
文章読解うまくいかないよ。

母国語では自然とやっているんだけど。
国語辞典だって意味は何項目も書いてあるでしょ。

891 名前:デフォルトの名無しさん :2006/07/14(金) 08:12:42
Cygwinみたいに、UNIXのAPIをWIN APIにかぶせたりして、
WINDOWSで使えるようなツールって、ほかにありますか?

892 名前:デフォルトの名無しさん :2006/07/14(金) 08:24:50
>>891
スレ違い。
すれ立てるまでもない質問は〜というスレッドがあるはずなんだが、
ちょうど 1000 行ったところみたいだな。

893 名前:デフォルトの名無しさん :2006/07/14(金) 08:48:12
>>891
↓ここ行ってみれば?

Service for UNIX
http://pc8.2ch.net/test/read.cgi/unix/1015676742/

894 名前:デフォルトの名無しさん :2006/07/14(金) 08:50:19
>>892
ちがうところ探します。

895 名前:デフォルトの名無しさん :2006/07/14(金) 08:51:30
>>893
ありがとうございます!
いってみます。

896 名前:デフォルトの名無しさん :2006/07/15(土) 13:11:59
ヘッダに関数を書くとインライン関数になってサイズが大きくなるから使うな

と某所で書いてあったんですが、どういう意味でしょうか?
.hファイルに関数定義を書いてると#includeしてその関数呼び出すところは
全部インラインになるってこと?まじ?

897 名前:デフォルトの名無しさん :2006/07/15(土) 13:14:44
>>896
インライン展開されるか否かはコンパイラの御心次第。
コンパイラによっては、別ソースの関数でもインライン化してくれるかも知らん。
サイズを問題にするなら、コンパイルオプションを併用するのが無難。
#そしてその話題はスレ違いなので以下個別環境向けスレでどうぞ。

898 名前:デフォルトの名無しさん :2006/07/15(土) 13:33:45
バカが即レスすると見当違いも甚だしいとい見本ですな

899 名前:デフォルトの名無しさん :2006/07/15(土) 13:45:11
>>896
インライン関数になるかどうかは inline と明示するか、
クラス定義内でメンバ関数の定義まで書いてしまうかで決まる。
ヘッダに書いたからインライン関数になるわけじゃない。

サイズが大きくなるっていうのは言い訳で、
ほんとはなるべくヘッダに実装を晒すべきじゃない
ってことが言いたいんじゃないかな?

効率を求めない限りはインライン関数なんて
積極的に使うもんじゃないしね。

900 名前:デフォルトの名無しさん :2006/07/15(土) 13:51:47
最近のコンパイラはinlineつけなくてもメンバ関数じゃなくてもインライン展開するからなぁ。

>>899
>効率を求めない限りはインライン関数なんて
>積極的に使うもんじゃないしね。
kwsk

901 名前:デフォルトの名無しさん :2006/07/15(土) 13:56:56
>>900
>最近のコンパイラはinlineつけなくてもメンバ関数じゃなくてもインライン展開するからなぁ。
リンク時コード生成?まだまだ一般的じゃないような

902 名前:デフォルトの名無しさん :2006/07/15(土) 13:59:58
>>900
詳しくも何も、そのまんまだよ。インライン関数はヘッダに定義を晒す必要があるから、
関数の中身を変更したときは使ってる側の再コンパイルが要ることになるだろ。
中身を書くためには追加でヘッダのインクルードが必要になったりするしね。
ヘッダの依存関係はなるべく小さいほうがいいでしょ?

903 名前:デフォルトの名無しさん :2006/07/15(土) 14:04:27
>>900
しったか乙

904 名前:デフォルトの名無しさん :2006/07/15(土) 14:06:31
static void foo() { ... }
int main() {
 foo();
}

は、大抵のコンパイラならインライン化することない?

905 名前:デフォルトの名無しさん :2006/07/15(土) 14:07:48
>>900は別にしったかじゃないでしょww
知らなくて聞いただけなんだから
>>897はバカ無能クソ低脳カス知ったかだけど

906 名前:デフォルトの名無しさん :2006/07/15(土) 14:09:30
>>904
コンパイラの勝手だ。 foo() の中身にもよる。
それが大抵のコンパイラで事実だとしても、それに依存した
コーディングをしていいわけじゃないし。

907 名前:デフォルトの名無しさん :2006/07/15(土) 14:13:41
>>897はどこが間違ってるの?
だいたい合っていると思うんだが。

908 名前:デフォルトの名無しさん :2006/07/15(土) 14:16:43
俺もそんな間違ってないと思う

909 名前:デフォルトの名無しさん :2006/07/15(土) 14:17:14
>>907
単体では間違っていないが、質問への返答としては見当違い。

910 名前:デフォルトの名無しさん :2006/07/15(土) 14:30:56
>>909
別に検討違いじゃないと思うけど

911 名前:デフォルトの名無しさん :2006/07/15(土) 14:40:56
それはお前が897だからだろ。バカ丸出しですな。

912 名前:デフォルトの名無しさん :2006/07/15(土) 14:41:21
大体あってる。

違うという奴は、ほのめかしではなくて、きちんと指摘しろ。

913 名前:897 :2006/07/15(土) 14:41:22
まぁ、>899の方が無難な回答だろうね。
確かに漏れの回答はベクタが違う。
それを指して馬鹿だ無能だ低脳だとまぁ言いたい放題だこと。

>>901
iccの場合、オブジェクトモジュール内にインライン展開用の情報を埋めておいてリンク前に
プロシージャ間最適化している模様。
但し,gccも含めて>904のケースはコンパイル時にインライン展開してしまう。
#ついでに末尾再帰のループ化とか。

914 名前:デフォルトの名無しさん :2006/07/15(土) 14:46:37
>>913
「見当違い」と指摘されて「ベクタが違う」と言い直すのが見苦しいな。
スレ違いだと自分で言っていたのに、勝手に特定のコンパイラの話まで持ち出すし。
これではさすがに知識披露厨と罵られても仕方がない。

915 名前:デフォルトの名無しさん :2006/07/15(土) 14:49:46
>>914
ウザいな、お前。
どこがどう見当違いなのか、具体的に指摘しろ。
出来なければ消えろ。

916 名前:デフォルトの名無しさん :2006/07/15(土) 14:50:53
>>914
これは酷いな。
>>909は「指摘」なんかじゃなくてただの「言いがかり」。
「勝手に」持ち出したんじゃなくて聞かれたから答えた。
途中から読んでもこんくらいのことすぐわかる。
頭大丈夫?

917 名前:デフォルトの名無しさん :2006/07/15(土) 14:51:08
>>914

918 名前:デフォルトの名無しさん :2006/07/15(土) 14:53:16
>>913
>>899は定義を別ファイルにしてもinline化される可能性について排除しているから、
>>897の方が俺はいいと思うけどな。

919 名前:918 :2006/07/15(土) 14:55:12
>>918
「クラス定義外」別ファイル

「」が抜けた…

920 名前:デフォルトの名無しさん :2006/07/15(土) 14:56:42
register が意味なくなってるのと同様に、
inline もあんま意味ないの?

921 名前:デフォルトの名無しさん :2006/07/15(土) 14:59:37
boostが付けてるから付けておけみたいな
まあ転送関数だよ、程度の意味にしか使ってないな

922 名前:デフォルトの名無しさん :2006/07/15(土) 15:08:14
昨日「ポインタのポインタってポインタのアドレスのことですよね?」議論に
関わってただろ。

923 名前:デフォルトの名無しさん :2006/07/15(土) 16:47:30
>>920
ヘッダに関数の定義を書けるという効果があるから、
ヘッダだけの簡易的なライブラリを作るのに使える。

だめ?

924 名前:デフォルトの名無しさん :2006/07/15(土) 17:00:07
>>915
お前が消えろ。臭い。

925 名前:デフォルトの名無しさん :2006/07/15(土) 19:50:56
>>924
だまれ、糞ガキ

926 名前:デフォルトの名無しさん :2006/07/15(土) 20:12:06
そもそも、記述場所がヘッダファイルかどうかを
インラインにするかどうかの判断基準に入れてるコンパイラなんてあるの?
もちろんそうするのは勝手だろうが、
(順序でなく)記述場所によって意味が変わることになってしまうのは・・

927 名前:デフォルトの名無しさん :2006/07/15(土) 20:29:33
場所の問題じゃなくて、
リンカに頼らなくても、定義を利用できるかどうかの問題だろ。

中間コードを利用してリンカでinline展開するコンパイラもあるけどね。

928 名前:デフォルトの名無しさん :2006/07/15(土) 22:09:48
>>914 = >>863
差し詰め言いがかり厨といったところか

929 名前:デフォルトの名無しさん :2006/07/16(日) 01:07:46
>>925
お前が黙れ、糞ガキ

930 名前:デフォルトの名無しさん :2006/07/16(日) 04:23:14
とうとう無駄に歳食ってる事実だけを武器にし始めたw

931 名前:デフォルトの名無しさん :2006/07/16(日) 10:22:21
#include <iostream>
class Session {};
class SessionFactory {

public:
Session Create( );
Session* CreatePtr( );
void Create(Session*& p);
};
Session SessionFactory::Create( ) {
Session s;
return(s);
}
Session* SessionFactory::CreatePtr( ) {
return(new Session( ));
}
void SessionFactory::Create(Session*& p) {
p = new Session( );
}
static SessionFactory f; // The one factory object
int main( ) {
Session* p1;
Session* p2 = new Session( );
*p2 = f.Create( ); // Just assign the object returned from Create
p1 = f.CreatePtr( ); // or return a pointer to a heap object
f.Create(p1); // or update the pointer with the new address
}

このコードc++cookbookのサンプルコードなんだけど
p1 = f.CreatePtr()で新しいSessionがnewされて
次にf.Create(p1)でまた新しいSessionがnewされてるけど
このままじゃメモリリークしないですか?

932 名前:デフォルトの名無しさん :2006/07/16(日) 10:31:58
します

933 名前:デフォルトの名無しさん :2006/07/16(日) 10:57:49
普通にリークするな。

934 名前:デフォルトの名無しさん :2006/07/16(日) 12:01:29
メモリリークも糞も…すぐにmain()が終わってるし。
Factoryの使い方を説明しているだけのコードだろ。
小さいことにこだわるな。

935 名前:デフォルトの名無しさん :2006/07/16(日) 12:06:09
> すぐにmain()が終わってるし

そういう問題じゃない気がするが

936 名前:デフォルトの名無しさん :2006/07/16(日) 12:07:03
class C {
public:
    void setHoge(@) { ... }
    A getHoge() { ... }
private:
    tr1::shared_ptr<Hoge> hoge_;
};
このようなクラスがあったとき、@とAはHoge*かtr1::shared_ptr<Hoge>の
どちらにするのがいいのでしょうか?
Aはユーザーが誤ってdeleteできないようにtr1::shared_ptrを返す
べきとは思うのですが

937 名前:デフォルトの名無しさん :2006/07/16(日) 12:33:36
>>935
そういう問題でしょ

938 名前:デフォルトの名無しさん :2006/07/16(日) 13:02:15
>>936
get出来ないのがいいと思う。
access用のinterfaceを用意して。

939 名前:デフォルトの名無しさん :2006/07/16(日) 14:51:47
>>937
ちがう

940 名前:デフォルトの名無しさん :2006/07/16(日) 14:59:02
>>939
いや、そういう問題でしょ

941 名前:デフォルトの名無しさん :2006/07/16(日) 15:01:59
free()と違ってdeleteはデストラクタを呼ぶ。
だからmainが終わるからと言って呼ばなくて良いことにはならない。

そう書くと、今度は931のSessionにはデストラクタがないとか言われそうだけどさ。

942 名前:デフォルトの名無しさん :2006/07/16(日) 15:06:07
ひょっとして、プログラム終わる前にdeleteして廻れって言いたいのかな?

943 名前:デフォルトの名無しさん :2006/07/16(日) 15:10:11
質問をさせてください。
当方、C/C++の開発をやってみようと思って、いろいろサイトを見て回ったのですが、
統合開発環境が沢山ありすぎ、
どれを使ったらよいのかわかりません。
お勧めなものや、一般的に普及している統合開発環境ってありますでしょうか。


944 名前:デフォルトの名無しさん :2006/07/16(日) 15:15:08
WindowsならVC EE一択。
Unix系ならeditor + Makefile。
Macは知らん。

945 名前:デフォルトの名無しさん :2006/07/16(日) 15:15:14
>>942
デストラクタに重要な動作があれば必須かと。

946 名前:デフォルトの名無しさん :2006/07/16(日) 15:16:57
ほほう。
で、>>931のコードには、その重要な何かがあると?

947 名前:デフォルトの名無しさん :2006/07/16(日) 15:20:43
一番のオススメはComeau

948 名前:デフォルトの名無しさん :2006/07/16(日) 15:22:34
>>944
早いレスありがとうございました。
申し訳ありません、詳細を記述しておりませんでした。
当方の環境はWindowsXPです。

Windows系なので、一択といえるものがあり、安心しました。
VCとはVisual C++のことだと思うのですが、EEとは何の略称なのでしょうか?


949 名前:デフォルトの名無しさん :2006/07/16(日) 15:32:12
Express Edition

950 名前:デフォルトの名無しさん :2006/07/16(日) 15:33:26
>>940
コードをちゃんと嫁
読んでも分からんのなら勉強しろ
mainで解放していようがいまいが、>>931のクラスと使い方ではリークする


951 名前:デフォルトの名無しさん :2006/07/16(日) 15:45:12
ありがとうございました。
早速Visual C++ Express Edition についていろいろ調べてみようとおもいます。

952 名前:デフォルトの名無しさん :2006/07/16(日) 16:00:39
ちょっとVCEEについて調べてみたのですが、
「ゲーム作成ができない」という表現がございました。

まず、当方のやりたい事を記述していなくて申し訳ありませんでした。
ネットゲームでのツール(オートログイン、経験値時給表示、キャラ自動操作等)
を作成してみたいと考え、C/C++の開発を行おうとおもっています。

ゲーム作成とネットゲームのツール作成は
確かに異なりますが、私のやりたいことはVCEEにて可能なのでしょうか

953 名前:デフォルトの名無しさん :2006/07/16(日) 16:03:37
>>950
じゃあ、ソースを呼んだお前が>>931のクラスと使い方の問題点でも
指摘すればいいんじゃね?

954 名前:デフォルトの名無しさん :2006/07/16(日) 16:20:57
>>952
基本的に何でもできると思うよ。
平易か困難かは別問題だが。
まぁ自力で調べる力はあるようなので心配はいらないかもな。

955 名前:デフォルトの名無しさん :2006/07/16(日) 16:24:05
Express Edition って Win32 SDK がなかったり、
色々なのが欠乏してたと思う。

956 名前:デフォルトの名無しさん :2006/07/16(日) 17:04:59
>>955
それは別途Platform SDKをダウンロードすればよいだけ。

957 名前:デフォルトの名無しさん :2006/07/16(日) 17:07:48
>メモリリークも糞も…すぐにmain()が終わってるし。

すぐにmain()が終わってるから所詮サンプルコードって意味じゃね
「main()が終わる前にdeleteすればちゃんと動く」とは誰も言ってない気が

958 名前:デフォルトの名無しさん :2006/07/16(日) 18:27:10
Express EditionはMFCが使えないってことくらいか
その手の人に言わせると使えてしまうらしいが

959 名前:デフォルトの名無しさん :2006/07/16(日) 18:28:43
structとclassの違いって
structはデフォルト公開子がpublicで
classはprivate
っていうだけですか?
例えばC#ではstructはスタックにclassはヒープ
っていう違いがあるけどC++ではどうなのでしょうか?

960 名前:デフォルトの名無しさん :2006/07/16(日) 18:33:58
>>959
それだけ。全く違いは無い
one keyword, one functionality.ということで
自分はstructが好きだが
Boostを見るとみんな好みで使ってるようだな

961 名前:デフォルトの名無しさん :2006/07/16(日) 18:34:26
>>959 C# みたいな違いはないよ。

962 名前:デフォルトの名無しさん :2006/07/16(日) 18:36:26
>>939
>>access用のinterfaceを用意して
kwsk

963 名前:959 :2006/07/16(日) 18:39:22
>>960
>>961
了解。ありがとうございました

ところで
one keyword, one functionality
とはどこが出典の格言でしょうか?
それとどういう意味ですか?

一つのキーワードは一つの機能と対応すべし
って意味だと思うんですが、
もともとstructがクラスとしての機能を果たしえたのに
名前的な対応のためにclassキーワードが追加された
とかいう背景でもあるのですか?

964 名前:デフォルトの名無しさん :2006/07/16(日) 18:52:36
>>952
普通なら頑張れと言うところだが、升(チート)作りが目的なら寧ろ頑張るな。
別にMFCでGUIを作るわけじゃなさそうだからそれこそVC2005EEで充分だとは思うが。

965 名前:デフォルトの名無しさん :2006/07/16(日) 18:57:44
今更なんだろうが、
>>964 升がチートの略表記なのね。1/3圧縮か。おもしろいなあ

966 名前:デフォルトの名無しさん :2006/07/16(日) 19:03:23
>>963
Cとの互換性のためにstructではディフォルトがpublicになっているが、
オブジェクト指向のデータの隠蔽という概念からすれば、ディフォルトがprivate が望ましい。

だから新たなキーワード class が必要だったんじゃない?

967 名前:デフォルトの名無しさん :2006/07/16(日) 22:34:09
c++coding standardの項目24

「常に内部の#includeガードを書こう
決して外部の#includeガードを書いてはいけない」

の中に以下の文があるのですが、理解できません。


昔の本に提唱されていた古臭い外部の#includeガードを
使うのはやめよう。

#ifndef FOO_H_INCLUDE_
#include "foo.h"
#define FOO_H_INCLUDE_
#endif

外部の#includeガードは冗長で、現在のコンパイラでは時代
遅れである。また、インクルードする側とヘッダーファイルが
ガード名について合意していなければならない。
これにより密接な結合が生じ脆弱になる。


文章中の「インクルードする側とヘッダーファイルがガード名について
合意しなければならない」とは具体的にどういう状況なのでしょうか?


968 名前:デフォルトの名無しさん :2006/07/16(日) 22:44:49
>>967
その例では foo.h の中で使われるインクルードガードが
FOO_H_INCLUDE_ である必要がある。 foo.h が勝手に
インクルードガード変えたりすると破綻する。変更に対応しようとすると
FOO_H_INCLUDE_ を使ってる箇所を全部置換してまわる必要がある。

969 名前:デフォルトの名無しさん :2006/07/16(日) 22:47:34
>>66ほか
D&Eに何かないかとざっと探してみたが、classという言葉をSimulaから持ってきたということは書いてあったけど、
そもそもstructではだめだったのかということを直接的に書いているところは見当たらなかった。
強いて言えば4.4の中、「シンタクスは重要だ」とかが関係あるかな。
structとclassについて書いてあったのはこれくらい。
---3.5.1の後半の要約
しかしそれではなぜ私はstructとclassを別の概念にすることを選ばなかったのだろうか?
私の意図は、概念を1つにすることだった。ルールを二つにしてもそんなに困らなかったかもしれないが、
しかし単一概念のほうが、各機能の円滑な統合化と単純な実装を可能にする。
概念を一つにしなければ、"伝統的なCスタイルのプログラミング"から"抽象データタイプ"へ、
そしてさらに"オブジェクト指向プログラミング"への、円滑で斬新的な移行はできない、と感じていた。

結局のところ、こういう考え方が、実用ツールとしてのC++の成功のためにきわめて重要だったのではないだろうか。

970 名前:デフォルトの名無しさん :2006/07/16(日) 23:04:58
>>968
君、何か大きな勘違いをしてるよ

971 名前:デフォルトの名無しさん :2006/07/16(日) 23:07:44
インクルードファイル側でFOO_H_INCLUDE_によるインクルードガードをしてたらアボーンだな。

972 名前:968 :2006/07/16(日) 23:35:14
>>970-971
外部インクルードガードって、ヘッダ内のガードを外でも検査するガードのことじゃないの?

確かに >>967 で #include の後にもう一度 #define しているのは辻褄が合わないな。
どうも勘違いをしているのかもしれない。

そう思って今一度 Google に聞いてみたが、 >>967 の例がおかしいんじゃないかと思った。

973 名前:デフォルトの名無しさん :2006/07/16(日) 23:40:01
だから、>>967
#ifndef FOO_H_INCLUDE_
#include "foo.h"
#define FOO_H_INCLUDE_
#endif
みたいなインクルードのしかたは頭悪すぎ、って話でしょう

974 名前:デフォルトの名無しさん :2006/07/16(日) 23:44:45
Mozillaじゃ普通にやってることだが?

975 名前:デフォルトの名無しさん :2006/07/16(日) 23:50:14
そらMozillaの頭が悪すぎってだけだろ。

976 名前:デフォルトの名無しさん :2006/07/17(月) 00:00:34
ヘッダ自身が自身のインクルードを「ヘッダ内部」でガードするべき、ってことでしょ
ヘッダ外部にガードを委託するべきでない、と

977 名前:967 :2006/07/17(月) 00:19:04
質問の仕方が悪かったです
すみません

本では内部インクルードを以下のように定義しています
---foo.h---
#ifndef インクルードガード名
#define インクルードガード名
//ここにヘッダファイルの中身を書く
#endif

で、この内部インクルードは置いておいて、
>>967のような外部インクルード[のみ]を使う方法について、
どうしてインクルードする側とインクルードされるヘッダ側に
インクルードガード名についての合意が必要なのかが
わからないのです

たとえばa.cppで
#ifndef FOO_
#include "foo.h"
#define FOO_
#endif
としてガード名をFOO_としてfoo.hをインクルードするとき、
foo.h側は別にガード名FOO_を知らなくても何も問題が
ないじゃないかと思ったのです
一体どこらへんが合意なのかと

>>968さんの回答が理解できません
上記の例ではfoo.h自体はインクルードガードをしていないのです
foo.h自身がするインクルードガードを内部インクルードガードと
呼んでいる様なのです

978 名前:デフォルトの名無しさん :2006/07/17(月) 00:39:09
>>977
外部インクルードガードのみを使う場合でも、すべての箇所で
同じガード名を使わないと意味ないから、ガード名について
妙なスコープでの統一が要るようになるのは確かだな。
何も問題がないとは言えないだろう。

翻訳が腐ってるとか、そんなオチだったりして。

979 名前:デフォルトの名無しさん :2006/07/17(月) 00:42:59
俺はこういうことかと思った。

foo.hは次のようになっていて、
#ifndef FOO_
#define FOO_
/* ... */
#endif

hoge.cppは次のようにする。
#include "bar.h" //ここで既にfoo.hはインクルードされているかもしれない
#ifndef FOO_
#include "foo.h"
#define FOO_
#endif

hoge.cppはそのまま"foo.h"をインクルードすると、
大量の空行を読み込むことになる。それを気にするほどメモリがないから、
予めhoge.cpp側でFOO_が定義されているかどうかを調べるという具合。

で、hoge.cppのようなことはやめようというのが件の記述ではないか?

980 名前:デフォルトの名無しさん :2006/07/17(月) 00:45:34
>>977
あとね、外部インクルードガードの効果は、 #ifndef によって結局は無駄になる
ヘッダファイルの(ある意味物理的な)読み取りによるオーバーヘッドを避けるのが
よくある使用意図であって、外部インクルードガードだけを使うことなんて無いと思うよ。

この意図で多く使われるようになったが、コンパイラの実装によって
内部インクルードガードのパターンを認識してファイルの読み取り自体を
スキップするようなこともできるから、結局外部インクルードガードは無駄になる。

981 名前:デフォルトの名無しさん :2006/07/17(月) 01:28:49
>>979
多分それが正解。今手元にないから確かめられないけど、『大規模C++
ソフトウェアデザイン』に載ってた話。

で、理由がちょっと違ってて、大規模プロジェクトにおけるコンパイル時間を
短縮するために、external include guardも書きましょう、という話だったと思う。
10年前の本だからね。コンパイル時間も数時間、あるいは10時間を超える
ようなこともあたりまえだった。

だけど今では、external include guardを書かなくても、プリプロセッサが
読み込んだヘッダファイルを覚えていて、たとえ二重にインクルードしても
ディスクアクセスが発生しなくなったから、というのが理由だったと思う。

多分、多分で恐縮だけど、こんな話だったと思う。

982 名前:981 :2006/07/17(月) 01:30:18
・・・と980を読む前に書いたのでした orz

983 名前:デフォルトの名無しさん :2006/07/17(月) 02:03:26
これかな? >>981
http://www.radiumsoftware.com/0403.html
冗長インクルードガード


984 名前:v(^・^)v :2006/07/17(月) 03:13:46
そろそろ次スレが要りそうだ。
以下は次スレの準備に使わせてほしい。
相談は次スレが建つまで待ってくれ。

985 名前:v(^・^)v :2006/07/17(月) 03:25:59
テンプレの更新をしようとしたんだけど、いくらか気になったことがあったんで相談。
反対意見があれば言ってほしい。ただし肯定意見や埋まりそうな気配があれば
以下の要領でさっさと建てるんであしからず。

>>6
ISO の規格を参照するなら open-std のサイトからダウンロードできる
最新のドラフトが pdf 内でリンク貼られててすごく見やすいと思った。
こっちがあれば怪しい kuzbass のやつはリンク削除してもおk?

CUJ へのリンクは更新してみようとしたけど、新しいとこは何か
見にくいサイトになってるんで要らないかも。削除おk?
[Dr. Dobb's Journal | C++ (was C/C++ Users Journal)]
 http://www.ddj.com/dept/cpp/

cppll のリンクも確認のために見てみたけど、リンクに使われてる
バーの背景が見にくくて嫌だった。こっちも要らないかも。削除でおk?

>>11
実際の関連スレは多すぎ、 Boland C++ や C++ Builder のスレも復活してるし。
もう「スレタイ C++ で検索してくれ」でいいかな?
それでも Boost スレと GCC スレはヒットしないから、別途リンク貼る。
ATL/WTL は削除するつもり。

986 名前:デフォルトの名無しさん :2006/07/17(月) 04:42:15
その方針でいいんでない?

987 名前:デフォルトの名無しさん :2006/07/17(月) 05:20:48
>>983
リンク先のリンク先を流し読みしたところ、次のような記述がありました。

> I wrote a quick script to add redundant guards to all the source code
> and did a full build again. The number of includes reported by the compiler
> went down to 10,568 (from over 15,000). That means that there were about
> 5,000 redundant includes in a full build. However, the overall build time
> didn't change at all.
>
> Result: Zero. Apparently Visual Studio .NET 2003 (and probably most of
> the major compilers) does a pretty good job caching those includes by itself.

これは数百ファイルからなるプロジェクトをVS .NET 2003でビルドするときの
話なんですが、のべ15,000回を超えるincludeが、”冗長”guard(=external
include guard)をすることによって、10,568回に減ったそうです。

ところが、フルビルド時間は全く変わっていない。
このことから、VS .NET 2003ではincludeファイルの読み込みをうまくキャッシング
してるのであろうし、他のメジャーなコンパイラもそうであろうと結論付けています。


988 名前:デフォルトの名無しさん :2006/07/17(月) 05:24:00
『大規模C++ソフトウェアデザイン』という書籍は、当時かなりのインパクトを
業界にもたらしたんだと思う。
俺もこの本を読んだときに、脊髄に電気が走った記憶がある。
ただ、今となってはどんな内容だったのか思い出せないが・・・。

989 名前:デフォルトの名無しさん :2006/07/17(月) 05:53:20
http://www.cppll.jp/cppreference/ もテンプレに加えようぜ。

990 名前:v(^・^)v :2006/07/17(月) 05:55:48
次スレ建てた。

C++相談室 part51
http://pc8.2ch.net/test/read.cgi/tech/1153079297/

削除した ATL/WTL スレが上がってたんで何事かと思ったが、
削除してよかったような気がした。

991 名前:v(^・^)v :2006/07/17(月) 05:59:45
>>989
ごめん。足しといて。次から >>6 の■基本■に足すか。

992 名前:デフォルトの名無しさん :2006/07/17(月) 12:43:34
GNUのautoconfでは、
config.hの中で外部インクルードガード風のコードが多用されています。

インクルードガードのように二度読み込むのを防ぐんじゃなくて、
プラットフォームの違いを吸収するのが目的だけど。

こういう目的以外には外部インクルードガード「風」はほとんどないんじゃないかと思います。


993 名前:デフォルトの名無しさん :2006/07/17(月) 13:32:51
>>992
どうして外部インクルードガード風のコードが
プラットフォームの差を吸収できるのか
もうちょっと
kwsk

994 名前:デフォルトの名無しさん :2006/07/17(月) 13:52:35
992じゃないけど
クロスコンパイル環境を作りたくて
glibcを直してたときに見たなー

実際に見た方が早いよ


995 名前:993 :2006/07/17(月) 16:11:58
>>994
わかりました
これから見てみます
理解できなかったら次スレで質問させて下さい


996 名前:デフォルトの名無しさん :2006/07/17(月) 16:13:27
埋めるべ

997 名前:デフォルトの名無しさん :2006/07/17(月) 16:20:22
あっ、埋めよう

998 名前:デフォルトの名無しさん :2006/07/17(月) 16:28:53
同志社

999 名前:デフォルトの名無しさん :2006/07/17(月) 16:31:09
同志社

1000 名前:デフォルトの名無しさん :2006/07/17(月) 16:32:12
魑魅魍魎


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