clipka wrote:
> Am 02.06.2010 20:55, schrieb Nicolas Alvarez:
>> The point is: If he stops complaining and goes get his hands dirty and
>> sends you a patch adding the needed std:: namespace prefixes... will you
>> accept it and apply it?
> 
> Warp used to have an account for the POV-Ray code repository to directly
> submit changes, so your question is actually missing the point, unless
> that account was revoked for some reason (and even then it would
> ultimately be up to Chris Cason to accept or reject such a patch).

I think you're missing the point too. Just because he has commit access 
doesn't mean he can go against what other team members want.

If he commits such a change, will you or Thorsten complain and/or revert it?

Post a reply to this message

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

Am 04.06.2010 00:07, schrieb Nicolas Alvarez:

> If he commits such a change, will you or Thorsten complain and/or revert it?

Let me put it this way: Justifying a rollback of someone's changes 
requires much stronger arguments than making the change in the first place.

At any rate it would be Chris Cason who would have the last word on such 
an issue, not me nor Thorsten.


But the question has become pretty much academic anyway, given that 
Chris has already announced that he will be addressing the issue himself.

Post a reply to this message

Edouard <pov### [at] edouardinfo> wrote:
> 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.

  Well, I can honestly say that I don't. To me it's perfectly readable, and
the 'std::' prefixes make it even clearer what is a standard type or function
and what is a local variable, hence making it *more* readable to me than if
the prefixes had been omitted.

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

  Well, that's the problem: Without the prefixes you have to make an
assumption. With the prefixes you don't have to assume anything.

  If your programming policy is to skip the namespace prefixes, then you also
have to use additional extraneous coding conventions in order to avoid name
collisions with the standard library. For example, you must never use a
function name or type which might be the same as one existing in the standard
library. Given how extensive the standard library is, it's not completely
unlikely that naming collisions won't happen.

  What is worse, even if your code doesn't clash with the standard libraries
*now*, they might start clashing in the future when new names are introduced
to it.

  However, if you always fully qualify names in the std namespace and never
use 'using namespace std' then you don't need those extra coding conventions
because it's much less likely for name collisions to happen, now or in the
future.

  Thus fully std:: qualifications are not pointless. Not only do they
increase readability (yes, I stress that point a lot), but they also make
the code more robust and less likely to break in the future.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Edouard <pov### [at] edouardinfo> wrote:
>> 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.
> 
>   Well, I can honestly say that I don't. To me it's perfectly readable,
> and the 'std::' prefixes make it even clearer what is a standard type or
> function and what is a local variable, hence making it *more* readable to
> me than if the prefixes had been omitted.

I agree. Sometimes I found code using std::something where I didn't know the 
'something' even existed in the C++ standard. Without the std:: I would have 
thought it was a custom function.

Post a reply to this message

On 04.06.10 18:56, Warp wrote:
>    Well, that's the problem: Without the prefixes you have to make an
> assumption. With the prefixes you don't have to assume anything.
>
>    If your programming policy is to skip the namespace prefixes, then you also
> have to use additional extraneous coding conventions in order to avoid name
> collisions with the standard library. For example, you must never use a
> function name or type which might be the same as one existing in the standard
> library. Given how extensive the standard library is, it's not completely
> unlikely that naming collisions won't happen.
>
>    What is worse, even if your code doesn't clash with the standard libraries
> *now*, they might start clashing in the future when new names are introduced
> to it.

Nonsense, pure and simple: The standard library uses lower case for all 
names. So guess what is sufficient to avoid any and all collisions now and 
in the future ... ROFL - your arguments really don't make sense!

(Rhetoric question) Don't you think it is time to quit this thread?

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 04.06.10 18:56, Warp wrote:
> > you also
> > have to use additional extraneous coding conventions in order to avoid name
> > collisions with the standard library.

> Nonsense, pure and simple: The standard library uses lower case for all 
> names. So guess what is sufficient to avoid any and all collisions now and 
> in the future ... ROFL - your arguments really don't make sense!

  Thanks for confirming exactly what I said. Ironically, you thought you
were discrediting it.

  (Besides, your claim is easy to prove wrong: std::FILE.)

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> (Rhetoric question) Don't you think it is time to quit this thread?

  Btw, can I ask you a non-rhetorical question?

  Why are there so many questions in this thread which I have asked and
which have got no answers whatsoever? These are *practical* questions
related to solving the problem at hand.

  - You claimed that using fully qualified names "seriously deteriorates
maintainability", which is why it's a bad idea to do that. I asked you
exactly how. I got no answer.

  - Edouard suggested that rather than changing the 'shared_ptr' references
in the code, instead the "using namespace" statements should be changed
"to intelligently chose (based on compiler and version) whether a particular
compilation of POV uses the version in std or the version in boost". When
I asked exactly how this would be done without breaking any of the other
unqualified names in the code, I got no answer.

  - Someone suggested a precompiler macro specific to VC++ 2010 to make it
not include 'std::shared_ptr'. When I asked what will be done when other
compilers start implementing 'std::shared_ptr', potentially repeating the
current problem at hand, I got no answer.

  - It was suggested that some newer boost TR1 implementation of shared_ptr
should be used as some kind of solution to the current problem. You agreed
that it would be a good idea. When I asked exactly how this would be done
in such a way that it would solve the problem at hand, I got no answer.

  - Most importantly, when I asked the question: What exactly would be the
problem in using 'boost::shared_ptr' (perhaps abstracted away with a typedef)
instead of 'shared_ptr', which would nicely solve the problem at hand in a
portable way and without having to resort to compiler-dependent trickery,
I got no answer.

  Can you answer me even that last question, if not the others? I honestly
cannot see the problem in using 'boost::shared_ptr' explicitly. It would
just solve the current problem, would not depend on any compiler-specific
settings, and would be a clean and easy solution. So what exactly *is* the
problem?

  Is that too much to ask? I'm asking completely honestly here.

-- 
                                                          - Warp

Post a reply to this message

On 05.06.10 10:32, Warp wrote:
>> Nonsense, pure and simple: The standard library uses lower case for all
>> names. So guess what is sufficient to avoid any and all collisions now and
>> in the future ... ROFL - your arguments really don't make sense!
>
>    Thanks for confirming exactly what I said. Ironically, you thought you
> were discrediting it.
>
>    (Besides, your claim is easy to prove wrong: std::FILE.)

Great, I was certain you would come up with some macro (there are also 57 
macros) or some other C compatibility feature to make "your point". But 
luckily, I can read and quote the standard...

Annex D [depr]
(normative)
Compatibility features
1 This clause describes features of the C++ Standard that are specified for 
compatibility with existing implementations.
2 These are deprecated features, where deprecated is defined as: Normative 
for the current edition of the Standard, but not guaranteed to be part of 
the Standard in future revisions.

D.5 Standard C library headers [depr.c.headers]
2 Each C header, whose name has the form name.h, behaves as if each name 
placed in the Standard library namespace by the corresponding cname header 
is also placed within the namespace scope of the namespace std and is 
followed by an explicit using declaration (7.3.3)

LOL, the bad, bad standard uses "using declarations" for whole files. How 
can those amateurs dare!

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 05.06.10 10:32, Warp wrote:
> >> Nonsense, pure and simple: The standard library uses lower case for all
> >> names. So guess what is sufficient to avoid any and all collisions now and
> >> in the future ... ROFL - your arguments really don't make sense!
> >
> >    Thanks for confirming exactly what I said. Ironically, you thought you
> > were discrediting it.
> >
> >    (Besides, your claim is easy to prove wrong: std::FILE.)

> Great, I was certain you would come up with some macro (there are also 57 
> macros) or some other C compatibility feature to make "your point". But 
> luckily, I can read and quote the standard...

  I don't understand how your quote of the standard is related to what I said
above.

> Annex D [depr]
> (normative)
> Compatibility features
> 1 This clause describes features of the C++ Standard that are specified for 
> compatibility with existing implementations.
> 2 These are deprecated features, where deprecated is defined as: Normative 
> for the current edition of the Standard, but not guaranteed to be part of 
> the Standard in future revisions.

> D.5 Standard C library headers [depr.c.headers]
> 2 Each C header, whose name has the form name.h, behaves as if each name 
> placed in the Standard library namespace by the corresponding cname header 
> is also placed within the namespace scope of the namespace std and is 
> followed by an explicit using declaration (7.3.3)

> LOL, the bad, bad standard uses "using declarations" for whole files. How 
> can those amateurs dare!

  Perhaps you don't understand what "compatibility" and "deprecated" mean?

  In English those words mean in this context "compilers should implement
.h versions of standard header files for compatibility with code written
for pre-standard C++ compilers, but these headers should be considered
deprecated and might be removed at any time in the future".

-- 
                                                          - Warp

Post a reply to this message