- Boost - lists.boost.org

Boost regression notification (2005-10-18 [RC_1_33_0])
by Douglas Gregor 19 Oct '05

19 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-18T15:24:21Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 55 failures in 4 libraries: parameter (2) python (17) range (3) serialization (33) |parameter| tutorial: borland-5_6_4 gcc-2.95.3-linux |python| builtin_converters: cw-8_3 cw-9_4 gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.1-linux gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: cw-9_4 test_class_info_load_binary_archive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_text_archive: cw-9_4 test_class_info_load_text_archive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_text_warchive: cw-9_4 test_class_info_load_text_warchive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_xml_archive: cw-9_4 test_class_info_load_xml_archive_dll: cw-9_4 intel-win32-8_1 test_class_info_load_xml_warchive: cw-9_4 test_class_info_load_xml_warchive_dll: cw-9_4 intel-win32-8_1 test_demo_xml_load: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 test_demo_xml_load_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_shared_ptr_132_text_warchive: intel-win32-8_1 test_shared_ptr_binary_archive: borland-5_6_4 test_shared_ptr_binary_archive_dll: borland-5_6_4 test_shared_ptr_text_archive: borland-5_6_4 test_shared_ptr_text_archive_dll: borland-5_6_4 test_shared_ptr_text_warchive: borland-5_6_4 test_shared_ptr_text_warchive_dll: borland-5_6_4 test_shared_ptr_xml_archive: borland-5_6_4 test_shared_ptr_xml_archive_dll: borland-5_6_4 test_shared_ptr_xml_warchive: borland-5_6_4 test_shared_ptr_xml_warchive_dll: borland-5_6_4

3 2

[TR1 Review] TR1 Formal Review Beginning
by Beman Dawes 19 Oct '05

19 Oct '05

The formal review of the Boost TR1 Library by John Maddock begins today, Saturday, September 24th, and runs through Wednesday, October 5th. The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes: * Reference Wrappers * Smart Pointers * Class template result_of. * Function template mem_fn. * Function Object Binders. * Polymorphic function wrappers. * Type Traits. * Random Number Generators and Distributions. * Tuples. * Tuple Interface to std::pair. * Fixed Size Array. * Hash Function Objects. * Regular Expressions. * Complex Number Algorithm Overloads. * Complex Number Additional Algorithms. Functionality in TR1 but not yet available: * Mathematical Special Functions. * Unordered Associative Set (Hash Table). * Unordered Associative Map (Hash Table). * C99 C language additions. Additional information including online documentation is available at http://freespace.virgin.net/boost.regex/tr1/index.html The complete TR1 lib source and docs can be downloaded from http://freespace.virgin.net/boost.regex/tr1/tr1-20050816.zip Please help Boost by posting your formal review of this library. Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. --Beman Dawes, Review Manager

7 13

Re: [boost] [Review] of binary_int utility starts
by Scott Schurr 19 Oct '05

19 Oct '05

Reece Dunn wrote: > Scott Schurr wrote: > > I'm going to wait until after the review period to start on fixing > > the 64-bit support. Since I don't have a local 64-bit compiler > > I'll be working blind and my first few efforts will be dead wrong. > > The 32-bit microsoft compiler has support for 64-bit literals if you > have version 7.0 or above handy (6.0 might have this, but I haven't > checked). You will need to enable language extensions. I am not sure > about the other compilers, though. > > It should be possible to test the 64-bit stuff on a 32-bit compiler like > VC7 with MS language extensions, or even GCC. > > You may get warnings when converting a 64-bit type to a 32-bit type, or > even a 32-bit type to a 16-bit type. However, the solution for this is: Thanks for the suggestion Reece. I thrashed about some this morning turning on extensions. I'm now able to reproduce the problem that Markus Sch?pflin found: Markus Sch?pflin wrote: > For the next test, I changed struct test_values (in binary_int_test.cpp) to > the following: > > struct test_values { > uint64_t hex_value; > uint64_t bin_value; > }; > > This additionally needs #include <boost/cstdint.hpp>. > > When compiling and running this (on both 32 bit and 64 bit systems), I got > the following error: > > At test_array index 40 8a6c4e20 != ffffffff8a6c4e20 > assertion "test_array[i].hex_value == test_array[i].bin_value" failed: file > "../binary_int_test.cpp", line 118 And I found that... Scott Schurr wrote prematurely: > > At an initial glance it looks like 64-bit support should be > > achievable without heroic efforts. But it certainly won't come > > along for free. I'm using the Microsoft 32-bit Compiler, Version 13.00.9466, and I'm running into two different problems with 64 bit values: 1. So far I've been unable to make Marcus's problem go away. With 32-bit values I was able to fix this up by forcing the underlying type that I write to my enums. When I try this same fix in 64-bits nothing gets better. 2. The worse problem is that binary value values larger than 32 bits (8 nibbles) get their upper nibbles truncated. After a couple of tests it appears that, for this compiler, the largest supported enum value must fit in 32 bits. If that's correct, then my enum based calculations run out of steam on this compiler at 32 bits. Hmmph. Matt Calabrese's macro-based approach is looking more appealing, at least as far as 64-bit support goes. Scott Schurr

5 5

[testing] Refactoring serialization tests, and possibly others.
by Rene Rivera 19 Oct '05

19 Oct '05

After having run two cycles of tests for Boost with the mingw-3_4_2-stlport-5_0 configuration and having it take more than 14 hours on a 2.2Ghz+1GB machine, most of that in the Boost.Serialization library[*]. And reading some of the recent discussion about the desire to expand testing to include cross-version compatibility and cross-compiler compatibility, and hence having the number of tests multiply possibly exponentially. I am seriously concerned that we are going in the wrong direction when it comes to structuring tests. From looking at the tests for serialization I think we are over-testing, and we are past the point of exhausting testing resources. Currently this library takes the approach of carpet bombing the testing space. The current tests follow this overall structure: [feature tests] x [archive types] x [char/wchar] x [DLL/not-DLL] Obviously this will never scale. My first observation is that it doesn't seem that those axis look like independent features to me. That is, for example, the char/wchar functionality doesn't depend on the feature getting tested, or at least it shouldn't. And I can't imagine the library is structure internally in that way. To me it doesn't make sense to test "array" saving with each of the 3 archive types since the code for serialization of the "array" is the same in all situations. Hence it would makes more sense to me to structure the tests as: [feature test] x [xml archive type] x [char] x [not-DLL] [text archive tests] x [char] x [non-DLL] [binary archive tests] x [non-DLL] [wchar tests] x [non-DLL] [DLL tests] Basically it's structured to test specific aspects of the library not to test each aspect against each other aspect. Some benefits as I see them: * Reduced number of tests means faster turn around on testing. * It's much easier to add tests for other aspects as one only has to concentrate on a few tests instead of many likely unrelated aspects. * The tests can be expanded to test the aspects more critically. For example the DLL tests can be very specific as to what aspect of DLL vs non-DLL they test. * It is easier to tell what parts of the library are breaking when the tests are specific. [*] That's just a CPU time observation, not to mention that it takes 2.15GB of disk space out of a total of 5.09GB. And it's only one compiler variation. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

5 37

[Boost-bugs] [ boost-Support Requests-1330119 ] building boost sgd libraries
by SourceForge.net 18 Oct '05

18 Oct '05

Support Requests item #1330119, was opened at 2005-10-18 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1330119&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: cxgd (cxgd) Assigned to: Nobody/Anonymous (nobody) Summary: building boost sgd libraries Initial Comment: how do I build the boost sgd libraries ? My project requires libboost_thread-vc71-mt-sgd-1_33.lib but I have libboost_thread-vc71-mt-gd-1_33.lib what is the difference between the sgd and the gd libraries ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1330119&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2005-10-18 [HEAD])
by Douglas Gregor 18 Oct '05

18 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-18T05:00:20Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 115 failures in 11 libraries: concept_check (13) graph (2) mpl (1) parameter (14) python (7) serialization (36) spirit (8) thread (4) tuple (1) typeof (21) xpressive (8) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc tutorial: gcc-2.95.3-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| builtin_converters: gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 vc-7_1 exec: intel-win32-9_0 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3: gcc-3.4.4-linux test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5: gcc-3.4.4-linux test5u: gcc-3_3-darwin test6: gcc-3.4.4-linux test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

3 3

asio networking proposal 0.3.4
by Christopher Kohlhoff 18 Oct '05

18 Oct '05

Hello all, I have just released asio 0.3.4. You can download it, or view the documentation online, at http://asio.sourceforge.net. The major changes in this version include support for scatter-gather operations, an initial SSL implementation, and documentation improvements including an HTTP 1.0 server example. Code that uses asio will need to be updated. It is my feeling that there are no more major interface changes to be made, and my next goal is to convert asio into "Boost format" in preparation for a submission. Feedback is appreciated. In detail, the changes since asio 0.3.3 include: - Added support for scatter-gather on all read and write operations. These operations now take a list of one or more "buffers" for the operation. These buffers may be created to represent raw memory, POD arrays, boost::array or std::vector. This change breaks existing code, which needs to be fixed as follows. Where one used to write: sock.read(data, length); one now needs to write: sock.read(asio::buffers(data, length)); Similar changes are needed on all read, write, send and receive operations, both synchronous and asynchronous. - Added initial SSL support using OpenSSL. This takes the form of a template, called asio::ssl::stream, which can be used with any class which supports the Sync_*_Stream and Async_*_Stream concepts, e.g.: typedef asio::ssl::stream<asio::stream_socket> my_ssl_socket; Please note that for now this only works when used with single-threaded demuxers. A big thanks to Indrek Juhani of Voipster for developing the core implementation, and to Dirk Griffioen for organising this contribution. - Exceptions in handlers are no longer suppressed using catch (...). Instead they are now allowed to propagate out of the basic_demuxer::run function so they may be caught by application code. After an exception is caught, basic_demuxer::run may be called again immediately to continue processing. - Replaced the basic_demuxer::work_started/work_finished classes with an RAII class called basic_demuxer::work. - Added iostream output operators for ipv4::address, ipv4::tcp::endpoint and ipv4::udp::endpoint. - Added an HTTP 1.0 server example. - Added a kqueue reactor implementation for Mac OS X. Thanks to Stefan Arentz for providing the initial implementation. - Improved error handling in the epoll_reactor. - TSS slot usage has been minimised to use one slot for all demuxers of a given type, rather than one slot per demuxer object. - The calls to WSAStartup and WSACleanup have been made safer with respect to global demuxer objects. - Automaticaly link in ws2_32.lib when using asio on Win32 with Visual C++ or Borland C++. - Added back missing implementation of get_remote_endpoint. - Visual C++ 6 and gcc 2.95.x are not supported in this version, due to lack of testing resources. - Many documentation improvements. Note that I chose not to rename the send/receive family of functions to write and read, as had been discussed. After further thought I came to the conclusion that functions should only have the same name if they provide the same semantics. I think it's fair to say that read and write are the ideal names for the stream concepts' operations. However stream_socket's send and receive functions take additional parameters (flags) that can significantly alter the semantics (e.g. peek). A similar thing applies to not renaming datagram_socket's send/send_to/receive/receive_from functions, which are datagram-oriented, as opposed to the stream concepts' read and write which are (obviously) stream-oriented. Cheers, Chris

4 7

Re: [boost] asio networking proposal 0.3.4
by Martin Bonner 18 Oct '05

18 Oct '05

From: Christopher Kohlhoff [mailto:chris@kohlhoff.com] > >>> struct message { >>> int a; >>> double b; >>> int c_size; >>> char c[0]; >>> }; >>> message* m = ...; >>> sock.write(buffers(m, sizeof(message) + m->c_size)); >> > --- Martin Bonner <martin.bonner(a)pitechnology.com> wrote: >> Oh no! Please! Don't let us encourage bad code like that. > > One person's bad code is another person's necessary performance > optimisation :) > >> It will work if >> the receiving socket belongs to the same program on the same >> machine. Otherwise it depends on: >> - sizeof(int) (16,32,64 bits) >> - endianness >> - representation of double (IEEE or IBM) >> >> ... and that's just the obvious, real-world, differences that can be >> encountered TODAY. > > It will in fact work across different machines that have the same > architecture, where the programs use the same alignment etc. This may > seem picky, but it is a vital point. > > The optimisation shown in the example, ugly though it looks, is in > principle what is used in receiver-makes-right protocols, i.e. the > cost associated with dealing with architecture differences is left to > the receiver. That way if the data is sent between two machines of > the same type, then those costs are eliminated. > > There's a large body of research and experience in these sorts of > optimisations, e.g. MPI, and they are critical to high performance > computing. > > I agree that code like that should not appear in typical applications > and should not be generally encouraged. However there is a use case > for it in domains that would also often use C++ for performance. > Therefore I believe that a C++ networking library must not preclude > such a usage. That seems fair enough (a programmer's gotta do what the profiler says a programmer's gotta do). However, can I put in a plea that we arrange things so that this is not the simplest thing to do? Compare the C file API. The simplest way to read and write a struct to a file, is with a simple call to fread/fwrite. That means too many people just read and writes structs to file as binary, and then hit problems when the next compiler release changes the struct layout. Doing it the right way (with a series of unsigned chars) is hard work (and often doesn't get done). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Re: [boost] asio networking proposal 0.3.4
by Martin Bonner 18 Oct '05

18 Oct '05

> --- Beman Dawes <bdawes(a)acm.org> wrote: >> Where did this idea come from that the only way to avoid an >> additional copy is to use a void *? From: Christopher Kohlhoff [mailto:chris@kohlhoff.com] > It's not just avoiding a copy, it's avoiding a copy *and* allowing > arbitrary data structures to be sent. IMHO an important use case for > C++ and networking is being able to do things like: > > struct message { > int a; > double b; > int c_size; > char c[0]; > }; > message* m = ...; > sock.write(buffers(m, sizeof(message) + m->c_size)); Oh no! Please! Don't let us encourage bad code like that. It will work if the receiving socket belongs to the same program on the same machine. Otherwise it depends on: - sizeof(int) (16,32,64 bits) - endianness - representation of double (IEEE or IBM) ... and that's just the obvious, real-world, differences that can be encountered TODAY. The only safe datatype for transport over a socket is an array of unsigned char with a defined layout. Thus we would need somethink like: message* m = ...; std::vector<unsigned char> mbuf; mbuf.reserver(sizeof(m)+m->c_size); mbuf.push_back( m->a & 0xff ); mbuf.push_back( (m->a >> 8) & 0xff ); pushDouble( mbuf, m->b ); // pushDouble decodes the double and pushes // the bytes of a IEEE double onto mbuf. etc This looks like an application for something like serialization. For example, the result of right shifting a negative number is implementation defined and something more subtle is required for real portability. (Something like serialization, rather than the same as, because the user needs to specify "this field is 16 bits", "this field is 32 bits" independant of the size of the datatype used to store the field). (Or have I missed something terribly subtle in the "buffers" code which handles all this) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

[program_options] typo in doc
by Matt Hurd 17 Oct '05

17 Oct '05

http://www.boost.org/doc/html/program_options/overview.html#id1247613 has the line pd.add("output-file", 2).add_optional("input-file", -1); which is not supported. Only void add(...) exists. pd.add("output-file", 2) pd.add("input-file", -1); would be correct I think. matt.

1 0