[boost] Re: [constant] New version + YANL-example available

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2004-01-26 14:01:28

Beman Dawes wrote:
> At 10:59 AM 1/26/2004, David Abrahams wrote:
>  >Daniel Frey <daniel.frey_at_[hidden]> writes:
>  >
>  >>And I use __typeof__, which I don't know
>  >
>  >I haven't been paying too much attention, but I sure hope we don't
>  >have a [proposed] boost library which relies on the presence of
>  >nonstandard language extensions (__typeof__) for its operation here.
> 
> Particularly since the C++ committee hasn't agreed on final specs for 
> __typeof__, or whatever it ends up being called. The specs may change 
> quite a bit before a final vote is taken. This isn't a case of some 
> compiler vendors just being slow to implement something the committee 
> has already blessed.
> 
> Dave's choice of the word "relies" is a key point. Lots of Boost 
> libraries make use of nonstandard compiler extensions if available, but 
> have useful fallbacks if the extension isn't available. Thus they don't 
> rely on the extension for correct operation.

Hm, I could ask the user to specify the result type of each operator 
call for some types T and U for all platforms/compilers that don't 
support __typeof__. Is that what you had in mind?

If yes, please take into account that it's currently a waste of time as 
all compilers that can compile the code (even without __typeof__) have 
__typeof__ anyway. VC7.1 gave an internal compiler error on previous 
versions that haven't used __typeof__, so removing it won't make the 
code any more portable AFAICS.

And if you have other ideas how to improve the situation, I'd be glad to 
hear about them. I just fear that I found just another example why 
__typeof__ is needed so badly that it is already implemented by many 
compilers (unlike a lot of other proposed extensions).

For the "rely on the extension for correct operation": Isn't this what 
the unit tests are meant for? Even if there is a standard, we know that 
we need to test everything over and over again given the real-world 
situation with compiler bugs.

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial solutions & technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de