POV-Ray : Newsgroups : povray.beta-test : Beta 37 and C++0x : Re: Beta 37 and C++0x Server Time
30 Jun 2024 17:47:04 EDT (-0400)
  Re: Beta 37 and C++0x  
From: Warp
Date: 30 May 2010 10:44:10
Message: <4c0279ba@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> wrote:
> >    I'm curious to know what your excuse will be when the C++0x standard is
> > ratified and POV-Ray will stop compiling on *standard* compilers.

> POV-Ray will continue to compile on all compilers that are ISO C++ 1998 and 
> 2003 standard compliant. Academically designing for an unknown future 
> standard would mean no program would ever be written as standards can change 
> everything over time, and _do_ even *drop* features!

  You are seriously claiming that using 'std::' prefixes in order to make
the code more compatible with future standards is a bad idea?

> >    Avoiding "using namespace std;" is a good practice because it avoids
> > precisely the kind of problems as presented here.

> No

  WTF, man? "Avoiding 'use namespace std;' is a good practice." "No."

  Are you serious? It seems that you are. Your argumentation, however,
doesn't make the least bit of sense:

> even a fine grain use of namespace std will not solve the problem.

  I don't even understand what that means.

> You end up having to fully qualify all names

  And that's bad because...?

> which could not be more pointless 
> - it completely defeats the purpose of namespaces being meant as a 
> simplification, not a complication, for the programmer.

  No, the purpose of namespaces are to avoid name collisions, and 'using
namespace std;' completely defeats their purpose.

  Could you please explain in which way using 'std::' prefixes is a
complication?

> >    Exactly what would be the problem in avoiding "using namespace std;" and
> > using the 'std::' prefixes? It's not like POV-Ray needs to be compilable in
> > 20-years-old compilers anylonger (it requiring boost and all).

> Formally the current standard-compliant way of accessing the std smart 
> pointers is by accessing namespace std::tr1.

  There are no std smart pointers (other than auto_ptr). 'std::tr1' is not
standard.

  If you want to use boost smart pointers, then use boost smart pointers,
not some smart pointers which have been dumped to the global namespace,
causing potential name collisions (as happened here).

> The std qualifiers just add a 
> lot of completely useless clutter to the code, seriously deteriorating 
> maintainability.

  You are arguing purely for the sake of argument, and clearly don't know
what you are talking about. You clearly have the mindset of the typical
C hacker / beginner C++ programmer that the 'std::' prefixes are "ugly"
and "useless clutter", when in fact they are the exact opposite: They make
the code easier to understand and they are useful precisely because they
lessen the danger of name collisions (which is exactly what happened in
this case).

  Could you *please* explain to me *in detail* how using 'std::' prefixes
"seriously deteriorates maintainability"?

  I can argue why 'std::' prefixes make code easier to understand. For
example, assume a line of code like this:

    if ( equal(a, b, c) ) { ... }

  What can you tell me about that line of code? That's right: Nothing at all.
This could be anything. Without seeing the rest of the code it's impossible
to tell what exactly it's doing.

  However, consider this line of code instead:

    if ( std::equal(a, b, c) ) { ... }

  What can you tell me about that line of code? Quite a lot. The 'std::'
prefix makes a whole world of a difference. Now you know that it's using
the 'equal()' function of the standard library, and hence you know that
'a' and 'b' are iterators defining a range, and 'c' is an iterator specifying
the beginning of another range. You also know what the conditional will do
(run through the first range and compare all the elements to the second
range).

  That's quite a lot of information that a simple 'std::' is conveying. More
importantly, the 'std::' prefix is making the line a lot more unambiguous
because you know you don't have to look where the definition of 'equal()'
might be, as you know it's a standard function. Hence the code is much
easier to understand more quickly and with less work.

  So, again, could you please explain how using 'std::' prefixes deteriorates
maintainability?

-- 
                                                          - Warp


Post a reply to this message

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