POV-Ray : Newsgroups : povray.beta-test : Beta 37 and C++0x : Re: Beta 37 and C++0x Server Time
2 Jul 2024 15:09:33 EDT (-0400)
  Re: Beta 37 and C++0x  
From: Warp
Date: 30 May 2010 14:40:57
Message: <4c02b139@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> wrote:
> On 30.05.10 19:51, Christian Froeschlin wrote:
> > this is certainly true. However, as far as I understand VS 2010
> > includes only that subset of C++0x which is deemed to be stable
> > and which will likely be present in other future C++ compilers.
> > Despite all reasoning to the contrary, MS folks are not
> > completely stupid. They will have picked carefully.

> If this only was true :-(  For a long time, the M$ person on the ISO C++ 
> committee tried to force the "concept" feature into the standard, 
> subsequently leading to the two year delay when this unfinished idea had to 
> be pulled because national bodies would not have such a broken incomplete 
> idea in an international standard.

  I didn't know Bjarne Stroustrup worked for Microsoft (given that he has
been one of the most influential proponents of the concepts feature).

> > I'm not arguing against using namespace statements here, but at
> > least the known almost certainly soon-to-be name conflicts should
> > use fully qualified names even if the assessement is based on a
> > draft. Otherwise you get "academic code quality" ;)

> As said, there is no problem as long as new experimental compiler features 
> are not enabled. There are actually C++ macros that return the version that 
> is being compiled against. I would argue that it might be a good idea to 
> check this version and refuse to preprocess if the required version is not set.

  You are seriously suggesting that instead of removing "using namespace std;"
and "using namespace boost;", the code should use some non-standard macro
checks and refuse to compile if they do not have a certain value?

  Have you gone completely mad? I knew that you are stubborn and have a strong
resistance to change (any change), but this is going too far.

> The more interesting question is the following though: Why does the problem 
> appear at all? The answer is equally simple: Some header file pulls in the 
> non-standard shared pointer class.

  No, the answer is: "using namespace std;" and "using namespace boost;"
dump everything inside those namespaces to the *global* namespace, causing
potential name collisions.

  The solution is simple: Don't dump everything to the global namespace.

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.