Thorsten Froehlich <tho### [at] trfde> wrote:
> On 01.06.10 00:00, Edouard wrote:
> > For now, you could try putting the following switch in the "C++ Command Line"
> > additional options field:
> >
> > /D_HAS_CPP0X=0
> >
> > That should suppress the TR1 features in the Microsoft headers, as it seems it's
> > not quite the time to move away from the Boost implementation of those features
> > just yet.

> Cool, I was looking for this but could not find it at any logical place (to 
> me) in the MSDN VC2010 documentation that is online. Do you have a reference 
> where to find it? Strangely, googling for "D_HAS_CPP0X" returns no results - 
> yet I thought all VC 2010 docs are online (I still have 2008, so i can't 
> check offline docs).

  I'm curious to know what is your solution to all the other compilers which
are implementing features of the upcoming C++ standard. Will you find such
preprocessor macros in all of them and add them to the project? Are you going
to keep blaming the compilers for implementing the new standard?

  And what happens when the upcoming standard gets ratified and suddenly all
those compilers become standard (and hence you can't blame them anylonger)?
What if some of those compilers stop referring to "CPP0X" or alike, once
again breaking the compilation?

  That solution is, simply put, a *kludge* to get around a design problem
which would have a very clear and clean solution.

  After all, it's perfectly *ok* for there to exist a class named "shared_ptr"
inside the 'boost' namespace *and* the 'std' namespace. That's exactly what
namespaces exist for. If you pull everything out of those namespaces and
suddenly get naming collisions, the problem is not in the libraries. The
problem is in your code. It's the code which is broken. The libraries are
doing nothing wrong.

-- 
                                                          - Warp

Post a reply to this message