December 2010 - Boost-users - lists.preview.boost.org

Re: [Boost-users] variant over base and derived classes
by Hicham Mouline 09 Dec '10

09 Dec '10

>> -----Original Message----- >> From: Hicham Mouline [mailto:hicham@mouline.org] >> Sent: 09 December 2010 00:04 >> To: 'boost-users(a)lists.boost.org' >> Subject: variant over base and derived classes >> >> hello, >> <snip> >> >> typedef boost::variant<S,Deriv1, Deriv2, Deriv3> my_variant_t; >> >> Deriv3 d3; >> >> struct print_type: public boost::static_visitor<> { >> template <typename T> >> void operator()(const T&) const >> { >> std::cout<< typeid(T).name() <<std::endl; >> } >> }; >> >> const S& s = d3; >> my_variant_t v = s; >> boost::apply_visitor( print_type(), v ); >> >> This prints S. >> >> Is it a truncated copy of d3 that is stored v? >Yes. >> How do I construct v polymorphically so that the real object is stored? >> >> regards, >You have to downcast before creating the variant. >boost::variant only uses the static type of the object. >In Christ, >Steven Watanabe If I am given a const S* sptr, how do I construct an instance of the above variant then? const Deriv1* d1ptr; const Deriv2* d2ptr; const Deriv3* d3ptr; my_variant_t v = ((d1ptr = dynamic_cast<const Deriv1*>(sptr)) != 0 )? *d1ptr: ((d2ptr = dynamic_cast<const Deriv2*>(sptr)) != 0 )? *d2ptr: ((d3ptr = dynamic_cast<const Deriv3*>(sptr)) != 0 )? *d3ptr: *sptr; Is there a better way of writing this? rds, -------------------------------------------- Trying to do this more generically, I've thought of call mpl::for_each on the ::types of the variant to see which dynamic_cast works. The problem is that I need the most derived type to be stored in the variant. I can see how to do it by a virtual function but that is completely intrusive. regards,

2 1

Re: [Boost-users] [Proto] Failed to Mimic the "Lazy Vector" Example
by Hossein Haeri 09 Dec '10

09 Dec '10

Hi Thomas, > > Trying to mimic what comes in the Lazy Vector example > > http://www.boost.org/doc/libs/1_45_0/doc/html/proto/users_guide.html#boost_… <snip> > The type EmtDomain is incomplete when it is used in EmtExpr > (proto::extends ...). So is also lazy_vector_domain when it is used in lazy_vector_expr. What's different here? (See below.) > The solution is to forward declare EmtExpr, define the Domain and then > define the expression wrapper. Thanks, that works. :) But, I do still wonder why the same order of definition for Lazy Vector didn't work here: Grammar > Forward Declaration of Domain > (Context) > Expression Wrapper > Domain Do you mind shedding light on this too? TIA, --Hossein

1 0

Re: [Boost-users] mpi: sending/receiving different types
by Hicham Mouline 09 Dec '10

09 Dec '10

>The way we do this is send a special message saying that a broadcast >will be sent next. > Brian > >probe() checks only for messages sent by send(), not by broadcast(). >Matthias Thanks, I spend most of my time broadcasting, and sometimes sending.... I guess that means in the slave processes: . use mpi::broadcast() . if the received value is a signal that a send() to me will be issued next, then I'll recv() About the broadcast() function, I obviously have many types of messages to send, would you rather: 1. send a broadcast with just an int (like a tag) to tell which broadcast is following next or 2. construct a virtual base class my_mpi_broadcast , derive all the sendable broadcasts from it, from sender, send actual instance of derived from my_mpi_broadcast, and at receiver, can the mechanism reconstruct for me the derived class? (with boost::serialization) Is 2 doable at all? If so, pros/cons regards,

2 4

variant over base and derived classes
by Hicham Mouline 09 Dec '10

09 Dec '10

hello, How to determine the actual type of the object stored in a variant? struct S { virtual ~S() {} }; struct Deriv1 : public S { virtual ~Deriv1() {} }; struct Deriv2 : public S { virtual ~Deriv2() {} }; struct Deriv3 : public Deriv2 { virtual ~Deriv3() {} }; typedef boost::variant<S,Deriv1, Deriv2, Deriv3> my_variant_t; Deriv3 d3; struct print_type: public boost::static_visitor<> { template <typename T> void operator()(const T&) const { std::cout<< typeid(T).name() <<std::endl; } }; const S& s = d3; my_variant_t v = s; boost::apply_visitor( print_type(), v ); This prints S. Is it a truncated copy of d3 that is stored v? How do I construct v polymorphically so that the real object is stored? regards,

3 2

Re: [Boost-users] variant over base and derived classes
by Hicham Mouline 09 Dec '10

09 Dec '10

>> -----Original Message----- >> From: Hicham Mouline [mailto:hicham@mouline.org] >> Sent: 09 December 2010 00:04 >> To: 'boost-users(a)lists.boost.org' >> Subject: variant over base and derived classes >> >> hello, >> >> How to determine the actual type of the object stored in a variant? >> >> struct S { >> virtual ~S() >> {} >> }; >> >> struct Deriv1 : public S { >> virtual ~Deriv1() >> {} >> }; >> >> struct Deriv2 : public S { >> virtual ~Deriv2() >> {} >> }; >> >> struct Deriv3 : public Deriv2 { >> virtual ~Deriv3() >> {} >> }; >> >> typedef boost::variant<S,Deriv1, Deriv2, Deriv3> my_variant_t; >> >> Deriv3 d3; >> >> struct print_type: public boost::static_visitor<> { >> template <typename T> >> void operator()(const T&) const >> { >> std::cout<< typeid(T).name() <<std::endl; >> } >> }; >> >> const S& s = d3; >> my_variant_t v = s; >> boost::apply_visitor( print_type(), v ); >> >> This prints S. >> >> Is it a truncated copy of d3 that is stored v? >Yes. >> How do I construct v polymorphically so that the real object is stored? >> >> regards, >You have to downcast before creating the variant. >boost::variant only uses the static type of the object. >In Christ, >Steven Watanabe If I am given a const S* sptr, how do I construct an instance of the above variant then? const Deriv1* d1ptr; const Deriv2* d2ptr; const Deriv3* d3ptr; my_variant_t v = ((d1ptr = dynamic_cast<const Deriv1*>(sptr)) != 0 )? *d1ptr: ((d2ptr = dynamic_cast<const Deriv2*>(sptr)) != 0 )? *d2ptr: ((d3ptr = dynamic_cast<const Deriv3*>(sptr)) != 0 )? *d3ptr: *sptr; Is there a better way of writing this? rds,

1 0

emacs mode for quickbook?
by Wilhelm 09 Dec '10

09 Dec '10

Hi, does anybody know of there is already an emacs-mode for quickbook? -- Wilhelm

2 1

[Proto] Failed to Mimic the "Lazy Vector" Example
by Hossein Haeri 08 Dec '10

08 Dec '10

Dear all, Trying to mimic what comes in the Lazy Vector example http://www.boost.org/doc/libs/1_45_0/doc/html/proto/users_guide.html#boost_… I get a strange error speaking about result_of and the like. My guess is that there is some specialisation of a function object which does do the job for std::vector<> that I need to also specialise for my class. I can't find any track of that thing though. And, I might be totally wrong too... Anyway, for your reference, I have put the code as well as the error message that I get in GCC 4.5.1, MinGW, WinXP, SP3 in the PS section of this posting. Any ideas please? TIA,--Hossein <Code> #include <iostream> #include <boost/proto/proto.hpp> namespace mpl = boost::mpl; namespace proto = boost::proto; using proto::_; struct EWBase {}; typedef proto::terminal<double (*) (double)> FunctionType; struct EmtGrammar: proto::or_ < proto::terminal<EWBase>, proto::shift_right<EmtGrammar, FunctionType> > {}; struct EmtDomain; template<typename Expr> struct EmtExpr : proto::extends<Expr, EmtExpr<Expr>, EmtDomain> { typedef proto::extends<Expr, EmtExpr<Expr>, EmtDomain> base_type; EmtExpr( Expr const & expr = Expr() ) : base_type( expr ) {} }; template< typename T > struct Emt : EmtExpr<typename proto::terminal<EWBase>::type> { typedef typename proto::terminal<EWBase>::type expr_type; Emt(): EmtExpr<expr_type>(expr_type::make(EWBase())) {} }; struct EmtDomain : proto::domain<proto::generator<EmtExpr>, EmtGrammar> {}; int main() { return 0; } </Code> <Error Message> -------------- Build: Debug in ProtoGame2 --------------- Compiling: main.cpp In file included from D:\Sources\Boost\boost_1_42_0/boost/proto/traits.hpp:34:0, from D:\Sources\Boost\boost_1_42_0/boost/proto/expr.hpp:27, from D:\Sources\Boost\boost_1_42_0/boost/proto/core.hpp:17, from D:\Sources\Boost\boost_1_42_0/boost/proto/proto.hpp:12, from D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:3: D:\Sources\Boost\boost_1_42_0/boost/utility/result_of.hpp: In instantiation of 'boost::detail::result_of_nested_result<EmtDomain, EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<const EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>)>': D:\Sources\Boost\boost_1_42_0/boost/utility/result_of.hpp:75:1: instantiated from 'boost::detail::result_of_impl<EmtDomain, EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<const EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>), false>' D:\Sources\Boost\boost_1_42_0/boost/utility/detail/result_of_iterate.hpp:24:109: instantiated from 'boost::result_of<EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<const EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>)>' D:\Sources\Boost\boost_1_42_0/boost/preprocessor/iteration/detail/local.hpp:34:1: instantiated from 'boost::proto::exprns_::extends<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l>, EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >, EmtDomain, 0l>' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:25:1: instantiated from 'EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:36:1: instantiated from here D:\Sources\Boost\boost_1_42_0/boost/utility/result_of.hpp:68:1: error: invalid use of incomplete type 'struct EmtDomain' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:20:8: error: forward declaration of 'struct EmtDomain' In file included from D:\Sources\Boost\boost_1_42_0/boost/proto/extends.hpp:533:0, from D:\Sources\Boost\boost_1_42_0/boost/proto/core.hpp:23, from D:\Sources\Boost\boost_1_42_0/boost/proto/proto.hpp:12, from D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:3: D:\Sources\Boost\boost_1_42_0/boost/preprocessor/iteration/detail/local.hpp: In instantiation of 'boost::proto::exprns_::extends<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l>, EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >, EmtDomain, 0l>': D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:25:1: instantiated from 'EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:36:1: instantiated from here D:\Sources\Boost\boost_1_42_0/boost/preprocessor/iteration/detail/local.hpp:34:1: error: no type named 'type' in 'struct boost::result_of<EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<const EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>)>' In file included from D:\Sources\Boost\boost_1_42_0/boost/proto/traits.hpp:34:0, from D:\Sources\Boost\boost_1_42_0/boost/proto/expr.hpp:27, from D:\Sources\Boost\boost_1_42_0/boost/proto/core.hpp:17, from D:\Sources\Boost\boost_1_42_0/boost/proto/proto.hpp:12, from D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:3: D:\Sources\Boost\boost_1_42_0/boost/utility/result_of.hpp: In instantiation of 'boost::detail::result_of_nested_result<EmtDomain, EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>)>': D:\Sources\Boost\boost_1_42_0/boost/utility/result_of.hpp:75:1: instantiated from 'boost::detail::result_of_impl<EmtDomain, EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>), false>' D:\Sources\Boost\boost_1_42_0/boost/utility/detail/result_of_iterate.hpp:24:109: instantiated from 'boost::result_of<EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>)>' D:\Sources\Boost\boost_1_42_0/boost/preprocessor/iteration/detail/local.hpp:34:1: instantiated from 'boost::proto::exprns_::extends<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l>, EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >, EmtDomain, 0l>' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:25:1: instantiated from 'EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:36:1: instantiated from here D:\Sources\Boost\boost_1_42_0/boost/utility/result_of.hpp:68:1: error: invalid use of incomplete type 'struct EmtDomain' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:20:8: error: forward declaration of 'struct EmtDomain' In file included from D:\Sources\Boost\boost_1_42_0/boost/proto/extends.hpp:533:0, from D:\Sources\Boost\boost_1_42_0/boost/proto/core.hpp:23, from D:\Sources\Boost\boost_1_42_0/boost/proto/proto.hpp:12, from D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:3: D:\Sources\Boost\boost_1_42_0/boost/preprocessor/iteration/detail/local.hpp: In instantiation of 'boost::proto::exprns_::extends<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l>, EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >, EmtDomain, 0l>': D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:25:1: instantiated from 'EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >' D:\My Documents\My Programmes\Tutorial\Proto\ProtoGame2\main.cpp:36:1: instantiated from here D:\Sources\Boost\boost_1_42_0/boost/preprocessor/iteration/detail/local.hpp:34:1: error: no type named 'type' in 'struct boost::result_of<EmtDomain(boost::proto::exprns_::expr<boost::proto::tag::function, boost::proto::argsns_::list1<EmtExpr<boost::proto::exprns_::expr<boost::proto::tag::terminal, boost::proto::argsns_::term<EWBase>, 0l> >&>, 1l>)>' Process terminated with status 1 (0 minutes, 2 seconds) 6 errors, 0 warnings </Error Message>

2 1

Re: [Boost-users] mpi: sending/receiving different types
by Hicham Mouline 08 Dec '10

08 Dec '10

-----Original Message----- From: "Riccardo Murri" [riccardo.murri(a)gmail.com] Date: 08/12/2010 01:50 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] mpi: sending/receiving different types >> 2. the root sends directly a reference to a base class of anything sendable, >> then the receivers construct the derived classes on reception with >> broadcast. The T is then the base class type. >> > There's a risk of slicing here, i.e., if you pass a reference to a > base class, only the base class data will be serialized and received. > As far as I understand, Boost.Serialization (hence Boost.MPI) will do > the correct thing if you use *pointers* instead: i.e., you send a > pointer to a (derived) class and you receive it through a pointer to > the base class. > (Beware: I have not checked!) Does Boost.Serialization/MPI construct an object on the heap when it deserializes? e.g. master: base* b = &derived; broadcast( world, b, 0 ); slave: base* b; broadcast( world, b, 0 ); /// does this create the appropriate derived class on the heap, and make b point to it? Is this what you meant? Another question, the base struct contains a double and 2 char[8] fields, but also a virtual function. Does this mean it shouldn't be set as being a MPI data type because of its polymorphism? Thanks,

1 0

[Serialization] Inconsistent tracking_level when switching from static to DLL
by Guy Prémont 08 Dec '10

08 Dec '10

Hi, I am using boost (1.40) serialization on Windows (VS 2008) to serialize a complex hierarchy of classes. My application is composed of different modules, each having its own serialization library. I have a Core library, with a CoreSerialization library, that defines a bunch of classes and base data types; I also have a Vehicle library, with a separate VehicleSerialization library, the defines some other classes with base classes in Core and that also use some user data types defined in Core. Using static libraries, everything saves and loads perfectly. We recently switched to using DLLs. When loading and saving with an application that only uses core (as Dlls) everything serializes perfectly. We can load files that were generated by an older application (using static libraries), save them and load them back. If the application also uses the Vehicle libraries, it can load older files (generated using static libraries), save them, but fails to load them back. The difference between the files generated with a DLL application and a static link application, lies in the tracking of certain classes. Since the serialization is split between 2 DLLs, the tracking level (by default selectively) will actually depends on what classes are serialized in the DLL and may be different in different DLLs. This seems to be cause by the various singleton that are created, notably pointer_oserializer<T> and oserializer<T>. In a statically linked application, there is only one instance on those singleton, in a DLL linked application, there is one instance of the singleton for each DLL. I've also noticed that in my Core DLL, for certain type, there are both notably pointer_oserializer<T> and oserializer<T>, while in the Vehicle DLL, there is only notably oserializer<T>, hence the difference in tracking level. There is an easy fix here, not to use selective tracking but track always or never, explicitly. But still, there seems to be some data that needs to be shared across various serialization DLLs. I am a bit worry about some other bugs popping out relative to it. Has this bug ever been found? It may be a side effect of putting serialization code in DLLs, the documentation on that subject is a bit sparse. Thanks for any inputs Guy -- Guy Prémont, D.Sc. Architecte logiciel senior / Senior software architect CM Labs Simulations Inc. <blocked::http://www.cm-labs.com/> http://www.cm-labs.com/ Tel. 514-287-1166 ext. 237

2 5

Re: [Boost-users] [gil] Using gil::color_converted_view with gil::for_each_pixel (Christian Henning)
by Chris Yuen 08 Dec '10

08 Dec '10

Dear Christian, > > > > 2. This compiles > > > > gil::gil_function_requires<gil::ImageViewConcept<int> >(); > What do you mean? This shouldn't compile? I was under the impression that the point of gil_function_requires is to do static checking to ensure that a type is compatible with an GIL type? (Something akin to BOOST_CONCEPT_ASSERT) Is an int supposed to be compatible with ImageViewConcept? From the GIL tutorial http://stlab.adobe.com/gil/html/giltutorial.html#GenericVersionSec, it seems like it's being used as a static type check, and int clearly isn't compatible to an image view. Am I missing something? Best regards, Chris Yuen

2 1