Boost logo

Boost :

From: Dietmar Kuehl (dietmar.kuehl_at_[hidden])
Date: 1999-07-14 20:54:58

At 17:37 14.07.99 -0700, Reid Sweatman wrote:
>Wow, I guess I really pushed one of your buttons <g>.

Well, there are several reasons why I really don't want to deal
with this configuration stuff for non-standard compilers:
- It is aweful work which sometime has significant impact on the interface.
- It kind of "blesses" this non-standard compiler.
- It is more work.
- I have used more than just egcs and found that there are several compilers
  which are sufficiently close to the standard to need no work arounds.

> However,
>there's *no such thing* as a totally compliant compiler,

Apart from minor bugs there is only one feature which is not yet (or
at least not yet widely) available and this is the separation model. I
have no problem to work around this one and I figure even if this feature
becomes widely available there is a good chance that I won't use it eg.
for Boost submissions: Header only submissions simply require no kind of
compilation to install the library.

Actually, this issue, namely a way to compile code for all platforms,
would be much more interesting than the configuration stuff.

>so ignoring the
>outfit in Redmond for the nonce, do you really want to limit the usefulness
>of your code to a tiny fraction of compilers that can handle it with no

Although none of the compilers is standard conforming, most implement
all functionality which effects the actual interface. I think that
I'm not limiting my code to a faction of the current compilers! What
I have seen from EDG (this is the front-end eg. of the C++ compiler
shipped by SGI, Siemens, Intel (I think), Comeau, KAI), Visual Age C++,
and egcs, and what I have heard about Metrowerk's, SUN's, and HP's compiler
I'm quite sure that these compile my code. This already covers a large
range of platforms... And even if my code only compiles with egcs, if
this makes an argument why egcs should be used in favor of some other
compiler, this suits me fine!

Just to make things clear: I'm not opposed to any form of configuration
header which is used to deal with functionality outside the scope of the
C++ standard (eg. file system access, GUI, threads, etc.). However, I don't
see any point in a configuration header which deals with missing standard
C++ features. ... and I think we agreed on standard C++ code anyway!


------------------------------------------------------------------------ home: - Simplifying group communications

Boost list run by bdawes at, gregod at, cpdaniel at, john at