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

[parameter][1.33.1] last few failures
by John Maddock 27 Oct '05

27 Oct '05

Dave, Daniel, are the last few failures (http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i…) of the parameter lib fixable or should they be marked up? Thanks, John.

3 8

Re: [boost] Is there any interest in a library that provides cont ainers with virtual destructors?
by Martin Bonner 27 Oct '05

27 Oct '05

----Original Message---- From: Victor A. Wagner Jr. [mailto:vawjr@rudbek.com] Sent: 27 October 2005 03:55 To: boost(a)lists.boost.org; boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library that provides containers with virtual destructors? > [deleted] > >>>> >>>> are you suggesting that if it were class people: public >>>> std::vector<person> {.....}; as above the same would be true? >>>> not "in practice", "in theory". >>> >>> Absolutely. See 5.3.5/1 of the standard where this is explicitly >>> called out as undefined behaviour. > > 5.3.5/1 looks like this in my copy of the standard [snip] > > perhaps some other paragraph? this doesn't address anything about > derived objects. D'oh! As others have pointed out, I meant 5.3.5/3. Sorry about that :-( -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

range idea (single)
by Neal Becker 27 Oct '05

27 Oct '05

Suppose one adopts the range concept. All algorithms are written to accept ranges as arguments. It is common to want to implement a function F, which operates on one data element. For example: template<typename T> T sqr (T x) { return x * x; } Also, implement a version that operates on a container. This could be done by defining only the single element version, and a version of transform, that operates on ranges. Here's an interesting idea. Suppose instead that only the range version of F is defined, but a range type is made that encapsulates a single element. Again, only 1 version of F needs to be defined. Here is an outline: template<typename T> struct Single { typedef T* iterator; typedef const T* const_iterator; typedef size_t size_type; Single (T& _x) : x (_x) {} T& x; size_t size() const { return 1; } iterator begin() { return &x; } const_iterator begin() const { return &x; } iterator end() { return &x+1; } const_iterator end() const { return &x+1; } // not complete yet... }; // Test program... template<typename out_t, typename in_t> out_t copy (in_t const& in) { out_t out (boost::size (in)); std::copy (boost::begin (in), boost::end (in), boost::begin (out)); return out; } int main() { using namespace std; using namespace boost; int x; Single<int> s (x); vector<int> v = copy<vector<int> > (s); }

3 2

Re: [boost] Is there any interest in a library that provides containers with virtual destructors?
by Victor A. Wagner Jr. 27 Oct '05

27 Oct '05

At 21:52 2005-10-26, Matt Calabrese wrote: >On 10/26/05, Victor A. Wagner Jr. <vawjr(a)rudbek.com> wrote: > > > perhaps some other paragraph? this doesn't address anything about > > derived objects. > > >Just look 2 paragraphs further: > >5.3.5 paragraph 3 > >"In the first alternative (delete object), if the static type of the operand >is different from its dynamic type, the static type shall be a base class of >the operand's dynamic type and the static type shall have a virtual >destructor or the behavior is undefined." ... indeed, but there is no dynamic type vs static type in the example. >The paragraph then goes further to talk about arrays. > >As for interest in the STL containers with virtual destructors, I'd >personally say no. I didn't suggest them, I'm arguing that for the example given they aren't necessary > I've never encountered a situation where it would be >useful or at least useful and better than other alternatives. Anyway, the >desire for a virtual destructor could exist with any type. If someone wants >virtual destructors for STL containers, then what next? multi_array with >virtual destructors? graphs? Forgive me if that sounds like a slippery slope >argument, but really I see no logic as to why one would want virtual >destructors for STL containers yet not any other types. You can use the same >type of argument for any type you can think of -- "I want to derive from the >type and then add functionality, but want to delete it via a pointer to the >base class". I have never said such. I don't know where you got the idea I had. > Does this mean that all types should have one version with >virtual destructors, and one without? Definately not. I just don't see why >someone would want to make the exception for STL containers. > >-- >-Matt Calabrese >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

[iterator] huge differences in compile time between iterator_facade and iterator helpers
by Joaquín Mª López Muñoz 26 Oct '05

26 Oct '05

While in the process of replacing iterator helpers from <boost/operators.hpp> in favor of boost::iterator_facade as my internal iterator generation lib in Boost.MultiIndex, I've discovered an unpleasant increase in compilation times. The attached program shows the problem. Compilation times when using boost::iterator_facade are *way* higher than with good old boost::bidirectional_iterator_helper (to test it yourself, just comment/uncomment the line "#define USE_BOOST_ITERATOR" in the program): MSVC++ 6.0: iterator_facade: ~7 sec. bidirectional_iterator_helper: less than 1 sec. GCC 3.2 iterator_facade: 4.9 sec. bidirectional_iterator_helper: 2.5 sec. My questions: 1. Maybe the test program is flawed and has some (unseen by me) bias in favor of bidirectional_iterator_helper? 2. If not so, why is iterator_facade so very expensive? Is there any way to alleviate the problem? As it stands, I'm not so sure it's a good idea to adopt boost::iterator_facade: my local tests for Boost.MultiIndex show an overall increase in compilation time of around 25% :( Thanks for your help, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 8

Re: [boost] FW: [Xpressive] quantify embedded regex - still no joy
by BRIDGES Dick 26 Oct '05

26 Oct '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler > Sent: Tuesday, October 25, 2005 10:59 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] FW: [Xpressive] quantify embedded regex > - still no joy > > BRIDGES Dick wrote: > > I ran the softfloat ARM cross-comiler against the exemplar and it > > compiled. Problem seems to be the x86 gcc 3.4.2 compiler? > > It appears so. According to the regression tests, quantifying an > embedded regex compiles on gcc-3.4.4-linux (see misc1 test at > http://tinyurl.com/dyaub) I guess gcc-3.4.2 is broken wrt > xpressive. Sorry. > > -- > Eric Niebler > Boost Consulting > www.boost-consulting.com No problem. Updated to gcc-3.4.4 and it compiles just dandy. I never did like that old compiler anyway. ;) Thank you very much for your help. Regards, Dick Bridges

2 1

[1.33.1] spurious Borland failures in serialisation lib?
by John Maddock 26 Oct '05

26 Oct '05

The remaining Borland failures for the serialisation lib in 1.33.1 appear to be spurious, or at least the HTML is all mixed up, the links all lead to digital-mars failures! Any ideas what's happening? Thanks, John.

1 0

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

26 Oct '05

Boost regression test failures ------------------------------ Report time: 2005-10-26T05:00:18Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 430 failures in 14 libraries: concept_check (13) date_time (2) graph (2) mpl (1) parameter (2) python (1) serialization (40) spirit (8) thread (4) tr1 (12) tuple (1) type_traits (318) typeof (21) xpressive (5) |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 |date_time| testwcustom_time_zone: gcc-2.95.3-linux testwposix_time_zone: gcc-2.95.3-linux |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |parameter| efficiency: msvc sfinae: msvc |python| exec: intel-win32-9_0 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc test_tracking_binary_archive: vc-7_1 test_tracking_text_warchive: vc-7_1 test_tracking_xml_archive: vc-7_1 test_variant_text_warchive_dll: vc-7_1 |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| std_test_array_tricky: vc-7_1 std_test_bind_tricky: vc-7_1 std_test_function_tricky: vc-7_1 std_test_mem_fn_tricky: vc-7_1 std_test_reference_wrapper_tricky: vc-7_1 std_test_tuple_tricky: vc-7_1 test_array_tricky: vc-7_1 test_bind_tricky: vc-7_1 test_function_tricky: vc-7_1 test_mem_fn_tricky: vc-7_1 test_reference_wrapper_tricky: vc-7_1 test_tuple_tricky: vc-7_1 |tuple| tuple_test_bench: gcc-3_4_3-sunos |type_traits| tr1_add_const_test: 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 intel-win32-9_0 tr1_add_cv_test: 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 intel-win32-9_0 tr1_add_pointer_test: 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 intel-win32-9_0 tr1_add_reference_test: 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 intel-win32-9_0 tr1_add_volatile_test: 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 intel-win32-9_0 tr1_aligned_storage_test: 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 intel-win32-9_0 tr1_alignment_of_test: 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 intel-win32-9_0 tr1_extent_test: 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 intel-win32-9_0 tr1_has_nothrow_assign_test: 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 intel-win32-9_0 tr1_has_nothrow_constr_test: 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 intel-win32-9_0 tr1_has_nothrow_copy_test: 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 intel-win32-9_0 tr1_has_trivial_assign_test: 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 intel-win32-9_0 tr1_has_trivial_constr_test: 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 intel-win32-9_0 tr1_has_trivial_copy_test: 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 intel-win32-9_0 tr1_has_trivial_destructor_test: 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 intel-win32-9_0 tr1_has_virtual_destructor_test: 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 intel-win32-9_0 tr1_is_abstract_test: 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 intel-win32-9_0 tr1_is_arithmetic_test: 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 intel-win32-9_0 tr1_is_array_test: 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 intel-win32-9_0 tr1_is_base_of_test: 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 intel-win32-9_0 tr1_is_class_test: 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 intel-win32-9_0 tr1_is_compound_test: 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 intel-win32-9_0 tr1_is_const_test: 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 intel-win32-9_0 tr1_is_convertible_test: 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 intel-win32-9_0 tr1_is_empty_test: 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 intel-win32-9_0 tr1_is_enum_test: 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 intel-win32-9_0 tr1_is_floating_point_test: 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 intel-win32-9_0 tr1_is_function_test: 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 intel-win32-9_0 tr1_is_fundamental_test: 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 intel-win32-9_0 tr1_is_integral_test: 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 intel-win32-9_0 tr1_is_member_func_test: 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 intel-win32-9_0 tr1_is_member_obj_test: 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 intel-win32-9_0 tr1_is_member_pointer_test: 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 intel-win32-9_0 tr1_is_object_test: 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 intel-win32-9_0 tr1_is_pod_test: 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 intel-win32-9_0 tr1_is_pointer_test: 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 intel-win32-9_0 tr1_is_polymorphic_test: 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 intel-win32-9_0 tr1_is_reference_test: 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 intel-win32-9_0 tr1_is_same_test: 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 intel-win32-9_0 tr1_is_scalar_test: 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 intel-win32-9_0 tr1_is_signed_test: 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 intel-win32-9_0 tr1_is_union_test: 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 intel-win32-9_0 tr1_is_unsigned_test: 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 intel-win32-9_0 tr1_is_void_test: 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 intel-win32-9_0 tr1_is_volatile_test: 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 intel-win32-9_0 tr1_rank_test: 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 intel-win32-9_0 tr1_remove_all_extents_test: 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 intel-win32-9_0 tr1_remove_const_test: 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 intel-win32-9_0 tr1_remove_cv_test: 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 intel-win32-9_0 tr1_remove_extent_test: 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 intel-win32-9_0 tr1_remove_pointer_test: 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 intel-win32-9_0 tr1_remove_reference_test: 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 intel-win32-9_0 tr1_remove_volatile_test: 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 intel-win32-9_0 |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

Re: [boost] Is there any interest in a library that provides cont ainers with virtual destructors?
by Victor A. Wagner Jr. 26 Oct '05

26 Oct '05

At 02:51 2005-10-26, Martin Bonner wrote: >----Original Message---- >From: Victor A. Wagner Jr. [mailto:vawjr@rudbek.com] >Sent: 26 October 2005 05:36 >To: boost(a)lists.boost.org; boost(a)lists.boost.org >Subject: Re: [boost] Is there any interest in a library that provides >containers with virtual destructors? > > > At 10:04 2005-10-25, Andy Tompkins wrote: > >> I have read a few times that people sometimes wish that std::vector > >> (or other containers) had a virtual destructor. >[snip] > >> This allows one to write something like: > >> > >> struct person { > >> string first_name; > >> string last_name; > >> }; > >> class people : public virtual_vector<person> > >> { > >> public: > >> //extra methods > >> }; > >> > >> Is this useful? > > > > unless I mis-read (or mis-understood...far more likely) a lot of > > books on how C++ works, I don't believe there is any reason for what > > _you've_ shown to need a virtual destructor. > >You have mis-read or mis-understood (or you need better books). Consider: > virtual_vector<person>* p = new people; I guees I wasn't clear.. I was suggesting that virtual_vector has no need for existence. > delete p; >That invokes undefined behaviour unless virtual_vector<person> has a virtual >destructor. are you suggesting that if it were class people: public std::vector<person> {.....}; as above the same would be true? not "in practice", "in theory". >In *practise*, you will (probably) get away with it. The most *likely* >behaviour is that virtual_vector<>::~virtual_vector() will be called, >without calling people::~people(). ... but that doesn't alter the fact that >it *is* undefined behaviour, which is not good. > > > >-- >Martin Bonner >Martin.Bonner(a)Pitechnology.com >Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, >ENGLAND Tel: +44 (0)1223 441434 >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[Boost-bugs] [ boost-Bugs-1338326 ] token_iterator::at_end() result is inversed
by SourceForge.net 26 Oct '05

26 Oct '05

Bugs item #1338326, was opened at 2005-10-26 03:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1338326&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: token_iterator::at_end() result is inversed Initial Comment: token_iterator::at_end() returns true when our iterator is not at end and false othervise. It should return !valid_. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1338326&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0