RE: [boost] boost::config and covariant return types

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-09-27 17:46:33

----- Original Message -----
From: Jens Maurer <Jens.Maurer_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, September 27, 2001 6:32 PM
Subject: Re: [boost] boost::config and covariant return types

> Fernando Cacciola wrote:
> > > Should the topic come up in the LWG, I would definitely argue strongly
> > > against it.
> > >
> > Sorry; but, against "having a compiler_config header" or against
> > "considering optional features a bad idea"?
>
> Against having a compiler_config header and thus officially
> accepting and trying to deal with less-capable implementations on
> the standard level.
>
I see.
Yours might be the most appropriate position from a Standard perspective.
I'm not sure though, because in the not-so-short term, it just makes real
developers dealing with real compilers struggle to do a task that would be
significantly easier if the right tools existed. I understand however, that
allowing this might just give compiler vendors a good reason to keep
underestimating the neccesity of comformance; so in the really-long term
this can turn out to be the best choice.

However, I think you'd agree that in order to write any piece of portable
code such a header is REQUIRED.

Therefore, the questions are how,when and by whom is such a header created.

If it won't be part of a vendor's standard library (though it generally is,
as a private part of it), then I *strongly recommend* having
boost\config.hpp be targeted to the end user, not just boost developers.

>From a user perspective, I'd find such a header a fundamental tool. In fact,
chances are that any developer writing portable code will use *that* header
in his own non-boost code (or a header built with copy and paste).
It takes a lot of time to identify the subtleties and dark-corners of each
compiler and platform. Boost have already advanced a lot in this direction,
so I think that allowing users to gain all that information is fundamental.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com