Re: [boost] VC++ 7.0 Challenge

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-08-22 13:42:03

>It's very sad, but that would seriously limit my participation. My employer
>demands VC++ compatibility, ...
>
> > From: "Beman Dawes" <beman_at_[hidden]>
> >
> > > I've had an email exchange with a MS VC++ product manager, who confirms
> > > that they have no plans to improve ISO compliance in 7.0.  So any
> > > improvements are several years away at best.
> >
> > If Microsoft refuses to conform to ISO C++ then I strongly recommend
> > that people stop using their compiler.  There are some excellent
> > alternatives available.
> >
> > I also suggest we pick a not-too-distant date to phase out 6.0
> > support in Boost, and not even try to support 7.0.

Some outside commentary here.

It sounds like VC++ is in the same boat as me with gcc.  That 
is that it demands special treatment.  (I should know as I had
to write a nearly separate version of libsigc++ just for VC++.)
One approach is to phase out support, but when what happens when
the next compiler doesn't meet boost level of standards compliance?  

The more balanced approach is to do like I plan to do.  I need
formatter for g++, so I will contribute that plus one written
toward the standard.  If the one I contribute is broken toward
VC++, someone else who is interested should port it as best the
API translates.  Like libsigc++, the VC++ port may be defective in
minor ways but if 99% of the API works and looks the same it
is likely close enough.  Boost should host the libraries and 
note which libraries require a special port.  

------------------------------------------------------------------------
Example:  from libsigc++

X - use standard
D - use standard with some deficiencies
P - special port required
N - not available (special port would need to be written)
 
               standard  gcc 2.7 egcs  gcc 2.95  BC  VC++
   ---------------------------------------------------------------- 
   libsigc++   X         N       D*        X      X    P**

* Some specialization is broken resulting in excessive value copies.
Consider upgrading.

** VC++ is the worst compiler we have every seen it lacks partial
specialization and can not compile templates with default arguments
which are template types.  Both result in degraded performance.

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

In other words make it clear in a table that some libraries in boost
just can't be ported because they are too defective.  There they
require a special port link to a specific bitch about their faulty compiler.
At the same time don't let VC++ hold back good clean implementations as
good clean implementation are what we should be trying to get in STL
not back hacks to work around VC++.

If boost currently has VC++ support for some of its libraries it should
keep it.  However, decisions regarding the API should be made solely
with regard to what the standard it allowed.  When and if people 
need a library from boost that doesn't support VC++ then people will
have to make the effort to port.  If it can't be done directly, then
all the more reason for them to bitch to M$ that their product sucks.   

<rant>
If you want to see Mircosofts position regarding what their customers
think of their standards compliance read this link from my 
C++ interview hall of shame file

  http://msdn.microsoft.com/visualc/headlines/joninterview.asp

From interview with Jon Caves
   ...
   The biggest contributing
   factor to our current level of conformance is the need to maintain
   backwards compatibility with existing code, as more important than
   comformance to the standard. The majority of our users rank backward
   compatibility with existing code higher than conformance to the standard.
   That said, we will continue to implement features that bring us as close as
   possible to the standard, without negatively impacting our developers.
   ...
   Given my statement above, I would say that for many, if not most, of
   our users we already have an acceptable level of compliance. What I would
   like to see is that, for each release of Visual C++, the numbers of users,
   who are happy with our level of compliance rises. We certainly are still
   working on making Visual C++ more compliant so hopefully this number
   will continue to rise with future releases of Visual C++.

For more reading see

  http://www.msdn.microsoft.com/chats/vc/VisualC_032599.asp

Where all those features are "being looked at".

Someone really needs to tell Jon his customers aren't happy with current
level of support enough that a major effort would like to see support
for VC++ in design decision go out the door!

</rant>

Note that things like no partial specialization and other features
were not enough to prevent me from getting libsigc++ over to VC++.
There are ways to get around it through the use of specialized traits.
Though I admit is was a fair bit more pain then I would wish on most
people.

--Karl