[random] Update for better TR1 compliance
I've checked in changes to the Boost.Random library that add constructors and seeding for both template<class Generator> and unsigned long arguments, thereby moving Boost.Random one step further towards TR1 compliance. The random_test.cpp program now has basic tests for this feature. In order to guide overload resolution, I've used boost::enable_if<> and type traits to make sure that integral arguments don't try to call the "template<class Generator>" overloads. This could mean decreased compiler support, sorry. It works for me with gcc 3.4.3. Jens Maurer
Jens Maurer wrote:
In order to guide overload resolution, I've used boost::enable_if<> and type traits to make sure that integral arguments don't try to call the "template<class Generator>" overloads. This could mean decreased compiler support, sorry.
Hi Jens, By coincidence, yesterday I modified the iostreams regression tests to use Boost.Random instead of std::rand, which was behaving poorly on Linux and Darwin. The above change means that iostreams is now broken on at least one compiler, CodeWarrior 8.3, which doesn't support SFINAE. Would you mind if the new constructors and seed functions were included only for compilers supporting enable_if? Alternatively, would you mind if I implemented these functions without enable_if? From a quick look, it appears that all of the seed functions and most if not all of the constructors can be made to work on older compilers without much work. Jonathan
Jonathan Turkanis wrote:
Jens Maurer wrote:
In order to guide overload resolution, I've used boost::enable_if<> and type traits to make sure that integral arguments don't try to call the "template<class Generator>" overloads. This could mean decreased compiler support, sorry.
:-(
Hi Jens,
Would you mind if the new constructors and seed functions were included only for compilers supporting enable_if? Alternatively, would you mind if I implemented these functions without enable_if? From a quick look, it appears that all of the seed functions and most if not all of the constructors can be made to work on older compilers without much work.
*I* certainly would welcome that. Given that I worked hard to get many of the tests working on CodeWarrior 8.3, only to have them broken again. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
By coincidence, yesterday I modified the iostreams regression tests to use Boost.Random instead of std::rand, which was behaving poorly on Linux and Darwin. The above change means that iostreams is now broken on at least one compiler, CodeWarrior 8.3, which doesn't support SFINAE.
Would you mind if the new constructors and seed functions were included only for compilers supporting enable_if? Alternatively, would you mind if I implemented these functions without enable_if? From a quick look, it appears that all of the seed functions and most if not all of the constructors can be made to work on older compilers without much work.
They can indeed: when I put together the TR1 library in the sandbox vault (http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=tr1), I wrapped all the random generators in order to provide a TR1 conforming interface: no fancy compiler tricks were required at all. Feel free to steal any code you want. Footnote: strictly speaking these changes which introduce new features should not have been introduced at this time (right before release). John.
John Maddock wrote:
Footnote: strictly speaking these changes which introduce new features should not have been introduced at this time (right before release).
Especially changes known ahead of time to cause regressions. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
John Maddock wrote:
Footnote: strictly speaking these changes which introduce new features should not have been introduced at this time (right before release).
Especially changes known ahead of time to cause regressions.
Well this is really aggravating.. Here I spend a few thousand dollars, in my time, getting tests to work for the current code with the CodeWarrior compilers. And the random changes, really new features, break *four* already passing libraries for CW-8.3. (don't know about the other versions as I didn't keep track) Please.. I implore.. Fix problems.. Don't create them :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Jonathan, Please revert these changes to use Boost.Random. We cannot afford such changes at this time in the release cycle. As it is, the iostreams has a huge number of failures on many platforms. We need to fix those failures, soon, and not introduce any more of them. On May 20, 2005, at 1:56 PM, Rene Rivera wrote:
Rene Rivera wrote:
John Maddock wrote:
Footnote: strictly speaking these changes which introduce new features should not have been introduced at this time (right before release). Especially changes known ahead of time to cause regressions.
Well this is really aggravating.. Here I spend a few thousand dollars, in my time, getting tests to work for the current code with the CodeWarrior compilers. And the random changes, really new features, break *four* already passing libraries for CW-8.3. (don't know about the other versions as I didn't keep track)
Please.. I implore.. Fix problems.. Don't create them :-(
Doug Gregor 1.33.0 Release Manager
Jens, We appreciate that Boost.Random is moving toward TR1 compliance, but right now are in the middle of a release cycle and we cannot deal with destabilizing changes. The regression tests from the Random library went from almost completely green (I think I fixed the last bugs about 2 days ago) to having a large number of failures, which have propagated to other libraries. Please revert these changes. You can create a separate branch and commit the changes there, or wait until we have released 1.33.0 to commit them. Doug Gregor 1.33.0 Release Manager On May 19, 2005, at 4:35 PM, Jens Maurer wrote:
I've checked in changes to the Boost.Random library that add constructors and seeding for both
template<class Generator> and unsigned long
arguments, thereby moving Boost.Random one step further towards TR1 compliance.
The random_test.cpp program now has basic tests for this feature.
In order to guide overload resolution, I've used boost::enable_if<> and type traits to make sure that integral arguments don't try to call the "template<class Generator>" overloads. This could mean decreased compiler support, sorry.
It works for me with gcc 3.4.3.
Jens Maurer
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
Doug Gregor -
Jens Maurer -
John Maddock -
Jonathan Turkanis -
Rene Rivera