- Boost-users - lists.boost.org

[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

Re: [Boost-users] posix_time::from_ftime versus DateTime.FromFileTime
by Anders Dalvander 22 May '09

22 May '09

Archie14(a)lists.boost.org wrote: > I will appreciate any help in sorting out following issue: > > There is a value dt of type long. Calling boost::posix::time::from_ftime in > c++ and > DateTime.FromFileTime with that value produce "slightly" different results: > > dt = 128822886020000000 > > c++: "2009-Mar-23 13:30:02" > c#: {3/23/2009 9:30:02 AM} > DateTime.FromFileTimeUtc will probably produce the same results as boost::posix::time::from_ftime. Perhaps DateTime.SpecifyKind are needed as well. Regards, Anders Dalvander

2 1

boost::iterator_property_map causes run-time fatal error in debug mode on VS2008
by Artyom 22 May '09

22 May '09

Dear all, Noticed some strange behaviour in Debug mode today using boost::iterator_property_map. Not sure whether this is a bug so decided to post here. Here is a how property map is instantiated: template< class Graph, class Vertex, class Edge, class VertexIterator, class EdgeIterator > class PathRecorder { typedef typename boost::property_map< typename Graph, boost::vertex_index_t >::type VertexId_PMap; typedef boost::iterator_property_map< typename std::vector< Edge >::iterator, VertexId_PMap, typename Edge, typename Edge & > PredEdgeMap; /// relevant members std::vector< Edge > edges; VertexId_PMap vertex_id; PathRecorder( void ) : /*** some instantiations here ***/ predEdgeMap( edges.begin(), vertex_id ) { } /** @desc Update an entry inside a map ( fatal error happens here ) **/ void put( Vertex target, Edge e ) { boost::put( predEdgeMap, target, e ); } } In Release mode everything works fine but in Debug mode put method causes a fatal error. It fails in property_map.hpp (351): inline R operator[](key_type v) const { return *(iter + get(index, v)) ; } iter seems to be equal to 0... Which is extremely suspicious. Could anyone think whether I am doing something wrong? I can provide more information if this isn't enough. Arty

3 3

[asio] io_service performance
by Rusty Koonce 22 May '09

22 May '09

First, I'm a noob to the mailing list -- you all need a "search" option on the archives... perhaps it's there, but I didn't see it. I gave up on my O(N) search after making it through the last 3 or 4 months of archives. :) My question is rather simple... Is it better to have a single io_service with multiple threads sharing it calling poll()/poll_one(), or have each thread own its own io_service and calling run()? I saw the HTTP example that did the latter -- each thread owned its own io_service and called run(). My worry there would be if one handler takes a long time to execute it essentially blocks all others behind it. But it seems a single io_service with multiple threads calling poll() or poll_one() would prevent one expensive handler from holding up processing of others behind it (but there could be much more contention on the handler queue). Without a better understanding of the underlying architecture, I'm not sure which way would yield the best performance as traffic scales up on the server. Thanks! -Rusty

2 1

bootstrap.sh questions (compiling v1.39)
by Raymond Wan 22 May '09

22 May '09

Hi all, I'm hadn't been following the development of Boost's installation process and just went from 1.38 to 1.39 and realized the steps that I had written down no longer work. :-) I'm glad that the process was being looked into, but could someone help me with a couple of things? First, I use mpi and use to edit $BOOST/user-config.jam and put "using mpi ;" at the end to get it to compile. I didn't do this and I got a similar warning as before even though I ran: ./bootstrap.sh --with-libraries=graph,mpi,program_options,serialization Does "mpi" in it have no effect? After it finished, it seems the other 3 were made, but not mpi. Should I add "using mpi ;" still? [In $BOOST, I now notice there is no user-config.jam but a project-config.jam.] And the other thing I use to do was to edit the Makefile by adding "--layout=system" so that the generated libraries do not indicate the compiler version. (I did read the discussion earlier this month and I'm now wondering if it's bad practice to do this? I would like libboost_program_options-mt.so instead of libboost_program_options-gcc43-mt.so .) How do I do this with bootstrap.sh/bjam? Thank you! Ray

2 4

scoped_lock
by Space Ship Traveller 22 May '09

22 May '09

I think this is my own fault. I'm debugging some issues with multi-threading and using boost scoped_lock. My code looks like this: { // Enqueue the notification to be processed scoped_lock(m_notifications.lock); m_notifications.sources->push(note); } Am I correct in assuming this is not going to work as expected? The compiler might not even instantiate the lock given this code? I need to write it like this? { // Enqueue the notification to be processed scoped_lock locked(m_notifications.lock); m_notifications.sources->push(note); } Kind regards, Samuel

2 1

Re: [Boost-users] Error (runtime) assigning multi_array to multi_array with smaller dimensions
by Oei, YC 22 May '09

22 May '09

> //at class constructor > boost::multi_array<char, 2> array2d = new boost::multi_array<char, > 2>(boost::extents[x][y]); > //at class method > boost::multi_array<char, 1> array1d = array2d[0]; I tried out those two lines (minus the "new") here (see below), and they compile without complaints in g++ 4.1.2. Yung-Chin -- contents of test file -- #include <iostream> #include <boost/multi_array.hpp> int main() { size_t x = 5; size_t y = 7; boost::multi_array<char, 2> array2d = boost::multi_array<char, 2>(boost::extents[x][y]); std::cout << array2d.num_dimensions() << std::endl; std::cout << array2d[0].num_dimensions() << std::endl; boost::multi_array<char, 1> array1d = array2d[0]; std::cout << array1d.num_dimensions() << std::endl; return 0; } //main

2 3