May 2009 - Boost-users - lists.boost.org

[wave] assertion failed - multithread issue?
by Ein Held 23 May '09

23 May '09

Hello when parsing some cpp files via boost.wave using multiple threads, I randomly get a failed assertion. "Assertion failed: static_cast<RefCountType>(*d.begin()) != 0, file C:\projekte\libs\boost\include\boost-1_38/boost/wave/util/flex_string.hpp, line 1216" I am pretty sure that this is a multi-thread issue, as when using only one thread to parse the files, everything works fine. Unfortunately I cannot give you more specific information as I cannot get gdb to run on my system. I am using gcc 4.3.3 Thank you

2 2

Design for boost::serialization of STL iterators.
by Carlo Wood 23 May '09

23 May '09

On Sat, Mar 11, 2006 at 11:45:36PM +0200, Peter Dimov wrote: > Carlo Wood wrote: > > > 1) WHY does boost::serialization not support serialization > > of iterators? > > It's very hard, if not impossible, in general. It is either impossible or possible. When it is possible, it can't be hard :p I think that at the moment of serialization, the actual container needs to be known. So, only concentrating on the syntax of the code that serializes an iterator, the following cannot work: ar & iter; However, the container will be known at that point (or at least, we might as well assume that). Therefore, I could imagine a syntax like: ar & foobar(container, iter); where 'foobar' is some template function (that will be part of boost::serialization in the future). Lets start with the last one (have to start somewhere). In order to deserialize the iterator (and taken into account that we already have the container) -- which makes me think that it might be better to pass a functor to operator& above. In other words, (at least for writing), use: template<class Container> struct Foobar { Foobar(Container const&, typename Container::const_iterator& iter) : M_container(container), M_iter(iter); private: Container const& M_container; Container::const_iterator& M_iter; }; and then assign to M_iter, whatever we find in M_container. > If you have access to the container to which the iterator i refers: > > a) if the container is a map, you can serialize i->first, then on > deserialization look up the key in the map using .find(); > > b) if the container is a sequence, and it has the same contents on > deserialization as it does on serialization, you can serialize the index of > the element - distance( c.begin(), i ). I don't think that it is a requirement that the whole container has to be read: either it's a map or set, in which case later insertions will not invalidate the container, or it is a vector, in which case we use an index, from which we can construct the end iterators before the whole container is reconstructed. Therefore, the following syntax can work imho: ar & FooBar(container, iter); Would you agree? There are a zillion questions and implementation details open - but I'd like to get anyones feedback about this type of interface for iterators before continuing. Current questions: What is a good name for Foobar? Am I right when I think that Foobar needs to be declared in boost::serialization? Now the hard part (for me) is that part that involves the internals of the boost library. At the moment one tries to serialize an iterator, it is possible (though not necessarily) that the object that the iterator points to is already serialized. In the case that we are dealing with an associative container (map or set etc), we don't want to store the contents of the object (or key part, in the case of a map) again: I'd like to just store that once, and store a reference in the archive at the other place. How can I make the library store an object only the first time and the store a reference the second time? This would be for an object of arbitrary type thus. I think that it is only feasible to do this when it's actually the same object (same memory address), which is the case; but while storing the object element of the container, the address of it isn't stored as well, is it? Is there a way to make: std::set<SomeData> s; [...] ar << s; Store the address of s (&s) along with the contents of s? And would that then automatically cause the library to not store that same object again when I do: std::set<SomeData>::iterator iter = s.find(...); [...] ar << *iter; Because then, &*iter would again be the same memory address as what was stored before. -- Carlo Wood <carlo(a)alinoe.com>

3 2

[BGL] Is it possible to control algorithm's behavior by visitor?
by Li Ning 23 May '09

23 May '09

In some complex application, I need to control algorithm's behavior according to edge's property. It seems all visitor are used to "visit" the predefined place in a algorithm but it can not "control". All functions in visitor has void return type, so it can't give algorithm anything. Why there is no STL-like functor which can control algorithm's behavior? -- View this message in context: http://www.nabble.com/-BGL--Is-it-possible-to-control-algorithm%27s-behavio… Sent from the Boost - Users mailing list archive at Nabble.com.

4 11

date_time question
by Amadeus W.M. 23 May '09

23 May '09

I have a file with tab separated entries like this: 1230735660 12/31/2008 10:01:00 8.94 277880 1230735729 12/31/2008 10:02:09 8.95 279693 1230735791 12/31/2008 10:03:11 8.95 284743 etc. I don't assume which column represents the date so I read one line at the time and test each token if it's a date in the format "%m/%d/%Y %H:%M:%S". However, when I process the first token (1230735660) date_time thinks it's a date in my format and returns 5660-Dec-07 00:00:00 How come? It seems to think that 3 is a separator. Could anyone please shed some light? Thanks! Here is a short program that exemplifies the problem: // g++ -g -Wall -o dateIO -I/usr/local/include/boost-1_38 -L/usr/local/ lib/ dateIOTest.C -lboost_date_time-gcc43-mt-1_38 #include <iostream> #include <sstream> #include <cstdlib> #include <string> #include <boost/date_time/posix_time/posix_time.hpp> using namespace std; using namespace boost::posix_time; int main(int argc, char * argv[]) { ptime pt; string datestr("1230735660"); istringstream INSTR(datestr); time_input_facet * tifacet=new time_input_facet("%m/%d/%Y %H:%M:%S"); locale loc(INSTR.getloc(),tifacet); INSTR.imbue(loc); INSTR >> pt; cout << pt << endl; return 0; }

1 0

Including Xutil.h on Fedora breaks BOOST_FOREACH
by Tron Thomas 22 May '09

22 May '09

Compiling this: #include <X11/Xutil.h> #include <boost/shared_ptr.hpp> #include <vector> #include <cstdlib> #include <boost/foreach.hpp> #include <iostream> using std::ostream; class Value { public: explicit Value(int amount) : m_amount(amount) {} void WriteTo(ostream& stream) const { stream << m_amount; } private: int m_amount; }; ostream& operator <<(ostream& stream, const Value& value) { value.WriteTo(stream); return stream; } int main() { typedef boost::shared_ptr<Value> ValuePtr; std::vector<ValuePtr> valueBuffer; for(int count = 0; 10 > count; ++count){ valueBuffer.push_back(ValuePtr(new Value(::rand()))); } BOOST_FOREACH(ValuePtr value, valueBuffer){ std::cout << *value << std::endl; } return 0; } on Fedora 10 (Intel) produces error output like: /usr/include/boost/foreach.hpp:223: error: expected nested-name-specifier before ‘int’ /usr/include/boost/foreach.hpp:223: error: two or more data types in declaration of ‘parameter’ /usr/include/boost/foreach.hpp:224: error: default template arguments may not be used in function templates Value.cpp: In function ‘int main()’: Value.cpp:34: error: no matching function for call to ‘not_(boost::is_array<std::vector<boost::shared_ptr<Value>, std::allocator<boost::shared_ptr<Value> > > >*)’ Value.cpp:34: error: no matching function for call to ‘not_(boost::foreach::is_noncopyable<std::vector<boost::shared_ptr<Value>, std::allocator<boost::shared_ptr<Value> > > >*)’ Value.cpp:34: error: no matching function for call to ‘not_(boost::is_array<std::vector<boost::shared_ptr<Value>, std::allocator<boost::shared_ptr<Value> > > >*)’ Value.cpp:34: error: no matching function for call to ‘not_(boost::foreach::is_noncopyable<std::vector<boost::shared_ptr<Value>, std::allocator<boost::shared_ptr<Value> > > >*)’ Value.cpp:34: error: no matching function for call to ‘not_(boost::is_array<std::vector<boost::shared_ptr<Value>, std::allocator<boost::shared_ptr<Value> > > >*)’ Value.cpp:34: error: no matching function for call to ‘not_(boost::foreach::is_noncopyable<std::vector<boost::shared_ptr<Value>, std::allocator<boost::shared_ptr<Value> > > >*)’ If the first included header file is removed from the code, it builds successfully. Even though the code in this example doesn't technically need that first header file included, it is representative of code that does. What is needed so this code can build successfully while including all the header files?

3 2

Re: [Boost-users] Boost-users Digest, Vol 2003, Issue 6
by Tron Thomas 22 May '09

22 May '09

> > Date: Fri, 22 May 2009 22:42:05 +0100 From: "Pete Bartlett" > <pete(a)pcbartlett.com> Subject: Re: [Boost-users] Including Xutil.h on > Fedora breaks BOOST_FOREACH To: <boost-users(a)lists.boost.org> > Message-ID: <4CBFD915E6B84833BC9CE588386CDD04@P2> Content-Type: > text/plain; charset="us-ascii" Tron Thomas wrote: >> >#include <X11/Xutil.h> >> > > A quick search on Google Codesearch shows that Xutil.h includes Xlib.h which > has the following > > " > #define Bool int > #define Status int > #define True 1 > #define False 0 > " > > (around line 112 in the version I am looking at). > > This breaks Boost.ForEach's (legitimate) attempt to use "Bool" as the name > for a template type. How to fix? Some possibilities > > a) Stop using libraries that employ such bad practices, or > b) Wrap the include in your own header that tidies up after X11 with some > #undefs, or > c) include X11 after Boost ?! > > I doubt Boost.ForEach would be the only library the X11 include would foul > up Thanks Pete. I was able to get the code to compile now.

1 0

[BIL] BIL & AOP
by Jonathan Leonard 22 May '09

22 May '09

Hello, I'm trying to do aspect-oriented programming in C++ and found this library which is almost up to speed to do it (but not quite). The documentation is rather incomplete (with respect to AOP at least) but the relevant code itself seems pretty complete (although I can't quite figure out how to use it for AOP :)). http://www.cdiggins.com/bil.html Does anyone here have experience with the BIL and/or AOP in C++? The specific problem I'm having is using an 'interface' as a 'pointcut'. The docs seem to indicate that an interface is a pointcut, but when I try substituting it in as the 'aspect' class' pointcut_type, I get this error: 1>c:\expedia\ems\ads\lib\boost\boost_1_37\boost\interfaces\crosscut.hpp(59) : error C2039: 'generator' : is not a member of 'Ic' 1> c:\expedia\ems\devs\v-jleonard\aspect_test\aspect_test\aspect_test.cpp(12) : see declaration of 'Ic' 1> c:\expedia\ems\ads\lib\boost\boost_1_37\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(39) : see reference to class template instantiation 'boost::interfaces::detail::crosscut_impl<Aspects>::generator_impl<Derived,Flags,Base>::merge::apply<Aspect>' being compiled 1> with 1> [ 1> Aspects=boost::mpl::list<log_aspect,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na>, 1> Derived=boost::interfaces::crosscut_interface<c,log_aspect>, 1> Flags=boost::interfaces::flags::default_, 1> Base=boost::interfaces::detail::empty_base, 1> Aspect=boost::interfaces::aspect<Ic,log_advice> 1> ] 1> c:\expedia\ems\ads\lib\boost\boost_1_37\boost\mpl\aux_\preprocessed\plain\apply.hpp(43) : see reference to class template instantiation 'boost::mpl::apply_wrap1<F,T1>' being compiled 1> with 1> [ 1> F=boost::interfaces::detail::crosscut_impl<boost::mpl::list<log_aspect,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na,boost::mpl::na>>::generator_impl<boost::interfaces::crosscut_interface<c,log_aspect>,boost::interfaces::flags::default_,boost::interfaces::detail::empty_base>::merge, 1> T1=boost::interfaces::aspect<Ic,log_advice> 1> ] It seems that interface_base has a 'generator' member, but the BOOST_IDL_END macro derives interfaces from interface_base::type instead. I realize this isn't yet an official boost library, but it deals with a great many of the same techniques/ideas [and relies on a lot of underlying boost functionality] so any help you can offer would be much appreciated! [My code is attached and the BIL code can be downloaded here: http://www.coderage.com/interfaces/] Thanks, Jonathan P.S. if anyone knows of alternate ways of pulling off AOP in C++, I'd be open to that too!

1 0

Compile errors using BOOST_FOREACH on Fedora Linux
by Tron Thomas 22 May '09

22 May '09

I have a class defined like this: class SomeObject { public: ... virtual void Method(); ... private: typedef boost::shared_ptr<AnotherObject> AnotherObjectPtr; ... std::vector<AnotherObject> m_objects; ... }; void SomeObject::Method() { ... BOOST_FOREACH(AnotherObjectPtr object, m_objects){ object->DoSomething(); } } The code compiles fine using Boost 1.39.0 on Mac OS X 10.5 (PowerPC). However, when I compile the same code on Fedora 10 (Intel), I get compile errors like: .../boost_1_39_0/boost/foreach.hpp:221: error: expected nested-name-specifier before ‘int’ .../boost_1_39_0/boost/foreach.hpp:221: error: two or more data types in declaration of ‘parameter’ .../boost_1_39_0/boost/foreach.hpp:222: error: default template arguments may not be used in function templates .../SomeObject.cpp: In member function ‘virtual void SomeObject::Method()’: .../SomeObject.cpp:110: error: no matching function for call to ‘not_(boost::is_array<std::vector<boost::shared_ptr<AnotherObject>, std::allocator<boost::shared_ptr<AnotherObject> > > >*)’ .../SomeObject.cpp:110: error: no matching function for call to ‘not_(boost::foreach::is_noncopyable<std::vector<boost::shared_ptr<AnotherObject>, std::allocator<boost::shared_ptr<AnotherObject> > > >*)’ .../SomeObject.cpp:110: error: no matching function for call to ‘not_(boost::is_array<std::vector<boost::shared_ptr<AnotherObject>, std::allocator<boost::shared_ptr<AnotherObject> > > >*)’ .../SomeObject.cpp:110: error: no matching function for call to ‘not_(boost::foreach::is_noncopyable<std::vector<boost::shared_ptr<AnotherObject>, std::allocator<boost::shared_ptr<AnotherObject> > > >*)’ .../SomeObject.cpp:110: error: no matching function for call to ‘not_(boost::is_array<std::vector<boost::shared_ptr<AnotherObject>, std::allocator<boost::shared_ptr<AnotherObject> > > >*)’ .../SomeObject.cpp:110: error: no matching function for call to ‘not_(boost::foreach::is_noncopyable<std::vector<boost::shared_ptr<AnotherObject>, std::allocator<boost::shared_ptr<AnotherObjecth> > > >*)’ These error are quite puzzling, and I'm not sure what is causing the problem especially since the code compiled fine on another platform, which suggests it might be fine. What is needed to fix this problem so the code will compile successfully?

2 2

1.35 -> 1.39 update
by Terry.Rankine＠csiro.au 22 May '09

22 May '09

Hi I am updating some code from 1.35 to 1.39 and i am stuck on this http://www.boost.org/doc/libs/1_38_0/boost/enable_shared_from_this.hpp vs http://www.boost.org/doc/libs/1_39_0/boost/smart_ptr/enable_shared_from_thi… The code i have to update is making calls like this: _internal_weak_this.expired() this is now private in 1.39, but i cant see a way of replicating its actions. Terry Rankine

2 1

Re: [Boost-users] Boost-users Digest, Vol 2003, Issue 1
by Tron Thomas 22 May '09

22 May '09

> > Tron Thomas wrote: >> > I have a class defined like this: >> > >> > class SomeObject >> > { >> > public: >> > ... >> > >> > virtual void Method(); >> > >> > ... >> > >> > private: >> > typedef boost::shared_ptr<AnotherObject> AnotherObjectPtr; >> > >> > ... >> > >> > std::vector<AnotherObject> m_objects; >> > >> > ... >> > }; >> > >> > void SomeObject::Method() >> > { >> > ... >> > >> > BOOST_FOREACH(AnotherObjectPtr object, m_objects){ >> > object->DoSomething(); >> > } >> > } >> > >> > The code compiles fine using Boost 1.39.0 on Mac OS X 10.5 (PowerPC). >> > > That's surprising since m_objects is a vector of AnotherObject, not a > vector of AnotherObjectPtr. (Hint: *always* post the actual code that is > failing.) > > -- Eric Niebler BoostPro Computing http://www.boostpro.com Yes, the declaration of m_objects should have been: std::vector<AnotherObjectPtr;> m_objects; That is consistent with the actual code where the problem is happening. Given that what do people know about how to fix the compiler error?

1 0