|
|
Boost : |
Subject: Re: [boost] Selective Unit Testing
From: dominic ibeme (detroydom_at_[hidden])
Date: 2008-10-22 03:38:24
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_at_[hidden]" <boost-request_at_[hidden]>
To: boost_at_[hidden]
Sent: Tuesday, October 21, 2008 5:00:03 PM
Subject: Boost Digest, Vol 2343, Issue 3
Send Boost mailing list submissions to
boost_at_[hidden]
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_at_[hidden]
You can reach the person managing the list at
boost-owner_at_[hidden]
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_at_[hidden])
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_at_[hidden])
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_at_[hidden]
Subject: Re: [boost] [1.37.0][serialization] Assertion failed at
libs/serialization/src/extended_type_info.cpp:92
To: "boost_at_[hidden]" <boost_at_[hidden]>
Message-ID: <48FDDB7E.8060600_at_[hidden]>
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_at_[hidden]>
Subject: [boost] Selective Unit Testing
To: boost_at_[hidden]
Message-ID: <96943.77520.qm_at_[hidden]>
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_at_[hidden]>
Subject: Re: [boost] [mp_int] new release
To: <boost_at_[hidden]>
Message-ID: <004e01c93386$32d5dac0$0600a8c0_at_hetp7>
Content-Type: text/plain; charset="us-ascii"
>-----Original Message-----
>From: boost-bounces_at_[hidden]
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Brandon Kohn
>Sent: 10 October 2008 16:37
>To: boost_at_[hidden]
>Subject: Re: [boost] [mp_int] new release
>--------------------------------------------------
>From: "Kevin Sopp" <baraclese_at_[hidden]>
>Sent: Friday, October 10, 2008 10:25 AM
>To: <boost_at_[hidden]>
>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_at_[hidden]
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_at_[hidden]>
Subject: Re: [boost] [1.37.0] beta 1 release candidate QA
To: <boost_at_[hidden]>
Message-ID: <004f01c93387$97fa88f0$0600a8c0_at_hetp7>
Content-Type: text/plain; charset="us-ascii"
>-----Original Message-----
>From: boost-bounces_at_[hidden]
>[mailto:boost-bounces_at_[hidden]] 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_at_[hidden]
------------------------------
Message: 5
Date: Tue, 21 Oct 2008 10:40:46 -0400
From: "Beman Dawes" <bdawes_at_[hidden]>
Subject: Re: [boost] [1.37.0] beta 1 release candidate QA
To: boost_at_[hidden]
Message-ID:
<a61d44020810210740l22606e39w236bea29b0c6222c_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow_at_[hidden]>wrote:
> >-----Original Message-----
> >From: boost-bounces_at_[hidden]
> >[mailto:boost-bounces_at_[hidden]] 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_at_[hidden]>
Subject: Re: [boost] [1.37.0][serialization] Assertion failed at
libs/serialization/src/extended_type_info.cpp:92
To: <boost_at_[hidden]>
Message-ID: <48fdea18.06025a0a.7a9f.6c94_at_[hidden]>
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_at_[hidden]>
Subject: [boost] [function] function.hpp lacks include guard
To: boost_at_[hidden]
Message-ID: <gdkpn1$ajl$1_at_[hidden]>
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_at_[hidden]>
Subject: Re: [boost] [1.37.0] beta 1 release candidate QA
To: <boost_at_[hidden]>
Message-ID: <005001c9338c$141aaba0$0600a8c0_at_hetp7>
Content-Type: text/plain; charset="us-ascii"
>-----Original Message-----
>From: boost-bounces_at_[hidden]
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Beman Dawes
>Sent: 21 October 2008 15:41
>To: boost_at_[hidden]
>Subject: Re: [boost] [1.37.0] beta 1 release candidate QA
>
>On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow
><pbristow_at_[hidden]>wrote:
>
>> >-----Original Message-----
>> >From: boost-bounces_at_[hidden]
>> >[mailto:boost-bounces_at_[hidden]] 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_at_[hidden]
------------------------------
Message: 9
Date: Tue, 21 Oct 2008 17:55:01 +0300
From: "Peter Dimov" <pdimov_at_[hidden]>
Subject: Re: [boost] [1.37.0][serialization] Assertion failed
atlibs/serialization/src/extended_type_info.cpp:92
To: <boost_at_[hidden]>
Message-ID: <AADF4B12D73849629D295161BAC51971_at_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_at_[hidden]
Subject: Re: [boost] [1.37.0][serialization] Assertion failed at
libs/serialization/src/extended_type_info.cpp:92
To: "boost_at_[hidden]" <boost_at_[hidden]>
Message-ID: <48FDEE48.6020003_at_[hidden]>
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_at_[hidden]>
Subject: Re: [boost] Selective Unit Testing
To: boost_at_[hidden]
Message-ID: <loom.20081021T151743-746_at_[hidden]>
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_at_[hidden]>
Subject: Re: [boost] [1.37.0][serialization] Assertion failed at
libs/serialization/src/extended_type_info.cpp:92
To: boost_at_[hidden]
Message-ID: <gdkstr$opo$1_at_[hidden]>
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_at_[hidden]>
Subject: Re: [boost] [function] function.hpp lacks include guard
To: boost_at_[hidden]
Message-ID: <gdktvq$sjg$1_at_[hidden]>
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_at_[hidden]>
Subject: Re: [boost] [1.37.0][serialization] Assertion failed at
libs/serialization/src/extended_type_info.cpp:92
To: <boost_at_[hidden]>
Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
> 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.
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_at_[hidden]>
Subject: Re: [boost] [1.37.0][serialization] Assertion failed
atlibs/serialization/src/extended_type_info.cpp:92
To: <boost_at_[hidden]>
Message-ID: <48fdfbe0.07045a0a.162b.ffffba69_at_[hidden]>
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_at_[hidden]>
Subject: Re: [boost] [1.37.0][serialization] Assertion failed at
libs/serialization/src/extended_type_info.cpp:92
To: <boost_at_[hidden]>
Message-ID: <48fdfc69.07045a0a.162b.ffffbb50_at_[hidden]>
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
**************************************
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk