- Boost - lists.preview.boost.org

[1.37] Showstopper? Documentation pdf build broken.
by John Maddock 23 Oct '08

23 Oct '08

Generation of pdf's from the docbook source appears to be terminally broken at present, for example: fop.render.pdf ..\..\..\bin.v2\libs\config\doc\msvc-8.0\debug\threading-multi\config.pdf (document [system-id file:/c:/data/boost/boost/trunk/libs/config/doc/../../../bin.v2/libs/config/doc/msvc-8.0/debug/threading-multi/config.fo] (validate [error] Element 'fo:inline' cannot be a child of 'fo:flow'. Only block-level elements are permitted in this context. [validation total: 1 error] Parse error: Invalid XSL FO source 'file:/c:/data/boost/boost/trunk/libs/config/doc/../../../bin.v2/libs/config/doc/msvc-8.0/debug/threading-multi/config.fo': 1 error found during validation The problem occurs with both FOP and XEP as the FO translator BTW. Anyone know where to look for the problem? John.

1 0

[1.37] Fixing doc typos in the beta.
by John Maddock 23 Oct '08

23 Oct '08

Someone's just emailed me regarding a doc typo in Boost.Regex. Is this the sort of QA issue that should be fixed between the beta and release? If so what criteria and procedure should we be applying? Cheers, John.

2 1

[pool] doubling algorithm
by Boris 23 Oct '08

23 Oct '08

Are there any plans to make the pool's doubling algorithm configurable? It would be great if it was possible for example to set an upper limit or to use constant chunk sizes (thus no algorithm at all). If there are no plans may I propose then some patches? I ask as I need to configure the pool as it eats too much memory sometimes. Boris

3 5

[test] Problems building Boost.Test
by Daniel Walker 23 Oct '08

23 Oct '08

Hello, I'm trying to build Boost.Test from SVN trunk. Linking the dynamic libraries fails with gcc 4.0 on OSX. Apparently, the option -h is passed to the linker. Not sure what that means. The complete bjam output follows. Daniel Walker $ echo $OSTYPE darwin9.0 $ gcc --version i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ bjam --version Boost.Build V2 (Milestone 12) Boost.Jam 03.1.16 $ svn update At revision 49428. $ bjam --toolset=gcc --with-test ...patience... ...found 659 targets... ...updating 2 targets... gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib ld: unknown option: -h collect2: ld returned 1 exit status "g++" -o "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib" -Wl,-h -Wl,libboost_prg_exec_monitor-gcc40-mt-1_37.dylib -shared -Wl,--start-group "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/execution_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/debug.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/cpp_main.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -Wl,--strip-all ...failed gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_prg_exec_monitor-gcc40-mt-1_37.dylib... gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib ld: unknown option: -h collect2: ld returned 1 exit status "g++" -o "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib" -Wl,-h -Wl,libboost_unit_test_framework-gcc40-mt-1_37.dylib -shared -Wl,--start-group "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/execution_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/debug.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/compiler_log_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/framework.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/plain_report_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/progress_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/results_collector.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/results_reporter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/test_tools.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_log.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_main.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_monitor.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_parameters.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/unit_test_suite.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/xml_log_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/xml_report_formatter.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/exception_safety.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/interaction_based.o" "bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/logged_expectations.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -Wl,--strip-all ...failed gcc.link.dll bin.v2/libs/test/build/gcc-4.0.1/release/threading-multi/libboost_unit_test_framework-gcc40-mt-1_37.dylib... ...failed updating 2 targets... $

3 5

[1.37.0][serialization] unreferenced formal parameter warning
by Jeff Flinn 22 Oct '08

22 Oct '08

Robert, Can this be fixed: \boost_1_37_0\boost/serialization/extended_type_info_typeid.hpp(115) : warning C4100: 'p' : unreferenced formal parameter I'm also having trouble reading portable_binary file generated from boost_1_35_0. I'll try to reproduce with a smaller test case, but if you have any ideas on what to look for I'd appreciated it. Thanks, Jeff

3 4

[1.37.0] The release branch is closed; please do not commit
by Beman Dawes 22 Oct '08

22 Oct '08

The release branch is closed; please do not commit. Creating the beta is in process and it really screws things up if branches/release changes. --Beman

1 0

[1.37.0][serialization] possible loss of data warnings
by Jeff Flinn 22 Oct '08

22 Oct '08

Robert, The following warnings are the result of assigning int values to smaller data types in basic_binary_oarchive::save_overload. Any thoughts on clearing these up. Should these use numeric_cast? boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(72) : warning C4244: 'initializing' : conversion from 'const unsigned int' to 'const unsigned char', possible loss of data boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(77) : warning C4244: 'initializing' : conversion from 'const int' to 'const boost::int_least16_t', possible loss of data \boost_1_37_0\boost/archive/basic_binary_oarchive.hpp(82) : warning C4244: 'initializing' : conversion from 'const int' to 'const boost::int_least16_t', possible loss of data Thanks, Jeff

1 0

Re: [boost] New library in Vault: Msm (Meta State Machine)
by Christophe Henry 22 Oct '08

22 Oct '08

Hi Andreas, > Whether you'd want to work with entry & exit points in the alarm-beeps > case is a matter of taste. I personally wouldn't bother simply because it > seems unlikely that it can be reused anywhere. Do you mean your example is irrelevant or that reuse is not important? > To reach a definite verdict in this particular example we'd need to define > first what coupling in a state machine actually means. To my knowledge, > nobody has done that so far. Do you need more than common sense to know that if you need to see inside of a state machine you have coupling? > Given my first 3 paragraphs above, I hope it has become clear that a > state-boundary-crossing transition combined with an entry/exit-point is > *not* an encapsulation breach. Please forgive me for not agreeing. > Just to make sure we're not talking past each other: With "entry/exit > states" I guess you mean "entry point pseudostate" and "exit point > pseudostate" as defined in UML? Yes, are there other possibilities? > You have read the whole paragraph, right? I quote it here for clarity: > > <quote> > A submachine state is semantically equivalent to a composite state. The > regions of the submachine state machine are the regions of the composite > state. The entry, exit, and behavior actions and internal transitions are > defined as part of the state. Submachine state is a decomposition > mechanism that allows factoring of common behaviors and their reuse. > </quote> > > Note the first sentence. What is unclear here? Well, first why there are 2 terms. They are not equal but equivalent. So what is the difference? And what does it have to do with the subject? The important part is about reuse. Again this is a key point for Msm. > I don't follow. Isn't it a fact that the current version of Msm only > supports a single entry point for a composite state/submachine, namely the > initial state? There is the entry function of the sub state machine and the one of the initial state. > Exactly. However, IIUC, at the moment Msm only supports a single entry > point and a single exit point, which IMO also makes reuse harder than > necessary, see below. Again I have to disagree. When a program runs, it calls functions, which call other functions, etc. Now if you read a book of Model Driven Development, you'll probably find inside that a UML diagram and code are two views of the same model. And now we have it. You don't mind having a single entry point in a function, right? Why is it a problem in a diagram? And there we are again, multiple entry points in a function are labels and goto. > Firstly, let's be clear that any reasonable semantics definition for FSMs > (e.g. Harel, UML) absolutely requires that an entry action of a composite > state/submachine is called when the composite state/submachine is entered > and it doesn't matter at all how the state is entered (ordinary > transition, state-boundary-crossing transition). The same goes for the > exit action when the state is left. Unfortunately I understood it the other way and had to go to great lengths in the example you gave me to avoid the entry of the composite. Maybe I'm not the only unreasonable and this brings confusion? > To cut a long story short: I would encourage you to do either of the > following: > > 1) Allow state-boundary-crossing transitions (without entry/exit points). > Once you have these, entry- and exit-points are a no-brainer: An entry > point is simply a member typedef in the type that defines the submachine. > An exit-point can be supported just as easily by passing the destination > state(s) as template parameters to the submachine. > 2) Introduce entry & exit points as first-class concepts. Implementing a > state-boundary-crossing transition would then become a three step process: > a) define an entry/exit point, b) connect the point with an internal > state, c) connect the point with an external state. > > In my (admittedly biased) view and from a purely conceptual standpoint > (ignoring e.g. performance and other real-world stuff for the moment), > option 1 is clearly superior as it gives the user complete freedom how to > tackle his design problems. Option 2 would be acceptable, when it is clear > that supporting 1) requires too many trade-offs. My goal is not to reimplement Statechart but offer an alternative. It is a key point for Msm to provide an easy-to-use interface and increase reusability. And a list of destination states in the submachine definition does neither. But we already discussed this. I wrote in the documentation of Msm and repeated you that I could implement entry and exit pseudostates if users asked for it. And this only if I'm satisfied of the solution I would offer. Regards, Christophe

2 1

[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

daylight save for time zone on trac
by Peng Yu 21 Oct '08

21 Oct '08

Hi, https://svn.boost.org/trac/boost/prefs/datetime There is no such option for daylight saving. Can somebody add that option? Thanks, Peng

1 0

[serialization] basic_xml_grammar.hpp broken
by Eric Niebler 21 Oct '08

21 Oct '08

Changeset 49349 broke the xml archive, and wave with it. http://svn.boost.org/trac/boost/changeset/49349/trunk/boost/archive/impl/ba… // spirit stuff #if (defined __BORLANDC__) && (__BORLANDC__ < 0x593) \ || (defined _MSC_VER) && #if (_MSC_VER <= 1300) Whoops-------------------^^^ -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[ublas] slice iterators are indexed iterators
by Neal Becker 21 Oct '08

21 Oct '08

It seems that basic_slice iterators are indexed, they store an integral index and dereference looks like: return (*this) ().start () + it_* (*this) ().stride (); This seems to kill performance. Is there any good reason why slice iterators could not be based on pointers? If it were, the most common use, which would iterate using 'it++' should be faster.

2 1

The status of Proto
by Peng Yu 21 Oct '08

21 Oct '08

Hi, It is exciting to know Proto helps the development of expression template based library. Since learning it and use it efficiently could take quite a lot of time, I want to know whether it is almost stable right now. Or it will subject to some further changes in the future. Does it have any limit on what kinds of expression template based designs it can be used? If Proto is good enough, can it be used to reimplement many expression template based pacakges, boost.ublas, blitz++, etc.? Thanks, Peng

3 2

[date_time] Time zone improvements
by Rutger ter Borg 21 Oct '08

21 Oct '08

Dear Boost.Date_Time developers, Being a heavy user of Boost's Date_Time library, I think it is very useful. However, I think one area could use improvement: its time zone handling. I would like to bring the full Olson tz database [1] to Boost.Date_Time. This offers a very high-quality, and, on package-managed-UNIX-systems, a maintainance-free solution to a time zone database. I have written a modern C++ implementation for reading zic-compiled binary zoneinfo-files. At the moment, Boost.Date_Time is not able to represent time zones that have DST offsets and/or zone abbreviations depending on (or, changing over) time. I.e., if a country or locality changes its time zone definitions. E.g., a system that is in "Europe/Amsterdam" has changing DST offset and time zone abbreviation, which depend on time $ date -d "2008-10-10 20:00:00Z" Fri Oct 10 22:00:00 CEST 2008 $ date -d "1930-10-10 20:00:00Z" Fri Oct 10 20:19:32 AMT 1930 I would like to propose changes that enables Boost.Date_Time to represent time zone definitions that change over time. The semantics will remain similar to the current version, boost::shared_ptr< time_zone > my_zone( "Europe/Amsterdam" ); local_date_time some_time( pt, my_zone ); some_time.utc_time(); // 2008-Oct-10 20:00:00 some_time.local_time(); // 2008-Oct-10 22:00:00 some_time.is_dst(); // true some_time.zone_abbrev(); // "CEST" some_time.dst_offset(); // 02:00:00 in addition, the abstract Time Zone interface and supported accessors will have to undergo a change. Although the desired result may be achieved in multiple ways, I think the time zone base could support accessors like from_utc( ptime const& p) and from_local(...) methods, perhaps returning a (pointer to a) ttinfo tuple, // UTC offset, is_dst, abbreviation typedef boost::tuple< time_duration_type, bool_type, string_type > ttinfo; and/or a special type in case the conversion is ambigious. When using the Olsen data base, this structure could be looked up through from_utc using std::lower_bound on a std::map or a ptr_map of transition points. I see a local_time_iterator is absent from the library, which I would like to add as well. By way of this email I would like to ask whether there is interest the proposed improvement. If so, please let me know, so we can work on the details. Kind regards, Rutger ter Borg [1] Sources for Time Zone and Daylight Saving Time Data, http://www.twinsun.com/tz/tz-link.htm

3 2

Re: [boost] [1.37.0][serialization] Assertion failed at libs/serialization/src/extended_type_info.cpp:92
by Hartmut Kaiser 21 Oct '08

21 Oct '08

> 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. You can't safely increment an iterator after deleting the object it points to: erase(start++). This code relies on the fact that in order to be incremented the iterator doesn't need the object it points to (which at least for lists is a wrong assumption). Regards Hartmut > > To: > > assert(start != end); > > // remove entry in map which corresponds to this type > while(start != end) { > if(this == *start) > x.erase(start++); > else > ++start; > } > > Which wouldn't remove the problem, but at least avoids hanging the > program if assertions are off... > > Regards Hartmut

4 8

Selective Unit Testing
by dominic ibeme 21 Oct '08

21 Oct '08

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..

2 1