- Boost - lists.boost.org

Boost regression notification (2005-09-19 [RC_1_33_0])
by Douglas Gregor 19 Sep '05

19 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-19T14:50:08Z 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… 115 failures in 9 libraries: concept_check (20) foreach (1) graph (5) multi_index (1) random (1) range (3) serialization (73) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-2.95.3-linux 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-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |multi_index| test_serialization: intel-win32-9_0 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: gcc-3.2.3-linux test_class_info_load_binary_archive_dll: gcc-3.2.3-linux test_class_info_load_text_archive: gcc-3.2.3-linux test_class_info_load_text_archive_dll: gcc-3.2.3-linux test_class_info_load_text_warchive: gcc-3.2.3-linux test_class_info_load_text_warchive_dll: gcc-3.2.3-linux test_class_info_load_xml_archive: gcc-3.2.3-linux test_class_info_load_xml_archive_dll: gcc-3.2.3-linux test_class_info_load_xml_warchive: gcc-3.2.3-linux test_class_info_load_xml_warchive_dll: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

Boost regression notification (2005-09-19 [HEAD])
by Douglas Gregor 19 Sep '05

19 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-19T05:00:21Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 219 failures in 15 libraries: concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) math (3) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |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 vc-7_1 |date_time| testlocal_time_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc testlocal_time_period: gcc-2.95.3-linux msvc |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: msvc |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin quaternion_test: gcc-4_0-darwin special_functions_test: gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 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: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| data_members: msvc |regex| static_mutex_test: msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin 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: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin 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| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier: msvc test_barrier_lib: intel-9.0-linux msvc test_condition: msvc test_condition_lib: intel-9.0-linux msvc test_mutex: msvc test_mutex_lib: intel-9.0-linux msvc test_once: msvc test_once_lib: intel-9.0-linux msvc test_read_write_mutex: msvc test_read_write_mutex_lib: intel-9.0-linux msvc test_thread: msvc test_thread_lib: intel-9.0-linux msvc test_tss: msvc test_tss_lib: intel-9.0-linux msvc test_xtime: msvc test_xtime_lib: intel-9.0-linux msvc |typeof| data_member_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux data_member_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ptr_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ref_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lvalue_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_int_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_tpl_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 type_emulation: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

[Review] xpressive
by Thomas Witt 19 Sep '05

19 Sep '05

The review of Eric Niebler's xpressive library begins now and runs through Sunday, September 18. The library is available here: http://www.boost-consulting.com/vault/index.php?directory=Strings%20-% 20Text%20Processing Here is a short introduction that I shamelessly reassembled from the xpressive documentation. xpressive is an advanced, object-oriented regular expression template library for C++. Regular expressions can be written as strings that are parsed at run-time, or as expression templates that are parsed at compile-time. xpressive brings these two approaches seamlessly together and occupies a unique niche in the world of C++ text processing. With xpressive, you can choose to use it much as you would use Boost.Regex, representing regular expressions as strings. Or you can use it as you would use Spirit, writing your regexes as C+ + expressions, enjoying all the benefits of an embedded language dedicated to text manipulation. When writing your review, you may wish to consider the following questions: * 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. Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. Thanks Thomas Witt Review Manager xpressive Thomas Witt witt(a)acm.org

13 38

GUI
by Benjamin Munson 19 Sep '05

19 Sep '05

Hi. I'm Ben, first time poster, occasional lurker. I've been playing around with ideas for a nice cross platform C++ GUI, something I think is lacking. Is there any interest in this? More importantly, are there any thoughts on how this should best be done, and features that would be needed. My idea was to have a base window class, with child windows derived from that (admitedly my ideas are retardly simple on occasion), and a special toplevel window derived too. The base window class would obviously need a number of virtual functions for mouse/key/painting etc and I'm not sure how much this would affect performance, I expect at most you'd have two or three levels of inheritance working, and maybe a dozen or so virtuals? Because I'd like this to be usable in real-time systems (like games) rather than just event driven ones I thought that a desktop class would work well as a top level control for all the windows. To handle the drawing itself, I thought some kind of canvas object, obviously this would be the most platform specific part, with members for the different drawing operations you might need, lines/rects/blitting etc. I've actually worked up a test version of a lot of this, a win32 version and a glut version. The win32 version obviously uses the win32 api. The glut version uses glut but no acceleration at all, everything is rendered to a bitmap and glBitmap'ed to the screen at the end, so all lines etc use software algorithms. Also, the glut version unfortunately isn't totally portable for font based reasons, I had to use windows fonts since glut doesn't let you use truetype fonts afaik. The test version implements the top level window, a textbox and button class. Another point I'd like advice on is how best to handle the platform specific parts of a library like this. Right now, there are three classes (desktop, canvas and window_top_level) with platform specific parts variables or that need seperate versions of methods. I've just used #defines to configure which platform is used, and for ease of finding things I've grouped the platform specific parts in seperate files (so I have a window_top_level.cpp, window_top_level_glut.cpp and window_top_level_windows.cpp) with the common methods in the named cpp file. I have a feeling this might not be the best way of doing things. And ideas? I think it might be better if each platform has an entire implementation in one file to itself. I'm sorry if this is a bit rambling, it's a bit of a mind dump to be honest. I can stick the demo online if anyone is interested. If you are, let me know. Ben.

6 14

[functional/hash] Reason for failure of hash_float_test on Tru64/CXX
by Markus Schöpflin 19 Sep '05

19 Sep '05

As can be seen at http://tinyurl.com/9lded there is a failure for a very specific test of the hash function on Tru64/cxx65-042. I finally took the time to track this down and it turned out to be due to a bogus return value of std::numeric_limits<long double>::denorm_min(). The good news is that it's fixed in the latest compiler release. But should the failure be marked as expected for older versions of the compiler, or should a workaround be added to the test itself? Any preferences? Markus

2 2

[parameter] efficiency testing
by David Abrahams 19 Sep '05

19 Sep '05

Last week, we were considering using the parameter library in some client software that demands high performance (they are doing massively parallel statistical analysis), so I sat with Matthias Troyer, an expert in high-performance C++, and developed the test that's now checked in at libs/parameter/test/efficiency.cpp. The test was carefully designed to avoid deceptive effects due to dead code elimination, constant propagation, and CPU architecture, and the process of developing it was highly instructive to me personally. We left lots of comments in the code so I'd be able to remember the issuse involved. I recommend reviewing it for anyone interested in how to measure abstraction penalty. One set of results is checked in at libs/parameter/test/timings.txt, and are reproduced below. As you can see, at least on that platform, you don't need to worry about Boost.Parameter slowing your code down; it might even speed your code up! We'd be very interested in seeing results produced with other compilers and/or platforms at the highest optimization levels. ----------------- Test #1 ---------------- Testers: Matthias Troyer, Michael Gauckler, David Abrahams Date: 2005-09-09 Compiler: Cygwin g++-4.0.0 Command lines: g++ -c -o efficiency.o -ftemplate-depth-100 -funroll-loops \ -O3 -finline-functions -Wno-inline -DNDEBUG efficiency.cpp g++ -o efficiency.exe efficiency.o -Wl,--strip-all efficiency && efficiency && efficiency Machine: Dell Inspiron 9300 Intel(R) Pentium(R) M processor 2.00GHz Running on 230 volts AC power Timings: Run #1 results discarded per standard practice Run #2 plain time: 0.75 named parameter time: 0.734 Run #3 plain time: 0.781 named parameter time: 0.766 ----------------------------------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 4

[xpressive] MinGW 3.4.2 ICE
by Cromwell Enage 19 Sep '05

19 Sep '05

Sorry for being last-minute. Attempting to compile samples/main.cpp results in an ICE caused by <boost/xpressive/detail/matchers.hpp>, line 299. I'm guessing MinGW doesn't like the comma used that way? Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

[RMI-like-lib] is there any interest in such?
by Slawomir Lisznianski 19 Sep '05

19 Sep '05

I've been thinking of a library that would bring RMI-like capabilities to C++ (RMI stands for Remote Method Invocation). Primary goal, and differentiating feature, of this library is not to rely on IDL-like compiler, hence no cross-language support either -- if you need that, check out CORBA (www.omg.org) or ICE (http://www.zeroc.com) As an example, I'm going to "implement" client and server sides of a trivial calculator using proposed library. Step 1. Define calculator interface ----------------------------------- // // Operations: add, subtract, multiply and divide // struct add { typedef function2<double, double, double> function_type; }; struct subtract { typedef function2<double, double, double> function_type; }; struct multiply { typedef function2<double, double, double> function_type; }; struct divide { typedef function2<double, double, double> function_type; }; // Calculator interface // typedef interface< operation<sum>, operation<subtract>, operation<multiply>, operation<divide> > calculator_i; Step 2. Client invocation ------------------------- // Construct a proxy to the remote calculator // instance. Arguments to the constructor // describe remote object's location (not shown). // proxy<calculator_i> calculator(...); // Call `subtract' on remote object (call // doesn't block). Returned object implements // Asynchronous Completion Token (or Future) // concept. // act<double> res = call<subtract>(calculator, 12, 43); // Retrieve actual result, or get an exception... // double result = res(); Step 3. Server implementation ----------------------------- // Implement actual calculator. // struct calculator_servant { double sum(double a, double b) { return a + b; } ... // other operations here }; // Instantiate calculator servant // calculator_servant servant; // Create a TCP listener. // tcp_listener listener(...) // Create a stub object that acts as an // adapter between transport and a servant. // stub<calculator_i> calculator(listener); // Install operation handlers. // calculator.register_function<add>(bind(&calculator_servant::sum, ref(servant), _1, _2)); ... // register remaining handlers // Start accepting calls. // calculator.activate(); // Block until exiting. // calculator.wait_for_shutdown(); ... -- end of example] I'm fairly satisfied with the client side, but I'm not so enthusiastic about the server side though. For one, it feels less safe. For example, what if a user forgets to register a "handler" for a particular operation? Any way to enforce this at compile time? Typically, say with CORBA, IDL compiler generates operations as pure virtual functions, so at compile time, the user knows what's left out in her servant. On the other side, it's quite powerful too (being able to "bind" functors to operations, that is). Would that be a problem for you or you'd see it as a good feature? Let me know what you think. Cheers, Slawomir Lisznianski

2 4

Re: [boost] [Review] xpressive
by Scott Woods 18 Sep '05

18 Sep '05

* What is your evaluation of the design? Good. It has taken some powerful, established technologies (e.g. regular expressions and parser generators) and delivered a C++ facillity that uses some of the latest C++ techniques. Hosting these technologies within C++ syntax has resulted in some slightly jarring constructs (e.g. prefix "one-or-more", tag assignment) but the set of design decisions made seem very reasonable. There were some corners that got me curious; the following queries are therefore more about curiosity than suggestions for change. 1. What is the benefit of providing the complete match in the first entry of the results? e.g. "what[0]". While this is consistent with a long tradition in RE, after some time with STL it's presence at position zero wasnt as comfortable as I expected. 2. Why the slash syntax in dynamic regex? The resulting requirement for a double is fairly ugly. It may be consistent with something (Perl/ECMA/..?) but on balance is it worth it? 3. Why ">>" and not "," (comma). Did the "set" facillity take priority or does the low precedence of comma just result in a different ugliness (sorry, not really the word I want to use :-). 4. C++ operators and RE operators are not really comfortable bed-fellows. While the operator overloading technique has given something useful and concise was there no flirtation with "key words" (i.e. in the manner of "as_xpr"). "+" could have been "one_or_more( xpr )". Maybe the keyword version is viable as an alternate targeted at beginners? Unjustifiably complex? 5. There didnt appear to be much specific thought given to file processing. Is this another "not yet implemented"? In particular elegant integration with any async I/O facillity arising from sockets and file I/O initiatives. 6. Very interested in the future of "semantic actions". Actions and file processing probably go together? * What is your evaluation of the implementation? Cannot say. Not used. * What is your evaluation of the documentation? Good. I liked the balance of technical terminology combined with some informality. Appeared to be some minor problems such as initially not knowing what "_w" and "_d" meant. Was this my failing or was there a missing definition. Was the later use of "+alpha" and others inconsistent? * What is your evaluation of the potential usefulness of the library? Huge. Some of that answer refers to the usefulness of RE but xpressive is obviously more. There has been some discussion about overlap with regex. It would be nice to clarify that. The uptake of RE within the development community (at least, the one where I live) is almost embarrassingly low. I have seen many circumstances that cried out for the power and rigor of RE that instead got limited, buggy hand-written solutions. The ease-of-use (installation, build and coding) of xpressive might help? * Did you try to use the library? With what compiler? Did you have any problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study with a glaring omission; the library was not used. Lack of time, old compiler, employer resistance to boost. * Are you knowledgeable about the problem domain? Yes. * 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. Yes. Cheers.

8 24

[serialization] portable_binary_archive
by troy d. straszheim 18 Sep '05

18 Sep '05

Hi Robert, boost... I've implemented a portable binary archive, wondering if there is general interest. I've tested (very thoroughly) on our target platforms, which are 32 and 64 bit linux, and osx on a g5, each platform reads and writes archives written by the others, down to the bit. The archive itself is stored little-endian (as the vast majority of my users are on intel hardware) so big-endian platforms are responsible for byteswapping, though this could be configurable. The problem types are (unsigned) long int and long double. For long int, the archive checks to see if it is small enough to fit into 32 bits, if so it stores it in 32 bits, otherwise it throws. For long double, it just throws, as that's 12 bytes on some platforms, 16 on others, no good way to handle this, and the type is seldom used anyhow. Float and double are assumed to be ieee754, and are just handled as blocks of 32 or 64 bytes. So if the write succeeds, the read is guaranteed to. Part of the idea here is that without resorting to widespread use of int32_t and friends, 4-byte-long platforms are always be able to write archives readable on 8-byte-long platforms. On 8-byte-long platforms, you could write archives readable on the smaller machines, but best to choose either int or long long int or a typedef thereof (int32_t or int64_t). The code is at http://svn.resophonic.com/pub/boost, in boost/archive/detail/portable_binary_archive.hpp boost/archive/portable_binary_iarchive.hpp boost/archive/portable_binary_oarchive.hpp libs/serialization/src/portable_binary_iarchive.cpp libs/serialization/src/portable_binary_oarchive.cpp libs/serialization/test/portable_binary_archive.cpp Issues that come to mind: The test isn't boost-test, that'd need rewriting. Haven't tried any of this on microsoft. Maybe there is some preferred way to detect endianness. The decision to go little-endian was relatively arbitrary, maybe the byte-swapping should be configurable. A possibility I considered was to upgrade all 32 bit longs to 64 bit and do the range-check/throw when *reading* (We nixed this idea, preferring to have the error come up sooner rather than later), maybe this should be configurable as well. There's surely platforms out there with other differences that aren't handled, I don't have a good feel for whether they would make the archive useless to a wider audience. The tests require having access to binary archives written on other platforms, haven't yet thought about how to put that together in the boost build/test context. So have a look, let me know if you're interested. Thanks again for a great lib. troy d. straszheim

4 10