May 2006 - Boost - lists.preview.boost.org

[for_each] suggestion for new macro
by Thorsten Ottosen 24 May '06

24 May '06

Hi Eric, Here's an idea for a macro to complement BOOST_FORACH. Use example: BOOST_ITER_FOREACH( i, get_range() ) { std::cout << *i; } It shoul be quite easy to generate a for-loop behind the scene. The motivation for having this macro would be that often you actually need access to the iterator because it provides much more details than the value-type, eg. - the base-iterator - index etc. With the upcoming range adaptors, the creation of ranges/iterators of unknown type could be much more common. -Thoorsten

4 6

[asio][filesystem] system error handling
by Christopher Kohlhoff 24 May '06

24 May '06

Hello all, I have been thinking about how to reconcile Boost.Asio error handling with the system error classes defined in the TR2 filesystem proposal N1975. I have some concerns which I'll outline in the context of how I plan to use them. The current plan is as follows: - Synchronous functions would by default throw a system_error exception. - An overload of each synchronous function would take an error_code& as the final argument. On failure these functions set the error_code to the appropriate error. On success, the error_code is set to represent the no error state. These functions do not throw exceptions. - Callback handlers for asynchronous functions would take an error_code as the first parameter. For example: void handle_read(error_code ec) { ... } - Since many error codes in socket programming are "well-known" and often tested for explicitly, they need to be defined somewhere. The current errors in the asio::error::code_type enum would be replaced by constants of type error_code: namespace boost { namespace asio { namespace error { const error_code access_denied = implementation_defined; const error_code message_size = implementation_defined; ... } // namespace error } // namespace asio } // namespace boost (Note that in practice boost::asio::error might actually be a class with static members rather than a namespace). The issues I have run into so far are: - The error_code class seems to assume that there is a single "namespace" for the system_error_type values. This is not necessarily the case for the errors in socket programming. For example on UNIX most socket functions use errno values, but the netdb functions (gethostbyname and friends) use a different set of error values starting from 1, and the getaddrinfo/getnameinfo functions use another set of error values starting from 1. Would it be possible for the error_code class to have a category value (which is probably an integer with implementation-defined values) to allow the creation of unique error_code values for each type of system error? A category value would also allow implementors and users to extend the system error classes for other sources of system error (e.g. SSL errors, application-specific errors, etc). - A common idiom in code that uses asio, when you don't care about a specific error type, is to simply treat the error as a bool: void handle_read(asio::error e) { if (e) { // take action because of error } else { // success } } Can the error_code class be made convertible-to-bool and also have operator! to support this style? - Are these classes available in CVS somewhere so they can be reused by other boost libraries? Cheers, Chris

5 7

[math : special functions] Borland 5.8 fail of hypot test
by AlisdairM 24 May '06

24 May '06

The test is currently failing on the following line: ( BOOST_ROOT/boost/math/special_functions/hypot.hpp line 32) BOOST_ASSERT(std::numeric_limits<T>::is_specialized); I believe the problem is Borland's traditional bad handling of const parameters with templates. In the case of this test, T deduces as const double, so of course numeric limits is not specialized. I believe the workaround will be to detect Borland compiler, and do a remove_const on T for the whole function, or perhaps detect const and forward to an explicit call to the non-const function. A similar patch would be applied to: expm1.hpp log1p.hpp Are the library maintainers interested in supporting such a patch? Should we introduce the type_traits dependency (Checking for the Borland platform first?) Should we look to patch mainline, or 1.34 branch. The only active regression testing on Borland is on the 1.34 branch at the moment. -- AlisdairM

2 1

Re: [boost] Random Access to Files (RAF) - any interest ?
by Martin Bonner 24 May '06

24 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Slava, Alex Sent: 23 May 2006 22:32 To: boost(a)lists.boost.org Subject: Re: [boost] Random Access to Files (RAF) - any interest ? >> On 5/22/06, Tomas Puverle <Tomas.Puverle(a)morganstanley.com> wrote: > ... >>> There are filesystems out there that support 128 bits for file >>> sizes. So I think there needs to be a more general solution. >>> > > Totally agree about more general solution. Another reason for wanting a more general solution, is coping with the user wanting many RAF objects at once. That also means that the user needs to be able to specify whether to map the whole file or a window. (The implementation might think there is nothing wrong with mapping the whole of this 1G file on a 32-bit operating system, but the user may be about to open another three such files - which won't fit!) > > That does not change anything, but just out of curiosity some > calculations were made: the number of atoms in the graphite of a > pencil is < 2^72, > > http://www.madsci.org/posts/archives/oct98/905633072.As.r.html > > so the storage providing capacity to hold files with 128-bit offset > would have to contain at least as many atoms as 8*2^56 = 2^59 pencil > leads ! Hundreds of tons of material that should be. And this is with > just 1 atom per bit of information. Seems a bit too much for any > conceivable technology... What FS would need to provide support for > such capacities ? -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

1 0

[serialization] Header Ordering tests for Borland
by David Abrahams 24 May '06

24 May '06

As far as I can tell, in the current CVS state (even after my patch) none of the test_exported_xxx tests will build for Borland... Fatal F1003 ..\..\..\boost/spirit/core/config.hpp 56: Error directive: "Compiler not supported. See note in <boost/spirit/core/config.hpp>" *** 1 errors in Compile *** ...of course, I don't have Spirit 1.6 installed, but even msvc 6 and 7 will run enough of the test_exported_xxx tests to verify that things are working. So, is this a problem? I don't think I can test against Borland. -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 8

[serialization] array problems and patch (cont'd)
by David Abrahams 23 May '06

23 May '06

...and I'm seeing the following array-related problems: testing.capture-output ..\..\..\bin.v2\libs\serialization\test\test_exported_array_binary_archive.test\msvc-7.1\debug\test_exported_array_binary_archive.run ====== BEGIN OUTPUT ====== Assertion failed: NULL != bpos_ptr, file ..\..\..\boost/archive/detail/oserializer.hpp, line 419 testing.capture-output ..\..\..\bin.v2\libs\serialization\test\test_exported_array_binary_archive_dll.test\msvc-7.1\debug\test_exported_array_binary_archive_dll.run ====== BEGIN OUTPUT ====== Assertion failed: NULL != bpos_ptr, file ..\..\..\boost/archive/detail/oserializer.hpp, line 419 Not to mention quite a few vc6-bug-specific problems (just about every test fails with this error): test_exported.cpp ..\..\..\boost/serialization/array.hpp(69) : error C2265: '<Unknown>' : reference to a zero-sized array is illegal These problems are making it hard for me to know that I haven't broken anything. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 11

[Boost Review] Property Tree Library accepted
by Thorsten Ottosen 22 May '06

22 May '06

Dear All, I have the great pleasure to announce that Marcin Kalicinski's Property Tree Library have been accepted into Boost (www.boost.org) The votes were as follows: - yes: 11 - no: 3 Congratulations to Marcin! I would like to thank the following people for doing a review: Sebastian Redl Matt Doyle Pavel Vozenilek Ivan Vecerina Gennadie Rozenal Tom Brinkman Darren Cook Alexander Belyakov John Maddock Daniel Wesslén Jose Paul A Bristow Jeff Hardy. Matias Capeletto I apologize if I have overlooked anybody. Also thanks to the *countless* people who participated in the dicsussion during the review: none mentioned, none forgotten (as we say in Denmark). Below follows more comments on the issues raised in the review. best regards Thorsten Ottosen, review manager Detailed review comments ------------------------ The general feedback was positive, with one reviewer even said he would use the library even if it was not accepted into Boost. Experienced boosters saw the general quality of the submission as higher than average. There was also some strong concerns by a few long-time boost members, most notably because of a potential overlap with Boost.Program Options. I think in the end it was fairly clear that the two libraries take different approaches to the problem. Even so, the property-tree library should clearly state the limitations of its program option parser component and via its documentation refer to Boost.Program Options for a more scallable solution. There were quite a big number of people that thought the library could and should be further polished / enhanced. There is nothing new to this, and I hope Marcin will work hard to incorporate/try out as many of the ideas from the review. (There have been quite a few libraries which went through substantial changes after the review and before the post-review.) When Marcin feels his design/functionality is rock-solid, he should do a post-review on the developer list to clear up remaining matters. Here's a list of ideas that should be considered for the post-review: 1. documentation needs smaller topics, more examples and syntax highlighting 2. implementation: it could be a possibility to use Boost.Multi Index to give a space-optimal implementation. We should not underestime the tasks the library vould be used for, so space/performce does matter. The idea of flattening queries with wildcard syntax "prop.foo.*" might be something to look into 3. support for non-standard strings was seen as a must 4. the issue of preserving white-spaces and comments was important to some people, which is understandable if the library is used to read and write config files 5. serialization support would be nice 6. there should be clear statements on the limitations of the supplied parsers 7. many would like to see the incorporation of a path concept 8. many were intersted in even more syntactic sugar to make the library even easier to use, eg. by using (),[] etc cleverly. Thanks again to Marcin for his submission. -Thorsten

4 7

[serialization] Header Placement
by David Abrahams 22 May '06

22 May '06

The serialization library seems to blatantly violate Boost header placement conventions. 1. Normally detail namespaces are for implementation details that should never be touched by a user of the library, but Serialization puts several framework classes designed to be used by archive authors inside of detail subnamespaces. 2. Also, the top-level boost/ directory is supposed to be reserved for non-implementation details, i.e. files with documented purposes that expose the interfaces of accepted libraries, yet boost/pfto.hpp is clearly an implementation detail of the serialization library. It is not a header I would bet any other Boost library would use, but if I'm wrong about that, it should at least be pushed into boost/detail, where common implementation details live. The conundrum of item 2 is partly the from a mistaken organization. boost/archive/ and boost/serialization/ are segments of the same library, and they should have been organized as such. An obvious organization would've been boost/serialization/archive and, e.g., boost/serialization/streaming. Then boost/pfto.hpp could've been boost/serialization/detail/pfto.hpp These unconventional moves are at best confusing for users and other maintainers. The Boost source base is hard enough to control without library authors inventing their own new rules for organizing things. I realize that these problems can't be repaired all at once, but they should be fixed. I'd start by pushing boost/pfto.hpp into boost/detail, for example. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

[multi_index] invalid expression as template parameter
by Tal Agmon 22 May '06

22 May '06

Hello, I use multi_index as follow with success: typedef boost::multi_index::multi_index_container< boost::shared_ptr<NodeBase>, boost::multi_index::indexed_by< boost::multi_index::ordered_unique< BOOST_MULTI_INDEX_CONST_MEM_FUN(NodeBase, handle, getHandle) >, boost::multi_index::ordered_non_unique< BOOST_MULTI_INDEX_CONST_MEM_FUN(NodeBase, group_id, memberOf) > > > NodePtrSet; but I would like NodeBase inherite boost::enable_shared_from_this<NodeBase> I get error C2964: invalid expression as template parameter using msvc 6 any idea?

2 4

[tuple] can't get size of const empty null tuple.
by Giovanni P. Deretta 22 May '06

22 May '06

Hi all, With GCC 3.4.6, when compiling this simple program, (in tuple_test.cc) 1: #include <boost/tuple/tuple.hpp> 2: typedef const boost::tuple<> tuple; 3: const int size = boost::tuples::length<tuple>::value; 4: int main() {} I get /usr/local/include/boost/tuple/detail/tuple_basic.hpp: In instantiation of `boost::tuples::length<const tuple>': tuple_test.cc:3: instantiated from here /usr/local/include/boost/tuple/detail/tuple_basic.hpp:483: error: no type named `tail_type' in `const class tuple' If i remove "const" from line 2, the program compiles fine. It also compiles if line 2 is substituted with: "typedef const boost::tuple<int> tuple;" I think that 'length' not working with const empty tuples is clearly a bug. Shouldn't 'boost::tuples::length' need to be specialized for 'const tuple<>' in addition to 'tuple<>'? -- Giovanni P. Deretta

1 0