Warp <war### [at] tagpovrayorg> wrote:

>   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.

So, addressing the question of namespaces prefixes in general:

I've seen quite a lot of code in my time that looks like this:

std::vector< std::string > v1 = someFunction();
std::vector< std::string > v2;
std::transform( v1.begin(), v1.end, v2.begin(), std::bind1st( std::not_equal_to<
std::string >( "" ) ) );
for( std::vector< std::string >::iterator i = v2.begin(); i != v2.end(); ++i )
    std::cout << *i << std::endl;

and I have trouble with it in terms of readability. There are namespace
qualifiers everywhere, and they don't convey any useful information to me. If I
see a "vector< string >" in some code, I make the assumption that it's a
std::vector and a std::string. Qualifying it seems rather pointless - esp when
you see it repeated on many subsequent lines. I don't look at the code above and
go "oh, and they are talking about a std::vector< std::string > on the second
line too - that's really useful to know. It would be very ambiguous otherwise".

Programming a medium to large sized project involves establishing a vocabulary
for that project. If you are working on project with others it allows you to
agree on common terms, and default meanings. You use typedefs and templates to
do this. I'm arguing that you should also do the same with common terms like
cout, vector and string. You are saying, for said project, "when I talk about a
vector, I mean std::vector".

There are probably projects where a different set of common terms could be
chosen - some engineering project where vector means
"fancy_numeric_library::vector", and not "std::vector". That's fine, as that is
the vocabulary for that project.

Having established the default terms in your project, you can use them
efficiently and tersely. And when you need to refer to some other similarly
named class, variable or concept, you can do some with explicit
qualification, as you are now referring to the exception and not the rule.

In my own code I use namespace directives to establish these common terms, and
use explicit qualification when I want to convey useful information - uncommonly
used library classes can benefit from qualification for example.

Another way I use explicit qualification to convey information is global
variables - in general globals should be avoided, but having some is useful, esp
when referring to program wide information. Program options is a common example.
I use a "namespace global { ... }" with those items, and in most code I
explicitly qualify their usage:

if( global::use_bitmap_caching == true ) { ... }

Of course I have some startup code that only deals with those globals, so I
either put all that code into a single cpp file and using a "using namespace
global", or (on other occasions) I put the "using" statement into the individual
functions. Function level using statements are very powerful and I find they
greatly aid both maintainability and readability.

Again, the thing I'm always aiming to do is convey useful information with
namespaces.

>   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.

I'm not so much for that, as shared_ptr already has well established and
understood semantics for C++ programmers. And the versions we are choosing
between in this case all have exactly the same semantics. I'm not sure a
pov_shared_ptr type is any clearer than a plain shared_ptr. To my mind, this is
a library management issue, not a functional one.

But its not bad either. This whole discussion isn't black and white - there is
no right or wrong. There are simply a set of choices, each of which can be
graded on multiple sets of criteria. Some choices may aid readability, but harm
maintainability for example. The community can then discuss the implications and
arrive at (hopefully, but not always, a) consensus decision about which choice
seems to have the most positive aspects versus negative ones.

>   (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.)

I got that, yes. Hopefully you can see that I've got some reasons, whether or
not you agree with them, for my position as well.

Cheers,
Edouard.

Post a reply to this message