- Boost - lists.boost.org

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 09 Jun '05

09 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

RE: [boost] Re: meta-double
by Martin Bonner 09 Jun '05

09 Jun '05

> Rob Stewart <stewart(a)sig.com> writes: >> AFAIK, the only thing you can say about the size of int is that >> it must handle the INT_MIN to INT_MAX range on a given platform >> and the only thing you can say about short is that it is no >> bigger than int and at least one byte. >> Have I missed something that requires both to be at least 16 >> bits? David Abrahams <dave(a)boost-consulting.com> writes: > Yes. That's a bit gnomic. What you have missed Rob is that the standard requires SHRT_MIN <= -32767 and SHRT_MAX >= 32767. That implies short must have at least 16 bits. There is a similar requirement on long that means it must be at least 32 bits. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 3

Announcement: Library-Centric Software Design (LCSD 05)
by jarvi 09 Jun '05

09 Jun '05

The following call for papers should be of interest to many in the Boost community. For more information, see http://lcsd05.cs.tamu.edu Posting the announcement has been approved by Boost moderators. Best, Jaakko Järvi ----------------------------------------------------------------------- LIBRARY-CENTRIC SOFTWARE DESIGN - LCSD'05 Workshop, on Sunday, October 16, 2005 at the Object-Oriented Programming, Systems, Languages and Applications (OOPSLA'05) conference in San Diego, California, October 16-20, 2005 CALL FOR PAPERS Libraries are central to all major scientific, engineering, and business areas, yet the design, implementation, and use of libraries are underdeveloped arts. This workshop is one of the first steps in the process of placing all aspects of libraries on a sound technical and scientific basis through research into fundamental issues and documentation of best practices. A software library is an organized collection of code with associated tools supporting programming in general or in specific domains, usually united by a specified set of principles and conventions. Most libraries are aimed at the use by several people and in different environments. The areas of software library research include * Design and implementation of libraries * Program and system design based on libraries * Libraries supporting specific application domains, such as biology and banking * Evolution, refactoring, and maintenance of libraries * Empirical studies of library use * Performance of libraries, including benchmarking and library-based optimizations * Design of language facilities and tools in support of library definition and use * Validation, debugging, and testing of libraries * Extensibility, parameterization, and customization * Distribution of libraries * Specification of libraries and their semantics * Usability for library users and developers * Assessing quality of libraries * Documentation and teaching of libraries * Creating and supporting communities of library users * Using several libraries in combination We invite the submission of extended abstracts on software library research, including, but not limited to, the above list of topics. The extended abstracts should address issues important to libraries as a field, i.e., describe ideas or techniques that can be reused for libraries across problem domains and/or languages; they should refrain from merely describing a particular library, no matter how novel the choice of domain. As an additional criterion, the extended abstracts are reviewed against suitability for a journal publication of the corresponding full paper. For uniformity, authors should use the latest ACM SIGS conference style file (option 1) at http://www.acm.org/sigs/pubs/proceed/template.html. Submissions should be limited to 10 pages in this style. Accepted extended abstracts will be posted on the workshop's Web site prior to the workshop, and collected in a proceedings published as a Rensselaer Polytechnic Institute tech report. Authors of selected papers will be invited to submit a full paper for a special issue of a journal, to be announced later. IMPORTANT DATES Jul 31 Submission of extended abstracts Sep 9 Notification of acceptance Oct 4 Final version posted on workshop Web site Oct 16 Workshop SUBMISSION PROCEDURE For details of the electronic submission procedure, see the workshop's Web site, http://lcsd05.cs.tamu.edu. ORGANIZERS * David Musser, Rensselaer Polytechnic Institute * Andrew Lumsdaine, Indiana University * Jaakko Jarvi, Texas A&M University * Sibylle Schupp, Chalmers University of Technology * Todd Veldhuizen, Indiana University * Jeremy Siek, Rice University Primarily, the email address lcsd05(a)cs.tamu.edu should be used for questions addressed to the organizers. PROGRAM COMMITTEE Not yet finalized, but the following are confirmed: * Uwe Assmann, Technical University of Dresden * Matt Austern, Google Inc. * Herve Broennimann, Polytechnic University * Antonio Cisternino, University of Pisa * Jack Dongarra, University of Tennessee * Ulrich Eisenecker, University of Leipzig * Calvin Lin, University of Texas at Austin * Alex Stepanov, Adobe Systems Inc. * Bjarne Stroustrup, Texas A&M and AT&T Labs * Frank Tip, IBM Research In addition, the organizers will serve as program committee members. WORKSHOP GOALS AND ACTIVITIES The workshop establishes a scientific forum for presenting original research in the design, implementation, and evaluation of software libraries. Other major activities include the identification of open questions specific to library research and the discussion of a strategic plan for establishing library research as a field. The outcome of the workshop is a combination of research contributions and specific next steps for improving the infrastructure for library research. Participants are expected to read the accepted submissions beforehand. The technical presentations, although based on the accepted papers, should not provide mere summaries of the papers. Instead, authors are encouraged to use their presentation slots (20 + 10 mins) to bring up topics for discussion. The technical presentations are mixed with scientific and organizational discussions. The discussions aim at furthering the topics of the presentations, thus their agenda will be publicly discussed among the participants and then posted on the website of the workshop. All participants are expected to come prepared with their tentative answers or thoughts. The full-day workshop starts with a keynote talk for the stimulation of discussion and concludes with a plenary discussion that decides the specific next steps for improving the infrastructure for library research. FOR MORE INFORMATION AND UPDATES please visit the workshop's Web site, http://lcsd05.cs.tamu.edu. _______________________________________________

1 0

[ann]Fast_lookup - first snapshot available
by Mikhail Glushenkov 09 Jun '05

09 Jun '05

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.

4 7

share_ptr serialization
by Robert Ramey 09 Jun '05

09 Jun '05

In the course if making a new shared_ptr seriailzation implementation, I've come upon a question. If a shared pointer has been created with a custome deleter, how is one to determine what kind of deleter is attached without opening the implementation of shared_ptr? That is, I see no way to correctly serialize/deserialize a shared_ptr with a custom deleter from the published interface of shared_ptr. Can anyone explain how to do this? Robert Ramey

3 2