09/03/02 03:21:34
>198
struct MyModule {
void extend_function() {
// ……
};
};
class MyClass : public MyModule {};
派生クラスを操作する必要がある場合は
template<typename T>
struct MyPolicy {
MyPolicy& self() { return *(static_cast<MyPolicy*>(this)); };
void extend_function() {
// ……
};
};
class MyClass : public MyPolicy<MyClass> {};
201:200
09/03/02 03:22:29
あ、間違えた
template<typename T>
struct MyPolicy {
MyPolicy& self() { return *(static_cast<T*>(this)); };
void extend_function() {
// ……
};
};
202:デフォルトの名無しさん
09/03/02 04:05:44
>>201
selfの戻り値もT&だろ。
203:デフォルトの名無しさん
09/03/02 09:50:38
大元のclass MyClassの記述を変更せずに、という(多分)そもそもの目的に外れるのでは。
何か便利な文字列操作メソッドを追加したいとかで使うんだろうけど、
std::string弄るわけにはいかないし。
204:デフォルトの名無しさん
09/03/02 13:34:46
思ったんだけどstructとclassの違いって何だろう？
205:デフォルトの名無しさん
09/03/02 13:37:18
>>204
継承とメソッドのデフォルトがpublicかprivateかの違いだけ
206:デフォルトの名無しさん
09/03/02 13:42:52
Boost.Iterator使ってイテレータ作るときのオブジェクトはstructにしないとコンパイルエラー出るな
デフォルト継承の問題のようだが
207:デフォルトの名無しさん
09/03/02 20:36:56
>206
つ friend class boost::iterator_core_access;
208:デフォルトの名無しさん
09/03/03 21:25:08
ARM用にクロスコンパイルができない。bjamで正しく設定すればコンパイル通るのか
209:デフォルトの名無しさん
09/03/06 22:44:20
更新しました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Config]
config: add cpp0x files not added after merge
config: fix both BOOST_HAS_LONG_LONG and BOOST_NO_LONG_LONG getting defined at the same time for some compilers
[Math]
Add option to disable use of std::fpclassify.
Fix for no long double support.
[Bind]
Make bind.hpp and mem_fn.hpp forward to bind/bind.hpp and bind/mem_fn.hpp. (Ref #2238)
[Unordered]
Add missing return for operator=.
[Smart_ptr]
Move smart_ptr into boost/smart_ptr/*.hpp (refs #2239).
Fix enable_shared_from_this-related tickets in trunk. Refs #2126. Refs #2584.
[Signals2]
Merged Signals2 from sandbox to trunk.
[Graph]
Fix: Avoid compiler warning if BOOST_NO_HASH is already defined.
210:デフォルトの名無しさん
09/03/06 23:57:23
あのーーー
>>209にうｐされてるのVC2005では使えないんですか？
211:デフォルトの名無しさん
09/03/07 00:47:58
VC2008SP1でビルドしておりますので、VC2005では恐らく使えないと思います。
次回からその旨分かる様に、ファイル名に"VC2008"を追加致します。
212:デフォルトの名無しさん
09/03/07 00:53:37
>>211
そうなんですか、同じコンパイラメーカーのでもバージョン違うと駄目なんですか,orz
213:デフォルトの名無しさん
09/03/07 04:54:22
>212
少し古いバージョンで良いならこっから落とせるよ。
2003, 2005, 2008 用をインストール時に選択可能。
URLﾘﾝｸ(www.boostpro.com)
214:デフォルトの名無しさん
09/03/07 09:40:22
コンパイラによって関数の対応状況変わるから調べたほうがいいよ
215:デフォルトの名無しさん
09/03/08 14:57:29
最近はヘッダファイルをジャンルごとにディレクトリ切るように移行中なのか。
あとspirit使うとclassicのヘッダファイル使えと警告出るんだけど、classicじゃないspiritの使い方って
どっかに書いてあるんだろうか・・・（公式ドキュメントも前のまんまだった）
216:デフォルトの名無しさん
09/03/08 15:05:58
>>215
spiritはV2になるから準備じゃないか？今のマニュアルがclassicに相当するようだ。
俺も最近spirit始めたところで悩んだ。
classicヘッダは名前空間がclassicに変わってるから注意だ
217:デフォルトの名無しさん
09/03/12 20:47:14
すでに自己解決した問題なんだけど、ぐぐっても日本語の情報が見つからなかったので、垂れ流しておきます。
環境依存(MinGW)っぽい話で、ここに書くべきか分かりませんが。自分の環境は
OS: Windows XP (Home Edition, SP2)
コンパイラ: gcc version 3.4.5 (mingw-vista special r3)
boost 1.38.0
<boost/date_time/filetime_functions.hpp> がインクルードされるときに以下の警告が出ます。
> (略)/boost/date_time/filetime_functions.hpp:101: warning: left shift count >= width of type
この警告は、該当のファイルの99行目と100行目の UL を ULL に書き換えると出なくなります。
書き換え前
> const uint64_t c1 = 27111902UL;
> const uint64_t c2 = 3577643008UL;
書き換え後
> const uint64_t c1 = 27111902ULL;
> const uint64_t c2 = 3577643008ULL;
こういう解決法でいいのか、よく分かりませんが。今のところ Boost Trac のTicket #2809で報告されています。
218:デフォルトの名無しさん
09/03/13 15:59:34
> const uint64_t c1 = UINT64_C(27111902);
> const uint64_t c2 = UINT64_C(3577643008);
じゃ駄目なの？
219:217
09/03/13 16:26:19
>>218
そっちのほうが良さそうですね。（そのマクロは初めて知りました）
私の環境では、マクロ __STDC_CONSTANT_MACROS を自分で定義しないとUINT64_Cが使えませんでしたが、
定義するとうまく行きました。後の人の参考までに。
220:デフォルトの名無しさん
09/03/13 17:54:45
更新しました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Signals2]
some inspect cleanups (mostly getting rid of tabs).
Finally fixed some odd test errors on msvc9.
[Smart_ptr]
De-optimize assignment into this_type(r).swap(*this)
Attempt to fix como link failure.
[Functional]
Move hash_fwd into the hash subdirectory.
Remove deprecated headers.
[Math]
Misc. small platform specific fixes and expected error rate adjustments.
[Fusion]
Protected unused_type by an ADL barrier
[Numeric]
added unit test for LU decomposition
add new constructor from vector to permutation matrix
[Serialization]
checked in new type trait - is_virtual_base_of.hpp
Try new version of is_virtual_base_of.hpp
[Wave]
Wave: now compiles even with BOOST_FILESYSTEM_NO_DEPRECATED defined
[Typeof]
BOOST_TYPEOF_NESTED_TYPEDEF now supports expressions containing "this" for VC compilers
[Detail]
Initial commit.
[Config]
Added configuration macros BOOST_NO_AUTO_DECLARATIONS and BOOST_NO_AUTO_MULTIDECLARATIONS.
[Function]
60% speedup on a micro-benchmark that copies and calls such function objects repeatedly.
221:デフォルトの名無しさん
09/03/16 00:17:11
boost1.36.0を使っているのですが、ファイルの絶対パスから相対パスを取得する良い方法は何か無いでしょうか…？
222:デフォルトの名無しさん
09/03/16 00:29:11
あれ？relative_path()ってまさにそのためのメソッドじゃなかったっけ？
223:デフォルトの名無しさん
09/03/17 17:05:03
ublasにqr分解する関数ないですか？
lu分解はあるようなんですけど
224:デフォルトの名無しさん
09/03/17 18:58:20
>>223
「ublas qr分解」で検索すると、boost.ublasで実装した例が見つかるくらいだから、
直接qr分解するような関数はないんじゃね?
225:デフォルトの名無しさん
09/03/18 13:45:04
pythonのc apiが変更になるみたいだけど
boost.pythonは対応してくれるんだろうか
特に日本語文字列を渡せるかあたりが変わるとか
226:デフォルトの名無しさん
09/03/18 15:24:07
この機会にLuaとかSquirrelとかに移行してみるというのはどうだろう。 いやもちろん用途次第だけど。
227:デフォルトの名無しさん
09/03/18 15:46:02
v8でJavaScriptとか・・・
試してみたらかなり楽に使えたんでびっくりした
228:デフォルトの名無しさん
09/03/18 17:49:16
>>226
Boost.Luaとか期待しています。
229:デフォルトの名無しさん
09/03/18 18:07:26
pythonってライブラリのサポート率が凄く高いんだよね。
だから簡単に他に移行するのは、結構難しいんじゃないかな。
230:デフォルトの名無しさん
09/03/19 09:20:09
じゃあ俺はBoost.AngelScriptを期待。
231:デフォルトの名無しさん
09/03/20 18:54:29
更新しました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Type_traits]
Add is_virtual_base_of.
Add extra tests for is_base_of to test virtual inheritance.
[Math]
Add instrumentation code and some FPU control options.
Updated the sign functions to use Johan Rade's fp-utilities code.
[Serialization]
Use new is_virtual_base_of
[Config]
Revert 51733 - it broke the regression testing system
[Proto]
work around issue with <termios.h> #define'ing B0
add proto::noinvoke to block metafunction invocation in ObjectTransforms
[Tuple]
fixed tuples::length not having a specialization for const tuple<> and const null_type
232:デフォルトの名無しさん
09/03/21 00:16:11
以下のコードでVC++2005だとエラーは出ませんがIntelC++11だと「オペランドの型に互換性がありません ("boost::foreach_detail_::rvalue_probe<const ListInt>" と "const ListInt")」というエラーが出ます。どうしたら回避できるんでしょうか？
#include <boost/foreach.hpp>
#include <list>
typedef std::list<int> ListInt;
int _tmain(int argc, _TCHAR* argv[])
{
ListInt A;
ListInt& B=A;
const ListInt& C=A;
BOOST_FOREACH(const int& i,B)
{
}
BOOST_FOREACH(const int& i,C) //ここでエラー
{
}
return 0;
}
233:デフォルトの名無しさん
09/03/21 09:12:24
まったくの勘で物をいってすまないが、
BOOST_FOREACH(int const& i,C)
とかでだめかな？
234:デフォルトの名無しさん
09/03/21 09:35:01
BOOST_FOREACH(const int& i,C)
も
BOOST_FOREACH(int const& i,C)
も同じ意味
235:デフォルトの名無しさん
09/03/21 09:37:23
そもそもconst int&でなくintにしてみたらどうだろう。
それでだめならforeachの実装覗くしかないんじゃね。
236:デフォルトの名無しさん
09/03/21 12:06:26
class step_iterator : public boost::iterator_facade<step_iterator,int , boost::bidirectional_traversal_tag>
{
public:
explicit step_iterator(int v, int s = 1):value(v), step(s){}
private:
friend class boost::iterator_core_access;
void increment()
{
value += step;
}
void decrement()
{
value -= step;
}
int& dereference() const
{
return value;
}
bool equal(const step_iterator& other) const
{
return value >= other.value;
}
int value;
int step;
};
237:236
09/03/21 12:07:13
>>236
int に対する iterator で increment でstepずつ増やす iterator を
作ってみてるのですが、dereference() の箇所で
error C2440: 'return' : 'const int' から 'int &' に変換できません。
とエラーになってしまいます。
メンバーのvalueをintへのポインターにして、dereference()で*valueを
返す様にしたら期待した動作をしてくれます。
また、const_cast しても期待した動作になります・・・
なぜ、int では駄目なのでしょうか？
238:デフォルトの名無しさん
09/03/21 12:46:15
URLﾘﾝｸ(d.hatena.ne.jp)
ここのUDP通信のソースで質問なんだけど、
send_to()ではIPとポート指定してるのに、
何故recv_from()では必要無いんですか？
boost::asio::ip::udp::socket がIPとかを記録するんじゃないかと思ったんだけど、
リファレンスマニュアル見ても明確に書いてなかった
239:デフォルトの名無しさん
09/03/21 14:32:08
>>236
メンバ関数のconst外す or 戻り値にconst付ける
>>238
郵便を送るには送り先住所が必要ですが、受け取るにはポストを設置しておけばいいだけです。
receive_fromに渡しているendpointは差出人の住所を受け取るためのバッファです。
ちなみにそのページの非同期コードは未定義だね。
240:デフォルトの名無しさん
09/03/21 15:00:11
>>239
>>戻り値にconst付ける
error C2440: 'return' : 'const int' から 'int &' に変換できません。
>>メンバ関数のconst外す
error C2662: 'step_iterator::dereference' : 'const step_iterator' から 'step_iterator &' へ 'this' ポインタを変換できません。
iterator_core_access::dereference が
static typename Facade::reference dereference(Facade const& f)
{
return f.dereference();
}
だから const はずせないです。
241:デフォルトの名無しさん
09/03/21 15:04:38
>237
> int& dereference() const
const メンバ関数なので this は const step_iterator*。
従って、メンバの value も const int になります。
これは変更不可能なので、変更可能な参照 int& として返すことができません。
value を int* にした場合は、int * const になり、ポインタ値としては const ですが、
指している int の値は変更可能なので int& にできます。
> public boost::iterator_facade<step_iterator,int , boost::bidirectional_traversal_tag>
> int& dereference() const
ではなくて
> public boost::iterator_facade<step_iterator,const int , boost::bidirectional_traversal_tag>
> const int& dereference() const
でどうでしょう？
242:デフォルトの名無しさん
09/03/21 15:18:52
>>241
うまくいきました。
dereference()して値を変えたい場合は、ポインターなどにしてやる必要があるんですね。
>const メンバ関数なので this は const step_iterator*。
>従って、メンバの value も const int になります。
>これは変更不可能なので、変更可能な参照 int& として返すことができません
調べてると、「mutableでないと駄目」とか書いてあったけど、↑のことだったのか・・・
243:デフォルトの名無しさん
09/03/21 15:58:49
>>238
recv_fromはbindでポートと結びついてるソケットで読み込んでるからでないの？
244:238
09/03/21 16:17:09
>>239
UDPでは（？）どのポートに来たメッセージも受信できちゃうってことですか？
>>243
bind()ではポート番号とか渡してないみたい
245:デフォルトの名無しさん
09/03/21 18:27:28
>244
send_toの時にバインドされてる
246:238
09/03/22 08:53:20
>>245
やっぱそうなのか
この辺で失礼します。ありがとう
247:デフォルトの名無しさん
09/03/22 18:01:34
vc2008EE sp1 winxp boost1.38(boostpro)で
int x = 1, y = 10;
(boost::lambda::_1 + boost::lambda::protect(boost::lambda::_1 + 2))(x)(y);
がコンパイル通らないんだけど、なんで？
error C2664: 'boost::lambda::lambda_functor<T>::lambda_functor(const boost::lambda::lambda_functor<T> &)' : 1 番目の引数を 'const boost::lambda::lambda_functor<T>' から 'const boost::lambda::lambda_functor<T> &' に変換できません。
248:デフォルトの名無しさん
09/03/22 18:57:14
とりあえず解決法だけ
(x)を(boost::cref(x))にする(refでもおk)
gcc-4.4, boost trunkで動作確認できた
249:デフォルトの名無しさん
09/03/22 21:42:42
Boostライブラリって同じ機能・もしくはちょっと違う機能のついた別クラスが
多い．
こういうとこ改善しないのかな？
250:デフォルトの名無しさん
09/03/22 21:59:52
>>249
具体的にどれのこと？全部挙げなくて良いからさ。
あと、改善しないのか気になるんなら、直接提案してみれば良いよ。
251:デフォルトの名無しさん
09/03/22 22:22:20
249じゃないけど、bindとlambda::bindとかtupleとfusionとか
これまで書かれたコードがあるから一本化できないんだろ
どっちかが非推奨になることはあるかもしれんが
boostのライブラリは便利だけど、組み合わせようとするとあれ？ってなる感じがする。
lambdaはresult_ofに対応したんだっけ？
252:デフォルトの名無しさん
09/03/22 22:33:56
boost/functionを使うときにはたいていboost/bindも使うとか
文字列処理クラスが機能かぶってるとかのことを言ってるのか？
おれは↑と他ちょっとしかboostしないから知らないけどなんかあんの？
253:247
09/03/22 22:46:02
boost::protect の一番わかりやすい（シンプルな）
サンプルコード教えてください。
(boost::protectの有無で結果変わるやつ)
254:232
09/03/24 22:59:56
>>233-235
直らなかったので、ソースを調べました。
コンパイラのバージョンチェックがまずかったようです。
boost/foreach.hppの頭のほうの行の
|| BOOST_WORKAROUND(BOOST_INTEL_WIN, <= 810)
を、以下のように変えたらコンパイラが通りました。
|| BOOST_WORKAROUND(BOOST_INTEL_WIN, <= 1100)
とりあえず、これで様子見です。
255:デフォルトの名無しさん
09/03/27 22:43:50
更新しました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Fusion]
added default implementation for iterator_facade
[Math]
Fix bug in cyl_bessel_i that hits when v=0.5 and x is small.
[Archive]
Throw new exception when program class version is less than file class version.
[Serialization]
moved to type traits
[Smart_ptr]
Move enable_shared_from_this2.hpp to boost/smart_ptr.
[Timer]
Fix spelling boo boo (Shawn Roe)
[Regex]
Patch for ICU on AIX.
[Type_traits]
Added has_new_operator from Robert Ramey.
[Filesystem]
System, Filesystem: remove boost/detail/test_framework.hpp;
use boost/detail/lightweight_test.hpp instead (Thanks to Peter Dimov for pointing this out)
[Units]
Fix return type for division by a constant
[Tr1]
shared_count.hpp has moved.
[Interprocess]
Changes for Boost.1.39
[Intrusive]
Changes for Boost.1.39
[Bind]
Add ref_compare for weak_ptr. Refs #2849.
256:デフォルトの名無しさん
09/03/28 16:52:31
Spirit使っている人に聞きたいです。
eps_pを使うと括弧を減らせるみたいらしいですが、
俺的にはeps_pを使うよか括弧を使う方が分かりやすいと思うんです。
みさなんはどう思いますか？
257:デフォルトの名無しさん
09/03/28 19:26:02
ウロ覚えだが括弧の中に括弧がネストしてる場合もちゃんと処理してくれるんじゃなかったっけ
258:256
09/03/28 19:31:45
>>257
そー言われれば、括弧のネストを解消して括弧の数を減らせるな。
…あと、見やすいかどうかは主観に寄るよなやっぱ。
259:デフォルトの名無しさん
09/03/29 01:38:49
Spiritに関して
パーザーPARがあったとして、PARにマッチしないって言うのを表すにはどう書けばいい？
具体的には
boost::spirit::sign_p
にマッチしないって言うのを表したかったのだが、
~boost::spirit::sign_p
とやったらoperator~はsign_pには定義されていないよっていうエラーがでるんだけど・・・。
260:259
09/03/29 01:54:34
boost::spirit::anychar_p-boost::spirit::sign_p
で良かったか。
事故解決した気がするが、これで間違っていたら教えてくれ。
261:デフォルトの名無しさん
09/03/29 14:41:25
>>260
手っ取り早い方法だとそれで良いと思う。
ただ、anychar_p sign_pの両方が評価されるので、
-を使った方法は多用しまくると効率悪いかもね。
＜この例なら気にならないだろうけど
262:デフォルトの名無しさん
09/03/29 14:41:39
Spiritにて
expr=
(
+(boost::spirit::digit_p)//[&the_func]
>>
*(
(boost::spirit::ch_p('!'))//[&the_func]
)
)//[&the_func]
この3カ所にセマンティックアクション
void the_func(const char* const, const char* const)
を入れたかった。しかし実際やってみると
3つ目のthe_funcの場所「以外」入れられずコンパイルエラーになる。
何で？
263:=260=259
09/03/29 14:42:35
>>261
ありがとう。初めて使ってみて今3日目。感動を禁じ得ない。
264:デフォルトの名無しさん
09/03/29 14:54:09
>>262
間違ってるかもしれないが、デフォルト定義パーサ(の一部？)には、
セマンティックアクションを組み込めなかったかも？
いったん別なルールに入れれば良かったんじゃなかったっけ？
rule a,b;
a = digit_p;
b = ch_p;
expr = +a[&fnc] >> *b[&fnc] ～
みたいに。
265:デフォルトの名無しさん
09/03/29 14:55:22
>>264
やってみる！
266:デフォルトの名無しさん
09/03/29 14:55:42
あるいはこうだったかも
a = digit_p[&fnc];
b = ch_p[&fnc];
267:262
09/03/29 15:05:31
boost::spirit::rule<scannerT> expr, num_p, exclamation_mark_p;
num_p=boost::spirit::digit_p;
exclamation_mark_p=boost::spirit::ch_p('!');
expr =
(
+num_p[&the_func]
>>
*(
exclamation_mark_p[&the_func]
)
)
;
これで出来た！動作も今のところ大丈夫っぽい。
ありがとう。
ちなみに
a = digit_p[&fnc];
b = ch_p[&fnc];
は死にました。
やっぱりおっしゃるとおり、プリミティブパーサには直接セマンティックアクションを入れられない場合があるみたい。
268:262
09/03/29 15:08:45
ただし
int_p[&PUSH]
とかやる時は直接プリミティブパーサにセマンティックアクションを付けてもおｋなのか。
むむぅ。
初めて知った。
269:デフォルトの名無しさん
09/03/29 15:09:18
アクション関数のシグネチャが違うんじゃないの。
270:268
09/03/29 16:55:52
>>269
ぽいね。
int1つを受け取るセマンティックアクション用の関数とint_pならおｋなのか。
どうも。
271:デフォルトの名無しさん
09/03/31 16:11:05
文字列の前後の空白を除去する関数が欲しくてBoost.Xpressiveを使って自作しようと思った。
ところがよく見ると<boost/algorithm/string>にtrimという目当ての関数(？)があるようで、
それを使おうかなとも思っている。
でも<boost/algorithm/string>をインクルードするとそれ全体の分で結構バイナリってでかくなっちゃう？
それともtrimしか使わないならtrimに相当する分だけがバイナリになって
他の<boost/algorithm/string>の部分は付いてこない？
Boost.Xpressiveは別の用件で使っているから抵抗ないんだが、
<boost/algorithm/string>はこのtrim以外で使う予定がないもんだから、
ちょっと心配なんだけど、教えてくださいませんか？
272:デフォルトの名無しさん
09/03/31 16:12:54
マップファイル出力付きでコンパイルして確認してみればよいじゃまいか
273:デフォルトの名無しさん
09/03/31 16:28:54
悩まず即自作してたら、30分で解決したんじゃないか？ｗ
274:デフォルトの名無しさん
09/03/31 16:35:53
じゃ<boost/algorithm/string/trim.hpp>
275:デフォルトの名無しさん
09/03/31 16:53:41
みんなありがとう。
やってみる。
276:デフォルトの名無しさん
09/04/02 22:43:22
boost/algorithm/string/trim.hpp
だけincludeすれば、少しはマシかも
277:デフォルトの名無しさん
09/04/03 15:08:33
>>276
>>274
278:デフォルトの名無しさん
09/04/03 19:33:45
Boost.Spiritを使った適当なプログラムを書いてみた。
そのプログラムは
#include <boost/spirit/core.hpp>
となっているのだが、これをより広く
#include <boost/spirit.hpp>
にしたプログラムを作ってみると、
（他は全く変更していないのに）ファイルサイズが違うのだが、なんで？
環境は
Windows XP, g++でコンパイルオプションは-O2
なんだが、実際に使われていない関数やクラスもリンクされてバイナリになっているってこと？
279:デフォルトの名無しさん
09/04/03 20:43:32
グローバル変数の初期化関連じゃないか。
280:デフォルトの名無しさん
09/04/04 01:21:35
更新しました。 今週の更新の大半はドキュメントとGraphのアップデートでした。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Flyweight]
made Boost.Interprocess names shorter to accommodate some filesystems
[Type_traits]
Add missing #includes.
[Graph]
Renamed some functions to work better on some compilers
First batch of merges from Parallel BGL
Merged more changes from Parallel BGL
[Spirit]
Fixes to exception messages.
Fixes to some exception messages.
[Numeric]
storage.hpp: fix #2891, now check new size instead of old one
[Proto]
fix proto::lazy
281:278
09/04/04 11:12:22
>>279
あーなるほど。
282:デフォルトの名無しさん
09/04/04 11:15:31
>>280
利用させてもらっています
いつも乙です
283:デフォルトの名無しさん
09/04/04 11:42:04
>>280
お疲れ様です。
284:デフォルトの名無しさん
09/04/04 12:46:44
Boost.Spiritの構文木作成について学べるサイトがあったら教えてください。
日本語がいいです。
285:284
09/04/04 12:51:11
ちなみに俺がググったところ
パースツリーを作る
URLﾘﾝｸ(homepage3.nifty.com)
がヒットしているんですが、もしみなさんのオススメがあれば是非知りたいです。
286:デフォルトの名無しさん
09/04/05 17:00:21
Windows XP SP2, MinGW(g++ 3.4.5)をインストールして使っています。
コマンドプロンプトで
g++ something.cpp -I "C:\BoostC++Libraries"
として使っていますが、毎回インクルードパスを入力するのが面倒で、
環境変数で省略出来るのではないかと思い調べてみました。
その結果、
CPLUS_INCLUDE_PATHにboostのパス(私の場合C:\BoostC++Libraries)
を設定すれば大丈夫という記述を見つけたのですが、
実際に設定してみてもうまくいきません。
(インクルードパスを省略してg++ something.cppだけでコンパイルできません。)
近い環境の方で、出来ている方はいらっしゃいませんか？
287:デフォルトの名無しさん
09/04/05 17:04:10
つ[makefile]
288:デフォルトの名無しさん
09/04/05 17:07:27
自分もその環境変数でうまくいかなかったから、.bashrcで
alias g++='g++ -I /cygrive/.../boost_1_38_0'
のようにしている。お察しの通り、Cygwinだけど。
289:デフォルトの名無しさん
09/04/05 17:16:54
俺は>>286と同じ環境で、コマンドプロンプトでCPLUS_INCLUDE_PATHを設定すると
ちゃんと読みに行ってくれるよ。
まあ、普段はmsys使ってるけど。
290:デフォルトの名無しさん
09/04/05 17:20:09
>>287-289
みんなありがとう。
やっぱみなさん色々やってんのね。
291:デフォルトの名無しさん
09/04/05 17:25:51
結果、GUIでなく、
>>289さん方式(コマンドプロンプトからCPLUS_INCLUDE_PATHを設定)
でインクルードパスの指定が不要になりました。
愛してる。
292:デフォルトの名無しさん
09/04/05 18:37:11
たぶんね、マイコンプータのプロパテから環境変数を設定したあと再起動してなかったでしょ
293:デフォルトの名無しさん
09/04/05 19:05:13
>>292
それもしてなかったです。
設定→ダメじゃん→設定を削除して元に戻す
しかしてなかったです。
それも試してみます。
294:デフォルトの名無しさん
09/04/05 19:58:48
大元の環境変数は再起動しないと反映されないよ
Windowsはね
295:デフォルトの名無しさん
09/04/05 20:03:06
>>294
Linuxなら再起動しなくても反映されますか？
296:デフォルトの名無しさん
09/04/05 20:14:28
環境変数を設定したシェルから起動したシェルでは大丈夫。
297:デフォルトの名無しさん
09/04/05 20:48:55
環境変数で悩める２８６が羨ましいぜ
二日掛りでmingw + bjamの罠から未だ抜け出せない。
298:デフォルトの名無しさん
09/04/05 20:55:33
bjamってmingwには未対応ってことになってるよね、確か。
俺はcmd.exeからbjamを使ってコンパイルして、使うときはmsysからmingwを使ってる。
これで Program Options と Thread を使ってるが、一応うまく動いてるぞ。
299:デフォルトの名無しさん
09/04/06 15:19:32
俺もmingwだけど、includeファイルは標準のところにぶち込んだ
300:デフォルトの名無しさん
09/04/07 13:48:14
何かWikiに「gzipはGPL」って書いてるんだが、これは
・RFC1952で記述されてるアルゴリズムを元に作ったgzipという圧縮ツールがGPL
・boostに含まれているgzipライブラリはboostライセンス
って事だよな？
301:デフォルトの名無しさん
09/04/07 13:59:08
どこのWikiの話だよ
302:デフォルトの名無しさん
09/04/07 14:03:15
>>301
すまん、以下のところ。
URLﾘﾝｸ(ja.wikipedia.org)
303:デフォルトの名無しさん
09/04/07 17:55:46
boostが使ってるのはgzipじゃなくてzlibだろ
304:デフォルトの名無しさん
09/04/07 19:30:15
boostのshared_ptrを使ってると
再帰関数内ですぐにスタックオーバーフローになる。
305:インドリ
09/04/09 10:05:55
URLﾘﾝｸ(blogs.wankuma.com)
URLﾘﾝｸ(d.hatena.ne.jp)
306:デフォルトの名無しさん
09/04/09 12:13:53
不買活動？
307:デフォルトの名無しさん
09/04/09 13:48:24
> 税込2,940円
高い！
308:デフォルトの名無しさん
09/04/09 21:14:12
>>304
shared_ptrって８バイトしかないんだし、別の問題じゃね？
309:デフォルトの名無しさん
09/04/09 21:38:38
>>305 欲しい
310:デフォルトの名無しさん
09/04/09 21:59:59
>>305 欲しくない
311:デフォルトの名無しさん
09/04/09 22:17:12
欲しいとか欲しくないじゃない。うざいから買いたくない。
本屋で平積みしてたら、上に萌々linux載せてあげてもいい。
312:デフォルトの名無しさん
09/04/09 22:25:32
内容がまともなら、日本語でC++の本が増えて喜ばしいことだと思う。
313:デフォルトの名無しさん
09/04/09 22:51:32
>>305
のインドリってヤツ、
> ・投稿者は、話題と無関係な広告の投稿に関して、相応の費用を支払うことを承諾します
広告費払ったのかな？
おまけにマルチ野郎か。
ｽﾚﾘﾝｸ(tech板)
314:デフォルトの名無しさん
09/04/09 22:51:57
>>308
デストラクタが再帰的に呼び出されることじゃねーの
315:デフォルトの名無しさん
09/04/10 00:47:52
functionを配列にして、それにlambdaを入れて使っています。
第１引数に構造体へのポインタを取って、そのメンバを書き換えているのですが
加算代入をやると変な値になってしまいます。
回避方法はもう分かったのですが、値が壊れてしまう原因が知りたいです。
URLﾘﾝｸ(bucyou.mydns.jp)
コンパイラはVC2008Express、boostのバージョンは1.38です。
316:デフォルトの名無しさん
09/04/10 11:25:38
> ( (_1->*_x) += 0.5),
も
( (_1->*_x) += constant(0.5))
ってすればいいんでは？
317:316
09/04/10 11:31:06
同じ環境動作確認済み
出力結果
1, 1
10, 1
10, 20
10.5, 20
10.5, 20.5
318:デフォルトの名無しさん
09/04/10 14:44:28
それが
> 回避方法はもう分かったのですが
ってことだと思う。なんで0.5の場合はconstantつけないとおかしくなるの？って質問では。
319:デフォルトの名無しさん
09/04/10 16:11:25
0.5がラムダ式として扱われず、すぐに評価されてしまうから
constantを付けることで、ラムダ式にして評価を遅延させる。
constantを付けないと(_1->*_x)なラムダ式に0.5を加算して
おかしなことになる。
320:デフォルトの名無しさん
09/04/10 17:51:10
更新しました。今週はビルドシステムとドキュメントとGraphを中心にかなり大量の更新が為されています。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Graph]
Merged headers and source files (but not examples, tests, or docs) from Parallel BGL
[Spirit]
New lexer guts struct: note detail namespace!
[Wave]
Use data() accessor on state_machine.
[Mpl]
add mpl::char_ and mpl::string, fixes #2905
[Program_options]
Merge from release:
[Detail]
Avoid an unnecessary copy in 'operator[]'
[Exeption]
added functions: current_exception_diagnostic_information, current_exception_cast
[Graph,Mpi,Pending,Property_map,Python,Signals]
Moved property map library into property_map/ directory;
made old files into stubs with #warnings;
converted uses and docs of property map library to use new names
[Flyweight]
fixed a thread safety bug in refcounted
[Math]
signbit can return either zero or not, rather than true/false.
[Format]
Fixed unused parameter - bug #2455
[Config]
As of STLport 5.2, unordered_set and unordered_map have been moved
from the std:: namespace to the std::tr1:: namespace
[Asio]
Prevent locales from affecting the formatting of endpoints. Fixes #2682.
321:315
09/04/10 20:58:38
>>319
ありがとうございます。
警告レベルを/W3から/W4へ引き上げたら、「代入演算子が生成できない」という警告が出ました。
警告の内容はよく分からないんですが、やっぱり型がおかしかったみたいです。
// Release設定でコンパイルしたら何故か正常に計算されて笑いましたけど。
322:デフォルトの名無しさん
09/04/10 21:22:27
>>321
ReleaseとDebugどちらか片方でのみ正常に動作する場合、
参照先が「初期化されていない」か「既に解体されている」ことが多い。
315は「+=」で生成されるオブジェクトが0.5をconst参照で保持しているのが問題。
0.5は一時変数なので、funcの初期化が完了した時点で解体される。
「=」が正常に動作するのは、10.0をコピーして保持しているため。
constant(0.5)も同様。
323:デフォルトの名無しさん
09/04/12 16:25:57
typedef boost::mpl::vector<int, char, std::string> vector;
typedef boost::mpl::if_c<boost::is_pod<boost::mpl::_1>::type::value,
boost::add_pointer<boost::mpl::_1>::type,
boost::mpl::_1,
> operate;
typedef boost::mpl::transform<vector, operate>::type result;
mpl::transform の Op に mpl::if_c は使えないの？
324:デフォルトの名無しさん
09/04/12 19:59:48
そもそも使い方がめちゃくちゃなんだが何がしたいんだ。
325:デフォルトの名無しさん
09/04/12 20:22:51
typedef boost::mpl::vector<int, char, std::string> vector;
typedef boost::mpl::if_<boost::is_pod<boost::mpl::_>, boost::add_pointer<boost::mpl::_> ,boost::mpl::_> operate;
typedef boost::mpl::transform<vector, operate>::type result;
を、if_cに書き換えたんだけど・・・
typedef boost::mpl::vector<int, char, std::string> vector;
typedef boost::mpl::if_c<boost::is_pod<boost::mpl::_>::type::value, boost::add_pointer<boost::mpl::_>::type, boost::mpl::_> operate;
typedef boost::mpl::transform<vector, operate>::type result;
typedef boost::mpl::transform・・・の行をコメントアウトすればコンパイルは通る。
めちゃくちゃってどこが？
326:デフォルトの名無しさん
09/04/12 20:53:39
using namespace boost::mpl::placeholders ;
typedef boost::mpl::if_< boost::is_pod< _1 >, boost::add_pointer< _1 >, _1 > operate ;
これで通るはず。
そもそもな、lambda expressionは、その時に評価してもしょうがないだろ。
add_pointer<_1>::type とした時点で、メタ関数は評価されているんだ。
transformの中で評価させたいんだから、早漏はコンパイラに嫌われるぞ。
>>325
そりゃ当たり前だ。transformに通さなきゃコンパイルは通るだろ。
こんどはunaryですらなくなってるぞ。
327:デフォルトの名無しさん
09/04/12 20:56:32
struct print_type
{
template < typename T >
void operator () (T) const
{
std::cout << typeid(T).name() << std::endl ;
}
} ;
int main()
{
using namespace boost::mpl::placeholders ;
typedef boost::mpl::vector< int, char, std::string > vector;
typedef boost::mpl::if_< boost::is_pod< _1 >, boost::add_pointer< _1 >, _1 > operate ;
typedef boost::mpl::transform< vector, operate >::type result ;
boost::mpl::for_each< result >( print_type() ) ;
}
動いてるみたいだな。
328:325
09/04/12 21:11:53
>>326
>typedef boost::mpl::if_< boost::is_pod< _1 >, boost::add_pointer< _1 >, _1 > operate ;
なら期待した動作することは確認済みです。
if_c でやりたい。
329:325
09/04/12 21:12:37
>>327
>>328
330:デフォルトの名無しさん
09/04/12 21:19:32
それは無理というものだ。
なぜなら、if_cは、メタ関数ではなく、boolを要求するんだから。
lambda expressionにしようがない。すぐに評価されては困るんだよ。
boost::is_pod< _1 >::type:value と、ネストされた型や定数を見た時点で、すでにinstantiateされる、つまり評価されているんだ。
331:デフォルトの名無しさん
09/04/15 15:21:46
javaの拡張scalaの上をいくものはできないものかなあ
332:デフォルトの名無しさん
09/04/15 16:57:44
>>331
Scalaのどの機能が欲しいの？おせーてプリーズ。
333:デフォルトの名無しさん
09/04/16 17:57:49
boost::unit_test_frameworkについて質問です。
今、std::wstring ToWide(std::string& rhs) という関数があり
この関数をテストするために
std::wstring ans = L"テスト";
std::string str = "テスト";
BOOST_CHECK_EQUAL( ToWide(str), ans );
というケースを書きましたが、コンパイルエラーになってしまいます。
BOOST_CHECK( ToWide(str) == ans );
とは書けましたのでwchar_tが出力されるときはこっちにすればいいのですが
wstringを出力できるようにするにはどうすればいいのでしょうか。
最近boostを使い始めたので変なこといってたらごめんなさい。
334:デフォルトの名無しさん
09/04/16 18:53:18
boost.lambdaから関数オブジェクト作ろうとすると
とんでもないタイプ量必要なのなんとかなんないの
335:デフォルトの名無しさん
09/04/16 18:54:32
C++03の限界です。あきらめてください。
336:デフォルトの名無しさん
09/04/17 22:17:38
更新しました。今週もドキュメントとビルドシステムの整備が多いです。
亦、boost_pythonのビルドをPython2.6.2ベースに移行しました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Graph]
Merged in changes from Nick to distributed betweenness centrality
Merged in code and docs from Parallel BGL; CMake-based build system for tests and examples and docs is not working; src and doc can be built with bjam
[Mpl]
mpl::string is a bidirectional sequence, not random access; c_str is a separate metafunction, not a class static
fix off-by-1 errors
add and document BOOST_MPL_LIMIT_STRING_SIZE and mpl/limits/string.hpp
saving some additional template instantiations
[Math]
Add more instrumentation code, along with some AMD64/Linux fixes.
[Exeption]
fixing an error that caused warnings in diagnostic_information.hpp
[Signals2]
signals2/signal.hpp does not need to include signals2/shared_connection_block.hpp.
Fixed compile errors in c++0x mode.
[Interprocess]
Modified examples so that they can be run in parallel.
[Unordered]
Add stream output to the count test helper for unordered.
[Filesystem]
Fix #2948 - Path typedef moved to namespace boost::filesystem
Fix incompatibility between asio and ncurses.h due to the latter defining
a macro called "timeout". Fixes #2156.
[Program_options]
Sync trunk&release branches
337:デフォルトの名無しさん
09/04/17 22:41:50
>>336
乙！
338:デフォルトの名無しさん
09/04/18 15:35:43
配列の要素数を変更する予定がなく、
しかしコンテナとしての扱いをしたい。
こんな場合にはboost::arrayがあるらしいですが、
これはstd::vectorよりも効率(速度やバイナリのサイズなど)
が良いのでしょうか？
std::vectorは標準ですからboost::arrayよりも
最適化の研究が(VC++やg++など有名どころで)なされているとか
そういったことは普通ないですよね？
339:デフォルトの名無しさん
09/04/18 15:41:09
以前実測したときはvectorよりは多少効率が良い程度だったよ。
当然ながらarrayでも生配列に比べるとかなり効率悪かった。
340:デフォルトの名無しさん
09/04/18 15:46:08
自分の環境で実測するしかないんじゃない
341:338
09/04/18 15:55:59
>>339
ありがとうございます。
ご教示に従い、コンパイル時に数が決まっている状況では
生配列にすることも考えてみます。
>>340
やっぱそうですよね。
そもそも本当にそれがボトルネックになっているのかから考えないといけませんしね。。。
342:デフォルトの名無しさん
09/04/18 17:03:54
>>339
最適化したのか？
vectorをreserveせずに増やしまくりとかじゃなければ、
配列だろうとarrayだろうと大した差はないと思うけど
343:デフォルトの名無しさん
09/04/18 19:25:06
>>342
たしかに大差ないんだが、indexでのアクセスはやっぱ生より遅い。
344:デフォルトの名無しさん
09/04/18 19:42:39
>>343
つまりは
実行スピードは
std::vector > boost::array >> 生の配列
か。
345:デフォルトの名無しさん
09/04/18 19:44:31
それ実行時間ｗ
346:デフォルトの名無しさん
09/04/18 19:54:37
>>345
アウチ！
間違ったｗ
347:デフォルトの名無しさん
09/04/18 21:29:19
vectorと、固定長配列の違いは、動的かそうでないかだけでは。
vectorだと多く確保できるけど、HDDに移される可能性がありそれが速度低下の原因では
348:デフォルトの名無しさん
09/04/18 21:37:16
環境依存の原因なんか挙げ始めればきりがない。
理論的には O(1) で同じと考えられる。
349:338
09/04/18 21:43:22
>>342-348
なるほど。
みなさま貴重なご意見ありがとうございます。
350:デフォルトの名無しさん
09/04/18 21:44:05
オーダーの話されてもなぁ。
ハッシュだって理屈の上ではO(1)だぜ？
351:デフォルトの名無しさん
09/04/18 21:51:09
>>350 で、何の話がしたいの？
352:デフォルトの名無しさん
09/04/19 01:58:00
>>347
固定長配列は、（自動変数なら）スタックポインタを減算するだけで確保できる。
それと比べれば、ヒープから空きメモリを探してくるvectorというかnew[]は確保に時間がかかる。
その点ではboost::arrayが組込の配列と比べて遅くなる要素は無いはずなんだけど。
（もちろん最適化がしっかりしていて、アサート全OFFという前提のもと）
353:デフォルトの名無しさん
09/04/19 03:27:48
> std::vector > boost::array >> 生の配列
なんか激しく疑わしいので比べてみた。@i386 gcc 4.1.2 -O2
for (size_t i = 0; i < size; ++i) cout << v[i] << endl;
生配列
.L21:
movl (%edi,%ebx,4), %eax
addl $1, %ebx
movl $_ZSt4cout, (%esp)
movl %eax, 4(%esp)
call _ZNSolsEi
movl %eax, (%esp)
call _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
cmpl %esi, %ebx
jne .L21
vector
.L15:
movl (%edi), %eax
movl (%eax,%ebx,4), %eax
addl $1, %ebx
movl $_ZSt4cout, (%esp)
movl %eax, 4(%esp)
call _ZNSolsEi
movl %eax, (%esp)
call _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
cmpl %esi, %ebx
jne .L15
まあ、確かに遅くはなると思うが・・・
354:デフォルトの名無しさん
09/04/19 12:48:08
movl 2回で済むところが3回になるのだから、そこだけみると結構遅いだろ？
355:デフォルトの名無しさん
09/04/19 13:06:42
movl (%edi), %eax
movl (%eax,%ebx,4), %eax
すごく無意味なことしてる気がするんだけど気のせい？
なんでこんなことしてるんだろ？
356:デフォルトの名無しさん
09/04/19 13:25:25
たまたま反復文の中が1行だったから比較的コストが高そうに見えるけど、
普通はそうじゃないよな。
うちのPCで国家予算分のジャリ銭を数え上げたら数分差が出るかもしれないけどさ。
(それでも分岐予測ミスによる揺らぎよりは小さそう・・・)
結局ありきたりの結論だけど
vectorが遅いかもしれないから生配列を使うことを検討するのに時間を使う方が
よっぽどコスト高だな。
int* vv = &v[0];
for (size_t i = 0; i < size; ++i) { cout << vv[i] << endl; }
とかすれば生配列と全く同じ速度になるわけだし。
357:デフォルトの名無しさん
09/04/19 13:33:27
確保される場所が違うだろ。
スタック上ではHDDにはうつりにくいけど
動的確保したらうつりやすい
358:デフォルトの名無しさん
09/04/19 13:52:46
>355
vector から先頭アドレスをロード。
要素の内容をロード。
だから無意味だとは思わないが、なんで？
毎回先頭アドレスをロードするのが無駄ってこと？
359:デフォルトの名無しさん
09/04/19 14:39:29
>>357
それは生配列かどうかとは違う問題では？
そもそも速度の変化を検知できるほど大きな配列をスタックに配置したら
数ページまるまる配列データだけになったりして、
そのページにアクセスする確率(≒スワップされない確率)は
ヒープ領域と変わらなくなってしまうんじゃないか？
ていうかメモリ増やせ。
360:デフォルトの名無しさん
09/04/19 17:51:13
うん、まぁほとんどの場合、生かvectorかで差がでることは
メモリの再配列以外では無いのは確かなんだ。
でも1.5倍以上の差がでる可能性があるのも間違いないからね。
どちらにするか悩むのは無駄だが、知識として抑えておくのは
悪いことではないでしょう。
361:デフォルトの名無しさん
09/04/19 18:39:44
>>358
生配列みたく
movl (%edi,%ebx,4), %eax
の1行でいいんじゃないの？ってことじゃないかと。
362:デフォルトの名無しさん
09/04/19 18:41:40
>>361
まぁそうだとしたら
>>355
は、レジスタの値とレジスタの値が指す先を混同してるってことか
363:338
09/04/19 22:55:36
ええと、皆様ありがとうございます。
アセンブラは全然理解出来ていないのですが、
頑張ってよく読ませていただきます。
364:デフォルトの名無しさん
09/04/20 00:21:29
>1.5倍以上の差がでる可能性があるのも間違いない
どこからそんな結論が
365:デフォルトの名無しさん
09/04/20 00:57:25
>>360
まず、お前がもっと深い知識を蓄えてから発言しろ
366:デフォルトの名無しさん
09/04/20 06:23:45
相手にも言えるレスで相手を馬鹿にしても、効果は薄いし説得力にも欠ける。
367:デフォルトの名無しさん
09/04/20 09:28:05
shared_ptrって参照数を保持する変数をnewしてるんだよね。てことは、
shared_ptr<int> pn(new int(0));
とか書くと、intはnewできてコンストラクタ内でnewが例外投げるとintのポインタが行方不明になる？
うん、なるな。
368:デフォルトの名無しさん
09/04/20 09:35:15
>>367
なんでドキュメントを読まずに「行方不明」とか意味のわからない結論で納得するの？
URLﾘﾝｸ(www.boost.org)
> Exception safety: If an exception is thrown, delete p is called.
369:367
09/04/20 09:46:13
うん、ヘッダ見たらすぐにわかった。恥ずかしい。
370:デフォルトの名無しさん
09/04/20 11:15:45
>>344
352も言ってるけど、何で生配列とboost::arrayで差が出るんだよ
353のループ部を gcc 4.3.3 -O2 で試したけど、まったく同じアセンブラコードになったぞ
371:デフォルトの名無しさん
09/04/20 11:38:09
お前の世界にはgccしかないのか？
372:デフォルトの名無しさん
09/04/20 11:50:44
お前はgccよりひどい最適化のコンパイラを使うのか？
373:デフォルトの名無しさん
09/04/20 11:51:38
multiarrayの方だけど
＞ boost::array<array_type::index,3> idx = {{0,0,0}};
＞ A(idx) = 3.14;
＞この方法は次元非依存のコードを書くのに役立ち，
＞いくつかのコンパイラの下では operator[] よりも高いパフォーマンスをもたらす。
とboost.cppll.jpに解説があるくらいなので、オーバーライドされた[]が最適化
されないケースは間違いなくあるんだろう。
374:デフォルトの名無しさん
09/04/20 11:57:18
だな
375:デフォルトの名無しさん
09/04/20 12:02:56
つまり、boost::arrayで速度が問題になるようならより最適化されやすいA(idx)を使えばいいってこと?
376:デフォルトの名無しさん
09/04/20 13:43:59
370の言ってることが間違いじゃなければgccなら最適化されるから
速度が問題になることはないだろう。
つまりgcc使えば良いんだよ。
ターゲット環境にgccが無いのなら、移植しろってことなんだろう。
377:デフォルトの名無しさん
09/04/20 21:04:20
>>375
multiarrayのoperator []が遅くなる要因は一時オブジェクトを作らないといけないからだと思う。
ところで、VC++ 9でも試してみたけど、やっぱりboost::arrayと生配列で出て来るコードは同じだった。
NDEBUGを定義して/O2で。
まあ普通のコンパイラならこれくらいGCCでなくても当然だと思う。
378:デフォルトの名無しさん
09/04/20 21:12:30
最適化に関するたいした知識のない俺から見れば
g++やVC++の最適化機能ってすんげーんだな
と思う。
だって俺、最適化機能のあるコンパイラを作れって
言われても絶対無理だと思う。
そんな「boost::arrayと生配列で出て来るコードは同じ」みたいな
ところまで気を回せるコンパイラの作者陣って
ホントに尊敬するわ。
379:デフォルトの名無しさん
09/04/20 21:26:02
boost::arrayのコードを見れば
ごく当たり前のことなんだけどな
380:デフォルトの名無しさん
09/04/20 21:51:47
inline展開様々だな
381:デフォルトの名無しさん
09/04/21 03:43:59
だな
382:デフォルトの名無しさん
09/04/21 22:39:48
boost::shared_ptr<MyClass> ptr;
これを関数に渡す場合、const参照渡しにした方が望ましいの？
それとも
STLのイテレータや組み込み型変数のようにconst参照渡しよりコピー渡しの方が望ましいの？
383:デフォルトの名無しさん
09/04/21 23:01:47
普通に値渡しの方がいいんじゃない？
どうせそこまで速度稼ぎたいわけじゃないだろうし、ポインタと同じように扱うためのスマートポインタだし。
384:デフォルトの名無しさん
09/04/21 23:25:38
値渡しじゃないと参照カウント増えないんじゃないか？
385:デフォルトの名無しさん
09/04/22 00:19:58
>>384
関数内で、別の変数に代入するなどすれば、そのとき増えるので無問題。
それとは別の話で、もしptrの参照先を見るだけだったら、
ただのMyClass&/MyClass const&にすればいいな。
386:デフォルトの名無しさん
09/04/22 00:42:04
const参照にしとけ。
使ってる場所が多いと、値だと結構クルよ。
387:デフォルトの名無しさん
09/04/22 01:19:29
呼び出し元次第。
const参照だと、実際に使うときに実体が存在しない危険がある。
388:デフォルトの名無しさん
09/04/22 06:13:57
>const参照だと、実際に使うときに実体が存在しない危険がある。
呼び出し元にはshared_ptrがあるのだから、関数実行中に実体が消えることはないと思うんだけど。
389:デフォルトの名無しさん
09/04/22 13:11:54
>>388
その理屈だとshared_ptr自体いらなくね？
390:デフォルトの名無しさん
09/04/22 16:12:07
オブジェクトの寿命を自分で管理したいのか、shared_ptrに管理させたいのかで決めれば良いと思う
391:デフォルトの名無しさん
09/04/22 20:51:14
>>389
なんで？そんな理屈にはならんよ。
392:デフォルトの名無しさん
09/04/22 20:53:38
>>391
auto_ptrで充分じゃね？
393:デフォルトの名無しさん
09/04/22 20:57:57
>>392
だからなんでそんなことになるの？
394:デフォルトの名無しさん
09/04/22 21:01:08
>>392
auto_ptrは使用禁止でもおかしくない。
395:デフォルトの名無しさん
09/04/22 21:12:12
#define auto_ptr unique_ptr
396:デフォルトの名無しさん
09/04/22 21:37:41
>>392
おいおい素人にも程があるだろ・・・
397:382
09/04/22 22:19:38
ふーむ、なるほどね。
そういったことを考えて決定するのが正しいのね。
ありがとう。
398:デフォルトの名無しさん
09/04/22 22:46:44
引数は何も考えずconst参照にしといて問題ない
399:デフォルトの名無しさん
09/04/22 23:10:09
組み込み型は値渡しがいいなあ
400:デフォルトの名無しさん
09/04/22 23:43:04
>>398
組み込み型とイテレータは値渡しが望ましいとEffective C++で書かれていた気がするんだが。
401:デフォルトの名無しさん
09/04/23 00:11:10
今はshared_ptrの話をしてるんじゃないのか
402:デフォルトの名無しさん
09/04/23 00:40:38
>388
それはshared_ptrのオーナー次第。関数自体はオーナーじゃ無いことに注意する必要がある。
下記はかなり恣意的な例だけど、マルチスレッドプログラムだとすぐ嵌りそうですな。
struct A {
A() : s(new std::string) {};
boost::shared_ptr<string> s;
}
void doom(std::auto_ptr<A> body, boost::shared_ptr<string>& str) {
*str; // boo!!
};
int main() {
std::auto_ptr<A> a(new A);
doom(a, a->s);
}
403:デフォルトの名無しさん
09/04/23 01:04:44
>>402
この例が一体何を示しているというのか。
boo!とか書いてるところで何か起きるわけでもなし。
404:デフォルトの名無しさん
09/04/23 01:26:28
>>402
それ問題ないです…
マルチスレッドについてはconst参照でなく値渡ししたとしても、
コピー操作がアトミックじゃない以上は嵌る可能性があるよ。
shared_ptrの実装自体がconst参照使ってるわけだし、基本はconst参照でいいと思う。
405:402
09/04/23 02:11:38
本当？>404
死んでるshared_ptrの参照剥しをしているんだけど？
まあ、マルチスレッドについてはアトミックなカウンタじゃないと死ぬっつうのは確かですな。
C++0xでマルチスレッド対応するらしいけど……
406:デフォルトの名無しさん
09/04/23 02:14:31
>>405
お前、実行してみろ。本当？じゃねーよ。
407:デフォルトの名無しさん
09/04/23 02:19:37
>>405
doom() を抜けるまでは最初の new A で生成したインスタンスは生きてるように見えるが？
408:402
09/04/23 02:53:07
あ、本当だ。ごめん。こうしないと死なないね。
まあ、マルチスレッドでもなきゃやらんだろうけど。
struct A {
A() : s(new std::string) {};
boost::shared_ptr<string> s;
}
void doom(std::auto_ptr<A> body, boost::shared_ptr<string>& str) {
{
std::auto_ptr<A> b(body);
}
*str; // boo!!
};
int main() {
std::auto_ptr<A> a(new A);
doom(a, a->s);
}
409:デフォルトの名無しさん
09/04/23 02:59:58
>>408
なんかもう shared_ptr も何も関係ないな。
410:デフォルトの名無しさん
09/04/23 03:06:30
>>408
>>402がまずいコードなのは確かだけど、*strの問題じゃないよ。
bodyが先に生成されればa->sの時点で死ぬ。
strが先に生成されれば問題なし。
そして引数の評価順は不定であり、評価順依存のコードの実行結果は未定義なので、
コード自体が間違っている。
411:デフォルトの名無しさん
09/04/23 03:23:24
>>410
a による body の初期化って、順番が不定な「引数の評価」に含まれるの？
5.2.2 Function call の p4 より
> When a function is called, each parameter shall be initialized with its corresponding argument.
同じく p8 より
> All side effects of argument expression evaluations take effect before the function is entered.
とか、読んでみたけどはっきりしない。
412:デフォルトの名無しさん
09/04/23 07:40:17
まあとにかく、shared_ptrは何も考えずconst参照にしといて問題ないよ。
413:デフォルトの名無しさん
09/04/23 12:36:08
>>411
5.2.2 p4のこれがそうなんじゃないかなあ。
>The initialization and destruction of each parameter occurs within the context of the calling function.
414:382
09/04/23 19:20:17
ふーむ。
試しに
void foo(const boost::shared_ptr<MyClass> &p)
{
p->m_func();
}
と
void foo(boost::shared_ptr<MyClass> p)
{
p->m_func();
}
とだけが異なった2種のソースをg++に渡して-O2でコンパイルさせてみたら、
後者の方が大きかったんだが。
とりあえずこのソースに限り、ファイルサイズはconst参照じゃない方が小さく済むみたい。
実行時間は・・・どうやって調べればいいの？
415:デフォルトの名無しさん
09/04/23 20:17:17
？
416:デフォルトの名無しさん
09/04/23 20:29:06
>>414
とりあえずcodepadかどこかにソースうｐしてもらえないとなんとも
417:414
09/04/23 20:41:45
さすがにエスパー要求しすぎなレスだったね。
すまなかった
C++ code - 38 lines - codepad
URLﾘﾝｸ(codepad.org)
コピーバージョン。
C++ code - 38 lines - codepad
URLﾘﾝｸ(codepad.org)
const参照バージョン
このソースをg++に渡してコンパイラオプション-O2で
コンパイルさせてみたら、後者の方が大きかった。
となると、後者の方が効率が悪いってことかなぁ
→でも効率を論ずるならやっぱり速度を測定しないとなぁ
→速度の実測ってどうすればいいのか分からない
ってことです。m(_ _)m
418:デフォルトの名無しさん
09/04/23 21:45:07
それくらい自分で調べろ、っていうか速度気にするレベルじゃなくない？
419:414
09/04/23 23:18:17
>>418
それもそうだな。
boostのtimerでも使うか。
420:デフォルトの名無しさん
09/04/23 23:28:56
const参照は不完全型が許されるのがいい。
421:デフォルトの名無しさん
09/04/24 10:10:05
デフォでconst参照でいいってぐらいconst T&ばっかりになるから困る
422:414
09/04/24 14:56:00
報告：
結局const参照verの方が遅かった。
サンプルソースでだけど。
423:デフォルトの名無しさん
09/04/24 15:30:22
const& で遅くなることなんてあるんだ
424:414
09/04/24 15:53:05
>>423
C++ code - 45 lines - codepad
URLﾘﾝｸ(codepad.org)
これの
void the_function(boost::shared_ptr<MyClass> p)
を
void the_function(const boost::shared_ptr<MyClass> &p)
にしてみたバージョンとで比較してみて。
俺はconst参照verの方が遅くなったよ。
425:デフォルトの名無しさん
09/04/24 16:27:09
$cat foo.cxx
#include <iostream>
#include <boost/progress.hpp>
#include <boost/shared_ptr.hpp>
class MyClass {
public:
virtual void f(){std::cerr << "MyClass f!" << std::endl;};
MyClass(){std::cerr << "MyClass Constructor!" << std::endl;};
virtual ~MyClass(){std::cerr << "MyClass Destructor!" << std::endl;}; };
void the_function(boost::shared_ptr<MyClass> p){ p->f(); }
void the_function_cr(boost::shared_ptr<MyClass> const& p){ p->f(); }
int main(){
const int M=0xffff, N=0xf;
#define FOO(f) { \
boost::progress_timer t; \
boost::shared_ptr<MyClass> po(new MyClass); \
for( unsigned long i=0; i<M; ++i ) \
for( unsigned long j=0; j<N; ++j ) \
(f)(po); \
}
FOO(the_function);
FOO(the_function_cr); }
$g++ foo.cxx
$./a.out 2>/dev/null
0.85 s
0.81 s
誤差じゃね？
426:414
09/04/24 16:37:53
>>425
おや、俺の環境と逆転した結果か？
うーん、どうなんだろう？
427:デフォルトの名無しさん
09/04/24 18:01:08
>>425
iostreamが重そうだと思ったから、
ダミーの関数呼出(GetCurrentProcess)にしてやってみた。
ただし、N = 0xfffに変更。共に-O2使用。
Cygwin g++ 3.4.4
5.87 s
1.79 s
VC++ 2008 SP1
7.70 s
1.12 s
やっぱり参照カウンタの操作が重いんだと思う。
ちなみに、BOOST_SP_DISABLE_THREADS（参照カウンタの操作にアトミックなやつを使わない）
を指定すると、値渡し版の所要時間が4割くらい減る。
428:デフォルトの名無しさん
09/04/24 18:25:28
値渡しのほうが遅くなるのなら納得
429:デフォルトの名無しさん
09/04/24 19:51:49
参照よりもコピーコンストラクタが走るほうが速いというのは
なんだかおかしな気がするわな
430:デフォルトの名無しさん
09/04/24 22:24:06
>>414と>>417で言ってることが逆なのはどういうことなんだ？
手元ではコピーコンストラクタのほうが実行コードが大きくなったぞ？
431:414
09/04/24 22:30:17
俺は二種類のサンプルソースで試したけど参照渡しの方が大きかった。
・・・もしかして参照渡しになっているところの数によって変化する要因があるとか？
あとは最適化か？？
432:デフォルトの名無しさん
09/04/24 22:34:34
>>431
一時オブジェクトが作られてないか？
433:414
09/04/24 22:42:48
>>432
ちゃんとconst参照渡しだから大丈夫なはずなんだが。。。
う～ん？
まあ速度は・・・誤差かもしれない。
相当回数トライして結果をt検定してみないと有意に早いとは証明できない程度。
でもサイズは誤差じゃなくcopy_verの方が小さいです。
434:デフォルトの名無しさん
09/04/24 22:45:23
>>431
つまり、>>414は間違いだったってことでいいの？
435:デフォルトの名無しさん
09/04/24 22:48:23
更新しました。ここ暫くはGraphの更新が多いです。それから、Cmakeでのビルド環境が整備されつつある様です。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Graph]
Applied performance patch from Jongsoo Park.
Importing null (no-op) property map from SOC/2007.
[Math]
Add some macro-expansion-suppression code to test_sign.cpp.
Fix for no long double math functions.
[Smart_ptr]
Bring back "explicit" on the auto_ptr rvalue constructor. Refs #2951.
436:414
09/04/24 22:49:09
>>434
いや、const参照渡し版よりcopy版の方がこちらの環境ではわずかながら早い。
ただそれが有意な差であると言い切れるかは検定してない。
あと、コンパイラのバージョンがg++ 3.4.5(MinGW)であることを追記し忘れたm(_ _)m
>とりあえずこのソースに限り、ファイルサイズはconst参照じゃない方が小さく済むみたい
これは確か。
437:デフォルトの名無しさん
09/04/24 22:49:25
[Asio]
Don't include termios.h unless BOOST_ASIO_HAS_SERIAL_PORT is defined.
[Property_map]
Approximated non-ASCII character by ASCII one
[Pending]
Fixed tab
[Signals2]
Fix c++0x perfect forwarding for deconstruct.
[Functional]
Fix float support on vxWorks.
[Connfig]
Added support for vxworks.hpp.
Fixes #2959.
[Fsion]
Trying to fix ambiguities of operator<<() for unused_type.
[Regex]
Added possessive modifiers ++ *+ ?+ {}+.
Added support for \v and \h as character classes as per Perl-5.10.
[Serialization]
Add missing 'inline'. Don't include <exception> when excepetions are disabled.
438:デフォルトの名無しさん
09/04/24 22:53:49
>>436
いや、だからさあ、
>>414と>>417であなたが言ってることは逆でしょう？
どこかでファイルを取り違えていたりしない？
439:414
09/04/24 22:57:07
>>438
ごめん
既に>>414の段階でおかしかった。
吊ってくる。
>つまり、>>414は間違いだったってことでいいの？
おっしゃるとおり逆だ。
>とりあえずこのソースに限り、ファイルサイズはconst参照じゃない方が小さく済むみたい
これは正しい。
そして>>435様に挟む形でレスして申し訳ございません。
440:デフォルトの名無しさん
09/04/24 22:59:44
>>414
gccのバージョンと環境を教えて。
441:414
09/04/24 23:01:51
>>440
Windows XP Home Edition SP2
C:\>g++ --version
g++ (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
BoostはRelease 1.37.0
442:デフォルトの名無しさん
09/04/24 23:05:51
またずいぶんと古いバージョン使ってるなぁ。
うちの会社は未だに2.9系使ってるけど。
443:デフォルトの名無しさん
09/04/24 23:07:49
>>442
MinGWが未だ3.4.5しか対応してくれていないんだ。
正式版じゃなければ4.x.x系列のもあるらしいんだが。。。
444:デフォルトの名無しさん
09/04/24 23:20:21
まあまあ、Cygwinだって基本は3.4.4ですよ。別途g++-4とかが入れられるけど。
445:443
09/04/24 23:27:12
>>444
ああ、やっぱそうなのか。
じゃあ不満持ってもしかたないか。
446:デフォルトの名無しさん
09/04/24 23:55:50
MinGWでいつもGCC4.xを自分でビルドして使ってる
447:デフォルトの名無しさん
09/04/25 13:59:35
mingwはlibiconvをインクルードしなくなったのと
3.4.5でwstringが未対応なので、野良の4.3.3使ってる。
まあ普通に動くよ。Dwarf2でVC近い速度が出るし。
448:デフォルトの名無しさん
09/04/26 03:00:54
Windows 7 64bit でboost群使える？
色々テストしてみたいんだけど
449:デフォルトの名無しさん
09/04/26 03:36:54
コンパイラさえ動けば問題ないだろ。
450:デフォルトの名無しさん
09/04/27 16:43:09
今までhoge.cppファイルの中でboost::bindを使っていたのだけれど、
今度そのhoge.cppにboost::lambdaも使うことにしようと思っている。
なお、このhoge.cpp以外でboost::bindおよびboost::lambdaは使用していない。
このような時は
1.boost::lambdaをただ追加する
（＝<boost/bind.hpp>と<boost/lambda/lambda.hpp>をインクルードする。）
2.boost::bindを使っている箇所も全てboost::lambdaに置き換える
（＝<boost/lambda/lambda.hpp>だけインクルードする。）
このどちらが良いのかい？
451:デフォルトの名無しさん
09/04/27 16:59:24
boost::bindはグローバルに_1とか置く割と行儀が悪いライブラリだったりするんで俺なら2を選ぶ
452:450
09/04/27 17:05:52
>>451
> boost::bindはグローバルに_1とか置く割と行儀が悪いライブラリだったりするんで俺なら2を選ぶ
そうだったんか。
そういえばboost:lambdaの_1とかとバッティングすることがあると聞いた気がするなぁ。
まあbindは古株だからかな？
453:デフォルトの名無しさん
09/04/27 17:46:19
bindのところをlambdaにしたらそれだけでファイルサイズが60kbくらいあがったわ。
・・・でもPC向けだしこのくらいいいかな、利便性を考えれば。
454:デフォルトの名無しさん
09/04/27 23:09:28
初心者ですがお願いします.以下のようなエラーが出て困っています。
boostのbind.hでerror C2825: 'F': '::' が後に続くときは、クラスまたは名前空間でなければなりません
c:\includefiles\boost\bind.hppと出ます。
いかがその部分です
template<class F> struct result_traits<unspecified, F>
{
typedef typename F::result_type type;
};
色々サイトで調べてみたのですが、#include <boost/bind.h>の前に
#define BOOST_BIND_ENABLE_STDCALL
#define BOOST_MEM_FN_ENABLE_STDCALLを書くと良いと記載されていたのですが、
エラーが取れません。原因がわかりませんでしょうか？
455:デフォルトの名無しさん
09/04/27 23:27:35
>>454
result_traitsの後に<は書けなくね？
456:デフォルトの名無しさん
09/04/27 23:50:15
>>455さん
ご返事ありがとうございます。
エラーの箇所を確認したのですが、bind.hの中からエラーを出力しているようです。
boostの中のバグということでしょうか？
457:デフォルトの名無しさん
09/04/28 00:10:18
>>456
エラーの発生する自分で書いた側のコードをupして。
458:デフォルトの名無しさん
09/04/28 00:38:20
>>457さん
確認したのですが bind.hppのエラーしか出力されていないようです。
ちなみにエラー箇所はbind.hppの68行目で
template<class F> struct result_traits<unspecified, F>
{
typedef typename F::result_type type;
};
から出力されておりエラー内容は
error C2825: 'F': '::' が後に続くときは、クラスまたは名前空間でなければなりません c:\includefiles\boost\bind.hpp
error C2039: 'result_type' : '`global namespace'' のメンバではありません。c:\includefiles\boost\bind.hpp
error C2146: 構文エラー : ';' が、識別子 'type' の前に必要です。c:\includefiles\boost\bind.hpp
error C2208: 'boost::_bi::type' : メンバのない列挙型、構造体、共用体が定義されました。c:\includefiles\boost\bind.hpp
error C1903: 直前のエラーを修復できません。コンパイルを中止します。c:\includefiles\boost\bind.hpp
error C2039: 'result_type' : '`global namespace'' のメンバではありません。c:\includefiles\boost\bind.hpp
error C2208: 'boost::_bi::type' : メンバのない列挙型、構造体、共用体が定義されました。c:\includefiles\boost\bind.hpp
と記述されています。お手数ですがアドバイスお願いいたします。
459:デフォルトの名無しさん
09/04/28 00:57:36
>>458
boost::bind()を呼ぶところの第3引数が間違っている可能性が高い。
だから>>457
460:デフォルトの名無しさん
09/04/28 00:59:54
>>459
第3は余計だった。なんでこんなこと書いたんだ
とにかく引数の指定を間違えてる
461:デフォルトの名無しさん
09/04/28 01:38:35
>>458
最近のVisual C++なら、
「foo.cpp(7) : コンパイルされたクラスの テンプレート のインスタンス化 'HogeHoge' の参照を確認してください」
ってのがエラーメッセージの随所に挟まっている。
（IDEからビルドしているなら、エラー一覧ではなく出力ウィンドウのほうに）
このメッセージだけを見ていくと、その中に必ず自分のソースコードを指しているものがあるはず。
462:デフォルトの名無しさん
09/04/28 02:01:59
>>459,460,461
返事が遅くなってしまい申し訳ございませんでした。
ご親切なご回答ありがとうございます。
自分のソースを確認した所、
1>c:\includefiles\boost\bind.hpp(67) : error C2825: 'F': '::' が後に続くときは、クラスまたは名前空間でなければなりません
1> c:\includefiles\boost\bind\bind_template.hpp(15) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::_bi::result_traits<R,F>' の参照を確認してください
1> with
1> [
1> R=boost::_bi::unspecified,
1> F=void (__thiscall Servent::* )(const boost::system::error_code &,size_t) throw()
1> ]
1> c:\work_data\gg\src\network\servent.cpp(54) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::_bi::bind_t<R,F,L>' の参照を確認してください
1> with
1> [
1> R=boost::_bi::unspecified,
1> F=void (__thiscall Servent::* )(const boost::system::error_code &,size_t) throw(),
1> L=boost::_bi::list3<boost::_bi::value<Servent *>,boost::arg<1>,boost::arg<2>>
1> ]
463:デフォルトの名無しさん
09/04/28 02:13:39
すみません、誤って書き込んでしまいました。上記のエラーメッセージが出力されています。
ソースとしては、
typedef typename result_traits<R, F>::type result_type;
boost::bind(&Servent::read, this,boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred));
あと質問なのですが、boostのバージョンによる不具合の可能性はあるのでしょうか？
現在boostの1.35を使用して実行しております。
度々ご質問して申し訳ございません。
464:デフォルトの名無しさん
09/04/28 06:06:36
>>454
> 初心者ですが
これいらない
465:デフォルトの名無しさん
09/04/28 14:21:59
ついにboostもcmakeか
466:デフォルトの名無しさん
09/04/28 14:50:26
>>463
コンパイルしてそのエラーの出る最低限のソースが必要。
467:デフォルトの名無しさん
09/04/29 01:27:44
VC++のバージョンは？
7.0以下だと該当コードは利用できず、別のコードに置換されるみたいだけど。
468:デフォルトの名無しさん
09/04/30 11:13:14
enable_ifの引数にboost::mplもつかえるんだね。boostってスゲエと思った。
469:デフォルトの名無しさん
09/04/30 19:11:05
>>468
ホントすげぇよBoost。
C++が大好きなんだろうなぁと思わせられるよね(笑)
Boost.Lambda(functionも。)やBoost.Spirit、Boost.MPLあたりが変態級の名を冠するにふさわしいか。
利便性で言えばshared_ptrもヤヴァイけど。
470:デフォルトの名無しさん
09/04/30 22:49:38
preprocessorを忘れるとはけしからんな。
471:デフォルトの名無しさん
09/04/30 23:11:00
C++ code - 32 lines - codepad
URLﾘﾝｸ(codepad.org)
このコードにて、エラーになる原因が分かりません。
私の考えでは
boost::lambda::bind(func_i, boost::lambda::protect(boost::lambda::bind(my_name, boost::lambda::_1)))
でconst char* constを受け取りintを返す関数が得られるので、
それをlambda_test_funcの引数として渡せるのではないかと思ったのですが。
どこを修正すればよろしいでしょうか？
472:デフォルトの名無しさん
09/04/30 23:17:13
>>471
lambda で生成される関数は、関数オブジェクトの一種。
関数へのポインタは C++ 言語上の「関数」を指すことができるけど、
言語上はクラスオブジェクトとなる関数オブジェクトを指すことはできない。
関数と関数オブジェクトを同等に扱うためのものとして boost::function がある。
- void lambda_test_func(int (*func_ptr)(const char* const char_ptr))
+ void lambda_test_func(boost::function<int (const char*)> f)
473:472
09/04/30 23:38:58
>>471
あと、関数合成に boost::lambda::protect 要らない。
URLﾘﾝｸ(www.boost.org)
474:デフォルトの名無しさん
09/05/01 02:59:05
UBLas使ってる人に聞きたいんだけど、固有値分解とかはどうやってるの？
検索するとCLapack使ってるのしかでないけど、みんな自前で書いてるの？
475:471
09/05/01 05:58:59
>>472
ありがとうございます。
学べました！
476:デフォルトの名無しさん
09/05/01 19:03:13
更新しました。今週はSpiritに大きな変化がありました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Mpl]
portability patch for sunpro on little-endian platforms
[Regex]
Added support for \g \K and \R.
[Spirit]
Merging Spirit V2.1
Spirit: Added missing files, deleted old files, cleaned up empty directories
Spirit: Started to add repository of reusable Spirit components, added
repository::karma::confix and some related tests
Spirit: Fixed assertion in multi_pass iterator
[Statechart]
Updated VC project files to 1.39.
Fixed a bug that prevented the use of boost::ref()
with fifo_scheduler<>::create_processor<>, reported by Steve Hawkes.
This should fix the non-standard code used in changeset 52616.
[Signals2]
Trying to fix compile problems on msvc 9 in release mode.
[Serialization]
Correct logic for enabling THROW_EXCEPTION
Add support for std::bitset.hpp
477:デフォルトの名無しさん
09/05/01 19:10:05
>>476
ほほうspiritがV2になったのか
478:デフォルトの名無しさん
09/05/02 01:00:05
>96 の問題は直ったんだろうか
479:デフォルトの名無しさん
09/05/02 22:45:06
>>476
Signals2って何かな？と思って調べたらスレッドセーフのSignalらしい。これは欲しい。
480:デフォルトの名無しさん
09/05/03 12:01:48
1.39きたぁぁぁ
481:デフォルトの名無しさん
09/05/03 13:32:00
>>480
Boostって結構こまめに更新した方が良いの？
俺のBoostは1.37なんだけど。。。
482:デフォルトの名無しさん
09/05/03 13:50:15
>>481
最近一定期間ごとにリリースする方針に変えたらしいね。
更新内容を見て、興味のない更新ばかりだったら放置しても可だと思うけど。
特に最近は後方互換性を平気で破壊するような更新が多いから悩む。
exceptionとかexceptionとかexceptionとか。
483:481
09/05/03 13:57:14
>>482
ありがとう。exceptionって使ったこと無いなぁ。便利？
その仕様変更はBoostだから出来ることか。
まあC++に正式に乗っちゃったら迂闊に仕様変更できないから
今のうちに満足行くまで更新して欲しい。
484:481
09/05/03 14:01:33
>>482
ホントだ、1.36以降、3ヶ月刻みになっているね。
Version 1.39.0
May 2nd, 2009 12:00 GMT
Version 1.38.0
February 8th, 2009 12:00 GMT
Version 1.37.0
November 3rd, 2008 12:00 GMT
Version 1.36.0
August 14th, 2008 12:00 GMT
Version 1.35.0
March 29th, 2008 12:00 GMT
485:471
09/05/03 14:36:17
>>472-473
ご教示の通り
boost::lambda::protectを外した上で boost::function を利用したところ、
問題無くコンパイル通りました。
ありがとうございました。
486:デフォルトの名無しさん
09/05/03 17:29:29
>>481
必要に応じてあげていけばいいと思うよ。
でもバージョン上げたら、コンパイルできなくなったりすることがあるから一気にバージョン上げるとつらいかも。
487:471
09/05/03 17:55:45
普通の部分では以前ご教示いただけた通りで動きました。
今度はBoost.Spiritのセマンティックアクションにラムダ式を入れる時にまた困っております。
//以下はMyClass.hの中身
class MyClass
{
MyClass();
virtual ~MyClass()=0;
public:
static const int get_10(const char * const);
};
//以下はMyClass.cppの中身
#include "MyClass.h"
const int MyClass::get_10(const char * const)
{return 10;}
//mainは以下です。
C++ code - 112 lines - codepad
URLﾘﾝｸ(codepad.org)
このソース中の質問箇所というコメントのところ
('/' >> fctr)[
boost::lambda::bind(func_geti_reti,
boost::lambda::bind(MyClass::get_10, boost::lambda::_1)
)
]
が問題点なのですが、
488:471
09/05/03 17:58:47
前述のように
①Boost.Spiritのセマンティックアクションに
②ラムダのbindで関数を結合し
③MyClass::get_10の部分ががクラスのstaticメンバ関数である
この①～③の時に
x_error.cpp:82: error: invalid initialization of non-const reference of type 'co
nst int (&)(const char*)' from a temporary of type 'const int ()(const char*)'
C:/BoostC++Libraries/boost/lambda/detail/bind_functions.hpp:256: error: in passi
ng argument 1 of `const boost::lambda::lambda_functor<boost::lambda::lambda_func
tor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambd
a::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<typ
ename boost::lambda::detail::constify_non_funcs<T>::type, const Arg2, boost::tup
les::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuple
s::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples:
:null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&,
const Arg2&) [with Arg1 = const int ()(const char*), Arg2 = boost::lambda::place
holder1_type]'
というエラーが出てしまいます。
環境はg++です。
489:471
09/05/03 18:03:35
先のソースは
× MyClass::get_10(const char * const)
○ MyClass::get_10(const char * const, const char * const)
× boost::lambda::bind(MyClass::get_10, boost::lambda::_1)
○ boost::lambda::bind(MyClass::get_10, boost::lambda::_1, boost::lambda::_2)
とすべきでした。失礼致しました。
それでもなお
x_error.cpp:81: error: invalid initialization of non-const reference of type 'co
nst int (&)(const char*, const char*)' from a temporary of type 'const int ()(co
nst char*, const char*)'
というエラーが出てしまいます。
非constな参照でテンポラリな何物かを捉えているという旨のようですが、
どうすれば回避できるのか分かりません。
どうかお知恵をお貸しください。
490:471
09/05/03 18:31:34
boost::lambda::bind
をboost::bindに書き換えたら問題無く動作しました。
個人的にはboost::bindライブラリとboost::lambdaライブラリを混在させるのは気持ち悪いので
出来ればboost::bindの箇所は無くして全てboost::lambda::bindにしたいのですが、
どうすれば良いでしょうか？
491:デフォルトの名無しさん
09/05/03 20:36:47
3行でまとめてくれ
492:471
09/05/03 21:01:43
>>491
SpiritのSemantic Actionにlambda::bindで関数を結合して渡すとエラーになりますが、boost::bindならOKです。lambda::bindでも大丈夫にする方法を教えていただけないでしょうか？
493:デフォルトの名無しさん
09/05/03 21:17:04
恐縮ですwww
func_geti_retiの引数の&が余分じゃないか？
494:471
09/05/03 21:36:52
>>493
int func_geti_reti(const int& num)
を
int func_geti_reti(const int num)
や
int func_geti_reti(int num)
にしてみましたが、
error: invalid initialization of non-const reference of type 'const int (&)(const char*)' from a temporary of type 'const int ()(const char*)'
と言われます。
私の見解では
関数の戻り値などのテンポラリオブジェクト(この場合はint)を
constな参照で束縛できるというC++の仕様がありますから、
このあたりが問題な訳ではなさそうだと思っております。
495:デフォルトの名無しさん
09/05/04 20:23:45
letsboost::operators
URLﾘﾝｸ(www.kmonos.net)
ここで紹介されているoperatorsって、いちいち定義が面倒なのを自動化してくれるらしいから
便利そうだと思っているんだが、使うと遅くなったりするのかい？
496:デフォルトの名無しさん
09/05/04 23:18:04
しない。
ただし、クラス/構造体のサイズを余計に増やしたくなければ、ちょっとだけ特殊な記法が必要。
497:デフォルトの名無しさん
09/05/04 23:52:23
>>496
ほう、そうなんか。そのちょっとだけ特殊な記法とはEBOに関連する？
498:デフォルトの名無しさん
09/05/05 00:17:24
URLﾘﾝｸ(en.wikipedia.org)
499:デフォルトの名無しさん
09/05/05 00:21:31
>>498
EBOはEmpty Base Optimizationのつもりで書いた。
みんなに通じる略称かと思っていたが甘かったかな。
500:デフォルトの名無しさん
09/05/05 00:33:29
意味は判るがその略称は初めて見たぞ。
ちなみにその直感は超正しい。 俺はDirect3Dを使ったソフトでベクトル型をboost::operatorから継承したせいで
半日謎のバグと戦う羽目になった。
501:デフォルトの名無しさん
09/05/05 01:05:17
OpenGLで同様な目にあった俺参上。
502:デフォルトの名無しさん
09/05/05 08:58:41
ふーん、なんかややこしいような気がしてきてしまった。
何はともあれ皆さんありがとう。
503:デフォルトの名無しさん
09/05/05 11:29:54
Effective C++の最新日本語訳本を読んだところ、
p202にEBOがEmpty Base Optimizationの略称で使われているのを発見した。
原著ではどうなっているのかな？
504:デフォルトの名無しさん
09/05/05 12:29:05
EBO とか ADL, CRTP, SFINAE, RAII あたりは普通に使ってる
505:デフォルトの名無しさん
09/05/05 12:42:43
あとはRVO、NRVOかな
506:デフォルトの名無しさん
09/05/05 12:47:20
RAIIぐらいはいいが、
あんまりにも乱発するのは感心しないぞ。
507:デフォルトの名無しさん
09/05/05 13:11:24
TSKに、RNPTはKNSNしないな
508:デフォルトの名無しさん
09/05/05 13:14:46
>>506
ADLやSFINAEはバグの原因になるから
勝手に使えるようになる。
CRTPやEBOはどうなんだろ。
趣味でやってると手を出したくなるけど。
509:デフォルトの名無しさん
09/05/05 13:41:36
>508
いや、略語乱発は感心しないという話では？
510:デフォルトの名無しさん
09/05/05 14:48:23
だれがどう感心しないんだｗ
つうかそこいらの女子高生の略語に比べればカワイイもんだ
511:デフォルトの名無しさん
09/05/05 18:38:34
1.39落としたけど、
./booststrap.sh してできた project-config.jam の
option.set libdir の行が PREFIX/lib じゃなくて /lib になるのは
何かやんごとなき事情でもあるの？
512:デフォルトの名無しさん
09/05/07 11:06:59
1.39.0、またビルドの方法変わった？
1.38.0の時にやってた、
bjam --toolset=msvc-8.0 -sBZIP2_SOURCE=～ -sZLIB_SOURCE=～ --stagedir=. stage release debug link=static,shared runtime-link=static,shared
でビルドしようとすると何か途中で止まるんだが…
513:デフォルトの名無しさん
09/05/07 11:22:31
VC8なら、runtime-link=staticは使わないだろ。外した方が良い。
あとシングルスレッドライブラリも使わないから、threading=multiも指定した方が良いな。
514:デフォルトの名無しさん
09/05/07 11:26:39
>>513
㌧
おかげでビルド進みました。
515:デフォルトの名無しさん
09/05/07 11:36:46
まあ、それとビルドが進まないのとは別問題なんだけどな。
なんかmathがビルドできないな。
しかも、なぜか自分でファイルを消しておいて、そのファイルが見つからないからskipとかいうヘンなメッセージが。
もう一度試したらうまくいっているようだが。
516:デフォルトの名無しさん
09/05/07 12:30:11
>>515
link=staticとruntime-link=staticがどうたらこうたらっていうエラーメッセージが出て止まってた。
やっぱりバッチファイル直接実行じゃなくてコマンドプロンプトから実行しないとダメだな…
517:デフォルトの名無しさん
09/05/07 20:35:09
1.39でてたのか
チェックしてくる
518:デフォルトの名無しさん
09/05/07 21:19:56
>>517
1.37->1.39にした俺はspiritの名前空間が変わってて驚いた。
519:デフォルトの名無しさん
09/05/07 22:52:30
1.39のリリースノートによるとメモリリーク対策で導入すべきなのだが
再ビルドに時間がかかり面倒なので見なかったことにした
520:デフォルトの名無しさん
09/05/07 23:31:10
マルチコアなCPUを使うのは、今時のBoost使いなら当たり前。
521:デフォルトの名無しさん
09/05/07 23:40:39
ビルドが必要なライブラリって、なんかどうしても使う気になれないんだよねぇ。。。
みんな積極的に使ってる？
522:デフォルトの名無しさん
09/05/07 23:46:32
>>521
必要なら使う、当たり前のこと。
523:デフォルトの名無しさん
09/05/08 01:13:49
使うにしてもregexとfilesystemとserializationくらいだなぁ
524:デフォルトの名無しさん
09/05/08 01:59:58
program_opt……いや、なんでもないんだ
525:デフォルトの名無しさん
09/05/08 07:46:02
>>524
もうちょっとシンプルなら使うのに…
526:デフォルトの名無しさん
09/05/08 09:16:23
あれはシンプルとかそれ以前に問題が多すぎる。
boost初期からあるってだけで、今新規に投稿しようとしたら満場一致で拒否られるレベル。
527:デフォルトの名無しさん
09/05/08 09:29:49
program_optionを普通に使ってて便利だと思ってる俺がおかしいのか。
528:デフォルトの名無しさん
09/05/08 11:37:47
あれunicodeのサポートが最悪だよ。
529:デフォルトの名無しさん
09/05/08 21:48:14
>>518
1.38でビルド時に警告が出てた。
530:518
09/05/08 22:40:53
>>529
結局ソースを見てたどっていって正しい名前空間を見つけたから大丈夫だったがね。
531:デフォルトの名無しさん
09/05/09 09:36:58
上のほうの書き込み見て思ったが、1.39.0ではVS2005のランタイムライブラリに
マルチスレッドデバッグ（/MTdオプション）やマルチスレッド（/MTオプション）を
指定している場合用のライブラリのビルドできなくなってるのかな？
532:デフォルトの名無しさん
09/05/09 09:55:48
そもそもMS自身が、もはやスタティックリンク版のCRTライブラリの使用を推奨してない。
533:デフォルトの名無しさん
09/05/09 11:30:32
URLﾘﾝｸ(booster.x0.to)
確かにビルドの挙動が変わっていますね・・・。
少なくとも3週間以上、sharedライブラリがビルドされていない事に気付かないままアップロードしていましたので全て取り下げました。
申し訳ございません。
ところでお詫び代わりという訳でもありませんが、Windows+VC環境では導入が面倒なライブラリ群(bzip2,Expat,ICU,zlib 32/64bit)の
ビルド済みパッケージを用意しました。(libs_for_build_boost.rar)
残りのMPICH2とPythonのインストーラを公式からダウンロードしてインストールすれば、32/64bitBoostのフルビルドが簡単に行える様になります。
それから、build.txtを改訂序にhow_to_build.txtに名称変更しました。
そういえば今週のsvnスナップショットは今夜辺りにでもビルドしてアップロードする予定ですが、64bit版svnスナップショットの需要はありますでしょうか。
32bit版と同梱にすると圧縮しても250MB程度まで膨れ上がる可能性がありますし、
ファイルを分けるにしてもサイト容量と作業時間を食いますので需要が無ければ今迄通り32bit版のみにします。
若しくは、1.39等のリリース版ソースを使った64bitビルドが欲しいといったリクエストでも構いません。こちらも一時の手間で済みますので楽です。
>>531
staticもsharedも、特に今迄と変わり無くビルド可能です。
534:デフォルトの名無しさん
09/05/09 11:38:33
Signals と Signals2 との違いって、マルチスレッド対応だけ？
シングルスレッドなプログラムなら、かえって Signals のままのほうが
排他制御なくて性能いいとかあるんかな。
535:デフォルトの名無しさん
09/05/09 12:38:51
>>534
ライブラリビルド不要とも書いてあったな。
536:デフォルトの名無しさん
09/05/09 15:34:23
>>534
dummy_mutexなんてもんもあるでな。
537:デフォルトの名無しさん
09/05/10 00:46:30
↓ 更新しました。link=shared runtime-link=sharedでmpiとzlib絡みのエラーが発生して
計12ファイルが欠損しておりますが追々改善していきます。毎度人柱仕様で申し訳ございません。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Spirit]
Spirit.Support: Renamed policy namespace for iterators
Spirit: fixed member initialization sequence
Spirit: added some parenthesis' avoiding macro expansion of certain names
[Archive]
fix for error in handling compilers which don't handle has_new_operator
[Config]
Add __GXX_EXPERIMENTAL_CXX0X__
[Units]
Allow specifing the default conversion using either base units or units.
[wave]
Update Wave to cope with some namespace reshuffling in Spirit
Wave: Pending fix after namespace change in Spirit2 iterators
[Type_traits]
new test of empty aligned_storage
[mpi]
Fixes for bugs 2586 and 2594
↓
[Regex]
Add support for named sub-expressions.
[Utility]
eliminate noisy warning on msvc, fixes #2993
それと>>531の件ですが、確かにmt-s,mt-sgdがビルド出来なくなっていました。
ただ、bjamのオプションを弄ったりすると一部ビルドが出来たり
ビルドログを取ってみるとエラーメッセージがおかしかったりとbjamの挙動が良く分かりませんのでこちらも検証していきます。
538:デフォルトの名無しさん
09/05/10 01:32:26
まだ軽くしか調べていませんが、どうもbjamか設定ファイルがバグっているみたいですね。
--build-type=completeやlink=static runtime-link=staticとすると何故か
error: link=shared together with runtime-link=static is not allowed
error: such property combination is either impossible
error: or too dangerious to be of any use
と表示されますが、--build-type=complete --with-mpiやlink=static runtime-link=static --with-mpi(--with-pythonでも可)とすると
ビルドが通ります(但しmpiやpython関連ライブラリのみですが)。
539:デフォルトの名無しさん
09/05/10 07:39:46
そのエラーは正しいとしか思えない。
というのも、例えばVCの場合、CRTのライブラリには、いくつものバージョンがある。
それこそ、SPごとにバージョンが変わる。
CRTをスタティックリンクするが、Boostをダイナミックリンクするということは、
CRTのバージョンが異なる可能性があり、危険だと思う。
そしてそもそもCRTのスタティックリンク自体が、VCでは推奨されていない。
確か、Boostの連中の検証した所によると、スタティックリンクのCRTを使うと、
スレッド周りで、たとえ正しいコードを書いたとしても、メモリリークする場合があるらしいとかいうMLを、
どっかで見た気がする。
540:デフォルトの名無しさん
09/05/10 13:14:22
私もエラーメッセージの意味するところ自体は正しいと思いますし、link=shared runtime-link=staticは
1.38以前からビルドは不可能でした。ただ、1.39のbjamビルドでは
link=shared runtime-link=staticではなく
link=static runtime-link=staticや--build-type=completeでも
error: link=shared together with runtime-link=static is not allowed
と表示されてしまい、
link=static runtime-link=static --with-python(or mpi)としたり
--build-type=complete --with-python(or mpi)とすると
ビルドが通ってしまう点がよく分かりません。
1.38と1.39のdebugビルド時のbjamの動作の違いは
Boost 1.38
static static: libboost_...-vc90-mt-sgd-1_38.lib
static shared: libboost_...-vc90-mt-gd-1_38.lib
shared static: error: link=shared together with runtime-link=static is not allowed
shared shared: boost_...-vc90-mt-gd-1_38.lib + boost_...-vc90-mt-gd-1_38.dll
（続く）
541:デフォルトの名無しさん
09/05/10 13:15:30
（続き）
Boost 1.39
static static: error: link=shared together with runtime-link=static is not allowed
(--with-python(or mpi)時のみlibboost_...-vc90-mt-sgd-1_39.lib)
static shared: libboost_...-vc90-mt-gd-1_39.lib
shared static: error: link=shared together with runtime-link=static is not allowed
shared shared: boost_...-vc90-mt-gd-1_39.lib + boost_...-vc90-mt-gd-1_39.dll
です。そのCRTスタティックリンク非推奨の件でstatic staticが封印されたのかとも思いましたが、
CMakeでVC用のプロジェクトファイルを作成してビルドするとmt-s(release static static)やmt-sgd(debug static static)が作成されましたので、
--build-type=completeがエラー扱いになってしまう事と併せるとbjam(の設定ファイル)の不具合ではないかと考えています。
上記とはあまり関係ありませんが、libs_for_build_boost.rarをアップデートしました。URLﾘﾝｸ(booster.x0.to)
zlibに似た何かをzlibと勘違いしてビルドしてしまっておりましたので正しい物に差し替えました。申し訳ございません。
これで、ビルド不可能なBoostライブラリはboost_graph_parallelのlibとdllのみ(mpi絡みのエラー)となります。
boost_graph_parallelはログを見ると32bit版がリンクエラーなのに対して
64bit版ではコンパイルエラーで引っ掛かっているのでソースが怪しい気がしなくもないですが・・・。
只、readmeやhow_to_build.txt内のbjamビルドコマンドについては上記の件もあり私自身混乱気味ですので、参考程度にして下さい。