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ビルドコマンドについては上記の件もあり私自身混乱気味ですので、参考程度にして下さい。
542:デフォルトの名無しさん
09/05/10 15:31:21
regex
date_time
program_option
serialization
thread
filesystem
(system)
要ビルドのライブラリで使うのはこれぐらいかなぁー
543:デフォルトの名無しさん
09/05/10 16:53:36
>>542
十分つかってるな。
544:デフォルトの名無しさん
09/05/10 17:14:49
むしろ使ってないのを挙げた方が早いなｗ
545:デフォルトの名無しさん
09/05/10 18:07:22
static-staticビルド不可の原因が半分掴めました。対症療法的なビルドは可能になりました。
svn rev.52330(April 11,2009)での\Jamrootの更新で、160行目周辺の
if <link>shared in $(properties) && <runtime-link>static in $(properties) &&
! ( <toolset>cw in $(properties) )
{
return <build>no ;
}
が
if <link>shared in $(properties) && <runtime-link>static in $(properties) &&
! ( <toolset>cw in $(properties) )
{
ECHO "error: link=static together with runtime=link is not allowed" ;
ECHO "error: such property combination is either impossible " ;
ECHO "error: or too dangerious to be of any use" ;
EXIT ;
}
に変更されています。EXIT ;をreturn <build>no ;にすれば旧来通りの動作(上記エラーメッセージが2度表示されますが)になりstatic-staticがビルドされます。
546:デフォルトの名無しさん
09/05/10 18:08:02
但し、RegexのICUサポートを有効にしている場合は
Skipping build of: libs/regex/build/icucore <build>no in common properties ...
と表示され、ビルドされたlibboost_regex-vc90-mt-sgd.libは
EXIT ;をreturn ;(唯戻るだけ)にして上記Skippingメッセージが表示されない状態でビルドした同libとファイルサイズもMD5も一致しません。
ログ(return <build>no ;:URLﾘﾝｸ(booster.x0.to) return ;:URLﾘﾝｸ(booster.x0.to))を見ると
作業フォルダこそ違え同じ様な動作をしている様に見えるのですが、return ;でビルドした方が僅かにファイルサイズが大きくなります。
しかしそもそもstatic-staticでは実行されない筈のルーチンが実行されたり
エラーメッセージが2度表示されしまっている(エラー処理ルーチンを2度通っている)時点で何かがおかしいのですが、
今迄エラーメッセージを発せずICU絡みでしか実害が無い(と思われる)仕様でしたので問題が隠蔽されていた様です。
bjamとJamrootをそれぞれrev.38329(August 1,2007)とrev.38534(August 9,2007)迄戻してもstatic-staticがこのルーチンに引っ掛かっていましたので、
相当昔からのバグの様です。おかしいのは設定ファイルではなく恐らくbjamのソースの方でしょうか。
EXIT ;をreturn ;にしてエラーを完全に無かった事にしてしまうのが対症療法としては現状での最善と思われますが、
この場合、禁止されているshared-staticでも52回エラーメッセージを繰り返した後ビルドを始めてしまいますのでご注意下さい。
547:デフォルトの名無しさん
09/05/10 22:18:43
回避方法乙。
早速使わせてもらいます。
ゲームの場合はstatic-staticじゃないとサポート面倒なんで…
548:デフォルトの名無しさん
09/05/10 23:24:58
Bおおst、buildすら困難になって来たのか
549:デフォルトの名無しさん
09/05/11 00:13:20
俺BoostをLinuxで使うよ君だけど
そのままBuid出来た事なんて一度もないよ
いつもJamファイルと格闘する羽目になる
Windowsはそうでもないのか、うらやましいのぅ
550:デフォルトの名無しさん
09/05/11 02:00:46
VCでCRTのスタティックリンクはもういい加減にやめた方がいいと思うがなぁ。
だいたい何で必要なんだ。
ランタイムのインストーラーの他に、
DLLをEXEと同梱することもライセンス的に認められているというのに。
551:デフォルトの名無しさん
09/05/11 11:07:34
>>549
ぜひ最後の
make instal
コマンドlを
checkinstall
に変えて
で同時にできたdebパッケージを配布してほしい
552:デフォルトの名無しさん
09/05/11 17:34:47
>>550
DLLの検索に失敗して起動できなかったりすることがあるんだよな
調べるのも面倒だからスタティックリンクする
side-by-sideとか意味わかんね
553:デフォルトの名無しさん
09/05/11 21:51:08
>>474
亀レスだが
URLﾘﾝｸ(boost-sandbox.cvs.sourceforge.net)
を使ってます。
ただ、ublas は LAPACK と要素の格納方法が違うので、
hermitian_matrix とかに対して heev が使えないとか、けっこう不便な所がある。
554:デフォルトの名無しさん
09/05/11 22:07:13
>>549
VCだといつも問題なくライブラリビルドできるね。
555:デフォルトの名無しさん
09/05/11 22:20:51
>>552
そういやそれなんで起こるんだろうな。
対処法があればいいんだが。
556:デフォルトの名無しさん
09/05/11 23:30:35
プライベート配置でちゃんとマニフェスト置いておいても失敗するなんて
_BIND_TO_CURRENT_VCLIBS_VERSIONがらみくらいしか知らんがどうなんだろ
そういやURLﾘﾝｸ(booster.x0.to)さんのビルドDLLは、埋め込みマニフェストのCRTバージョンが
9.0.21022.8になってるから、SP1のmsvcr90.dllを配置すると死ぬかもね
557:デフォルトの名無しさん
09/05/12 00:10:17
その心配は要らないはず。
SP1版ランタイムが存在する環境では、バージョンリダイレクトの指定によって、
マニフェストで無印版msvcr90.dllを指定したアプリでも、SP1版ランタイムが読み込まれる。
（たしか無印版CRTをプライベート配置している場合でも）
蛇足だけど、そのことを知ってから自分は
_BIND_TO_CURRENT_VCLIBS_VERSION使うのやめた。
558:デフォルトの名無しさん
09/05/12 12:52:07
戻り値をスマートポインタで返す時に、
scoped_ptrはコピーが禁止されてるから普段はshared_ptrを使ってるんだけど、
コピー禁止+暗黙の型変換でscoped_ptrにできるオブジェクトを作って
それを返してやればいいんじゃね？ってことを思いついた。
今実行できる環境にないからアレだけど……
559:デフォルトの名無しさん
09/05/12 13:32:27
>>558
それは auto_ptr の仕事じゃないか？
560:デフォルトの名無しさん
09/05/12 14:39:24
>>559
Pythonのwith文やC#でusingを使うように
ファクトリ関数の戻り値をスコープ管理したい時に、
生のポインタを返してscoped_ptrで包んでもいいんだけど、
忘れたら嫌なのでスマートポインタで返したい、というイメージ。
auto_ptrだとコピー可能だし、所有権がどうのとか考えるのがめんどくさい。
あくまで戻り値を返す瞬間、一回だけコピーできるようにしたい。
561:デフォルトの名無しさん
09/05/12 14:43:35
>>560
だからまさにそれauto_ptrだって。
562:デフォルトの名無しさん
09/05/12 15:41:56
const auto_ptr=getHogefuga();
みたいなかんじ？んなわけねえか？ｗ
563:デフォルトの名無しさん
09/05/12 18:59:19
>>562
558, 560だけど、const auto_ptrが駄目な理由が分かんなくなってきた……
どこに問題があるか教えてくれるとありがたいんだけど
564:デフォルトの名無しさん
09/05/12 19:10:11
const auto_ptrでいいよ。
const auto_ptrはscoped_ptrのようなものだ。少し違うけど。
565:デフォルトの名無しさん
09/05/12 19:20:20
>>563
const じゃ破壊的代入できないだろ？constでないメンバ関数呼べないんだから
そういうこと？
566:デフォルトの名無しさん
09/05/12 19:27:32
早くunique_ptrがauto_ptr/scoped_ptrに取ってかわるときが来てほしい。
567:558, 560
09/05/12 19:27:43
ん、const auto_ptrを戻り値の型に指定しても右辺値がconstになるだけで
constで受けることを強制できるわけじゃないのか。
受ける時に気をつけるんだったら別にscoped_ptrでもいいし、
なんだかなあって感じだ
568:558, 560
09/05/12 19:47:37
と、俺の提案にも穴があることを発見してしまった
暗黙の型変換演算子も一応関数なので、
scoped_ptr型を返す関数を定義してやんなきゃいけないが、
戻り値を返す時にコピーが発生するので無理だ。
ざんねん！！ わたしの ぼうけんは これで おわってしまった！！
C++0xのunique_ptrとかは右辺値参照とか使ってこれを回避してるのかな？
569:デフォルトの名無しさん
09/05/12 20:25:21
scoped_ptrにauto_ptrで初期化するコンストラクタがあるから、auto_ptrで返してscoped_ptrで受け取ればいいんじゃね?
なぜかドキュメントに載ってないが
570:デフォルトの名無しさん
09/05/13 04:17:00
>>569
559 の時点でゴールが示されてるのに、なぜかたどり着けない 558 が哀れだ。
571:デフォルトの名無しさん
09/05/13 08:32:52
>>568
C++03 の unique_ptr 実装はなかなかうまい方法で右辺値から(のみ)の初期化を実現してる。
それを真似することで、所有権移動禁止だが右辺値初期化だけ可能な scoped_ptr を
作ることはできる…が、それはもはや scoped じゃないという気も
572:デフォルトの名無しさん
09/05/13 10:37:34
みんな意地悪だな。これでいいんだろ？
std::auto_ptr<int> f();
boost::scoped_ptr<int> p(f());
>>571
「C++03 の unique_ptr 実装」って何？ auto_ptr の間違い？
573:デフォルトの名無しさん
09/05/13 22:43:40
>>572
ggrks
URLﾘﾝｸ(home.roadrunner.com)
574:デフォルトの名無しさん
09/05/14 14:40:30
[Review Results] Range.Ex library accepted into boost
URLﾘﾝｸ(groups.google.com)
いつのまにかAcceptされてたんだね。これでやっとRange-Base Algorithmsが大手を振って使える
575:デフォルトの名無しさん
09/05/14 21:40:39
Boost.Oven が誕生することはなかったか…
そいや Egg ってなんで蹴られたんだっけ？ ドキュメント？
576:デフォルトの名無しさん
09/05/14 22:42:56
>>574
Range-Base Algorithmsって何だい？
577:576
09/05/14 22:45:29
>>574
ちょっと見た感じ、Boostにふさわしい変態級の記法をしているように見えるのだが
よく分からんのだ。
578:デフォルトの名無しさん
09/05/14 23:13:29
>>575
誰もレビューしてくれなかったんじゃなかったっけ？
>>576
STLアルゴリズム、std::hoge(c.begin(), c.end(), foo)をboost::hoge(c, foo)と書けるようになるラッパ。
今までBoost Vaultにくすぶっていた部分。
>>576
hoge | foo | barのようなやつのことだな。それはレンジアダプタ。
同類のOvenスレより
ｽﾚﾘﾝｸ(tech板)
> ようするに、| 演算子でパイプ(Unix的なあれ)を作ったC++テンプレートライブラリ。
579:デフォルトの名無しさん
09/05/15 00:21:57
Egg-Oven-Range か・・・なるほど
580:デフォルトの名無しさん
09/05/15 00:37:16
>>577
ModernのAndrei Alexandrescuのこれでも読むといい
URLﾘﾝｸ(groups.google.com)
今が旬だ
581:デフォルトの名無しさん
09/05/15 19:49:24
更新しました。今週は更新の殆どがSpiritとGraphでした。尚、svnは1.40に移行しました。
亦、今回からビルドログを添付する様に致しました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Spirit]
Spirit: Fixing ADL problem in example karma/calc2_ast_vm.cpp
Spirit: Boost.Endian will be used starting Boost V1.41 only
Spirit: Fixed a problem in static lexer generator
[Dynamic_bitset]
Minor comment edit
[Unorderwd]
Cherrypick some unordered container changes from sandbox.
Merge emplace support for sandbox - but without move support.
[Graph_parallel]
Fixed uninitialized variable warning
[Regex]
Add support for named and/or subexpressions with indexes > 99 in conditional format expressions.
[Graph]
Added boost:: qualifications to next, using patch from bug 3013, fixing #3013
Added a new labeled graph adaptor that maps vertices to user-defined key types.
Added missing labeled graph file.
[Pending]
Added a specialization of retag_property_list that will correctly retag
Added a metafunction to determine if a property is no_property.
[Filesystem]
Filesystem: fix #3008, improving namespace discipline to avoid naming conflicts with the C++0x std library.
[Smart_ptr]
Merged in smart_ptr changes from the sandbox/boost0x branch created for
BoostCon '09. This adds move semantics to weak_ptr and intrusive_ptr.
[Exeption]
exception_ptr improvements, documentation update.
582:デフォルトの名無しさん
09/05/16 21:41:28
>>581
お疲れ様です！
583:デフォルトの名無しさん
09/05/16 21:42:54
class rational :
less_than_comparable < rational<IntType>,
equality_comparable < rational<IntType>,
less_than_comparable2 < rational<IntType>, IntType,
equality_comparable2 < rational<IntType>, IntType,
addable < rational<IntType>,
subtractable < rational<IntType>,
multipliable < rational<IntType>,
dividable < rational<IntType>,
addable2 < rational<IntType>, IntType,
subtractable2 < rational<IntType>, IntType,
subtractable2_left < rational<IntType>, IntType,
multipliable2 < rational<IntType>, IntType,
dividable2 < rational<IntType>, IntType,
dividable2_left < rational<IntType>, IntType,
incrementable < rational<IntType>,
decrementable < rational<IntType>
> > > > > > > > > > > > > > > >
ってrationalの定義にあるんだが、これは何？？
もしかしてこうするとEmpty Base Optimizationが働くとか！？
584:デフォルトの名無しさん
09/05/16 21:49:22
>>583
Boost::operatorで自明な演算子定義を省略してるんだろ
こうしとけば+=があれば+は勝手に実装される
585:デフォルトの名無しさん
09/05/16 21:57:53
ちなみに、継承のアクセサを省略(private継承)してるのでis-aの関係ではなく、
どちらかというとmixinに近いことになってる。
586:583
09/05/16 22:05:31
>>584
ああ、Boost.Operatorsライブラリはしってるんだけど、
このテンプレートにテンプレートを重ねる変態的記法に驚いたのだ。
で、「Empty Base Optimizationが働くとか！？」と思った。
587:583
09/05/16 22:06:53
つまり普通だったらprivateの多重継承を考えるじゃない。
それを使わず、テンプレートにテンプレートを食わせてるじゃん。
588:デフォルトの名無しさん
09/05/16 22:27:44
URLﾘﾝｸ(www.boost.org)
ドキュメントにかいてあるぞ
589:583
09/05/16 22:30:46
ありがとう。
やっぱEmpty Base Optimizationね。
590:デフォルトの名無しさん
09/05/16 22:39:29
これ使った場所でちょっと複雑な原因不明のエラーが起こったら
デバッグできる自信ない・・・
591:デフォルトの名無しさん
09/05/16 22:50:33
自作ライブラリの実装が
boostの実装と微妙にかぶっちゃうところがあるんですけど
それってライセンス違反になるんでしょうかね？
spiritとかlambdaとかのアイディアの根幹に関わる部分じゃなく
全然一般的な実装なんですけど。
例えばユークリッドの互除法とか。
592:デフォルトの名無しさん
09/05/16 23:39:11
Boostからぱくった？
はい→ライセンス見ろ。改変おｋ、ソースコードからクレジットを外すなとかその程度でライセンスはクリアだ。
いいえ→結果的に同じものでも別々に作れば違う著作物。それぞれに著作権がある。堂々としろ。
593:591
09/05/16 23:49:16
>>592
ありがとうございます。別にぱくったわけではなく、結果的に若干（気にしすぎなのかもしれませんが）似てしまいました。
あと、まだはっきりとライセンスを熟読したこと無いのですが
Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:
The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
これは短いですが、全文ですよね。
熟読してきます。
594:デフォルトの名無しさん
09/05/16 23:58:48
相手の実装を知っていて、
自分も作ってみたら似てしまったというのなら、
GNUの中の人的にはアウトだな。
パクリ元がNDA結んだ仕事相手じゃなくてboostでよかったな。
595:591
09/05/17 00:00:26
実装を流用する場合に関係がありそうな部分は
二段落目
The copyright notices in the ～
ですね。
要するに
…………………………
1.流用対象のライブラリの著作権表記
2.Boost Software License の全文
流用して作ったソースコードを開示する場合、これらを全て記載すること。
ただし実行ファイルの形ならば無制限。
…………………………
ってことですね。
ありがとうございました。
596:デフォルトの名無しさん
09/05/17 00:27:29
俺は今までバイナリでしか使ったこと無い（し、そもそも職場がboost原則禁止orz）から分からないんだが、
例えばBoost.Functionのあるソースを流用して自作ライブラリMy_Libを作り、
My_LibのソースコードをBSDライセンスで公開したい場合はどうすればいいってことになるの？
1.My_Libのソースコードに
Boost.Functionの著作権表記と
Boost Software Licenseの全文を記載する。
2.My_Libのソースコードに
BSDライセンスの全文を記載する。
3.「2.」のBSDライセンスの文言にはBoost.Functionの著作権表記は関わらない。
かい？でもこれだとMy_Libを流用する第三者がMy_LibのBSDライセンスの通りに作ると
Boost.Functionの著作権表記が引き継がれなくなっちゃうよね？
だれか分かるお方、お知恵をお貸しくだされ