- Boost - lists.boost.org

Boost regression notification (2005-07-12)
by Douglas Gregor 13 Jul '05

13 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-12T14:33: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. random io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 390 failures in 10 libraries: date_time (2) io (1) parameter (45) preprocessor (1) program_options (5) random (2) serialization (320) spirit (1) test (6) wave (7) |date_time| testlocal_time_input_facet: cw-9_4 testtime_input_facet: cw-9_4 |io| ios_state_unit_test: intel-win32-8_1 |parameter| basics: 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-darwin gcc-3_4_3-sunos intel-win32-8_1 intel-win32-8_1 msvc macros: 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-darwin gcc-3_4_3-sunos intel-win32-8_1 intel-win32-8_1 msvc sfinae: borland-5_6_4 cw-8_3 cw-9_4 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.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4.0.0-linux intel-8.1-linux intel-win32-8_1 intel-win32-8_1 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-8_0 |preprocessor| seq: cw-8_3 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor2_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_default_ctor2_text_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_default_ctor2_xml_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_default_ctor_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_intrusive_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_intrusive_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_shared_ptr_132_binary_archive: borland-5_6_4 test_shared_ptr_132_binary_archive_dll: borland-5_6_4 test_shared_ptr_132_text_archive: borland-5_6_4 test_shared_ptr_132_text_archive_dll: borland-5_6_4 test_shared_ptr_132_text_warchive: borland-5_6_4 test_shared_ptr_132_text_warchive_dll: borland-5_6_4 test_shared_ptr_132_xml_archive: borland-5_6_4 test_shared_ptr_132_xml_archive_dll: borland-5_6_4 test_shared_ptr_132_xml_warchive: borland-5_6_4 test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: cw-9_4 test_slex_lexer: cw-9_4 testwave: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux

3 2

[1.33.0] Release status and updated timeline
by Douglas Gregor 12 Jul '05

12 Jul '05

The regression tests are starting to look quite a bit better now, and most of the other pre-release activities (inspection report, documentation updates) are going well. There are a few issues we need to resolve before we can wrap up this release: 1. The Serialization lib is failing many of its regression tests. We need to get these under control. 2. PDF generation of BoostBook documentation is failing (problems with FOP) If anyone else has any other pre-release activities that need to get done, please tell me ASAP. I plan to roll prerelease tarballs this weekend, and hope to release within the next two weeks. Doug Gregor 1.33.0 Release Manager

8 12

Digital Mars C++ regression tests
by Aleksey Gurtovoy 12 Jul '05

12 Jul '05

The following message is a courtesy copy of an article that has been posted to gmane.comp.lib.boost.testing as well. ... are now up and running! We've finally sorted out all the setup issues that prevented the reports audience from seeing the actual status of the toolset, so hopefully now the interested parties can start taking the look at the failures and work together on improving the compiler's standing with Boost. The results are available at http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/summar… under "dmc-8_44b-stlport-4_5_3" column. Enjoy, -- Aleksey Gurtovoy MetaCommunications Engineering

7 14

[Boost-bugs] [ boost-Support Requests-1236739 ] .Net 2005 Beta 2 and VC++ 8.0
by SourceForge.net 12 Jul '05

12 Jul '05

Support Requests item #1236739, was opened at 2005-07-12 07:19 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=1236739&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: .Net 2005 Beta 2 and VC++ 8.0 Initial Comment: Hello, I'm testing our apps with VS .Net 2005 Beta 2. I encountered some difficulties with Boost. Some samples of the errors messages I got at linkage: libboost_date_time-vc6-mt-gd-1_32.lib(greg_month.obj) : warning LNK4049: locally defined symbol ?? 1out_of_range@std@@UAE@XZ (public: virtual __thiscall std::out_of_range::~out_of_range(void)) imported libboost_date_time-vc6-mt-gd-1_32.lib(greg_month.obj) : warning LNK4217: locally defined symbol ?? 0out_of_range@std@@QAE@ABV?$basic_string@DU? $char_traits@D@std@@V? $allocator@D@2@@1@@Z (public: __thiscall std::out_of_range::out_of_range(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)) imported in function "public: __thiscall boost::gregorian::bad_month::bad_month(void)" (?? 0bad_month@gregorian@boost@@QAE@XZ) libboost_date_time-vc6-mt-gd-1_32.lib(greg_month.obj) : warning LNK4217: locally defined symbol ?? 0out_of_range@std@@QAE@ABV01@@Z (public: __thiscall std::out_of_range::out_of_range(class std::out_of_range const &)) imported in function "public: __thiscall boost::gregorian::bad_month::bad_month (struct boost::gregorian::bad_month const &)" (?? 0bad_month@gregorian@boost@@QAE@ABU012@@Z ) libboost_signals-vc6-mt-gd-1_32.lib (named_slot_map.obj) : warning LNK4049: locally defined symbol ??1runtime_error@std@@UAE@XZ (public: virtual __thiscall std::runtime_error::~runtime_error(void)) imported libboost_signals-vc6-mt-gd-1_32.lib (named_slot_map.obj) : warning LNK4217: locally defined symbol ??0runtime_error@std@@QAE@ABV? $basic_string@DU?$char_traits@D@std@@V? $allocator@D@2@@1@@Z (public: __thiscall std::runtime_error::runtime_error(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)) imported in function "public: __thiscall boost::bad_function_call::bad_function_call(void)" (?? 0bad_function_call@boost@@QAE@XZ) libboost_signals-vc6-mt-gd-1_32.lib (named_slot_map.obj) : warning LNK4217: locally defined symbol ?? 0runtime_error@std@@QAE@ABV01@@Z (public: __thiscall std::runtime_error::runtime_error(class std::runtime_error const &)) imported in function "public: __thiscall boost::bad_function_call::bad_function_call (class boost::bad_function_call const &)" (?? 0bad_function_call@boost@@QAE@ABV01@@Z) I also found some compile-time errors, but I think it is our fault, I must investigate some more. Did boost 1.32 work with VS .Net 2005 beta 2? I'm sure I'm not the first to try. Any advice about this issue or others? If a new release of Boost is needed, is a team working on it? How can I help? Our old compiler was VC++ 6.0, I use Boost 1.32, latest release. Thanks all ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1236739&group_… ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[serialization] Patch : Borland workarounds for shared_ptr_132.hpp
by AlisdairM 12 Jul '05

12 Jul '05

The following patches compile for bcc 0x564 - I don't have a version of the library built to link against to verify the run time nature of the test. cvs diff -w shared_ptr_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_ptr_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_ptr_132.hpp,v retrieving revision 1.2 diff -w -r1.2 shared_ptr_132.hpp 42a43,44 > > #if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) 43a46 > #endif 123a127,130 > #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) > template<class Y> > explicit shared_ptr(Y * p): px(p), pn(p, boost::checked_deleter<Y>()) // Y must be complete > #else 125a133 > #endif and cvs diff -w shared_count_132.hpp (in directory D:\Projects\boost\boost\serialization\detail) Index: shared_count_132.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/detail/shared_count_132.hpp,v retrieving revision 1.1 diff -w -r1.1 shared_count_132.hpp 46a47,48 > > #if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) 47a50 > #endif 86a90 > #if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) 87a92 > #endif 92a98,100 > #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) > typedef boost::detail::lightweight_mutex mutex_type; > #else 93a102 > #endif -- AlisdairM

4 12

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 12 Jul '05

12 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > Sent: Sunday, July 10, 2005 10:23 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > Eelis van der Weegen <gmane(a)contacts.eelis.net> writes: > > > So, in conclusion, the motivation for your dual_state is > very valid, > > but personally I think Boost.Optional is a more appropriate design. > > IMO the "guaranteed object delivery" feature makes for a > useful specialization of the Boost.Optional design. However, > it would be nice to have both; it's not an alternative to > Boost.Optional. I agree. These are two separate ideas, each with its own utility. > > There's a lot of resonance with the Boost.Parameter library in here. Where can I find information on Boost.Parameter? One additional thought occurred to me. How does Boost.Optional handle cases where object construction fails? I'm not sure how many approaches exist to the problem of failed constructors, but I think most programmers agree that constructors should rarely (if ever) be allowed to throw an exception. Would it make sense for Boost.Optional to detect failed constructors and consider those objects uninitialized? Here is a contrived example: // -- begin class construct_status { /* TBD */ }; class foo : public construct_status { int *i; public: foo() throw() : i(new(nothrow) int) { if( !i ) { this->construct_status::set_bad(); } else { this->construct_status::set_good(); } } }; boost::optional<foo> x = foo(); if( !x ) { // end up here if the foo constructor called construct_status::set_bad } // -- end It seems that if Boost.Optional users must always test for initialization anyway, we could add a valid object check for free. I would be interested to hear what others think about this. -Andy

4 3

MS compiler detection
by Ulrich Eckhardt 11 Jul '05

11 Jul '05

Hi! I ported large parts of Boost 1.32 to embedded Visual C++ 4 some time ago. One of the major changes was because the included cross compilers reported _MSC_VER somewhere in between 1200 and 1202. IOW, a plethora of cases that checked ==1200 or >1200 failed to work for a few of them. I already once submitted a patch, but it hasn't been incorporated yet, so here is one against CVS from this afternoon. The changes I made were mostly mechanical: MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER == 1200 -> MSC_VER < 1300 MSC_VER >= 1300 -> MSC_VER > 1200 Some other changes were that I corrected a few comments that spoke of only VC6, but there are too many of them - I didn't get them all. Another change was that I prepared the autolinking feature for evc4. I tested the changes on a mirror of CVS from 6 months ago, and so far it seems to work with evc4, vc6 and vc7.1. BTW-1: I also noticed the same problem with other compilers/versions, i.e. there are checks like 'MSC_VER > 1310' targeting VC8. This will fail if there comes a service pack with a compiler with version 13.11, not an acute problem though, just something to keep in mind perhaps. BTW-2: There are a few cases where the compiler version was used to check for a feature of the standardlibrary some variants of it came bundled with. I think I marked these places with a 'TODO' tag. For all who wonder, there is no real standardlibrary shipped with evc4, neither a C nor a C++ one. STLport is mandatory therefore. Also, the functions of the win32 API that use TCHAR=char are also almost gone, but those are another patch another day. A last thing is that when linking, the name of the lib must not be larger than 32 chars, or the runtime linker won't be able to find the lib. Explicit loading with LoadLibrary still works. Guess how much blood, sweat&tears it took me to find out ... the threads lib which is the only one I need is 33 chars or somesuch. Please commit these changes, they are easy to verify and nonintrusive for unaffected compilers, thanks. Uli

6 11

[iostreams] request for advice on naming [repost]
by Jonathan Turkanis 11 Jul '05

11 Jul '05

Dear all, I'm considering some last minute name changes for the iostreams library, and would like some feedback. There are two issues: 1. the names of the fundamental components streambuf_facade and stream_facade 2. inconsistent header names (Note: these changes shouldn't affect the regression tests -- unless I botch them) ----------------------- streambuf_facade and stream_facade: Before I settled on "streambuf_facade" and "stream_facade," I tried five or six other pairs of names for these templates. I finally picked the current names because of the analogy with the iterators library. However, the templates are not really facades -- in the GOF sense -- and I'm not sure that the analogy with the iterators library will be very effective in helping users understand these templates. As a result, I'm think of using the less technical-sounding names "generic_streambuf" and "generic_stream." What do people think? ----------------------- inconsistent header names: Until now I've followed the policy that a header should have the same name as the component it contains, if it contains a single component, and a short descriptive name if it contains several related components. For example, the header regex_filter.hpp contains the single component regex_filter, while the header zlib.hpp contains the component zlib_error, zlib_params, zlib_compressor and zlib_decompressor. This policy has resulted in a peculiar mix of names. For instance, boost/iostreams/filter now contains: bzip2.hpp counter.hpp gzip.hpp line_filter.hpp newline.hpp one_step_filter.hpp regex_filter.hpp stdio_filter.hpp symmetric_filter_adapter.hpp test.hpp zlib.hpp As you can see, some contain "_filter" and some don't, and it all depends on whether the header contains more than one component, which can be hard to remember. I'm thinking of renaming the headers that are curently based on component names so that all headers will have short, simple names. E.g., bzip2.hpp counter.hpp gzip.hpp line.hpp newline.hpp one_step.hpp regex.hpp stdio.hpp symmetric.hpp test.hpp zlib.hpp Thoughts? Best Regards, Jonathan

4 16

[Parameter] New failures due to missing boost/parameter/instance.hpp
by Doug Gregor 11 Jul '05

11 Jul '05

e.g., In file included from ../libs/parameter/test/basics.cpp:12: ../libs/parameter/test/basics.hpp:11: boost/parameter/instance.hpp: No such file or directory Doug

2 1

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 11 Jul '05

11 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van > der Weegen > Sent: Sunday, July 10, 2005 9:47 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > Jost, Andrew wrote: > > *THE UNDEFINED_OBJECT* > > A third difference between Boost.optional and dual_state > involves the > > very personal issue of syntax. It is nonsense to tell people to > > prefer one syntax over another, but I will note that > dual_state's use > > of the undefined_object lends a unique feel to code that > uses it. The > > programmer's intent is unmistakably clear when "undef" is used to > > initialize members: > > > > [snip] > > > > The concept of using self-evident constructs to obviate > documentation > > is a valuable one. It is detailed in the Boost.noncopyable notes. > > Boost.Optional has some interaction with (including > initialization from) boost::none, which seems to correspond > to your "undef". Good point, but I would also like to see overloaded == and != operators using boost::none. > > Regarding guaranteed object delivery: > I must say I find this design aim questionable. The whole > point of these facilities (Boost.Optional and your > dual_state) is that there are situations where it is simply > not possible to assign a meaningful value to the object. It > is only logical that this implies that wherever the object is > used, there must either be some invariant in user code that > guarantees that it is defined, or an if/else to deal with > both cases. Quickly default constructing the underlying > object when it turns out that the user is attempting to use > it when it is not defined seems like a very arbitrary thing > to do, and I believe it will only be sensible and correct in > very few situations. This is the first reason why the notion > of Boost.Optional being a model of OptionalPointee appeals to me. Our opinions differ on this point. I believe there are cases where providing a default object is quite appropriate, but again, it all depends on the application. If, as you say, an "invariant in user code" can be used to control a program's behavior, why can't the defined and documented behavior of default object delivery serve as the invariant -- especially if it simplifies syntax? > Regarding full operator support: > I'm very skeptic about this design aim, mainly because it is > an attempt at making the class as a whole a transparent > wrapper around the underlying object, which is fundamentally > not possible in C++ and will only cause confusion. Sure, the > syntax is nice for a few cases, but conceptually it makes the > interface complex and inconsistent. I'm skeptical, too. I am happy to discard this idea. > This is the second reason > why the notion of Boost.Optional being a model of > OptionalPointee appeals to me: the syntax and semantics are > pretty much as one would expect (from a smart pointer). > > So, in conclusion, the motivation for your dual_state is very > valid, but personally I think Boost.Optional is a more > appropriate design. > > Eelis Thanks, for your opinion. I would say we mostly agree, except that I believe there are cases where guaranteed object delivery is useful. Perhaps something like dual_state would be best built as an addition to Boost.optional, as David Abrahams has suggested. So we could say Boost.optional is a robust and appropriate design, and dual_state may offer some useful (though, uh, optional) additions to Boost.optional. Thanks again. -Andy

2 1