- Boost-users - lists.boost.org

serialization : XML Schema?
by m.korbosli 13 Mar '06

13 Mar '06

Hi, I 'm working on a project where I want to parse XML archives generated by boost serialization library, except that I didn't find any serialization's specification or XML schema describing this mechanism. Is there any documentation providing this? Thanks Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34 /mn) ; tél : 08 92 68 13 50 (0,34/mn)

3 3

"Re: serialization : XML Schema?"
by m.korbosli 13 Mar '06

13 Mar '06

Vladimir Prus wrote: >>Was the original question about schema for specific serialized data >>types,or rather for general syntax of XML archives, regardless >>of the serialized types? It sounded like the latter for me. Yes, it's about the latter! I'm seeking a general syntax in order to verify the coherence of the serialized data when parsing XML archives. Is there anything about that? Thanks Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34 /mn) ; tél : 08 92 68 13 50 (0,34/mn)

2 1

BGL Graph - Edge_connectivity
by Adam Hartshorne 13 Mar '06

13 Mar '06

Hi All, What does the edge_connectivity function do? I can't find any reference to it in the online documentation. Adam

1 0

boost::serialization doesn't support iterators?
by 'Carlo Wood' 13 Mar '06

13 Mar '06

I looked for hours in the docs, because I couldn't believe that a serialization library that supports deep copying of pointers and STL containers wouldn't even MENTION iterators (after all, iterators are the pointers of the STL). However, it seems that boost::serialization simply does not support serializing iterators! Is this true? I really need to serialize iterators, how can I do that? -- Carlo Wood <carlo(a)alinoe.com>

6 9

Syntax of get for Variant and any_cast for Any
by Scott Meyers 13 Mar '06

13 Mar '06

It took me a little while to figure out that get<T> on a variant is really just the moral equivalent of dynamic_cast<T> with a funny syntax. I'd like to understand why, given a variant v, this syntax is used T* p = get<T>(&v); T& r = get<T>(v); instead of this: T* p = variant_cast<T*>(&v); T& r = variant_cast<T&>(v); any_cast on pointers also uses what I consider to be a counterintuitive syntax, using this (for an any object a) T* p = any_cast<T>(&a) instead of this: T* p = any_cast<T*>(&a) However, any_cast to a reference works with a syntax analogous to dynamic_cast. Implementing the "expected" syntax doesn't seem to be too difficult. For example, here's my quick cut at variant_cast: template<typename T, typename U1, typename U2, typename U3> T variant_cast(boost::variant<U1, U2, U3>& v) // ref { using namespace boost; BOOST_STATIC_ASSERT(is_reference<T>::value); return get<remove_reference<T>::type>(v); } template<typename T, typename U1, typename U2, typename U3> T variant_cast(const boost::variant<U1, U2, U3>& v) //ref-to-const { using namespace boost; BOOST_STATIC_ASSERT(is_reference<T>::value); return get<remove_reference<T>::type>(v); } template<typename T, typename U1, typename U2, typename U3> T variant_cast(boost::variant<U1, U2, U3> *pv) // ptr { using namespace boost; BOOST_STATIC_ASSERT(is_pointer<T>::value); return get<remove_pointer<T>::type>(pv); } template<typename T, typename U1, typename U2, typename U3> T variant_cast(const boost::variant<U1, U2, U3> *pv) // ptr-to-const { using namespace boost; BOOST_STATIC_ASSERT(is_pointer<T>::value); return get<remove_pointer<T>::type>(pv); } In a thread last month, Marc Mutz posted this approach to "normalizing" the syntax of any_cast: template <typename T> class any_cast2 : noncopyable { const any & m_any; public: explicit any_cast2( const any & v ) : m_any( v ) {} operator T() const { return any_cast<T>( m_any ); } }; template <typename T> class any_cast2<T*> : noncopyable { any * const m_any; public: explicit any_cast2( any * v ) : m_any( v ) {} operator T * () const { return any_cast<T>( m_any ); } }; template <typename T> class any_cast2<const T*> : noncopyable { const any * const m_any; public: explicit any_cast2( const any * v ) : m_any( v ) {} operator const T * () const { return any_cast<T>( m_any ); } }; template <typename T> class any_cast2<T&> : noncopyable { any & m_any; public: explicit any_cast2( any & v ) : m_any( v ) {} operator T & () const { return any_cast<T&>( m_any ); } }; template <typename T> class any_cast2<const T&> : noncopyable { const any & m_any; public: explicit any_cast2( const any & v ) : m_any( v ) {} operator const T & () const { return any_cast<const T&>( m_any ); } }; Maybe there are problems to these approaches -- I've hardly investigated them. But I would be interested to know if there is a good reason for the syntaxes for dynamic_cast, any_cast, and get to vary so much. Thanks, Scott

3 3

boost::serialization Bug
by Carlo Wood 13 Mar '06

13 Mar '06

Ok, it's not a "bug"... but it's damn annoying to get compiler warnings from library header. Especially when those compiler warnings are 1 page long. Is it possible to please not mention variables that aren't being used? This is what I get for a SINGLE warning: /usr/include/boost/archive/detail/interface_oarchive.hpp: In instantiation of ‘const boost::archive::detail::basic_pointer_oserializer* boost::archive::detail::interface_oarchive<Archive>::register_type(T*) [with T = std::set<DirTree, std::less<DirTree>, std::allocator<DirTree> >, Archive = boost::archive::xml_oarchive]’: /usr/include/boost/archive/detail/oserializer.hpp:332: instantiated from ‘static const boost::archive::detail::basic_pointer_oserializer* boost:: archive::detail::save_pointer_type<Archive, TPtr>::non_abstract<T>:: register_type(Archive&) [with T = std::set<DirTree, std::less<DirTree>, std::allocator<DirTree> >, Archive = boost::archive::xml_oarchive, TPtr = DirTrees*]’ /usr/include/boost/archive/detail/oserializer.hpp:349: instantiated from ‘static const boost::archive::detail::basic_pointer_oserializer* boost:: archive::detail::save_pointer_type<Archive, TPtr>::register_type(Archive&, T&) [with T = std::set<DirTree, std::less<DirTree>, std::allocator<DirTree> >, Archive = boost::archive::xml_oarchive, TPtr = DirTrees*]’ /usr/include/boost/archive/detail/oserializer.hpp:475: instantiated from ‘static void boost::archive::detail::save_pointer_type<Archive, TPtr>:: invoke(Archive&, TPtr) [with Archive = boost::archive::xml_oarchive, TPtr = DirTrees*]’ /usr/include/boost/archive/detail/oserializer.hpp:551: instantiated from ‘void boost::archive::save(Archive&, const T&) [with Archive = boost:: archive::xml_oarchive, T = DirTrees*]’ /usr/include/boost/archive/basic_xml_oarchive.hpp:84: instantiated from ‘void boost::archive::basic_xml_oarchive<Archive>::save_override(const boost::serialization::nvp<T>&, int) [with T = DirTrees* const, Archive = boost::archive::xml_oarchive]’ /usr/include/boost/archive/detail/interface_oarchive.hpp:80: instantiated from ‘Archive& boost::archive::detail::interface_oarchive<Archive>:: operator<<(const T&) [with T = boost::serialization::nvp<DirTrees* const>, Archive = boost::archive::xml_oarchive]’ ../../cppgraph/src/serialization.h:35: instantiated from ‘void Iterator<Container>::save(Archive&, unsigned int) const [with Archive = boost::archive::xml_oarchive, Container = DirTrees]’ /usr/include/boost/serialization/access.hpp:90: instantiated from ‘static void boost::serialization::access::member_save(Archive&, const T&, unsigned int) [with Archive = boost::archive::xml_oarchive, T = Iterator<DirTrees>]’ /usr/include/boost/serialization/split_member.hpp:42: instantiated from ‘static void boost::serialization::detail::member_saver<Archive, T>::invoke( Archive&, const T&, unsigned int) [with Archive = boost::archive:: xml_oarchive, T = Iterator<DirTrees>]’ /usr/include/boost/serialization/split_member.hpp:63: instantiated from ‘void boost::serialization::split_member(Archive&, T&, unsigned int) [with Archive = boost::archive::xml_oarchive, T = Iterator<DirTrees>]’ ../../cppgraph/src/serialization.h:46: instantiated from ‘void Iterator<Container>::serialize(Archive&, unsigned int) [with Archive = boost::archive::xml_oarchive, Container = DirTrees]’ /usr/include/boost/serialization/access.hpp:106: instantiated from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::xml_oarchive, T = Iterator<DirTrees>]’ /usr/include/boost/serialization/serialization.hpp:78: instantiated from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::xml_oarchive, T = Iterator<DirTrees>]’ /usr/include/boost/serialization/serialization.hpp:121: instantiated from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::xml_oarchive, T = Iterator<DirTrees>]’ /usr/include/boost/archive/detail/oserializer.hpp:148: instantiated from ‘void boost::archive::detail::oserializer<Archive, T>::save_object_data (boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::xml_oarchive, T = Iterator<DirTrees>]’ ../../cppgraph/src/serialization.cc:40: instantiated from here /usr/include/boost/archive/detail/interface_oarchive.hpp:60: warning: unused parameter ‘t’ Moreover, I normally treat warnings as errors (with -Werror); which is impossible when a third party library generates warnings. -- Carlo Wood <carlo(a)alinoe.com>

2 2

Trouble getting boost::ptr_container::ptr_map working
by Gustavo Ribeiro Alves 13 Mar '06

13 Mar '06

Hello, I'm writing an small library to represent types. Right now I'm focusing on representing type composition. For that I'm using the composite pattern as proposed by Gamma et al., so I have an abstract base class for my composites that has the virtual functions to addComposite members, but not their implementation. The header of my class looks like this: namespace dintype { class Type{ public: virtual ~Type()=0; typedef std::string Name_t; virtual void addComposition(const Name_t& name,Type* tp)=0; virtual void delComposition(const Name_t& name)=0; Type* clone() const; protected: typedef ptr_map<Name_t,Type> children_t; typedef children_t::iterator children_iterator; typedef children_t::const_iterator children_const_iterator; typedef children_t::size_type children_size_type; Type(); private: virtual Type* do_clone() const=0; }; inline Type* new_clone(const Type& c) { return c.clone(); } } The one for my composite class is: class CompositeType : public Type { private: children_t m_children; CompositeType(const CompositeType& r); virtual Type* do_clone(); protected: void clearAllCompositeChildren(); public: CompositeType(); virtual ~CompositeType(); virtual void addComposition(const Name_t& name,Type* tp); virtual void delComposition(const Name_t& name); }; Here is the implementation of the composite class: CompositeType::CompositeType(const CompositeType& r) : m_children(r.m_children.clone()) { } CompositeType::CompositeType() { } CompositeType::~CompositeType() { } void CompositeType::clearAllCompositeChildren() { m_children.erase(m_children.begin(),m_children.end()); } void CompositeType::addComposition(const Name_t& name,Type* tp) { m_children[name]=tp; // <========= THIS LINE IS THE PROBLEM } void CompositeType::delComposition(const Name_t& name) { m_children.erase(name); } I can't get the program to compile because gcc keeps complaining m_children[name] don't has operator= and that type is an abstract class and can't be initialized. I read all the boost::prt_container documentation and I couldn't find what I'm doing wrong. I also tried m_children.insert(name,tp); to no avail. I'll greatly appreciate any help. Thanks, Gustavo

1 0

Boost.Thread-RWLock
by george 12 Mar '06

12 Mar '06

hello! until boost 1.33.0 there was in the lib(boost thread) the RW locks now in 1.33.1 is of for deadlock reasons as I know... what about the next version of boost(1.33.2(??)),it would have it again? in the sandbox there is something... does somebody know when the next version will be ready?? I am working on a project and I wanna use RW locks,I dont want to use 1.33.0 RW locks not becouse I am afraid deadlock,the use of them will be simple,but becouse I want to use the latest stable vesrion. thanks!

1 0

Re: [Boost-users] multi_index 1.33.0, known problems with RHEL 3 compiler (gcc 3.2.3)?
by JOAQUIN LOPEZ MU?Z 12 Mar '06

12 Mar '06

----- Mensaje original ----- De: bert hubert <bert.hubert(a)netherlabs.nl> Fecha: Sábado, Marzo 11, 2006 6:39 pm Asunto: [Boost-users] multi_index 1.33.0,known problems with RHEL 3 compiler (gcc 3.2.3)? > Hi, > > Let me start off by saying that I consider multi_index to be the most > stunningly clever AND useful piece of c++ around. Thanks! > > A PowerDNS user on RHEL 3 with a gcc that calls itself 'gcc 3.2.3' > reportsthe following error compiling PowerDNS snapshot 576 > (http://svn.powerdns.com/snapshots/576/pdns- > 2.9.20.20060311.576.tar.gz):Message: > http://mailman.powerdns.com/pipermail/pdns-users/2006- > March/003134.html [...] > 285 typedef typename waiters_t::template index<KeyTag>::type > waiters_by_ttd_index_t;286 waiters_by_ttd_index_t& > ttdindex=d_waiters.get<KeyTag>(); > Any ideas, especially on a workaround? It compiles fine on all > gcc's I have > access to. > Hello Bert, I can try to investigate deeper into this next week, in the meantime let me suggest a couple of things: 1. Shouldn't be the expression waiters_by_ttd_index_t& ttdindex=d_waiters.get<KeyTag>(); written as waiters_by_ttd_index_t& ttdindex=d_waiters.template get<KeyTag>(); as d_waiters type is dependent on MTasker template args? Anyway, the error doesn't seem to be related to this, but who knows. 2. You might try the equivalent expression: waiters_by_ttd_index_t& ttdindex= boost::multi_index::get<KeyTag>(d_waiters); 3. Substituting identifiers (via an enum if you want to retain some legibility) for tags seem to reduce the stress on weaker compilers. If nothing of this works please let me know and I'll dig deeper once I've got access to a GCC environment next week. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

c++ parser with boost::spirit?
by Noel Yap 12 Mar '06

12 Mar '06

Has anyone created a c++ parser with boost::spirit? Thanks, Noel

8 12