Thanks Gennadiy . i can't seem to find a way to specify dependencies for test cases that are automatically registered. ----- Original Message ---- From: "boost-request@lists.boost.org" <boost-request@lists.boost.org> To: boost@lists.boost.org Sent: Tuesday, October 21, 2008 5:00:03 PM Subject: Boost Digest, Vol 2343, Issue 3 Send Boost mailing list submissions to boost@lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request@lists.boost.org You can reach the person managing the list at boost-owner@lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ Today's Topics: 1. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin@tid.es) 2. Selective Unit Testing (dominic ibeme) 3. Re: [mp_int] new release (Paul A Bristow) 4. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 5. Re: [1.37.0] beta 1 release candidate QA (Beman Dawes) 6. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 7. [function] function.hpp lacks include guard (Okko Willeboordse) 8. Re: [1.37.0] beta 1 release candidate QA (Paul A Bristow) 9. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Peter Dimov) 10. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (joaquin@tid.es) 11. Re: Selective Unit Testing (Gennadiy Rozental) 12. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Gennaro Prota) 13. Re: [function] function.hpp lacks include guard (Mathias Gaunard) 14. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 15. Re: [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) 16. Re: [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 (Hartmut Kaiser) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Oct 2008 15:39:10 +0200 From: joaquin@tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost@lists.boost.org" <boost@lists.boost.org> Message-ID: <48FDDB7E.8060600@tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?:
assert(start != end);
// remove entry in map which corresponds to this type do{ if(this == *start) x.erase(start++); else ++start; }while(start != end);
After looking at this code again I have the impression that it is broken anyways. You can't safely increment an iterator after deleting the object it points to: erase(start++).
I think your objection is wrong: erase(start++) is perfectly safe because the incrementing op is executed before erase is invoked. Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 2 Date: Tue, 21 Oct 2008 06:20:27 -0700 (PDT) From: dominic ibeme <detroydom@yahoo.com> Subject: [boost] Selective Unit Testing To: boost@lists.boost.org Message-ID: <96943.77520.qm@web53502.mail.re2.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Hi .. I've been using the boost unit testing framework and its quite a wonderful library... thanks to Gennadiy, however the section on advanced usage wasn't made available in release 1.36. i would really like to know how to perform selective testing i.e executing? test with dependencies, i guess this would show up in the future, but i kind of need help on this one. This request list has been?extremely helpful..? ------------------------------ Message: 3 Date: Tue, 21 Oct 2008 15:06:21 +0100 From: "Paul A Bristow" <pbristow@hetp.u-net.com> Subject: Re: [boost] [mp_int] new release To: <boost@lists.boost.org> Message-ID: <004e01c93386$32d5dac0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii"
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn Sent: 10 October 2008 16:37 To: boost@lists.boost.org Subject: Re: [boost] [mp_int] new release -------------------------------------------------- From: "Kevin Sopp" <baraclese@googlemail.com> Sent: Friday, October 10, 2008 10:25 AM To: <boost@lists.boost.org> Subject: Re: [boost] [mp_int] new release
I've tried to use your simple "general use" example in your documentation with MS Visual studio 9.0 Sadly it fails to compile with an Internal compiler error :-( 1>Compiling... 1>demo_unbounded_int.cpp 1>i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(44) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1411) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> i:\trunk\boost\mp_math\mp_int\detail\string_conversion_constants.hpp(47) : see reference to class template instantiation 'boost::mp_math::detail::max_power<MpInt,Base>' being compiled This is a bit of a showstopper ;-) Or am I doing something silly? Any suggestions about what to try changing? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com PS
I'll also need these for sure so it would be nice if they were added to the next release:
template <> class numeric_limits< boost::mp_math::mp_int<> > { private: typedef boost::mp_math::mp_int<> Type; public: static const bool is_specialized = true; static const int digits = 0; static const int digits10 = 0; static const bool is_signed = true; static const bool is_integer = true; static const bool is_exact = true; static const int radix = 2; static const int min_exponent = 0; static const int min_exponent10 = 0; static const int max_exponent = 0; static const int max_exponent10 = 0; static const bool has_infinity = false; static const bool has_quiet_NaN = false; static const bool has_signaling_NaN = false; static const float_denorm_style has_denorm = denorm_absent; static const bool has_denorm_loss = false; static const bool is_iec559 = false; static const bool is_bounded = false; static const bool is_modulo = false; static const bool traps = false; static const bool tinyness_before = false; static const float_round_style round_style = round_toward_zero; static Type min() { return static_cast<Type>(0); } static Type max() { return static_cast<Type>(0); }
static Type epsilon() { return static_cast<Type>(1); }
static Type round_error() { return static_cast<Type>(1); }
static Type infinity() { return static_cast<Type>(0); }
static Type quiet_NaN() { return static_cast<Type>(0); }
static Type denorm_min() { return static_cast<Type>(1); } }; } // namespace std
------------------------------ Message: 4 Date: Tue, 21 Oct 2008 15:16:20 +0100 From: "Paul A Bristow" <pbristow@hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost@lists.boost.org> Message-ID: <004f01c93387$97fa88f0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii"
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 21 October 2008 13:54 To: Boost Developers list Subject: [boost] [1.37.0] beta 1 release candidate QA
1.37.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing these out to SourceForge, we need volunteers to download and install, following the getting started guide.
See http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html
Is this right - it says 1_36_0 rather than 1_37_0? Thanks Paul PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report says "The files checked were from at revision ." rather than including the revision number. I suspect this is not intended? --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 10:40:46 -0400 From: "Beman Dawes" <bdawes@acm.org> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: boost@lists.boost.org Message-ID: <a61d44020810210740l22606e39w236bea29b0c6222c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow@hetp.u-net.com>wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 21 October 2008 13:54 To: Boost Developers list Subject: [boost] [1.37.0] beta 1 release candidate QA
1.37.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing these out to SourceForge, we need volunteers to download and install, following the getting started guide.
See http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html
Is this right - it says 1_36_0 rather than 1_37_0?
Not really, but we haven't updated beta.boost.org yet. I need to ping Rene; I'm not sure what has to be done.
Thanks
Paul
PS The http://boost.cowic.de/rc/inspect-snapshot.html Inspection report says
"The files checked were from at revision ."
rather than including the revision number. I suspect this is not intended?
The inspect program needs to be changed to get the revision number somewhere else if inspect isn't being run on an SVN working copy. I'll put my thinking hat on and see if I can come up with a reliable way to do that. Thanks, --Beman ------------------------------ Message: 6 Date: Tue, 21 Oct 2008 09:41:16 -0500 From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost@lists.boost.org> Message-ID: <48fdea18.06025a0a.7a9f.6c94@mx.google.com> Content-Type: text/plain; charset="iso-8859-1"
Hartmut Kaiser escribi?:
assert(start != end);
// remove entry in map which corresponds to this type do{ if(this == *start) x.erase(start++); else ++start; }while(start != end);
After looking at this code again I have the impression that it is broken anyways. You can't safely increment an iterator after deleting the object it points to: erase(start++).
I think your objection is wrong: erase(start++) is perfectly safe because the incrementing op is executed before erase is invoked.
Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context. The only thing which is guaranteed is, that the operation executed by erase() uses the initial value and afterwards start has been incremented (well, whatever happens if you increment an iterator after erasing the element it's pointing to). Regards Hartmut ------------------------------ Message: 7 Date: Tue, 21 Oct 2008 16:41:36 +0200 From: Okko Willeboordse <trash@willeboordse.demon.nl> Subject: [boost] [function] function.hpp lacks include guard To: boost@lists.boost.org Message-ID: <gdkpn1$ajl$1@ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp doesn't have an include guard like; #ifndef BOOST_FUNCTION_HPP #define BOOST_FUNCTION_HPP ... #endif // BOOST_FUNCTION_HPP Kind regards, Okko Willeboordse ------------------------------ Message: 8 Date: Tue, 21 Oct 2008 15:48:27 +0100 From: "Paul A Bristow" <pbristow@hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost@lists.boost.org> Message-ID: <005001c9338c$141aaba0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii"
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 21 October 2008 15:41 To: boost@lists.boost.org Subject: Re: [boost] [1.37.0] beta 1 release candidate QA
On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow@hetp.u-net.com>wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 21 October 2008 13:54 To: Boost Developers list Subject: [boost] [1.37.0] beta 1 release candidate QA
1.37.0 beta 1 release candidates are available at http://boost.cowic.de/rc/
Before pushing these out to SourceForge, we need volunteers to download and install, following the getting started guide.
See
http://beta.boost.org/doc/libs/1_36_0/more/getting_started/index.html
Is this right - it says 1_36_0 rather than 1_37_0?
Not really, but we haven't updated beta.boost.org yet. I need to ping Rene; I'm not sure what has to be done.
So should I try to follow those instructions anyway? Or wait a while? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com ------------------------------ Message: 9 Date: Tue, 21 Oct 2008 17:55:01 +0300 From: "Peter Dimov" <pdimov@pdimov.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost@lists.boost.org> Message-ID: <AADF4B12D73849629D295161BAC51971@pdimov2> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Hartmut Kaiser:
Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context.
It does, there is a sequence point before the call. ------------------------------ Message: 10 Date: Tue, 21 Oct 2008 16:59:20 +0200 From: joaquin@tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost@lists.boost.org" <boost@lists.boost.org> Message-ID: <48FDEE48.6020003@tid.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser escribi?:
Hartmut Kaiser escribi?:
assert(start != end);
// remove entry in map which corresponds to this type do{ if(this == *start) x.erase(start++); else ++start; }while(start != end);
After looking at this code again I have the impression that it is broken anyways. You can't safely increment an iterator after deleting the object it points to: erase(start++). I think your objection is wrong: erase(start++) is perfectly safe because the incrementing op is executed before erase is invoked.
Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context. The only thing which is guaranteed is, that the operation executed by erase() uses the initial value and afterwards start has been incremented (well, whatever happens if you increment an iterator after erasing the element it's pointing to).
I still disagree; start++ produces a side effect (std 1.9.7, emphasis mine): "Accessing an object designated by a volatile lvalue (3.10), *modifying an object* [...] are all side effects, which are changes in the state of the execution environment.[...] At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place." and as such, it must have taken place by the time the function erase is invoked (std 1.9.17): "When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body .[...]" Am i missing something? Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ------------------------------ Message: 11 Date: Tue, 21 Oct 2008 15:19:53 +0000 (UTC) From: Gennadiy Rozental <rogeeff@gmail.com> Subject: Re: [boost] Selective Unit Testing To: boost@lists.boost.org Message-ID: <loom.20081021T151743-746@post.gmane.org> Content-Type: text/plain; charset=utf-8 dominic ibeme <detroydom <at> yahoo.com> writes:
Hi ..
I've been using the boost unit testing framework and its quite a wonderful
library...
thanks to Gennadiy, however the section on advanced usage wasn't made available in release 1.36. i would really like to know how to perform selective testing i.e executing? test with dependencies, i guess this would show up in the future, but i kind of need help on this one.
To specify dependencies test_unit has method "depends_on". Also you can run test by name. It should be covered in docs. Gennadiy ------------------------------ Message: 12 Date: Tue, 21 Oct 2008 17:37:03 +0200 From: Gennaro Prota <gennaro.prota@yahoo.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: boost@lists.boost.org Message-ID: <gdkstr$opo$1@ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hartmut Kaiser wrote:
Anything I can do about this? What does this assertion mean?
My setup: Linux 64Bit, gcc 4.2.4, serialization is used for polymorphic objects loaded from different shared libraries, shared libraries are loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY).
Assertion (extended_type_info.cpp:92) occurs during program termination (after main returned), during dlclose().
If anything else isn't possible, would it be appropriate to change the related code (before the release!) from:
assert(start != end);
// remove entry in map which corresponds to this type do{ if(this == *start) x.erase(start++); else ++start; }while(start != end);
After looking at this code again I have the impression that it is broken anyways.
Yes, but IMHO not for the reason you mention. Certainly I wouldn't let the start++/++start "dance" pass a code review. PS: don't use tab characters in posts! :-) -- Genny ------------------------------ Message: 13 Date: Tue, 21 Oct 2008 17:54:35 +0200 From: Mathias Gaunard <mathias.gaunard@ens-lyon.org> Subject: Re: [boost] [function] function.hpp lacks include guard To: boost@lists.boost.org Message-ID: <gdktvq$sjg$1@ger.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Okko Willeboordse wrote:
My co-worker Bob Praster found, using PC-Lint 9.0, that function.hpp doesn't have an include guard
That's most likely because it doesn't need one, since it's only including other headers. ------------------------------ Message: 14 Date: Tue, 21 Oct 2008 10:55:57 -0500 From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost@lists.boost.org> Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4@mx.google.com> Content-Type: text/plain; charset="us-ascii"
Anything I can do about this? What does this assertion mean?
My setup: Linux 64Bit, gcc 4.2.4, serialization is used for
objects loaded from different shared libraries, shared libraries are loaded with dlopen(RTLD_GLOBAL|RTLD_LAZY).
Assertion (extended_type_info.cpp:92) occurs during program termination (after main returned), during dlclose().
If anything else isn't possible, would it be appropriate to change
Hartmut Kaiser wrote: polymorphic the
related code (before the release!) from:
assert(start != end);
// remove entry in map which corresponds to this type do{ if(this == *start) x.erase(start++); else ++start; }while(start != end);
After looking at this code again I have the impression that it is broken anyways.
Yes, but IMHO not for the reason you mention. Certainly I wouldn't let the start++/++start "dance" pass a code review.
Agreed.
PS: don't use tab characters in posts! :-)
It's a raw copy of the code, so there have to be tabs in the source files... Regards Hartmut ------------------------------ Message: 15 Date: Tue, 21 Oct 2008 10:57:10 -0500 From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost@lists.boost.org> Message-ID: <48fdfbe0.07045a0a.162b.ffffba69@mx.google.com> Content-Type: text/plain; charset="us-ascii"
Hartmut Kaiser:
Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context.
It does, there is a sequence point before the call.
Ok, there is always something new to learn out there. Thanks! Regards Hartmut PS: Anyway, that doesn't fix my assertion in the first place either :-P ------------------------------ Message: 16 Date: Tue, 21 Oct 2008 10:59:26 -0500 From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost@lists.boost.org> Message-ID: <48fdfc69.07045a0a.162b.ffffbb50@mx.google.com> Content-Type: text/plain; charset="us-ascii"
Actually, to be concise, you're invoking undefined behavior. The Standard doesn't guarantee any execution order of operations in this context. The only thing which is guaranteed is, that the operation executed by erase() uses the initial value and afterwards start has been incremented (well, whatever happens if you increment an iterator after erasing the element it's pointing to).
I still disagree; start++ produces a side effect (std 1.9.7, emphasis mine):
"Accessing an object designated by a volatile lvalue (3.10), *modifying an object* [...] are all side effects, which are changes in the state of the execution environment.[...] At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place."
and as such, it must have taken place by the time the function erase is invoked (std 1.9.17):
"When calling a function (whether or not the function is inline), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body .[...]"
Ok, I'm wrong. But I remember at least one problem in the past I have had exactly because of this. But that just might have been a non-conforming compiler playing games on me. Thanks for the explanations. Regards Hartmut ------------------------------ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost End of Boost Digest, Vol 2343, Issue 3 **************************************