- Boost - lists.boost.org

[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

[serialization] std::vector<>
by Richard Crossley 22 May '06

22 May '06

Hi, Using CVS HEAD with VC8 fails when writing out an empty std::vector as T* get_data(STD::vector<T,Allocator>& v) attempts to access element 0. Looks to me as if the optimized versions of save() and load() for std::vector in vector.hpp should be checking the vector size first. Regards, Richard.

2 1

[serialization] MSVC8 runtime check error
by John Reid 22 May '06

22 May '06

Hi, I'm getting a runtime check error from MSVC8 in the following code checked out from cvs_head: serialization/collections_load_imp.hpp line 116 ... template<class Archive, class Container, class InputFunction, class R> inline void load_collection(Archive & ar, Container &s) { s.clear(); // retrieve number of elements unsigned int count; unsigned int item_version; ar >> BOOST_SERIALIZATION_NVP(count); if(3 < ar.get_library_version()){ ar >> BOOST_SERIALIZATION_NVP(item_version); } R rx; rx(s, count); InputFunction ifunc; while(count-- > 0){ ifunc(ar, s, item_version); } } ... The debugger breaks every time ifunc() is called which is frustrating to say the least. If load_collection() is wrapped with #pragma runtime_checks( "u", off ) ... #pragma runtime_checks( "u", restore ) it doesn't help - perhaps I've rebuilt it incorrectly, perhaps the pragma needs to be around where the code is instantiated. I managed to get around the problem by assigning 0 to item_version. Has anyone specifically chosen to turn runtime checks on for debug builds with MSVC8 or is this just the default? Thanks, John.

1 0

[serialization] patch for Borland
by David Abrahams 22 May '06

22 May '06

I just checked this one in. Wouldn't compile on Borland without it, due to duplicate definitions of the same function template. BTW, the comment in that file reads: // if function is partiall specialized - which is wrong, because there's no partial specialization of functions. It should be fixed to say what you really mean. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

timedout async operation problem in boost::asio
by 李慧霸 22 May '06

22 May '06

I'm trying to use boost::asio, and I find that there isn't a built-in timeout parameter in any async operation. I think it's a very important function when writing real life programs, and I have done some walk around work, how can I try to contribute?

3 2