Why do some people hate namespace prefixes?

[Juha Nieminen]

As an avid armchair psychologist, it has always fascinated me why some
people just hate namespace prefixes in C++, and go to great lengths
to avoid them and will rabidly defend this practice, and oppose their
use. No amoung of argumentation will convince them otherwise.

I have literally never, ever, during my entire life (being programming
as a hobby and as my payjob for over 20 years), seen somebody complain
about having to write prefixes when they use some library (eg. some
C library) that has a common prefix in all of its names. Not even
if that prefix is separated from the rest of the name with an
underscore. They don't mind having to write "prefix_name()", but for
some peculiar reason they hate having to write "prefix::name()", and will
get rid of having to do it.

What's the difference?

I don't think the explanation is in the characters themselves. I don't
think '::' is somehow special compared to '_' that would elicit such
a contrarian reaction. So what is it?

I believe that it has to do with the fact that writing the prefix
is *optional* in the case of C++ namespaces. Somehow the notion that
it's optional makes them hate writing it. Whan it's *not* optional,
as in it being part of the name itself (like is the case with many
C libraries), it doesn't trigger the aversion reaction. However, just
the knowledge that it's optional makes them hate having to write it.

I bet that if they didn't know that writing namespace prefixes is
optional, that you can bypass it with a `using` expression, they
would not protest having to write it.

[leigh.v....@googlemail.com]

The answer to your question is irrationality. Alf is irrational. The cause could be a mild mental disorder.

/Leigh

[Alf P. Steinbach]

I gather that that's an effort to connect me to Juha's remarks, and as
such it's dishonest.

I and I guess others value many of your contributions to the group, but
postings like those about sausages, the rabid religious discussions, the
equally rabid swearing, the apparently seriousness of making a universal
compiler, and occasional technical or ad hominem trolling such as now,
detracts from that.


Cheers!,

- Alf

[leigh.v....@googlemail.com]

And when you add all those things (including the posts about sausages) together the result is still less egregious than your C++ coding style, Alf.

/Leigh

[Fred.Zwarts]

"Juha Nieminen" schreef in bericht
news:q96ja6$2l60$1...@adenine.netfront.net...

I won't say that I hate prefixes, sometimes I use them. But I prefer to use
'using', because it makes it easier for me to document where the names come
from.
I group the 'using' expressions in the same order as the #include lines. The
block of #include lines is followed by a few blocks of 'using' declarations.
One block for each #include.
In this way it is easy to see why a particlular #include is needed and also
from which #include the std::name originates.

E.g.:

#include <functional>
#include <exception>
#include <stdexcept>
#include <string>
#include <typeinfo>
#include <vector>


// Import some symbols from the include files.

using std::ref;
using std::reference_wrapper;

using std::exception;

using std::runtime_error;

using std::string;

using std::type_info;

using std::vector;

This shows immediately why <functional> is included.
Another reason, in particular for names that are used very often, is that in
complex expressions 'string' is easier to read than 'std::string', because
it is easier to keep the expressions short.

[leigh.v....@googlemail.com]

On Wednesday, April 17, 2019 at 10:59:27 AM UTC+1, F.Zwarts wrote:
> Another reason, in particular for names that are used very often, is that in
> complex expressions 'string' is easier to read than 'std::string', because
> it is easier to keep the expressions short.

This is a fallacious argument. "std::" is ONLY FIVE EXTRA CHARACTERS. Not using the prefix actually makes things harder not easier to grok as you can't tell at a glance what code is standard and what code is non-standard.

/Leigh

[Ian Collins]

It depends...

Writing std:: isn't particularly burdensome, but if the namespace or
namespaces are long (such as those produced when using Google protpbuf),
a using aids readability.

--
Ian.

[Fred.Zwarts]

schreef in bericht
news:a24842c2-63de-4ff9...@googlegroups.com...

If somebody missed the fact that string is defined in the std:: namespace,
than he is probably a very inexperienced C++ programmer. For most C++
programmers, std:: adds nothing as a prefix to string in terms of
readability.

[leigh.v....@googlemail.com]

Nonsense. These days with the idiom of using `auto` almost everywhere readability shouldn't be an issue and for the few places where we can't use `auto` it is more important than ever to fully qualify.

/Leigh

[Bart]

"std::" is nearly the same length as "string". So half of what you're
trying to see is noise. And while "string" and "vector" are obviously
distinct, "std::string" and "std::vector" are 45% identical by
character, and 66% identical by token.

Imagine if every noun in a piece of writing was prefixed with "eng::" to
tell you it was standard English. It would be a joke.

C++ has enough problems with readability without deliberately making it
worse.

[leigh.v....@googlemail.com]

In your opinion it is made worse; in my opinion and the opinion of others it is made worse by NOT having the prefix.

/Leigh

[Paavo Helde]

On 17.04.2019 10:06, Juha Nieminen wrote:
> As an avid armchair psychologist, it has always fascinated me why some
> people just hate namespace prefixes in C++, and go to great lengths
> to avoid them and will rabidly defend this practice, and oppose their
> use. No amoung of argumentation will convince them otherwise.

The namespaces are specifically designed in the way that they can be
omitted if so desired. This is a feature, not a bug. If people are using
a feature, there is nothing more to say, the feature is there to be used.

Of course, as any other feature this one can be overused or misused as
well. Obviously, omitting namespaces would be bad if it makes the code
harder to read, instead of making it easier.

Alas, the trouble is that what is harder and what is easier heavily
depends on the person reading the code and what he/she is accustomed to.
Somebody with a lot of experience and good memory might immediately
recognize which namespace the names like 'inclusive_scan' or
'greg_month' come from and what they mean, whereas for others this may
be a challenge.

I guess it's the same as with the tab/space issue. Whatever you do you
will never find a variant which would satisfy all people.

[Jorgen Grahn]

On Wed, 2019-04-17, Juha Nieminen wrote:
> As an avid armchair psychologist, it has always fascinated me why some
> people just hate namespace prefixes in C++, and go to great lengths
> to avoid them and will rabidly defend this practice, and oppose their
> use. No amoung of argumentation will convince them otherwise.

I think c.l.c++ posters are atypical C++ users these days. In real
life I've never met anyone who avoids prefixes that way. So in that
sense it's a non-issue ... I try not to worry about it.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Wed, 2019-04-17, Fred.Zwarts wrote:
> schreef in bericht
> news:a24842c2-63de-4ff9...@googlegroups.com...
>>
>>On Wednesday, April 17, 2019 at 10:59:27 AM UTC+1, F.Zwarts wrote:
>>> Another reason, in particular for names that are used very often, is that
>>> in
>>> complex expressions 'string' is easier to read than 'std::string',
>>> because
>>> it is easier to keep the expressions short.
>>
>>This is a fallacious argument. "std::" is ONLY FIVE EXTRA CHARACTERS. Not
>>using the prefix actually makes things harder not easier to grok as you
>>can't tell at a glance what code is standard and what code is non-standard.
>>
>>/Leigh
>
> If somebody missed the fact that string is defined in the std:: namespace,

It's not, not necessarily. I may want to use the name "string"
locally, and don't expect such a name to conflict with the standard
library. Not to mention names like find().

> than he is probably a very inexperienced C++ programmer. For most C++
> programmers, std:: adds nothing as a prefix to string in terms of
> readability.

[Robert Wessel]

While I rarely use "using", I suspect it's more that people dislike
the prefix std:: in particular. There seems to be a lot less
resistance to using it for non-core libraries. There's a least
something of a point there. The considerable proliferation of
"std::"s for those core functions doesn't appear to add much for most
programs.

C and C++ have much of what would be core functionality in other
languages defined in their libraries, so for things like string and
complex std:: arguably adds nothing but clutter.

OTOH, I don't think there's that much objection to requiring it on the
more obscure corners of the library.

[Manfred]

On 4/17/2019 9:06 AM, Juha Nieminen wrote:
> As an avid armchair psychologist, it has always fascinated me why some
> people just hate namespace prefixes in C++, and go to great lengths
> to avoid them and will rabidly defend this practice, and oppose their
> use. No amoung of argumentation will convince them otherwise.
>
> I have literally never, ever, during my entire life (being programming
> as a hobby and as my payjob for over 20 years), seen somebody complain
> about having to write prefixes when they use some library (eg. some
> C library) that has a common prefix in all of its names. Not even
> if that prefix is separated from the rest of the name with an
> underscore. They don't mind having to write "prefix_name()", but for
> some peculiar reason they hate having to write "prefix::name()", and will
> get rid of having to do it.
>
> What's the difference?

No definite answer, obviously, since this is mostly a matter of taste,
and.. de gustibus non disputandum est.

One difference I may see is right as you mention that the namespaces
come with C++ libraries, while it is C libraries that come with
prefixes, which tends to bias the kind of user.
In C naming conventions are far more important that in C++, so for C
programming attention to prefixes is simply good discipline that makes
life easier.

In C++, having scope delimiters like namespaces and classes, the
importance of the single identifier is less critical, which possibly
feeds the aversion you see.

But, FWIW, I don't share such aversion and I easily tend to prefer std::
prefixes to using directives. I think that such a decoration of the name
with its source makes the code tidier.
Even more with third party libraries.

[Juha Nieminen]

Fred.Zwarts <F.Zw...@kvi.nl> wrote:
> Another reason, in particular for names that are used very often, is that in
> complex expressions 'string' is easier to read than 'std::string', because
> it is easier to keep the expressions short.

If you use a C library like for example libpng, most names declared
in that library have the prefix "png_". Do you go your way to create
aliases for those names (eg. using macros of whatever) that have that
prefix removed?

If not, then what's the difference? Why does it not bother you to
have to write a prefix like for example "png_", but it does bother
you to have to write a prefix like for example "std::"?

I'm honestly curious to know.

[Daniel]

On Wednesday, April 17, 2019 at 10:58:03 AM UTC-4, robert...@yahoo.com wrote:
>
> I suspect it's more that people dislike the prefix std::

"std" was a rather uninspired choice as a namespace name, in contrast with
other languages that have well thought out divisions of namespaces, C++
chose to put almost everything into one big garbage dump. Although this does
seem to be changing, with some of the recent additions.

Daniel

[Bonita Montero]

> "std" was a rather uninspired choice as a namespace name, in contrast with
> other languages that have well thought out divisions of namespaces, C++

> chose to put almost everything into one big garbage dump. ...

These languages - like Java - have a much larger standard-library.
And in the case of Java there is also the package-level of member
-access which enforces a finer granular naming of the packages.

[Bonita Montero]

> If you use a C library like for example libpng, most names declared
> in that library have the prefix "png_". Do you go your way to create
> aliases for those names (eg. using macros of whatever) that have that
> prefix removed?

No, because this is inconvenient.
But if there would be png::-prefixes this would be convenient.

[Fred.Zwarts]

"Juha Nieminen" schreef in bericht

news:q97lu2$egu$1...@adenine.netfront.net...

I have not yet encountered such a situation.
I don't like macros, I like the scoping rules of 'using'. (If I use 'using'
in a header file, I never use it at the global :: namespace level, only in
my own namespaces.)
I do not know of an easy replacement of 'using' in the example you mention,
for variables, functions, classes, etc.
I assume that libpng is written in C, where no namespaces are available. If
there would be a simple replacement for 'using' I might consider to use it.
But only if it would be simple enough for the reader of the code to
understand in a blink of an eye the meaning of it.
The complexity of removing prefixes in your example bothers me more than the
prefixes themselves.
The difference with the std:: prefix is, that there is a very simple and
well known method to remove it, designed especially for this case.

[wyn...@gmail.com]

Juha Nieminen於 2019年4月17日星期三 UTC+8下午3時06分59秒寫道：

It's because of, me-thinks, the way people remember/process words.

The advantage(or disadvantage)of prefix is that the object is more
uniquely named. Unlike namespace, every time I see 'string' I have to
look for, even analyse programs to figure-out the right meaning that
name is associated to, from file to file.

Ex:
Mars::wind, Mars::rock
Earth::wind, Earth::rock

When I see 'wind', 'rock', how am I supposed to think with these words?
Mars_wind, Earth_rock would be more clearer.

[Fred.Zwarts]

"Jorgen Grahn" schreef in bericht
news:slrnqbe9ob.4...@frailea.sa.invalid...

>
>On Wed, 2019-04-17, Fred.Zwarts wrote:
>> schreef in bericht
>> news:a24842c2-63de-4ff9...@googlegroups.com...
>>>
>>>On Wednesday, April 17, 2019 at 10:59:27 AM UTC+1, F.Zwarts wrote:
>>>> Another reason, in particular for names that are used very often, is
>>>> that
>>>> in
>>>> complex expressions 'string' is easier to read than 'std::string',
>>>> because
>>>> it is easier to keep the expressions short.
>>>
>>>This is a fallacious argument. "std::" is ONLY FIVE EXTRA CHARACTERS. Not
>>>using the prefix actually makes things harder not easier to grok as you
>>>can't tell at a glance what code is standard and what code is
>>>non-standard.
>>>
>>>/Leigh
>>
>> If somebody missed the fact that string is defined in the std::
>> namespace,
>
>It's not, not necessarily. I may want to use the name "string"
>locally, and don't expect such a name to conflict with the standard
>library. Not to mention names like find().

I don't think it is wise to use such a widely used name as 'string' locally.
The other extreme is that someone may want to use 'std' locally. Then it
would be even more safe to always use ::std:: as a prefix. Some people do.

[Bart]

On Earth, how many times do people talk about Earth-rocks or Earth-wind
to distinguish them from not only Martian rocks and wind, but from any
other planet?

How annoying would it be to have to do that all the time?

(And just to make those terms absolutely unambiguous, would we also have
to prefix them with the the location of this solar system within this
galaxy?)

It is sufficient to use 'rocks' and 'wind' for 99.99% of the time, and
only use the qualifiers when you are actually talking about
extra-terrestrial versions.

[wyn...@gmail.com]

Bart於 2019年4月18日星期四 UTC+8下午5時44分50秒寫道：

What on 'Earth' we are actually talking about and physically live in are
an imaginary programming world.

> How annoying would it be to have to do that all the time?
>
> (And just to make those terms absolutely unambiguous, would we also have
> to prefix them with the the location of this solar system within this
> galaxy?)
>

Ambiguity are more of the problem than annoyance.
We should try to avoid name collision as possible, all the times.

> It is sufficient to use 'rocks' and 'wind' for 99.99% of the time, and
> only use the qualifiers when you are actually talking about
> extra-terrestrial versions.

I will try to eliminate that 0.01% hard-to-find 'bug'

[Öö Tiib]

Why you are using that "string" in complex expressions? Can you bring
example? I use string mostly in super simple contexts like:

using PhoneNumber = std::string;

Meaning of it is that in first sketch std::string can be enough;
but likely there will be a class PhoneNumber later. We may need
operations like PhoneNumber::countryCode() and we may need
a PetName not to be assignable to PhoneNumber. Same is true
with every kind of text values. These have type that in long run
can have more operations and constraints than "basic sequence
of chars". So why to type "std::string" in complex expressions?

[Manfred]

On 4/18/2019 11:44 AM, Bart wrote:
>> Ex:
>> Mars::wind, Mars::rock
>> Earth::wind, Earth::rock
>>
>> When I see 'wind', 'rock', how am I supposed to think with these words?
>> Mars_wind, Earth_rock would be more clearer.
>>
>
> On Earth, how many times do people talk about Earth-rocks or Earth-wind
> to distinguish them from not only Martian rocks and wind, but from any
> other planet?
>
> How annoying would it be to have to do that all the time?

The translated geography of "On Earth" would be "within std", i.e.
inside standard-library code, not application code.

[Juha Nieminen]

Fred.Zwarts <F.Zw...@kvi.nl> wrote:
> I do not know of an easy replacement of 'using' in the example you mention,
> for variables, functions, classes, etc.
> I assume that libpng is written in C, where no namespaces are available. If
> there would be a simple replacement for 'using' I might consider to use it.

Why would you want to? Why would you want to remove the "png_" prefix from
all the names in the library? That would only make your code harder to read
because you can't see anymore where you are calling the libpng library
functions and where you are calling something else.

[Juha Nieminen]

Bart <b...@freeuk.com> wrote:
> It is sufficient to use 'rocks' and 'wind' for 99.99% of the time, and
> only use the qualifiers when you are actually talking about
> extra-terrestrial versions.

Suppose a program is using the Boost library, and you see a stray
"shared_ptr" without a prefix. Which version is it using?

(This is from an actual real-life example, not just an artificially
invented one.)

[Bonita Montero]

> Why would you want to? Why would you want to remove the "png_" prefix from
> all the names in the library? That would only make your code harder to read
> because you can't see anymore where you are calling the libpng library
> functions and where you are calling something else.

If there would be namespaces with libpng and the types / fuctions within
this namespace would be meaningful and not ambigous when stripped, this
could be convenient.
With std:: the types and functins are well known to the deveopers so
there isn't any confusion when std:: is stripped.

[Vir Campestris]

There are those who wish to remove the std:: prefix from all the names
in STL. That's not really different to removing the png_ prefix from all
the names in the PNG library.

I asked this question on the C++ group at work. Early indications are
that people want to keep the std:: prefixes in place. I'll try to report
back... I think there are more people on that than regularly post here.

Andy

[Alf P. Steinbach]

First note that you don't need to know. `std::shared_ptr` is an adaption
of `boost::shared_ptr`, so you already know all about it even if you
don't know details of Boost. Also if you're going to maintain that code,

* use the smart pointer that the original developers did,

unless you're going to refactor it, in which case you're in for a larger
effort anyway.

---

But let's say the example was, instead, something like
`something::Image` versus `something_else::Image` versus
`boost::gil::Image`, where the two first have nothing to do with
photographic images.

Ordinarily you get acquainted with the relevant types as you dive into
the code.

But if one just, unexpectedly, encounters an unqualified "Image", then
one checks what that means in this code, once.

The easiest way is just visual inspection, move eyeballs up with line of
sight in roughly the direction of the nearest `using` declaration.

If that's out of sight then I find it easier to hover the mouse over the
word than to scroll.


Cheers & hth.,

- Alf

[Ike Naar]

The problem is that other namespaces may have defined 'string' as well.
So if you see unadorned 'string' it's not clear whether std::string,
foo::string or bar::string was intended.

[Bonita Montero]

> The problem is that other namespaces may have defined 'string' as well.

Yes, and main() of course also! I'll bet my right hand on that.

[Bart]

Why are those other modules also defining 'string'? Which is known to be
a built-in type.

If they are alternatives to std::string, then wouldn't it make it an
easier plug-in replacement if you don't have to go around changing all
those "std::" to "foo::"?

Besides I thought the IDEs that everyone uses could tell which library
any unadorned "string" belonged to.

(I've developed some languages with namespaces. But I hardly ever used
such a qualifier.

In a first version, there was a natural search order so that if 'string'
was seen, it would look first in std, next in foo (or equivalents). A
qualifier was needed to specify which one.

In the next version, a qualifier, ie. a module prefix, would only be
needed if 'string' was ambiguous, ie. more than one exported 'string'
was visible from that place in the code.)

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>On 19/04/2019 18:27, Ike Naar wrote:

>> The problem is that other namespaces may have defined 'string' as well.
>> So if you see unadorned 'string' it's not clear whether std::string,
>> foo::string or bar::string was intended.
>>
>
>Why are those other modules also defining 'string'? Which is known to be
>a built-in type.

Perhaps because the code was written long before there was a concept
of namespaces (or a class called 'string') in C++?

[Juha Nieminen]

Bart <b...@freeuk.com> wrote:
> Why are those other modules also defining 'string'? Which is known to be
> a built-in type.

"string" is not a built-in type.

But perhaps in this situation "string" in particular is a poor
example because it's so ubiquitously known. But how about the
more obscure and less used names in the standard library? Can you
say that you remember by heart every single one of them, and avoid
using any of those names in your code? Every time you declare a new
function, type or variable, do you check if that name might be used
in the standard library? I doubt it.

Therefore, if you for example find a function named "equal" being
called in some code, do you know from looking at that line alone
whether it's a custom function or a standard library function?

[Juha Nieminen]

Bonita Montero <Bonita....@gmail.com> wrote:
> With std:: the types and functins are well known to the deveopers so
> there isn't any confusion when std:: is stripped.

Really? Given the literally *hundreds* of names used in the standard
library, can you remember by heart every single one of them? When you
see a name being used in code, can you be absolutely certain that it's
a name in the standard library, or a custom name?

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> If that's out of sight then I find it easier to hover the mouse over the
> word than to scroll.

I have always been of the opinion that the readability and
undrestandability of code shouldn't be reliant on an IDE. The code
should remain readable and understandable even if you are just looking
at it with a vanilla text editor.

[Bart]

Or on a printout, if anyone still uses those.

[Bart]

I think if you have code dominated by a sea of "std::" then that is a
problem that needs solving.

In this case caused by having too few things that are built-in and
unambiguous, and too much implemented in a library which, since the same
names could be used in a different library, mean this namespace prefix
is required.

I don't write C++ myself. But if I look at rextester.com (online C++),
it starts with this program:

#include <iostream>

int main()
{
std::cout << "Hello, world!\n";
}

I find that "std::" irritating. And that's not all. If I get rid of the
#include, it doesn't work (doesn't know 'std'); if I keep that but get
rid of std::, it doesn't work either (doesn't know 'cout'). And this is
the simplest possible program.

(Mind you I find 'cout' and '<<' equally irritating, but that's another
subject.)

This isn't just a C++ thing. On that same site, you will find:

fmt.Printf (Go; requires import "fmt")
System.out.println (Java; requires imports)
Console.WriteLine (C# and VB; requires various 'using')

But then the majority are much cleaner:

Put_Line (Ada; requires "with" and "use")
echo (Bash)
print (Lisp)
writeln (D; requires import "std.stdio")
print (Fortran)
print (Haskell)
print (Javascript)
print (Lua)
writeln (Pascal)
print (Perl)
print (Python)
println (Scala)
print (Swift)
printf (C; requires include <stdio.h>)

So what is with C++ and those other long-winded languages? How do all
these others solve the problem of ambiguity when you leave out those
prefixes?

[Bonita Montero]

>> With std:: the types and functins are well known to the deveopers
>> so there isn't any confusion when std:: is stripped.

> Really? Given the literally *hundreds* of names used in the standard
> library, can you remember by heart every single one of them? When you
> see a name being used in code, can you be absolutely certain that it's
> a name in the standard library, or a custom name?

Then you google in 5 seconds "C++ name" if a name is already defined
in the standard-library or any relvant C++-library.

[Bonita Montero]

> I have always been of the opinion that the readability and
> undrestandability of code shouldn't be reliant on an IDE.

I don't see any reason for that.

[Alf P. Steinbach]

That's what we have mobile phones for, when one sits down to read code
on paper.


Cheers!,

- Alf

[Ian Collins]

Ah but readability is in the eye of the beholder :)

Which would be more readable, a ten character name prefixed bay thirty
characters of namespaces, or a using directive and a ten character name?

--
Ian.

[Ian Collins]

On 22/04/2019 01:09, Bart wrote:
> On 21/04/2019 13:33, Juha Nieminen wrote:
>> Bart <b...@freeuk.com> wrote:
>>> Why are those other modules also defining 'string'? Which is known to be
>>> a built-in type.
>>
>> "string" is not a built-in type.
>>
>> But perhaps in this situation "string" in particular is a poor
>> example because it's so ubiquitously known. But how about the
>> more obscure and less used names in the standard library? Can you
>> say that you remember by heart every single one of them, and avoid
>> using any of those names in your code? Every time you declare a new
>> function, type or variable, do you check if that name might be used
>> in the standard library? I doubt it.
>>
>> Therefore, if you for example find a function named "equal" being
>> called in some code, do you know from looking at that line alone
>> whether it's a custom function or a standard library function?
>
> I think if you have code dominated by a sea of "std::" then that is a
> problem that needs solving.
>
> In this case caused by having too few things that are built-in and
> unambiguous, and too much implemented in a library which, since the same
> names could be used in a different library, mean this namespace prefix
> is required.

What gets built in and what gets included in libraries is always a trade
off. The more you build in, the more you restrict the environments
where the language can be used.

We are lucky that C++ is designed to allow extension through libraries.

--
Ian.

[Chris Sykes]

On 21/04/2019 14:09, Bart wrote:
> I don't write C++ myself. But if I look at rextester.com (online
> C++), it starts with this program:
>
>   #include <iostream>
>
>   int main()
>   {
>        std::cout << "Hello, world!\n";
>   }
>
> I find that "std::" irritating. And that's not all. If I get rid of
> the #include, it doesn't work (doesn't know 'std'); if I keep that
> but get rid of std::, it doesn't work either (doesn't know 'cout').
> And this is the simplest possible program.

Well in C++ you can always add:

using std::cout, std::string; // comma separated list allowed since c++17

To pull in precisely what you want to use from the standard library, or:

using std;

To dump everything into the local scope.

The biggest advantage (IMO) of C++ namespaces is that they provide a
mechanism to resolve otherwise ambiguous names; that is, even when
`using std;`, you can fully qualify references to string, cout
or whatever to resolve any ambiguity with symbols defined elsewhere.

Many other languages do something similar; the compiler (or interpreter)
raises an error (hopefully identifying where the conflicting symbols
are declared), and you fix it by qualifying the references with the
appropriate namespace, package, module/whatever prefix.

[Chris Sykes]

On 21/04/2019 13:37, Juha Nieminen wrote:

Absolutely. Time saved in code review (or just coming back to some
code *you* wrote a while ago) vastly outweighs a few characters
saved when first entering the code, and both IDEs and editors tend
to have pretty good auto-complete when entering code these days
anyway.

[Jorgen Grahn]

On Thu, 2019-04-18, Fred.Zwarts wrote:
> "Jorgen Grahn" schreef in bericht
> news:slrnqbe9ob.4...@frailea.sa.invalid...
>>

>>On Wed, 2019-04-17, Fred.Zwarts wrote:
>>> schreef in bericht
>>> news:a24842c2-63de-4ff9...@googlegroups.com...
>>>>
>>>>On Wednesday, April 17, 2019 at 10:59:27 AM UTC+1, F.Zwarts wrote:
>>>>> Another reason, in particular for names that are used very often, is
>>>>> that
>>>>> in
>>>>> complex expressions 'string' is easier to read than 'std::string',
>>>>> because
>>>>> it is easier to keep the expressions short.
>>>>
>>>>This is a fallacious argument. "std::" is ONLY FIVE EXTRA CHARACTERS. Not
>>>>using the prefix actually makes things harder not easier to grok as you
>>>>can't tell at a glance what code is standard and what code is
>>>>non-standard.
>>>>
>>>>/Leigh
>>>
>>> If somebody missed the fact that string is defined in the std::
>>> namespace,
>>

>>It's not, not necessarily. I may want to use the name "string"
>>locally, and don't expect such a name to conflict with the standard
>>library. Not to mention names like find().
>
> I don't think it is wise to use such a widely used name as 'string' locally.

I do. Namespaces were added to C++ (at least partly) to allow that;
seems a waste not to take advantage of it.

How much of an advantage it is varies from person to person.
Personally I find prefixes quite distracting: I strongly prefer
e.g. "insert(a, b)" to "my_insert(a, b)".

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Thu, 2019-04-18, wyn...@gmail.com wrote:
> Juha Nieminen於 2019年4月17日星期三 UTC+8下午3時06分59秒寫道：
>> As an avid armchair psychologist, it has always fascinated me why some
>> people just hate namespace prefixes in C++, and go to great lengths
>> to avoid them and will rabidly defend this practice, and oppose their
>> use. No amoung of argumentation will convince them otherwise.

...

> It's because of, me-thinks, the way people remember/process words.
>
> The advantage(or disadvantage)of prefix is that the object is more
> uniquely named. Unlike namespace, every time I see 'string' I have to
> look for, even analyse programs to figure-out the right meaning that
> name is associated to, from file to file.
>

> Ex:
> Mars::wind, Mars::rock
> Earth::wind, Earth::rock
>
> When I see 'wind', 'rock', how am I supposed to think with these words?
> Mars_wind, Earth_rock would be more clearer.

Just like Mars::wind and Earth::rock.

IMHO you're missing part of the point of namespaces. You're supposed
to /know/ when you're inside it, much like you're supposed to know
what planet you're on.

Or, if I had a brother called Donald, I'd call him "Donald" when
talking to my sister. I wouldn't call him "Donald Grahn" to make it
clear I'm not talking about Donald Duck, or Knuth. If I did, my
sister would be confused and possibly worried.

When you're not inside the namespace, using the full name is normally
the way to go: if a whole class or function only works on Earth::rock,
then that's a sign maybe it should have been in the Earth namespace.

[wyn...@gmail.com]

Jorgen Grahn於 2019年4月23日星期二 UTC+8上午12時07分57秒寫道：

> On Thu, 2019-04-18, wyn...@gmail.com wrote:
> > Juha Nieminen於 2019年4月17日星期三 UTC+8下午3時06分59秒寫道：
> >> As an avid armchair psychologist, it has always fascinated me why some
> >> people just hate namespace prefixes in C++, and go to great lengths
> >> to avoid them and will rabidly defend this practice, and oppose their
> >> use. No amoung of argumentation will convince them otherwise.
> ...
>
> > It's because of, me-thinks, the way people remember/process words.
> >
> > The advantage(or disadvantage)of prefix is that the object is more
> > uniquely named. Unlike namespace, every time I see 'string' I have to
> > look for, even analyse programs to figure-out the right meaning that
> > name is associated to, from file to file.
> >
> > Ex:
> > Mars::wind, Mars::rock
> > Earth::wind, Earth::rock
> >
> > When I see 'wind', 'rock', how am I supposed to think with these words?
> > Mars_wind, Earth_rock would be more clearer.
>
> Just like Mars::wind and Earth::rock.
>
> IMHO you're missing part of the point of namespaces. You're supposed
> to /know/ when you're inside it, much like you're supposed to know
> what planet you're on.
>

OK (some namespace name is deliberately long, e.g. >10 characters)

> Or, if I had a brother called Donald, I'd call him "Donald" when
> talking to my sister. I wouldn't call him "Donald Grahn" to make it
> clear I'm not talking about Donald Duck, or Knuth. If I did, my
> sister would be confused and possibly worried.
>

but the compiler doesn't know what my mind-state is in. Compiler doesn't
even know most of standard library's codes.

Ex: In file bits/stl_algobase.h, I'm still bugged why the line
swap(*__a,*__b) is not written as std::swap(*__a,*__b), which caused
compilation of one of my program failed.

> When you're not inside the namespace, using the full name is normally
> the way to go: if a whole class or function only works on Earth::rock,
> then that's a sign maybe it should have been in the Earth namespace.
>
> /Jorgen
>
> --
> // Jorgen Grahn <grahn@ Oo o. . .
> \X/ snipabacken.se> O o .

I checked my codes to see that I still use namespce prefix in cases
they are defined in different files (in the same namespace).

[Rosario19]

i not agree in use namespace or liking facility

the way for me it is in the start of code make clear what operator or
function call, where is the file executable where the function is,
what is its name in that file (and prototiype afther for compiler
check right arguments)

for example if i want call '*'
i would write

define '*' "file.dll:operatorNameInThatFile"

first of call '*' in 3*4

[Fred.Zwarts]

"Ike Naar" schreef in bericht
news:slrn3nf4qbk...@faeroes.freeshell.org...

If you really are so unsure about the context in which you are programming,
it might be even better to use ::std::string, because otherwise it is
unclear whether foo::std::string, or bar::std::string was intended. '::' is
ONLY TWO EXTRA CHARACTERS. :-)

It is probably a matter of taste. In mosts contexts it is perfectly clear
that there is no foo::string, nor foo::std. No confusion in that case if an
unadorned 'string' or unadorned 'std' is used. If confusion is possible,
than a namespace prefix is very useful. I agree with that.

[Bonita Montero]

> Ex: In file bits/stl_algobase.h, I'm still bugged why the line
> swap(*__a,*__b) is not written as std::swap(*__a,*__b), which
> caused compilation of one of my program failed.

The discussion is about omitting napespace-prefixes when a namespace
is chosen or a function or type of a namespace is chosen; and not
about missing chosen namespaces.

[Vir Campestris]

Feedback from our group at work.

Out of 100 people signed up... I got about half a dozen "using namespace
std is evil", one who said "but only in headers" and a couple of
explicit don't cares.

Leaving about 90% who couldn't give a damn.

Andy

[Ian Collins]

That's about what I would expect form a similar number at my work. Mind
you, the numbers would be much the same for any style question. Only
those with a strong opinion will speak up, the majority couldn't give a
damn!

--
Ian.

[Juha Nieminen]

Bart <b...@freeuk.com> wrote:
> I think if you have code dominated by a sea of "std::" then that is a
> problem that needs solving.

Why?

On the contrary, the more you use standard library tools, usually the better
(assuming you know and understand the performance of those tools). If you
use your own implementation of something that's provided by the standard
library, you are needlessly increasing the complexity of your code and
introducing additional sources of potential bugs. The standard library
implementations have been, after all, tested millions of times (probably
quite literally) and it's pretty safe to assume they are bug-free (when
used as per their specs).

Therefore the more "std::" you see in the code, usually the better!

(Of course it's still very possible to use standard library tools in
a very inefficient manner. Just using them does not guarantee efficiency.
Know your tools and use them where appropriate.)

> I don't write C++ myself. But if I look at rextester.com (online C++),
> it starts with this program:
>
> #include <iostream>
>
> int main()
> {
> std::cout << "Hello, world!\n";
> }
>
> I find that "std::" irritating.

Why? Why do you have a problem with it? Why does it bother you?

It makes the name much more unambiguous. There's pretty much zero doubt
that this name is actually from the standard library, and not something else.
Why would this bother you?

[Juha Nieminen]

So instead of seeing directly from the code that the name is from the
standard library, you need to resort to googling it.

And you think that's a *good* thing?

[Juha Nieminen]

Ian Collins <ian-...@hotmail.com> wrote:
> Which would be more readable, a ten character name prefixed bay thirty
> characters of namespaces, or a using directive and a ten character name?

Actually, and I'm not kidding, I regularly use names in my production code
like for example:

Core::GameMode::Classic::levelData

Especially since such names (like "levelData" here) appear in several such
namespaces, the disambiguation is very helpful, not just to make the code
compile, but for readability. I want to see *which* "levelData" is being
used here, rather than have to guess.

I suppose I could get rid of that "Core::" or even "Core::GameData::"
prefix, but I honestly don't find the urge nor the need to.

I have since very, very long time got completely rid of the (somewhat
strange) desire to write code that's as short as possible. Good riddance,
I say.

[Bart]

Look at the question I posed at the end of my post: why does C++ (and a
few others) make such a meal of it when in most languages you basically
just use 'print'.

Suppose built-in types could also be part of a library, would std::int
be acceptable?

How about operators like "+"; how do I know that the "+" here:

a + b

is either standard "+", or the "+" from library X, or the "+" from Y?

Should all such code be written as a std::+ b, or a X::+ b?

And if a and b are globals, should it be:

X::a std::+ Y::b

just to remove all doubt?

Look at file systems, which can also have long absolute paths. But most
of the time you don't need that path to distinguish F from A/F or B/F or
C/F. F is usually taken to be ./F, and usually you don't need to write
the "./".

Using std:: is like insisting all file names must be written in
canonical form with absolute paths. What a PITA that would be.

[Bonita Montero]

> So instead of seeing directly from the code that the name is
> from the standard library, you need to resort to googling it.

If you don't know the name you would have to check the documentation
anyway, no matter if its prefixed or not.

[Alf P. Steinbach]

I agree.

But I think you're arguing with people who find the qualified names
useful, because they're unable to keep the outer context in mind.

If that hypothesis is true then your arguments are doomed to fail to
convince, because the intended audience is unable to grok what you say.


Cheers!,

- Alf

[Bonita Montero]

> But I think you're arguing with people who find the qualified names
> useful, because they're unable to keep the outer context in mind.
>
> If that hypothesis is true then your arguments are doomed to fail to
> convince, because the intended audience is unable to grok what you say.

Juha has a low feeling of safety that makes him thinking compulsive.
That's a disorder some programmers have. And those people often want
that others obey their rules.

[Scott Lurndal]

Horseshit.

>
>If that hypothesis is true then your arguments are doomed to fail to
>convince, because the intended audience is unable to grok what you say.

In other words, everyone but Alf is too stupid to understand.

[Öö Tiib]

Because C++ is often used for writing programs where are hundreds
of thousands or even millions of lines of code. In namespaceless
programming languages the issues that it causes are avoided
either by having lot of little separate programs or by having the
namespace non-optional part of name like std_print,
big_print, bart_print, pig_print.

> Suppose built-in types could also be part of a library, would std::int
> be acceptable?

Worse, int is taboo to use in large number of projects
(both C and C++). It will be rejected by review with verdict:
"Should use int32_t." Now about int32_t there is indeed
difference. When author included <cstdint> then they
should use std::int32_t; when author included <stdint.h>
then they should use int32_t.

> How about operators like "+"; how do I know that the "+" here:
>
> a + b
>
> is either standard "+", or the "+" from library X, or the "+" from Y?
>
> Should all such code be written as a std::+ b, or a X::+ b?

No. Binary operators should be either inside class of first argument
or inside same namespace with argument types. Compiler will
search from those places and so should programmer assume
that those are there.

> And if a and b are globals, should it be:
>
> X::a std::+ Y::b
>
> just to remove all doubt?

Globals don't scale anyway because one has to put locks around
accesses of those to avoid race conditions. Do you program little
hello word style apps only?

> Look at file systems, which can also have long absolute paths. But most
> of the time you don't need that path to distinguish F from A/F or B/F or
> C/F. F is usually taken to be ./F, and usually you don't need to write
> the "./".
>
> Using std:: is like insisting all file names must be written in
> canonical form with absolute paths. What a PITA that would be.

Can't parse that analogy. I am typically programming in "different
directory" than std lets say, in namespace named x and in member
function of class x::Y sure I won't qualify x::F there, just write F.
But how is the std::F suddenly also F for me?

[Paavo Helde]

Or that might be because their own library namespace plus a couple of
other heavily used namespaces are already containing thousands of
symbols, and adding hundreds from std:: in the kettle would be clearly
too much. There are limits for everything and everyone.

[Paavo Helde]

If I know it's from std:: then I know it has a much better chance to
work correctly than everything else, so I don't need to concentrate on
it when debugging.

If I see std::sort in the code then I know what's doing. When it's just
sort, then I don't know what it is, what it is doing and if it is doing
it correctly. I have to spend my time to figure out first if it is
std::sort or something else, which might be very non-trivial (recall
Koenig lookup etc). Then I will need to remember that in this project
and in this file the sort was meaning this and that, and recall this the
next time I have to work with this code.

I have no idea what you guys have against the std:: prefix, this seems
like one of the easiest and simplest ways to disambiguate the code.

[Bart]

On 24/04/2019 18:06, Öö Tiib wrote:
> On Wednesday, 24 April 2019 17:47:12 UTC+3, Bart wrote:

>> Look at the question I posed at the end of my post: why does C++ (and a
>> few others) make such a meal of it when in most languages you basically
>> just use 'print'.
>
> Because C++ is often used for writing programs where are hundreds
> of thousands or even millions of lines of code.

Some of those other languages where 'print' or equivalent is one name,
can also be used for large programs.

> In namespaceless
> programming languages the issues that it causes are avoided
> either by having lot of little separate programs or by having the
> namespace non-optional part of name like std_print,
> big_print, bart_print, pig_print.

I thought one of the advantages of a namespace feature is that you have
the luxury of a bigger local context, even across a whole module,
instead of just inside functions.

That should result in less need for uniqueness among names. But since
you have to prefix each one with its namespace name, there seems little
point. Why not forget namespaces, and use std_string instead of
std::string, if you have to write it in full anyway.

>> Suppose built-in types could also be part of a library, would std::int
>> be acceptable?
>
> Worse, int is taboo to use in large number of projects
> (both C and C++). It will be rejected by review with verdict:
> "Should use int32_t." Now about int32_t there is indeed
> difference. When author included <cstdint> then they
> should use std::int32_t; when author included <stdint.h>
> then they should use int32_t.

Meanwhile the rest of the world just uses int32 or i32 and everyone
knows what they mean. (How many bits wide? How about taking a wild guess...)

Why is it just C++ that gets its knickers in a twist about this?

>> How about operators like "+"; how do I know that the "+" here:
>>
>> a + b
>>
>> is either standard "+", or the "+" from library X, or the "+" from Y?
>>
>> Should all such code be written as a std::+ b, or a X::+ b?
>
> No. Binary operators should be either inside class of first argument
> or inside same namespace with argument types. Compiler will
> search from those places and so should programmer assume
> that those are there.
>
>> And if a and b are globals, should it be:
>>
>> X::a std::+ Y::b
>>
>> just to remove all doubt?
>
> Globals don't scale anyway because one has to put locks around
> accesses of those to avoid race conditions. Do you program little
> hello word style apps only?

No. I use a language (not C++) that has namespaces, but it's rare that I
need specify one with a prefix. If there's an ambiguity because the same
two identifiers are visible, then the compiler will tell me.

(And when I do need to use one, I use ".", not "::", which is easier on
the eye.)

[Daniel]

On Wednesday, April 24, 2019 at 1:03:14 PM UTC-4, Scott Lurndal wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:
> >On 24.04.2019 16:46, Bart wrote:
>
> >But I think you're arguing with people who find the qualified names
> >useful, because they're unable to keep the outer context in mind.
>

> >If that hypothesis is true then your arguments are doomed to fail to
> >convince, because the intended audience is unable to grok what you say.
>
> In other words, everyone but Alf is too stupid to understand.

Alf, and most (I think most, but I'll settle for many) people programming in
the .NET languages, which have far more names, but most (or many) people
import the namespaces they're interested in and work with those names, in
the context of those namespaces.

One of the arguments in favour of prefixing everything from the standard
library with std:: is that it's short, but that's just an artifact of the
C++ standard library being similarly inspired as IBM was when it chose names
like APL (a programming language) or PL1 (programming language #1). But as
we're starting to see more meaningful names such as std::filesystem, I doubt
if many people are going to fully qualify with them.

Daniel

[Jorgen Grahn]

On Wed, 2019-04-24, Daniel wrote:
...

> One of the arguments in favour of prefixing everything from the standard
> library with std:: is that it's short, but that's just an artifact of the
> C++ standard library being similarly inspired as IBM was when it chose names
> like APL (a programming language) or PL1 (programming language #1). But as
> we're starting to see more meaningful names such as std::filesystem, I doubt
> if many people are going to fully qualify with them.

By coincidence, I removed a 'using boost::filesystem' today. I had to
qualify a few declarations of something of the type 'path' (actually
boost::filesystem::path) and it was a clear improvement.

The rest could be avoided using 'auto' and Koenig lookup.

There was one type I pulled in; I think it was
boost::filesystem::basic_filesystem_error. You have to draw the line
somewhere.

[Paavo Helde]

I'm sure you know you can also use namespace aliases:

namespace fs = boost::filesystem;

[Jorgen Grahn]

On Wed, 2019-04-24, Paavo Helde wrote:
...

>> By coincidence, I removed a 'using boost::filesystem' today. I had to
>> qualify a few declarations of something of the type 'path' (actually
>> boost::filesystem::path) and it was a clear improvement.
>>
>> The rest could be avoided using 'auto' and Koenig lookup.
>>
>> There was one type I pulled in; I think it was
>> boost::filesystem::basic_filesystem_error. You have to draw the line
>> somewhere.
>
> I'm sure you know you can also use namespace aliases:
>
> namespace fs = boost::filesystem;

Yes, and that would have been worse in the case, IMO. It's an extra
level of indirection to follow. Better than 'using namespace', though.

Please note the "in this case". Parts of Boost has names only
slightly shorter than an average Russian novel, and namespace aliases
may be the right solution there a lot of the time.

[David Brown]

On 24/04/2019 16:46, Bart wrote:

> Look at file systems, which can also have long absolute paths. But most
> of the time you don't need that path to distinguish F from A/F or B/F or
> C/F. F is usually taken to be ./F, and usually you don't need to write
> the "./".
>
> Using std:: is like insisting all file names must be written in
> canonical form with absolute paths. What a PITA that would be.

If only C++ had a way to let people use identifiers from a namespace
without having to fully qualify them. Imagine if there were some simple
method to let the compiler know that you were going to be using
identifiers from a namespace and wanted to do so without prefixes.
Imagine how convenient it would be if people could /choose/. Those who
want to use a prefix and write "std::cout" could do so, while those that
wanted to automatically use identifiers from std could just write
something easy and obvious like "using namespace std;" and the compiler
would magically know that "cout" really means "std::cout". People could
pick the method that makes most sense for the code they are writing.

Some people might think that C++ already supports this obvious feature,
but that could not be true. Bart has told us that C++ is always bad,
always ugly, always more awkward than any other language. And he got
this knowledge without actually programming in C++, so it /must/ be true.

[Daniel]

On Wednesday, April 24, 2019 at 3:17:40 PM UTC-4, Paavo Helde wrote:
>
> I'm sure you know you can also use namespace aliases:
>
> namespace fs = boost::filesystem;

You're right, I know that :-)

But I think

using boost::filesystem;

is in most cases preferable. In general, we are programming within a context
where the number of names is limited.

Daniel

[Alf P. Steinbach]

On 24.04.2019 20:48, Jorgen Grahn wrote:
> On Wed, 2019-04-24, Daniel wrote:
> ...
>> One of the arguments in favour of prefixing everything from the standard
>> library with std:: is that it's short, but that's just an artifact of the
>> C++ standard library being similarly inspired as IBM was when it chose names
>> like APL (a programming language) or PL1 (programming language #1). But as
>> we're starting to see more meaningful names such as std::filesystem, I doubt
>> if many people are going to fully qualify with them.
>
> By coincidence, I removed a 'using boost::filesystem' today. I had to
> qualify a few declarations of something of the type 'path' (actually
> boost::filesystem::path) and it was a clear improvement.

I always use

namespace fs = std::filesystem;

... for that, and write e.g. (and in particular)


fs::path

... instead of completely unqualified `path`, and I have the impression
that that's a kind of common convention?

> The rest could be avoided using 'auto' and Koenig lookup.
>
> There was one type I pulled in; I think it was
> boost::filesystem::basic_filesystem_error. You have to draw the line
> somewhere.

:)


Cheers!,

- Alf

[Daniel]

On Wednesday, April 24, 2019 at 1:31:07 PM UTC-4, Paavo Helde wrote:

> Or that might be because their own library namespace plus a couple of
> other heavily used namespaces are already containing thousands of
> symbols, and adding hundreds from std:: in the kettle would be clearly
> too much. There are limits for everything and everyone.

There are more more opportunities for name leakage in C++ than in JAVA or .NET, despite the latter two having many more names in their libraries, and perhaps this suggests a different strategy. It's unfortunate that std is a garbage dump of names from such a miscellany of categories, including vector, regex, fstream, and so on.

Daniel

[Ian Collins]

On 25/04/2019 08:10, Alf P. Steinbach wrote:
> On 24.04.2019 20:48, Jorgen Grahn wrote:
>> On Wed, 2019-04-24, Daniel wrote:
>> ...
>>> One of the arguments in favour of prefixing everything from the standard
>>> library with std:: is that it's short, but that's just an artifact of the
>>> C++ standard library being similarly inspired as IBM was when it chose names
>>> like APL (a programming language) or PL1 (programming language #1). But as
>>> we're starting to see more meaningful names such as std::filesystem, I doubt
>>> if many people are going to fully qualify with them.
>>
>> By coincidence, I removed a 'using boost::filesystem' today. I had to
>> qualify a few declarations of something of the type 'path' (actually
>> boost::filesystem::path) and it was a clear improvement.
>
> I always use
>
> namespace fs = std::filesystem;
>

> .... for that, and write e.g. (and in particular)
>
>
> fs::path
>
> .... instead of completely unqualified `path`, and I have the impression

> that that's a kind of common convention?

It is for me, especially when dealing with long winded nested
namespaces. I started using namespace aliases for our Google protobuf
namespaces (at least three levels deep) and a quick search of our code
shows the practice is now common.

--
Ian.

[Bart]

On 24/04/2019 20:49, David Brown wrote:
> On 24/04/2019 16:46, Bart wrote:
>
>> Look at file systems, which can also have long absolute paths. But
>> most of the time you don't need that path to distinguish F from A/F or
>> B/F or C/F. F is usually taken to be ./F, and usually you don't need
>> to write the "./".
>>
>> Using std:: is like insisting all file names must be written in
>> canonical form with absolute paths. What a PITA that would be.
>
> If only C++ had a way to let people use identifiers from a namespace
> without having to fully qualify them.

The debate here is with people who want to fully qualify them all the
time. Their point appears to be that that is necessarily for the names
to be always 100% unambiguous.

> Some people might think that C++ already supports this obvious feature,
> but that could not be true.  Bart has told us that C++ is always bad,
> always ugly, always more awkward than any other language.  And he got
> this knowledge without actually programming in C++, so it /must/ be true.
>

You get a big hint as soon as you see: 'std::cout << "hello"'. Something
that seems to have been little copied by other languages.

[David Brown]

On 24/04/2019 22:34, Bart wrote:
> On 24/04/2019 20:49, David Brown wrote:
>> On 24/04/2019 16:46, Bart wrote:
>>
>>> Look at file systems, which can also have long absolute paths. But
>>> most of the time you don't need that path to distinguish F from A/F
>>> or B/F or C/F. F is usually taken to be ./F, and usually you don't
>>> need to write the "./".
>>>
>>> Using std:: is like insisting all file names must be written in
>>> canonical form with absolute paths. What a PITA that would be.
>>
>> If only C++ had a way to let people use identifiers from a namespace
>> without having to fully qualify them.
>
> The debate here is with people who want to fully qualify them all the
> time. Their point appears to be that that is necessarily for the names
> to be always 100% unambiguous.

Of course names should be 100% unambiguous. Why would you want
ambiguous identifiers?

Whether that requires full qualification or not is a matter of style,
preference, and the kind of code you are writing.

>
>> Some people might think that C++ already supports this obvious
>> feature, but that could not be true.  Bart has told us that C++ is
>> always bad, always ugly, always more awkward than any other language.
>> And he got this knowledge without actually programming in C++, so it
>> /must/ be true.
>>
>
> You get a big hint as soon as you see: 'std::cout << "hello"'. Something
> that seems to have been little copied by other languages.

It is supported by almost all languages that are suitable for big
programs, libraries, and multiple people working on the same code base.
Which techniques you choose to use is not defined by any serious
language - they offer multiple options.

Thus in C++ you might use std:: (or other namespace qualifiers) on
names. Or you might use "using namespace std;" at the start of the
module. Or you might use it within a function. Or you might use a
"using" clause for just the identifiers you want to use regularly
without std::.

This is not remotely something unique to C++.

[Ian Collins]

C++ iostreams my be cumbersome for simple types, but they come into
their own when outputting more complex types which contain other other
non-trivial members. They also simplify streaming to things other than
files.

Then there's templates, a feature not shared by many other languages.

--
Ian.

[Bart]

On 24/04/2019 21:42, David Brown wrote:

> On 24/04/2019 22:34, Bart wrote:

>> to be always 100% unambiguous.
>
> Of course names should be 100% unambiguous.  Why would you want
> ambiguous identifiers?

> Whether that requires full qualification or not is a matter of style,
> preference, and the kind of code you are writing.

Well, that is the debate, to use std:: everywhere or not.

>
>>
>>> Some people might think that C++ already supports this obvious
>>> feature, but that could not be true.  Bart has told us that C++ is
>>> always bad, always ugly, always more awkward than any other language.
>>> And he got this knowledge without actually programming in C++, so it
>>> /must/ be true.

(You seem to have a strong opinion of my own languages without
programming in them either.)

>>
>> You get a big hint as soon as you see: 'std::cout << "hello"'.
>> Something that seems to have been little copied by other languages.
>
> It is supported by almost all languages that are suitable for big
> programs, libraries, and multiple people working on the same code base.
> Which techniques you choose to use is not defined by any serious
> language - they offer multiple options.

Have a look at my much earlier post. Actually I'll just copy the
relevant bit here:

Put_Line (Ada; requires "with" and "use")
echo (Bash)
print (Lisp)
writeln (D; requires import "std.stdio")
print (Fortran)
print (Haskell)
print (Javascript)
print (Lua)
writeln (Pascal)
print (Perl)
print (Python)
println (Scala)
print (Swift)
printf (C; requires include <stdio.h>)

How many use anything remotely like "cout"?

How many use the peculiar "<<"?

How many (in the few not shown here that need a dotted name) use "::" to
qualify a name?**

So even this small fragment of a hello, world program seems to
accurately set the scene for what C++ is going to be like.

(** Out of the 400 languages here:

https://rosettacode.org/wiki/Hello_world/Text

I think between 1 and 4 others use those C++ features in each case.)

[David Brown]

I don't know of any other languages that use "cout <<" or a similar
syntax. It is a syntax with a lot of interesting features and
advantages - but also some disadvantages. But that is irrelevant to the
discussion.

>
> How many (in the few not shown here that need a dotted name) use "::" to
> qualify a name?**

You picked an example function that is, in many languages, a built-in
function or special statement. Most of these languages, if they are
suitable for large-scale programming, have a system of namespaces for
library and user functions. Those that don't (like C) need manual
prefixes in the identifiers or other ad-hoc methods to keep control of
identifiers from different blocks of code.

>
> So even this small fragment of a hello, world program seems to
> accurately set the scene for what C++ is going to be like.
>
> (** Out of the 400 languages here:
>
>   https://rosettacode.org/wiki/Hello_world/Text
>
> I think between 1 and 4 others use those C++ features in each case.)

C++ is mildly unusual in not having any equivalent to "print"
immediately available in the language. But that is not relevant to the
issue at hand.

[Öö Tiib]

On Wednesday, 24 April 2019 21:12:54 UTC+3, Bart wrote:
> On 24/04/2019 18:06, Öö Tiib wrote:
> > On Wednesday, 24 April 2019 17:47:12 UTC+3, Bart wrote:
>
> >> Look at the question I posed at the end of my post: why does C++ (and a
> >> few others) make such a meal of it when in most languages you basically
> >> just use 'print'.
> >
> > Because C++ is often used for writing programs where are hundreds
> > of thousands or even millions of lines of code.
>
> Some of those other languages where 'print' or equivalent is one name,
> can also be used for large programs.

In C++ the "printf" is also one name when the team uses <stdio.h>. I
have very rarely seen anyone demanding usage of "::printf" then.
However when the team uses <cstdio> then "printf" is not required
to compile by standard so one should write "std::printf". Issue with
"printf" is that it is not type safe. Team should use static analysis
tools to verify that the format specifiers match (but better compiler
like gcc contain it already).

> > In namespaceless
> > programming languages the issues that it causes are avoided
> > either by having lot of little separate programs or by having the
> > namespace non-optional part of name like std_print,
> > big_print, bart_print, pig_print.
>
> I thought one of the advantages of a namespace feature is that you have
> the luxury of a bigger local context, even across a whole module,
> instead of just inside functions.

That certainly is so. The std just is not "local context" for anyone but
for standard library programmer.

> That should result in less need for uniqueness among names. But since
> you have to prefix each one with its namespace name, there seems little
> point. Why not forget namespaces, and use std_string instead of
> std::string, if you have to write it in full anyway.

When I read "string" then I assume that it is local name and am
annoyed when it is actually local alias of "std::string". Locally
all texts should have some local type. For example "CarModel"
that may be alias of "std::string". I have no idea why you want
to redeclare "basic sequence of bytes" (that "std::string" is)
locally in your "ropes" namespace as "ropes::string" and
to confuse the hell out of everybody.

> >> Suppose built-in types could also be part of a library, would std::int
> >> be acceptable?
> >
> > Worse, int is taboo to use in large number of projects
> > (both C and C++). It will be rejected by review with verdict:
> > "Should use int32_t." Now about int32_t there is indeed
> > difference. When author included <cstdint> then they
> > should use std::int32_t; when author included <stdint.h>
> > then they should use int32_t.
>
> Meanwhile the rest of the world just uses int32 or i32 and everyone
> knows what they mean. (How many bits wide? How about taking a wild guess...)
>
> Why is it just C++ that gets its knickers in a twist about this?

In C++ we have had some trouble when ::u32 and ::i32 were typedefs
of "unsigned long" and "signed long" by platform vendor and
"unsigned int" and "signed int" by vendor of third party module.
Typical "bleeding edge" crap from moronic American chip
manufacturer. Typical silver bullet" module bought for $ 120K
by fatsos. Both wrong! But we *must* use those. :(

I still support if team wants to use such names as aliases
of std::uint32_t and std::int32_t ... even if we have to maintain
the third party "silver bullets" as result.

> >> How about operators like "+"; how do I know that the "+" here:
> >>
> >> a + b
> >>
> >> is either standard "+", or the "+" from library X, or the "+" from Y?
> >>
> >> Should all such code be written as a std::+ b, or a X::+ b?
> >
> > No. Binary operators should be either inside class of first argument
> > or inside same namespace with argument types. Compiler will
> > search from those places and so should programmer assume
> > that those are there.
> >
> >> And if a and b are globals, should it be:
> >>
> >> X::a std::+ Y::b
> >>
> >> just to remove all doubt?
> >
> > Globals don't scale anyway because one has to put locks around
> > accesses of those to avoid race conditions. Do you program little
> > hello word style apps only?
>
> No. I use a language (not C++) that has namespaces, but it's rare that I
> need specify one with a prefix. If there's an ambiguity because the same
> two identifiers are visible, then the compiler will tell me.
>
> (And when I do need to use one, I use ".", not "::", which is easier on
> the eye.)

Ok. Note that I asked couple questions you did not ask:

You wrote:
> Look at file systems, which can also have long absolute paths. But most
> of the time you don't need that path to distinguish F from A/F or B/F or
> C/F. F is usually taken to be ./F, and usually you don't need to write
> the "./".
>
> Using std:: is like insisting all file names must be written in
> canonical form with absolute paths. What a PITA that would be.

And I answered:

Can't parse that analogy. I am typically programming in "different
directory" than std lets say, in namespace named x and in member
function of class x::Y sure I won't qualify x::F there, just write F.
But how is the std::F suddenly also F for me?

Can you please explain it or at least agree that the analogy was not
best thought thru?

[Fred.Zwarts]

"Öö Tiib" schreef in bericht
news:f80611c0-4996-44a4...@googlegroups.com...

Maybe a softlink in a directory is an analogy to 'using ::std::string'.
If a file in another directory is used very often, a softlink can bring that
file into your working directory.
Similarly, if ::std::string is used often, it can be brought into the
working namespace to avoid al lot of unnecessarily repeated detail that
distract the reader from what is going on.

[Bart]

I don't quite understand what you mean. But I'll give another example.
If I want to use the program 'cl.exe' on Windows from the command line
(which is MS' C (maybe also C++) compiler), I would type this:

cl prog.c

I wouldn't use this 11-levels-deep full path:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\
Tools\MSVC\14.15.26726\bin\Hostx86\x64\cl.exe prog.c

Even if writing a script, 95% of that would be noise obscuring whatever
it is that that line is trying to do.

This works because there is some set-up equivalent to 'using namespace',
otherwise you would quickly lose the will to live if you had to retype
that lot every time.

The problem is that you might have another "cl.exe" which is encountered
before the one you want. But then C++ allows you to write this:

typedef struct {int x,y;} std;

Now std::cout no longer works. Or it does work if I declare another
working std::cout, but it's now silently using the wrong one.

So std::cout doesn't guarantee anything.

[Jorgen Grahn]

On Wed, 2019-04-24, Daniel wrote:

No more limited when you use boost::filesystem than in any other code.

Does that mean you think namespace is an unnecessary language feature?

[Daniel]

On Thursday, April 25, 2019 at 7:24:46 AM UTC-4, Jorgen Grahn wrote:
>
> Does that mean you think namespace is an unnecessary language feature?
>

No.

Daniel

[Daniel]

On Thursday, April 25, 2019 at 7:24:46 AM UTC-4, Jorgen Grahn wrote:

> On Wed, 2019-04-24, Daniel wrote:
> > But I think
> >
> > using boost::filesystem;
> >
> > is in most cases preferable. In general, we are programming within a
> > context where the number of names is limited.
>

> Does that mean you think namespace is an unnecessary language feature?
>

Of course not. Namespace are what make it possible to use the unadorned
"filesystem" within a context. Without namespaces, it would be
boost_filesystem and the like.

Daniel

[Paavo Helde]

Please don't make such generalizations involving other people. One of
the major usage cases for C++ are large projects where the number of
names might not be so limited.

Also, using whole foreign namespaces like boost::filesystem which you
don't have control over is always a bad idea. You never know which names
will be added there in the next version, and if there appear conflicts
then somebody has to find time and take care of fixing them.

This is even worse for open-source libraries, where the task of fixing
the conflicts will be placed on the user of your library who has no
knowledge about your library or maybe not much knowledge about C++ at
all. If the conflict appears in some templated code the error message
may be several pages long. I have ditched several open-source libraries
when they failed to compile with the next compiler version, with
mysterious errors.

[Öö Tiib]

On Thursday, 25 April 2019 12:37:55 UTC+3, F.Zwarts wrote:
> "Öö Tiib" schreef in bericht
> news:f80611c0-4996-44a4...@googlegroups.com...
>

> >You wrote:
> >> Look at file systems, which can also have long absolute paths. But most
> >> of the time you don't need that path to distinguish F from A/F or B/F or
> >> C/F. F is usually taken to be ./F, and usually you don't need to write
> >> the "./".
> >>
> >> Using std:: is like insisting all file names must be written in
> >> canonical form with absolute paths. What a PITA that would be.
> >
> >And I answered:
> >
> >Can't parse that analogy. I am typically programming in "different
> >directory" than std lets say, in namespace named x and in member
> >function of class x::Y sure I won't qualify x::F there, just write F.
> >But how is the std::F suddenly also F for me?
> >
> >Can you please explain it or at least agree that the analogy was not
> >best thought thru?
> >
>
> Maybe a softlink in a directory is an analogy to 'using ::std::string'.
> If a file in another directory is used very often, a softlink can bring that
> file into your working directory.
> Similarly, if ::std::string is used often, it can be brought into the
> working namespace to avoid al lot of unnecessarily repeated detail that
> distract the reader from what is going on.

I already explained that in other namespaces (like "ropes", "fishing",
"underwear" whatever) the name "string" just confuses.
What makes sense there are things like:

using Mark = std::string;
using Manufacturer = std::string;

What does not make sense and annoys is:

using std::string;

That is my position, yours may different.

[David Brown]

The solution for compiling here is our old favourite, "make". The long
path name goes in a variable in the makefile, so that you can type "make
prog" (the same number of keypresses as "cl prog.c") and get the right
version of the "cl.exe" command. As a bonus, for people who know how to
use compilers, you have a neat place to put your compiler flags.

The C++ equivalent, I suppose, is to have functions in your own code
with convenient names (in namespaces if you like) so that any long
external namespace names are written once in the function definition and
don't have to be repeated. Such functions are obviously a good place to
put other bits of code - translation between formats, logging for
debugging, or whatever you like in your wrapper code.

> But then C++ allows you to write this:
>
>   typedef struct {int x,y;} std;
>
> Now std::cout no longer works. Or it does work if I declare another
> working std::cout, but it's now silently using the wrong one.
>
> So std::cout doesn't guarantee anything.

There are those who feel the solution is to write "::std::cout". Most
C++ programmers, I suspect, feel it is more appropriate to force-feed
the person who made that struct with a printout of the latest C++
standards document, until they agree not to be so painfully stupid again.

That is the key point of having the standard library in the "std::"
namespace - it means new versions of C++ can add to that without fear of
conflict with existing code, and users don't have to worry about their
code clashing with future library identifiers. It is /far/ better than
having a language where an enthusiastic, well-meaning but thoughtless
designer can randomly add whatever new built-in function names and other
identifiers they like with no regard with how they conflict with
existing code.

[Jorgen Grahn]

On Wed, 2019-04-24, Daniel wrote:

Why? What problem does that cause? What namespace would you otherwise
put std::regex in -- std::regex::regex? std::text::parsing::regex?
AFAIC std::regex is necessary and sufficient: it says it's the regex
class of the standard library.

The std namespace separates the standard library from other libraries,
and I find that enough ... unless the standard library grows to levels
approaching Python's, but I don't think that will happen anytime soon.

[Öö Tiib]

On Thursday, 25 April 2019 14:00:48 UTC+3, Bart wrote:
> On 25/04/2019 09:39, Öö Tiib wrote:
> > On Wednesday, 24 April 2019 21:12:54 UTC+3, Bart wrote:
>
> >> Using std:: is like insisting all file names must be written in
> >> canonical form with absolute paths. What a PITA that would be.
> >
> > And I answered:
> >
> > Can't parse that analogy. I am typically programming in "different
> > directory" than std lets say, in namespace named x and in member
> > function of class x::Y sure I won't qualify x::F there, just write F.
> > But how is the std::F suddenly also F for me?
> >
> > Can you please explain it or at least agree that the analogy was not
> > best thought thru?
>
> I don't quite understand what you mean. But I'll give another example.
> If I want to use the program 'cl.exe' on Windows from the command line
> (which is MS' C (maybe also C++) compiler), I would type this:
>
> cl prog.c
>
> I wouldn't use this 11-levels-deep full path:
>
> C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\
> Tools\MSVC\14.15.26726\bin\Hostx86\x64\cl.exe prog.c
>
> Even if writing a script, 95% of that would be noise obscuring whatever
> it is that that line is trying to do.

I use aliases there instead of that full path. Bare cl is certainly
ambiguous for me with 3 MS compilers installed plus about
8 other compilers. I feel seriously crippled when working
on systems that has just 1-2 C++ compilers on it and dislike
Apple exactly for reason of fighting against me there.

> This works because there is some set-up equivalent to 'using namespace',
> otherwise you would quickly lose the will to live if you had to retype
> that lot every time.
>
> The problem is that you might have another "cl.exe" which is encountered
> before the one you want. But then C++ allows you to write this:
>
> typedef struct {int x,y;} std;

That is sabotage. It does not matter. I will order the author publicly
executed or if law happens not to allow then to be fired and sued. ;)

> Now std::cout no longer works. Or it does work if I declare another
> working std::cout, but it's now silently using the wrong one.
>
> So std::cout doesn't guarantee anything.

In my team it guarantees ... YMMV.

[Jorgen Grahn]

Thanks. You see (I think) namespace qualification as something to use
when the need arises. I don't agree, but at least it makes sense as a
strategy.

[Vir Campestris]

On 24/04/2019 18:06, Öö Tiib wrote:
> Worse, int is taboo to use in large number of projects
> (both C and C++). It will be rejected by review with verdict:
> "Should use int32_t." Now about int32_t there is indeed
> difference. When author included <cstdint> then they
> should use std::int32_t; when author included <stdint.h>
> then they should use int32_t.

(forking the thread)

I use int when I mean "I've got this signed number that isn't
especially big, compiler go ahead and pick the one that's best to use on
this architecture".

I use uin32_t when I'm dealing with fixed data structures that are cross
platform. And even then I worry one day I'll meet a Vax.

uint32_t may carry significant overheads if the compiler has to mess
about with packing/unpacking it from some different size native word.

Andy

[Mr Flibble]

int_fast32_t dear.

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais
“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.”
– Ricky Gervais
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."

[Öö Tiib]

More than 99.99% of C++ developers do not target such platforms
where [u]int32_t is not alias of [unsigned] int. I have to
support quite exotic projects some are 16 bits. I agree with usage
of int_fast16_t as performance optimization in that 5% of code
base where performance matters.

Preferring std::[u]int32_t (often u32/i32 aliases when team agrees)
to [unsigned] int is because what is data passed in direct function
call today can turn into data passed by cross platform RPC
tomorrow.

Sometimes it isn't so obvious but actual bits are extremely
important. One project I participate is spread between tens of
subproject repos (wasn't mine idea). Changing some i32 to i64
in interface of one did make several of those to warn and to
need refactoring, then the pull requests, reviews, retesting and
so on. If part of those would run on platform where int is say 48
bits then changing that i32 to int would have similar effect like
that change had, don't you agree?

[Melzzzzz]

I agree that not fixing sizes of variables is design error.


--
press any key to continue or any other to quit...

Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Juha Nieminen]

Bonita Montero <Bonita....@gmail.com> wrote:
> Juha has a low feeling of safety that makes him thinking compulsive.
> That's a disorder some programmers have. And those people often want
> that others obey their rules.

Why don't you go fuck yourself?

[Juha Nieminen]

Bart <b...@freeuk.com> wrote:
> Meanwhile the rest of the world just uses int32 or i32 and everyone
> knows what they mean. (How many bits wide? How about taking a wild guess...)

If you see a function named "equal()" being called in the code, do you know
if it's a custom function, or a function from the standard library?