June 2008 - Boost-users - lists.boost.org

[Boost-users] [Boost-users] wave - help compile to list_includes sample.
by 신영일 24 Jun '08

24 Jun '08

Hi, all. I tring compile list_includes sample code with VS2008 CF. but, compiled. first of all, modify to wave/samples/list_includes/build/Jamfile.v2. SOURCES = ../list_includes.cpp ../instantiate_cpp_exprgrammar ../instantiate_cpp_grammar ../instantiate_cpp_literalgrs ../instantiate_defined_grammar ../instantiate_lexertl_lexer ; I was modify from ../list_includes.cpp to ../list_includes of second line. It's right? after, I tring to line_includes sample compiling. Enter to >bjam --build-dir=C:\boost1.35 but, not compiled with below errors. How to solve this problem? Help me... pleeeeeeez. ~~~ ...patience... ...patience... ...found 1441 targets... ...updating 1 target... msvc.link C:\boost1.35\boost\bin.v2\libs\wave\samples\list_includes\build\msvc-9 .0\debug\list_includes.exe Creating library C:\boost1.35\boost\bin.v2\libs\wave\samples\list_includes\bu ild\msvc-9.0\debug\list_includes.lib and object C:\boost1.35\boost\bin.v2\libs\w ave\samples\list_includes\build\msvc-9.0\debug\list_includes.exp list_includes.obj : error LNK2001: unresolved external symbol "public: static un signed int const boost::program_options::options_description::m_default_line_len gth" (?m_default_line_length@options_description@program_options@boost@@2IB) list_includes.obj : error LNK2001: unresolved external symbol "class std::basic_ string,class std::allocator > boost::pr ogram_options::arg" (?arg@program_options@boost@@3V?$basic_string@DU?$char_trait s@D@std@@V?$allocator@D@2@@std@@A) list_includes.obj : error LNK2019: unresolved external symbol "public: static st ruct boost::wave::cpplexer::lex_input_interface,class std::allocator,class boost::w ave::util::CowString >,char *> > > > > * __cdecl boost::wave::cpplexer::lexertl: :new_lexer_gen,cl ass std::allocator >,struct boost::wave::util::file_position,class std::allocator< char>,class boost::wave::util::CowString >,char *> > > >::new_lexer(class std::_ String_iterator,class std::allocator > const &,class std::_String_iterator,class std ::allocator > const &,struct boost::wave::util::file_position,class std::allocator ,class boost::wave::util::CowString >,char *> > > const &,enum boost::wave ::language_support)" (?new_lexer@?$new_lexer_gen@V?$_String_iterator@DU?$char_tr aits@D@std@@V?$allocator@D@2@@std@@U?$file_position@V?$flex_string@DU?$char_trai ts@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@ D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost @@@lexertl@cpplexer@wave@boost@@SAPAU?$lex_input_interface@V?$lex_token@U?$file_ position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$ AllocatorStringStorage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boos t@@@util@wave@boost@@@util@wave@boost@@@cpplexer@wave@boost@@@345@ABV?$_String_i terator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0ABU?$file_position@V?$fle x_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorString Storage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@b oost@@@util@45@W4language_support@45@@Z) referenced in function "public: static struct boost::wave::cpplexer::lex_input_interface,class std::allocator,class boost: :wave::util::CowString >,char *> > > > > * __cdecl boost::wave::cpplexer::lexert l::lexertl_input_interface,class std::allocator,class boost::wave::util::CowString< class boost::wave::util::AllocatorStringStorage >,char *> > > > >::new_lexer,class std::allocator > >(class std::_String_iterator,class std::allocator > const &,class std::_Strin g_iterator,class std::allocator > const &,struct boost::wave::util::file_position,class std::allocator,class boost::wave: :util::CowString >,char *> > > const &,enum boost::wave::language_support)" (??$ new_lexer@V?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$l exertl_input_interface@V?$lex_token@U?$file_position@V?$flex_string@DU?$char_tra its@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator @D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boos t@@@cpplexer@wave@boost@@@lexertl@cpplexer@wave@boost@@SAPAU?$lex_input_interfac e@V?$lex_token@U?$file_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocat or@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@D@std@@@util@wave@bo ost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost@@@cpplexer@wave@boo st@@@234@ABV?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0AB U?$file_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowSt ring@V?$AllocatorStringStorage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@w ave@boost@@@util@wave@boost@@@util@34@W4language_support@34@@Z) C:\boost1.35\boost\bin.v2\libs\wave\samples\list_includes\build\msvc-9.0\debug\l ist_includes.exe : fatal error LNK1120: 3 unresolved externals call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DEBUG /subsystem:console /out:"C:\boost1.35\boost\ bin.v2\libs\wave\samples\list_includes\build\msvc-9.0\debug\list_includes.exe" @"C:\boost1.35\boost\bin.v2\libs\wave\samples\list_includes\build\msvc-9.0\debu g\list_includes.exe.rsp" if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL% if exist "C:\boost1.35\boost\bin.v2\libs\wave\samples\list_includes\buil d\msvc-9.0\debug\list_includes.exe.manifest" ( mt -nologo -manifest "C:\boost1.35\boost\bin.v2\libs\wave\samples\li st_includes\build\msvc-9.0\debug\list_includes.exe.manifest" "-outputresource:C: \boost1.35\boost\bin.v2\libs\wave\samples\list_includes\build\msvc-9.0\debug\lis t_includes.exe;1" ) ...failed msvc.link C:\boost1.35\boost\bin.v2\libs\wave\samples\list_includes\bu ild\msvc-9.0\debug\list_includes.exe... ...failed updating 1 target...

1 0

MPL: Possible bug related to for_each and numbered vectors
by Martin Apel 23 Jun '08

23 Jun '08

Hi all, I stumbled across something very strange related to boost::mpl::for_each and numbered vectors and sets (as opposed to the variadic forms). The program below contains a typelist with 21 (i.e. more than BOOST_MPL_LIMIT_SET_SIZE) classes. This typelist is converted to a typelist containing pointers to those classes. Finally the main program calls for_each with that typelist to print the names of the types. This works without problems on Linux and Windows. But now: If you remove the include "boost/mpl/vector/vector30.hpp" everything still compiles fine without warnings under both operating systems. On Linux everything continues to work, whereas under Windows nothing is printed anymore. for_each does not loop through the typelist for an unknown reason. Everything works again, when reducing the number of classes to 20 (and adjusting the include to set20.hpp). From my understanding BOOST_MPL_LIMIT_SET_SIZE and its brothers and sisters should not have any impact on numbered sequences, only on variadic ones. But still it looks as if something very strange is happening here. Any comments are welcome, Martin #include <iostream> #include "boost/mpl/vector/vector30.hpp" #include "boost/mpl/set/set30.hpp" #include "boost/mpl/for_each.hpp" #include "boost/mpl/transform.hpp" #include "boost/mpl/inserter.hpp" #include "boost/mpl/vector.hpp" #include "boost/type_traits/add_pointer.hpp" class C1; class C2; class C3; class C4; class C5; class C6; class C7; class C8; class C9; class C10; class C11; class C12; class C13; class C14; class C15; class C16; class C17; class C18; class C19; class C20; class C21; typedef boost::mpl::set21<C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11, C12, C13, C14, C15, C16, C17, C18, C19, C20, C21 > ElementClasses; typedef boost::mpl::transform<ElementClasses,boost::add_pointer<boost::mpl::_1>, boost::mpl::inserter<boost::mpl::vector0<>, boost::mpl::push_back<boost::mpl::_1, boost::mpl::_2> > >::type ElementClassesAsPointer; class Test { public: Test(void) { boost::mpl::for_each<ElementClassesAsPointer> (*this); } template<class T> void operator() (T x) { std::cout << "Operator() called for type " << typeid(T).name() << std::endl; } }; int main(void) { Test test; } ____________ Virus checked by G DATA AntiVirus Version: AVKA 18.302 from 18.06.2008 Virus news: www.antiviruslab.com

3 4

[graph] depth_first_search with VertexList=listS
by Tim Blechmann 23 Jun '08

23 Jun '08

hi all, the following trivial code doesn't compile for me: #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> typedef boost::adjacency_list<boost::vecS, boost::listS > graph_t; int main() { graph_t graph; boost::depth_first_search(graph, boost::visitor(boost::dfs_visitor<> ())); } is there any way to run a depth_first_search, with an adjacency_list based graph class, using a VertexList=listS or setS? thanks, tim -- tim(a)klingt.org http://tim.klingt.org Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac

2 1

[serialization] assert loading shared_ptr to abstract base class using boost 1.35.0
by Ult Mundane 23 Jun '08

23 Jun '08

Hi there, Using the boost::serialization library, I'm hitting an assert while deserializing. It happens only in a specific set of circumstances requiring a shared_ptr to an abstract base class. Class "Derived" is derived from class "AbstractBase" which is abstract. I'm serializing two objects which are of type shared_ptr<AbstractBase> that point to objects of type Derived. After the two shared_ptr's are serialized to disk, when I read them back in I hit an assert in basic_iarchive.cpp: "Assertion `new_cid == cid' failed". This assert happens on the second object only. As far as I can tell from the serialization documentation, I am using the appropriate BOOST_CLASS_EXPORT() line for the derived class, as well as registering the base-derived relationship with base_object(), and I even threw in a couple of BOOST_SERIALIZATION_SHARED_PTR() calls for good measure although I don't think they do anything in my environment. Two additional pieces of information: - If the base class is not abstract, but I still use BOOST_IS_ABSTRACT(), I get the same assert. This might indicate that some necessary polymorphism code isn't being generated as a result of declaring the class abstract. - If I serialize the pointers directly instead of using shared_ptr, it does not hit the assert. I have a workaround for this problem: it works as expected if I define the load_construct_data() template function for the base class do to nothing (assert), instead of using the BOOST_IS_ABSTRACT() macro. Attached is the minimal code to reproduce the problem. I'm using boost 1.35.0 with gcc 3.3.5 on Linux (RHEL4). Is there something I'm missing to make this work? Thanks in advance, Ult #include <fstream> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/serialization/export.hpp> class AbstractBase { public: AbstractBase() : mInt(-1) { } virtual ~AbstractBase() { } virtual void func() const = 0; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar & mInt; } int mInt; }; BOOST_IS_ABSTRACT(AbstractBase); BOOST_SERIALIZATION_SHARED_PTR(AbstractBase); BOOST_CLASS_IMPLEMENTATION(AbstractBase, boost::serialization::object_serializable); class Derived : public AbstractBase { public: Derived() : mInt2(-2) { } void func() const { } template<class Archive> void serialize(Archive & ar, const unsigned int) { ar & boost::serialization::base_object<AbstractBase>(*this); ar & mInt2; } int mInt2; }; BOOST_CLASS_EXPORT(Derived); BOOST_SERIALIZATION_SHARED_PTR(Derived); BOOST_CLASS_IMPLEMENTATION(Derived, boost::serialization::object_serializable); int main(int /* argc */, char * /* argv */[]) { char const * fname = "abstract.out"; boost::shared_ptr<AbstractBase> baseA(new Derived()); boost::shared_ptr<AbstractBase> baseB(new Derived()); { std::ofstream ofs(fname, std::ios::out | std::ios::binary); boost::archive::text_oarchive oa(ofs); oa & baseA; oa & baseB; } { std::ifstream ifs(fname, std::ios::in | std::ios::binary); boost::archive::text_iarchive ia(ifs); ia & baseA; std::cout << "The following line asserts:" << std::endl; ia & baseB; // Assertion `new_cid == cid' failed // Full text of assert: // // /dev/libs/boost_1_35_0/libs/serialization/src/basic_iarchive.cpp:432: const boost::archive::detail::basic_pointer_iserializer* boost::archive::detail::basic_iarchive_impl::load_pointer(boost::archive::detail::basic_iarchive&, void*&, const boost::archive::detail::basic_pointer_iserializer*, const boost::archive::detail::basic_pointer_iserializer*(*)(const boost::serialization::extended_type_info&)): Assertion `new_cid == cid' failed. } }

1 0

[xpressive] Can I use boost.xpressive with ARM processor (iPhone)?
by Igor Mikushkin 23 Jun '08

23 Jun '08

Hello! Could anyone tell me if s/he has an experience of using boost.xpressive with ARM processor. I work on iPhone project and want to make parsing using that library. I will compile with GCC. Thanks. Best Regards. Igor Mikushkin

2 1

Re: [Boost-users] boost shared_ptr and parent child relation ships
by Richard L. Aurbach 23 Jun '08

23 Jun '08

On Jun 20, 2008, at 8:38 AM, gast128 wrote: > Dear all, > > maybe this an off-topic issue, because it does not directly relate to > shared_ptr and is more related to life time of objects and their > validity > during construction and destruction. > > There were the following issues: > 1) childs validity depends on availability of parent and vise versa > 2) in ctor one can not use the shared_from_this() > 3) in destructor of the child the parent shared_ptr was inaccesible > > ad 1) the doc's are clear: you can not make a cycle in shared_ptrs > between > parent -> child and child -> parent. Thus now we use a weak_ptr for > child -> > parent, but actually the child can not exist without parent. So if > one shares > a child through a shared_ptr, a hypothetical situation could exist > that its > parent get destroyed, but a child lifes on (in an invalid state due > to missing > parent) because a client has requested it. > > ad 2) this is quite unhandy, since I thought it would be handy to > let the > parent create the childs passing itself. I think this can only be > solved by > two way construction. > > This may well turn out to be a fundamental problem. Consider two > classes A and > B which are associated with each other. Object of class A is valid > when it is > valid itself and when its associated object of class B is valid. > When A gets > changed it is temporalily invalid. It updates first B, but if B asks > services > from A during that call, it asks an invalid object. Reversing the > order may > help, but A may have to update itself again after it calls B. For > two related > classes it can be overseen, but of course real life applications > have 1000 or > more classes. Btw to some extend Bertrand Meyer's book touches this > subject, > but he only mentions the problem within a class (with public and > private > members). > > ad 3) the destructor of the child needed the parent to call another > class. > However the parent was inaccessible because it was destroyed itself. > This is > of course also a fundamental problem because when an object gets > destroyed not > all of its members may be valid (the parent object is in an invalid > state), so > calling the parent at that time was questionable too. The real > problem was > that it needed form the parent its parent which was still valid, > solutions are > obvious (but ugly) > > Sample code: > > struct Child; > struct Parent; > > struct Child > { > Child(boost::shared_ptr<Parent> ptrParent) > { > m_ptrParent = ptrParent; > } > > ~Child() > { > boost::shared_ptr<Parent> ptrParent = m_ptrParent.lock(); > if (ptrParent) > { > //never come here > } > } > > boost::weak_ptr<Parent> m_ptrParent; > }; > > struct Parent : public boost::enable_shared_from_this<Parent> > { > Parent() > { > //won't work: > //m_ptrChild.reset(new Child(shared_from_this())); > } > > boost::shared_ptr<Child> m_ptrChild; > }; > > > void TestParentChild() > { > boost::shared_ptr<Parent> ptrParent(new Parent); > ptrParent->m_ptrChild.reset(new Child(ptrParent)); > } > > wkr, > me When I use shared_ptr and weak_ptr in parent/child relationships, I tend to take a different tack. First of all, I like to use the concept of a "master" shared_ptr. That is, I attempt to design my architectures so that there is one shared_ptr which persists for the lifetime of the object being pointed to; other shared_ptrs are transient, in that they persist for a shorter period of time (typically which a particular piece of work is being performed). To pursue the metaphor, the "master" shared_ptr holds its object in existence. It is the pointer which (when reset) ultimately causes the object to be deleted. Using this concept, my parent object holds the master shared_ptr of its child. (Typically there are multiple children and their master shared_ptrs are stored in a vector.) The child holds a weak_ptr to its parent. In my work, typically both parent and child inherit from enable_shared_from_this. The "trick" is to treat the parent-child relationship seriously. Since child objects do not exist except in the context of a parent, it is logical to create a function member of the parent which is responsible for creating the child and establishing linkages. (Or, if this needs to occur elsewhere, the child is constructed by some other [third- party] object's member function which creates the child and links the child and parent together.) It should not be necessary to construct the child in the parent's constructor, nor should it be necessary to establish linkages with the parent in the child's constructor. The problems you are concerned about need not exist. As long as the construction of the child and its linkage to its parent occur in a single member-function, it should not be necessary for either the parent's or the child's constructor to be responsible for establishing the linkage. Cheers, Rick Aurbach, Ph.D. President and Chief Engineer Aurbach & Associates, Inc. 8233 Tulane Avenue, Suite B St. Louis, MO 63132 www: http://www.aurbach.com/ eMail: support(a)aurbach.com [business] rick(a)aurbach.com [personal] Fax: 314/678-0869 Phone: 800/774-7239 314/726-1321 "If it ain't broke and you haven't fixed it recently, it probably needs to be rewritten." - Richard Aurbach (1948- ) "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth, computer scientist (1938- ) "If in the last few years you haven't discarded a major opinion or acquired a new one, check your pulse. You may be dead." - Gelett Burgess (1866-1951) "A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing." - George Bernard Shaw (1856-1950) "It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong." - Richard Feynman (1918-1988) "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." - Nathaniel Borenstein (1957-)

2 1

Re: [Boost-users] boost shared_ptr and parent child relation ships
by Lang Stefan 23 Jun '08

23 Jun '08

-----Ursprüngliche Nachricht----- On Jun 20, 2008, at 8:38 AM, gast128 wrote: > Dear all, > > maybe this an off-topic issue, because it does not directly relate to > shared_ptr and is more related to life time of objects and their > validity > during construction and destruction. > > There were the following issues: > 1) childs validity depends on availability of parent and vise versa > 2) in ctor one can not use the shared_from_this() > 3) in destructor of the child the parent shared_ptr was inaccesible > > [snip] 1) If you have cyclic dependencies parent<->child (or other), the design is wrong (see below for a solution) 2) If you mean using a shared pointer from your parent class to hand to your child - you shouldn't be using shared_ptr in the first place. A shared_ptr implies you have the means and the right to destroy the object! A weak_ptr is all you need. 3) If a child needs sth the parent can supply, then make it accessible through another class (see below) The basic solution to cyclic dependencies of classes is extracting parts of one class into another and have the original class (minus those parts) inherit from it. Here's a short example: // original structure: class B; // forward decl class A { public: ~A(); void someService(); private: B* myChild; }; A::A() : myChild(new B(this)) { } A::~A() { delete myChild; } class B { public: B(A*); ~B(); private: A* myParent; }; B::B(A* parent) : myParent(parent) { } B::~B() { myParent->someService(); // problem: if called during destruction, myParent may be invalid! } // suggested structure: class B; // forward decl class C { public: void someService(); } class A : public C { public: ~A(); private: B* myChild; }; A::A() : myChild(new B(this)) { } A::~A() { delete myChild; } class B { public: B(C*); ~B(); private: C* myServiceProvider; }; B::B(C* sp) : myServiceProvider(sp) { } B::~B() { myServiceProvider->someService(); // no problem! } Please note that even if A may be invalid during destruction, it's base class C is still valid as long as A's destructor isn't finished! Hope this helps, Stefan P.S.: I didn't bother with shared pointers in my example, but since cyclic dependencies are an independent problem you can just choose to use shared pointers instead (or not).

1 0

Calculating needed space for Boost.Serialization
by Ioannis Papadopoulos 23 Jun '08

23 Jun '08

Hi, I want to calculate exactly how much space it is needed to serialize a number of objects. What I'm thinking is another class that implements the Saving Archive concept and only invokes sizeof() rather than actually writing anything. From what I understand I should overload the << and & operators for this class to call save() or serialize() on the object, unless it is a POD (in which case the size is already known). Has this been done before? Thanks

1 1

Boost.Serialization and size of archive
by Ioannis Papadopoulos 23 Jun '08

23 Jun '08

Hi, Is there any means of obtaining how big my archive will be before actually serializing? Something like a special boost::archive that will count the size of what I'm serializing. I'm mainly concerned on allocating exactly the space I'll be needing for binary_oarchives. I guess I should follow the SA concept (since I'm trying to find the size before saving) but how can I know any extra overhead? Thanks

6 7

Boost libraries on Mac OS (Leopard)
by Dave Mazzoni 22 Jun '08

22 Jun '08

I'm trying to get the threads library to link. I've built all the libraries using bjam (--toolset=darwin) and they are in /usr/local/lib (e.g., libboost_thread-mt-1_35.dylib). However, when I execute this (from make, but this is the crux): g++ -funsigned-char -I ~/Desktop/Work/boost_1_35_0/ main.cpp -L /usr/local/lib -lboost_thread-mt-1_35 -t -pthread -o lock_free it fails with this output: In file included from /usr/include/c++/4.0.0/backward/strstream:51, from enforce.h:10, from main.cpp:5: /usr/include/c++/4.0.0/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated. *ld: in /usr/local/lib, can't map file, errno=22 /usr/lib/crt1.10.5.o collect2: ld returned 1 exit status* make: *** [lock_free] Error 1 Any ideas? At first I thought it was a boost library error, but then I added the -t linker option and the /usr/lib/crt1.10.5.o showed up. Thanks in advance -

1 0