June 2005 - Boost - lists.boost.org

[iostreams] 64-bit patch for gzip
by Markus Schöpflin 10 Jun '05

10 Jun '05

Currently the gzip test fails on 64-bit system because of 32/64-bit issues in 'iostreams/filter/gzip.hpp'. Attached patch fixes this, and additionally renames the functions read_byte() to read_uint8() and read_long() to read_uint32() as this is what they actually do. The patch has been tested on a 32 bit system (Linux/GCC 3.4.2) and on a 64 bit system (Tru64/CXX 6.5-042, GCC 3.4.3). Ok to commit? Markus Index: filter/gzip.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iostreams/filter/gzip.hpp,v retrieving revision 1.14 diff -u -w -r1.14 gzip.hpp --- filter/gzip.hpp 20 May 2005 04:11:11 -0000 1.14 +++ filter/gzip.hpp 8 Jun 2005 09:12:39 -0000 @@ -353,21 +353,21 @@ static gzip_params make_params(int window_bits); template<typename Source> - static int read_byte(Source& src, int error) + static uint8_t read_uint8(Source& src, int error) { int c; if ((c = boost::iostreams::get(src)) == EOF || c == WOULD_BLOCK) throw gzip_error(error); - return static_cast<unsigned char>(traits_type::to_char_type(c)); + return static_cast<uint8_t>(traits_type::to_char_type(c)); } template<typename Source> - static long read_long(Source& src, int error) + static uint32_t read_uint32(Source& src, int error) { - int b1 = read_byte(src, error); - int b2 = read_byte(src, error); - int b3 = read_byte(src, error); - int b4 = read_byte(src, error); + uint8_t b1 = read_uint8(src, error); + uint8_t b2 = read_uint8(src, error); + uint8_t b3 = read_uint8(src, error); + uint8_t b4 = read_uint8(src, error); return b1 + (b2 << 8) + (b3 << 16) + (b4 << 24); } @@ -412,16 +412,17 @@ { throw gzip_error(gzip::bad_header); } - mtime_ = read_long(src, gzip::bad_header); // MTIME. - read_byte(src, gzip::bad_header); // XFL. - os_ = read_byte(src, gzip::bad_header); // OS. + mtime_ = read_uint32(src, gzip::bad_header); // MTIME. + read_uint8(src, gzip::bad_header); // XFL. + os_ = read_uint8(src, gzip::bad_header); // OS. if (flags & boost::iostreams::gzip::flags::text) flags_ |= f_text; // Skip extra field. (From J. Halleaux; see note at top.) if (flags & gzip::flags::extra) { - int length = read_byte(src, gzip::bad_header) + - (read_byte(src, gzip::bad_header) << 8); + int length = static_cast<int>( + read_uint8(src, gzip::bad_header) + + (read_uint8(src, gzip::bad_header) << 8)); // length is garbage if EOF but the loop below will quit anyway. do { } while (length-- != 0 && !is_eof(boost::iostreams::get(src))); @@ -432,8 +433,8 @@ if (flags & gzip::flags::comment) // Read comment. comment_ = read_string(src); if (flags & gzip::flags::header_crc) { // Skip header crc. - read_byte(src, gzip::bad_header); - read_byte(src, gzip::bad_header); + read_uint8(src, gzip::bad_header); + read_uint8(src, gzip::bad_header); } } @@ -447,13 +448,11 @@ footer += c; detail::range_adapter<input, std::string> rng(footer.begin(), footer.end()); - if ( static_cast<unsigned long>(read_long(rng, gzip::bad_footer)) - != - this->crc() ) + if ( read_uint32(rng, gzip::bad_footer) != this->crc() ) { throw gzip_error(gzip::bad_crc); } - if (read_long(rng, gzip::bad_footer) != this->total_out()) + if (static_cast<int>(read_uint32(rng, gzip::bad_footer)) != this->total_out()) throw gzip_error(gzip::bad_length); } enum {

3 6

XML report generating library
by Tony Han Bao 10 Jun '05

10 Jun '05

Dear Boosters, I'm looking for a library that handles XML format report generating. What I need is to generate a standard XML format document object and make it streamable to an output stream. Is there a library in the current Boost release that can do this? If not, is there one planned for future release? Thanks in advance.

1 0

RE: Serialization with private destructors
by Marcin Tustin 10 Jun '05

10 Jun '05

I should have said *protected* destructors. > -----Original Message----- > From: Marcin Tustin > Sent: 10 June 2005 10:51 > To: boost(a)lists.boost.org > Subject: Serialization with private destructors > > > The classes that I am trying to serialize all have > private destructors (and constructors - they are intended to > be accessed through a factory function that returns a smart > pointer). Is there any way serialize such classes beyond > modifying the headers of these classes (I don't have the > source) to include "friend class boost::serialization::access;"? > > Marcin Tustin > IT Innovation Centre > 2 Venture Road > Chilworth Science Park > Southampton, SO16 7NP, UK > > tel: +44 23 8076 0834 > fax: +44 23 8076 0833 > > mailto:mt@it-innovation.soton.ac.uk > http://www.it-innovation.soton.ac.uk >

1 0

Serialization with private destructors
by Marcin Tustin 10 Jun '05

10 Jun '05

The classes that I am trying to serialize all have private destructors (and constructors - they are intended to be accessed through a factory function that returns a smart pointer). Is there any way serialize such classes beyond modifying the headers of these classes (I don't have the source) to include "friend class boost::serialization::access;"? Marcin Tustin IT Innovation Centre 2 Venture Road Chilworth Science Park Southampton, SO16 7NP, UK tel: +44 23 8076 0834 fax: +44 23 8076 0833 mailto:mt@it-innovation.soton.ac.uk http://www.it-innovation.soton.ac.uk

1 0

Iterator adaptors <-> boost::bind interaction
by Aleksey Gurtovoy 10 Jun '05

10 Jun '05

The following code currently fails to compile because of a subtle interaction between bind-produced function objects and the current implementation of transform_iterator's 'dereference' function (the same applies to 'filter_iterator' and most likely the rest of the adaptors in the library): #include <boost/iterator/transform_iterator.hpp> #include <boost/bind.hpp> int add_two( int x ) { return x + 2; } int main() { int x[] = { 0 }; *boost::make_transform_iterator( boost::make_transform_iterator( x, boost::bind( &add_two, _1 ) ) , boost::bind( &add_two, _1 ) ); } The problem here is that the result of 'boost::bind( &add_two, _1 )' takes its argument by reference, while transform_iterator's 'dereference' implementation is: typename super_t::reference dereference() const { return m_f(*this->base()); } ^^^^^^^^^^^^^ In our case, '*this->base()' produces a temporary 'int' which cannot be directly passed to 'm_f'. Effectively, the issue prevents you from layering any iterator adaptors built with 'boost::bind' on top of 'transform_iterator', which, needless to say, is BAD. My sugesstion would be to replace the above with typename super_t::reference dereference() const { typename iterator_reference<Iterator>::type x( *this->base() ); return m_f( x ); } Comments? -- Aleksey Gurtovoy MetaCommunications Engineering

2 13

Serialization: using xml archives?
by Oliver Kullmann 10 Jun '05

10 Jun '05

Hello, I want to build up a database of timing results, and these timing results should be stored in xml-files. It seems that the only library in Boost providing xml-functionality is the Serialization library. Now in principle it could work fine: Basically I could create a struct with string tags describing the timing context, and a container with the timing results; via serialisation I write it to an xml-archive, and as additional bonus I also can read it back. However I have the following concerns: 1. The xml-archives must be human-readable. 2. The xml-archives should be also usable with other xml applications. Regarding 1., it seems that readability for the current output is kind of alright --- but this doesn't seem to be guaranteed for the future? Brings me to point 2: It seems that the xml-format is not specified, and thus is a kind of "proprietary file format", changed at will with new releases --- is this the intention, or not?! To me it would make perfect sense, that at least the xml-archives can be used by other applications, and for that there should be a document type definition (dtd) available for each archive, and furthermore the general structure should be standardised. But perhaps this is not intended for this library. I would be glad for any comments. Thanks! Oliver

2 1

[iostreams] Docu Bug
by Bertolt Mildner 10 Jun '05

10 Jun '05

The link to Windows binaries of zlib in /libs/iostreams/doc/classes/zlib.html (pointing to http://www.gzip.org/zlib/contrib/index.html) leads to Win16 binaries only! Probably it should be changed to: http://www.gzip.org/zlib/index.html Same for bzip2 in /libs/iostreams/doc/classes/bzip2.html (no link corrently). Probably should be http://www.digistar.com/bzip2/ . Bertolt PS: Please note that i didn't do any tests with this binaries! PPS: Just saw that the bjam output for missing bzip2 support on Win32 is: ****************************************************** Building Boost.Iostreams with bzip2 support disabled. ECHO To enable bzip2, cons ult the Boost.Iostreams documentation ******************************************************

2 1

[interval] suggestions and minor doc error
by Mark Gilbert 10 Jun '05

10 Jun '05

In my own code, I have long used a type similar to boost::interval. In my class, I find these functions useful: T center() const { return (low + up) / 2; } T extent() const { return up - low; } T clamp(T t) const { return t < low ? low : t > up ? up : t; } T wrap(T t) const { return fmodpos(t - low, extent()) + low; } T evaluate(T t) const { return low + t * extent(); } T normalize(T t) const { return (t - low) / extent(); } clamp provides a convenient way to limit a value, changing this ugly thing: double x = max(lower, min(upper, raw_x)); to this: double x = interval(lower, upper).clamp(raw_x); evaluate and normalize map the interval to a normalized interval with values in the range [0,1]. The minor documentation error is at (http://www.boost.org/libs/numeric/interval/doc/interval.htm) where it says, ". . . rounding a+b down and c+d up will suffice." Shouldn't that say "a+c down and b+d up"? Thanks for the good work on this class, Mark Gilbert

3 2

Announcement: Synopsis 0.8
by Stefan Seefeld 09 Jun '05

09 Jun '05

I'm pleased to announce the release of Synopsis 0.8. Synopsis is a multi-language source code introspection tool that provides a variety of representations for the parsed code, to enable further processing such as documentation extraction, reverse engineering, and source-to-source translation. While this release mainly focusses on an internal redesign, there are nevertheless a number of major enhancements and new features: * Synopsis contains a new C Parser. * The C++ parser contains lots of bug fixes. * The HTML formatter contains a number of bug fixes. Synopsis' internals have been largely redesigned, to eventually expose public C++ and python APIs to the lower-level code representations such as parse trees or symbol tables. It currently contains experimental code to use synopsis as a scriptable source-to-source compiler, though these APIs are still in development. Due to limitations of its C/C++ preprocessor, synopsis is presently not able to parse the current boost code. (For an example of an older boost snapshot, see http://synopsis.fresco.org/boost/) However, the sandbox already contains a new preprocessor based on boost.wave, which will be moved into mainline as soon as boost 1.33 is released. Source and documentation is available at http://synopsis.fresco.org. For contact information, see http://synopsis.fresco.org/contact.html.

1 0

RE: [boost] [ann]Fast_lookup - first snapshot available
by Brian Braatz 09 Jun '05

09 Jun '05

Looks interesting. I wasn't able to find the performance tests though. Also- I wonder if a better name might be found. maybe simply "associative_vector"- but that is a lot of typing. hmmm... or maybe come up with a name for the body of libraries (containters) that you intend to implement. something like Boost.supercontainers Hmm... (quick check on http://thesaurus.reference.com for the word "speed"): Main Entry: speed Part of Speech: noun Definition: rate Synonyms: acceleration, activity, agility, alacrity, breeze, briskness, celerity, clip, dispatch, eagerness, expedition, fleetness, gait, haste, headway, hurry, hustle, legerity, lick, liveliness, momentum, pace, precipitancy, precipitation, promptitude, promptness, quickness, rapidity, rapidness, readiness, rush, rustle, snap, steam, swiftness, ton, urgency, velocity hmmm... none of that is working very well one other suggestion: boost.optocontainters (i.e. for optimized) I hope that helps or sparks an idea. Brian > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Mikhail Glushenkov > Sent: Wednesday, June 08, 2005 3:26 PM > To: boost(a)lists.boost.org > Subject: [boost] [ann]Fast_lookup - first snapshot available > > First snapshot of the to-be proposed Fast_lookup library is available > for download at the vault. > Direct link (watch for line breaks!): > http://boost-sandbox.sourceforge.net/vault/index.php?&order= > &directory=fast_lookup > Sorry, no documentation as of yet. > > Fast_lookup provides "sorted vector"-based versions of standard > associative > containers, thus embracing the common practice. > > Highlights of this release: > * map and set have been implemented > * Two different storage policies - 'default' and KeepKeysSeparate, which > is > usually faster, but takes more memory > * Out-of-the-box support for Boost.Serialization > > I haven't done any significant optimizations yet, but the performance > tests are > in, and they show that we are in pretty good shape(compared to > Loki::AssocVector). > Fast_lookup currently does not work on vc6 though I've made some initial > stabs > at this problem. > > Since I'm going on vacation starting from this Friday, the next snapshot > will > likely be posted in August. Planned features include multiset and multimap > + > indirect storage(some parts of pointer_containers library will be probably > reused) > > Any suggestions, comments, feature requests or critique are welcome. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0