04/11/25 21:12:08
関連スレ
C++相談室 part37
ｽﾚﾘﾝｸ(tech板)
【C++】STL（Standard Template Library）相談室
ｽﾚﾘﾝｸ(tech板)
BOOSTを語れゴラァ
ｽﾚﾘﾝｸ(tech板)
リンク
STLPort
URLﾘﾝｸ(www.stlport.org)
Boost
URLﾘﾝｸ(www.boost.org)
Loki
URLﾘﾝｸ(freshmeat.net)
URLﾘﾝｸ(www.geocities.com)
ISO/IEC 14882
Programming languages -- C++
URLﾘﾝｸ(webstore.ansi.org)
URLﾘﾝｸ(www.kuzbass.ru)
3:デフォルトの名無しさん
04/11/25 21:12:30
boostに関する有名な日本語サイト
・boost info
URLﾘﾝｸ(shinh.skr.jp)
・boost::spiritっちゃえ！
URLﾘﾝｸ(www.c3.club.kyutech.ac.jp)
・Let's boost
URLﾘﾝｸ(www.kmonos.net)
・Regex
URLﾘﾝｸ(www.s34.co.jp)
・Boostを使おう
URLﾘﾝｸ(www.emaki.minidns.net)
4:デフォルトの名無しさん
04/11/25 21:12:51
参考図書
・テンプレート
C++ Templates
URLﾘﾝｸ(www.amazon.com)
Modern C++ Design
URLﾘﾝｸ(www.amazon.co.jp)
C++ Template Metaprogramming
URLﾘﾝｸ(www.amazon.co.jp)
・Boost関連
Boost C++ Libraryプログラミング
URLﾘﾝｸ(www.amazon.co.jp)
The Boost Graph Library
URLﾘﾝｸ(www.amazon.co.jp)
・STL
Generic programming―STLによる汎用プログラミング
URLﾘﾝｸ(www.amazon.co.jp)
Effective STL
URLﾘﾝｸ(www.amazon.co.jp)
STLによるコンポーネントデザイン
URLﾘﾝｸ(www.amazon.co.jp)
5:デフォルトの名無しさん
04/11/25 23:45:32
追加
C++ Template Metaprogramming
: Concepts, Tools, and Techniques from Boost and Beyond
URLﾘﾝｸ(www.amazon.com)
Dependancy Inversion Principle
URLﾘﾝｸ(www.objectmentor.com)
6:デフォルトの名無しさん
04/11/26 01:17:17
>>1
_n
（ l _、_
＼ ＼ （ <_,` ）
ヽ___￣￣ ） ｸﾞｯｼﾞｮﾌﾞ!!
/ /
7:デフォルトの名無しさん
04/11/26 19:54:41
C++相談室に統一すれば良かったのに.....
8:デフォルトの名無しさん
04/11/26 20:07:43
ここを相談室と統一するのはどうかと思うけどな。
9:デフォルトの名無しさん
04/11/26 20:20:50
STLスレとBOOSTスレとこのスレを統合すべきだよね。
10:デフォルトの名無しさん
04/11/26 20:24:21
いやC++相談室とこことSTLスレが統合して(つまり標準)
BOOSTを分けるべきじゃ?
個人的には上のは全部一つのスレでいいとは思うんだけど
11:10
04/11/26 20:25:30
おっとここは標準じゃないんだったか
12:デフォルトの名無しさん
04/11/26 20:37:47
BOOSTはSTLの拡張みたいなものだから同じスレで良いと思う。
そもそもBOOSTなんてただの一ライブラリに過ぎないのにスレをわける必要があるの
だろうか。
13:デフォルトの名無しさん
04/11/26 20:47:05
MFCやATLでスレたってるじゃん
14:デフォルトの名無しさん
04/11/26 20:49:01
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
BOOSTはSTLの拡張みたいなものだから
15:デフォルトの名無しさん
04/11/26 20:57:23
1には申し訳ないが
ここと【C++】STL（Standard Template Library）相談室はもういらんだろう
以後は話題によって如何に書くべし
BOOSTを語れゴラァ
C++相談室 part37
【初心者歓迎】C/C++室 Ver.12【環境依存OK】
16:デフォルトの名無しさん
04/11/26 20:59:48
C++スレで質問する初心者はだいたい標準C++及びSTLでの回答を期待してると思うんだ。
だからこれらは一緒にしてもいいと思う。
17:デフォルトの名無しさん
04/11/26 21:01:56
以前はLokiとかも考慮してここが立ってたのにな。
前みたいにスレタイにBoostやLokiを入れてれば重複スレに置き換わられることも無かったろうに。
18:デフォルトの名無しさん
04/11/26 21:08:14
Lokiに限定した質問て最近ほとんどないので現状では
BOOSTを語れゴラァ
C++相談室 part37
どっちかに振れば良いと思う
「BOOSTを語れゴラァ」の次スレあたりで
Lokiの名前を加えるといいのではないでしょうか
19:デフォルトの名無しさん
04/11/26 21:11:20
AssocVectorについて
20:デフォルトの名無しさん
04/11/26 21:15:20
Loki って使いものになります？業務で。
21:デフォルトの名無しさん
04/11/26 21:15:45
>「BOOSTを語れゴラァ」の次スレあたりで
>Lokiの名前を加えるといいのではないでしょうか
それはつまり内容的にここのことじゃないか。
22:デフォルトの名無しさん
04/11/26 21:18:32
標準C++相談室【STL含む】スレと
C++テンプレート相談室【Boost/Loki】スレ
があればいいんだ。
これでスレタイで検索できるから重複も立たないし、
質問する人もわかりやすい。
23:デフォルトの名無しさん
04/11/26 21:19:43
>>20
あなたには無理です
24:デフォルトの名無しさん
04/11/26 21:24:24
>>22
いいですね
C++相談室は今のスレが950くらいになったら
次スレの名前として「標準C++相談室【STL含む】」を提案しましょう
で「C++テンプレート相談室【Boost/Loki】スレ」はどうします?
25:デフォルトの名無しさん
04/11/26 21:25:13
boostってそもそもtemplateじゃないのも多いのに
26:デフォルトの名無しさん
04/11/26 21:25:36
>>23
誰なら使い物になりますか？
27:デフォルトの名無しさん
04/11/26 21:27:34
>>25
別にC++非標準ライブラリ相談室でもいいぞ
28:デフォルトの名無しさん
04/11/26 21:33:59
>>20
実際の開発で Loki 使っている人いる？是非聞きたいなー。
29:デフォルトの名無しさん
04/11/26 21:34:31
crypto++とかについて話せるスレがやっとできるのか
30:デフォルトの名無しさん
04/11/26 21:36:15
lib*のC++インターフェースが用意されてない事も多いから
C/C++非標準ライブラリ相談室にしよう。
31:デフォルトの名無しさん
04/11/26 21:39:30
C/C++非標準ライブラリ相談室【Boost/Lokiなど】
とライブラリ名を入れるのを忘れないようにしよう。
入れないと絶対重複スレ立てる人いるから。
32:デフォルトの名無しさん
04/11/26 21:45:15
C++アブノーマル相談室
33:デフォルトの名無しさん
04/11/26 21:46:50
>>31
「C/C++非標準ライブラリ」というと標準以外全部含みそうなので(まぁBoost/Lokiなどといれてるけど)
C/C++環境非依存ライブラリ相談室【Boost/Lokiなど】
C/C++准標準ライブラリ相談室【Boost/Lokiなど】
とかどうでしょうか?
34:デフォルトの名無しさん
04/11/26 21:50:08
>>33
標準以外全部含んでいいんじゃないの？
専用スレがあったら誘導すればいいんだし。
そのスレタイだと初心者が迷いそう。
そもそもスレタイは初心者が迷わないために工夫するんだし。
35:33
04/11/26 21:55:10
>>34
>そもそもスレタイは初心者が迷わないために工夫するんだし。
そうかもしれない
じゃ自案は取り下げて如何を支持します
C/C++非標準ライブラリ相談室【Boost/Lokiなど】
36:デフォルトの名無しさん
04/11/26 21:57:43
そうすると今後は純粋にtemplateについての質問は
標準スレに回ることになるんですよね？
そこらへんは「柔軟に」ってことで良いのかな？
37:デフォルトの名無しさん
04/11/26 22:00:31
標準スレだろ
38:デフォルトの名無しさん
04/11/26 22:06:17
もういまどきテンプレート関数やクラスをC++じゃないなんて
言う奴もいないだろ？
39:デフォルトの名無しさん
04/11/26 22:20:09
CとC++は分けたほうがいいと思うなぁ…
40:デフォルトの名無しさん
04/11/26 22:27:48
分けられるとlibpngをC++で使いたい時とか困るよなあ…
41:デフォルトの名無しさん
04/11/26 22:56:58
標準か非標準かよりも（比較的）汎用か非汎用かの方がスレを分ける際に重要だと思うけど。
MFCがC++スレに混ざってたら、大半の人にとっては無関係な話題が延々繰り返されるわけでうざくてしょうがないが、
boostもLokiもある程度の環境で使えるんだからみんな全く無関係ってほどでもないだろ？
42:デフォルトの名無しさん
04/11/26 22:58:04
MFCは専用スレが既にあるから問題無いと思うが
43:デフォルトの名無しさん
04/11/26 23:01:11
>>41
それってポータブルかどうかってことだと思うんだけど
訳は汎用でいいの
44:デフォルトの名無しさん
04/11/26 23:03:32
>>43
気にするな。いい日本語が思いつかなかっただけだ。
45:デフォルトの名無しさん
04/11/27 00:16:33
>>41
標準 / 非標準環境非依存 / 非標準環境依存 の3通りだな
...表記長いな
46:デフォルトの名無しさん
04/11/27 17:22:23
ところで
boost/algorithm/string/replace.hppの
//! Replace all algorithm
...
\return A reference to the modified input
*/
って間違いだよね？replace_allは戻り値voidだし。
47:デフォルトの名無しさん
04/11/27 21:39:17
コピペしたときに消し忘れたっぽいね。
48:46
04/11/28 00:02:14
むしろその方が使いやすいような気がするんだけどなぁ。俺が自分で
作って使っていたreplace_allは名前が同じで引数がまったく同じシグニチャで
戻り値だけが違って変更後の文字列への参照を返してた。
49:デフォルトの名無しさん
04/11/28 00:08:42
In place modificationはvoidを返すんでいいよ。
プロトタイプ見ただけでin placeであることが分かる。
50:デフォルトの名無しさん
04/11/28 00:14:09
あぁ、なるほど。そういう考え方の切り口があったのか。
ｱﾘｶﾞﾄﾝ。
51:デフォルトの名無しさん
04/12/02 10:34:53
以下のコードをビルドするとリンカで外部参照未解決というエラーがでます
template<class T> T Test(T t){ return t; }
//template int Test<int>(int); //明示的に生成
int main(){
//Test<int>(0); //普通に使用
boost::bind(Test<int>, 1);
return 0;
}
どちらかのコメントをとると上手くいきますが、こういう仕様でしょうか？
52:デフォルトの名無しさん
04/12/02 10:36:13
>>51 VC6か？
53:デフォルトの名無しさん
04/12/02 10:43:27
>>52
そうです
54:デフォルトの名無しさん
04/12/02 10:46:17
捨てるしか
55:デフォルトの名無しさん
04/12/02 11:08:46
>>54
そうですか。2005まで粘ろうかなぁ。なんて。あははｈっは
56:デフォルトの名無しさん
04/12/02 11:18:16
2005 までは Toolkit とか 2005 Beta とか 2005 Express 使ってりゃいいじゃん
VC6 はさっさと捨てろ
57:デフォルトの名無しさん
04/12/02 12:29:27
貧乏人は死ね
58:デフォルトの名無しさん
04/12/02 12:58:30
優越感に浸りたいお年頃
59:デフォルトの名無しさん
04/12/02 13:44:50
うちは金持ちだけど6.0
60:デフォルトの名無しさん
04/12/02 13:52:18
ダメじゃん。
61:デフォルトの名無しさん
04/12/03 03:22:13
>>59
金持ちだけど技術なし？
62:デフォルトの名無しさん
04/12/09 01:13:37
下がりすぎage
63:デフォルトの名無しさん
04/12/09 01:36:48
template=天ぷらって？
64:デフォルトの名無しさん
04/12/09 01:39:31
>>63
10点
65:デフォルトの名無しさん
04/12/09 02:31:21
１０点ならいいじゃん。
オリンピックだって１０点満点で評価してるしな。
66:デフォルトの名無しさん
04/12/09 02:37:49
違う。１０００点満点中の１０点だ。よく覚えとけ。
67:デフォルトの名無しさん
04/12/09 18:13:18
boostの質問はここでいいのでしょうか？
以下のようにboost::bindを二重に使うと上手くキャストできません。
二回目のBase&を渡すところで内部でコピーされてスライスされているのでしょうか。
ポインタで渡せば問題ないのですが、参照で保持してくれるようにはできませんか？
struct Base { virtual ~Base() {} };
struct Hoge : public Base { };
void bar ( Base& b ){
if ( Hoge *p = dynamic_cast<Hoge*>(&b) )
std::cout << "bar ok" ; //ここへはこない
}
void foo ( Base& b ){
if ( Hoge *p = dynamic_cast<Hoge*>(&b) )
std::cout << "foo ok" ;
boost::bind ( &bar, b )();
}
int main(){
Hoge hoge;
boost::bind ( &foo, hoge )();
return 0;
}
68:デフォルトの名無しさん
04/12/09 18:19:54
boost::bind ( &foo, boost::ref( hoge ) )();
69:デフォルトの名無しさん
04/12/09 18:26:04
間違えた
-boost::bind ( &bar, b )();
+boost::bind ( &bar, boost::ref ( b ) )();
-boost::bind ( &foo, hoge )();
+boost::bind ( &foo, boost::ref ( hoge ) )();
ね
70:デフォルトの名無しさん
04/12/09 18:28:55
bindが引数の型を推論するときにBase &のtop-level referenceを剥いじゃうんですよね・・・
71:デフォルトの名無しさん
04/12/09 18:30:22
>>69
67の例だとhogeをラップする必要はないですよ．
72:デフォルトの名無しさん
04/12/09 18:36:09
即答ありがとうございます。上手くキャストされました
73:デフォルトの名無しさん
04/12/12 14:38:59
listのメンバであるsort関数についてお尋ねしたいのですが、
これの引数であるCompare compというのはどういう物なのでしょうか。
関数オブジェクトやfunctionalの物かと思って色々試してみたのですが、どうにも上手くいきません。
74:デフォルトの名無しさん
04/12/12 14:51:30
普通に二項の関数オブジェクト
75:73
04/12/12 15:19:55
すいません、functionalでもgreaterだけは通りました。
lessやless_equal、greater_equalでは駄目みたいです。
>>74
レスありがとうございます。では私の何かやり方がまずいっぽいです。
どうか添削して頂けないでしょうか。
#include <iostream>
#include <list>
using namespace std;
struct func_object{
bool operator()( const int& lhs, const int& rhs ){
return lhs < rhs;
}
};
int main(){
list<int> list_hage;
list_hage.push_back( 5 );
list_hage.push_back( 1 );
list_hage.push_back( 3 );
list_hage.sort( func_object() ); //error: struct func_objectから、struct std::greater<int>に変換できません(VC6)
//確認用
for( list<int>::iterator it = list_hage.begin(); it != list_hage.end(); ++it ){ cout << (*it) << endl; }
return 0;
}
76:デフォルトの名無しさん
04/12/12 15:41:31
>>75
コンパイラがまずいんじゃないの？gcc3.4.2では普通に通るぞ。
#include <iostream>
#include <list>
struct func_object {
bool operator()(const int& lhs, const int& rhs) const {
return lhs < rhs;
}
};
int main()
{
std::list<int> list_hage;
list_hage.push_back(5);
list_hage.push_back(1);
list_hage.push_back(3);
list_hage.sort(func_object());
//確認用
for (std::list<int>::const_iterator it = list_hage.begin(); it != list_hage.end(); ++it)
std::cout << *it << std::endl;
}
77:うすげ
04/12/12 15:43:16
hogeの代わりにhageを使うヤツは嫌い。
78:デフォルトの名無しさん
04/12/12 15:54:32
だからVC6じゃC++は使えないんだって何度言えば
79:デフォルトの名無しさん
04/12/12 15:56:45
>>76
確認ありがとうございます。おかげですっきりしました。
勉強中の身ですし、頭からコンパイラのせいだ！とは言いづらく…。
>>77
私も眉毛と生え際の間がﾌｫｰﾌｨﾝｶﾞｰでして、自嘲の意味で良く使うのですが、配慮が足りずすいません。
80:つる
04/12/12 16:03:40
>>うすげ
気にするな
個性だ
81:デフォルトの名無しさん
04/12/12 21:56:38
こんどからusageの替わりにusugeを使おう。
82:デフォルトの名無しさん
04/12/14 23:42:13
偉大なるstroustrupに敬意を示すため
我々C++プログラマは、むしろ積極的にhageを使っていくべきじゃなかろうか
83:Addicted to C++ ◆nrBjarne.g
04/12/14 23:44:30
むしろ積極的にトリップにBjarneを入れていくべきではないだろうか。
84:デフォルトの名無しさん
04/12/16 16:49:49
>>78
意味不明。
85:デフォルトの名無しさん
04/12/16 17:28:50
つまり
VC++6使ってる奴は貧乏人
っていうことですよ
86:デフォルトの名無しさん
04/12/16 17:38:24
決して割れに手を出さない分、高貴とも言える
87:デフォルトの名無しさん
04/12/16 18:12:58
金が無いならvc2005 betaでも使えば良いだろ。
88:デフォルトの名無しさん
04/12/16 19:35:46
金が無いならVCTKでも使えば良いだろ。
89:デフォルトの名無しさん
04/12/16 21:13:44
金がないならハンドコンパイルすればよいだろ。
90:デフォルトの名無しさん
04/12/17 11:45:57
Boost.Spirit見てて思ったんだが、
同じようにSQLクエリをC++で記述できないもんかな。
sql.select( Person.name, Person.sex ).from( Person ).where( Person.age>=20 );
ってな感じで。
91:デフォルトの名無しさん
04/12/17 12:40:12
>>90
わらった。変態すぎ。
92:デフォルトの名無しさん
04/12/17 13:36:33
>>90
ちょっと面白そう
93:デフォルトの名無しさん
04/12/17 23:54:26
>>90
今作ってるオリジナル言語のコンパイラが完成したら
開発に着手する気でいたｗ
94:デフォルトの名無しさん
04/12/18 13:24:58
>>90
URLﾘﾝｸ(www.tietew.jp)
95:デフォルトの名無しさん
04/12/25 14:39:04
T1 と T2 が整数型という前提で sizeof(T1) > sizeof(T2) の時に
T2型の整数をゼロ拡張してT1型の整数に変換するテンプレート関数
はどのように書けばよいでしょうか？
template<class T1, class T2>
T1 zero_ext( const T2& x );
96:デフォルトの名無しさん
04/12/25 16:34:01
ゼロ拡張？
意味不明。
俺用語を使うな。
97:デフォルトの名無しさん
04/12/25 16:34:07
>>95
template<class T1, class T2>
T1 zero_ext(const T2& x)
{
return static_cast<unsigned T1>(x);
}
98:デフォルトの名無しさん
04/12/25 17:05:50
>>96 (´ﾟc_,ﾟ` ) ﾌﾟｯ
URLﾘﾝｸ(www.google.co.jp)
99:デフォルトの名無しさん
04/12/25 17:47:33
ISO C++の4.7.2にあるunsignedのintegral conversionの事でしょうね。
zero expansionってのはアセンブラの世界では良く使うね。
100:デフォルトの名無しさん
04/12/25 17:51:47
>>97
それだと、T2が符号付きのときに符号拡張されちゃうんじゃないか？
101:デフォルトの名無しさん
04/12/25 18:05:04
じゃあこうか?
template<class T1, class T2>
T1 zero_ext(const T2& x)
{
return static_cast<unsigned T1>(static_cast<unsigned T2>(x));
}
102:デフォルトの名無しさん
04/12/25 18:06:37
そもそもunsigned T1とかできるのかな?
103:デフォルトの名無しさん
04/12/25 18:15:08
よく知らんが、boost::numeric_convertionってそういう目的のライブラリじゃないのかな？
104:デフォルトの名無しさん
04/12/25 19:10:36
template<typename T, typename Container = std::map<Key, T>, typename Key = std::size_t> class Tree { };
こういう順番にテンプレート引数を取りたいのですが、どうしたらいいでしょうか？
Tree<int, std::vector<T> >としたときKeyは当然不要なので省略できるようにしたいのです。
105:デフォルトの名無しさん
04/12/25 19:13:29
テンプレートのデフォルト引数は一つまでだYO
106:デフォルトの名無しさん
04/12/25 19:15:55
無理じゃね？
107:デフォルトの名無しさん
04/12/25 19:21:17
Tree<std::vector<int> > としたときTは当然不要なので
108:デフォルトの名無しさん
04/12/25 19:47:26
struct use_default{};
template <typename T, typename Container = use_default, typename Key = use_default>
class Tree{/* がんばって情報を取り出す */};
boost::iterator_adapterの実装が参考になるかも試練。
109:デフォルトの名無しさん
04/12/25 19:57:26
おまえらぶーすとに踊らされすぎだぶー
110:デフォルトの名無しさん
04/12/25 20:02:46
boostは一緒に踊ってくれる数少ない仲間なんだよ。
111:デフォルトの名無しさん
04/12/25 20:04:43
踊る阿呆に見る阿呆、同じ阿呆なら踊らにゃソンソン
112:デフォルトの名無しさん
04/12/25 21:42:20
踊らにゃシャンソン
113:デフォルトの名無しさん
04/12/25 22:01:15
>>111
必ずどちらかの阿呆であるという無理な前提で人を煽るその言葉は大嫌いだ。
114:デフォルトの名無しさん
04/12/25 22:24:27
２択でもなく決め付けだしな
詭弁だ
115:デフォルトの名無しさん
04/12/25 22:27:59
なんで踊るよりも見る方が損なのかがわからん。
踊ったら疲れるだけなのに。
116:デフォルトの名無しさん
04/12/25 22:47:49
理論（見る）より実践（踊れ）てこと
117:デフォルトの名無しさん
04/12/25 22:51:29
>>115
踊ることが楽しいと言いたいのだろう。
118:デフォルトの名無しさん
04/12/25 23:20:36
>>101
VC++ 7.1 だと unsigned T1 のような書き方は構文エラーになりました。
119:デフォルトの名無しさん
04/12/26 00:16:22
C++Templateの便利な機能のうち
Javaでは実現できないことってなんなのかを
教えてください。
120:デフォルトの名無しさん
04/12/26 00:17:25
特殊化
121:デフォルトの名無しさん
04/12/26 00:18:39
ていうかほぼ全部？
122:デフォルトの名無しさん
04/12/26 01:13:48
>>119
使ってすぐ分かるのは、コンテナから取り出すときにナローイング変換しなくていいこと。
123:120
04/12/26 01:16:18
あれ?
Java Genericsかと思ったけど、Javaか…
124:デフォルトの名無しさん
04/12/26 04:53:50
JavaのGenericsってただの自動キャストでそ？
C++のtemplateとは比較にならないのでは・・・
125:デフォルトの名無しさん
04/12/26 08:56:50
.NETのgenerics、試みは面白い。
126:デフォルトの名無しさん
04/12/26 13:31:14
で、結局具体的にどんなことがJavaにできなくて
C++で出切るんですか？
C++ではこんなに簡単に書けるのに
Javaで書くとこんな風になっちゃうって例を
出していただけると助かります。
いろいろ考えたんですが、特別優れた使い方ってのが
思いつかなかったので。
もしかして、ないのかな・・・
127:デフォルトの名無しさん
04/12/26 20:01:11
ｸﾏｰ
128:デフォルトの名無しさん
04/12/26 20:13:40
.| | | | | | | ｜
.| | | ﾚ | | | ｜
∩＿＿＿∩ | | | J | | ｜
| ノ＼ ,＿ ヽ .| ﾚ ｜ ｜ ﾚ｜
/ ●゛ ● | .J し | |
| ∪ ( _●_) ミ .｜ し
彡､ |∪| | .Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
＼ " ／ ｜ | Javaしらね。覚える気もねえし
＼ ／￣￣￣ ／
129:デフォルトの名無しさん
04/12/26 20:56:55
>>126
Java Genericsは分かるの?
130:デフォルトの名無しさん
04/12/28 00:49:18
>>126
「オブジェクト指向をベース」にプログラムを書いた場合
JavaのGenericsで全てが事足りる。
131:デフォルトの名無しさん
04/12/28 01:22:25
速度以外はな。
132:デフォルトの名無しさん
04/12/28 05:44:30
素人が首突っ込んで申し訳ないが
Javaには専用プラットフォーム必須なんだよね？
要はエミュレータ？
133:デフォルトの名無しさん
04/12/28 08:33:23
>>132
プラットフォームの意味わかってんのか?
134:デフォルトの名無しさん
04/12/28 12:28:32
>>126
Lokiのような変態的なライブラリは無理じゃないの？Generics知らんけど。
135:デフォルトの名無しさん
04/12/28 13:19:32
その変態なLokiなんですけど、TYPELISTって動作遅くしないですか？
継承によって、多義性をサポートさせるのはよい。
コンパイル時にその多義性を作り出すのも良い。
けど、継承って、実行速度おそくなりませんか？
136:デフォルトの名無しさん
04/12/28 13:24:09
>>134
あれはオブジェクト指向を捨ててるからな。
オブジェクト指向で書き直せばもっときれいなのが作れるよ。
137:デフォルトの名無しさん
04/12/28 13:38:33
>>135
Modern C++ Designを読めば分かるけど、
LokiのPolicyは仮想関数を使ってないから…
138:デフォルトの名無しさん
04/12/28 13:42:22
>>135
TYPELISTはコンパイル時のみ。
継承なしで巨大ライブラリを作れる人、使える人はそうしたら良かろう。
Cで書いてあるgtk+みたいなのでも継承しているけどね。
139:デフォルトの名無しさん
04/12/28 13:42:58
大抵は問題にならん
140:デフォルトの名無しさん
04/12/28 14:51:39
lokiはデザパタではなくてboost::mplに似ているわけか。
141:デフォルトの名無しさん
04/12/28 15:23:42
たくさんのレスに感謝。
>137
Modernは読んでます。内容を完全に理解したとは言いがたいですが。
けれども、Efficient読んでるとvirtual使わない継承でも動作遅くなるよ～。
と書いてあるもので。
「本質的な問題ではない。」が結論なんですけどね。
>138
その通りです。
継承無しでライブラリの作成…作ったことありませんがゾッとします。
>139
>大抵は問題にならん。
継承しまくったオブジェクトを生成&削除しまくるプロジェクトとか
（サーバー用途？）ではどうでしょうか？
ModernのTYPELISTの継承構造見ていると、継承の無駄が多い気がして。
p237のクラス階層とかってつまりは。
class AbstractEnemyFactory :public AbstractFactoryUnit<Soldier>,
public AbstractFactoryUnit<Monster>, public AbstractFactoryUnit<SuperMonster>
なわけで。
実際に巨大プロジェクトの現場を経験したことのない人間の戯言ですが。
142:デフォルトの名無しさん
04/12/28 15:27:43
>実際に巨大プロジェクトの現場を経験したことのない人間の戯言ですが。
自覚しているんなら黙れ。っーつか氏ね。
143:デフォルトの名無しさん
04/12/28 15:28:43
>>142
お前こそ黙っとけよ。
144:デフォルトの名無しさん
04/12/28 15:31:01
>>143
バーカ
145:デフォルトの名無しさん
04/12/28 15:38:54
>っーつか氏ね。
OK。発音してみよう。
146:デフォルトの名無しさん
04/12/28 15:48:24
>>141
それ、TYPELISTなしで書いた方が可読性悪いでしょ。
TYPELISTは実行時に負担ないしね。コンパイル時にやるから。
typeid listじゃないから。
147:デフォルトの名無しさん
04/12/28 15:51:47
>継承しまくったオブジェクトを生成&削除しまくるプロジェクトとか
>（サーバー用途？）ではどうでしょうか？
メモリ確保＆解放は一瞬。メモリに書き込むことは多少重いけど。
ただ、ゲームなんかのメモリ資源が超少ない環境では
メモリのフラグメントなんかが起こって、メモリが足りなくなることはある。
148:デフォルトの名無しさん
04/12/28 16:01:22
いや、new/deleteは重いけど、
継承しているしていないに関係ない。
継承して複雑な部分を作り出す構造だと、
一つのオブジェクトの中にまとめられるから、
利用するメモリチャンクの数が減ることも考えられる。
Cでやると、ポインタの嵐になって別々の構造体になるから、
malloc/freeを寄り頻繁にする必要がある(事が多い)。
とりあえず、135は、
・templeteが、compile時のみ働くものであること
・詳解C++(いわゆるAnnotated)を読んで、継承のメモリ利用
を勉強しろ。
分からない奴はいつまでたっても設計ができない。
149:デフォルトの名無しさん
04/12/28 16:03:14
>>148
> Cでやると、
「継承しないでやると、」の方がいいかな。
compositionとinheritanceの違いはAnnotated読んで。
150:デフォルトの名無しさん
04/12/28 16:58:14
みんなRubyのこと嫌いなの？
151:135
04/12/28 18:54:45
自分でTYPELISTでAbstractFactoryを組んで、それをいじくりまわしてみました。
結果：変わらないですね…
なんか狐につままれた感じのするのは私だけでしょうか。
>・詳解C++(いわゆるAnnotated)を読んで、継承のメモリ利用
を勉強しろ
多分これが今の私に必要なんでしょうね。
はい。いろいろとがんばってみます。
皆様ありがとうございました。
152:151
04/12/28 22:14:45
>結果：変わらないですね…
コンパイル時間が変わっていると思うけど……
153:デフォルトの名無しさん
04/12/29 01:08:18
mmap+boost で、データ構造のシリアライズがやりたいです。
具体的には、
１、データファイルをmmap で巨大なヒープとしてメモリに貼り付ける。
なお、このとき、毎回同じメモリアドレスに貼り付ける必要性がある。
２、boost の new をいじくり、すべてそのmmapされたヒープの中でのみ
allocate されるようにする。
以上で、データ構造がそっくりシリアライズできるような気がするのですが、
どうやってやればいいでしょうか。
154:デフォルトの名無しさん
04/12/29 01:32:26
boost::serialize使えばいいのに
155:デフォルトの名無しさん
04/12/29 01:33:17
boost::serializationだった
156:デフォルトの名無しさん
04/12/29 03:49:42
ええっと、それだと、一度すべての変数をずるずるっと舐めることになりますよね。
そうじゃなく、効率も考え、変数空間全体をmmap でファイルに貼り付けたいんです。
157:デフォルトの名無しさん
04/12/29 03:53:06
舐めるならレロレロとかチュパチュパじゃないか？
ずるずるってﾅﾆ？
158:デフォルトの名無しさん
04/12/29 03:54:17
つーか
＞毎回同じメモリアドレスに貼り付ける必要性がある。
これで破綻してるとは思わないのか
159:デフォルトの名無しさん
04/12/29 05:06:16
それはすくなくともLinuxなら可能です。
とくに、今後の64bit Linuxなら、アドレス「空間」はいくらでも余ってるので、
何の問題もないでしょう。
160:デフォルトの名無しさん
04/12/29 17:23:10
>>159
^^
161:デフォルトの名無しさん
04/12/29 17:48:45
>>153
やりたいようにやればあ。
絶対アドレス依存じゃないヒープ保存で有名なのはEmacsとTeX。
絶対アドレスに依存するのはちょっと面倒だね。
C++のオブジェクトを直接張り付けるんじゃなくても、
wrapper classで仮想的に扱えるよね。
162:デフォルトの名無しさん
04/12/29 21:34:37
おまえら、「boost の new」の意味はわかってるのか？
漏れにはわからん。
163:デフォルトの名無しさん
04/12/29 21:39:05
「boostで使うnewとかもひっくるめて自分でglobalなoperator new()をオーバーライドしちゃいます」
という意味だと思ってた
164:デフォルトの名無しさん
04/12/29 21:53:12
>>163
そうなると、「mmap+boost で」っていうのがわからん。
boost も template も関係ないじゃないか。
165:デフォルトの名無しさん
04/12/29 21:58:22
ううむ。確かに。
boostの機能のキの字も使ってないもんなぁ。
166:161
04/12/29 22:00:47
そもそもシリアライズじゃないし(w
167:デフォルトの名無しさん
05/01/04 00:56:10
知り合いs
168:デフォルトの名無しさん
05/01/06 00:15:21
GC(参照カウント方式)に使えるポインタオブジェクトで
オブジェクトのconst修飾が参照先のconst修飾に対応した
クラスってないでしょうか
Boost流だとこんな↓感じ？
template<typename T>
class my_shared_ptr : protected boost::shared_ptr<T>
{
public:
const T * operator->() const { return __super::operator->(); }
T * operator->() { return __super::operator->(); }
// other functions implementation...
};
おねがいします
169:デフォルトの名無しさん
05/01/06 00:22:41
>>168
そんな感じでいいんじゃないの？
170:168
05/01/06 00:26:23
はい、ありがとうございます
ただ、既存のライブラリでいいのはないかと思いまして・・・
171:デフォルトの名無しさん
05/01/06 01:16:46
>>170
Boost は「既存のライブラリ」以外の何だというのかね？
172:デフォルトの名無しさん
05/01/06 02:12:11
>>168
ちなみにshared_ptr<T const>を嫌う理由は何ですか？
173:デフォルトの名無しさん
05/01/06 06:31:17
重い
174:デフォルトの名無しさん
05/01/06 10:28:20
プログラム全体の動作に致命的なほど遅くはなんねぇよ
175:デフォルトの名無しさん
05/01/06 10:56:57
何の要件もなしに「重い」と言って切り捨てる >173 も、
何の前提もなしに「致命的なほど遅くはなんねぇ」という >174 も、
同じ程度に浅はかである。
176:デフォルトの名無しさん
05/01/06 11:01:20
>>175
それを否定してしまったら何もかけなくなっちゃうよ。
177:デフォルトの名無しさん
05/01/06 11:09:22
>>176
175が何を否定してるんだ？
178:デフォルトの名無しさん
05/01/06 11:10:18
日本の将来
179:電波系赤の他人
05/01/06 11:13:22
俺も人格も否定しているような気がする。
180:デフォルトの名無しさん
05/01/06 18:37:00
>>172
嫌というほどでもないんですが、
コンパイルが遅そうとか、その程度です
const my_shared_ptr<T> get_obj_ptr() const;
my_shared_ptr<T> get_obj_ptr();
より、
shared_ptr<T const> get_obj_ptr() const;
shared_ptr<T> get_obj_ptr();
の方が意味的に適切だとは思うんですが
自分で書くのめんどうなので、とりあえずboost::shared_ptrでいいや・・・
181:デフォルトの名無しさん
05/01/06 20:30:30
こういうのどうですか？
#defineBEGIN_JUNK( __Super, __Misc ) \
template< int _N >struct __Junkyard{ enum { _junk_no = __Junkyard< _N - 1 >::_junk_no }; }; \
template<> \
struct __Junkyard< __LINE__ > : public __Super::_junk \
{ \
enum { _junk_no = __LINE__ }; \
typedef __Super::_junk _prev; \
__Misc; \
}; \
typedef__Junkyard< __LINE__ >_start_junk; \
#defineREDEF_JUNK( __Misc ) \
template<> \
struct __Junkyard< __LINE__ > : public _prev_junk \
{ \
enum { _junk_no = __LINE__ }; \
typedef _prev_junk_prev; \
__Misc; \
}; \
#defineEND_JUNK() \
typedef_cur_junk_junk; \
長いので詳細は↓に書いてあります。
URLﾘﾝｸ(www2.odn.ne.jp)
割と使えると思うんだがどうだろう？
182:デフォルトの名無しさん
05/01/06 22:08:44
>181
マクロで実装してるreflection系ライブラリの提案見るたびに思うんですけれど
マクロとテンプレートの相性の悪さはどう対処するつもりなんでしょうか？
毎回typedef？（面倒）BOOST_PP_SEQ？（カッコ悪い）variadic macro待ち？（いつ出る？）
struct Sample2
{
typedef Sample2 _self;
BEGIN_JUNK( ZJunkBase, typedef ZTypeList<> _data_member1; );
DATA_MEMBER( 1, my_class<char, int>, x );
END_JUNK();
};
183:181
05/01/06 22:39:57
>>182
言いたいことには同意
対処って程ではないが、苦肉の策でこんなことやってる
#define $ ,
struct Sample2
{
typedef Sample2 _self;
BEGIN_JUNK( ZJunkBase, typedef ZTypeList<> _data_member1; );
DATA_MEMBER( 1, my_class<char $ int>, x );
END_JUNK();
};
はげしくかっこ悪いが ｗ
184:デフォルトの名無しさん
05/01/06 22:59:24
>183
それだとDATA_MEMBERが評価される前に$が評価されてしまうので結局同じことになりませんか？
色々漁ってみたら限界はあるもののいくつか対処法はあるみたいですね．
URLﾘﾝｸ(lists.boost.org)からだと
template<class T> struct wrap { typedef T type; };
template<class T> struct wrap<void (T)> { typedef T type; };
#define TYPE(x) wrap<void x>::type
#define DEP_TYPE(x) typename wrap<void x>::type
struct Sample2
{
typedef Sample2 _self;
BEGIN_JUNK( ZJunkBase, typedef ZTypeList<> _data_member1; );
DATA_MEMBER( 1, TYPE((my_class<char, int>)), x );
END_JUNK();
};
とか．記事本文では指摘されていないですけれど，型がdependent typeか
どうかでマクロを使い分ける必要もありますね，これ．
・・・っていうか話題をそらしてしまってすいませんです．
185:181
05/01/07 00:10:36
>>184
コンパイル通らないですか？
当方、VC++ 2003 しかないので、他のコンパイラだと通らないのだったら正直すまん
ただ、VC++ 2003 でも多重にマクロを定義している時は、評価順序によって通らない時もある
その時はマクロを調整するでは駄目ですか・・？
リンク先のようなやり方もあるとは知りませんでした
参考にさせて頂きます
186:181
05/01/07 00:38:04
あと、typename に対してですが
__if_exists が使えればこういうやり方もあります
template< bool >struct ExistsBool {};
template<>struct ExistsBool< true > { enum { _true }; };
#defineTYPEDEF( __Type, __Alias ) \
__if_exists( __template__::_true ){ \
typedef typename __Type __Alias; \
} \
__if_not_exists( __template__::_true ){ \
typedef __Type __Alias; \
} \
template< class _Type >
struct Sample7
{
typedef ExistsBool< true >__template__;
TYPEDEF( _Type::_type, _type );
// ２値判定にも使える
__if_exists( ::ExistsBool< _Type::_n == 0 >::_true ){
}
};
__template__ をクラスごとに宣言する必要があるのが難点ですが
187:デフォルトの名無しさん
05/01/07 19:48:15
>>184
>それだとDATA_MEMBERが評価される前に$が評価されてしまうので結局同じことになりませんか？
引数展開の前に引数は確定するから、この例では問題ない。
でもこの結果を別のマクロに渡すと結局だめだから、
あまりお勧めはできないが。
# define ID(x) x
# define COMMA() ,
# define DECL_A(type, var) type var
# define DECL_B(type, var) ID(type) var
DECL_A(std::pair<int COMMA() int>, pa); // ok
DECL_B(std::pair<int COMMA() int>, pb); // error: IDの引数過多
188:184
05/01/07 21:39:12
>186
考えてみた結果enclosing scopeがtemplateかどうかに対する切り分けが
本質的に必要ではないかと思うのでこの方法はあまり使えなさそうです．
>187
マクロのargument substitutionについて理解が足りていませんでした．
function-like macroがidentityされてから後，replacement-listに対する
置換が実行される前にargumentに含まれるmacro tokenが置換されるんですね．
見た感じやはり184の解法が幾分かbetterでしょうか．
189:181
05/01/08 00:55:07
これでどうだろう。>>184 と組み合わせてみた。
template<class T> struct wrap{ typedef T type; };
template<class T> struct wrap<void (T)>{ typedef T type; };
#define TYPE(x) wrap<void x>::type
template< bool >struct ExistsBool{};
template<>struct ExistsBool< true >{ enum { _true }; };
#defineTYPEDEF( type, alias ) \
__if_exists( __template__::_true ){ typedef typename TYPE((typename type)) alias; } \
__if_not_exists( __template__::_true ){ typedef TYPE((type)) alias; } \
#defineCLASS( __Class ) \
typedef __Classself; \
typedef ExistsBool< false >__template__; \
#defineTEMPLATE( __Class ) \
typedef __Classself; \
typedef ExistsBool< true >__template__; \
#define$,
190:181
05/01/08 00:55:32
つづき
template< class T >
struct hara
{
TEMPLATE( hara );
template< class T > struct horo
{
TEMPLATE( horo );
TYPEDEF( T::type,type );
};
struct hire : public horo< T >
{
CLASS( hire );
TYPEDEF( my_class<char $ int>, type2 );
};
TYPEDEF( hire::type, type );
TYPEDEF( hire::type2, type2 );
};
$ を主張するわけではないが、タイプ量が少ないと嬉しいので
ところで、誰も Jankyard に触れてくれない orz
191:デフォルトの名無しさん
05/01/08 01:04:10
誤: typedef __Classself;
正: typedef __Class self;
誤: #define$,
正: #define $ ,
です。連投すんまそん
192:デフォルトの名無しさん
05/01/09 07:22:01
＞ところで、誰も Jankyard に触れてくれない orz
ぶっちゃけていうとreflection系ライブラリの提案はすでに色々ありますからね．
自分の知っている範囲だと
URLﾘﾝｸ(www.garret.ru)
URLﾘﾝｸ(www.arneadams.com)
あたりでしょうか？後プロパティの実装なら
URLﾘﾝｸ(www.open-std.org)
とか．
ついでに__if_existsに関して，名前がするかどうかというコンパイル時の情報で
プリプロセッサレベルの処理を行えるというのは確かに強力で魅力的なんですが
やはりVC++限定なのがネックでしょうね．
一応クラスのメンバ（型・関数・変数）や非メンバ関数の存在をテストしてその情報を
コンパイル時に取得する技法を標準C++の範囲内で実装することは可能なので，
それでほとんどの部分は代用できると思います．
（というか自分は本質的に__if_existsが必要な状況を思い付けません）
193:181
05/01/09 09:15:49
>>192
今回提案したのはリフレクション自体ではなく、その辺りをサポートする仕組みだったのだが。
リフレクションも含む、その他タイプリスト生成や、マクロ間での型の受け渡し、
継承関係の中で連番発行など。プロパティはネタです。
__if_exists は本質的に必要ないのには同意します。
ただ、テンプレートの特化の変わりに使えるので
__if_exists を使うとシンプルに記述出来ることも少なくありません。
この辺りは好みによるのでしょうね。
VC++限定なのはどうしようもないですが。
いづれにせよ、騒がしているだけのようなので、これで引っ込むことにします。
＞一応クラスのメンバ（型・関数・変数）や非メンバ関数の存在をテストしてその情報を
＞コンパイル時に取得する技法を標準C++の範囲内で実装することは可能なので，
＞それでほとんどの部分は代用できると思います．
詳細きぼん
194:デフォルトの名無しさん
05/01/09 12:47:08
ここでいいのかしら。ちょっと彷徨い気味ですがどうぞよろしゅう
2つのソート済みvectorの中で共通する項目の数を数えたいのですが
set_intersection( (省略) , common_ins)
common.size();
で実行しています。これだとvectorの中身が100kとかになった時に速度がちょっとまずいのです。
上記より高速な方法でなにか良案ご存知の方いらっしゃいませんか？
ちなみのその後、共通部分から作ったcommonに対する処理は何も行いません(数えたいだけです)
195:デフォルトの名無しさん
05/01/09 12:52:27
vecAとvecBを
mergeしてvecCを作りuniqueしてvecA.size()+vecB.size()-vecC.size()
196:デフォルトの名無しさん
05/01/09 12:54:20
set_intersectionもソート済み範囲なのか。なら>>194の方が遅そうだ。
197:デフォルトの名無しさん
05/01/09 12:59:38
>>195のがだろ
198:デフォルトの名無しさん
05/01/09 13:00:07
URLﾘﾝｸ(www.google.com)
199:194
05/01/09 13:14:44
mergeして差分を考える方法は実行済みなのですが
残念ながら、set_intersectionの方法に比べて倍近く時間がかかってしまったのです
う～ん、これはもう構造的にどうしようもないですかね
割と頻繁に更新されるvectorなので、馬鹿にならないコストなんですが・・・
200:デフォルトの名無しさん
05/01/09 13:29:34
スマートポインタを使ってるならただのポインタに変えてみる。
ただのポインタなら実体に変えてみる。
実体ならポインタに変えてみる。
201:デフォルトの名無しさん
05/01/09 13:33:31
set_intersection の result は OutputIterator なので、
*result = common (or *result++ = common)
がカウントアップの動作をするような擬似イテレータを作れば、
コピーのコストを無くすことができそうだ。
202:デフォルトの名無しさん
05/01/09 13:39:05
うっ、そこを触ることになりますか…
Iteratorの中身について理解が出来ていないので全くの手探りになりますが、資料ひっくり返して勉強します
ありがとうございました
203:デフォルトの名無しさん
05/01/09 14:48:42
暇つぶしにやってみた。
boost::counting_iterator がそのまま使えるかと思ったけど OutputIterator じゃなかった。
しょうがないから結局ファンクタ書く羽目になった。
#include <cstddef>
#include <algorithm>
#include "boost/function_output_iterator.hpp"
template<typename Incrementable>
class increment
{
Incrementable* m_target; // not reference to make this class Assignable
public:
increment(Incrementable& target) : m_target(&target) {}
template<typename T> void operator () (T const&) { ++*m_target; }
};
template<typename InputIterator1, typename InputIterator2>
std::size_t count_intersection(InputIterator1 first1, InputIterator1 last1, InputIterator2 first2, InputIterator2 last2)
{
std::size_t result = 0;
std::set_intersection(first1, last1, first2, last2
, boost::make_function_output_iterator(increment<std::size_t>(result)));
return result;
}
lambda 使えば、 increment くらい消せるかも。
204:デフォルトの名無しさん
05/01/09 17:29:22
いちおうできた。
#include <cstddef>
#include <algorithm>
#include "boost/function_output_iterator.hpp"
#include "boost/lambda/lambda.hpp"
template<typename InputIterator1, typename InputIterator2>
std::size_t count_intersection(InputIterator1 first1, InputIterator1 last1, InputIterator2 first2, InputIterator2 last2)
{
std::size_t result = 0;
std::set_intersection(first1, last1, first2, last2
, boost::make_function_output_iterator(++boost::lambda::var(result)));
return result;
}
ただ、 lambda のファンクタが Assignable にならないので、
_GLIBCXX_CONCEPT_CHECKS で怒られた。
VCでは /W3 まで大丈夫。
205:デフォルトの名無しさん
05/01/09 19:25:21
template<class T>
struct X {
void func() {}
};
TがクラスAかクラスAのpublic派生クラスの特殊版を定義する場合
X<T>::func()をどのように定義すればよいのでしょうか？
206:デフォルトの名無しさん
05/01/09 23:59:37
>193
具体的な実装の例だとboost/mpl/has_xxx.hppとかが参考になるかと思います．
>205
Boost使うなら以下のような感じでですかね？
#include <iostream>
#include <boost/mpl/if.hpp>
#include <boost/type_traits/is_base_and_derived.hpp>
struct A{ };
template<class T> struct X{
struct yes_tag{ };
struct no_tag{ };
typedef typename boost::mpl::if_<
boost::is_base_and_derived<A, T>, yes_tag, no_tag>::type
dispatch_tag;
void func_dispatch(yes_tag){std::cout << "derived version" << std::endl;}
void func_dispatch(no_tag){std::cout << "non-derived version" << std::endl;}
void func(){ func_dispatch(dispatch_tag()); }
};
struct Hoge : public A{ };
struct Huga{ };
int main(){
X<Hoge>().func();
X<Huga>().func();
}
207:デフォルトの名無しさん
05/01/10 17:24:10
こういう書き方って動作は保証されるのでしょうか？
std::vector<int> test;
for ( std::vector<int>:iterator element = test.begin(); element != test.end(); element++ ) {
test.erase(element);
}
208:デフォルトの名無しさん
05/01/10 17:30:51
↑おもいっきりぬけてたので修正しました
std::vector<int> test;
test.push_back(0);
test.push_back(1);
test.push_back(2);
test.push_back(3);
test.push_back(4);
for ( std::vector<int>:iterator element = test.begin(); element != test.end(); element++ ) {
if ( *element == 2 ) {
test.erase(element);
}
}
209:デフォルトの名無しさん
05/01/10 17:35:21
>>208
eraseした時点でイテレータそのものが無効になるよ。
210:デフォルトの名無しさん
05/01/10 17:38:08
ではループしつつ条件に当てはまるイテレータの内容だけ削除するには
どのような手段を用いればよいのでしょうか？
プールで一端どこかにマークをつけて、ループ終了後該当の物だけeraseとかでしょうか？
211:デフォルトの名無しさん
05/01/10 17:38:33
だから、std::remove()で、値が2の要素をコンテナの後に集めておき、最後に一回だけ
eraseするといい。
test.erase(std::remove_if(test.begin(), test.end(), std::bind2nd(std::equal<int>(), 2)), test.end());
212:デフォルトの名無しさん
05/01/10 17:38:57
あ、ループがプールに・・orz
213:デフォルトの名無しさん
05/01/10 17:39:57
なるほど、ありがとうございます
214:デフォルトの名無しさん
05/01/10 17:40:36
こういう書き方は最初は戸惑うかもしれないが、慣れるとすごく便利になる。
そのうちこれでも不便になって、必ずboost::bindとかに手を出したくなるから。
215:デフォルトの名無しさん
05/01/10 17:43:26
わかりました。
参考にしてみます。
216:デフォルトの名無しさん
05/01/10 17:43:57
というか、EffectiveSTLを読め。
>>211のも含めて色々書いてあるから
217:デフォルトの名無しさん
05/01/10 17:50:47
test.erase(std::remove(test.begin(), test.end(), 2), test.end());
でもいいねこの場合。叙述関数あるいは関数オブジェクトの替わりにconstな値を
とるだけだから。
218:デフォルトの名無しさん
05/01/10 17:58:23
if ( *element == 2 ) {
test.erase(element++);
}
でOK。
219:デフォルトの名無しさん
05/01/10 18:01:18
>>218は忘れて。
for ( std::vector<int>:iterator element = test.begin(); element != test.end(); ) {
if ( *element == 2 ) {
element = test.erase(element);
}
else
++element;
}
220:デフォルトの名無しさん
05/01/10 18:01:28
>test.erase(std::remove_if(test.begin(), test.end(), std::bind2nd(std::equal<int>(), 2)), test.end());
わけがわかりません。
こんなの仕事で使われたら恐怖です。
やめてください。
221:デフォルトの名無しさん
05/01/10 18:02:08
>>217-219
やめてください。
怖いです。
222:デフォルトの名無しさん
05/01/10 18:02:50
>>218
vectorコンテナのeraseはCで言うところのrealloc()に相当する動作を実行する
事もあるんだぞ。でたらめ書くな。
223:デフォルトの名無しさん
05/01/10 18:03:47
>>220
そのくらいのSTL構文も分からないならC++使うのをやめた方がいいよ。
224:デフォルトの名無しさん
05/01/10 18:06:37
>>222
おいおい。
「イテレータは、より小さなインデックスの要素が挿入または削除されたり、再割り当てが
行われて容量が変わるまで有効」だぞ。
規格票をよく読め。おまえこそでたらめ。
225:デフォルトの名無しさん
05/01/10 18:10:44
規格票でました。
m9（^Д^）ﾌﾟｷﾞｬー
226:デフォルトの名無しさん
05/01/10 18:12:25
§23.1.2.8当たりだろ。
227:デフォルトの名無しさん
05/01/10 18:13:13
URLﾘﾝｸ(www-6.ibm.com)
＞言語の機能 であるはずのものが、その言語のユーザーを恐れさせるようになったら、何かを変えるべき時なのです。
228:デフォルトの名無しさん
05/01/10 18:13:59
>>226
それAssociative Container
229:デフォルトの名無しさん
05/01/10 18:15:05
ここは
問題を無闇に複雑にして悦に浸る馬鹿のス靴（なぜか変換できない）
ですね。
230:デフォルトの名無しさん
05/01/10 18:19:30
§23.2.4.3当たりだと見た。
231:デフォルトの名無しさん
05/01/10 18:20:25
>>227>>229
またperlとかrubyの○キ信者ですか？
232:デフォルトの名無しさん
05/01/10 18:23:27
boostが異常なのは認めなければなるまい。
昨今のC++は異常が常態。
233:デフォルトの名無しさん
05/01/10 18:24:29
確かに異常だが、使っているうちに快感になる。
234:デフォルトの名無しさん
05/01/10 18:24:50
(23.1.1/7)と(23.2.4.3/3)読む限り>219でもOKっぽいですね
235:デフォルトの名無しさん
05/01/10 18:27:46
CommonLispのようなわかりにくさを競い合って悦に浸るのがここの流儀
236:デフォルトの名無しさん
05/01/10 18:28:39
>>234
OKだろ。個人的には俺はあまり書きたくないけど。
237:デフォルトの名無しさん
05/01/11 00:57:13
>>219
引くってのはどうよ。
for(element = test.begin(); element != test.end(); ++it)
{
if(*element == 2){
test.erase(element--);
}
}
あ、でも element = test.begin(); element--; は大丈夫なのかな。
まぁ、EffectiveSTLを読んでいれば test.erase(remove(),test.end())と書くというのに一票。
238:237
05/01/11 00:58:59
訂正。
>>237
++it => ++element
239:デフォルトの名無しさん
05/01/11 01:06:22
>>237 ダメ
240:デフォルトの名無しさん
05/01/11 14:28:58
for(element = test.begin(); element != test.end(); ++element)
if(*element == 2)
{
element = --test.erase(element);
}
こんな感じが一番シンプルなところなのかな？
241:デフォルトの名無しさん
05/01/11 15:04:23
removeとeraseの組み合わせが一番シンプル
242:デフォルトの名無しさん
05/01/11 15:59:47
とりあえずremoveとeraseの組み合わせが何でも一番です（＾＾
243:デフォルトの名無しさん
05/01/11 16:01:18
clearって手もあるよ
244:デフォルトの名無しさん
05/01/11 19:46:02
>>223
プロジェクトって大抵いろんな技術レベルの人がいるから
その台詞でばっさりはちょっと抵抗あるなぁ。
一人でやるなら何使ったってOKだけどね。
245:デフォルトの名無しさん
05/01/11 20:32:55
>>244
211はかなり基本だと思うんだけど...
246:デフォルトの名無しさん
05/01/11 20:46:56
あれが解からないって？
…ときどき思うんだ。俺、なんで2chなんか見てるんだろう、って。
247:237
05/01/11 22:30:46
なんか不安になってきたので確認したいのですが
vectorのeraseで無効になるのは消した要素以降のイテレータですよね。
だから>>237と>>240は結果的に同じことになりますよね？
私が>>237で心配だったのは
最初の要素でヒットしたとき、
element = test.begin();
--element;
++element;
でbegin()に戻るのが規格で保証されてなさそう(多くの実装では戻りそうだけど)
というのと
元々のサイズが1のとき、test.erase(test.begin());で全てのイテレータが無効になる
ときにバッファを解放してbegin()とend()がNULLを返してくるようになるとend()と
永遠に一致しなそう(VC7のclearがバッファを解放(capacityを0)にしてくれるのに
気づいて以来疑り深くなっています)
の二点なんですけど、
そのあたりをふまえて>>239はダメと言っているんですよね？
うーん、remove(や類似のアルゴリズム)を使わないでやるならやはり>>219なのか。
248:237
05/01/11 22:34:15
ああ、そうか、後者の不安は>>240と書くことで払拭されるのか。
ｽﾏｿ
249:244
05/01/12 01:12:53
>>245
俺も基本だと思ってるし、これぐらいわかれよって思ってるよ。
でも、それが通用しないのが多人数でしょ？って投げかけ。
…技術と関係なくなるか。消えるよ。スレ汚しすまん。
250:デフォルトの名無しさん
05/01/12 02:17:30
なぜforで回す……わざわざC++使うんだったら、効率にも気を
配らないともったいないよ。
>247
>237 >240の例だと
・ループごとにtest.end()の呼び出しが発生する
・elementを削除するたびにvectorの再パッケージが発生する
で遅くなりますな。
あと、>237だと後置インクリメントの一時オブジェクトの生成が
発生してさらに効率が悪くなります。
251:デフォルトの名無しさん
05/01/12 02:18:18
なぜにremoveを使いたくないのかが知りたい
252:250
05/01/12 02:24:13
自己フォロー
>237>240ともに、はelement==test.begin()のときに
*element==2だとアウトですな。
＃test.begin()よりも前に移動するから未定義の世界に突入
253:デフォルトの名無しさん
05/01/12 02:48:28
>250
ループごとのtest.end()も後置インクリメントもここでは本質じゃない。
254:デフォルトの名無しさん
05/01/12 02:56:25
>253
ふうん、じゃ、こう言っておこうかな
・郷に入れば郷に従え
STLはC++の一部なんだから、それぐらい覚えろ
・こんぐらいできないなら、そもそもC++使うな
or こんなこともできないやつをプロジェクトに入れるな
他にもPerlとか色々あるんだから、わざわざC++を使う必要ないよね。
255:デフォルトの名無しさん
05/01/12 07:36:48
list に追加されている remove(),remove_if() 見習って、
template<class Container> void remove(Container&, typename Container::value_type const&)
template<class Container, class Predicate> void remove_if(Container&, Predicate p);
のような関数を作れば、双方文句はなかろう。
256:255
05/01/12 07:50:40
s/Container/Sequence/
remove() の意味が混乱を招きやすいという認識はSGIのドキュメントにも記載されている。
「慣用句だ」と言って押し切るよりは、むしろまともな認識だと思う。
URLﾘﾝｸ(www.sgi.com)
これをそのままソースに書いてしまうと言うのは、
例えば定数除算をシフトで書いてしまうのと同等の誤りであると思う。
257:デフォルトの名無しさん
05/01/12 07:51:49
forで回すからうっかり>>218とか>>237とか>>240とかいう問題のあるコードを書いて
しまうんだよ。
だったらおとなしくremoveを使えと。
まぁ、色々書き方があってその中から適切な物を状況に応じて選ぶのがプログラムの
醍醐味ではあるけど。
258:デフォルトの名無しさん
05/01/12 08:53:47
＞なぜにremoveを使いたくないのかが知りたい
叙述関数やoperator==とかにコードが分散するのがイヤ
ループが内包されるのがイヤ ループを制御下に置いておきたい
ブレイクポイントが設定しやすいよ
削除以外の用途にループが流用できるよ
てゆうかぶっちゃけremove_copy中でやってること、あれはありえないでしょ
それを言ったらvectorでeraseすること自体ありえないかｗ
259:デフォルトの名無しさん
05/01/12 09:59:55
>ループが内包されるのがイヤ ループを制御下に置いておきたい
ループを明示的に書くより効率が良くなる可能性があるし、
コードの見通しも良くなる
260:デフォルトの名無しさん
05/01/12 10:06:05
>>254
「理想郷」との差でしかモノを語れない
頭でっかちの引き籠もりはレスしなくていいです ;-)
261:デフォルトの名無しさん
05/01/12 10:32:21
>260
それ、オレじゃない。人違いだ
262:デフォルトの名無しさん
05/01/12 10:48:33
>260
IDくらい見ろ、ボケ！
263:デフォルトの名無しさん
05/01/12 11:10:58
>>262
この板ID無いんだって気付よ！
264:デフォルトの名無しさん
05/01/12 11:21:54
お前さんたちなんか楽しそうだね。
265:デフォルトの名無しさん
05/01/12 11:42:25
IDの見方知らない香具師ってまだいたんだね
266:デフォルトの名無しさん
05/01/12 12:13:29
はっきりいってvectorに限らず配列っぽいデータ構造を使っている時に
removeみたいなアルゴリズムを適用したくなることってあるか？
無理して適用しておもしろいことがあるようなものでもないと思うのだけど…
何か見落としている革新的な理由でもあったりするのだろうか？
267:デフォルトの名無しさん
05/01/12 23:55:01
> removeみたいなアルゴリズムを適用したくなることってあるか？
配列から複数の要素を一度に取り除きたいときだな。
268:デフォルトの名無しさん
05/01/13 00:11:28
簡単
let remove x num = snd (List.partition (fun a -> a=x) num);;
269:デフォルトの名無しさん
05/01/14 14:04:12
>>268
配列っぽくないデータ構造。
270:デフォルトの名無しさん
05/01/15 01:33:25
>>267
そそ、端からeraseしてると効率悪いし、
効率的な処理にしようとすると意外に面倒。
271:デフォルトの名無しさん
05/01/17 09:41:54
俺も小さくて、しかもあまり使わないような関数を分散させるのが嫌いなんだけど、
「リファクタリング」を読むと、一行処理すら場合によっては関数にすることを推奨してるんだよな。
しっかりした関数名をつけることによって可読性が高まるって話なんだけど、
必ずしもそうとは思えないのは、英語圏ネイティブじゃないせいかね。
と、templateスレに書き込もうとしたのだけど、主旨に合わないのでこっちに投棄
272:デフォルトの名無しさん
05/01/17 09:43:01
C++スレに書くつもりが…
もうどうでもいいや
273:デフォルトの名無しさん
05/01/17 13:41:34
リファ～に書いてあるのは関数じゃなくてメソッドのことでは
何の分類もしない単独の関数増やしてくのはあんま良いとは思えないが
メソッドの場合インターフェース抽出とか階層整理とかで意味がある
274:272
05/01/17 17:58:06
>>273
失礼、つい関数と呼んじまう。
インターフェース抽出や階層整理は、それ自体をメインにして行うべきな気がするんだよねぇ。
それどころかそれ以前で、非道い話だが「たくさんの、たった数行のメソッド」ってだけで、嫌悪感を感じてしまう。
いずれにせよスレ違い申し訳ない。
275:デフォルトの名無しさん
05/01/18 00:41:35
>>273
そんな区別ないだろ。
少なくともC++ではthisポインタの有無しか違いはないわけで、
それが関数分けの基準に影響するとは思えない。
276:デフォルトの名無しさん
05/01/18 01:35:22
時々272のような人いるよね。
読むときあっちこっちの関数みないといけないから、とか言って。
このヘタレが
277:デフォルトの名無しさん
05/01/18 01:45:39
そもそも行数とか関係ないだろ
278:デフォルトの名無しさん
05/01/18 02:41:33
>275
その他にも可視性とアクセス範囲に違いがあるわけで……
279:デフォルトの名無しさん
05/01/18 08:17:20
>>278
そうだな。
それらが要るならクラス作ってメンバ関数を作ればいいし、
要らないならフリー関数にしてもいい。
どう整理するかどうかが違うだけで、
処理に名前をつけてまとめたほうがよいかどうかの基準には関係ない。
複数のフリー関数を作った後に、さらに
それらをまとめてクラスを作ればよいことに気付くことも考えられる。
思い立ったらさっさと名前付けてまとめれ。
渋る意味がわからん。
280:272
05/01/18 08:20:53
ちとスレ違い悪いんでこっちでレス
ｽﾚﾘﾝｸ(tech板:41番)
281:デフォルトの名無しさん
05/01/21 18:18:02
お聞きしたいのですが、
下記（次レス）のコードがVC7.1でコンパイルできませぬ。
どこがいけないのでしょうか…
色々実験してみた結果
・UINT を int にすると通る。
・UINT を std::size_t にしてもダメ。
・typename T を削除して、 boost::array の T を int とかにすると通る。
・boost:array の nSize を適当な数値で直打ちすると通る。
・bcc5.5.1 では普通に通る。
282:281
05/01/21 18:18:34
#include <boost/array.hpp>
typedef unsigned int UINT;
template<typename T, UINT nSize>
class A
{
typedef typename boost::array<T, nSize> tObjects;
typedef typename tObjects::iterator tObjectsIt;
tObjects m_cObjects;
public:
tObjectsIt Func();
};
// ↓C2244：関数の定義を既存の宣言と合致させることができませんでした。
template<typename T, UINT nSize>
inline typename A<T, nSize>::tObjectsIt A<T, nSize>::Func()
{
return m_cObjects.begin();
}
283:デフォルトの名無しさん
05/01/21 20:49:28
>>281
手元にVC7.1もboostもないし、よくわからんけど、
コンパイラがバグってることはよくあるからｗ
284:デフォルトの名無しさん
05/01/21 20:57:34
>>282
g++(3.3.3)ではなんの警告もエラーもなく通るのぅ……
285:デフォルトの名無しさん
05/01/21 21:31:52
>>282
戻り値を素直に
typename boost::array<T, nSize>::iterator
とすると通りますね。
286:デフォルトの名無しさん
05/01/22 00:57:24
typedefがprivateなのにinlineなのがいけないんじゃないのか？
と試してもないのに言ってみる
287:281
05/01/22 11:00:38
やはり、コンパイラが悪い方向なんですか… orz
なお、>>286を参考に、
すべてのメンバをpublic にしてみてもコンパイルが通りませんでした。
しょうがないので、現状では
・class内に直書き
・>>285 の方法
の２点で回避したいと思います。
どうもありがとうございました。
288:デフォルトの名無しさん
05/01/22 11:27:55
いまだにちゃんと動かないコンパイラ多いのかよ
おまえらC++信用できますか？
289:デフォルトの名無しさん
05/01/22 11:28:34
C++なら信用できるよ。
290:デフォルトの名無しさん
05/01/22 15:39:27
>>282
vc8 でもダメっぽい
291:デフォルトの名無しさん
05/01/23 15:44:13
boost::bindはstd::bind2ndとかより実行速度が落ちるって本当ですか？
292:デフォルトの名無しさん
05/01/23 16:18:47
>>291
ためして、みなさいって。
293:デフォルトの名無しさん
05/01/23 16:20:48
using句が,による複数引数を受け付けないのは何故ですか？
using A::AA, A::AB, A::AC;
のように出来たら便利だと思うのですが？
294:デフォルトの名無しさん
05/01/23 17:06:31
本スレの次スレ
【標準C++】C++相談室 part39【STL含む】
ｽﾚﾘﾝｸ(tech板)
295:デフォルトの名無しさん
05/01/23 17:51:32
>>293
そんなんオレらに聞かれても困るよ
296:デフォルトの名無しさん
05/01/23 17:57:05
>>293
プリプロセッサマクロを書くとか?
あんまり便利とも思えないけど
297:デフォルトの名無しさん
05/01/23 22:42:53
boost(かSTL)に、次のような関数テンプレートって含まれていませんか？
template<typename T>
inline void assign(T& lhs, const T& rhs)
{
lhs = rhs;
}
次のような感じで、setterを用意していないメンバ変数(m_is_foo)を変更する関数オブジェクトを作るのに使いたいのです。標準であるならそっちを使いたいなと思いまして。
hoge(boost::bind(assign<bool>, boost::ref(m_is_foo), true));
298:デフォルトの名無しさん
05/01/23 23:01:05
>>297
試してないけど、 hoge(boost::lambda::var(m_is_foo) = true) じゃだめ？
299:297
05/01/23 23:16:36
>>298
> 試してないけど、 hoge(boost::lambda::var(m_is_foo) = true) じゃだめ？
いけました。サンクスです。
うーん、lambdaか…。主観ですが実戦投入はちょっと怖いんですよね。
300:デフォルトの名無しさん
05/02/07 09:18:51
ふぇ～い
Boostを最新リリースにしたら＠VC6
_bvector.hでコンパイラが内部エラー起こしてビルドできない
Releaseビルドなら通った
コンパイラもしょっちゅう固まるし
やっぱ テンプレートをプリコンパイルヘッダにしたのが悪いのかな ・・
301:デフォルトの名無しさん
05/02/07 09:23:19
日記はMeadowにでｍ(ry
302:デフォルトの名無しさん
05/02/07 09:28:51
>>300
ヘッダのインクルード順序を変えてみれ。
自分は面倒なので#ifとか使ってインクルード順序をすぐに変えられるようにしてる。
例：
#if 0 //ここを１にしたり0にしたりする。
#include <boost/regex.hpp>
#include <algorithm>
#else
#include <algorithm>
#include <boost/regex.hpp>
#endif
303:デフォルトの名無しさん
05/02/07 14:42:53
Meta-Programming 専用のスレってない？
304:デフォルトの名無しさん
05/02/07 17:41:03
あったけど、ここに統合。
305:デフォルトの名無しさん
05/02/11 13:36:27
テンプレートを使ったクラスでundefined referenceがでます。
ソースは次のようなものです。プリプロセッサは省略してあります。
//temptest.h
template<class T> class temptest{
public:
temptest();
};
//temptest.cpp
template<class T> temptest<T>::temptest(){}
//main.cpp
int main(){
temptest<int> t;
return 0;
}
gccでは "undefined reference to `temptest<int>::temptest(void)"
VisualC++6では "public: __thiscall temptest<int>::temptest<int>(void)は未解決です"
というエラーです。
ちなみに定義をインラインにしたらうまくできました。
どなたか解決方法を教えてください。
306:デフォルトの名無しさん
05/02/11 13:40:12
>>305
templateの定義はヘッダに書かないとダメ、ということになってます。
307:304
05/02/11 13:50:47
そんな決まりがあったんですか。
でもSTLのインクルードファイルを見たところ宣言だけのようですが、
STLは特別なんでしょうか。
308:デフォルトの名無しさん
05/02/11 13:52:15
STLもヘッダの下のほうに書いてあるんじゃねーの
309:デフォルトの名無しさん
05/02/11 13:52:42
STLも例外ではないよ
クラステンプレートに実体がなくてもその後ろにクラスメンバのテンプレートの実体が定義されてるはず
310:デフォルトの名無しさん
05/02/11 14:13:29
stlportだとcppをヘッダからincludeしてたとおもう
311:デフォルトの名無しさん
05/02/11 14:44:21
ヘッダからcppをインクルード・・・萌えるな。
312:デフォルトの名無しさん
05/02/11 15:04:53
>>307
temptest.cpp コンパイル時には class T が何だか解らないので
コンストラクタは生成されない
↓
main.cpp コンパイル時には temptest<int> のコンストラクタが
どこかにあるものとしてコンパイル
↓
リンクしてみたら、どこにもいない
明示的にインスタンス化するよろし。
//temptest.cpp
template class temptest<int>;
313:デフォルトの名無しさん
05/02/11 16:01:01
exportキーワードをまともに実装した処理系はComeau C++だけでしょ。
314:デフォルトの名無しさん
05/02/11 19:41:42
もう諦めてexportを標準から外した方が良いんじゃないかとさえ思ったり．
現状，exportによる利得というのがほとんど無いみたいですし．
315:デフォルトの名無しさん
05/02/11 21:11:04
つーか既に実装しなくていいよもう、ってことになったんじゃなかったか？
316:デフォルトの名無しさん
05/02/11 21:50:10
>315
ソースきぼんぬ．
export周りは泣きそうなほどグダグダみたいですし，さもありなんですけど．
317:デフォルトの名無しさん
05/02/11 22:10:19
それがC++クオリティ
318:デフォルトの名無しさん
05/02/12 06:49:19
>>316
D&E日本語版読んでみ。
exportは未だに実装してないといけない規格になっている。
319:デフォルトの名無しさん
05/02/12 19:42:14
exportって何？
320:デフォルトの名無しさん
05/02/12 19:42:57
るｂｙ
321:デフォルトの名無しさん
05/02/16 10:47:32
shared_ptrとかintrusive_ptrのリファレンスカウント操作って
引数で値渡しすると呼び出しのたびに操作しますよね。
最適化によるコード削減を阻害しないでしょうか?
特にテンプレートを展開したもののコードがどうなるかが気になります。
322:デフォルトの名無しさん
05/02/16 11:26:01
>>321
適材適所で。
それからテンプレートの勉強もね。
323:デフォルトの名無しさん
05/02/16 11:38:00
>>322 要するにオーバーヘッドはかかるというお答えという理解でよろしい?
intrusive_ptrの参照を渡せばいいんですけど、ポインタの置き換えに使うつもり
でいるといまひとつ面倒というか泥くさいというか。
あと、これらのコンテナをfor_eachなどで処理するときのbind(+lambda)で、
_1 と書くだけじゃdeductionしてくれず、bind(&HogePtr::get, _1)
のようにしないといけないのが面倒で、
これを何とか自動でやってくれるようにする方法はありませんか。
HogePtrという派生クラスを作ってポインタから暗黙的にキャストさせると
一番簡単にコンパイラを黙らせられるんですが、今度はコンテナを処理するときに
毎回HogePtrを作って比較するというコードを出してくるようになるので、
なるべく派生はさせずに済ませたい。
324:デフォルトの名無しさん
05/02/16 20:11:57
参照カウンタによるオーバーヘッドが許せないのなら、
shared_ptr系は精神衛生上使わないほうがいいと思う。
325:デフォルトの名無しさん
05/02/17 00:41:46
>>323
bind の件は既に修正済みのはず。
326:デフォルトの名無しさん
05/02/17 14:17:53
>>323
恐ろしいことだが君のようなハッカーには
それらはもうレガシーだ。boostなのにね。
sandboxにModern C++ Designのを移植した
policy_ptrというのがあるので見るべき
これはなかなか強烈だよ
327:デフォルトの名無しさん
05/02/18 02:14:48
>>326
お前は独逸の詩人かよ!?
328:デフォルトの名無しさん
05/02/18 12:12:10
>>326
ポリシーベースの派、前に検討して却下してshared_ptr達が採用されたのに
なんで今更？
329:デフォルトの名無しさん
05/02/18 20:40:47
>328
その議論読んでみたいんですがどこにありますか？
policy_ptrは「shared_ptrは重い」といった主張を持つユーザに対する
選択肢の一つとして提供されるのだと思いますよ．
そもそもpolicy_ptrはshared_ptrなどの既存のスマートポインタに取って代わるものではなく，
むしろそれらと相補関係にあって共存するべきものですし．
なのでshared_ptrを"legacy"と表現するのは恐らく適切ではないです．
ここら辺のもう少し詳しい議論は以下のスレッドや
policy_ptrのドキュメントのFAQあたりが参考になると思います．
URLﾘﾝｸ(thread.gmane.org)
330:デフォルトの名無しさん
05/02/18 21:19:44
似たような*_ptrばっか増やして、
馬鹿じゃないの？
ふざけてるの？
331:328
05/02/18 21:23:27
>>329
URLﾘﾝｸ(boost.cppll.jp)
の２番目を。
332:デフォルトの名無しさん
05/02/18 23:38:55
>>330
C++ ってそういうもんだよ。人によって用途も違えば、実行環境のリッチさも
天と地ほど違うので。
333:デフォルトの名無しさん
05/02/22 15:00:52
新規にクラスを作るならば、COM のように侵入型の参照ポインタにして、
intrusive_ptr で管理するとか
334:デフォルトの名無しさん
05/02/22 17:27:12
STLかboostあたりに、ある条件を満たすものをoutput_iteratorにコピー
するような関数はないでしょうか?
boost::mplにcopy_ifというそれらしい名前のがあるんですが、
使い方がさっぱりわからない……
335:デフォルトの名無しさん
05/02/22 17:40:29
なぜか std に copy_if ないんだよね・・・
boost::filter_iterator と std::copy でなんとか汁
336:デフォルトの名無しさん
05/02/22 17:43:19
std::remove_copy_if(first, last, std::not1(pred));
337:336
05/02/22 17:43:58
ごめん。
std::remove_copy_if(first, last, out, std::not1(pred);
だ。
338:デフォルトの名無しさん
05/02/22 18:06:02
今回は元のコンテナを変更したくないのでremove_copy_ifは使えなさそうです。
結局自分で書きました。
自分でforループを書くと頭悪くなったように感じるので、
これくらいstdに入れておいてほしいものです……。
template <class InputIterator, class UnaryFunction, class OutputIterator>
void copy_if(InputIterator begin, InputIterator end,
OutputIterator result,
UnaryFunction pred) {
for ( ; begin != end; ++begin)
if (pred(*begin)) {
*result = *begin;
++result;
}
}
g++のヘッダを見るとconcept checkとやらを入れたほうがいいらしいのですが、
何を使えばいいのかよくわからんです。boostに道具があるんでしょうか。
remove_copy_ifも説明がよくわからんのですよね。
削除するのに大きさが変わらないってどういうこと?
339:デフォルトの名無しさん
05/02/22 18:06:58
>>338
remove_copy_ifは入力シーケンスを変更しないよ。
340:デフォルトの名無しさん
05/02/22 18:17:58
>>338
return result;
341:一つ賢くなった!
05/02/22 18:32:43
>>339
おお、本当だ。コードを見るとほぼそっくりではないですか。
今までremove_copy_ifは元のを破壊的に変更しつつ、削除したものを
コピーするのだと思っておりました。
名前がミスリーディングだと思うのです……。
>>340
忘れてました。というか気にしてなかったのですが、返すべきですね。
342:デフォルトの名無しさん
05/02/22 19:24:56
struct NURUPO
{
template<typename T> operator T*() { return 0; }
};
int ILoveNurupo()
{
NURUPO mynurupo;
return (int)mynurupo[0];
}
vc7.1とgcc3.3にガッ
343:デフォルトの名無しさん
05/02/22 21:10:19
なんか違わないか？
344:デフォルトの名無しさん
05/02/23 01:38:28
>>338
STLPortには入ってるよ。
345:デフォルトの名無しさん
05/02/24 14:00:35
テンプレートの特殊化ってどこに書きますか？
以下のように特殊化する型の定義と一緒に書くと、
* primary.h
#include <iostream>
template <class T>
inline void foo(const T&) { std::cout << "primary\n"; }
---
* specialized.h
#include "primary.h"
struct bar {};
template <>
inline void foo(const bar&) { std::cout << "specialized\n"; }
---
* troublesome.h
struct bar;
bar& get_bar();
346:345
05/02/24 14:01:58
* troublesome.cpp
#include "specialized.h"
bar& get_bar() { static bar b; return b; }
void trouble1()
{
foo(get_bar()); // #1
}
---
* main.cpp
#include "primary.h"
#include "specialized.h" // #2
#include "troublesome.h"
int main()
{
foo(get_bar());
return 0;
}
---
#1 と #2 をコメントアウトしたりしなかったりで実行結果が変化します。
具体的には #1 と #2 の両方をコメントアウトした場合 primary が出力されます。
かといって、極端な話 STL のヘッダファイルに書き足すわけにもいけませんし・・・。
347:デフォルトの名無しさん
05/02/25 00:39:40
>>345
URLﾘﾝｸ(www.kuzbass.ru)
14.7.3 -6- および -7- で、
使う場所より前に特殊化は宣言されていないといけない、
というルールは書いてあるが、コンパイラによるチェックは不要ということになっている。
あげくに規格中に「宣言の位置には気をつけろ」と書かれている。
primary.h の foo<T> の中でダミーでいいから sizoef(T) を使って、
不完全型ではインスタンス化できないようにしておけば、
いちおうエラーにすることができると思う。
348:デフォルトの名無しさん
05/02/28 11:44:49
template<class T> class A
{
public:
void hoge() { }
void foo() { }
// 他にいろいろなメンバがある
};
というクラステンプレートがあって、プログラム中でA<T>::hogeだけどこからも使われなかったとき
A<T>::hogeのコードは生成されるのでしょうか?
349:デフォルトの名無しさん
05/02/28 12:01:34
>>348
されない。だから定義しなくても大丈夫。
350:デフォルトの名無しさん
05/02/28 19:22:11
>>348
処理系依存
351:デフォルトの名無しさん
05/02/28 21:47:50
>>350
ほんと？
352:デフォルトの名無しさん
05/02/28 22:10:33
一応標準としてはAの暗黙のインスタンス化ではhogeはインスタンス化されません．(14.7.1/1)
ちなみにAの明示的インスタンス化の際にはhogeのインスタンス化が伴います．(14.7.2/7)
353:デフォルトの名無しさん
05/02/28 22:10:41
>350は狼少年
354:デフォルトの名無しさん
05/03/01 22:32:51
>>348
Modarn C++ Designの1.8に、生成されないことを前提にした技法があったな確か。
シンタックス・チェックだけは、実装によっては行われるんだったっけか。
355:デフォルトの名無しさん
05/03/02 01:29:19
Modern ね
356:デフォルトの名無しさん
05/03/02 12:31:04
スマソ
357:デフォルトの名無しさん
05/03/08 02:55:11
AdobeのASLもここでいいんかな?
358:デフォルトの名無しさん
05/03/08 10:23:35
使われているプログラミング技法を語るならここかな
あるいはBoostスレか
359:デフォルトの名無しさん
05/03/09 18:17:53
以下のコードで complex を set に入れようとしたところ、
「stl_function.h:197: error: no match for 'operator<' in '__x < __y'」
とか言われてしまうのですが (g++ 3.3.3)、原因が分かりません。
何がおかしいのでしょうか。
#include <complex>
#include <set>
using namespace std;
bool operator<(const complex<int> &a, const complex<int> &b)
{
return real(a) < real(b) || (real(a) == real(b) && imag(a) < imag(b));
}
int main()
{
set<complex<int> > s;
s.insert(complex<int>(1, 2));
return 0;
}
360:デフォルトの名無しさん
05/03/09 18:39:00
>>359
<set>の中からそのoperator<()が見えていない。しかしoperator<()を
#includeよりも前に持ってくると今度はcomplexが定義されていない。
しかしstd名前空間内部のものを先行宣言することは許されていない。
自分で関数オブジェクトを定義するしかない。
361:デフォルトの名無しさん
05/03/09 18:40:16
namespace std {
bool operator<(const complex<int> &a, const complex<int> &b)
{
return real(a) < real(b) || (real(a) == real(b) && imag(a) < imag(b));
}
}
で通ったけど、これってやっていいことだっけ……？
362:デフォルトの名無しさん
05/03/09 18:56:02
>>360
> <set>の中からそのoperator<()が見えていない。
これは関係ない。どうせグローバルのoperator<は使われない。
363:デフォルトの名無しさん
05/03/09 19:00:21
>>361
結論：ダメ
宣言や定義をstd名前空間に加えてはならない。今回の場合、struct
std::less<>の特殊化も考えられるが、後述の規定によりuser-definedな名前で
特殊化しない限りundefined behaviorとなる。
17.4.3.1 Reserved names -1
It is undefined for a C++ program to add declarations or definitions
to namespace std or namespaces within namespace std unless otherwise
specified. A program may add template specializations for any standard
library template to namespace std. Such a specialization (complete or partial)
of a standard library template results in undefined behavior unless
the declaration depends on a user-defined name of external linkage
and unless unless the specialization meets the standard library requirements
for the original template.
364:デフォルトの名無しさん
05/03/09 19:17:37
>>362
#include <set>
using namespace std;
struct hoge{int x;};
bool operator<(const hoge& a, const hoge& b){return a.x < b.x;}
int main(){
set<hoge> s;
s.insert(hoge());
return 0;
}
これ通らない？
365:デフォルトの名無しさん
05/03/09 21:08:49
>364
それはhogeとoperator<が同じ名前空間（グローバル）で定義されているので通りますよ．
std::complexを引数とする呼び出しからoperator<が見えるためには
operator<がstd名前空間で定義されていないといけないです．
でもそのような定義をstd名前空間に追加することは許されないので(>363)，
自分で関数オブジェクトを書いて(>360)それをsetのテンプレート引数に与えるしかないです．
366:デフォルトの名無しさん
05/03/09 21:12:46
で、結局こう、と。
#include <complex>
#include <set>
using namespace std;
template <typename T>
struct complex_less: binary_function<complex<T>, complex<T>, bool> {
bool operator() (const complex<T>& a, const complex<T>& b) {
return real(a) < real(b) || (real(a) == real(b) && imag(a) < imag(b));
}
};
int main () {
set< complex<int>, complex_less<int> > s;
s.insert(complex<int>(1, 2));
return 0;
}
367:359
05/03/09 21:25:39
>>360-366
皆さんありがとうございます。よく分かりました。
ちゃんと勉強しないとダメだなぁ～ orz
368:デフォルトの名無しさん
05/03/09 21:55:23
string とか pair が std 名前空間に operator < を定義しているから
ADL のせいで operator < を std 名前空間の外に探しに行かないという認識であってますか？
369:デフォルトの名無しさん
05/03/09 22:09:23
↑俺には断言できん
↓あってるのか？
370:デフォルトの名無しさん
05/03/09 22:11:50
あってる。
371:369
05/03/09 23:24:46
>>368
あってるぞ。
よし、俺ツーポイントゲット。
372:デフォルトの名無しさん
05/03/10 04:08:30
その為に less がテンプレート引数になってるんではないのか。
…と、こないだ初めて map で less を使った俺が言いました。
373:デフォルトの名無しさん
05/03/11 02:09:30
練習で push_back_if なるものを書いてみたのですが
駄目だしお願いします。
template <typename IIte, typename Container, typename Pred>
void push_back_if(IIte b, IIte e, Container &c, const Pred p)
{
for(;b!=e;b++)
{
if(p(*b)) c.push_back(*b);
}
}
insert_if とか copy_if ってないんですか？
あったら便利だと思うのですが・・・。
374:デフォルトの名無しさん
05/03/11 02:24:34
copy_ifはある。あとはback_inserterを組み合わせて使えばよし。
375:デフォルトの名無しさん
05/03/11 02:27:17
> copy_ifはある。
ウソだった。標準ではない。すまん。
376:デフォルトの名無しさん
05/03/11 02:36:13
>>373
残念ながらcopy_ifは標準にはない。どっかに作っておいたら？
//copy_if
template <typename InputIterator,
typename OutputIterator,
typename Predicate>
inline
OutputIterator
copy_if(InputIterator begin,
InputIterator end,
OutputIterator destBegin,
Predicate p)
{
while (begin != end)
{
if (p(*begin)) *destBegin = *begin;
++destBegin;
++begin;
}
return destBegin;
}
377:デフォルトの名無しさん
05/03/11 16:52:41
>>373
> for(;b!=e;b++)
++bにしたほうがいい。
378:デフォルトの名無しさん
05/03/11 19:43:05
>377
また荒れるようなことを
379:デフォルトの名無しさん
05/03/11 20:28:43
いやいや荒れるまでもなく当たり前の事ですよ
380:373
05/03/11 21:26:10
>>374-379
レスが遅くなってすいません。参考にします。
381:デフォルトの名無しさん
05/03/13 00:46:27
荒れてもいいから理由を教えろ
382:デフォルトの名無しさん
05/03/13 01:27:48
>>381
後置インクリメントだと、一時オブジェクトが必要になるから。
POD型の場合でもレジスタを余計に必要としたりね。
#それが理由で後置インクリメントを持たないクラスも作ることも多いし。
383:デフォルトの名無しさん
05/03/13 01:32:28
C++より++C
384:デフォルトの名無しさん
05/03/13 01:50:07
> POD型の場合でもレジスタを余計に必要としたりね。
は？
385:デフォルトの名無しさん
05/03/13 03:26:57
今 typeof が使えるコンパイラって g++, icc の他にどんなのがある？
typeofなんてぶっちゃけ template つかってないと殆ど使わんだろうしここでいいよね。
386:デフォルトの名無しさん
05/03/13 09:54:26
RTTIとテンプレートはあまり関係ないだろうと思いつつ、
ほとんどのメジャーなコンパイラは扱えますよ。
387:デフォルトの名無しさん
05/03/13 09:57:05
typeidじゃないよ。
388:デフォルトの名無しさん
05/03/13 12:31:23
メジャーじゃないコンパイラは"ほとんど"に含まれない言葉のトリック
389:デフォルトの名無しさん
05/03/13 13:47:16
そういうもんだいではない
390:デフォルトの名無しさん
05/03/13 17:59:47
#define FOR_EACH(RANGE, ITERATOR) \\
for(boost::range_iterator::< typeof(RANGE) >::type ITERATOR \\
= boost::begin(RANGE); \\
ITERATOR != boost::end(RANGE); \\
++ITERATOR)
int a[3] = {1, 2, 3};
FOR_EACH(a, it){
cout << *it << endl;
}
391:デフォルトの名無しさん
05/03/13 18:00:22
struct plus
{
template<class LHS, class RHS>
typeof(l + r) operator()(LHS const &lhs, RHS const &rhs) const{
return lhs + rhs;
}
private:
LHS l;
RHS r;
};
392:デフォルトの名無しさん
05/03/13 18:15:58
391間違えました．スレ汚してすいません
template<LHS, RHS>
struct plus_result{
typedef typeof(l + r) type;
private:
LHS l;
RHS r;
};
struct plus
{
template<class LHS, class RHS>
typename plus_result<LHS, RHS>::type operator()(
LHS const &lhs, RHS const &rhs) const
{ return lhs + rhs; }
};
393:デフォルトの名無しさん
05/03/13 18:17:47
typeof って何で標準に入る予定ないの？
394:デフォルトの名無しさん
05/03/13 18:21:14
最初からplus_resultのとこにtypeofを書けばいいような？
395:デフォルトの名無しさん
05/03/13 20:16:10
>>393
そんなこと誰が言ったんだ？
396:デフォルトの名無しさん
05/03/13 22:50:55
条件Aに適合する場合にBを適用するという意味で
apply_if を書いてみたのですが、駄目だしをお願いします。
template <typename IIte, typename CheckPred, typename ApplyPred>
void apply_if(IIte begin, IIte end, CheckPred check, ApplyPred apply)
{
for(;begin!=end;++begin)
{
if(check(*begin)) apply(*begin);
}
}
397:デフォルトの名無しさん
05/03/13 23:18:26
>>396
じゃ遠慮なく。
・名前の省略するな。（×IIte → ○InputIterator）
・Pred は predicate（述語） の略なので、 bool を返す関数以外には使うな。（×ApplyPred → ○UnaryFunction）
・*begin が繰り返されているのは良くない。
・std::for_each() に倣って UnaryFunction を戻り値としたほうがいいかもしれない。
398:デフォルトの名無しさん
05/03/14 00:29:28
>>397
細かいことを言えば、
InputIterator に apply はまずい。
InputOutputIterator じゃ長いけど。
399:デフォルトの名無しさん
05/03/14 01:03:01
とりあえず試しに Visual C++ Toolkit 2003 を使ってみたけど、
typeof() は使えない模様。__typeof とかなんかあったりするのかな？
400:デフォルトの名無しさん
05/03/14 01:06:34
>>398
イテレータのコンセプトを表すという意味で InputOutputIterator はありえない。
出力も兼ねると言うことなら、現行の規格では ForwardIterator が候補になるだろう。
しかしここも std::for_each() に倣って InputIterator とするのが正解だろう。
401:デフォルトの名無しさん
05/03/14 01:13:19
なんなんだよ、typeof()って？
初めて聞いたぞ。
type_infoクラスとtypeid演算子ならC++にあるけど、
typeof()は何をするためのもの？
402:デフォルトの名無しさん
05/03/14 01:21:18
>>401
まず最初に言っておくと、typeofは今のところまだ標準には無い。
で、まぁ名前の如く変数の型を得る演算子(?)の事。
Type a;
typeof(a) b = a;
みたいに使える。
この例では a の型が分かってるけど、Expression Template なんかの場合はどえらい事になっちゃうっしょ。
って分かりにくいかなぁ。誰か分かりやすい例キボンヌ。
403:デフォルトの名無しさん
05/03/14 01:27:44
その程度だとtypeid, type_infoとどう使い方が違うのか見えんな。
404:デフォルトの名無しさん
05/03/14 01:29:18
テンプレート宣言の
template<typename HOGE>
を適宜、
template<typename HOGE, typename PLUS_TYPE>
にすれば回避できるんじゃないの？
曖昧さの解決にもなるし。
というか、C++とtypeof()は相性が最悪な気がする。
多重継承さえ嫌がる人が多いというのに、
typeof()は、無駄にデバッグ作業を増やさせるだけではないか？
405:デフォルトの名無しさん
05/03/14 01:31:35
>>400
ForwardIteratorが正しいね。
しかし、InputIterator で要素の変更を行うのは論外では？
for_each()は変更を伴わない関数。
本質的に違う関数に倣うという理由付けも理解に苦しむ。
406:デフォルトの名無しさん
05/03/14 02:01:52
>>405
std::for_each() で要素の変更は許される方向にあるらしい。
URLﾘﾝｸ(www.open-std.org)
「いまさら禁止されては困る」という本音が多分にあるだろうと思うので、
明示的に許可を後付けされてもすっきりしないよな。
はっきりと Mutating algorithm に移動させて欲しい。