09/02/17 00:07:42
shared_ptrだと
boost::scoped_ptr<string> x;
boost::scoped_ptr<string> y( new string("foo") );
x = y;
scoped_ptrだと
x.reset(new string("foo"));
と理解しました。
init関数でresetって違和感ありますが、こういうものなのでしょうか。
scoped_ptrを初期化子リストでnewしない場合は
設計を見直した方がいいのかな
111:デフォルトの名無しさん
09/02/17 01:03:57
見直した方がいいかもね。結果は変わらないかもしれんが。
112:デフォルトの名無しさん
09/02/17 01:12:04
shared_ptrでもresetできるよ、一応念のため。
113:デフォルトの名無しさん
09/02/17 03:44:59
>>110
コンストラクタから例外投げないとか言うアホなコーディング規約に縛られてるんでもなければ
初期化リストで new しとけ。
114:113
09/02/17 03:46:52
あれ？ごめん。 init() はコンストラクタの中で呼ぶのね。
そうなると初期化リストで new しない理由がわからん。以下 >111 と同文。
115:デフォルトの名無しさん
09/02/18 08:31:26
boostのshared_ptrの資料に、無名オブジェクトを使った以下のコードはfunc2が例外を投げるとリークの可能性があると書いてたけどどう？
func(shared_ptr<Hoge>(new Hoge(),func2( ))
newしてfunc2が評価されて例外投げるとshared_ptrにセットされる前の可能性があるかららしいけど、この評価順は規格上未定義だからって普通にあるの？それとも規格上ありうるってこと？
116:デフォルトの名無しさん
09/02/18 10:23:47
>>115
Effective C++にも 「やるな」 って書いてなかったっけ？
117:デフォルトの名無しさん
09/02/18 11:04:26
>>115
経験談だけど引数の評価順はかなり簡単に変わるから普通にある
評価順に依存してバグが起こるコードだとマジヤバイ
当然コンパイラ次第なのだけど，デバッグ用の最適化なし，と，最適化あり，にするだけで変わったりする
デバッグで問題見つからなくて泣きそうになったことある
118:デフォルトの名無しさん
09/02/19 00:53:23
そんなクソコードはマクロでも使わなきゃでてこないんじゃね？
119:デフォルトの名無しさん
09/02/19 03:38:54
スマートポインタどうこうは別にして
評価順によるバグなんて本能的に避けるだろ。
たまに、新米プログラマで、変数使わないで長い式をグダグダ一気に書くのが
かっこいいと思ってる奴がいるから困る
120:デフォルトの名無しさん
09/02/19 19:09:25
，を越えて評価順が混ざるとは思わなかった。
121:デフォルトの名無しさん
09/02/19 19:56:50
>>120
115の例に表れるカンマは関数呼び出しの一部だよ。
順次演算子としてのカンマなら、たしかに評価順序点になるけど。
122:デフォルトの名無しさん
09/02/20 21:44:14
更新しました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Units]
Get rid of duplication between conversion_helper and conversion_factor_helper.
[Graph]
Updating core_numbers from David Gleich.
Importing examples from SOC 2007
[Random]
Change shfit2 to shift2. Add missing namespace scope definitions of shift1 and shift2. Fixes #2764
Convert uniform_01 to the current distribution interface,
dispatching on the first template paramter to retain backwards compatibility. Fixes #599. Fixes #1544. Fixes #2679
[Ptr_container]
fixed bug in ptr_sequence_adapter.hpp, plus removed some warnings in detail/reversible_ptr_container.hpp.
added new overload of new_clone() that allows for null-values.
removed nasty bug in erase()
[Fusion]
use vectorN instead of vector for shorter names
#define to allow testing if unused_type has IO
[Interprocess]
Ticket #2766: error in boost::interprocess::file_lock::swap
[intrusive]
Ticket #2755: compile error in boost_intrusive 1.38.0: a set of classes with protected destructor
[Spirit]
Fix: rename "boost::math" to "boost::spirit::math".
Remove :: from memcpy()
[Serialization]
Correction to extended_type_info implementation
123:デフォルトの名無しさん
09/02/21 13:25:35
boost.graphについてですが、
検索を途中でキャンセルするのは例外を使用するしかない？
例：幅優先で検索し、目的のvertexが見つかったらそこで
検索をやめる。
boost.graph自体は基本的な例外安全は確保されているみたい
なので例外の使用自体に問題はないとは思いますが・・・。
124:デフォルトの名無しさん
09/02/21 13:51:45
>>123
それは例外ではないから例外で抜けるのは不適当だろう。
125:123
09/02/21 14:02:45
全検索関数を途中やめること自体が例外的・・・。
（言葉遊びですな）
126:デフォルトの名無しさん
09/02/21 17:06:21
使用するに足る理由があって他の方法より適当だと思えば
例外でも何でも使えばいいと思うよ
例外だからってエラー処理以外に使わざるべしという論理的根拠はない
127:デフォルトの名無しさん
09/02/21 17:11:55
エラー処理以外に例外を使って地雷を踏む例は多いんだが、地雷原と知ってもなお進むというなら止めはしない。
128:デフォルトの名無しさん
09/02/21 17:14:17
実装できないよりましだな
129:123
09/02/21 17:46:38
>>126
>例外だからってエラー処理以外に使わざるべしという論理的根拠はない
同意です。ただ他の方法があるのかという質問です。
例外使えないときもあるし。
>>127
具体的には? 例外安全に関する話題？
130:デフォルトの名無しさん
09/02/21 18:05:52
見つからないってのはエラーではないのか？
131:デフォルトの名無しさん
09/02/21 19:11:13
例外は単なるステートメントの1つである。
132:デフォルトの名無しさん
09/02/21 19:30:14
例外しか方法ないなー
全部黒にしてvisitorの実行を抑制することならできるけど
それでも走査することには変わりねぇしな
つうことは見付かった時点で全部を辿るって前提が満たされなくなるから例外でいいんじゃないと
133:デフォルトの名無しさん
09/02/21 23:53:50
別にチョコボの不思議なダンジョンのリサイクルボックスみたいに
n回使ったらバグが発生するとかそういうものでもないんだから、
そこまでして忌避したり意味を考えたりとかしなくていいんじゃなかろうか。
134:デフォルトの名無しさん
09/02/22 00:16:53
Let's Boostの人スゲーなアグレシップすぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
135:デフォルトの名無しさん
09/02/22 00:51:26
なんか変わってる？
そういや中の人は院卒業したんだっけか。
136:デフォルトの名無しさん
09/02/22 08:04:34
>132
>全部黒にしてvisitorの実行を抑制することならできるけど
TerminatorFunc を使うってことでいいですか？
137:デフォルトの名無しさん
09/02/22 09:48:29
>>135
名前と写真が出るわ出るわ
138:デフォルトの名無しさん
09/02/22 10:27:09
海外では顔出しも本名出しも普通だろ
ガキじゃねーんだからキャーキャー騒ぐなよ
139:デフォルトの名無しさん
09/02/22 16:50:27
クラスのメンバ関数をパラメータ的に扱いたいんだけどどうすればいいかな。
こんな感じのことがしたいんだけど。
class A
{
public:
void func_a1();
void func_a2();
};
class B
{
public:
void func_b();
}
template<???>
void call_twice(???)
{
//オブジェクトとメンバ関数を引数にとってメンバ関数を２回呼ぶ
}
int main()
{
A a;
B b;
call_twice(a,func_a1);
call_twice(a,func_a2);
call_twice(b,func_b);
}
140:デフォルトの名無しさん
09/02/22 17:24:13
つ boost.function
141:デフォルトの名無しさん
09/02/22 17:33:21
単にメンバ関数へのポインタを使えば十分だろう。
Boost的には、bind使えば引数一つにまとまられるよと言うくらい。
142:デフォルトの名無しさん
09/02/22 18:17:25
そのレスはほんとうに単純にメンバ関数へのポインタを渡すような誤解を与えるぞ。
メンバ関数へのポインタをどう使うのかを書かないと。
このスレ的には>>140を使うことを前提にしてるんだろうけど。
143:139
09/02/22 21:29:21
レスどうもです。
boost.function使ってみました。結構いい感じ。
で、つかぬことをおききしますがboost::functioinを使った場合インライン展開はされるのでしょうか。
速度が必要なもんで気になります。
一応アセンブラをみて見たんですが俺にはよくわからない。(´･ω･`)
関数ポインタならインライン展開されなさそうなきがするんですが。
144:デフォルトの名無しさん
09/02/22 21:42:00
されないね。
145:139
09/02/22 21:47:28
そですかー(´･ω･`)
ありがとうございます。
boostってテンプレートだけじゃなくて意外と中でマクロも使われてるんですね。
いっそマクロの併用も検討するか…
146:デフォルトの名無しさん
09/02/22 21:58:17
ちなみに関数ポインタもあんまインライン展開はされないぞ。
147:141
09/02/22 21:59:17
>>142
単にこれでいいだろうというつもりで書いた。やや楽観的期待だが、インライン展開もされるだろう
template<typename T>
void call_twice(T x, void (T::*p)())
{
(x.*p)();
(x.*p)();
}
int main()
{
A a;
B b;
call_twice(a, &A::func_a1);
call_twice(a, &A::func_a2);
call_twice(b, &B::func_b);
}
148:デフォルトの名無しさん
09/02/22 22:02:38
>>143
速度が必要なら仮想関数や関数ポインタは向かないね。
テンプレートで展開されるようにしたほうがいいかも
149:デフォルトの名無しさん
09/02/22 23:51:22
147くらいのコードだと頭のいいコンパイラはインライン展開しちゃうけど、
たぶん142は何らかのデータ構造にメンバ関数を保存して必要なときに
実行とかいう使い方をするだろうから最終的には間接参照が最低一回
必要になると思う。
とりあえずテンプレート使ってみた版
template <class T, void (T::* func)()>
void call_twice(T t) {
(t.*func)();
(t.*func)();
}
int main() {
A a;
B b;
call_twice<A, &A::func_a1>(a);
call_twice<A, &A::func_a2>(a);
call_twice<B, &B::func_b>(b);
}
150:139
09/02/23 00:15:36
>>149
うおっ！なんかすごいのきたｗ
テンプレートの引数にvoid (T::* func)()なんて使えるのかー。
カルチャーショックだぜ。
もっと精進せねば。
どうもありがとうございます。
151:デフォルトの名無しさん
09/02/23 11:43:44
>>149
この形式だと inline 化されるというのを昔 Cryolite 氏が実験してたな
152:デフォルトの名無しさん
09/02/23 12:18:33
テンプレート引数に関数クラスを渡す方法ならかなり自由度が上がるかも
153:デフォルトの名無しさん
09/02/23 16:41:31
ひとつ相談なのですが、初期サイズの違う複数のpoolを同時に使うくらいなら
boost::pool<> pool(1) にして
(T*)pool.ordered_malloc(sizeof(T)) でひとつのpoolを共有すべきですか？
154:デフォルトの名無しさん
09/02/23 18:32:23
>>153
サイズの種類が限られてるなら同時につかえばいいんじゃないか？
155:デフォルトの名無しさん
09/02/23 18:41:34
やったことは無いんだけど、４バイト未満のチャンクって作れるのかな
156:デフォルトの名無しさん
09/02/24 09:25:08
>>153
以前ordered_mallocを使ってnew []演算子を作ろうと思って試したことがあるが、
普通のnew[]演算子よりむちゃくちゃ重くなった。
おそらくメモリプールに指定のサイズの領域が空いてるかどうかチェックする処理が重いんだと思うけど…
157:デフォルトの名無しさん
09/02/24 09:45:16
常識的に考えて、その方法が速いならnewの実装なんてとっくにそうなってるに決まってるだろ……
158:デフォルトの名無しさん
09/02/24 10:43:02
>>154-157
ありがとうございます。参考になりました
今回は型ごとにpoolを作ろうと思います
ordered_mallocが使用される回数を極力抑えられるように書いてみます
159:デフォルトの名無しさん
09/02/24 20:17:56
boost::lambda::bindで下のコードがコンパイルエラーとなります。
(1)のところを
la::bind(&human::use, man, la::var(t))();
としても同じでした。
因みにboost::bindを使用した場合は
bind(&human::use, man, ref(t))();
とするとコンパイルエラーが発生しないようになりました。
lambda::bindを使用した場合にでるコンパイルエラーを回避する方法はないでしょうか？
環境：WinXP, VC8, boost1.38.0
// main.cpp
#include <boost/lambda/bind.hpp>
#include <boost/lambda/lambda.hpp>
#include "create.hpp"
#include "human.hpp"
#include "tool.hpp"
namespace la = boost::lambda;
int main()
{
human man;
tool* t(create_tool()); // toolは抽象クラス
la::bind(&human::use, man, t)(); // -----(1)
delete t;
}
160:デフォルトの名無しさん
09/02/24 20:18:48
長いので分割失礼します。
// human.cpp
略...
void human::use(tool* t) { t->hoge(); }
略...
// tool.hpp
class tool
{
略...
virtual void hoge() = 0;
略...
[コンパイル]
main.cpp
\XXX\boost/tuple/detail/tuple_basic.hpp(419) : error C2259: 'tool'
: 抽象クラスをインスタンス化できません。
次のメンバが原因です:
'void tool::hoge(void)' : は抽象型です
\YYY\tool.hpp(6) : 'tool::hoge' の宣言を確認してください。
161:デフォルトの名無しさん
09/02/24 20:55:08
突然ですが、おまえらに問いたい！
boostのイメージカラーは何色？
162:デフォルトの名無しさん
09/02/24 21:01:09
マ板でやれ
163:デフォルトの名無しさん
09/02/24 21:03:29
>>161
失せろクズ
164:デフォルトの名無しさん
09/02/24 21:48:39
>>161
二度とくんなカスが
165:デフォルトの名無しさん
09/02/24 21:49:15
>>161
VIPでやれ
166:デフォルトの名無しさん
09/02/24 21:53:55
ここまで俺の自演
167:デフォルトの名無しさん
09/02/24 22:12:16
>>159
create_toolの中は？
168:デフォルトの名無しさん
09/02/24 22:21:11
>>162～166
オメーも反応すんなヴォケ
しかも一人で無駄に投稿すんな。
169:デフォルトの名無しさん
09/02/24 22:23:56
159です。
>> 167
// create.cpp
class hammer : public tool
{
public:
略...
void hoge()
{
// 実装
}
略...
};
tool* create_tool()
{
return new hammer;
}
といった感じです。
toolの具象クラスのhammerは表に出ないようになっています。
170:デフォルトの名無しさん
09/02/24 23:17:28
>>169
とりあえずboost::refをつけたら、こっちではコンパイル通った
la::bind(&human::use, boost::ref(man), t)(); // -----(1)
GCC 4.0.1, boost 1.38.0
171:デフォルトの名無しさん
09/02/24 23:59:16
159です。
>>170
確かに
void human::use(tool*);
ならそれで通りますね。ありがとうございます。
私の実際のコードでは
void human::use(tool&);
となっていまして、教えて頂いたようにしても同じコンパイルエラーが発生してしまいます。
172:デフォルトの名無しさん
09/02/25 07:01:49
>>171
*と&はまったく違う意味だぞ。
そこで一時オブジェクトを作ろうとしてエラーになってるんじゃないのかconst tool&にしてみろ
173:デフォルトの名無しさん
09/02/25 09:59:28
159です。
>>172
void tool::hogeがconstでないのでtool const&とはできません。
一度実際のコードを載せてみます。
// create.hpp
#pragma once
struct tool;
tool* create();
// create.cpp
#include <iostream>
#include "create.hpp"
#include "tool.hpp"
using namespace std;
struct hammer : tool { void effect() { cout << "gotin\n": }
tool* create() { return new hammer; }
// human.hpp
#pragma once
struct tool;
struct human { void use(tool& t); }
// human.cpp
#include "human.hpp"
#include "tool.hpp"
void human::use(tool& t) { t.effect(); }
174:デフォルトの名無しさん
09/02/25 10:00:01
// tool.hpp
#pragma once
struct tool {
virtual ~tool() throw() {}
virtual void effect() = 0;
};
// main.cpp
#include <boost/lambda/bind.hpp>
#include <boost/lambda/lambda.hpp>
#include <memory>
#include "create.hpp"
#include "human.hpp"
#include "tool.hpp"
using namesace boost;
using namespace std;
namespace la = lambda;
int main() {
auto_ptr<tool> t(create());
human man;
la::bind(&human::use, la::var(man), la::var(*t))();
}
175:デフォルトの名無しさん
09/02/25 11:30:52
struct pred
{
pred(int){}; ←(A)
void operator()(int v) const
{
std::cout << v << "\n";
}
};
boost::function_output_iterator<pred> fi(pred(0));←こうするには(A)が必要
boost::function_output_iterator<pred> fi(pred());←(A)を消してこう書くことができない←(B)
std::vector<int> v(boost::counting_iterator<int>(0),boost::counting_iterator<int>(10));
std::copy(v.begin(), v.end(), fi);←(B)だとここでエラー
std::copy(v.begin(), v.end(), boost::make_function_output_iterator(pred()));←これだと(A)がなくてもOK
make_function_output_iteratorは(B)と同じことしているんじゃないの？
176:デフォルトの名無しさん
09/02/25 12:25:21
const tool&を使わずに抽象クラスを渡すには、どうにかしてコピー可能にする必要がある。
tool*を使うか、ref(t)で渡す。
177:デフォルトの名無しさん
09/02/25 13:16:26
159です。
>>176
tool*でならmain.cppの最終行を
la::bind(&human::use, la::var(man), t.get())();
としてやれば良いのですが
tool&をhuman::useの引数にすると
la::bind(&human::use, la::var(man), la::var(*t))();
は、やはりエラーとなりますね。
la::bind(&human::use, la::var(man), boost::ref(*t))();
としてもエラーです。
腑に落ちないのが
boost::bind(&human::use, boost::ref(man), boost::ref(*t))();
ならコンパイルが通ること。
lambdaの内部を追っているわけではないのでなんともいえませんが、
ユーザからすると、この動作は奇妙に思えます。
boost::bindとboost::lambda::bindは互換性があると勝手に思っていたの
で意外です。
boost::cref => boost::lambda::constant_ref
boost::ref => boost::lambda::var
という理解も間違っているのでしょうか？
178:デフォルトの名無しさん
09/02/25 14:13:20
main.cpp
\XXX\boost/tuple/detail/tuple_basic.hpp(419) : error C2259: 'tool'
: 抽象クラスをインスタンス化できません。
次のメンバが原因です:
'void tool::hoge(void)' : は抽象型です
\YYY\tool.hpp(6) : 'tool::hoge' の宣言を確認してください。
とでてるので、抽象クラスをやめたら
la::bind(&human::use, man, (*t);
でエラーにならない。
lambda::bindのどっかで抽象クラスをインスタンスかしようとしてるんだろう
179:デフォルトの名無しさん
09/02/25 14:15:02
マニュアル読む限り
boost::ref => boost::lambda::var
は間違ってると思う。
boost::ref は参照型だけど、lambda::var は参照じゃない
180:179
09/02/25 14:34:38
>>179
すまん、間違ってた。
やっぱ参照みたい。
181:デフォルトの名無しさん
09/02/25 15:05:38
URLﾘﾝｸ(boost.cppll.jp)
182:デフォルトの名無しさん
09/02/25 17:31:50
159です。
>>181
そのページは私も読みました。
boost::refはboost::lambda::varに置き換えられると理解しております。
>>178
でしょうね。
しかし、実装上の事情はどうであれ、インタフェースとしては抽象クラスの参照を
bindの引数にすることを可能としていなければいけないように思えます。
何か回避策がlambdaにあるのではと思うのですが直ぐには見つけられませんね。
ご存知の方いないでしょうか？
183:デフォルトの名無しさん
09/02/25 17:55:58
la::bind(&human::use, la::var(man), la::var(boost::ref(*t)))();
でどうか？
184:デフォルトの名無しさん
09/02/25 17:57:52
>>182
抽象クラスはインスタンス化できない。それをしようとしているからエラーになる。
テンプレートの引数に参照で渡したいときはref( )を使えば参照が渡せる。
185:デフォルトの名無しさん
09/02/25 18:05:31
>>182
>>159
>bind(&human::use, man, ref(t))();
boost::bind できるんなら、boost::lambda::bindにこだわる必要ないでしょう
186:デフォルトの名無しさん
09/02/25 18:10:46
bindのプレースホルダによる汚染が怖いとかじゃないんでしょうか
187:デフォルトの名無しさん
09/02/25 18:25:05
159です。
>>183
目から鱗ですね。
それでいけました。
ありがとうございます。
>>185
boost::bindとboost::lambda::bindの混在は面倒なトラブルが発生することが
あるので避けています。
皆さんありがとうございました。
他にもスマートな方法があればお教え頂きたいと思います。
188:デフォルトの名無しさん
09/02/25 18:27:25
>>183
それでいける理由が知りたい
189:デフォルトの名無しさん
09/02/25 18:44:07
簡単に言うならreference_wrapperとidentityにより型の解決が遅延されて、
早期の解決によって束縛される値が参照型から値型になってしまうことを防ぐことができるから
かなぁ
190:デフォルトの名無しさん
09/02/25 21:07:02
URLﾘﾝｸ(lists.boost.org)
191:デフォルトの名無しさん
09/02/26 16:50:17
「参照型から値型がになってしまう」とはどんな具体的にどんな状況ですか？
できれば最小のサンプルソースが見たいです。
192:デフォルトの名無しさん
09/02/26 16:51:37
>>189
「参照型から値型がになってしまう」とは具体的にどんな状況ですか？
できれば最小のサンプルソースが見たいです。
typo があったので再投稿。
193:デフォルトの名無しさん
09/02/26 18:09:02
まだtypoがある件
194:189
09/02/26 19:39:19
>>191
一言で言えば、remove_referenceを使えばそうなる。
以下、var(ref(*t))で上手くいくかの理由の大まかに解説する
remove_referenceはメタ関数deduce_non_ref_argument_typesで使われている、
このメタ関数はlambda_functor_baseが具現化される際に、束縛する値の型を保持する為のタプルの型の要素に対して適用される。
なのでvar(ref(*t))以外での渡し方をすると型計算の結果、tool&やconst tool&を要素として持つタプルの型が生成される。
するとtupleを構成する型に抽象型toolが含まれてしまい、tupleを実体化するときにtoolを実体化しようとしてエラーになる。
実際はtupleはconsで実装されているのでコンパイルエラーはconsのheadメンバの宣言の時点で発生する。
そこでduduce_(ryの時点でreference_wrapper<tool>になるようにしてremove_referenceを防ぐためにboost::ref()を使うわけだけど、
boost::refだけだとbindに渡された時点でbind_tuple_mapper内での型の解決によりtool&型になってしまうので、それを防ぐためにvar()を使う。
すると問題になっているtupleの要素の型はdeduce(ryを経てもidentity<reference_wrapper<tool> >のままになり、
結果boost::lambda::bindの返す関数オブジェクトはこの関数オブジェクトをそのままtupleの要素として保持することになる。
そしてこのidentity<reference_wrapper<tool> >は生成した関数オブジェクトが呼び出される際、つまりoperator()が解決されるときに、
identity、reference_wrapperの解決を経てtool&として解決される。
要するに>>189というわけだ。
これ以上詳しく知りたければboostのコード読んでください。
195:デフォルトの名無しさん
09/02/26 23:28:29
乙
196:デフォルトの名無しさん
09/02/27 22:01:56
更新しました。今週はソースの追加や削除が多いです。
ビルド用の設定ファイルもチューニングされ、今迄フルビルドに1時間弱掛かっていたのが20分に超高速化されました。
URLﾘﾝｸ(booster.x0.to)
以下更新内容の一部
[Gil]
GIL: fixed Ticket 784: Wrong initilization of data members in packed_pixel constructors
[Utility]
Fixed const issue of value_initialized according to ticket #2548.
[Functional]
adds missing template parameters for partial specialisations
Fix the hash dirname.
[Serialization]
fixed namespace
[Archive]
permit start/end load/save to be overridable
[Fusion]
updates functional module: only two unfused variants, now
Fix: remove non-existent test
[Random]
Initialize _modulus in the linear_congruential constructor that takes a pair of iterators. Fixes #2665
[Unordrered]
Make copy_buckets and move_buckets member functions - so that calling them is a bit simpler.
Move some of the data structure classes out of hash table data.
[Config]
Merge branches/cpp0x into trunk, enabling a bunch of BOOST_NO_* macros for C++0x early adopter feature tests
[Math]
Merges changes from Sandbox version:
MPFR Support.
New distributions: laplace, logistic and hypergeometric.
Added C# usage example.
197:デフォルトの名無しさん
09/02/28 01:30:27
>今迄フルビルドに1時間弱掛かっていたのが20分に超高速化されました
マジかよｗｗｗｗｗ
198:デフォルトの名無しさん
09/03/01 10:06:36
RubyのModule的なことをしたいんだけど可能？
関数を用意しておいて他のクラスにその関数をメンバとして追加したいです。
Rubyのコードだと以下のようになります。
module MyModule
def extend_function
print "extend_function\n"
end
end
class MyClass
include MyModule
end
object=MyClass.new
object.extend_function
199:デフォルトの名無しさん
09/03/01 10:10:56
C++0xスレで拡張メソッドが話題になったばかりだから覗いてみるといいかな
200:デフォルトの名無しさん
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
と記述されています。お手数ですがアドバイスお願いいたします。