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.

"Simon Buchan" 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

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

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

"John Maddock" 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

"Howard Hinnant" 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 typeof( sqrt( X() * X() + Y() * Y())) hypot( X ,Y); a promoted::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::type is a suitable candidate for type_traits ? regards Andy Little

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.

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.