[boost] Re: config.h[pp]

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-07-13 12:51:56

As someone who's force to use one of the most broken compilers on the
market, I feel I have to protest.  While the way the SGI STL did it is
hardly ideal, at least it did give me a very easy piece of documentation for
seeing exactly *which* pieces of the STL my compiler would support, and
which it would work around.  I've no objection to doing this sort of thing
another way, but do it it must!  It's fine to sit in an Ivory Tower (maybe
not so politically correct as it once was <g>), but when you have to work
with one of those broken compilers, and furthermore, the one with the
biggest market share, you have to be able to *work*.

I'd ask for suggestions at this point on exactly *how* to do it, rather than
rejecting out-of-hand doing it at all.  And I'd offer a suggestion of my
own, if I had one, but this time the old clue bag's empty.

> -----Original Message-----
> From: Beman Dawes [mailto:beman_at_[hidden]]
> Sent: Tuesday, July 13, 1999 10:38 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: config.h[pp]
> 
> 
> At 09:03 AM 7/13/99 -0700, Nathan Myers wrote:
> 
> >I thought we had agreed that Boost wouldn't have workarounds
> >for missing standard features.
> 
> We did, early on before reality set in.  But the people who are
> actually submitting libraries are including macro workarounds.
> 
> >  People with broken compilers 
> >don't have to include Boost headers.
> 
> That would restrict usage of Boost libraries to a very small
> minority, at least today.  Compilance with all the features Boost
> authors are using may be as close as the next release for widely used
> compilers, but it is not here today.
> 
> >  Once you start down
> >the road of supporting broken compilers, where do you stop?
> 
> The current versions of the most widely used compilers are already
> pretty close to standard compliant.  No need to support older
> compilers, or even the few current compilers which have lots of
> compliance problems.
> 
> Template member functions and partial template specialization are the
> areas of major concern today.  The situation has improved markedly
> compared to a couple of years ago.   
> 
> >Is BOOST_NEXCEPTIONS next?
> 
> No, exceptions have been supported for years by most compilers.  
> 
> >  BOOST_EMBEDDED?
> 
> No, although it has never been discussed explicitly, Boost is
> currently focused entirely on hosted environments.
> 
> --Beman
> 
> --------------------------------------------------------------
> ----------
> Be as loud as you want
> Get free email and 20MB of webspace at FortuneCity.com
> http://clickhere.egroups.com/click/367
> 
> 
> 
> eGroups.com home: http://www.egroups.com/group/boost
> http://www.egroups.com - Simplifying group communications
> 
> 
> 
> 

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications