On Thu, 03 Jun 2010 00:22:26 +0200, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> I'll have a look to see if I can tighten the namespace usage up a bit.  
> As a
> rule I tend to try to avoid "using std" if I can, but there's some places
> where we use a namespace so much that typing in the prefix each time  
> makes
> the code less readable by cluttering it. At the least I might be able to
> only import specific portions.

Importing specific symbols (and in some cases even whole namespaces) can  
sometimes be useful, but care should be taken to limit the scope at which  
the import takes place. Doing it in a header file is generally  
inadvisable; you never know what other symbols might be visible in  
whatever files include the header.

Another issue with importing whole namespaces that has not yet been  
touched upon in this thread is that doing so prohibits you from (re)using  
any name that is visible in that namespace. In other words, you can get  
collisions with your own type/variable names, not just with those in  
another namespace you are also importing (as in this particular case). The  
likelihood of a name collision depends on the size of the imported  
namespace and the size of the scope into which it is imported.



> As for not compiling in VS 2010 - while I will fix it via the define
> mentioned in this thread, I will point out that breaking boost is poor
> practice by microsoft, as it's a very popular library.

They are *not* breaking Boost; the types are in separate namespaces and  
can coexist just fine. The problem only arises when someone imports both  
types into the current namespace (in this case implicitly by importing  
both namespaces in their entirety) and then tries to use the unqualified  
typename.



> I haven't looked at the VS2010 header files but if it's true that they
> are importing the namespace that their implementation of shared_ptr is
> in by default (without a specific directive from the project file), then
> that's hardly our fault.

Why does it have to be anyone's fault? Microsoft made the decision that  
they thought would benefit their customers most. The only question now is  
whether you care enough about compatibility with VC++ 2010 to make the  
changes necessary to ensure such compatibility.

Note that the issue would have surfaced eventually anyway, even if  
Microsoft had chosen differently. In all likelihood, the new C++ standard  
will become final in about a year or so (it is already at Final Committee  
Draft, which essentially means feature freeze). Compiler vendors will  
continue to implement C++0x features, and eventually they will stop being  
optional. In fact, Visual C++ may well be the most predictable of the  
bunch; it is very unlikely that Microsoft would add new features in a  
minor version upgrade, so what they have now is probably going to be all  
they have for at least a year or two (this may actually have been a  
significant factor in their decision).

If the official stance of the POV-team is that compilers with C++0x  
features enabled are not (yet) supported, then that is fine. At least it  
would be consistent. It might not be what I personally would have chosen,  
but it is not for me to make that call.



> They can't go and claim they didn't know there would be other folks using
> shared_ptr ... at a minimum, their project conversion wizard should have
> asked about this when bringing in pre-VS2010 projects.

I disagree. Boost is *expected* to clash with the standard library; one of  
the main goals of Boost is to get libraries into the standard. This is  
exactly the kind of situation that namespaces are intended for.



-- 
FE

Post a reply to this message