- Boost - lists.boost.org

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

Bug in signals library
by Алексей Суббота 06 May '04

06 May '04

There is bug at boost/signals/detail/config.hpp: Before #ifdef BOOST_HAS_DECLSPEC must be #include <boost/config.hpp> Without it line dll's version does't export nothing.

2 1

[Boost-bugs] [ boost-Bugs-949189 ] typos in wrapping_int.hpp
by SourceForge.net 06 May '04

06 May '04

Bugs item #949189, was opened at 2004-05-06 15:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=949189&group_i… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pieter (morban) Assigned to: Jeff Garland (az_sw_dude) Summary: typos in wrapping_int.hpp Initial Comment: In the following code: template<typename int_type_, int_type_ wrap_min, int_type_ wrap_max> class wrapping_int2 { public: typedef int_type_ int_type; static unsigned long wrap_value() {return wrap_max;} static unsigned long min_value() {return wrap_min;} ... the last two lines should probably read (changing return types and the first function's name): static int_type max_value() {return wrap_max;} static int_type min_value() {return wrap_min;} May I suggest renaming this class to "top_wrapping_int" in reaction to the comment above it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=949189&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Formal review] Collection Traits library review ends tomorrow
by hartmutkaiser＠t-online.de 06 May '04

06 May '04

Hi all, Just wanted to remind you, that the formal review of the Collection Traits library written by Thorsten Ottosen ends tomorrow, May 7th, 2004. Please submit your reviews until then, if you haven't already. Regards Hartmut Review Manager

1 0

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

06 May '04

In-Reply-To: <95C853D0-9EAF-11D8-BFD9-000A95DC1C98(a)itp.phys.ethz.ch> troyer(a)itp.phys.ethz.ch (Matthias Troyer) wrote (abridged): > As I see it the current serialization library allows both options, > depending on your preferences. Any archive may choose which types it > view as fundamental, but both have their disadvantages: I would use variable length integers. Use as many bytes as you need for the integer's actual value. That way the archive format is independent of whether short, int, long or some other type was used by the outputting program. It can also give you byte order independence for free. 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. void load( uintmax_t &result ) { result = 0; while (true) { unsigned char byte; *this >> byte; result = (result << 7) | (byte & 0x7f); if ((byte & 0x80) == 0) return; } } Thus integers less than 128 take 1 byte, less than 16,000 take 2 bytes etc. This gives a compact representation while still supporting 64-bit ints and beyond. You can use boost::numeric_cast<> or similar to bring the uintmax_t down to a smaller size. -- Dave Harris, Nottingham, UK

4 4

Re: static sized strings
by John Nagle 06 May '04

06 May '04

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. I'd suggest a class with the following properties: Fixed-allocated strings, with length information. No calls to "new". Supports most of the operations allowed for STL strings. Also supports the "classic" C string operations, like "sprintf", "strlen", etc., using the classic C syntax for them. Implicit conversion to "const char*", but not "char *", for compatibility with existing library calls. Fully protected against overflow. It might also be worthwhile to provide "sprintf", "strlen", etc. for STL strings. 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. John Nagle Team Overbot

1 0

Re:[boost] Re: Re: Re: Using Serialization for binary
by Robert Ramey 06 May '04

06 May '04

Ian McCulloch wrote: > > Dave Harris wrote: > > > In-Reply-To: <95C853D0-9EAF-11D8-BFD9-000A95DC1C98(a)itp.phys.ethz.ch> > > troyer(a)itp.phys.ethz.ch (Matthias Troyer) wrote (abridged): > >> As I see it the current serialization library allows both options, > >> depending on your preferences. Any archive may choose which types it > >> view as fundamental, but both have their disadvantages: > > > > I would use variable length integers. Use as many bytes as you need for > > the integer's actual value. That way the archive format is independent > of > > whether short, int, long or some other type was used by the outputting > > program. It can also give you byte order independence for free. > > > > 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. > [...] > > Thus integers less than 128 take 1 byte, less than 16,000 take 2 bytes > > etc. This gives a compact representation while still supporting 64-bit > > ints and beyond. You can use boost::numeric_cast<> or similar to bring > the > > uintmax_t down to a smaller size. > > Nice idea. I was thinking along the lines of how to achieve > high-performance, with shared memory & fast network message passing in > mind. I think now though, this is probably too specialized an application > for boost::serialization. > That's the way it's done in demo_portable_binary_archive included in the current serialization package. Robert Ramey

1 0

signals and threads
by David Abrahams 06 May '04

06 May '04

So, we're thinking of using the signals library in one of our projects, but the lack of thread-safety is a concern for us. What issues are preventing Boost.Signals from being made threadsafe? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 6