[concept_check] failures in release cfg
see http://tinyurl.com/3t3tc It seems that the concept_checks are inactive in release cfg, at least the lines template <class Concept> inline void function_requires(mpl::identity<Concept>* = 0) { #if !defined(NDEBUG) void (Concept::*x)() = BOOST_FPTR Concept::constraints; ignore_unused_variable_warning(x); #endif } make me think so. If there is no better way to instantiate Concept::constraints (without creating a local variable, which seems to be the reason to avoid the check in release mode), the cf-tests must be disabled for all release configurations. Stefan
Stefan Slapeta wrote:
[...]
The same seems to be valid for iterator/lvalue_concept_fail (http://tinyurl.com/4koaz)! Stefan
Stefan Slapeta <stefan@slapeta.com> writes:
Stefan Slapeta wrote:
[...]
The same seems to be valid for iterator/lvalue_concept_fail (http://tinyurl.com/4koaz)!
Very few of the Boost regression tests are meant to be run in "release mode" (i.e. with NDEBUG defined). Many in fact use <cassert>. I don't think it's reasonable to expect any particular result from Boost tests run in this way, nor is it reasonable to expect library authors to adjust their tests at this late date. I'm sure the number of affected tests goes way beyond the two you've found. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Very few of the Boost regression tests are meant to be run in "release mode" (i.e. with NDEBUG defined).
Are there any statistics for that? I don't share this feeling as most of the regression tests make use of boost.test.
Many in fact use <cassert>.
I would say those are incorrect.
I don't think it's reasonable to expect any particular result from Boost tests run in this way, nor is it reasonable to expect library authors to adjust their tests at this late date. I'm sure the number of affected tests goes way beyond the two you've found.
IMO it's somewhat important to detect potential differences between debug and release, which as everybody knows happen to occur sometimes! And (please tell me if I'm incorrect), when releasing a product, the regression tests are mostly run on a final build, which normally is a release build! Cheers, Stefan
David Abrahams writes:
Stefan Slapeta <stefan@slapeta.com> writes:
Stefan Slapeta wrote:
[...]
The same seems to be valid for iterator/lvalue_concept_fail (http://tinyurl.com/4koaz)!
Very few of the Boost regression tests are meant to be run in "release mode" (i.e. with NDEBUG defined). Many in fact use <cassert>. I don't think it's reasonable to expect any particular result from Boost tests run in this way, nor is it reasonable to expect library authors to adjust their tests at this late date.
I'm having the same sentiments. Let's concentrate on what _has_ to work. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
David Abrahams writes:
Stefan Slapeta <stefan@slapeta.com> writes:
Stefan Slapeta wrote:
[...]
The same seems to be valid for iterator/lvalue_concept_fail (http://tinyurl.com/4koaz)!
Very few of the Boost regression tests are meant to be run in "release mode" (i.e. with NDEBUG defined). Many in fact use <cassert>. I don't think it's reasonable to expect any particular result from Boost tests run in this way, nor is it reasonable to expect library authors to adjust their tests at this late date.
I'm having the same sentiments. Let's concentrate on what _has_ to work.
I personally disagree. I think it's rather presumptious of us to think that compiling debug versions is what "has to work". Most people using Boost will be compiling their programs in release mode at some point. How can we give users software that has not undergone at least some minor testing in the most common configuration? At least for me, if it doesn't work in release mode, it's unusable. I personally will continue to run the cw-8.3 release tests as that's one of the important platforms for me. And I will continue to find, and hopefully fix, error that come up from the difference the code optimizer impacts on the functioning of the code. And yes I have found and fixed some number of bugs because of this effort. --grafik
Rene, Rene Rivera wrote:
Aleksey Gurtovoy wrote:
David Abrahams writes:
Very few of the Boost regression tests are meant to be run in "release mode" (i.e. with NDEBUG defined). Many in fact use <cassert>. I don't think it's reasonable to expect any particular result from Boost tests run in this way, nor is it reasonable to expect library authors to adjust their tests at this late date.
I'm having the same sentiments. Let's concentrate on what _has_ to work.
I personally disagree. I think it's rather presumptious of us to think that compiling debug versions is what "has to work". Most people using Boost will be compiling their programs in release mode at some point. How can we give users software that has not undergone at least some minor testing in the most common configuration? At least for me, if it doesn't work in release mode, it's unusable.
I think we have to distinguish between the 1.32 feature set and the desired feature set for future boost versions. As far as 1.32 goes I think it is obvious that release mode testing is not a current boost feature and therefore it should not be required for 1.32. At least if we want to ship anytime soon. In terms of the general boost development I do agree that release mode testing makes sense and that we should try to make it work for the next release.
I personally will continue to run the cw-8.3 release tests as that's one of the important platforms for me. And I will continue to find, and hopefully fix, error that come up from the difference the code optimizer impacts on the functioning of the code. And yes I have found and fixed some number of bugs because of this effort.
IIUC nobody said that release mode testing should be stopped. It is a good thing, but not all testcode allows it yet. Thomas -- Thomas Witt witt@acm.org
Rene Rivera <grafik.list@redshift-software.com> writes:
Aleksey Gurtovoy wrote:
David Abrahams writes:
Stefan Slapeta <stefan@slapeta.com> writes:
Stefan Slapeta wrote:
[...]
The same seems to be valid for iterator/lvalue_concept_fail (http://tinyurl.com/4koaz)!
Very few of the Boost regression tests are meant to be run in "release mode" (i.e. with NDEBUG defined). Many in fact use <cassert>. I don't think it's reasonable to expect any particular result from Boost tests run in this way, nor is it reasonable to expect library authors to adjust their tests at this late date. I'm having the same sentiments. Let's concentrate on what _has_ to work.
I personally disagree. I think it's rather presumptious of us to think that compiling debug versions is what "has to work". Most people using Boost will be compiling their programs in release mode at some point. How can we give users software that has not undergone at least some minor testing in the most common configuration? At least for me, if it doesn't work in release mode, it's unusable.
I personally will continue to run the cw-8.3 release tests as that's one of the important platforms for me. And I will continue to find, and hopefully fix, error that come up from the difference the code optimizer impacts on the functioning of the code. And yes I have found and fixed some number of bugs because of this effort.
That's great, but I just don't think it's reasonable to try to make changes in the codebase to support it before this release. It requires a thorough review of all tests. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (6)
-
Aleksey Gurtovoy -
David Abrahams -
Rene Rivera -
Stefan Slapeta -
Stefan Slapeta -
Thomas Witt