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

[Boost.Msm] On the necessity of state-boundary-crossing transitions
by Andreas Huber 22 Oct '08

22 Oct '08

Unfortunately, the original thread on this subject has led to so many side arguments that IMO the main point hasn't gotten the attention it deserves. I'll therefore try to summarize the main point here, so that hopefully a more focused discussion results. State machine behavioral standards like e.g. Harel & UML allow that transitions can cross state boundaries. One example for when this is beneficial is given in Fig. 8 of Harel's paper, which can be found here: <http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf> In this example, the main reason for the existence of the "alarms-beep" composite state is to avoid duplicating the two transitions triggered by the "any button pressed" and "30 sec in alarms-beep" events. The design of Boost.Msm and the arguments presented in the thread titled "New library in Vault: Msm (Meta State Machine)" seem to amount to the following claim: It is *invariably* bad practice to let transitions cross state boundaries. It follows that a state machine like the one shown in Fig. 8 should *always* be redesigned so that the transitions no longer need to cross state boundaries [1]. For Fig. 8, I claim that any such redesign will lead to information duplication in the diagram and the code implementing it. Moreover, it's probably safe to say that the ultimate bad practice in software engineering is expressing the same piece of information more often in the code than minimally required by the language [2]. Therefore, if following a best practice leads to code duplication then common sense would mandate to choose the lesser of the two evils. So, boundary-crossing transitions cannot always be avoided. Therefore, the challenge is to show that my claim for Fig. 8 is wrong by coming up with an alternative state machine design with the same observable behavior where transitions no longer cross state boundaries without duplicating anything (transitions, events, states) [3]. Note that the leaf-state in which the machine currently resides is part of the observable behavior. So any redesign must have at least the states "alarm 1 beeps", "alarm 2 beeps", "both beep" and "displays". Anything else can be changed to suit. Note that Fig. 8 shows just one widely used pattern that employs boundary-crossing transitions. Other patterns employ them as well. So, even if Fig. 8 can be redesigned without boundary-crossing transitions and without duplicating any information then this is just one data point. Suitable redesigns for the other patterns would have to be shown as well. [1] UML's entry & exit points are "just" encapsulation tools that allow the designer of a composite state to only expose the parts of the inner workings that must be visible from the outside world. So, a transition destined to an entry point does in fact still cross the state boundary. The same goes for a transition originating at an exit point. [2] Of course, all rules come with exceptions: In some cases code duplication can increase performance, which in turn might help to meet system requirements that otherwise couldn't be met. Under such circumstances of course the lesser evil is the code duplication. [3] The obvious solution of moving the "displays" state into the "alarms-beep" state just replaces the crossings of the transitions triggered by the "T hits ..." events with the crossings of the transitions triggered by the "any button pressed" and the "30 sec in alarms-beep" events. Depending on how the latter transitions are drawn, the crossings might not be visible graphically but on the conceptual level they still exist. This is why such transitions are often drawn as the one triggered by y shown in Figure 2 here: <http://www.codeproject.com/KB/cpp/Statechart.aspx> -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

Are there any some utilities that helps to show where a exception is from?
by Peng Yu 22 Oct '08

22 Oct '08

Hi, If there is an error happens, I want to throw an exception, with the error string of the following format (similar to what assert would give). main.cc:12: int main(): some message I'm wondering if boost has such facility. I'm a new boost developer, I want to understand how existing boost libraries take care of runtime errors? Thanks, Peng

5 6

[RangeEx] Using istream_range?
by Robert Jones 22 Oct '08

22 Oct '08

Hi All I'd really appreciate an example of the use of istream_range from the Boost.Range library. I tried this #include <iostream> #include <iterator> #include "boost/range.hpp" #include "boost/range/istream_range.hpp" #include "boost/range/algorithm.hpp" void f( int i ) { std :: cout << i << std :: endl; } int main( ) { typedef std :: istream_iterator< int > in; boost :: for_each( boost :: istream_range< in >( std :: cin ), f ); return 0; } and other variations, but I don't think any of them are right! Do I really have to specify three template type parameters? The signature of the template is namespace boost { template<class Type, class Elem, class Traits> inline range<std::istream_iterator<Type, Elem, Traits> > istream_range(std::basic_istream<Elem, Traits>& in) { return range<std::istream_iterator<Type, Elem, Traits> >( std::istream_iterator<Elem>(in), std::istream_iterator<Elem>()); } } Thanks, Rob.

4 14

Re : Selective Unit Testing.
by dominic ibeme 22 Oct '08

22 Oct '08

Thanks Gennadiy for the immediate & direct response. i can't seem to find a way to specify dependencies for Auto Registered use cases.. cos they are registered during static initialization which would occur before u had a chance to specify dependencies. I'm thinking of the possiblility of tranversing the hierarcy from the master test suite, apparently, this seems non trivial, "i got lost in the plenitude of Macros being used" if there could be a way of manipulating the automated Registration test suites when invoking the initialization function Thanks.

1 0

Boost::statechart: state reaction returned result
by Rajpal Dangi 22 Oct '08

22 Oct '08

Could someone suggest me the recomended way of communicating error from fsm to the fsm user application? Assume state reaction unable to process event due to error and returns with discard_event(). As application calls process_event() to post an event which is of type "void". How do I make sure that my event was processed successfuly and not discarded? Thanks, Rajpal

2 1

Submit a library that compute the roots of a polynomial upto the 4th order
by Peng Yu 22 Oct '08

22 Oct '08

Hi, This is my first time that I wan to submit a library to boost. On http://www.boost.org/development/submissions.html, it mentioned boost vault, without explaining what it is. Can somebody let me know what it is? What is the difference between boost vault and boost sandbox? Do I need to submit my library to vault or sandbox? Where shall I put it? Thanks, Peng

4 4

Re: [boost] Selective Unit Testing
by dominic ibeme 22 Oct '08

22 Oct '08

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(a)lists.boost.org" <boost-request(a)lists.boost.org> To: boost(a)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(a)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(a)lists.boost.org You can reach the person managing the list at boost-owner(a)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(a)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(a)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(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDDB7E.8060600(a)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(a)yahoo.com> Subject: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <96943.77520.qm(a)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(a)hetp.u-net.com> Subject: Re: [boost] [mp_int] new release To: <boost(a)lists.boost.org> Message-ID: <004e01c93386$32d5dac0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn >Sent: 10 October 2008 16:37 >To: boost(a)lists.boost.org >Subject: Re: [boost] [mp_int] new release >-------------------------------------------------- >From: "Kevin Sopp" <baraclese(a)googlemail.com> >Sent: Friday, October 10, 2008 10:25 AM >To: <boost(a)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(a)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(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <004f01c93387$97fa88f0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)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(a)hetp.u-net.com ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 10:40:46 -0400 From: "Beman Dawes" <bdawes(a)acm.org> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: boost(a)lists.boost.org Message-ID: <a61d44020810210740l22606e39w236bea29b0c6222c(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow(a)hetp.u-net.com>wrote: > >-----Original Message----- > >From: boost-bounces(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdea18.06025a0a.7a9f.6c94(a)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(a)willeboordse.demon.nl> Subject: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdkpn1$ajl$1(a)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(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <005001c9338c$141aaba0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 15:41 >To: boost(a)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(a)hetp.u-net.com>wrote: > >> >-----Original Message----- >> >From: boost-bounces(a)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(a)hetp.u-net.com ------------------------------ Message: 9 Date: Tue, 21 Oct 2008 17:55:01 +0300 From: "Peter Dimov" <pdimov(a)pdimov.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)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(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDEE48.6020003(a)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(a)gmail.com> Subject: Re: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <loom.20081021T151743-746(a)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(a)yahoo.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: boost(a)lists.boost.org Message-ID: <gdkstr$opo$1(a)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(a)ens-lyon.org> Subject: Re: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdktvq$sjg$1(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4(a)mx.google.com> 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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfbe0.07045a0a.162b.ffffba69(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfc69.07045a0a.162b.ffffbb50(a)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 **************************************

2 1

Re: [boost] Selective Unit Testing
by dominic ibeme 22 Oct '08

22 Oct '08

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(a)lists.boost.org" <boost-request(a)lists.boost.org> To: boost(a)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(a)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(a)lists.boost.org You can reach the person managing the list at boost-owner(a)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(a)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(a)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(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDDB7E.8060600(a)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(a)yahoo.com> Subject: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <96943.77520.qm(a)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(a)hetp.u-net.com> Subject: Re: [boost] [mp_int] new release To: <boost(a)lists.boost.org> Message-ID: <004e01c93386$32d5dac0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn >Sent: 10 October 2008 16:37 >To: boost(a)lists.boost.org >Subject: Re: [boost] [mp_int] new release >-------------------------------------------------- >From: "Kevin Sopp" <baraclese(a)googlemail.com> >Sent: Friday, October 10, 2008 10:25 AM >To: <boost(a)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(a)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(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <004f01c93387$97fa88f0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)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(a)hetp.u-net.com ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 10:40:46 -0400 From: "Beman Dawes" <bdawes(a)acm.org> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: boost(a)lists.boost.org Message-ID: <a61d44020810210740l22606e39w236bea29b0c6222c(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow(a)hetp.u-net.com>wrote: > >-----Original Message----- > >From: boost-bounces(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdea18.06025a0a.7a9f.6c94(a)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(a)willeboordse.demon.nl> Subject: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdkpn1$ajl$1(a)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(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <005001c9338c$141aaba0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 15:41 >To: boost(a)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(a)hetp.u-net.com>wrote: > >> >-----Original Message----- >> >From: boost-bounces(a)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(a)hetp.u-net.com ------------------------------ Message: 9 Date: Tue, 21 Oct 2008 17:55:01 +0300 From: "Peter Dimov" <pdimov(a)pdimov.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)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(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDEE48.6020003(a)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(a)gmail.com> Subject: Re: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <loom.20081021T151743-746(a)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(a)yahoo.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: boost(a)lists.boost.org Message-ID: <gdkstr$opo$1(a)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(a)ens-lyon.org> Subject: Re: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdktvq$sjg$1(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4(a)mx.google.com> 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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfbe0.07045a0a.162b.ffffba69(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfc69.07045a0a.162b.ffffbb50(a)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 **************************************

1 0

Re: [boost] Selective Unit Testing
by dominic ibeme 22 Oct '08

22 Oct '08

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(a)lists.boost.org" <boost-request(a)lists.boost.org> To: boost(a)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(a)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(a)lists.boost.org You can reach the person managing the list at boost-owner(a)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(a)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(a)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(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDDB7E.8060600(a)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(a)yahoo.com> Subject: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <96943.77520.qm(a)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(a)hetp.u-net.com> Subject: Re: [boost] [mp_int] new release To: <boost(a)lists.boost.org> Message-ID: <004e01c93386$32d5dac0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Brandon Kohn >Sent: 10 October 2008 16:37 >To: boost(a)lists.boost.org >Subject: Re: [boost] [mp_int] new release >-------------------------------------------------- >From: "Kevin Sopp" <baraclese(a)googlemail.com> >Sent: Friday, October 10, 2008 10:25 AM >To: <boost(a)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(a)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(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <004f01c93387$97fa88f0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)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(a)hetp.u-net.com ------------------------------ Message: 5 Date: Tue, 21 Oct 2008 10:40:46 -0400 From: "Beman Dawes" <bdawes(a)acm.org> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: boost(a)lists.boost.org Message-ID: <a61d44020810210740l22606e39w236bea29b0c6222c(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2008 at 10:16 AM, Paul A Bristow <pbristow(a)hetp.u-net.com>wrote: > >-----Original Message----- > >From: boost-bounces(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdea18.06025a0a.7a9f.6c94(a)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(a)willeboordse.demon.nl> Subject: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdkpn1$ajl$1(a)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(a)hetp.u-net.com> Subject: Re: [boost] [1.37.0] beta 1 release candidate QA To: <boost(a)lists.boost.org> Message-ID: <005001c9338c$141aaba0$0600a8c0@hetp7> Content-Type: text/plain; charset="us-ascii" >-----Original Message----- >From: boost-bounces(a)lists.boost.org >[mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes >Sent: 21 October 2008 15:41 >To: boost(a)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(a)hetp.u-net.com>wrote: > >> >-----Original Message----- >> >From: boost-bounces(a)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(a)hetp.u-net.com ------------------------------ Message: 9 Date: Tue, 21 Oct 2008 17:55:01 +0300 From: "Peter Dimov" <pdimov(a)pdimov.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)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(a)tid.es Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Message-ID: <48FDEE48.6020003(a)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(a)gmail.com> Subject: Re: [boost] Selective Unit Testing To: boost(a)lists.boost.org Message-ID: <loom.20081021T151743-746(a)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(a)yahoo.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: boost(a)lists.boost.org Message-ID: <gdkstr$opo$1(a)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(a)ens-lyon.org> Subject: Re: [boost] [function] function.hpp lacks include guard To: boost(a)lists.boost.org Message-ID: <gdktvq$sjg$1(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfb98.14025a0a.2e02.ffff84e4(a)mx.google.com> 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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed atlibs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfbe0.07045a0a.162b.ffffba69(a)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(a)gmail.com> Subject: Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92 To: <boost(a)lists.boost.org> Message-ID: <48fdfc69.07045a0a.162b.ffffbb50(a)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 **************************************

1 0

[MPL] wrapper for if_ selecting integral_c
by Jordans, R. 22 Oct '08

22 Oct '08

Hi, I would like to suggest an addition to Boost MPL. In the project I am working on I often need to select integral values, either using MPL or home-brew template logic. Where MPL is preferred due to consistency. This requires me to do something like: int value = if_<condition, int_<value1>, int_<value2> >::type::value; Which (when adding namespaces to the above) is too much typing in my opinion and reduces readability of my code. Would it be useful to add a new variant of if_ to Boost MPL that would enable the following? (by combining the syntax of if_ and integral_c) type value = if_integral_c<condition, type, value1, value2>::value Best regards, Roel Jordans

4 7