July 2005 - Boost - lists.boost.org

[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 12 Jul '05

12 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

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

11 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-11T15:12:33Z 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 preprocessor io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 480 failures in 12 libraries: io (1) multi_index (1) parameter (42) preprocessor (1) program_options (5) random (2) range (1) serialization (412) spirit (1) test (6) thread (1) wave (7) |io| ios_state_unit_test: intel-win32-8_1 |multi_index| test_basic: vc-8_0 |parameter| basics: 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-4.0.0-linux intel-8.1-linux mingw-3_4_2 vc-7_1 vc-8_0 macros: 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-4.0.0-linux intel-8.1-linux mingw-3_4_2 vc-7_1 vc-8_0 sfinae: 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-4.0.0-linux intel-8.1-linux mingw-3_4_2 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 |range| algorithm_example: vc-8_0 |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 intel-win32-8_1 test_demo_exception_dll: cw-9_4 cw-9_4 intel-win32-8_1 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 intel-win32-8_1 msvc vc-6_5 vc-7_0 test_demo_xml_load_dll: intel-win32-8_1 test_demo_xml_save_dll: intel-win32-8_1 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_exported_binary_archive: msvc vc-6_5 test_exported_binary_archive_dll: msvc vc-6_5 test_exported_text_archive: msvc vc-6_5 test_exported_text_archive_dll: msvc vc-6_5 test_exported_text_warchive: msvc vc-6_5 test_exported_text_warchive_dll: msvc vc-6_5 test_exported_xml_archive: msvc vc-6_5 test_exported_xml_archive_dll: msvc vc-6_5 test_exported_xml_warchive: msvc vc-6_5 test_exported_xml_warchive_dll: msvc vc-6_5 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_mi_binary_archive_dll: intel-win32-8_1 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_no_rtti_binary_archive: msvc vc-6_5 test_no_rtti_binary_archive_dll: msvc vc-6_5 test_no_rtti_text_archive: msvc vc-6_5 test_no_rtti_text_archive_dll: msvc vc-6_5 test_no_rtti_text_warchive: msvc vc-6_5 test_no_rtti_text_warchive_dll: msvc vc-6_5 test_no_rtti_xml_archive: msvc vc-6_5 test_no_rtti_xml_archive_dll: msvc vc-6_5 test_no_rtti_xml_warchive: msvc vc-6_5 test_no_rtti_xml_warchive_dll: 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 msvc vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: borland-5_6_4 msvc vc-6_5 test_shared_ptr_132_text_archive: borland-5_6_4 intel-win32-8_1 msvc vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: borland-5_6_4 msvc vc-6_5 test_shared_ptr_132_text_warchive: borland-5_6_4 msvc vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: borland-5_6_4 msvc vc-6_5 test_shared_ptr_132_xml_archive: borland-5_6_4 msvc vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: borland-5_6_4 msvc vc-6_5 test_shared_ptr_132_xml_warchive: borland-5_6_4 msvc vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 msvc vc-6_5 test_shared_ptr_binary_archive: msvc vc-6_5 test_shared_ptr_binary_archive_dll: msvc vc-6_5 test_shared_ptr_text_archive: msvc vc-6_5 test_shared_ptr_text_archive_dll: msvc vc-6_5 test_shared_ptr_text_warchive: msvc vc-6_5 test_shared_ptr_text_warchive_dll: msvc vc-6_5 test_shared_ptr_xml_archive: msvc vc-6_5 test_shared_ptr_xml_archive_dll: msvc vc-6_5 test_shared_ptr_xml_warchive: msvc vc-6_5 test_shared_ptr_xml_warchive_dll: msvc vc-6_5 |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 |thread| test_read_write_mutex: borland-5_6_4 |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

1 0

Re: [boost] [optional] library documentation typo
by Martin Bonner 11 Jul '05

11 Jul '05

----Original Message---- From: Felipe Magno de Almeida [mailto:felipe.m.almeida@gmail.com] Sent: 07 July 2005 13:55 To: boost(a)lists.boost.org Subject: [boost] [optional] library documentation typo > In the "The Interface" part, in the end of this text: > <quote> > For value access operations optional<> uses operators * and -> to > lexically warn about the possibliy uninitialized state appealing to > the familiar pointer semantics w.r.t. to null pointers. > However, it is particularly important to note that optional<> objects > are not pointers. optional<> is not, and does not model, a pointer. > > For instance, > optional<> has not shallow-copy Should be "optional<> does not have shallow-copy" Don't ask me to explain the logic behind the rules of English! > so does not alias: two > different optionals never refer to the same value unless T itself is > an reference Should be "a reference" >(but my have equivalent values). I agree, "(but may have equivalent values). > </quote> > I think it should be: > (but may have equivalent values). > > may in the place of my... > > Thanks for boost and best regards, > Felipe. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

4 3

[thread] patch for borland regression
by Tobias Schwinger 11 Jul '05

11 Jul '05

Hi, here is a patch for the Borland regression of Boost.Thread. The problem: ------------ For some odd reasons BCC 5.6.4 fails to export a symbol for the destructor of read_write_mutex_impl. Solution annotations: --------------------- 1.1. Forced template instantiation of the destructor (which again needed a workaround, because explicit instantiation of a destructor does not seem to work) and it did not help 1.2. The destructor currently only contains assertions so I ended up commenting it 2.1. There are still some warnings (unreachable code, condition always true) wasn't sure whether it's safe to disable them 2.2. Tested with 5.6.5 and it works without the workaround (that's why there is no BOOST_TESTED_AT) 2.3. Tested with 5.5.0 and 5.5.1 and solved another minor problem with windows headers (size_t isn't visible at root namespace when compiling once.cpp) 2.4. Compiled and ran the read_write_mutex test for all compilers and it passed 2.5. Someone should perhaps test if Kylix needs the 5.6.4-workaround as well Regards, Tobias Index: boost/thread/read_write_mutex.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/thread/read_write_mutex.hpp,v retrieving revision 1.8 diff -u -r1.8 read_write_mutex.hpp --- boost/thread/read_write_mutex.hpp 29 Mar 2005 21:45:54 -0000 1.8 +++ boost/thread/read_write_mutex.hpp 3 Jul 2005 23:31:39 -0000 @@ -19,6 +19,7 @@ #include <boost/thread/detail/config.hpp> #include <boost/utility.hpp> +#include <boost/detail/workaround.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/detail/lock.hpp> @@ -52,7 +53,9 @@ typedef detail::thread::scoped_timed_lock<Mutex> scoped_timed_lock; read_write_mutex_impl(read_write_scheduling_policy::read_write_scheduling_policy_enum sp); +#if !BOOST_WORKAROUND(__BORLANDC__,<= 0x564) ~read_write_mutex_impl(); +#endif Mutex m_prot; Index: libs/thread/src/read_write_mutex.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/read_write_mutex.cpp,v retrieving revision 1.20 diff -u -r1.20 read_write_mutex.cpp --- libs/thread/src/read_write_mutex.cpp 3 May 2005 20:42:09 -0000 1.20 +++ libs/thread/src/read_write_mutex.cpp 3 Jul 2005 23:36:16 -0000 @@ -27,6 +27,8 @@ #include <boost/thread/read_write_mutex.hpp> #include <boost/thread/xtime.hpp> +#include <boost/detail/workaround.hpp> + #if !defined(BOOST_NO_STRINGSTREAM) # include <sstream> #endif @@ -376,6 +378,7 @@ , m_readers_next(true) {} +#if !BOOST_WORKAROUND(__BORLANDC__, <= 0x564) template<typename Mutex> read_write_mutex_impl<Mutex>::~read_write_mutex_impl() { @@ -390,6 +393,7 @@ BOOST_ASSERT(m_num_waking_readers == 0); BOOST_ASSERT(m_num_max_waking_readers == 0); } +#endif template<typename Mutex> void read_write_mutex_impl<Mutex>::do_read_lock() Index: libs/thread/src/once.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/once.cpp,v retrieving revision 1.19 diff -u -r1.19 once.cpp --- libs/thread/src/once.cpp 17 Jul 2004 04:33:59 -0000 1.19 +++ libs/thread/src/once.cpp 3 Jul 2005 23:25:19 -0000 @@ -11,11 +11,17 @@ #include <boost/thread/detail/config.hpp> +#include <boost/detail/workaround.hpp> + #include <boost/thread/once.hpp> #include <cstdio> #include <cassert> + #if defined(BOOST_HAS_WINTHREADS) +# if BOOST_WORKAROUND(__BORLANDC__,<= 0x551) + using std::size_t; +# endif # include <windows.h> # if defined(BOOST_NO_STRINGSTREAM) # include <strstream>

2 1