[important] Preparing to Test Release Builds
In order to make it viable to do boost-wide regression testing in release mode, I've gone through all the instances of assert() in our libs subdirectories and replaced any that seemed to be used for testing with constructs that don't get compiled away in release builds. This affects the following libraries: boost/cast.hpp mpl conversion function functional graph iterator mpl parameter program_options ptr_container python spirit If you maintain one of these libraries please review the attached patch, which I plan to apply on Wednesday unless there are objections. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Daniel James <daniel@calamity.org.uk> writes:
David Abrahams wrote:
functional
The functional changes are all in my tests, and look good to me.
Why is hashing located under functional? The functional library is deprecated, IIRC. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Why is hashing located under functional? The functional library is deprecated, IIRC.
Because it's based on the TR1 hash functions, which are in <functional>. So enhancements to <functional> are grouped together. I thought it was just Boost.Compose that was deprecated and removed. Daniel
Daniel James <daniel@calamity.org.uk> writes:
David Abrahams wrote:
Why is hashing located under functional? The functional library is deprecated, IIRC.
Because it's based on the TR1 hash functions, which are in <functional>.
Hm. I'm not sure if that's a good enough reason. Or maybe we should get the other stuff that's in there out of that directory.
So enhancements to <functional> are grouped together. I thought it was just Boost.Compose that was deprecated and removed.
Huh. Does anybody use http://www.boost.org/libs/functional/index.html? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 2/19/06, David Abrahams <dave@boost-consulting.com> wrote:
Daniel James <daniel@calamity.org.uk> writes:
David Abrahams wrote:
Why is hashing located under functional? The functional library is deprecated, IIRC.
Because it's based on the TR1 hash functions, which are in <functional>.
Hm. I'm not sure if that's a good enough reason. Or maybe we should get the other stuff that's in there out of that directory.
Well, I don't really mind where it goes, I'll happily follow the consensus. Daniel
"Daniel James" <daniel@calamity.org.uk> writes:
On 2/19/06, David Abrahams <dave@boost-consulting.com> wrote:
Daniel James <daniel@calamity.org.uk> writes:
David Abrahams wrote:
Why is hashing located under functional? The functional library is deprecated, IIRC.
Because it's based on the TR1 hash functions, which are in <functional>.
Hm. I'm not sure if that's a good enough reason. Or maybe we should get the other stuff that's in there out of that directory.
Well, I don't really mind where it goes, I'll happily follow the consensus.
I guess as long as functional.hpp isn't deprecated, it's fine where it is. But I like the idea that things built specifically for tr1 compatibility should go in boost/tr1/... -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Daniel James" <daniel@calamity.org.uk> writes:
On 2/19/06, David Abrahams <dave@boost-consulting.com> wrote:
Daniel James <daniel@calamity.org.uk> writes:
David Abrahams wrote:
Why is hashing located under functional? The functional library is deprecated, IIRC.
Because it's based on the TR1 hash functions, which are in <functional>.
Hm. I'm not sure if that's a good enough reason. Or maybe we should get the other stuff that's in there out of that directory.
Well, I don't really mind where it goes, I'll happily follow the consensus.
I guess as long as functional.hpp isn't deprecated, it's fine where it is. But I like the idea that things built specifically for tr1 compatibility should go in boost/tr1/...
boost/hash/ will do fine. <waves hand>
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Daniel James" <daniel@calamity.org.uk> writes:
On 2/19/06, David Abrahams <dave@boost-consulting.com> wrote:
Daniel James <daniel@calamity.org.uk> writes:
David Abrahams wrote:
Why is hashing located under functional? The functional library is deprecated, IIRC.
Because it's based on the TR1 hash functions, which are in <functional>.
Hm. I'm not sure if that's a good enough reason. Or maybe we should get the other stuff that's in there out of that directory.
Well, I don't really mind where it goes, I'll happily follow the consensus.
I guess as long as functional.hpp isn't deprecated, it's fine where it is. But I like the idea that things built specifically for tr1 compatibility should go in boost/tr1/...
boost/hash/ will do fine. <waves hand>
Yeah, that would've been best. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams writes:
In order to make it viable to do boost-wide regression testing in release mode, I've gone through all the instances of assert() in our libs subdirectories and replaced any that seemed to be used for testing with constructs that don't get compiled away in release builds. This affects the following libraries:
boost/cast.hpp mpl
[...]
If you maintain one of these libraries please review the attached patch, which I plan to apply on Wednesday unless there are objections.
None here, and thank you! -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
David Abrahams writes:
In order to make it viable to do boost-wide regression testing in release mode, I've gone through all the instances of assert() in our libs subdirectories and replaced any that seemed to be used for testing with constructs that don't get compiled away in release builds. This affects the following libraries:
boost/cast.hpp mpl
[...]
If you maintain one of these libraries please review the attached patch, which I plan to apply on Wednesday unless there are objections.
None here, and thank you!
Done. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
Aleksey Gurtovoy -
Daniel James -
David Abrahams -
Peter Dimov -
Thorsten Ottosen