- Boost - lists.preview.boost.org

[chrono] Motivation for Boost version evaporating
by Beman Dawes 13 May '09

13 May '09

The motivation for a Boost version of <chrono> seems to be evaporating since GCC 4.4.0 has shipped with an implementation and Microsoft has also signaled they intend to ship a C++0x standard library implementation sooner rather than later. Thus I'm no longer interested in working on a Boost version. If anyone else would like to take it on, that's OK with me, but I don't see enough benefit to Boost to make the effort worthwhile. --Beman

3 4

Re: [boost] Boost Bug Sprint Proposal
by Beman Dawes 13 May '09

13 May '09

On Tue, May 12, 2009 at 11:08 PM, Marshall Clow <marshall(a)idio.com> wrote: > A few weeks ago, Doug proposed a "Boost Bug Sprint", modeled on the Debian > one; to clean up the backlog of bugs, patches and feature request that have > grown in the Trac system. > > We currently have about 800 open issues. > > I am proposing that we start on Friday, May 29th and finish on Sunday, June > 7th. > That gives us a work week and two weekends, making time for both people who > can work during the week, and those who only have time to contribute to > boost on the weekends. Great idea! Those dates look good and I've added them to the Boost calendar. --Beman

1 0

Re: [boost] Boost Bug Sprint Proposal
by Daniel James 13 May '09

13 May '09

2009/5/13 Marshall Clow <marshall(a)idio.com>: >> What can you do? >> >> 1) You can fix bugs. >> * If you are a library author, you can commit changes. >> * If you are not a library author, you can fix a problem on your local >> machine (and test it!!), and then attach your fix as a patch to the Trac >> ticket for the library author to commit. If you do this, please provide a >> test case that exercises the problem; i.e, one that fails w/o your patch, >> and succeeds afterwards. I think library authors should also try to be more readily available for that week, maybe on IRC or by subscribing to the bug list. Daniel

1 0

[property_tree] streaming operators
by Chris Meyer 13 May '09

13 May '09

More on property_tree: It would be nice if the default translator did not use the << and >> operators by default. In my software, I use << to stream a debugging description of an object -- so it is useless for archiving purposes. Instead, the detail::translator could define and use template <class Ch, class T> inline void writeToStream(std::basic_ostream<Ch> &os, const T &value) { os << value; } template <class Ch, class T> inline void readFromStream(std::basic_istream<Ch> &is, T &value) { is >> value; } Then clients of the library would have more flexibility in implementing the streaming operations by providing specializations of these functions. (These functions would be used in place of the stream >> and << calls in detail::extractor::operator() and it's specializations). Is this list the right place for these requests or is there a better place to put them so that they get tracked?

2 1

property_tree iterators
by Chris Meyer 13 May '09

13 May '09

I've been using property_tree and it is very useful to me. It's easy to add typed data to the tree using something like MyType myvar[10]; for (i=0; i<10; ++i) pt.put(key, myvar[i], true); I can also implement my own translator to convert MyType to a string suitable for serializing to XML, JSON, or whatever. However, if I go to retrieve this data, things are less refined. Iterating over all elements with a given key requires something like this: ptree::key_compare comp; BOOST_FOREACH(ptree::value_type &v, pt) { if (!comp(v.first, key) && !comp(key, v.first)) { MyType myvar = convertStringToMyType(v.second.data()); doSomething(myvar); } } Perhaps there should be a templatized member function which uses the translator to automatically iterate all values of a particular key and have it converted to the desired data type. Then I could use something like: BOOST_FOREACH(MyType myvar, pt.get_all<MyType>(key)) { doSomething(myvar); } Is this possible? Or is there something I'm missing from the existing API that allows me to do this?

2 1

Boost Bug Sprint Proposal
by Marshall Clow 13 May '09

13 May '09

A few weeks ago, Doug proposed a "Boost Bug Sprint", modeled on the Debian one; to clean up the backlog of bugs, patches and feature request that have grown in the Trac system. We currently have about 800 open issues. I am proposing that we start on Friday, May 29th and finish on Sunday, June 7th. That gives us a work week and two weekends, making time for both people who can work during the week, and those who only have time to contribute to boost on the weekends. I am putting this out for comments: --- Proposal --- >What can you do? > >1) You can fix bugs. >* If you are a library author, you can commit changes. >* If you are not a library author, you can fix a problem on your >local machine (and test it!!), and then attach your fix as a patch >to the Trac ticket for the library author to commit. If you do this, >please provide a test case that exercises the problem; i.e, one that >fails w/o your patch, and succeeds afterwards. > >2) You can characterize bugs. >* You can attempt to replicate the bug on your system(s), and attach >information that you discover to the Trac ticket. This will make it >easier for other people to solve the problem, even if you cannot. >* You can write test cases demonstrating the problem, and attach >them to the Trac ticket. >* You can determine if the bug still exists; sometimes they get >fixed, and the ticket never gets closed. > >3) You can test patches. >* Some of the tickets in the trac system contain patches - some are >quite old. You can install these patches on your system, and >determine if they (a) build, and (b) work. >* You can write test cases for the patches, and attach them to the ticket. > >4) You can help implement new features. >* There are a whole set of "feature requests" in the Trac system. If >you have an idea about one of these, you can add comments to the >trac system. You can attempt to implement these new features, and >attach the patch to the ticket. (Don't forget the test cases!!). > --- End Proposal --- Please let me know what you think, and I will post an updated version. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 1

Boost Libraries under development: Bitfields
by vicente.botet 13 May '09

13 May '09

Hi, I have adapted the Bitfield library from Emile Cormier with its permision. Boost.Bitfield consists of: a.. a generic bitfield traits class providing generic getter and setter methods. b.. a BOOST_BITFIELD_DCL macro making easier the definition of the bitfield traits and the bitfield getter and setter functions. struct X { typedef boost::ubig_32 storage_type; storage_type d0; typedef unsigned int value_type; BOOST_BITFIELD_DCL(storage_type, d0, unsigned int, d00, 0, 10); BOOST_BITFIELD_DCL(storage_type, d0, unsigned int, d01, 11, 31); }; The library is quite stable but I want to add some test with Boost.Endian before adding it to the formal review schedule list. Here is the link from which you can get the library code + documentation + test https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Bitf… I'd appreciate if people could take a look, test it on their compiler and give me some feedback. Thanks for all, _____________________ Vicente Juan Botet Escribá

2 2

[1.40.0] OK to build release?
by Beman Dawes 13 May '09

13 May '09

There has been little feedback on the 1.40.0 beta release. I'm hoping that is a good sign:-) Unless someone objects, I'll start building the actual release in an hour or so. --Beman

9 28

Boost Install Target
by Esben Stien 13 May '09

13 May '09

I guessed that I had to run bjam install and it worked, but this was not mentioned in the manual, getting started guide. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@ n n

2 1

[sorting] Implementation of histogram sort
by Jeremiah Willcock 12 May '09

12 May '09

Does the proposed Boost sorting library contain an implementation of histogram sort or some other in-place variant of bucket sort (American flag sort, etc)? I would like to use an integer sort for a problem I have but need to save as much memory as possible. Having one element of temporary storage per bucket is fine, though. -- Jeremiah Willcock

3 2

SafeInt library for Boost
by Omer Katz 12 May '09

12 May '09

Hi everyone, I am considering adding a safeInt library to Boost. If there are any suggestions regarding a special content of such a library, or any special implementation ideas, I'll be glad if you'd let me know. right now I plan to use a template class for it. I'll be glad to accept your comments. Regards, Ziv

1 0

structure alignment
by Christoph Macheiner 12 May '09

12 May '09

(Long-time reader, first-time poster) Hi all Recently I wanted to upgrade from 1.33 and got build errors in boost format. It is a quite large codebase which, for legacy reasons, has to be built with 1-byte structure alignment (this cannot easily be changed). The error comes from an boost::optional<boost::io::detail::locale_t> in boost/format/internal.hpp that wants to be 4-byte aligned (platform is Win32 vc9). Now I cannot just include this (or all) boost headers with 4- (or 8-)byte alignment because they include other std headers which have already been included before (with 1-byte alignment). Is there an easy solution to this that I am missing despite changing all includes? Is there information on such interdependencies somewhere? Or do I have to bite the bullet and include all standard headers with a suitable alignment. I am sorry if this has been discussed before, but I could not find anything. Thanks, Christoph.

1 0

[trac] version 1.39.0 in trac
by Michael Caisse 12 May '09

12 May '09

Version: Boost 1.39.0 needs to be added in trac for tickets. Thank you - Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

3 2

Bounded String
by vicente.botet 12 May '09

12 May '09

Hi, I was looking for a bounded capacity string and I have take a look to the review (2006) of the rejected FixedString library (http://www.boostpro.com/vault/index.php?action=downloadfile&filename=fixed_…) Here follows a brief compilation of the main points * A motivating use case was missing * the motivating example (printf) was not enough significant, when we have the choice we can always find a better class. * The design was not adapted to the goals * the inheritance hierarchy was considered to complicated needing an allocation * buffer overrun should be configurable - truncate, exception, assert, * The formating should be considered orthogonal to the fixed_string class The context where I need to use something like this class is: * the binary layout can not be modified and must be bounded due to legacy issues, Third Party Products interfaces, protocol messages format or bounded capacity strings on persistent databases. * overrun must be checked because otherwise the program can crash. I will propose to name it bounded_c_string (when _c_ stands for "C-style" but recalls also capacity) These are the requirements I would associate to such a class * the value must always be a C-string (so with a trailing '\0') * The layout of a bounded_c_string<N> class must be the same as its counterpart C-string char[N] (sizeof(bounded_c_string<N>==N) * As a lot of code can use this type the refactoring from C code using char[N] to bounded_c_string<N> should be reduced to the type declaration (overloading of all the C string functions with bounded_c_string<N> are a must) * the efficiency must be equivalent to the hand written C-style * convertible to and from C-strings, std::string and other bounded_c_string<M> * C++ std::string like interface must also be provided Note that there is not issues with the length of the string coherency because not stored. This class do not intends to use dynamic memory when fixed capacity is not enough (see AutoBuffer library http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip for this use case) I don't know which is the FixedString library, the last upload on the Vault dates from 08.01.2006. Is there an interest for this simple class? Do you agree with the requirements? Is there an interest for a bounded_c_memory class which will take care of the length of the significant data instead of the trailing '\0'? Best regards, _____________________ Vicente Juan Botet Escribá

2 1

[GIL.IO] Looking for a review manager
by Christian Henning 12 May '09

12 May '09

Hi there, I'm looking for a review manager for the new GIL.IO extension. Anyone around here who would like to volunteer? Regards, Christian

1 0

Requesting interest in a bounded capacity C-string
by vicente.botet 12 May '09

12 May '09

Hi, I was looking for a bounded capacity string and I have take a look to the review (2006) of the rejected FixedString library (http://www.boostpro.com/vault/index.php?action=downloadfile&filename=fixed_…) Here follows a brief compilation of the main points * A motivating use case was missing * the motivating example (printf) was not enough significant, when we have the choice we can always find a better class. * The design was not adapted to the goals * the inheritance hierarchy was considered to complicated needing an allocation * buffer overrun should be configurable - truncate, exception, assert, * The formating should be considered orthogonal to the fixed_string class The context where I need to use something like this class is: * the binary layout can not be modified and must be bounded due to legacy issues, Third Party Products interfaces, protocol messages format or bounded capacity strings on persistent databases. * overrun must be checked because otherwise the program can crash. I will propose to name it bounded_c_string (when _c_ stands for "C-style" but recalls also capacity) These are the requirements I would associate to such a class * the value must always be a C-string (so with a trailing '\0') * The layout of a bounded_c_string<N> class must be the same as its counterpart C-string char[N] (sizeof(bounded_c_string<N>==N) * As a lot of code can use this type the refactoring from C code using char[N] to bounded_c_string<N> should be reduced to the type declaration (overloading of all the C string functions with bounded_c_string<N> are a must) * the efficiency must be equivalent to the hand written C-style * convertible to and from C-strings, std::string and other bounded_c_string<M> * C++ std::string like interface must also be provided Note that there is not issues with the length of the string coherency because not stored. This class do not intends to use dynamic memory when fixed capacity is not enough (see AutoBuffer library http://www.cs.aau.dk/~nesotto/boost/auto_buffer.zip for this use case) I don't know which is the FixedString library, the last upload on the Vault dates from 08.01.2006. Is there an interest for this simple class? Do you agree with the requirements? Is there an interest for a bounded_c_memory class which will take care of the length of the significant data instead of the trailing '\0'? Best regards, _____________________ Vicente Juan Botet Escribá

1 0

[filesystem] copy_file() not atomic proposed fix
by Beman Dawes 12 May '09

12 May '09

Ticket #2925 complains that "boost::filesystem cannot atomically copy file if target exists", and gives this example: void copy (std::string src, std::string target, int flags) { if ( (flags & Overwrite) && boost::fs::exists (tgt) ) { boost::fs::remove (tgt); } // second process can create file again here boost::fs::copy_file (src, tgt); } Changing boost::filesystem::copy_file() to overwrite isn't viable; (1) that just creates a mirror of the race condition when an overwrite is actually desired to be an error, and (2) changing the behavior would silently break existing code. The proposed solution is to add an option to copy_file(): enum class copy_option { fail_if_exists, overwrite_if_exists }; void copy_file( const Path & from_path, const Path & to_path, copy_option option=copy_option::fail_if_exists ); The implementation would be atomic on both POSIX and Windows. Comments? --Beman

1 0

Anybody tried AMD x86 Open64 Compiler Suite?
by Hartmut Kaiser 11 May '09

11 May '09

Here: http://developer.amd.com/CPU/OPEN64/Pages/default.aspx Regards Hartmut

4 3

[iostream] Device::read return inconsistency
by Richard Smith 11 May '09

11 May '09

The example in the documentation for the Source concept in Boost.Iostreams says: std::streamsize read(char* s, std::streamsize n) { // Read up to n characters from the input // sequence into the buffer s, returning // the number of characters read, or -1 // to indicate end-of-sequence. } (The same text appears in 'valid expressions / semantics' table, which is probably more definitive.) What does a return of less than n actually mean? Nowhere on the documentation pages for the Source concept or the read function template does it say what a return value in the range [0,n) means. And from the comment in the example, it would appear that read is permitted to return less than n if the some smaller number of characters are currently available /without/ implying that a subsequent call will hit eof. This seems to be confirmed by the use of non_blocking_adapter in places in the library where you want code to block until the n bytes are available, and to guarantee eof (or, I guess, an error) for a subsequent call. However, the comment in the BidirectionalDevice seems to disagree: std::streamsize read(char* s, std::streamsize n) { // Reads up to n characters from the input // sequence into the buffer s, returning the number // of characters read. Returning a value less than n // indicates end-of-sequence. } (Again, the same text appears in the 'valid expressions / semantics' table.) So which is it? I don't believe it is the library's intention for a [0,n) return to have different meanings in BidirectionalDevice and Source. I haven't located any code in the library itself that assumes a non-zero return of less than n signifies eof (though I haven't searched all that hard), but third-party code and/or any other boost libraries that use Boost.Iostreams may well do. However there do seem to be places where a return of zero is taken to mean eof. For example, indirect_streambuf::underflow seems to treat zero as eof. At the very least the documentation needs fixing to be consistent. And ideally it needs to document what a return of 0 means (presumably undefined behaviour unless n == 0) and whether a return in the range (0,n) implies that the next call to read will return eof (probably not). (Also, a minor typo: in the example on the Sink concept documentation, write should return std::streamsize, not void.) Richard Smith

2 3

[filesystem] [cygwin] Version 3 will not support BOOST_NO_STD_WSTRING
by Beman Dawes 11 May '09

11 May '09

The GCC 4.4.0 release binary for Windows available from http://www.equation.com/servlet/equation.cmd?call=fortran supports std::wstring, std::wcout, etc. Presumably official Cygwin support will follow. That removes the little remaining incentive I had, so Boost.Filesystem Version 3 will not support BOOST_NO_STD_WSTRING. There had been some previous discussion of this, but it is now definite. I still don't have an exact target date for V3, but plans should become more concrete over the next couple of months. --Beman

2 2

[dynamic_bitset] proposed fix for ticket #2842
by Juan Antonio Zaratiegui Vallecillo, a.k.a. Zara 11 May '09

11 May '09

Dear all, I have suffered the effects described on ticket #2842: "dynamic_bitset.hpp fails to compile with g++ (Ubuntu 4.3.3-5ubuntu2) 4.3.3" after upgrading from Ubuntu 8.10 to 9.04. After some testing, I have found a possible fix, but I would like to know how may I test thoroughly over as many compiler/versions as possible before I may suggest its inclusion in trunk. Fix data: -- tested under gcc versión 4.3.3 (Ubuntu 4.3.3-5ubuntu4) -- tested under gcc versión 4.1.2 20080704 (Red Hat 4.1.2-44) -- Patch data: <PATCH> Index: boost/dynamic_bitset/dynamic_bitset.hpp =================================================================== --- boost/dynamic_bitset/dynamic_bitset.hpp (revision 52752) +++ boost/dynamic_bitset/dynamic_bitset.hpp (working copy) @@ -999,11 +999,17 @@ using detail::dynamic_bitset_impl::access_by_blocks; using detail::dynamic_bitset_impl::value_to_type; +#if BOOST_WORKAROUND(__GNUC__, == 4) && (__GNUC_MINOR__ >= 3) + // NOTE: Explicitly qualificationf of "bits_per_block" + // breaks compilation on gcc 4.3.3 + const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block); +#else // NOTE: Explicitly qualifying "bits_per_block" to workaround // regressions of gcc 3.4.x const bool no_padding = dynamic_bitset<Block, Allocator>::bits_per_block == CHAR_BIT * sizeof(Block); +#endif const bool enough_table_width = table_width >= CHAR_BIT; </PATCH> TIA Zara

2 2

[scope_exit] Boost.ScopeExit capturing 'this'
by adam.butcher＠selex-comms.com 11 May '09

11 May '09

I wasn't sure whether I had the correct address for Boost.ScopeExit's author Alexander Nasonov, so I've submitted to this list just in case and to get feedback from other users. I have been playing with BOOST_SCOPE_EXIT -- it it very convenient. One thing I would have liked would be to capture 'this' inside member functions. I have created a patch which adds BOOST_SCOPE_EXIT_THIS to do just that. It provides an operator->() in the generated struct which can be used to access the enclosing class's members. The syntax is: BOOST_SCOPE_EXIT_THIS( (&a) (&b) ) { a; b; // local captures (*this)->member; // member access } BOOST_SCOPE_EXIT_END; and can be BOOST_SCOPE_EXIT_THIS() { (*this)->member; } BOOST_SCOPE_EXIT_END; providing the preprocessor allows for empty parameter lists (which gcc does and vc does albeit after disabling a warning to remove noise). The type pointed to by the result of operator->() is correctly cv qualified. It has been tested on gcc 4.3, gcc 4.2, msvc 7.1 and msvc 9.0. I don't have access to other compilers. Boost.Typeof worked fine on gcc for typeof(this) -- mostly because gcc has a native typeof I guess. On visual studio (vc71 and vc90) it was not so good -- a compiler bug ( http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… , http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… ) that has been marked as 'Won't fix' means that 'this' cannot be used in expressions within template argument lists -- even if those expressions are innocuous typeid()s or sizeof()s for type-inference. The common workaround (capturing a compile-time integer with an enumerator and using the enumerator in the template parameter list) doesn't work with the vc71-specific implementation of Boost.Typeof since it is based on typeid() -- this cannot be captured in a compile-time expression (or I know of no way to that doesn't involve the expression existing in a template argument list). All is not lost though -- the general-purpose sizeof() based approach for the other VC versions works fine for VC71 for determining the typeof 'this'. As such my patch includes a VC>=1300 specific workaround for typeof 'this' determination. This is unfortunate but I couldn't think of any other non-intrusive way of doing it. Please find the attached patch and let me know what you think -- I'm sure this feature would be useful to users -- it saves having to do: TypeOfMyClassWhichCouldBeTedious* self = this BOOST_SCOPE_EXIT( (&self) ) { self->member; } BOOST_SCOPE_EXIT_END; which removes the convenience of BOOST_SCOPE_EXIT in these contexts since something like: struct at_end { TypeOfMyClassWhichCouldBeTedious* self; ~at_end() { self->member; } } at_end = {this}; can be done without any dependencies to achieve the same result. Regards, Adam. ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Lambda House, Christopher Martin Rd, Basildon, SS14 3EL. England.

4 8

[1.40.0] Release branch open
by Beman Dawes 11 May '09

11 May '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule: * June 15, 2009: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * June 22, 2009: Release managers start QA checks. * July 6, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * July 13, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * July 20, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates. * August 1, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. --The release management team

1 0

[signals2] Compile errors when using signals2
by Carlos Rafael Giani 11 May '09

11 May '09

Hi, I had some compiling errors when I wanted to try out signals2. In predestructible.hpp line 33 there is an extra semicolon (the empty {} scope has a an extra ;). Also, in tracked_objects_visitor.hpp line 85, the "trackable" parameter is unused, which causes a warning. The warning is not critical, but the error is. It basically forces one to either manually fix the predestructible.hpp header, or to stop using the -pedantic flag. My flags: -Wextra -Wall -std=c++98 -pedantic

2 1

Boost Asio in Windows
by Kenny Stone 10 May '09

10 May '09

I'm trying to use asio in linux and windows, and I have to use a very specific way of starting my IO Service to get it to work in windows xp: void start() { tcp::endpoint endpoint = *iterator_; socket_.async_connect(endpoint, boost::bind(&MessageHandler::handle_connect, this, boost::asio::placeholders::error, ++iterator_ ) ); boost::thread t( boost::bind( &boost::asio::io_service::run, &(socket_.get_io_service() ))); t.detach(); //threadPool_.schedule(boost::bind( &boost::asio::io_service::run, &(socket_.get_io_service()) ) ); } The commented out line is what I wanted to use (threadpool), as thread detach is far from an ideal situation. To work in windows, I have to call io_service.run() in this function and thread detach; it doesn't seem to work any other way. Everything pretty much works in linux. Is there a pattern that I should be using here for cross platform usage of the library? Any ideas why the threadpool solution doesn't work in windows? ( http://threadpool.sourceforge.net/) Thanks, -- Kenny Stone Connamara Systems, LLC

2 1