- Boost-users - lists.boost.org

[Serialization] Serialization of a derived template class inheriting from a none template base
by Sebastian.Karlsson＠mmorpgs.org 10 Aug '08

10 Aug '08

Hi, I'm in the process of trying to get boost::any serializable, and it's quite tricky, especially considered my very limited experience with boost::serialize. I googled around and found an old discussion on this very list, and while interesting no resolution seemed to be found which satisfied all the criteria for being commited boost. However, since I'm not as picky with data portability, the solution hinted at in: http://lists.boost.org/boost-users/2005/09/14266.php seems very interesting. The only problem is that I can't see how it would be implemented to solve this problem. It needs to be within the definition of the class to be able for the typename to be in scoop, but since the macro seems to expand to a definition to be placed in the boost namespace I can't seem to get it to play nice. Any solution which lets me automagicaly serialize boost::any which contains serializable types, even if intrusive, would be extremely welcomed.

5 11

warning in bind header
by Isaac Lascasas 10 Aug '08

10 Aug '08

Hello, this is my first post to the Boost Users List. First, I want to present my respect to all the boost lib developers. I have been using boost lib for about two years and it has improved the quality and robustness of my code to points I would have never imagined. Thank you very much. I'm posting this message because I get the following warning in the bind.hpp header from the current trunk with the vc++2008 compiler: c:\code\BoostSVN\boost/bind.hpp(1643) : warning C4180: qualifier applied to function type has no meaning; ignored c:\code\BoostSVN\boost/bind.hpp(1677) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled with [ Pm=sl::math::vector4<float> (__cdecl sl::pipe_smasher::pipes::build_float4::* )(void), I=1 ] c:\code\sl\pipe_smasher\pipes/build.hpp(106) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled with [ Pm=sl::math::vector4f (__cdecl sl::pipe_smasher::pipes::build_float4::* )(void), A1=sl::pipe_smasher::pipes::build_float4 * ] My code looks like this: class build_float4 : public pipe { public: build_float4() { m_pOutput = add_output<vector4f>("Output"); m_pInputX = add_input<float>("x"); m_pInputY = add_input<float>("y"); m_pInputZ = add_input<float>("z"); m_pInputW = add_input<float>("w"); m_pOutput->add_dependency(boost::bind(&build_float4::on_input_change, this), m_pInputX, m_pInputY, m_pInputZ, m_pInputW); } vector4f on_input_change() { return vector4f(**m_pInputX, **m_pInputY, **m_pInputZ, **m_pInputW); } private: output<vector4f>* m_pOutput; input<float>* m_pInputX; input<float>* m_pInputY; input<float>* m_pInputZ; input<float>* m_pInputW; }; Checking the bind.hpp I found the following: template< class M, class T > struct add_cref< M T::*, 1 > { typedef M const & type; }; Maybe I'm doing something wrong or it is just a typo in the bind.hpp? Thank you, Isaac Lascasas

2 1

[multi-array] Performance? Difference from GIL or uBLAS?
by John C. Femiani 09 Aug '08

09 Aug '08

Has anybody measured performance of multi-array? I am considering whether or not to use it, but when I googled multi_array I got a very old, but unresolved, discussion about poor performance measurements in experiments with optimized code that uses multi_array. (http://lists.boost.org/boost-users/2003/07/4423.php) Also, after a rough glance through multi_array and uBLAS it looks like GIL, uBLAS, and multi_array seem to repeat very similar concepts (and seem to use different syntax). Isn't that kind of bad? I have been playing with GIL in the past but now I am scratching my head about these other libraries. -- John

5 22

A few boost::function questions
by Jesse Perla 09 Aug '08

09 Aug '08

Is there any way to get a normal function pointer out of a boost::function (with its state and potential bindings)? I want to have the option of calling existing optimization routines that are not functor aware. And hopefully including Fortran and C functions as well? I imagine that any solution to this would be hacky and potentially slow, but it would be nice to have the option without porting every optimization routine. Also, what is the general consensus on http://www.codeproject.com/KB/cpp/FastDelegate.aspx these days? How much faster is the overhead? From what I read in this link, it is virtually none vs. 20nanoseconds'ish for boost::function. Are there any caveats or reasons not to apply this widely (assuming that I am using only the Intel compiler)? And am I able to hack out a function pointer out of this library? Does using a binding library remove the speed of the fast delegation? Last, I am having a little trouble understanding the "forwarding problem" as a library user. My main use-case is for dynamic programming. I will have a function of 3-4 parameters (an euler equation or bellman iteration). I will bind all but one of the parameters and then run an optimizer over the other one. However, what values are bound will be in a foreach. (i.e. choose a state space, foreach in statespace run optimizer to see policy function choice for each point in the statespace. iterate...) . Is this going to work with these libraries? Is boost::function combined with boost::binding the most semantically correct way to do this? Am I going to run into enormous overhead or the forwarding problem when I do this? Do nested bindings add in linear overhead? Thanks, Jesse

3 2

[boost.function] member function object problem
by Olaf Peter 09 Aug '08

09 Aug '08

Hi, I perform some tests and run into problems. The following code doesn't compile: ---8<--- #include <boost/python.hpp> namespace python = boost::python; struct My { void exec_test() { } }; int main() { Py_Initialize(); boost::function<void (My*)> exec_test = &My::exec_test; //L13 My my; if (python::handle_exception(exec_test(&my))) { if (PyErr_Occurred()) { PyErr_Print(); } } return 0; } --->8--- $ LANG=en g++ -I /usr/include/python2.5 python_embedded.cpp -o python_embedded -l python2.5 -l boost_python python_embedded.cpp: In function 'int main()': python_embedded.cpp:13: error: variable 'boost::function<void ()(My*), std::allocator<void> > exec_test' has initializer but incomplete type but the code snipped from the boost.function doc page works: ---8<--- #include <boost/function.hpp> struct X { void foo() {} }; int main() { boost::function<void (X*)> f = &X::foo; X x; f(&x); } --->8--- I see no difference that matter, what happens here? Thanks, Olaf

2 2

[enable_if] Why any other than lazy?
by Robert Jones 09 Aug '08

09 Aug '08

Boost.EnableIf defines enable_if etc, and goes on to define lazy_enable_if, which the documentation states is for the circumstances and compilers when the non-lazy version would break since the instantiation for which SFINAE should apply is a nested instantiation which is not properly processed by some compilers. What I don't understand is why anyone would wish to use the non-lazy versions, since AFAICS the lazy version will always work. Then the obvious question is why the non-lazy versions exist at all? Thanks, Rob. -- ACCU - Professionalism in programming - http://www.accu.org

2 3

build times and Boost.Function
by gast128 09 Aug '08

09 Aug '08

Dear all, this would be my 3 post on build times and Boost, since we develop a fairly large system (> 3000 classes) and use Boost a lot. Rebuilding the complete system takes about 2 hours on my home pc (DELL P4 2GHz, 512 Mb) and about 1 hour on my pc @ work (DELL G280, P4, ht, 3.0 GHz, 1 Gb memory). We already use precompiled headers and tend to forward declare as much as possible. Using some of the Boost components in headers is just out of the question because of the increased build times: - exposing the Boost.MultiIndex headers in a much used header drammatically increases build times - same argument for <boost/variant.hpp> - including <boost/type_traits.hpp> give also a huge latency However I also notice that Boost.Function does not have an include guard. Boost.Function is used a lot and exposed through a lot of headers in our code (since they often define a callback interface). Adding an include guard myself drops the build time for a test project dramatically if Boost.Function is included recursively: - include guards + pch 0.42 - include guards 0.35 - normally 1.52 Is there a reason that <boost/function.hpp> does not have an include guard? Does it harm when adding one (or using a wrapper around it, i.e. "incboostfunction.h" which has an include guard)? wkr.

6 8

[preprocessor] ADD efficiency / documentation?
by Isaac Dupree 09 Aug '08

09 Aug '08

This documentation is self-contradictory: http://www.boost.org/doc/libs/1_35_0/libs/preprocessor/doc/ref/add.html "This macro is the most efficient when x is less than or equal to y. However, the efficiency gain is not worth actually comparing the two arguments prior to invocation. In other words, x should be the addend that is most likely to be the largest of the two operands." The first sentence says we want (x <= y); the last sentence says we want (x > y). Which is it? :-) -Isaac

2 1

[boost-users] crash of visual studio compiler with boost bind
by Oliver Kania 08 Aug '08

08 Aug '08

Hello, the following code makes the VC++ compiler (VS 2005) crash, but only when I am trying a release build ! The debug builds work fine. std::sort(l_vec.begin(),l_vec.end(),boost::bind(std::less<int>(),boost::bind(&CLayer::GetPrio,_1),boost::bind(&CLayer::GetPrio,_2))); Where CLayer::GetPrio returns an integer. Best regards, Oliver

6 11

[date_time] apparently still unfixed problem
by Ruediger Berlich 08 Aug '08

08 Aug '08

Hi there, from what I can see, neither the trunk nor the release branch of the upcoming 1.36 release have applied a fix to an issue in the date_time library, that was raised twice on the Boost mailing lists (once by Lothar Werzinger, once by me) and also submitted via the bug tracker (#2091). It is currently not possible to compile date_time-based programs with gcc 4.3.1 without applying a (slight) modification to a date_time header. I would assume that the problem appears with other gcc 4.3-compilers as well (at least Fedora Core 9 and OpenSUSE 11 use 4.3.x compilers). Lothar suggested an easy fix which, from what I can see, could not have any side-effects. It suffices to change line 161 of the file <Boost-Root>/boost/date_time/tz_db_base.hpp from typedef dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets; to typedef boost::date_time::dst_adjustment_offsets<time_duration_type> dst_adjustment_offsets; This change will affect two occurances of dst_adjustment_offsets in the same function only. Could this still be applied to the release candidate ? It would help a lot! In any case thanks, Ruediger

1 0