cout vs std::cout

[Mark Casternoff]

I'm getting back into C++ after a long hiatus (they didn't have
namespaces back then).

I know this question is completely subjective, but I'd be interested in
hearing which is
the "better" style and what the pros and cons are (I'm using cout as
example, but it really
applies to any similar construct):

1) using std::cout;
cout << "This is a test";

2) std::cout << "This is a test";

The difference being prefixing every cout with 'std' or declaring it
ahead of time. The second
method could be used if cout existed in more than one spot, but how
often is that an issue?

I've seen both methods in code, but I'm seeing #2 a lot more frequently.

[blargg]

In article <2008092815231175249-mac@foobarnetorg>, Mark Casternoff
<ma*@foobarnet.orgwrote:

I know this question is completely subjective, but I'd be
interested in hearing which is the "better" style and what the pros
and cons are (I'm using cout as example, but it really applies to
any similar construct):

1) using std::cout;
cout << "This is a test";

2) std::cout << "This is a test";

Code written using #1 is more interdependent, since the cout line depends
on there being a using line earlier. On the other hand, it can be more
readable. Use of "using" in source files is mostly a style issue. Use of
#1 in header files is generally a bad idea, especially at global scope;
use #2 in header files unless you have a good reason not to.

[Matthias Buelow]

Mark Casternoff wrote:

I've seen both methods in code, but I'm seeing #2 a lot more frequently.

It's because many C++ programmers prefer long-winded bureaucracy over
conciseness or even (shock!) simplicity. :) Why do you think the STL is
like it is?
I've never heard a good reason why one shouldn't do a "using namespace
std;" at the beginning of every compilation unit. Maybe there're some
special cases where it might cause problems but usually not using that
is rather nonsensical, imho. The std:: is just clutter and that's
usually bad in a program.

[Jeff Schwab]

Mark Casternoff wrote:

I'm getting back into C++ after a long hiatus (they didn't have
namespaces back then).

I know this question is completely subjective, but I'd be interested in
hearing which is
the "better" style and what the pros and cons are (I'm using cout as
example, but it really
applies to any similar construct):

1) using std::cout;
cout << "This is a test";

2) std::cout << "This is a test";

The difference being prefixing every cout with 'std' or declaring it
ahead of time. The second
method could be used if cout existed in more than one spot, but how
often is that an issue?

I've seen both methods in code, but I'm seeing #2 a lot more frequently.

#1 for the case you've shown here, but #2 for functions, to give Koenig
lookup a chance. One of Scott Meyer's Effective {C++,STL} books has an
item on this. For longish implementation files, I'll sometimes put a
bunch of

using some_namespace::some_type;

near the top of the file. There's nothing wrong with using-declarations
("using std::cout;"), but using-directives ("using namespace whatever;")
can lead to weird problems (like potential name clashes whenever a new
name is added to the used namespace), and using-directives at global
scope in header files are just evil.

[Rolf Magnus]

Stefan Ram wrote:

Mark Casternoff <ma*@foobarnet.orgwrites:

>>1) using std::cout;
cout << "This is a test";
2) std::cout << "This is a test";

I believe the majority of programmers is using style 1.

I prefer style 2, precisely, I prefer:

::std::cout << "alpha";

Reasons:

This code segment has a context-independent meaning
to the maximum extend possible by such a segment:

It can be copied from one source file to another
without the need to copy a using declaration, too.

Well, you need to copy the #includes too.

It can even be copied into

namespace example { namespace std {} void example(){ ... }}

and still retain its meaning.

I've never seen that anyone added his own namespace std somewhere. It would
be quite odd, so I don't see why I should attempt to protect against such a
case.

ISO/IEC 14882:2003(E) is using »::std« once,
»static ::std::locale::id« in 22.1.1.1.2.p1.

Once isn't really that often. How often does it not use that?

A disadvantage of explicitly qualifying with ::std or even with std is that
it makes it hard to create your own cout and replace all uses of the
standard cout with this one. If you have a

using std::cout;

cout << "Hello world\n";

you can simply replace the using declaration and you're done instead of
changing every single occurance of cout in your code.
And yes, I actually had a case where I wanted to exchange std::cout with my
own one. It was a microcontroller device with quite limited resources, so I
wanted to have something that behaves similar to cout, but provides only a
limited subset of the functionality to save resources.

[Yannick Tremblay]

In article <6k************@mid.dfncis.de>,
Matthias Buelow <mk*@incubus.dewrote:

>Mark Casternoff wrote:

>I've seen both methods in code, but I'm seeing #2 a lot more frequently.

It's because many C++ programmers prefer long-winded bureaucracy over
conciseness or even (shock!) simplicity. :) Why do you think the STL is
like it is?
I've never heard a good reason why one shouldn't do a "using namespace
std;" at the beginning of every compilation unit. Maybe there're some
special cases where it might cause problems but usually not using that
is rather nonsensical, imho. The std:: is just clutter and that's
usually bad in a program.

The std:: namespace contains an awful lot of identifiers that use very
simple common words.

If you remove std:: namespace an put everything global, the following
becomes very undesirable since you would have trouble figuring out
which "map"

namespace DoraTheExplorer
{
class map
{
//
};

}
//////////////////
#include "Dora.h"
#include <map>

using namespace std; // or remove std:: altogether
using namespace DoraTheExplorer;

int main()
{
map theMap; // should this compile or error
// due to missing template arguments?
}

[Matthias Buelow]

Yannick Tremblay wrote:

using namespace std; // or remove std:: altogether
using namespace DoraTheExplorer;

....^ here

int main()
{
map theMap; // should this compile or error
// due to missing template arguments?

It should wail about symbol collision...^

Dunno if it does (too lazy^Wbusy to check now), b0rk3d as C++ is, it
probably doesn't.

[Yannick Tremblay]

In article <6k************@mid.dfncis.de>,
Matthias Buelow <mk*@incubus.dewrote:

>Yannick Tremblay wrote:

>using namespace std; // or remove std:: altogether
using namespace DoraTheExplorer;

...^ here

>int main()
{
map theMap; // should this compile or error
// due to missing template arguments?

It should wail about symbol collision...^

Dunno if it does (too lazy^Wbusy to check now), b0rk3d as C++ is, it
probably doesn't.

Either of the three possible outcomes are undesirable.

I like to write my code the way it feels natural. Words like "find"
"sort" "map" "list" "pair", etc are likely to be used. Widening the
range of reserved identifiers/symbols to everything contained in the
C++ standard library steal from me a lot of possible identifiers I
might have liked to use and force me to use less natural words for
these which might make the code less clear, less readable, more bug
prone and harder to maintain. Worse: I might not even know that a
word is reserved by the standard library. I am pretty much able to
remember not to use the C++ reserved keywords (albeit I keep trying to
use "default":-( but pulling the whole standard library in the global
namespace hugely increases the list of reserved words that I am not
allowed to use. I don't want it.

If I write "using namespace std;" at the top of a file, I know that I
am pulling all that in the global namespace but the key is that I
choose to do it. I am perfectly allowed to use "map" for my own
purpose if I don't do "using namespace std;"

So personally, I do not find the std:: namespace a clutter but a very
useful tool.

Yan

[Hendrik Schober]

Yannick Tremblay wrote:

In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>Yannick Tremblay wrote:

>>[Ridiculous example deleted]

No. The next project introduced its string utilities
in a namespace 'Strings'.

But the point remains that "Strings" is less clear than "StringUtility".

In this particular case, the loss of clarity is probably acceptable
but that virtual ban on namespaces is IMO a bad thing because I
think it encourages bad naming.

Which ban?

Yannick

Schobi

[Hendrik Schober]

Rolf Magnus wrote:

[...]
A disadvantage of explicitly qualifying with ::std or even with std is that
it makes it hard to create your own cout and replace all uses of the
standard cout with this one. If you have a

using std::cout;

cout << "Hello world\n";

What about
std::ostream& mine = std::cout;
then? This allows to redefine 'mine' later and doesn't
need to have 'std::' removed from 'cout'. Or am I missing
something?

[...]

Schobi

[Hendrik Schober]

Matthias Buelow wrote:

Mark Casternoff wrote:

>I've seen both methods in code, but I'm seeing #2 a lot more frequently.

It's because many C++ programmers prefer long-winded bureaucracy over
conciseness or even (shock!) simplicity. :) Why do you think the STL is
like it is?

The STL is like /what/?

I've never heard a good reason why one shouldn't do a "using namespace
std;" at the beginning of every compilation unit.

You mean except for the fact that it might silently make your
code fail at run-time?

Maybe there're some
special cases where it might cause problems but usually not using that
is rather nonsensical, imho. The std:: is just clutter and that's
usually bad in a program.

So are static types. Let's get rid of them.

Schobi

[Matthias Buelow]

Hendrik Schober wrote:

So are static types. Let's get rid of them.

Yes, please.

[Juha Nieminen]

Matthias Buelow wrote:

It's because many C++ programmers prefer long-winded bureaucracy over
conciseness or even (shock!) simplicity. :)

Some programmers prefer clarity over conciseness. The simplicity of
the code is not changed either way.

I really don't understand the obsession some people (especially
beginners) have about writing code which is as short as possible. Of
course this doesn't mean you should prefer the opposite either, but too
concise == obfuscated.

Do you name all your variables with one single character, and when you
run out of the a-zA-Z characters do you start using to-character
variables? Or do you prefer naming your variables *descriptively*
regardless of how long they become? This is a perfect example where
concise code only leads to obfuscated code which is hard to read and
understand.

When you use the "std::" prefix you are self-documenting the code: You
are telling the reader what kind of function/type that is (a standard
one) and where its definition can be found (in the standard libraries).
For example, if I see this in some random code:

generate(v.begin(), v.end(), foo);

it's not immediately obvious what this "generate" function is. Is it a
function defined in the same program somewhere? However, if I see this:

std::generate(v.begin(), v.end(), foo);

then there just is absolutely no confusion at all. I *immediately* see
that this is a function from the C++ standard library. Even if I had
never even heard of the "std::generate" function, I would still
immediately know where to look for it.

In this case the "std::" prefix made a remarkable difference in
clarity and readability: It made it enormously easier to understand
what's going on (ie. a standard C++ library function is being called,
rather than some program-specific function defined somewhere).

As an added bonus you might avoid name collisions better by leaving
namespaces as they are.

The std:: is just clutter and that's usually bad in a program.

"Just clutter" which makes the code more readable and easier to
understand. Yeah, sure.

I prefer this "clutter" any day over concise code which nobody but the
author can read fluently (and even him only for a couple of weeks after
he wrote it).

[Juha Nieminen]

Mark Casternoff wrote:

1) using std::cout;
cout << "This is a test";

2) std::cout << "This is a test";

Let me ask you a question: What did you gain in #1 that made it worth
the "using" line?

Did you gain in code clarity? Is #1 clearer code than #2? Would you
have a harder time understanding #2 than #1?

In fact, I would argue that #2 results in clearer and easier to
understand code. I already posted this example in this thread, but let
me repeat it here. If you see this line in a random piece of long code:

generate(v.begin(), v.end(), foo);

what does that tell you? Is this "generate" function some function
defined elsewhere in the code? Or is it a standard function? Maybe it's
both? How can you know? You can't know unless you examine large amounts
of the program source code or documentation (although some interactive
compilers might make this task easier).

However, assume you instead see this:

std::generate(v.begin(), v.end(), foo);

Now there's absolutely no confusion: "generate" is a function in the
standard C++ library. Even if you have never even heard about this
function, you immediately know where to look for it. You don't have to
try to guess anything.

In this case the "std::" prefix made the code a lot more easier to
understand. Why some people consider this a bad thing is something I
will never understand.

[Matthias Buelow]

Juha Nieminen wrote:

In this case the "std::" prefix made the code a lot more easier to
understand. Why some people consider this a bad thing is something I
will never understand.

The problem exists on a different abstraction layer. Do you want having
to specially mark everything that isn't in the user program space in
fear of collision? I certainly don't since that turns programs really
ugly for little to no gain.

[Juha Nieminen]

Matthias Buelow wrote:

Juha Nieminen wrote:

> In this case the "std::" prefix made the code a lot more easier to
understand. Why some people consider this a bad thing is something I
will never understand.

The problem exists on a different abstraction layer. Do you want having
to specially mark everything that isn't in the user program space in
fear of collision? I certainly don't since that turns programs really
ugly for little to no gain.

I never use the "using" keyword to get rid of a namespace, and I have
never found the program becoming "ugly". On the contrary, when you get
used to reading the namespace prefixes, the effect is the opposite: The
program becomes clearer and easier to read.

Exactly what do you find "ugly" in the namespace prefixes? The two ':'
symbols? Come on, please.

[Matthias Buelow]

Juha Nieminen wrote:

Exactly what do you find "ugly" in the namespace prefixes? The two ':'
symbols? Come on, please.

The entire prefix is visually unappealing (although not really that much
of an eye-catcher in a C++ program) but more important is the fact that
I have to provide more detail than necessary, which is especially
obtrusive in a local context.

[Rolf Magnus]

Hendrik Schober wrote:

Rolf Magnus wrote:

>[...]
A disadvantage of explicitly qualifying with ::std or even with std is
that it makes it hard to create your own cout and replace all uses of the
standard cout with this one. If you have a

using std::cout;

cout << "Hello world\n";

What about
std::ostream& mine = std::cout;
then?
This allows to redefine 'mine' later and doesn't
need to have 'std::' removed from 'cout'. Or am I missing
something?

That would work, too - if you wrote your whole program with that in mind and
only use libraries where this is done too.

[Vidar Hasfjord]

On Sep 29, 6:36*pm, Juha Nieminen <[e-mail]:

Mark Casternoff wrote:

1) * using std::cout;
* * * cout << "This is a test";

2) *std::cout << "This is a test";

[...] Why some people consider this a bad thing is something I

will never understand.

Actually, I prefer to be more explicit. Don't assume you (the writer)
or the reader (reviewer) understand the context, that that the
compiler is on your side and that the code is interpreted according to
your intentions.

3) static_cast <void((*static_cast <::std::ostream& (*)
(::std::ostream&, const char*)(&::std::operator <<)) (::std::cout,
const_cast <const char*("This is a test")));

Here I explicitly state the full qualified names of any entity. I
explicitly select the operator overload I want. I also always
explicitly state the type of a string literal to foil that evil
implicit const char [] to char* conversion. I also explicitly state
that I am not interested in the the returned value by casting to void.
Don't leave anything to be inferred.

Actually 3) is a little simplified. My code usually is char/w_char
agnostic. So each string literal is further wrapped up in macros. But
I thought I should keep it simple and clear as mud here.

Regards,
Vidar Hasfjord

[Juha Nieminen]

Matthias Buelow wrote:

Juha Nieminen wrote:

> Exactly what do you find "ugly" in the namespace prefixes? The two ':'
symbols? Come on, please.

The entire prefix is visually unappealing

Yeah, I see how visual beauty is such an important concept in programming.

OTOH some programmers prefer clarity over beauty.

but more important is the fact that
I have to provide more detail than necessary, which is especially
obtrusive in a local context.

Oh, sheesh! Writing self-documenting easy-to-understand code really is
such a PitA. Stupid language standardization committees trying to force
us to write code that someone can actually read and understand.

Do you also make completely uncommented code? Because, you know, it's
way more detail than necessary. And of course you use the 1-character
variable and function names wherever possible, and switch to 2-character
ones when you run out of names (you didn't answer my earlier question on
this, so I have to assume a "yes"). And indentation? Who needs
indentation? That's just a waste of space. Why waste good disk space on
completely unnecessary characters?

I bet you are a huge fan of the IOCCC. Maybe you have participated?

[Juha Nieminen]

Vidar Hasfjord wrote:

On Sep 29, 6:36 pm, Juha Nieminen <[e-mail]:

>Mark Casternoff wrote:

>>1) using std::cout;
cout << "This is a test";
2) std::cout << "This is a test";

[...] Why some people consider this a bad thing is something I

will never understand.

Actually, I prefer to be more explicit. Don't assume you (the writer)
or the reader (reviewer) understand the context, that that the
compiler is on your side and that the code is interpreted according to
your intentions.

3) static_cast <void((*static_cast <::std::ostream& (*)
(::std::ostream&, const char*)(&::std::operator <<)) (::std::cout,
const_cast <const char*("This is a test")));

I really don't understand the point of your sarcasm. Are you seriously
insinuating that "std::cout" is hard to read and understand?

If that's the case, then I suppose we'll simply have to disagree.

[Vidar Hasfjord]

On Sep 29, 10:07*pm, Juha Nieminen <[e-mail]:

Vidar Hasfjord wrote:
* I really don't understand the point of your sarcasm.

Sorry, I didn't mean to offend.

Are you seriously insinuating that "std::cout" is hard to read and understand?

No. I just reacted to your statement that you "will never understand"
why someone will not prefer this style.

I find it easy to understand both styles. It is just a matter of how
comfortable you are to rely on inference; i.e. context and lookup
rules.

My attempted humor was to show the logical extreme of not relying on
any implicit meaning; lookup or otherwise.

Personally I use both 'using statements' and 'using declarations' in
my code; although never in headers, of course. I find it keeps my code
concise, and it has never caused me any problems in my many years as a
C++ programmer. When name conflicts have occurred it has been fairly
trivial to disambiguate; i.e. qualify where needed. In the few places
of my code where name lookup may be subtle and tricky, i.e. inside
generic template code, I fully qualify names.

In general, I think brevity is a nice feature of code as long as it
doesn't contribute to obscurity. I especially look forward to type
inference in C++0x:

::std::vector <int>::iterator i = v.begin (); // C++03
auto i = v.begin (); // C++0x

Regards,
Vidar Hasfjord

[LR]

Juha Nieminen wrote:

Matthias Buelow wrote:

>Juha Nieminen wrote:

>> Exactly what do you find "ugly" in the namespace prefixes? The two ':'
symbols? Come on, please.

The entire prefix is visually unappealing

Yeah, I see how visual beauty is such an important concept in programming.

I think it is. Someone elsethread might have mentioned http://www.ioccc.org/

>
OTOH some programmers prefer clarity over beauty.

Clarity is beauty. Isn't it?
Just thought I'd put in my $0.02. Years ago, before the compiler I was
using supported namespaces or the STL, I developed a library that had a
function called fill. When namespaces and the STL became supported the
thought of having to rewrite all that code to add, what was then
perceived of by the group I was working with as that annoying std::, led
us to using namespace std; and the inevitable consequence. Hilarity did
not ensue, but a rewrite of the code to remove the using namespace and
to add std:: to every std:: library name or function as appropriate did.

Now when I develop new code, almost all of it goes in some namespace.
Easier to read. Nicer to look at. Clarity is beauty.

It's just like, to pick a related topic, const,

void some_namespace::somefunc(const a_namespace::Mytype &variable) {

const int localvar = variable.method();

... more lines...

// localvar gets used here maybe like and I can quickly
// figure out that localvar shouldn't have changed values
// and won't here either.
const a_namespace::SomeType t = variable.method(localvar);

}

gets to be much easier to read, and while blearily debugging at 04:30,
easier to figure out too.

OTOH, I suspect doing adding clarity to the code might lead to less
debugging.

Perhaps one day I will be smarter and write perfect code. In the
meantime anything that leads to making the code easier to read and less
debugging is beautiful. IMHO.

LR

[James Kanze]

On Sep 29, 5:35 am, Rolf Magnus <[e-mail]:

[...]

A disadvantage of explicitly qualifying with ::std or even
with std is that it makes it hard to create your own cout and
replace all uses of the standard cout with this one.

I'd say just the opposite. A global search and replace on
\<std::cout\will work just fine. A global search and replace
on \<cout\will change not only the cout in std, but any other
cout you happen to have as well. (And of course, if it's
something special, you probably want to call it something other
than cout anyway.)

If you have a

using std::cout;

cout << "Hello world\n";

you can simply replace the using declaration and you're done
instead of changing every single occurance of cout in your
code.

The problem with this is that it fools the reader. If you see
cout, and you know that the programmer often makes use of using
declarations, you'll just assume that it's std::cout. If you
see std::cout, you know it's std::cout, and if you see
MyNamespace::cout, you know it isn't.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 29, 8:36 pm, Rolf Magnus <[e-mail]:

Hendrik Schober wrote:

Rolf Magnus wrote:

[...]
A disadvantage of explicitly qualifying with ::std or even
with std is that it makes it hard to create your own cout
and replace all uses of the standard cout with this one. If
you have a

using std::cout;

cout << "Hello world\n";

What about
std::ostream& mine = std::cout;
then?
This allows to redefine 'mine' later and doesn't
need to have 'std::' removed from 'cout'. Or am I missing
something?

That would work, too - if you wrote your whole program with
that in mind and only use libraries where this is done too.

Libraries shouldn't ever write to std::cout.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 29, 8:30 pm, Matthias Buelow <[e-mail]:

Juha Nieminen wrote:

Exactly what do you find "ugly" in the namespace prefixes?
The two ':' symbols? Come on, please.

The entire prefix is visually unappealing (although not really
that much of an eye-catcher in a C++ program) but more
important is the fact that I have to provide more detail than
necessary, which is especially obtrusive in a local context.

What do you mean exactly by "a local context"? One general rule
I've seen is that the length of entity names should be inversely
proportional to their scope: things like i and j are fine for
local, loop control variables, but don't cut it for program wide
globals. Standard out and standard in are program wide globals,
and even std::cout and std::cin are really too short and too
concise for them. (Of course, std::cin and std::cout are bad
examples, since you almost never use them anyway. Consider
std::ostream and std::istream, rather.)

More generally, I can buy the argument that if a given function
is going to use the same entity many times in a small area (and
any given function should be small enough so that its entire
body is a "small area"), then some sort of abbreviation, with
the declaration for the abbreviation at the top of the block, is
acceptable. I can't think of any really good examples involving
IO, but to take Juha's example, if you have a 10 line function
that invokes std::replace in 5 different places, I'd see nothing
objectionable to a:
using std::replace ;
at the top of the function. I'll also use such declarations
when writing unit tests for the class.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Hendrik Schober]

Rolf Magnus wrote:

Hendrik Schober wrote:

>Rolf Magnus wrote:

>>[...]
A disadvantage of explicitly qualifying with ::std or even with std is
that it makes it hard to create your own cout and replace all uses of the
standard cout with this one. If you have a

using std::cout;

cout << "Hello world\n";

What about
std::ostream& mine = std::cout;
then?
This allows to redefine 'mine' later and doesn't
need to have 'std::' removed from 'cout'. Or am I missing
something?

That would work, too - if you wrote your whole program with that in mind and
only use libraries where this is done too.

Well, in your case you have to use libraries which
adhere to some other convention ('using std::cout')
as well. (To me it seems that a lib that writes to
'std::cout' instead of a user-provided stream is in
need of an overhaul.)

Schobi

[Hendrik Schober]

Matthias Buelow wrote:

Hendrik Schober wrote:

> So are static types. Let's get rid of them.

Yes, please.

What are you doing in c.lc++?

Schobi

[Hendrik Schober]

Juha Nieminen wrote:

Matthias Buelow wrote:

>It's because many C++ programmers prefer long-winded bureaucracy over
conciseness or even (shock!) simplicity. :)

Some programmers prefer clarity over conciseness. The simplicity of
the code is not changed either way.

I really don't understand the obsession some people (especially
beginners) have about writing code which is as short as possible. [...]

I think it comes from the assumption that the time you
need to write code matters more than the time you need
to read and understand it.
This assumption, however, is wrong.

Schobi

[Gennaro Prota]

James Kanze wrote:

What do you mean exactly by "a local context"? One general rule
I've seen is that the length of entity names should be inversely
proportional to their scope

"Directly", you mean :-)

[snip]

but to take Juha's example, if you have a 10 line function
that invokes std::replace in 5 different places, I'd see nothing
objectionable to a:
using std::replace ;
at the top of the function. I'll also use such declarations
when writing unit tests for the class.

Could you please elaborate on this latter sentence?

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

[Matthias Buelow]

Hendrik Schober wrote:

>> So are static types. Let's get rid of them.

Yes, please.

What are you doing in c.lc++?

I read this newsgroup (and occasionally post to it) because I use C++
professionally; this doesn't mean I have to like it (in fact, I hate
it), clc++ isn't a fan club, is it?

[Rui Maciel]

On Tue, 30 Sep 2008 11:23:08 +0200, Hendrik Schober wrote:

I think it comes from the assumption that the time you need to write
code matters more than the time you need to read and understand it.
This assumption, however, is wrong.

Indeed. I don't believe that anyone who has any relevant experience
writing code is yet to develop their typing skills. Even if that was the
case, virtually any text editor, let alone any IDE, comes with some sort
of code completion feature.
Rui Maciel

[Rui Maciel]

On Tue, 30 Sep 2008 11:11:39 +0200, Hendrik Schober wrote:

What are you doing in c.lc++?

Mainly trolling, I suppose.
Rui Maciel

[Yannick Tremblay]

In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>Yannick Tremblay wrote:

>In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>>Yannick Tremblay wrote:
[Ridiculous example deleted]
No. The next project introduced its string utilities
in a namespace 'Strings'.

But the point remains that "Strings" is less clear than "StringUtility".

In this particular case, the loss of clarity is probably acceptable
but that virtual ban on namespaces is IMO a bad thing because I
think it encourages bad naming.

Which ban?

I did write *virtual* ban but sorry, I mean virtual ban of "using
namespace" not on "namespace" themselves.

The exact quote was:
"Most of the time I worked under the rule that using declarations (and
even using directives!) where allowed within any local scopes not
bigger than a function,"

IMO, this amount to a virtual ban. given that function scopes should
hopefully average less than 20 line and that in these 10-20 lines, you
are unlikely to use things from a particular namespace more than 3-5
times, then typing "using namespace String;" takes about as much
typing effort as 3 explicit String::. May almost as well ban them.
Obviously, then might become somewhat useful in 200 liners functions
but of course these should already have been banned well before the
restrictions on "using" was written :-)

Yannick

[LR]

James Kanze wrote:

On Sep 29, 5:35 am, Rolf Magnus <[e-mail]:

[...]

>A disadvantage of explicitly qualifying with ::std or even
with std is that it makes it hard to create your own cout and
replace all uses of the standard cout with this one.

I'd say just the opposite. A global search and replace on
\<std::cout\will work just fine. A global search and replace
on \<cout\will change not only the cout in std, but any other
cout you happen to have as well. (And of course, if it's
something special, you probably want to call it something other
than cout anyway.)

>If you have a

>using std::cout;

>cout << "Hello world\n";

>you can simply replace the using declaration and you're done
instead of changing every single occurance of cout in your
code.

The problem with this is that it fools the reader. If you see
cout, and you know that the programmer often makes use of using
declarations, you'll just assume that it's std::cout. If you
see std::cout, you know it's std::cout, and if you see
MyNamespace::cout, you know it isn't.

Sometimes, because of the environment I use I find this little snippet
useful:

namespace non_std { // or whatever namespace you'd like
std::ostream &cout = std::cout;
}

And in other code...
non_std::cout << "something" << std::endl;

When I don't want to write to std::cout for some reason, it's pretty
easy to change non_std::cout to refer to some other stream.

I do have to pay attention to what non_std::cout is.

LR

[Juha Nieminen]

James Kanze wrote:

I can't think of any really good examples involving
IO, but to take Juha's example, if you have a 10 line function
that invokes std::replace in 5 different places, I'd see nothing
objectionable to a:
using std::replace ;
at the top of the function.

So you write 19 characters (plus indentation plus a newline) to save
25 characters, for a total net saving of 6 characters (and only if we
don't count the indentation whitespaces and newline).

I really don't see the point.

[James Kanze]

On Sep 30, 1:05 pm, Gennaro Prota <gennaro/[e-mail]:

James Kanze wrote:

What do you mean exactly by "a local context"? One general
rule I've seen is that the length of entity names should be
inversely proportional to their scope

"Directly", you mean :-)

Yes.

[snip]

but to take Juha's example, if you have a 10 line function
that invokes std::replace in 5 different places, I'd see nothing
objectionable to a:
using std::replace ;
at the top of the function. I'll also use such declarations
when writing unit tests for the class.

Could you please elaborate on this latter sentence?

Well, my test code tends to be a lot different from normal code.
To begin with, it often contains very long functions, which are
just a linear succession of tests. And if I'm writing a test
suite for a class in a nested namespace, that class is very much
the center of attention of the test (which is never the case
otherwise). So I don't mind something like "using
Outer::Innter::ClassBeingTested" at the top of the function, or
even in the test header (which specifies the harness for this
particular class). It's a special case.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 30, 6:19 pm, Juha Nieminen <[e-mail]:

James Kanze wrote:

I can't think of any really good examples involving
IO, but to take Juha's example, if you have a 10 line function
that invokes std::replace in 5 different places, I'd see nothing
objectionable to a:
using std::replace ;
at the top of the function.

So you write 19 characters (plus indentation plus a newline)
to save 25 characters, for a total net saving of 6 characters
(and only if we don't count the indentation whitespaces and
newline).

So I write one line which makes each of the following lines
shorter. One line which might make the difference between
having to break an expression into two lines or not (because my
coding guidelines don't allow lines longer than 80 characters).

The case doesn't occur very often, but it does occur. And given
the length of my functions, the using declaration is never very
far from the actual use, and always in clear view.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

James Kanze wrote:

So I write one line which makes each of the following lines
shorter. One line which might make the difference between
having to break an expression into two lines or not (because my
coding guidelines don't allow lines longer than 80 characters).

If a code line is so long that it exceeds 80 characters, in my opinion
it *should* be broken into several lines.

(Nitpicking: Does your coding guidelines allow you to write lines
which are *exactly* 80 characters? Does the newline at the end count as
a character?)

[Hendrik Schober]

Yannick Tremblay wrote:

In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>Yannick Tremblay wrote:

>>In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:
Yannick Tremblay wrote:
[Ridiculous example deleted]
No. The next project introduced its string utilities
in a namespace 'Strings'.
But the point remains that "Strings" is less clear than "StringUtility".

In this particular case, the loss of clarity is probably acceptable
but that virtual ban on namespaces is IMO a bad thing because I
think it encourages bad naming.

Which ban?

I did write *virtual* ban but sorry, I mean virtual ban of "using
namespace" not on "namespace" themselves.

The exact quote was:
"Most of the time I worked under the rule that using declarations (and
even using directives!) where allowed within any local scopes not
bigger than a function,"

IMO, this amount to a virtual ban. [...]

<shrug>
It's what usually all developers agreed on in those projects.
It only encourages bad naming when you're afraid of typing
(or whatever it is that makes people obsessed with writing the
fewest possible characters.)

Yannick

Schobi

[Hendrik Schober]

Matthias Buelow wrote:

Hendrik Schober wrote:

>>> So are static types. Let's get rid of them.
Yes, please.

What are you doing in c.lc++?

I read this newsgroup (and occasionally post to it) because I use C++
professionally; this doesn't mean I have to like it (in fact, I hate
it), clc++ isn't a fan club, is it?

Well, that does make your statements in this thread
appear in a very different light then.

Schobi

[Hendrik Schober]

Juha Nieminen wrote:

James Kanze wrote:

>So I write one line which makes each of the following lines
shorter. One line which might make the difference between
having to break an expression into two lines or not (because my
coding guidelines don't allow lines longer than 80 characters).

This is the only reason I ever used using declarations.

If a code line is so long that it exceeds 80 characters, in my opinion
it *should* be broken into several lines.

Sometimes this hinders readability more than many other
things could.

Schobi

[James Kanze]

On Oct 1, 4:33 pm, Juha Nieminen <[e-mail]:

James Kanze wrote:

So I write one line which makes each of the following lines
shorter. One line which might make the difference between
having to break an expression into two lines or not (because my
coding guidelines don't allow lines longer than 80 characters).

If a code line is so long that it exceeds 80 characters, in my opinion
it *should* be broken into several lines.

(Nitpicking: Does your coding guidelines allow you to write lines
which are *exactly* 80 characters? Does the newline at the end count as
a character?)

The rule is that the line shouldn't wrap if displayed in a
window 80 characters wide. So it depends on the program being
used to look at the code:-). Seriously, I usually like to leave
a couple of characters margin, just in case.

In the company where I was before, they used nested namespaces,
with names of typically between ten and twenty characters. A
simple using declaration at the top of the function could cut
the number of lines in it in half. In my present code, I'm
using fairly short names for namespaces, and not nested too
deaply. I have something like 50 using declarations in
something like 150 KLoc. And some of those are 'using
namespace' at file scope---we had some problems with anonymous
namespaces at one time, and I occasionally emulate them with
something like 'namespace filename_private { /*...*/ } using
namespace filename_private;'. (I've also a couple of cases
where I do this in a header---logically, it's an anonymous
namespace, but used by several implementation files.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 1, 9:15 pm, Hendrik Schober <[e-mail]:

Juha Nieminen wrote:

James Kanze wrote:

So I write one line which makes each of the following lines
shorter. One line which might make the difference between
having to break an expression into two lines or not (because my
coding guidelines don't allow lines longer than 80 characters).

This is the only reason I ever used using declarations.

If a code line is so long that it exceeds 80 characters, in my opinion
it *should* be broken into several lines.

Sometimes this hinders readability more than many other
things could.

Not if the tool you're using to look at the code truncates the
line at 80 characters:-).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Hendrik Schober]

James Kanze wrote:

On Oct 1, 9:15 pm, Hendrik Schober <[e-mail]:

>Juha Nieminen wrote:

>>James Kanze wrote:
So I write one line which makes each of the following lines
shorter. One line which might make the difference between
having to break an expression into two lines or not (because my
coding guidelines don't allow lines longer than 80 characters).

> This is the only reason I ever used using declarations.

>> If a code line is so long that it exceeds 80 characters, in my opinion
it *should* be broken into several lines.

> Sometimes this hinders readability more than many other
things could.

Not if the tool you're using to look at the code truncates the
line at 80 characters:-).

What I meant is, being able to shorten the line is
sometimes better than breaking it.

Schobi

[Yannick Tremblay]

In article <gc**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>Yannick Tremblay wrote:

>In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>>Yannick Tremblay wrote:
In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:
Yannick Tremblay wrote:
>[Ridiculous example deleted]
No. The next project introduced its string utilities
in a namespace 'Strings'.
But the point remains that "Strings" is less clear than "StringUtility".

In this particular case, the loss of clarity is probably acceptable
but that virtual ban on namespaces is IMO a bad thing because I
think it encourages bad naming.
Which ban?

I did write *virtual* ban but sorry, I mean virtual ban of "using
namespace" not on "namespace" themselves.

The exact quote was:
"Most of the time I worked under the rule that using declarations (and
even using directives!) where allowed within any local scopes not
bigger than a function,"

IMO, this amount to a virtual ban. [...]

<shrug>
It's what usually all developers agreed on in those projects.
It only encourages bad naming when you're afraid of typing
(or whatever it is that makes people obsessed with writing the
fewest possible characters.)

But you said it yourself:
"What I've learned, though, is to avoid creating namespaces which are
long and hard to type right even after weeks ('StringUtility') of
usage. :)"

So it did encourage you to use shorter and less informative
identifiers than you initially found appropriate and that you
would have continued using was it not for this IMO dodgy coding
style edict. "String" is a less informative name than
"StringUtility". Why was "StringUtility" origianlly chosen?
Probably because it describes correctly the namespace. Why did you
shorten it to "String"? Because you were bored of typing. Not
because it describes the namespace better, made the code more
readable, more maintainable or anything else.

In this case, "String" might be acceptable but this a only the first
step on a slippery road. Be careful or the namespaces created by
worse programmers than yoursel will start ressembling hungarian
warts.

Yannick

[Hendrik Schober]

Yannick Tremblay wrote:

In article <gc**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:

>Yannick Tremblay wrote:

>>In article <gb**********@cb.generation-online.de>,
Hendrik Schober <sp******@gmx.dewrote:
Yannick Tremblay wrote:

[...]

>>IMO, this amount to a virtual ban. [...]

<shrug>
It's what usually all developers agreed on in those projects.
It only encourages bad naming when you're afraid of typing
(or whatever it is that makes people obsessed with writing the
fewest possible characters.)

But you said it yourself:
"What I've learned, though, is to avoid creating namespaces which are
long and hard to type right even after weeks ('StringUtility') of
usage. :)"

So it did encourage you to use shorter and less informative
identifiers [...]

No. It encouraged to use names that are easier to type.
That doesn't mean they had to be shorter or even less
informative. (But that was when we used an editor that
had no useful typing support. Nowadays probably nobody
would care.)
(Oh, and it was "Strings", not "String". :^)

In this case, "String" might be acceptable but this a only the first
step on a slippery road. Be careful or the namespaces created by
worse programmers than yoursel will start ressembling hungarian
warts.

Don't you think that a bunch of programmers who decide
that they generally want to explicitly spell out every
namespace name for every identifier have a typing pain
threshold high enough to not to shorten names beyond
usability?

Yannick

Schobi

[Yannick Tremblay]

In article <42**********************************@2g2000hsn.go oglegroups.com>,
James Kanze <ja*********@gmail.comwrote:

>On Oct 1, 9:15 pm, Hendrik Schober <[e-mail]:

>Juha Nieminen wrote:

James Kanze wrote:
So I write one line which makes each of the following lines
shorter. One line which might make the difference between
having to break an expression into two lines or not (because my
coding guidelines don't allow lines longer than 80 characters).

> This is the only reason I ever used using declarations.

If a code line is so long that it exceeds 80 characters, in my opinion
it *should* be broken into several lines.

> Sometimes this hinders readability more than many other
things could.

Not if the tool you're using to look at the code truncates the
line at 80 characters:-).

But in that case, where is the problem?
a) The tool you are using to look at the code is inadequate
b) the code is inadequate

Should all code be written to the lowest common denominator or should
a sensible compromise be taken to write at a useful and fairly common
denominator but not necessarily the lowest common one if the lowest
common denominator makes the code worse for above minimal users?

The huge majority will be able to use a code viewing tool that is able
to wrap lines and produce a readable display. So chopping lines to 80
chars then may result in less readable code for the huge majority of
cases while helping only a very small minority?

I once had a programmer tell me that he disliked small files because
it forced him to open more than one file to follow the logic and
lookup a different function. The guy was coding using vi in a
terminal window but making no use whatsoever of tools like ctags and
the vi ctags integration. What should have been the correct answer?
Put guidelines that all modules should consist only of one file so that
Mr-I-Don't-Know-How-To-Use-My-Tools would be conveniently served and
not have to open anymore files but could find his functions by
scrolling or using the '/' or '?' vi command which was maybe the limit
of his knowledge? Or should files be kept small and the
aforementioned be told to either change his tools or learn to use
them?

Yannick

[Jerry Coffin]

In article <gc**********@cb.generation-online.de>, sp******@gmx.de
says...

[ ... ]

Don't you think that a bunch of programmers who decide
that they generally want to explicitly spell out every
namespace name for every identifier have a typing pain
threshold high enough to not to shorten names beyond
usability?

Some of us have a bit of both. In particular, for years I've used
namespace names that were intentionally _very_ long and would be (quite
frankly) ridiculous to type out very often at all. In particular, to
give nearly absolute insurance against namespace clashes, I usually
include my name and the date of creation in the name of the namespace.
For (a real) example: Jerry_Coffin_Julian_Date_Dec_21_1999.

I then, however, use the namespace alias feature to create a short,
easy-to-type alias for that, something like:
namespace Julian = Jerry_Coffin_Julian_Date_Dec_21_1999;

The rest of the code would then use things like Julian::year_day, just
as if the namespace was named Julian.

A namespace alias can also be useful for switching out code when
necessary -- for example, at one time I had some problems with the
implementations of a container or two in the standard library. To fix
the problem I created replacement containers in my own namespace, but
otherwise conforming to the interface for the containers in the standard
library. Again, the namespace in which I put the containers had a long
name that wouldn't be duplicated by accident -- but then I had:

namespace containers = My_Replacement_Container_Namespace_Name;

A few versions of the compiler later, when the compiler vendor had
repaired their library code, I switched over to using that by just
editing that line to read:

namespace containers = std;

As I recall, the editing to fix the code actually took less time than
the re-compilation...

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Hendrik Schober]

Jerry Coffin wrote:

In article <gc**********@cb.generation-online.de>, sp******@gmx.de
says...

[ ... ]

> Don't you think that a bunch of programmers who decide
that they generally want to explicitly spell out every
namespace name for every identifier have a typing pain
threshold high enough to not to shorten names beyond
usability?

Some of us have a bit of both. In particular, for years I've used
namespace names that were intentionally _very_ long and would be (quite
frankly) ridiculous to type out very often at all. In particular, to
give nearly absolute insurance against namespace clashes, I usually
include my name and the date of creation in the name of the namespace.
For (a real) example: Jerry_Coffin_Julian_Date_Dec_21_1999.

I then, however, use the namespace alias feature to create a short,
easy-to-type alias for that, something like:
namespace Julian = Jerry_Coffin_Julian_Date_Dec_21_1999;

The rest of the code would then use things like Julian::year_day, just
as if the namespace was named Julian.

That's a good idea. But for the users of the code, 'Julian'
wasn't really all that different from the ordinary namespaces
we used to use.

A namespace alias can also be useful for switching out code when
necessary -- for example, at one time I had some problems with the
implementations of a container or two in the standard library. To fix
the problem I created replacement containers in my own namespace, but
otherwise conforming to the interface for the containers in the standard
library. Again, the namespace in which I put the containers had a long
name that wouldn't be duplicated by accident -- but then I had:

namespace containers = My_Replacement_Container_Namespace_Name;

A few versions of the compiler later, when the compiler vendor had
repaired their library code, I switched over to using that by just
editing that line to read:

namespace containers = std;

As I recall, the editing to fix the code actually took less time than
the re-compilation...

:)

(Implementing a bunch of std lib containers so that they have
less errors than bought ones isn't something most of us finish
on a sunny Sunday afternoon.)

Schobi