The formal review of the Boost TR1 Library by John Maddock begins today, Saturday, September 24th, and runs through Wednesday, October 5th. The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes: * Reference Wrappers * Smart Pointers * Class template result_of. * Function template mem_fn. * Function Object Binders. * Polymorphic function wrappers. * Type Traits. * Random Number Generators and Distributions. * Tuples. * Tuple Interface to std::pair. * Fixed Size Array. * Hash Function Objects. * Regular Expressions. * Complex Number Algorithm Overloads. * Complex Number Additional Algorithms. Functionality in TR1 but not yet available: * Mathematical Special Functions. * Unordered Associative Set (Hash Table). * Unordered Associative Map (Hash Table). * C99 C language additions. Additional information including online documentation is available at http://freespace.virgin.net/boost.regex/tr1/index.html The complete TR1 lib source and docs can be downloaded from http://freespace.virgin.net/boost.regex/tr1/tr1-20050816.zip Please help Boost by posting your formal review of this library. Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. --Beman Dawes, Review Manager
"Beman Dawes" <bdawes@acm.org> wrote
Additional information including online documentation is available at http://freespace.virgin.net/boost.regex/tr1/index.html
The links out of http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1/subject-list.html dont seem to work. e.g link to ref : http://freespace.virgin.net/boost.regex/tr1/doc/html/ref.html gives me "Sorry cant find page ...". Same for all the rest. regards Andy Little
The links out of http://freespace.virgin.net/boost.regex/tr1/doc/html/tr1/subject-list.html dont seem to work. e.g link to ref : http://freespace.virgin.net/boost.regex/tr1/doc/html/ref.html
gives me "Sorry cant find page ...". Same for all the rest.
Correct, the links to the rest of the Boost documentation don't work, I'd have to dump all of the Boost tree onto the server to make them work unfortunately. So this is just a link to your-boost-install-path/doc/html/ref.html. Apologies for any confusion this causes. John.
Beman Dawes wrote:
The formal review of the Boost TR1 Library by John Maddock begins today, Saturday, September 24th, and runs through Wednesday, October 5th.
The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. <snip> Hmm, I think a lot of distributions of TR1 will, at first, be edited, copied, trimmed, out-of-date, versions of boost's implementations anyway, so is there a way to say "I want to use the Boost version by default"? (#define?)
"Simon Buchan" <simon@hand-multimedia.co.nz> wrote in message news:dh7gq4$pp3$1@sea.gmane.org...
Beman Dawes wrote:
The formal review of the Boost TR1 Library by John Maddock begins today, Saturday, September 24th, and runs through Wednesday, October 5th.
The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. <snip> Hmm, I think a lot of distributions of TR1 will, at first, be edited, copied, trimmed, out-of-date, versions of boost's implementations anyway, so is there a way to say "I want to use the Boost version by default"? (#define?)
Simon, You need to read the documentation, and then comment on what you find there, rather than asking other people to do that work for you. --Beman
Hmm, I think a lot of distributions of TR1 will, at first, be edited, copied, trimmed, out-of-date, versions of boost's implementations anyway, so is there a way to say "I want to use the Boost version by default"? (#define?)
No for the following reason: If your vendor supplied version of <utility> already declares the TR1 components inside namespace std::tr1, the there is no way that Boost can do the same thing. If you really want the Boost versions then *use the Boost versions directly*. I guess we could get into namespace renaming: #define tr1 boost_tr1 something like STLport does, but lets see if there's a real demand first. John.
On Sep 25, 2005, at 7:52 PM, Simon Buchan wrote:
Hmm, I think a lot of distributions of TR1 will, at first, be edited, copied, trimmed, out-of-date, versions of boost's implementations anyway,
I'm not sure this is true; at least, it isn't for the 3 implementations of TR1 that I know are in development. All of them were built (mostly) from scratch, although the authors did borrow some ideas and test cases from the Boost implementations. Doug
On Sep 26, 2005, at 10:29 AM, Douglas Gregor wrote:
On Sep 25, 2005, at 7:52 PM, Simon Buchan wrote:
Hmm, I think a lot of distributions of TR1 will, at first, be edited, copied, trimmed, out-of-date, versions of boost's implementations anyway,
I'm not sure this is true; at least, it isn't for the 3 implementations of TR1 that I know are in development. All of them were built (mostly) from scratch, although the authors did borrow some ideas and test cases from the Boost implementations.
<nod> CodeWarrior Pro 9 has: template <class Sig> class result_of template <class T> class reference_wrapper template <class T> reference_wrapper<T> ref(T& t) template <class T> reference_wrapper<const T> cref(const T& t) template <class Sig> class function template<class T> class shared_ptr template<class T> class weak_ptr template<class T> class enable_shared_from_this template <class T0, class T1, ... class T9> class tuple Pro 10 (beta) adds: bind array type_traits All built as Doug describes. This "native" implementation can take advantage of compiler functionality such as __declspec__ or __typeof__, and superior type traits support. And bind just kicks butt with rvalue reference capability turned on. ;-) Definitely not "copied, trimmed, out-of-date." -Howard
Howard Hinnant wrote:
On Sep 26, 2005, at 10:29 AM, Douglas Gregor wrote:
On Sep 25, 2005, at 7:52 PM, Simon Buchan wrote:
Hmm, I think a lot of distributions of TR1 will, at first, be edited, copied, trimmed, out-of-date, versions of boost's implementations anyway,
I'm not sure this is true; at least, it isn't for the 3 implementations of TR1 that I know are in development. All of them were built (mostly) from scratch, although the authors did borrow some ideas and test cases from the Boost implementations.
<nod>
CodeWarrior Pro 9 has:
template <class Sig> class result_of template <class T> class reference_wrapper template <class T> reference_wrapper<T> ref(T& t) template <class T> reference_wrapper<const T> cref(const T& t) template <class Sig> class function template<class T> class shared_ptr template<class T> class weak_ptr template<class T> class enable_shared_from_this template <class T0, class T1, ... class T9> class tuple
Pro 10 (beta) adds:
bind array type_traits
All built as Doug describes. This "native" implementation can take advantage of compiler functionality such as __declspec__ or __typeof__, and superior type traits support. And bind just kicks butt with rvalue reference capability turned on. ;-) Definitely not "copied, trimmed, out-of-date."
-Howard Ahh, sorry, I've only seen the temporary GCC, and an unofficial MSVC (can't remember where) implementation. (Bows head) Is CodeWarrior still going strong? I thought Apple dumped them or something? (Off-Topic, don't need to reply)
On Sep 26, 2005, at 6:38 PM, Simon Buchan wrote:
Is CodeWarrior still going strong? I thought Apple dumped them or something? (Off-Topic, don't need to reply)
CodeWarrior is no longer available on Windows. There will be one last final release on the Mac shortly (Pro 10). Freescale will not pursue an Intel Mac (as far as I know). The CodeWarrior product line is alive and well on various game platforms and on embedded Freescale platforms. -Howard
Hi, In Mathematical Special Functions, why are the functions not template specialisations? Andy Little
In Mathematical Special Functions, why are the functions not template specialisations?
You would have to ask the original author of that section, but I believe it was C compatibility. There is also the issue that many of these functions can only be implemented efficiently if you know the precission of the argument type up front, so the float/double/long double versions would have different implementations in any case (different Chebyshev polynomial approximations for example) and there would be no "generic" implementation readily possible. I've also found that some well known formula can fail quite spectacularly once the compilers optimisations are turned on: either through double rounding of long double intermediates, or through non IEEE arithmetic optimisations. This makes implementing many mathematical functions as templates error prone - because you have no control over the compilation environment - where as separate file compilation effectly solves that issue, albeit in a compiler specific manner. See the proposed log1p implementation (and associated code comments) for one particularly fustrating, if trivial example. I realise you're suggesting template specialisations rather than a generic template, but if there is no generic template provided, what advantages do specialisations provide over regular overloads? John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:049301c5c5a7$369f3160$cfc76b51@fuji...
In Mathematical Special Functions, why are the functions not template specialisations?
You would have to ask the original author of that section, but I believe it was C compatibility.
I'm also under that impression.
There is also the issue that many of these functions can only be implemented efficiently if you know the precission of the argument type up front, so the float/double/long double versions would have different implementations in any case (different Chebyshev polynomial approximations for example) and there would be no "generic" implementation readily possible.
I've also heard comments from the Dinkumware folks that testing is a really major undertaking with these functions, and it also has to be very precision specific. --Beman
On Sep 29, 2005, at 10:11 AM, Andy Little wrote:
Hi,
In Mathematical Special Functions, why are the functions not template specialisations?
At the risk of being irritating, I'm going to ask just the opposite question. ;-) Why is hypot (for example) templated? template <class T> T hypot(T x, T y); If the intent is to implement 8.16.4 (from N1836), I don't think this does it. Consider this test for example: double x = hypot(99., 20); assert(x == 101.); Or this one: double x = hypot(99, 20); assert(x == 101.); Or <gag> this one: double x = hypot(float(99), char(20)); assert(x == 101.); Also do we want to support infinities and nans? assert(hypot(INFINITY, sqrt(-1.)) == INFINITY); -Howard
"Howard Hinnant" <hinnant@twcny.rr.com> wrote
If the intent is to implement 8.16.4 (from N1836), I don't think this does it. Consider this test for example:
double x = hypot(99., 20); assert(x == 101.);
This is the same issue with std::complex isnt it? : complex<double> x; 2 * x; // cant deduce function It would be easily fixable with typeof: template<typename X, typename Y> typeof( sqrt( X() * X() + Y() * Y())) hypot( X ,Y); a promoted<X,Y>::type would work for inbuilt types, but it wouldnt always work for more complicated cases http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html ;-) nevertheless maybe a promoted<X,Y>::type is a suitable candidate for type_traits ? regards Andy Little
nevertheless maybe a promoted<X,Y>::type is a suitable candidate for type_traits ?
The logic needed to carry out promotions as specified in TR1 for the std::complex function overloads is in boost/tr1/detail/math_overloads.hpp, it could be used for a TR1 version of <cmath> as well when we get something to put in it :-) The logic is quite specific to the problem domain, and heavily dependent on MPL though, so how generally applicable it would be I don't know. John.
At the risk of being irritating, I'm going to ask just the opposite question. ;-)
Why is hypot (for example) templated?
Good question, I needed hypot to implement some of the complex number stuff, and it's a template because it was possible to make it one :-)
template <class T> T hypot(T x, T y);
If the intent is to implement 8.16.4 (from N1836), I don't think this does it. Consider this test for example:
I'm aware of those nasties, but <cmath> is *not* part of the current submission, well that's my excuse anyway. Basically hypot/log1p/expm1 are some internals I needed and it seems a shame not to expose them in Boost.Math. I have jumped though hoops however to make sure that <complex> does the right thing with for example: polar(2.3, char(1)); // expression returns a std::complex<double>
Also do we want to support infinities and nans?
assert(hypot(INFINITY, sqrt(-1.)) == INFINITY);
Hmm, what does C99 say about this, I can see anything obvious at first glance? Your suggestion matches what the complex number functions are required to do however, so it's probably in there somewhere, I just can't see it at present. I'm not sure I handle range errors correctly either (setting errno that is). It would certainly be easy enough to convert those functions into non-template inlines that forward to the template implementation, and make them C99 conforming in the process (once I've figured out what that is!) Thanks for raising this, John.
On Sep 30, 2005, at 12:18 PM, John Maddock wrote:
I'm aware of those nasties, but <cmath> is *not* part of the current submission, well that's my excuse anyway. Basically hypot/log1p/expm1 are some internals I needed and it seems a shame not to expose them in Boost.Math.
<nod> Fair enough.
Also do we want to support infinities and nans?
assert(hypot(INFINITY, sqrt(-1.)) == INFINITY);
Hmm, what does C99 say about this, I can see anything obvious at first glance? Your suggestion matches what the complex number functions are required to do however, so it's probably in there somewhere, I just can't see it at present.
Annex F is the place to look. It is optional. You state your intention to conform to it with: #define __STDC_IEC_559_ _ Lots of good stuff in there. hypot is convered in F.9.4.3. -Howard
Hmm, what does C99 say about this, I can see anything obvious at first glance? Your suggestion matches what the complex number functions are required to do however, so it's probably in there somewhere, I just can't see it at present. I'm not sure I handle range errors correctly either (setting errno that is).
Never mind, I've found it in Annex F. John.
participants (2)
-
Andy Little -
Beman Dawes -
Douglas Gregor -
Howard Hinnant -
John Maddock -
Simon Buchan