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

On 05.06.10 12:51, Warp wrote:
>> 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".

Written for "pre-standard C++ compilers" - LOL. Seems you missed that C++ is 
not a successor to the ISo C standard. That standard is well defined and 
quite actively developed: <http://www.open-std.org/jtc1/sc22/wg14/> . But 
hey, what do I know, I don't even speak English.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> On 05.06.10 12:51, Warp wrote:
> >> 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".

> Written for "pre-standard C++ compilers" - LOL. Seems you missed that C++ is 
> not a successor to the ISo C standard. That standard is well defined and 
> quite actively developed: <http://www.open-std.org/jtc1/sc22/wg14/> . But 
> hey, what do I know, I don't even speak English.

  I can't believe I have to explain this to you, even though you know this
perfectly well.

  C++ was first developed by Stroustrup in 1983. C++ compilers began to
appear, each one implementing Stroustrup's language specification plus a
bunch of their own extensions, mostly in the form of libraries. These
libraries were in no way standardized and there was a wide variety of them.
These included all of the C standard libraries and compiler-specific C++
libraries.

  By 1994 one set of libraries, which would later be known as the STL,
became popular and widespread in many compilers due to their versatility.

  Back then there was no namespace support in many compilers, and a common
idiom was to have eg. a <vector.h> header file which declared the 'vector'
data container in global namespace. These got into widespread use.

  It was not until 1998 (15 years after the language was invented and
compilers started appearing) that the language was standardized. The
standardization committee decided that all standard libraries should
use the 'std' namespace instead of declaring everything in the global
namespace.

  Of course there was a minor practical problem then: In 1998 there were
tons and tons of C++ programs written for pre-standard C++ compilers. In
other words they used the <something.h> style of headers and assumed that
the names were in global namespace.

  To alleviate this practical problem the standarization committee decided
to declare that compilers could preserve their <something.h> headers and
make them work as previously (iow. they declare everything in the global
namespace), but the new standard headers should be of the form <something>
and declare everything in the 'std' namespace instead.

  The support for the old <something.h> style headers was added for
compatibility with existing compilers only, and marked as a deprecated
feature right from the start (in other words, new C++ code should not
assume that these headers will exist forever).

  So yes, written for pre-standard C++ compilers. No LOL. There existed
tons of compilers before C++ was standardized, and there was lots and lots
of code written for those compilers.

  Now, could you please explain what you meant with "seems you missed that
C++ is not a successor to the ISo C standard. That standard is well defined
and quite actively developed", and how it's relevant to what I wrote?

-- 
                                                          - Warp

Post a reply to this message

On 4/06/2010 09:01, clipka wrote:
> But the question has become pretty much academic anyway, given that 
> Chris has already announced that he will be addressing the issue himself.

I've made a change that pulls all the 'using namespace std' and 'using
namespace boost' out of the source, in favor of a few more specific
declarations in one header file (appropriately commented as to why):

  using std::string;
  using std::vector;
  using std::list;
  using std::runtime_error;
  using boost::shared_ptr;

since these are the most often used, scattered in many places throughout
the POV code. all other references to stdlib or boost classes are now
qualified or limited in scope to a single file. I wanted to do something
along these lines for a while anyhow, since I do think it's cleaner than
pulling in all of std (you may notice that in the code I checked in for
e.g. the shellouts the other week I was preferring qualifiers rather than
importing namespaces).

of course this doesn't fix the problem with VS 2010, because some of its
header files refer to std::tr1::shared_ptr, so unless we go to the trouble
of explicitly qualifying shared_ptr everywhere we use it (and then have to
change that if we ever decide to use the tr1 version instead), it's still
not going to compile.

if C++ supported template typedefs we could fix it more cleanly that way,
but currently that's not yet the case. we could alternatively use the
struct rebind workaround, but I'm not sure that's any better than just
appending boost:: everywhere (though at least if we do go tr1 we only
change it in one place).

I'll probably fix it eventually as I'd like to see it work with compilers
that have tr1. do you have any opinion regards the typedef struct
workaround vs explicit scoping option?

-- Chris

Post a reply to this message