- Boost - lists.boost.org

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 07 May '04

07 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

Re: Re: Re:boost::serialization Remarks
by martin.ecker＠tab.at 06 May '04

06 May '04

Jeff, > Although, I am having problems with my > VC71 MFC application reporting memory > leaks of a 24byte block corresponding > to each shared_ptr loaded from an > oarchive. You probably mean "loaded from an iarchive". Anyway, due to the modifications I've made in our local code base of boost::serialization I had a bit of a look through the code. I'm not sure, but the memory leaks you experience could possibly be related to the fact that basic_iarchive::delete_created_pointers is never called. Maybe you can add a call to this function yourself somewhere in your application (delete_created_pointers is a public member function of basic_iarchive) and see if the memory leaks disappear. Note that this is just a guess on my part, as I haven't had time to look at all the code in detail. In reference to the example you posted, you could change it to not use an empty shared_ptr but actually allocate an object for it and then change the deserialization code to: if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); ia & boost::serialization::make_nvp( "SomeClass", lSomeClass ); ia.delete_created_pointers(); } Regards, Martin TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

2 1

signal lib broken in current cvs version
by Vasco Lohrenscheit 06 May '04

06 May '04

Hello, I'm not sure where to best report it, but the current cvs version of the signal lib is broken: errors occur in named_slot_map.cpp/named_slot_map.cpp resp. iterator_facade.hpp (using vc7.1). One problem is a syntax error in named_slot_map.cpp line 91 and then methods decrement and advance are missing (resulting in an error in iterator_facade.hpp). best regards, Vasco Lohrenscheit

2 1

Re: Re: Re:boost::serialization Remarks
by Robert Ramey 06 May '04

06 May '04

Martin Ecker wrote: > > Although, I am having problems with my > > VC71 MFC application reporting memory > > leaks of a 24byte block corresponding to each shared_ptr loaded from > > an oarchive. > I'm not sure, but the memory leaks you experience could possibly be > related to the fact that basic_iarchive::delete_created_pointers is never > called. Maybe you can add a call to this function yourself somewhere in > your application (delete_created_pointers is a public member function of > basic_iarchive) and see if the memory leaks disappear. The intended purpose of delete_created_pointers is to delete object created in the course of de-serializing a stream which has thrown an exception. Nothing more. One place you might want to look shared_ptr serialization. Serialization of shared_ptr starts out by initializing the shared pointer to NULL and adds references as things proceed. This might be a problem in the case where the shared_ptr is already pointing to something. Robert Ramey

1 0