- Boost - lists.boost.org

[Formal Review] Collection Traits ends May 7th
by hartmutkaiser＠t-online.de 07 May '04

07 May '04

Hi all, Just wanted to remind you, that the formal review of the Collection Traits library (do we have agreed on a new name already?) ends today, May 7th, 2004. Regards Hartmut Review Manager

1 0

[serialization] exception during deserialization
by FATH Francois 07 May '04

07 May '04

I am trying to use the serialization library to save an object and a pointer to the object, but the pointer has the type of the object's base class. Something like: // declaration MyClass myObject; // object, not pointer MyBaseClass *myPointer = &myObject; // serialization code ar & BOOST_SERIALIZATION_NVP(myObject); ar & BOOST_SERIALIZATION_NVP(myPointer); And I get an exception (either null reference exception or access violation) during the deserialization. I am using xml archives. The xml generated code seems fine. I have also noticed that saving a pointer of the object's type pointing to the object solves the problem: // updated code MyClass myObject; // object, not pointer MyClass *myOtherPointer = & myObject MyBaseClass *myPointer = &myObject; // serialization code ar & BOOST_SERIALIZATION_NVP(myObject); ar & BOOST_SERIALIZATION_NVP(myOtherPointer); ar & BOOST_SERIALIZATION_NVP(myPointer); So is it a bug, or have I done something wrong ? The compiler is VC7.1, full example code is in attachement. Thanks, Francois Fath -- Disclaimer ------------------------------------ Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme. *** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system. #include "stdafx.h" #include <fstream> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/serialization/export.hpp> using namespace std; /* * Base class */ class Base { public: Base() {} virtual ~Base() {} private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { } }; /* * Derived class */ class Derived : public Base { public: Derived() {} virtual ~Derived() {} private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(Base); /* uncomment to avoid the exception * ar & BOOST_SERIALIZATION_NVP(this); */ } }; /* * exports */ BOOST_CLASS_EXPORT(Base) BOOST_CLASS_EXPORT(Derived) int _tmain(int argc, _TCHAR* argv[]) { // create Derived derived; Base *base = &derived; // serialize { ofstream ofs("toto.xml"); boost::archive::xml_oarchive oa(ofs); oa << BOOST_SERIALIZATION_NVP(derived); oa << BOOST_SERIALIZATION_NVP(base); } // deserialize { ifstream ifs("toto.xml"); boost::archive::xml_iarchive ia(ifs); ia >> BOOST_SERIALIZATION_NVP(derived); ia >> BOOST_SERIALIZATION_NVP(base); } //quit return 0; }

2 1

Re: [boost] Re: Re: Re: Using Serialization for binary marshalling
by brangdon＠cix.compulink.co.uk 07 May '04

07 May '04

In-Reply-To: <c7bsah$27c$1(a)sea.gmane.org> ianmcc(a)lorentz.leidenuniv.nl (Ian McCulloch) wrote (abridged): > Nice idea. I was thinking along the lines of how to achieve > high-performance, with shared memory & fast network message passing in > mind. I have some experience of that kind of code being quicker than code which naively treats an int as 4 bytes. There was enough compression that the bandwidth saving (eg on disk i/o) compensated for the complexity of the code. That was some years ago, and there may have been ways to optimise the naive code that I didn't try. Still, I wouldn't write this off on speed grounds without measuring it. -- Dave Harris, Nottingham, UK

3 2

Re:[boost] [serialization] pointers to built-in types
by Robert Ramey 07 May '04

07 May '04

Lirong wrote: > I remember that pointers to built-in types can not be serialized > directly in earlier versions of the library. The user would have to > write a wrapper around the built-in type. How is the situation now? The default serialization traits are such that pointers to primitive types are set to not-serializable. Suppose you set the implementation_level<long> to object serializable and serialize a pointer to a long. This well mean that all serialized longs have to be tracked. Do you want something like this to happen? Its possible to serialize a pointer to primitive - I just can't imagine a case where one would want to do because of the side effects it would cause. That's why I recommend wrapping the primitive in its own type so that you don't create a lot of unexpected/undesired side-effects. Look at strong typedef for a simple cheap automatic wrapper. Robert Ramey

2 1

RE: [boost] Re: static sized strings
by Reece Dunn 07 May '04

07 May '04

John Nagle wrote: >Reece Dunn wrote: >>There is currently a static-sized array in the Boost library that allows >>you to operate on arrays of fixed size. I was wondering if something >>similar exists for strings, in particular, providing buffer-overflow safe >>string operations. >> >>I have an nstring< std::size_t n > string class that provides size-safe >>copying and comparison, allowing for you to do things like: > > That's an excellent direction in which to be moving. > > How far can we go in replacing unsafe C strings? With >the endless reports of buffer overflow exploits, anything >that can be done in that direction would help. This was the motivation for designing the class: to allow safe string operations with a clean, easy-to-use interface. I have attached the source below. Note that this is still a work-in-progress and as such is not yet complete. > I'd suggest a class with the following properties: > > Fixed-allocated strings, with length information. > No calls to "new". Typical usage would be something like: boost::char_string< 15 > str; str.copy( "Hello World!" ); NOTE: there is not yet an operator=. The formatterex class is to support sprintf-like operations and can be used like this: error_message( boost::formatterex< 1024 >( "[%s]: %s", severity, msg )); > Supports most of the operations allowed for STL strings. Good idea - this will help shifting between both classes. > Also supports the "classic" C string operations, like > "sprintf", "strlen", etc., using the classic C syntax for them. Also a good idea. But where should these reside? In the global namespace, std namespace or boost namespace? > Implicit conversion to "const char*", but not "char *", for > compatibility with existing library calls. Done. > Fully protected against overflow. I hope that this is the case, although if any bugs are spotted, I'd appreciate feedback so I can fix them. Note that the const char ( & )[ m ] versions are to support string literals. > It might also be worthwhile to provide "sprintf", "strlen", etc. >for STL strings. This is where things get tricky. Where do we place these overloads? Like with the others (char_string) there is the question of how to be compatible with the existing std+global namespace versions. Note that this is complicated by the fact that the functions exist in the global namespace and are using-imported into the std namespace in (all?) existing implementations. I would suggest having something like a boost::string namespace, where these overloads (plus wchar_t overloads) of strlen, etc are placed. It may be that the implementations need to be placed directly in the global namespace, but I don't know what impact that would have. > The basic idea is that this should be retrofittable to old code >without major efforts. Ideally, you go through the code with >a program, replacing "char foo[nnn]" with "char_array<nnn> foo", >and "char *" with "char_array&", and it mostly works. Everything >that doesn't work gets a compile-time error. You fix all the compile >time errors, and your program is overflow-proof, at least in >this area. On my to-do list for this class is to add wchar_t support and support for a traits class (char_traits?) as well as completing the implementation. Let me know what you thing. Regards, Reece ===== // (C) Copyright 2003-2004: Reece H. Dunn #ifndef BOOST_CHAR_STRING_HPP #define BOOST_CHAR_STRING_HPP # include <cstring> namespace boost { template< std::size_t n > class char_string { private: char str[ n ]; public: // access inline operator const char *() const { return( str ); } public: inline const char * c_str() const { return( str ); } inline std::size_t size() const { return( n ); } public: // copy inline void copy( const char * s, std::size_t l ) { ::strncpy( str, s, ( l > n ) ? n : l ); } inline void copy( const char * s ) { copy( s, ::strlen( s )); } inline void copy( const char_string< n > & s ) { ::strncpy( str, s, n ); } template< std::size_t m > inline void copy( const char( & s )[ m ] ) { copy( s, m ); } public: // comparison inline int comp( const char * s, std::size_t l ) const { return( ::strncmp( str, s, ( l > n ) ? n : l )); } inline int comp( const char * s ) const { return( comp( s, ::strlen( s ))); } inline int comp( const char_string< n > & s ) const { return( ::strncmp( str, s, n )); } template< std::size_t m > inline int comp( const char( & s )[ m ] ) const { return( comp( s, m )); } public: inline char_string() { str[ 0 ] = '\0'; } }; template< std::size_t n > bool operator==( const char_string< n > & a, const char_string< n > & b ) { return( a.comp( b ) == 0 ); } template< std::size_t n, std::size_t m > bool operator==( const char_string< n > & a, const char( & b )[ m ] ) { return( a.comp( b ) == 0 ); } template< std::size_t n, std::size_t m > bool operator==( const char( & b )[ m ], const char_string< n > & a ) { return( a.comp( b ) == 0 ); } // formatter -- sprintf-like operations template< std::size_t n > class formatterex: public char_string< n > { public: inline const char * operator()( const char * fs ... ) throw() { va_list args; va_start( args, fs ); _vsnprintf( *this, n, fs, args ); va_end( args ); return( *this ); } public: inline formatterex( const char * fs ... ) throw() { va_list args; va_start( args, fs ); _vsnprintf( *this, n, fs, args ); va_end( args ); } inline formatterex() throw() { } }; typedef formatterex< 512 > formatter; } #endif _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Writing fully custom containers for the bgl
by Pierre DOUCY 07 May '04

07 May '04

I have written a custom container for the bgl's adjacency_list which was based on a subclass of a stl container (namely, std:list). Everything seemed to work just fine (if not by itself) as I followed the bgl book indications. Now, I'm working on a non stl-based container (a wrapper around the bdb API), and facing a lot of compile-time problems. I know my bdb wrapper is not fully stl-compliant. So my question is : if I make this wrapper fully standard-compliant (for instance by using boost::iterator and by implementing everything the stl tells me to implement in a AssociativeContainer or a MultipleAssociativeContainer), will the bgl play nicely with it (i.e. as if it was a std::map, for instance) ? If not, what should I do to be able to use my containers with the bgl. I haven't found any examples out there, and wondered if anyone tried (and succeded) in this task. My second question is : how and when does the adjacency_list instantiates its containers, and is there any way to mess with it, by passing special arguments to the containers when instatiating my graph ? Reading the code and following the process in a debugger doesn't really make my ideas clearer. Thanks in advance for any help and/or ideas Pierre -- Written slowly for people who can't read fast.

3 2

small enable_if documentation or header bug
by Richard Peters 06 May '04

06 May '04

The documentation of enable_if reads: 3 Using enable_if The enable_if templates are defined in boost/utility/enable_if.hpp, which is included by boost/utility.hpp. but the header boost/utility/enable_if.hpp is not included by boost/utility.hpp. best regards, Richard Peters

3 3

Re:[boost] Re: Re: Re: Using Serialization for binary
by brangdon＠cix.compulink.co.uk 06 May '04

06 May '04

In-Reply-To: <20040506033527.A2765313DF(a)acme.west.net> ramey(a)rrsd.com (Robert Ramey) wrote (abridged): > > > Specifically, I'd use a byte oriented scheme where the low 7 bits of > > > each byte contribute to the current number, and the high bit says > > > whether there are more bytes to come. > > That's the way it's done in demo_portable_binary_archive included in the > current serialization package. Yes. Demo_portable_binary_archive stores a length byte followed by the bytes needed. I specifically wanted to suggest an alternative to that. Using a bit from each byte means that small integers take half as much space as with your format. Some numbers of bytes: Integer Length Byte High Bit 0 2 1 10 2 1 100 2 1 1000 3 2 10000 3 2 100000 4 3 In practice most integers are small. Eg most archive version numbers will be below 100. -- Dave Harris, Nottingham, UK

1 0

RE: [boost] pool_alloc with Pair Associative Container?
by SCleary＠jerviswebb.com 06 May '04

06 May '04

Your declaration looks correct to me. hash_map is part of SGI's STL/STLPort. It will support Standard C++ Allocators IF the underlying compiler is capable of it (requires member template support). Otherwise, it has a nice fallback mechanism that uses its own form of STLPort Allocator. pool_alloc provides a Standard C++ Allocator; it does not support the STLPort Allocator interface. So, it sounds like you're using a compiler that is not capable of supporting Standard C++ Allocators properly. -Steve -----Original Message----- From: Thomas [mailto:hazard@imsa.edu] Sent: Wednesday, May 05, 2004 4:45 PM To: boost(a)lists.boost.org Subject: [boost] pool_alloc with Pair Associative Container? Can someone give me an example of how to use the boost pool_alloc allocator interface with a Pair Associative Container, like hash_map? I tried doing something like typedef hash_map<long long,double,longLongHasher,boost::pool_allocator< pair<const long long,double> > > tLongLongToDoubleHashMap; ,,,but I get errors when I try to compile code that actually uses tLongLongToDoubleHashMap. Thanks! Thomas -- Thomas <hazard(a)imsa.edu> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[bind] bug for vc7.1
by John Torjo 06 May '04

06 May '04

#include <boost/bind.hpp> using namespace boost; #include <vector> struct base { int i; }; struct test : public base { // if you uncomment here and comment above, it'll work // int i; }; int main() { typedef std::vector<test> vector; vector v; // generates compile-time error on vc7.1 bind<int&>( mem_fn(&test::i), _1) (v.front()); return 0; } Peter, any workarounds, until its' fixed? Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 3