September 2005 - Boost - lists.preview.boost.org

Boost.Signals and Qt
by Vladimir Prus 23 Sep '05

23 Sep '05

Hi, just came across this blog post: http://scottcollins.net/blog/2005/09/question-for-other-boost-users.html It's from a person affiliated with Trolltech (makers of Qt), and raises a question how Boost.Signals and Qt can be made to better work together. Any user of both Boost and Qt cares to comment? - Volodya

4 8

run_tests.sh portability fix
by Jonathan Wakely 23 Sep '05

23 Sep '05

(sorry for not putting a library name in the subject line, I'm not sure what to put for this) Hi, tools/regression/run_tests.sh uses the "export x=y" syntax, which is not supported by /bin/sh on Solaris9 (and probably other systems.) This means "sh run_tests.sh" or "chmod u+x run_tests.sh; ./run_tests.sh" won't work, you must use /usr/xpg4/bin/sh or another, better, sh. The attached patch fixes the problem, at only a slight readability cost. Is this OK to apply? jon

3 3

Re: [boost] Boost.Signals and Qt
by Martin Bonner 23 Sep '05

23 Sep '05

----Original Message---- From: Simon Buchan [mailto:simon@hand-multimedia.co.nz] Sent: 23 September 2005 09:40 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Signals and Qt > Vladimir Prus wrote: >> ? Do you mean that the current situation is optimal, and any >> attempts on improving it are just wasting time? >> >> - Volodya >> > Are you serious? You're writing a library! You think someone might use > it with Qt! Yes, dumbass, you SHOULD do that! Take a look at some of > the boost headers (esp. functional, lambda, bind) and THEN bitch > about how hard it is to write a library. > If it hurts your poor fingers (or eyes), put this somewhere useful > (ie. detail namespace): > namespace whatever = ::boost::BOOST_SIGNALS_NAMESPACE; Are *you* serious? Volodya ask if you think the current situation is optimal, and you insult him. I don't see how you post adds to the discussion. -- 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

[serialization docs] Ping?
by David Abrahams 23 Sep '05

23 Sep '05

"Robert Ramey" <ramey(a)rrsd.com> writes: > David Abrahams [mailto:dave@boost-consulting.com] wrote: > > The following message is a courtesy copy of an article > that has been posted to gmane.comp.lib.boost.devel as well. > > > Hi Robert, > > Are you going to reply to > > http://article.gmane.org/gmane.comp.lib.boost.devel/131257 > > ?? > > Thanks, > > I considered your comments and re-wrote the section Archive Concept and it's > checked into RC_1_33_0. It's an improvement, but either you missed or intentionally discarded some of my more important remarks. The most important question was: **** Isn't something in an Archive required to call "serialize?" **** If not, how does an Archive work with Serializable types? > There are two Archive concepts. Given a set of C++ data > structures consisting of Serializable types, a Saving Archive > will create a sequence of bytes. Given a sequence of bytes > created by a Saving Archive, a Loading Archive will reconstitute > the orginal configuration of C++ data structures. Both Archive > concepts are derived from the more basic concept of Archive. This is confusing and self-contradictory. Your text clearly states that there are two Archive concepts and then goes on to describe three Archive concepts: Archive, Saving Archive, and Loading Archive. > Notation > > In the following descriptions, it is assumed that: ^^^^^^^^^^^^^^^^^^^^ Strike this. You are telling the reader what these identifiers mean, not interpreting something about which you need to make some assumption. > • A is an Archive type > • T is an Serializable Type > • ar is an instance of type A. > • x is an instance of type T. > • u is an address. An address is an abstract notion; it doesn't have any value in the type system. You have to say "u is any pointer"... but see below. > Common Type Definitions in all Archives This should be a section for the "Archive" concept. These are not type definitions but valid expressions. > A::is_saving > > An integral constant of type boost::mpl::bool_. I'm sorry to be so blunt, but that's nonsense. A::is_saving is a type, not an integral constant, and boost::mpl::bool_ is a class template, not a type. If you mean to refer to the MPL Integral Constant concept, the correct thing to say would be: A boolean MPL Integral Constant with a link to the documentation for that concept. > Value is boost::mpl::bool_<true> "Value?" This is also nonsense. The ::value member of an MPL Integral Constant is an integral constant, not a type, but boost::mpl::bool_<true> is a type. I normally > if the Archive is a Saving Archive (see below) and > boost::mpl::bool_<false> otherwise. > A::is_loading > > An integral constant of type boost::mpl::bool_. Value is > boost::mpl::bool_<true> if the Archive is a Loading Archive > (see below) and boost::mpl::bool_<false> otherwise. Ditto. > Common Member Functions in all Archives Again, these are not member functions, but valid expressions. Presumably "ar & x" can be implemented by a free function and "ar.template register_type<T>()" invokes a member function template. > ar & x > > Returns a reference to ar. Appends the value of x along with > other information to ar. I think you should swap the two sentences; emphasis should be on effects and only secondarily on return value. But wait. Surely this expression, with the specified semantics, doesn't have to be valid for loading archives? Are you saying that all archives have to be able to save? > ar.template register_type<T>(); You should leave out "template." This is a little tricky, but that expression will never be valid in a context where A is not a dependent type. I realize you do need it when A is a dependent type, but the convention is to use the simpler notation. The author of an archive isn't going to be calling register_type anyway (especially not in a dependent context), so it won't help prevent him from making errors. > ar.register_type(u); > > Append information about class T to the archive. ^--"s" If so then you need to say that u is an expression of type T* > This information is used to construct the correct class when a > derived pointer is loaded. Invocation of this member function is > referred to as "class registration". This is explained in detail > in Special Considerations - Derived Pointers. > ar.library_version() > > Returns an unsigned integer containing the version number of > the serialization library that created the archive. This > number will be incremented each time the library is altered > in such a way that serialization could be altered for some > type. For example, suppose the type used for a count of > collection members is changed. The code that loads > collections might be conditioned on the library version to > make sure that libraries created by previous versions of the > library can still be read. Good! > Saving Archive > > A Saving Archive is a refinement of the Archive Concept. ^--- strike "A." The Saving Archive concept refines Archive. "A saving archive" referes either to a model of Saving Archive or an instance of such a model. > Notation > > In the following descriptions, it is assumed that: > > • ar is an instance of a Saving Archive. > • x is an instance of a Serializable Type. > • u is an address. A pointer again. > • count is an integer that can be converted to std::size_t. ^^^^^^^ no, it's an instance of any type that can be so converted. Your "strong typedef" isn't an integral type. > > Common Member Functions Valid expressions again. > ar << x > > Returns a reference to ar. Appends the value of x along with > other information to ar. Doesn't this have to call serialize(...) somehow? > ar.save_binary(u, count) > > Appends to the archive count bytes found at address. Actually it must be Appends to ar the std::size_t(count) bytes found at address. but doesn't it have to call serialize(...) somehow? > Loading Archive > > Notation > > In the following descriptions, it is assumed that: > > • ar is an instance of a Loading Archive. > • x is an instance of a Serializable Type. > • u, v are pointers to any type. > • count is an integer that can be converted to std::size_t. > > Common Member Functions in all Archives > > ar >> x > > Returns a reference to ar. Sets x with a value retrieved from ^^^^ I would say "to" > the ar. ^^^ strike this. Doesn't this have to call serialize(...) somehow? > ar.load_binary(u, count) > > Retrieves from the archive count bytes and stores them in ^^^^^^^^^^ "ar" > memory starting at address. ^^^^^^^ "u" Doesn't this have to call serialize(...) somehow? > ar.reset_object_address(v, u) > > Communicates to the archive that the object originally at > address u has been moved to address v. > > In order to facilitate loading of objects through a pointer > and to elminate redundant loading of objects, this system > implements object address tracking. Normally this is done > automatically with no action required on the part of the > user. For an implementor of an archive, this whole statement is confusing. Do I need to implement object tracking, or is provided for me somehow by "this system?" Is it done automatically? If so, by whom? I think I know the answers to these questions, but I'm not sure a new reader will. > However, there are cases when an object must be de-serialized to > a temporary location then moved to its final destination. This > is common in loading collections. > > In such cases, reset_object_address should be invoked to > communicate the final address of the last item loaded. This > permits the internal tables to be correctly maintained in > these special cases. > ar.delete_created_pointers() > > Deletes all objects created by the loading of pointers. This > can be used to avoid memory leaks that might otherwise occur if > pointers are being loaded and the archive load encounters an > exception. The following sentence belongs under "Archive Models." > There are archives based on text, binary and XML file formats but > all have the above interface. > Given that all archives present the > same public interface, specifcation of serialization is exactly > the same for all archives. Archive classes have other members not > mentioned here. However they are related to the internal > functioning of the library and are not meant to be called by > users of an archive. Are you telling me, after all this, that there are additional requirements on archives not documented in the section on Archive concepts? I find this rather alarming. Haven't I made it abundantly clear that the concept documentation has to give at least a minimal and complete documentation of what's required of an Archive? > Implementation of new archives is discussed in New Archives - > Implementation. Which then goes on to describe some "input archive" idea that hasn't been defined, etc... <snip> Okay, I don't know what to say at this point. I'm about to give up, because I don't have the time to keep going over this. It sure seems like you want to do this your own way, rather than by following the established practices and norms. If you were just "creative" but still rigorous, it would be one thing, but it doesn't even seem like you're paying close attention to what you yourself are writing. What should I do? > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > > © Copyright Robert Ramey 2002-2004. Distributed under the Boost > Software License, Version 1.0. (See accompanying file > LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) You might want to update the copyright date. -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 17

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

23 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-22T15:34:14Z 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. utility/enable_if Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 127 failures in 9 libraries: concept_check (20) foreach (1) graph (5) random (1) range (3) serialization (70) thread (8) utility/enable_if (16) 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 intel-win32-9_0 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 |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: 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_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_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 |utility/enable_if| constructors: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dummy_arg_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lazy_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_templates: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux namespace_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux no_disambiguation: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux partial_specializations: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

3 2

[Boost-bugs] [ boost-Support Requests-1299123 ] Boost.Iostreams and newline translation
by SourceForge.net 23 Sep '05

23 Sep '05

Support Requests item #1299123, was opened at 2005-09-22 15:00 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=1299123&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: jpstanley (jpstanley) Assigned to: Nobody/Anonymous (nobody) Summary: Boost.Iostreams and newline translation Initial Comment: I like the Boost.Iostreams framework in Boost 1.33. But I haven't found a way to make it do exactly what I want. I maintain software that parses files out of disk images instead of the local file system. I'd like to be able to wrap a C++ istream around my raw binary read/seek APIs to make it easier to parse data from disk images and interface with existing code. Boost.Iostreams makes this job a piece of cake--except that I haven't found a way to make the stream act like an ifstream opened in text mode (I'm on Win32, btw). In other words, I'd like to have CR, LF, and CRLF line endings translated into \n when I read the data. There is a newline_filter class provided which does nearly exactly what I want--but it doesn't support seeking. I still need seekg() and tellg() to work. I tried writing my own filter, but I ran into some problems. It seems the Boost stream buffer class is built on the assumption that this will hold: std::streamsize P0 = str.tellg(); str.read(buf, 100); std::streamsize P1 = str.tellg(); assert(P1 - P0 == 100); But with an ifstream opened in text mode, this assertion can fail (P1 - P0 > 100) if two-character CRLF combinations were translated into a one-character newline in the intervening data. Is it possible to implement an input-seekable filter that will let a Boost.Iostream behave this way? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1299123&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 2

Documentation Wizard
by David Abrahams 22 Sep '05

22 Sep '05

Allow me to introduce Rob Stewart in his new role as Boost Documentation Wizard. For some time we've needed a person to establish standards and policy, and to help ensure that Boost library documentation is of the highest quality. Rob has demonstrated both the interest and the aptitude for this job, and the Boost moderators are very pleased that he's accepted our invitation to take it on. He has lots of good ideas, so I'll leave the rest to him. Rob? -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 4

[metamath] Using mpl::numeric_cast
by Cromwell Enage 22 Sep '05

22 Sep '05

Scattered throughout the metamath library are template specializations of numeric metafunction classes like the following: template <> struct times_impl< integral_c_tag , metamath::double_c_tag > { ... } The purpose of mpl::numeric_cast<> (or BOOST_MPL_AUX_NUMERIC_CAST) is to render such specializations unnecessary. I understand that if template instantiation overhead is a problem then the current situation is okay, but if we start implementing more numeric metatypes such as metamath::float_ and/or metamath::long_double_, then the net increase in code size will become an issue. Also included in the last update of my math sublibrary are files from the metamath library that I modified to make use of BOOST_MPL_AUX_NUMERIC_CAST: * In <boost/metamath/double/double.hpp> I modified double_c_tag so that it inherits from boost::mpl::int_<8> (an arbitrary constant higher than zero). * In <boost/metamath/double/integral_to_double.hpp> I added a template specialization of BOOST_MPL_AUX_NUMERIC_CAST that uses integral_to_double<>. * In the other files I deleted the redundant specializations. Let me know what you think. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 6

Re: [boost] [SPAM] Re: [scope_guard] New revision available + naming consideration
by Jason Stewart 22 Sep '05

22 Sep '05

>You're missing the usage of wanting to keep the original undo >behavior, ignore it in some portion of the code, and then >reinstate it later. With the above, it appears that would entail >this sort of usage: > > scope_guard g(my_undo_function); > ... > g = scope_guard(); > ... > g = scope_guard(my_undo_function); > ... > >That introduces a maintenance problem. With the names we're >discussing, you'd write this instead: > > scope_guard g(my_undo_function); > ... > g.dismiss(); // or whatever name is selected > ... > g.protect(); // or whatever name is selected > ... Ok, I can see that. I like the latest suggestion of dismiss/protect. abandon might be another possiblity for dismiss and seems to go with protect. Jason Stewart

1 0

Re: [boost] [Review] xpressive
by Martin Bonner 22 Sep '05

22 Sep '05

----Original Message---- From: Daryle Walker [mailto:darylew@hotmail.com] Sent: 18 September 2005 20:54 To: Boost mailing list Subject: Re: [boost] [Review] xpressive > Making something like: > > std::copy( pieces.begin(), pieces.end(), destination ); > > completely useless isn't unfriendly? > You'll have to use a (mutable) object to store > "pieces.begin()" so you can increment it before the copy ??? Why can't you use: std::copy( ++pieces.begin(), pieces.end(), destination ); -- 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