- Boost-users - lists.boost.org

How to run the boost.python example
by Olga Gerchikov 11 Jan '06

11 Jan '06

Hi, how can I run the boost.python example? >From the README, I did this: ~/src/boost_1_33_1/libs/python/example bjam -sTOOLS=gcc test But please tell me what is the next step?

1 0

[lambda] Understanding ->*
by David Greene 11 Jan '06

11 Jan '06

I'm debugging some even nastier lambda compiler error messages (not sure if I can reduce to a testcase but I'll try). In the course of figuring this out, I relized that I need to understand the similarities and/or differences between bind operations and ->* in a lambda context. What is the difference between these two: class Class { public: int member_func(void); }; bind(&Class::member_func, _1) == 1 (_1 ->* &Class::member_func) == 1 used in the context of std::find_if(seq.being(), seq.end(), <lambda-func>); Does the second construct make sense in this case? I don't think it does because member_func takes no arguments. Because the ->* expression must be followed immediately by an argument list, there is no way to delay the substitution of the object on which to call member_func. This, I believe, it what bind is for. That is, ->* only delays application of n-1 arguments, where n is the total arity of the function (including the hidden "this" parameter). Bind is able to delay application of all n arguments. Is this analysis correct? -Dave

2 1

Re: [Boost-users] Pyste/Pyplusplus/Boost documentation problems
by Nat Goodspeed 11 Jan '06

11 Jan '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Drumheller, Michael > Sent: Wednesday, January 11, 2006 1:18 PM > To: c++-sig(a)python.org; boost-users(a)lists.boost.org > Subject: [Boost-users] Pyste/Pyplusplus/Boost documentation problems > > As a side question, does anyone use Boost.Python *without* an automatic > code generator such as Pyste or Pyplusplus? [Nat] We do. > It does not seem like a > practical thing to do--but maybe I'm missing something...? [Nat] Heh, maybe we should have paid more attention to Pyste when we got started, but we just kept growing the hand-coded prototype module.

1 0

Re: [Boost-users] Boost Serialization: extended_type_info_no_rtti not working...
by RIVASSEAU Jean Noel 11 Jan '06

11 Jan '06

Hello I get the exception for the derived class - not the base class. Yes, I have done everything correctly for both the base and derived class. After reading your mail, I have several questions: You recommend to include the archives headers once in the executable. This seems strange; I need to include them in many .cpp files (everytime I want to *call* serialization code). This is why I've included serialization code in the .cpp files and not the headers, in order to avoid multiple definitions. Of course, if you include the archive files only once in your executable, I understand that you can put all serialization code in the headers. But being able to include archive headers only once will require me to do quite a bit of code reorganization I think (every function that needs to call serialization has to be put in the same file... even if they are member functions belonging to different classes etc... I do not understand how you can achieve this without a big mess). If, like I did, you include serialization code only in the .cpp files, you avoid multiple definitions problems, since the code is only instantiated for each class during the compile of the .cpp. Of course, the disadvantage is that you must include the archive headers in each class that you want to serialize, before the export.hpp. And the second problem is that at run time it does not work (the problem I am reporting). This is strange. I found yesterday a way to avoid my problem. If I put all the serialization code in the *same* .cpp file, and compile that file, everything works fine. This means that the derived class is properly registered only if during the compilation of the same unit, the code corresponding to the base class is also instantiated. If you instantiate "separately" the serialization code for the base class and the derived class, it does not work. This is probably a bug, but only you can tell since you know the implementation (and with your way of organizing your code, you probably never ran into this problem). In fact, I think I will maybe keep this workaround (one special .cpp file with all the serialization code for all my classes) since it has several advantages (one is that I am independent of any archive implementation, as I only need to change the headers in that only .cpp file ). Thank you, I am waiting for your reply on these remarks. Jean-Noël For which class do you get this exception? But I have done the following: in all my classes, in the implementation unit (.cpp) I have included explicitely the headers needed for the archives I use: #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> Then I have something like that in each class: #include <boost/serialization/base_object.hpp> #include <boost/serialization/type_info_implementation.hpp> #include <boost/serialization/extended_type_info_no_rtti.hpp> #include <boost/serialization/export.hpp> namespace boost { namespace serialization { template<class Archive> void serialize(Archive & ar, PrimitiveMemberVariableSpecification & m, const unsigned int version) { ar & boost::serialization::base_object<MemberVariableSpecification>(m); ar & m.unused_primitive_type; } } // namespace serialization } // namespace boost BOOST_CLASS_TYPE_INFO( PrimitiveMemberVariableSpecification, extended_type_info_no_rtti<PrimitiveMemberVariableSpecification> ) BOOST_CLASS_EXPORT(PrimitiveMemberVariableSpecification) (Here the name of the class is PrimitiveMemberVariableSpecification. Is the above being done for the base class as well? I also want to report a bug in the documentation: the doc says that you should write: <skip> correct - good call. Normally the BOOST_CLASS_EXPORT should *register* all my classes. Why doesn't it work? I have of course also written a correct get_key() virtual function for all my classes. If I just change extended_type_info_no_rtti to extended_type_info_typeid, everything works fine, but I do want extended_type_info_no_rtti. This suggests that all derived classes are being exported. Also, keeping everything in the headers files seems to be a nightmare, although that is what Robert Ramsey recommends. I get tons of multiple definitions errors at link time if I do that (something like: multiple definition of `boost::archive::detail::guid_initializer<MemberVariableSpecification>::instance' with gcc - MinGW 3.4.2) This would surprise me. It suggests that boost/archive/...archive.hpp files are being included in several places. In order to avoid the bothersome warnings above and speed build time. I try to organize my code so that non-inline code is instantiated in only one place. This is not strictly a requirement but generally I've found that things work better this way. And I'm not just referring to serialization code but C++ template code in general. In theory, it shouldn't matter, but in practice things work better this way. So what works well for me is: Include serialization code in the headers corresponding to each type. That way all if the types are imported into different executables they are all all consistent with each other. include boost/archive/... headers only once in each executable. This will eliminate multiple definition errors. This might take a little bit of code re-organization and should not be strictly necessary - but it has worked well for me. Generally I also recommend that any boost/archive/...hpp headers be included before any boost/serialization/...hpp headers. This is not strictly necessary - though it was at one time - but I'm in the habit of doing it. If I find I can't do it, I'm wondering if I "accidently" included a boost/archive/....hpp in another header - which can lead to multiple definition warnngs. Also if I do this an import the module into another executable, I might be instantiating code that isn't called. By sticking to the "rules of thumb" above, I generally avoid some problems and or surprises. Note that there are couple of cases where header order does make a difference. a) boost/serialization/export.hpp has to follow all the boost/archive/...hpp files for each combination of type/archive export to be instantiated. b) boost/serialization/base_object.hpp has to follow all the boost/archive/*.hpp files. This is an oversight which will be corrected in the next version. I have looked at the documentation for two days, read absolutely everything and still do not understand. Maybe I should look at the code ??? LOL - if you like the documentation - you'll love the code ! But, trapping the exception will tell you which class isn't being "registered" which will be helpful information. Robert Ramey

2 1

Re: [Boost-users] [serialization] [wave] [spirit] Can't compile boost cvs
by Peter Whaite 11 Jan '06

11 Jan '06

Joel de Guzman <joel(a)boost-consulting.com> wrote: > > Ok, confirmed. I'm the culprit :( Someone submitted a patch > for the is* functions to work on other POD types. Hartmut is > reverting it now while I try to find a fix. OK thanks it compiles now. I'm still surprised this wasn't reported earlier as serialization seems to be one of the more popular libs.

1 0

BOOST_STATIC_ASSERT is not compiled
by OSA 11 Jan '06

11 Jan '06

Look at example code: class CBase { public: virtual ~CBase(){} virtual void foo()const = 0; }; template <class T> class CTest { private: BOOST_STATIC_ASSERT((boost::is_base_of<CBase,T>::value_type)); public: CTest(){} void what()const { } }; class CDerived : public CBase { CTest<CDerived> m_a; public: CDerived(){} virtual void foo()const{m_a.what();} }; int main(int argc, _TCHAR* argv[]) { CDerived d; d.foo(); return 0; } I am using the BOOST_STATIC_ASSERT to make sure the template parameter of the CTest class is inherited from some specific class (in particular CBase in this example). But this code is not compiled. I am using Visual C++ 7 compiler. What is my error?

2 1

[lambda] Binding template functions
by David Greene 11 Jan '06

11 Jan '06

Is it possible to bind template functions? If so, what's the syntax? I'm having trouble with this test: #include <boost/lambda/bind.hpp> #include <boost/numeric/interval.hpp> #include <vector> #include <cassert> typedef boost::numeric::interval<int> range; std::vector<range> ranges; int main(void) { using boost::lambda::bind; using boost::lambda::_1; int range_base = 0; int range_limit = 9; for(int i = 0; i < 10; ++i) { ranges.push_back(range(range_base, range_limit)); range_base += 10; range_limit += 10; } std::vector<range>::iterator i = std::find_if(ranges.begin(), ranges.end(), bind(&boost::numeric::template in<range>, 5, _1)); // bind(&boost::numeric::in<range>, 5, _1)); // bind(&boost::numeric::in, 5, _1)); assert(i == ranges.begin()); return(0); } None of the commented options works, either. I wouldn't expect the last one to work. They all fail with the same error trace: lambda.cc: In function `int main()': lambda.cc:27: error: no matching function for call to `bind(<unknown type>, int, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >&)' Any ideas? -Dave

3 3

Smart pointer library in boost
by Olga Gerchikov 11 Jan '06

11 Jan '06

Suppose I have this function in c++: int* f(int size) { int * array = new int[size]; return array; } Is there a safe idiom to prevent memory leak? Should i use auto_ptr in C++? Or should I use the smart pointer library in boost? Which is the simplest solution? Thank you.

3 2

[Boost.Build][program_options] Problem with path length
by Ames Andreas 11 Jan '06

11 Jan '06

Hi all, I have a problem with building program_options on VC 7.1. It is only related to program_options in that this is one of the boost libs with the longest names. The problem is the path length of files generated during build. As an example, there is a file generated with the name bin/boost/libs/program_options/build/libboost_program_options.lib/vc-7_1/debug/native-wchar_t-off/threading-multi/libboost_program_options-vc71-mt-gd-1_33.CMD which amounts to 158 characters in length. As the path to the leading bin directory is already 100 characters long, I cannot build (max. 254 characters on NTFS). Besides shortening the preceding path, is there any other solution (like customizing the generated path)? TIA, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | andreas . ames AT comergo . com

2 1

Re: [Boost-users] Cross compiling boost libraries with gcc and us ing boost jam to crosscompile third-party library (Jambase problem)
by James Hughes 11 Jan '06

11 Jan '06

> -----Original Message----- > From: Vladimir Michl [mailto:vladimir.michl@seznam.cz] > Sent: 11 January 2006 13:09 > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Cross compiling boost libraries > with gcc and > us ing boost jam to crosscompile third-party library (Jambase problem) > > > On Wed, 2006-01-11 at 11:25 +0100, James Hughes wrote: > > I had the same problem in the same circumstance. Just > hacked mine to call > > the correct objcopy. > > > > Did you get the whole boost system to build cleanly - I am > still seeing > > problems (although a very recent post may have explained why) > > I was compiling boost 1.32, may be this is reason why it worked. > > Vlad My build is 1.33, which may be the cause of the fault as indicated by another post today. Thanks for the info - I don't have -D_REENTRANT, so will try that anyway. James

1 0