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

On 3/06/2010 09:40, Fredrik Eriksson wrote:
> The only question now is whether you care enough about compatibility
> VC++ 2010 to make the changes necessary to ensure such compatibility.

No, that is not the question. It's not the question because I already
answered it in the message you are replying to (and in fact you even quoted
my response). I clearly stated I would fix it; yet you chose to be
insulting in response ('whether we care enough' is clearly not intended to
be polite).

Hint: obliquely insulting developers who give their time for free isn't a
good way to get things done.

> 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  

Our official stance is that we support what our source code pages say we
support. You can read into that what you wish.

> would be consistent. It might not be what I personally would have
> chosen, but it is not for me to make that call.

VS 2010 was only officially released a month or two ago; not everyone has
the luxury of having the latest release toolsets. If you wish to purchase a
copy of Visual Studio 10 Pro for us to use then I'd be happy to add
"official support" for it and thus C++0x.

If you are not willing to do so then it seems rather arrogant for you to be
taking the attitude you have in your previous posts. Put simply, if you're
not willing to provide us the tools to achieve the result you wish, then I
suggest you don't talk down to us in the manner you have.

NB for the record, I'm not interested in installing the free express
edition of VS 2010 and thus running with two versions of VS installed. I'm
happy enough using VS 2008 pro; POV-Ray isn't the only project I code on
(it may surprise you to know I have a day job which pays the bills around
here - POV-Ray certainly doesn't) and I need the full version's features.

I have no reason to upgrade at the moment as none of my paying clients
requires me to have VS 2010.

-- Chris

Post a reply to this message

Chris Cason wrote:
> NB for the record, I'm not interested in installing the free express
> edition of VS 2010 and thus running with two versions of VS installed. 

VMs are great for this sort of thing.  MS even has a free VM that 
(obviously) works really well with Windows.  Which is not to imply any 
obligation on your part to use a VM, but if your job ever requires you to 
use different programs that only run under incompatible OSes, it works out OK.

-- 
Darren New, San Diego CA, USA (PST)
    Ada - the programming language trying to avoid
    you literally shooting yourself in the foot.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Chris Cason wrote:
> > NB for the record, I'm not interested in installing the free express
> > edition of VS 2010 and thus running with two versions of VS installed.
>
> VMs are great for this sort of thing.  MS even has a free VM that
> (obviously) works really well with Windows.  Which is not to imply any
> obligation on your part to use a VM, but if your job ever requires you to
> use different programs that only run under incompatible OSes, it works out OK.

Seconded - I run VMWare on my Mac, so, in this case, I downloaded VS 2010
express and fired it up that way. Really works well.

I hadn't, however, seen the latest happenings with Virtual PC - thanks for the
info.

Cheers,
Edouard.

Post a reply to this message

On 03.06.10 00:39, Edouard wrote:
> I'd suggest upgrading to the latest boost (1.43.0), and using the it's tr1
> implementation (and namespace)

That actually *is* a good idea indeed.

	Thorsten

Post a reply to this message

On Thu, 03 Jun 2010 05:10:00 +0200, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> I clearly stated I would fix it; yet you chose to be
> insulting in response ('whether we care enough' is clearly not intended  
> to be polite).

It was never my intention to be insulting. That you choose to see things  
that way is unfortunate, but not my doing.



> Hint: obliquely insulting developers who give their time for free isn't a
> good way to get things done.

Taking offence when none was intended is not very productive either.



It is abundantly clear that in addition to what anyone feels about the  
technical issues under discussion, the very way I construct sentences is  
being construed as a personal attack. Consequently, I will refrain from  
further attempts at participation.



-- 
FE

Post a reply to this message

Edouard <pov### [at] edouardinfo> wrote:
> The point of namespaces is to give you tools to *manage* namespaces. If all you
> wanted was a way of naming things differently, then C++, pre-namespace, already
> gave you ways of doing that.

> one example being:

> struct std { class cout { ... }; class endl { ... }  };
> std::cout << blah() << std::endl;

  That would be incorrect. Using a 'struct' instead of a 'namespace' means
that you have to declare all the elements inside the one and same block.
You cannot divide the declarations into separate files, each one declaring
elements inside the same 'std' struct.

  Hence the standard library would be impossible to declare as a struct,
unless you want *everything* to be in one single header file. Given how much
template code there is in the C++ standard library, this one header file
would probably be several megabytes in size and take a significant amount
of time to parse.

> Namespaces are more than just another scoping qualifier. The whole point of
> namespaces is that they give you access to the using statement (with differing
> levels granularity, and with aliasing).

  No. The whole point of namespaces is to add scoping and help remove names
from the global namespace. 'using' (with respect to namespaces) is just a
convenience feature which is more or less irrelevant. It doesn't really add
anything to the language. It could well be left out and little would change
in terms of functionality and usability. (Heck, IMO it would be a big-ass
*improvement* if it was removed from the standard.)

> If all you use namespaces for is to add
> an additional scoping qualifier, that you then use in full everywhere in your
> code, than you're not really using them properly.

  And what, in your opinion, is the "proper" way of using namespaces?

  A "using namespace" statement more or less makes the whole namespace
feature moot. If you are using that statement, you might just as well not
use any namespace to begin with. What's the point? I cannot comprehend how
declaring something in a named namespace and then immediately popping it to
the global namespace would be the "proper" way of using namespaces. That's
not using namespaces at all.

  And as I have commented in another post, namespace prefixes actually make
the code *easier* to read and understand, not harder. It makes the code
significantly less ambiguous, and the prefix syntax is a clear visual clue
that something in a different scope is being used, and thus you don't have
to guess where that name might be defined and what its scope might be.

  Popping a single name with eg. "using std::something;" is slightly better
because at least you are kind-of documenting that "when you see 'something'
in the code below, it's actually 'something' from the std::namespace". Doing
it like that also lessens the danger of naming collisions (because you are
popping the name out of one specific namespace). However, "using namespace
std;" is just nonsensical.

-- 
                                                          - Warp

Post a reply to this message

Edouard <pov### [at] edouardinfo> wrote:
> Or you can leave them as bare shared_ptr's and instead having "using" statements
> to intelligently chose (based on compiler and version) whether a particular
> compilation of POV uses the version in std or the version in boost. Yes, the
> existing "using namespace boost; using namespace std;" causes a problem, but the
> solution is to change those two lines, not hundreds of other lines in the file.

  You are assuming that "shared_ptr" is the only thing that is being used
without a scope qualifier in the source code, and hence it's simply enough
to choose between either "using namespace std;" or "using namespace boost;"
to get the program to compile.

  If you change those two lines, you are going to break a lot more than
some "shared_ptr" uses. Thus you either have to keep those lines, or you
have to go through hunderds of lines of code and add namespace prefixes.

  Your argument did not, in fact, deal with whether it's a good idea to
use namespace prefixes or not. It dealt with abstraction. What you are
saying is "shared_ptr might refer to either the one in boost or the one
in the standard library, and it's thus bad to say explicitly at each
usage location which one it's using".

  The solution to such a problem is not to play with namespaces, but to
abstract away the type. Using the name "shared_ptr" may be a bad idea
because it's actually not abstracting away much, and it has the danger
of suffering from name collisions.

  In one post in this thread Thorsten suggested abstracting the smart
pointer away with a typedef. That's actually a good idea, and I concede that
that is a much better solution than the other things he suggested, or what
you are suggesting.

  (Of course that doesn't mean that the "using namespace" statements are
any more of a good idea. IMO they should be removed regardless of whether
"shared_ptr" is abstracted away or not.)

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 03.06.10 00:39, Edouard wrote:
> > I'd suggest upgrading to the latest boost (1.43.0), and using the it's tr1
> > implementation (and namespace)

> That actually *is* a good idea indeed.

  I don't really understand why it would be a good idea. Are you going to
either use a 'tr1::' namespace prefix (which will not compile with many
older compilers, and might not work with future compilers) or a "using
namespace tr1;" which would add yet a *third* instance of 'shared_ptr'
to mess up things even more?

  I thought that one of the main principles with POV-Ray is that it should
be very portable and that one can compile it with all kinds of compilers
in all kinds of systems. The 'tr1' namespace is implemented in only a
handful of compilers.

  If you use 'boost::shared_ptr' (even if typedeffed), that's going to
compile with all compilers, if the boost library is available, and it's
not going to break even with newer compilers and C++ standards.

-- 
                                                          - Warp

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> > 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  

> Our official stance is that we support what our source code pages say we
> support. You can read into that what you wish.

  I honestly cannot understand what is deemed so problematic here.

  After all, the solution to the problem presented in the original post is
quite simple: Use a fully qualified shared_ptr (iow. "boost::shared_ptr").
Even if both boost and std have the same "shared_ptr", it doesn't matter:
If you fully qualify it, it will be unambiguous. You don't need compiler-
specific settings or outright dropping support for a compiler which
implements things in the new C++ standard, and blaming such compilers for
"breaking boost".

-- 
                                                          - Warp

Post a reply to this message