«

On Monday, 31 December 2012 16:28:57 UTC+2, Tobias Müller wrote:
> Öö Tiib <> wrote:
> > On Saturday, 29 December 2012 16:47:18 UTC+2, Tobias Müller wrote:
> >> Juha Nieminen <> wrote:
> >>
> >>> I think it's a shame that textbooks and tutorials teach such a bad habit.
> >>
> >> Actually, I don't understand, why this flame comes up each and every time
> >> someone writes "using namespace std;".
> >>
> >> I can't see why this should be harmful in case of namespace std. Sure,for
> >> other namespaces it's a different story.
> >
> > When someone uses convenient short name that happens is also in std
> > namespace (like 'thread' or 'list' or 'ref') then things start to clash
> > and who the poor noob asks about strange error messages that he had
> > stared at for last two hours? Me of course.
>
> And you can tell him the issue in one minute.

Geniuses (who solve any problem under minute) can. For them that 'using
namespace std' is certainly harmless. I am not one, sorry. I have never
even met one.

> > Sure, it is harmful he sat
> > and stared there *and* it is harmful since more important things
> > had to wait while I solved such nonsense issue.
>
> I don't know if a "C++ programmer" who has to sit and stare more than five
> minutes to find out a namespace clash can produce many important things in
> that time.

Lucky you. Congrats. For me ... world is totally different. I do not claim
to write oh so many important things. C++ code is never simple and short
like in textbooks for me. It takes some time to see what is going on
in it.

Example from my sad practice: some non-std::ref (a member function accepting
same argument) has been assumed by compiler into that std::bind. The error
messages are strange and fail to tell anything about 'ref'. If to qualify that
'ref' then the problems disappear. Also, problems disappear if to rename that member function. That however is not what mine (non-genius) C++ programmer
noob tries. He thinks that he misunderstood something about how std::bind or
std::ref works. Googles and reads. Tries different things. Finally, when he
asks for help frustrated the code is actually wrong too. Then I have to
understand what he wanted to achieve, what he has written and what there
actually should be.

If he had never used 'using namespace std' then he could had written it
himself under 5 minutes yes. So for him and me that 'using namespace std'
is harmful, for you it apparently is not.


> >> If std::string is for strings what int is for integers, then why should it
> >> be harmful to use it unqualified? You can still use any other string
> >> classes qualified.
> >
> > String may also (depending on problem domain) mean:
> > * a cord usually used to bind, fasten, or tie
> > * a plant fiber
> > * the gut, wire, or nylon cord of a musical instrument
> > * the action of lagging for break in billiards
> > etc. etc.
>
> But in programming, a string is so universal and has a well defined
> meaning, so you better don't use your exotic string unqualified.

Depends. If it is application that works with UTF-8 texts then std::string
is used a lot. If it is a module that has to cooperate tightly with some
MS API or with Java code or with C# code then the texts are more efficient
to handle as UTF-16. As result ... std::string has next to no usage there,
despite being so universal and what else you said.

> > So you techically say the applications for such domains should use names
> > like 'cord_used_to_tie' instead of 'string' and 'string' unqualified
> > instead of 'std::string'?
>
> Use "yourdomain::string" for your exotic string class and just "string" for
> std::string. And for the case that you are actually inside yourdomain
> namespace, you can still use std::string qualified or if you don't use
> std::string at all, just don't #include <string>.

Can't ... if std::wstring is still used. Why ... now we have IMHO so lot of
complications here just to allow that 'using namespace std'?

> I don't understand why now you are arguing with such convoluted names like
> cord_used_to_tie. I never suggested not using namespaces at all.

That was maybe somewhat silly example on case of string. In general it is
similar to what people often do when they get lot of clashes. Naming thingslike 'electoral_list' or 'mailing_list' instead of 'list' makes sense but
it is easy to go too far there.

> > Or ... if it is really a domain where string
> > means also 'line of characters' then why not to import string into
> > domain namespace with 'using std::string;' and so leave 'std::thread'
> > still unimported?
>
> Why #including <thread> in the first place?

Any standard library header #included has right to #include on its order
any other standard library headers that the implementation sees fit.

Typically it happens so that maintenance adds #include <something> to some
header. <something> includes <other_thing> that clashes. Maintainer gets
strange error messages (not related to <something>) in somewhat related
code. So there 'using namespace std' was the bear trap that waited for that
maintainer and caused him some nuisance he was not prepared for. Yes,
for the under-a-minute fixers of yours it is maybe non-issue.

> > Whole point of namespace std and namespaces in general seems to be is
> > apparently too dim for so lot of people.
>
> The whole point of namespaces actually is, that you don't _have_ to use it
> unless you have a name clash. And if you have one, you can fix it on the
> client side.

But do not you feel that something has been 'broken' if it needs 'fixing'?

Usually I work in scope of some member function of some class in some
namespace. So there are 3 nested name scopes already. I do not need to
qualify names from these scopes. If the class has base class then names
from it too.

External names I either import or alias or use fully qualified. Such importing
and aliasing code is clear and documents my intentions. Nothing ever clashes.

'using namespace' on the other hand is lazy shortcut that imports whole
namespace, documents nothing and unless it causes clashes immediately it
works like time bomb that one needs to fix in the future.

> Otherwise they would not be a real improvement over std_string and your
> cord_used_to_tie.
>
> > First they use "using namespace"
> > a lot. Then they get clashes.
>
> Then they used qualified names...

Yes, indeed, that step I implied. They use that first, to fix clashes.
Still ... they get feed up with fixing clashes and ...

> > Then they fall back to age of in-name
> > qualifiers.
>
> Huh, why that? Are they C programmers?

Because namespaces are broken for coders who use 'using namespace' a lot.

> > Result: the 30+ character names are not too uncommon and the code base
> > looks as an inelegant pile of bloat that it is.
>
> You mean like: yourdomain::yoursubdomain::yoursubdubdomain::list?

No. That is the other edge way how to go too far with namespaces by
by splitting it into small namespaces with long names. C++ has
fortunately a cure to it:

namespace region = thatdomain::thatsubdomain::thatsubdubdomain;

On Monday, 31 December 2012 23:33:03 UTC+2, Balog Pal wrote:
> On 12/30/2012 10:15 PM, Juha Nieminen wrote:
> > The prefix can be really informative on its own right. For example, suppose
> > you see this line of code:
> >
> > if(equal(a, b, c))
> >
> > what does that line tell to you? Not much, really. A function named
> > 'equal', which might be defined *somewhere*, is being called with some
> > parameters. We can't really say where that function might be defined
> > (is it local to the current compilation unit, is it an extern function,
> > is it in some other library, is it a standard function...?) nor do we
> > know anything about those parameters.
> >
> > But now, imagine that the line had been like this instead:
> >
> > if(std::equal(a, b, c))
> >
> > This is a whole lot more informative. Now we know *immediately* that it's
> > a call to a standard function, and we also know what the parameters are
> > (they are iterators or pointers). And even if you didn't know what
> > std::equal() does, at least you know where to look for that info.
>
> A very good example, that should be framed on the wall.

Are you being sarcastic? It is good example.

> Demonstrating the main misconception about code reading (and
> consequently writing).
>
> So, to answer your first question, the first line shout bell:
>
> "that is a predicate function taking three items, not modifying them,
> and returning true if all are equal". The second should bell the same +
> "and it has noise".

That first one maybe is implemented exactly like you describe, who knows.

That second one I know. It certainly requires that the a, b and c are
iterators. There are two iterator ranges compared for equality.
The ranges are [a,b) and [c,c') where c' is as far from c as b is from a.

> The exact signature of the function, the place of its implementation,
> and the other stuff is completely irrelevant. (If you actually need to
> know it's an indication of systemic trouble.)

What? You must always know what the tools that you use do. There are no
universal rules in existence what every function or member function or
functor that happens to have name 'equal' and happens to accept 3
parameters should do.

> OTOH if you're in the marginal situation to need the implementation, it
> is just a click or keystroke away, unless you use some stone-age tools.

Who needs to read implementation of std::equal? It is quite well-documented.
No need to read its implementation to find out what it does.

Öö Tiib <> wrote:
> On Monday, 31 December 2012 16:28:57 UTC+2, Tobias Müller wrote:
>> Öö Tiib <> wrote:
>>> On Saturday, 29 December 2012 16:47:18 UTC+2, Tobias Müller wrote:
>>>> Juha Nieminen <> wrote:
>>>>
>>>>> I think it's a shame that textbooks and tutorials teach such a bad habit.
>>>>
>>>> Actually, I don't understand, why this flame comes up each and every time
>>>> someone writes "using namespace std;".
>>>>
>>>> I can't see why this should be harmful in case of namespace std. Sure, for
>>>> other namespaces it's a different story.
>>>
>>> When someone uses convenient short name that happens is also in std
>>> namespace (like 'thread' or 'list' or 'ref') then things start to clash
>>> and who the poor noob asks about strange error messages that he had
>>> stared at for last two hours? Me of course.
>>
>> And you can tell him the issue in one minute.
>
> Geniuses (who solve any problem under minute) can. For them that 'using
> namespace std' is certainly harmless. I am not one, sorry. I have never
> even met one.

Usually, the error message is something like: the use of identifier 'blah'
is ambiguous, possible candidates are...
This may include some lengthy templated types, but nothing hard to
understand if you read it carefully.

>>> Sure, it is harmful he sat
>>> and stared there *and* it is harmful since more important things
>>> had to wait while I solved such nonsense issue.
>>
>> I don't know if a "C++ programmer" who has to sit and stare more than five
>> minutes to find out a namespace clash can produce many important things in
>> that time.
>
> Lucky you. Congrats. For me ... world is totally different. I do not claim
> to write oh so many important things. C++ code is never simple and short
> like in textbooks for me. It takes some time to see what is going on
> in it.

Sure, but I would assume that error messages from template clashes are not
the most difficult to understand. There may be exceptions, but I've never
met one.

> Example from my sad practice: some non-std::ref (a member function accepting
> same argument) has been assumed by compiler into that std::bind.

I'm sorry but I just don't understand that sentence, so I cannot comment on
that issue.

> The error
> messages are strange and fail to tell anything about 'ref'. If to qualify that
> 'ref' then the problems disappear. Also, problems disappear if to rename
> that member function. That however is not what mine (non-genius) C++ programmer
> noob tries. He thinks that he misunderstood something about how std::bind or
> std::ref works. Googles and reads. Tries different things. Finally, when he
> asks for help frustrated the code is actually wrong too. Then I have to
> understand what he wanted to achieve, what he has written and what there
> actually should be.
>
> If he had never used 'using namespace std' then he could had written it
> himself under 5 minutes yes. So for him and me that 'using namespace std'
> is harmful, for you it apparently is not.

Error messages in C++ compilers are not always helpful or straight forward.
But that's true for almost all nontrivial and sometimes even for trivial
errors, not only the one that you describe.
Over time you'll get a feeling what the message really means.

Anyway, I'm not going to abandon a language feature only because it may
lead to cryptical error messages in some rare cases. I would probably have
to forbid most features of C++.

>>>> If std::string is for strings what int is for integers, then why should it
>>>> be harmful to use it unqualified? You can still use any other string
>>>> classes qualified.
>>>
>>> String may also (depending on problem domain) mean:
>>> * a cord usually used to bind, fasten, or tie
>>> * a plant fiber
>>> * the gut, wire, or nylon cord of a musical instrument
>>> * the action of lagging for break in billiards
>>> etc. etc.
>>
>> But in programming, a string is so universal and has a well defined
>> meaning, so you better don't use your exotic string unqualified.
>
> Depends. If it is application that works with UTF-8 texts then std::string
> is used a lot. If it is a module that has to cooperate tightly with some
> MS API or with Java code or with C# code then the texts are more efficient
> to handle as UTF-16. As result ... std::string has next to no usage there,
> despite being so universal and what else you said.

That's not my point. I meant that string as a sequence of characters (in
whatever encoding and chartype) is such a universal concept in programming,
that you better don't use your exotic string class (representing a cord
used to tie) unqualified if you don't want to deliberately provoke
confusion.
The same is IMO true for most identifiers in namespace std.

>>> So you techically say the applications for such domains should use names
>>> like 'cord_used_to_tie' instead of 'string' and 'string' unqualified
>>> instead of 'std::string'?
>>
>> Use "yourdomain::string" for your exotic string class and just "string" for
>> std::string. And for the case that you are actually inside yourdomain
>> namespace, you can still use std::string qualified or if you don't use
>> std::string at all, just don't #include <string>.
>
> Can't ... if std::wstring is still used.

That last sentence of mine is the least important of the cited paragraph.
It is just a suggestion to omit collisions, not a necessity.

> Why ... now we have IMHO so lot of
> complications here just to allow that 'using namespace std'?

What complications?

>> I don't understand why now you are arguing with such convoluted names like
>> cord_used_to_tie. I never suggested not using namespaces at all.
>
> That was maybe somewhat silly example on case of string. In general it is
> similar to what people often do when they get lot of clashes. Naming
> things like 'electoral_list' or 'mailing_list' instead of 'list' makes sense but
> it is easy to go too far there.

If your list can only contain email adresses, then mailing_list is a very
reasonable name. Much clearer than only list. And if not, then I'd still
prefer a name that tells me the difference to std::list, because if there
is none why not just use std::list.
Like std::map vs. std::unordered_map. Or would you prefer
std::unordered_containers::map?

>>> Or ... if it is really a domain where string
>>> means also 'line of characters' then why not to import string into
>>> domain namespace with 'using std::string;' and so leave 'std::thread'
>>> still unimported?
>>
>> Why #including <thread> in the first place?
>
> Any standard library header #included has right to #include on its order
> any other standard library headers that the implementation sees fit.

True but usually they make only reasonable #inclusions. And I wouldn't call
#including <thread> in <string> a very reasonable decision.
But you're right, to be portable you have to take this into account.

> Typically it happens so that maintenance adds #include <something> to some
> header. <something> includes <other_thing> that clashes. Maintainer gets
> strange error messages (not related to <something>) in somewhat related
> code. So there 'using namespace std' was the bear trap that waited for that
> maintainer and caused him some nuisance he was not prepared for. Yes,
> for the under-a-minute fixers of yours it is maybe non-issue.
>
>>> Whole point of namespace std and namespaces in general seems to be is
>>> apparently too dim for so lot of people.
>>
>> The whole point of namespaces actually is, that you don't _have_ to use it
>> unless you have a name clash. And if you have one, you can fix it on the
>> client side.
>
> But do not you feel that something has been 'broken' if it needs 'fixing'?

What something? Such an error does not appear out of nothing. You have to
make a change to the code or the environment. And if you did not anticipate
all consequences of that change, then your change is broken, not the
existing code nor the C++ language.

> Usually I work in scope of some member function of some class in some
> namespace. So there are 3 nested name scopes already. I do not need to
> qualify names from these scopes. If the class has base class then names
> from it too.

But here we are mainly talking about namespace std.

> External names I either import or alias or use fully qualified. Such importing
> and aliasing code is clear and documents my intentions. Nothing ever clashes.
>
> 'using namespace' on the other hand is lazy shortcut that imports whole
> namespace, documents nothing and unless it causes clashes immediately it
> works like time bomb that one needs to fix in the future.

For arbitrary external code that's of course the best you can do. For the
standard library I don't agree.

>> Otherwise they would not be a real improvement over std_string and your
>> cord_used_to_tie.
>>
>>> First they use "using namespace"
>>> a lot. Then they get clashes.
>>
>> Then they used qualified names...
>
> Yes, indeed, that step I implied. They use that first, to fix clashes.
> Still ... they get feed up with fixing clashes and ...

I don't believe that name clashes with std are so frequent.

>>> Then they fall back to age of in-name
>>> qualifiers.
>>
>> Huh, why that? Are they C programmers?
>
> Because namespaces are broken for coders who use 'using namespace' a lot.

I was only talking about std.

>>> Result: the 30+ character names are not too uncommon and the code base
>>> looks as an inelegant pile of bloat that it is.
>>
>> You mean like: yourdomain::yoursubdomain::yoursubdubdomain::list?
>
> No. That is the other edge way how to go too far with namespaces by
> by splitting it into small namespaces with long names. C++ has
> fortunately a cure to it:
>
> namespace region = thatdomain::thatsubdomain::thatsubdubdomain;

And hope that 'region' does not clash with a real namespace im the future.

But you're right of course. I didn't want to deny the usability of
namespaces at all.

Tobi

On Mon, 2012-12-31, Balog Pal wrote:
> On 12/31/2012 6:30 PM, Jorgen Grahn wrote:
>> On Mon, 2012-12-31, Balog Pal wrote:
>>>>> When someone uses convenient short name that happens is also in std
>>>>> namespace (like 'thread' or 'list' or 'ref') then things start to clash
>>>>
>>>> Or copy, find, read, ...
>>>>
>>>> Perhaps people who don't mind this are people who choose long and
>>>> convoluted names, like we used to do in C? Or use camelCase
>>>> conventions? Personally I tend to come up with function names which
>>>> look like the ones in namespace std, so I almost always spell out the
>>>> std::.
>>>
>>> I definitely would not pass on a review a homegrown class named 'list'.
>>> Honestly can't even imagine an explanation why would one present it so.
>>
>> Since my examples above were functions, would you object to them too?
>
> Functions are a different breed, as they form overload sets.
>
>> How about 'Book find(const Library&)', for example?
>> Would you prefer find_book(), find_in_library(), ... ?
>
> Can't tell without context. The first rule of overload sets is that all
> members have the same semantics. I mean SAME .

That's a rule I was unaware of. I happily break it, all the time.

> A freestanding find()? I'd expect it to need two pieces of info: where
> and what. And return an lvalue or some pointer/index/...

I was unclear (I meant a plain function) and I forgot the key. It
should have been something like:

Book find(const Library&, int id);

/Jorgen

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

On Tuesday, 1 January 2013 16:05:16 UTC+2, Tobias Müller wrote:
> Usually, the error message is something like: the use of identifier 'blah'
> is ambiguous, possible candidates are...
> This may include some lengthy templated types, but nothing hard to
> understand if you read it carefully.

When it just makes overload resolution to fail then that is easy. Then there are
list of ambiguous functions. Function names are only subset of names
in C++ standard library.

> Over time you'll get a feeling what the message really means.

Sure. Things change. Language evolves, compilers and tools get better. Then
I will relearn. Right now I feel that 'using namespace' does wrong thing that I
don't need.

> Anyway, I'm not going to abandon a language feature only because it may
> lead to cryptical error messages in some rare cases. I would probably have
> to forbid most features of C++.

Most people abandon lot of C++ features sooner or later. For example
there are very few who use raw pointer and new[] and delete[] for dynamic
array, majority use std::vector instead. Very rare ever consider overloading
operator,(), operator&&() or operator||(). Very rare use throw in destructor,
very rare call virtual functions from constructor or from destructor. etc.
These are all features that compile to valid code in C++ language.
However ... the behavior may be confusing and error prone so ... lot of
people have abandoned those.

People who avoid that 'using namespace' do it for similar reasons. It makes
code fragile.

> That's not my point. I meant that string as a sequence of characters (in
> whatever encoding and chartype) is such a universal concept in programming,
> that you better don't use your exotic string class (representing a cord
> used to tie) unqualified if you don't want to deliberately provoke
> confusion.
>
> The same is IMO true for most identifiers in namespace std.

There we differ. There are too lot of convenient short names in namespace std
to demand that these names are sacred and should never be used otherwise.
Why authors of C++ did put them into that namespace? I think because they
saw as well that these names can mean entirely other things in some other
context.

> >> Use "yourdomain::string" for your exotic string class and just "string" for
> >> std::string. And for the case that you are actually inside yourdomain
> >> namespace, you can still use std::string qualified or if you don't use
> >> std::string at all, just don't #include <string>.
> >
> > Can't ... if std::wstring is still used.
>
> That last sentence of mine is the least important of the cited paragraph.
> It is just a suggestion to omit collisions, not a necessity.

That last sentence was the only one that did matter to me. Most uses of some
name defined are in the scope where it was defined, IOW within the
namespace of that name. Using it qualified within the same namespace is
strange.

> > Why ... now we have IMHO so lot of
> > complications here just to allow that 'using namespace std'?
>
> What complications?

That I may never use any name from std namespace for something unqualified
even in my own namespace. Or that I may not #include <thread> in my header
because other guys code that includes my header may stop compiling.

> Like std::map vs. std::unordered_map. Or would you prefer
> std::unordered_containers::map?

No, std::map and std::unordered_map are similar containers. I mean things with
clear domain-specific meaning like 'building::floor::map'. That is not like
std::map at all. It prevents unqualified usage of std::map and maybe std::floor
by hiding those. The author of such unqualified usage may be some other person.
So the author of that map may need to use 'building::building_floor::floor_map'
or something like that to avoid breaking (or maintaining) other person's code.
In short ... stammer, just to legalize saving 5 characters 'std::' in few places.

> >> The whole point of namespaces actually is, that you don't _have_ to use it
> >> unless you have a name clash. And if you have one, you can fix it on the
> >> client side.
> >
> > But do not you feel that something has been 'broken' if it needs 'fixing'?
>
> What something? Such an error does not appear out of nothing. You have to
> make a change to the code or the environment. And if you did not anticipate
> all consequences of that change, then your change is broken, not the
> existing code nor the C++ language.

Hmm. There are two things that can cause something to break. Someone did
apply too lot of power or that the something was fragile and easy to break.

Someone wrote code that stops compiling because I started include <thread> in
my class header that they happen to include. Did it break because of their usage
of 'using namespace std' did make their code fragile or did it break because of
my oh so "evil" change?

> I don't believe that name clashes with std are so frequent.
....
> I was only talking about std.

For me the standard library is just a library that is guaranteed to be available
with C++. It has only one namespace, not a forest. The name of it is
short. That namespace contains exceptionally *lot* of quite generic names.
So ... loose usage of 'using namespace std' feels not that profitable
and more prone to clashes.

It is possible that you for example use some naming convention that prevents
clashes, for example you use capitalized names. Then you have 'Game::Map'
and it can no way clash with 'std::map'.

Öö Tiib <> wrote:
> On Tuesday, 1 January 2013 16:05:16 UTC+2, Tobias Müller wrote:
>> Usually, the error message is something like: the use of identifier 'blah'
>> is ambiguous, possible candidates are...
>> This may include some lengthy templated types, but nothing hard to
>> understand if you read it carefully.
>
> When it just makes overload resolution to fail then that is easy. Then there are
> list of ambiguous functions. Function names are only subset of names
> in C++ standard library.

I have no compiler at hand currently, but I believe that class or variable
name conflicts produce similar messages.

>> Over time you'll get a feeling what the message really means.
>
> Sure. Things change. Language evolves, compilers and tools get better. Then
> I will relearn. Right now I feel that 'using namespace' does wrong thing that I
> don't need.

But that's the case with almost all types of error messages.

>> Anyway, I'm not going to abandon a language feature only because it may
>> lead to cryptical error messages in some rare cases. I would probably have
>> to forbid most features of C++.
>
> Most people abandon lot of C++ features sooner or later.

But in most cases for different reasons:

> For example
> there are very few who use raw pointer and new[] and delete[] for dynamic
> array, majority use std::vector instead.

Because those may be dangerous at _runtime_, that's a different story.

> Very rare ever consider overloading
> operator,(),

Sure, most don't even use the builtin one. Still it is not dangerous to use
and I would never criticize somone for using it.

> operator&&() or operator||().

Probably because it is not possible to produce the same short-circuit
behaviour as with the builtin one. It won't do what everyone expects.

> Very rare use throw in destructor,

Can lead to crashes at _runtime_, if done while stack unwinding.

> very rare call virtual functions from constructor or from destructor. etc.

Because it usually makes no sense. Virtual functions are designed to be
virtual, and if they are called statically, they don't do the right thing.

> These are all features that compile to valid code in C++ language.
> However ... the behavior may be confusing and error prone so ... lot of
> people have abandoned those.
>
> People who avoid that 'using namespace' do it for similar reasons. It makes
> code fragile.

But all those other features are either dangerous at runtime or make the
(existing) code difficult to understand. 'using namespace' is neither
dangerous, nor confusing for reading existing code. It may require changes
in the future, when name clashes are introduced, but I find that
acceptable.

>> That's not my point. I meant that string as a sequence of characters (in
>> whatever encoding and chartype) is such a universal concept in programming,
>> that you better don't use your exotic string class (representing a cord
>> used to tie) unqualified if you don't want to deliberately provoke
>> confusion.
>>
>> The same is IMO true for most identifiers in namespace std.
>
> There we differ. There are too lot of convenient short names in namespace std
> to demand that these names are sacred and should never be used otherwise.
> Why authors of C++ did put them into that namespace? I think because they
> saw as well that these names can mean entirely other things in some other
> context.
>
>>>> Use "yourdomain::string" for your exotic string class and just "string" for
>>>> std::string. And for the case that you are actually inside yourdomain
>>>> namespace, you can still use std::string qualified or if you don't use
>>>> std::string at all, just don't #include <string>.
>>>
>>> Can't ... if std::wstring is still used.
>>
>> That last sentence of mine is the least important of the cited paragraph.
>> It is just a suggestion to omit collisions, not a necessity.
>
> That last sentence was the only one that did matter to me. Most uses of some
> name defined are in the scope where it was defined, IOW within the
> namespace of that name. Using it qualified within the same namespace is
> strange.

I never said you must always use "using namespace". Use it where
appropriate.
I myself have almost never conflicts with std. That's why I find it strange
that everytime it is mentioned here someone comments on that even if it's
completely irrelevant.

>>> Why ... now we have IMHO so lot of
>>> complications here just to allow that 'using namespace std'?
>>
>> What complications?
>
> That I may never use any name from std namespace for something unqualified
> even in my own namespace. Or that I may not #include <thread> in my header
> because other guys code that includes my header may stop compiling.
>
>> Like std::map vs. std::unordered_map. Or would you prefer
>> std::unordered_containers::map?
>
> No, std::map and std::unordered_map are similar containers. I mean things with
> clear domain-specific meaning like 'building::floor::map'. That is not like
> std::map at all. It prevents unqualified usage of std::map and maybe std::floor
> by hiding those.

If you use names from namespace std alot in a different contexts, then you
probably should not use "using namespace std", but not everyone does that.

But you are right, it would be nice if we could hide specific identifiers
from a "using namespace".

> The author of such unqualified usage may be some other person.
> So the author of that map may need to use 'building::building_floor::floor_map'
> or something like that to avoid breaking (or maintaining) other person's code.
> In short ... stammer, just to legalize saving 5 characters 'std::' in few places.
>
>>>> The whole point of namespaces actually is, that you don't _have_ to use it
>>>> unless you have a name clash. And if you have one, you can fix it on the
>>>> client side.
>>>
>>> But do not you feel that something has been 'broken' if it needs 'fixing'?
>>
>> What something? Such an error does not appear out of nothing. You have to
>> make a change to the code or the environment. And if you did not anticipate
>> all consequences of that change, then your change is broken, not the
>> existing code nor the C++ language.
>
> Hmm. There are two things that can cause something to break. Someone did
> apply too lot of power or that the something was fragile and easy to break.
>
> Someone wrote code that stops compiling because I started include <thread> in
> my class header that they happen to include. Did it break because of their usage
> of 'using namespace std' did make their code fragile or did it break because of
> my oh so "evil" change?

Either, it's in the same project, then it's your responsability that
everything compiles after your change. Or it's a different project, then
it's the responsability of the person that introduced the new version of
your header.

Changes in header files are almost never without danger if you don't know
all client files.

>> I don't believe that name clashes with std are so frequent.
> ...
>> I was only talking about std.
>
> For me the standard library is just a library that is guaranteed to be available
> with C++. It has only one namespace, not a forest. The name of it is
> short. That namespace contains exceptionally *lot* of quite generic names.
> So ... loose usage of 'using namespace std' feels not that profitable
> and more prone to clashes.
>
> It is possible that you for example use some naming convention that prevents
> clashes, for example you use capitalized names. Then you have 'Game::Map'
> and it can no way clash with 'std::map'.

I have rarely seen lowercase class names except the ones in the standard
library. Also, 99% of the code I work with uses CamelCase names.

At work, we even use Uppercase names for method and function names.

All this is not specifically because of name conflicts, but readability
(CamelCase vs under_score) or convention (Microsoft class and function
names are always Uppercase).

That it helps avoiding conflicts is just a bonus.

My point is, that the feature is not dangerous per se.

Tobi

On 1/1/2013 6:35 PM, Jorgen Grahn wrote:
>> Can't tell without context. The first rule of overload sets is that all
>> members have the same semantics. I mean SAME .
>
> That's a rule I was unaware of. I happily break it, all the time.

Guess then the other people working on the same code are not so happy
. Believe me, it's pretty important one both for functions and
operators. (The usual flamewars about evilness of operator overloading
ar normally based on examples where this rule is broken.)

On 1/1/2013 1:48 PM, Öö Tiib wrote:
> On Monday, 31 December 2012 23:33:03 UTC+2, Balog Pal wrote:
>> On 12/30/2012 10:15 PM, Juha Nieminen wrote:

>>> This is a whole lot more informative. Now we know *immediately* that it's
>>> a call to a standard function, and we also know what the parameters are
>>> (they are iterators or pointers). And even if you didn't know what
>>> std::equal() does, at least you know where to look for that info.
>>
>> A very good example, that should be framed on the wall.
>
> Are you being sarcastic? It is good example.
>
>> Demonstrating the main misconception about code reading (and
>> consequently writing).

no. I meant it literally. Unfortunately a written newsgroup is not the
best medium for discussion, on a live seminar it would just rock.

>> The exact signature of the function, the place of its implementation,
>> and the other stuff is completely irrelevant. (If you actually need to
>> know it's an indication of systemic trouble.)
>
> What? You must always know what the tools that you use do. There are no
> universal rules in existence what every function or member function or
> functor that happens to have name 'equal' and happens to accept 3
> parameters should do.

Well, really, the rule is more general and versed as "Say what you mean,
mean what you say." Guess you read it in several books including
Meyers'. And the extension of it is to mean the same for other people,
not just you (/the original writer).

It is pretty fundamental in quality of code/product and deviations
create opportunity for bugs. One major aspect of code reviews is to
ensure it is observed. If the code reads ambiguous, let alone does not
what it suggests, it's a problem in its own right, and better be fixed
on entry.

On 1/1/2013 3:26 PM, Juha Nieminen wrote:
> Balog Pal <> wrote:
>> "that is a predicate function taking three items, not modifying them,
>> and returning true if all are equal". The second should bell the same +
>> "and it has noise".
>
> Except that "equal()" does *not* do that.

Ok, you're right, and I keep temporarily forgetting that the original
content of std:: it broken in sooo many ways. Including major areas like
naming stuff, consistency, and having introduced an 'iterator' concept
that really is modeled on the pointer pattern rather than the iterator.

I normally don't use the original algos in std:: but similar versions
taking a collection or a Range object instead of a pair of "iterator"s.

Those who actually work with originals are hopefully wide aware that
most times you use two arguments to pass the really one piece of info
you have at hand.

With that addition stick with the semantics posted above (beat me for
poor phrasing

> Without the prefix we are left wondering what it actually does. We might
> *guess* what it does (ie. just compare the three values to the others)
> but, as you wonderfully demonstrate, we would be guessing wrong.

If the example is taken not in abstract discussion, but read in actual
code, where you see what is actually passed, the guessing disappears for
good.

> Using the prefix all ambiguity and guessing is removed. We know exactly
> what it does, and we know it immediately, without having to search for
> the definition of said function.

I keep with my original opinion, that in the context of the project it
is fairly redundant.

OTOH, I have to mention that I'm NOT against using std:: prefix on
*rarely* used or especially broken stuff of the library, and most of the
content in <algorithm> applies.

I DO mind spelling std::vector, string, map and many others that are
generally used, and if the project uses those for different purposes, it
will lead to massive confusion without a good reason. one not really
addressed by prefixes.

On 1/1/2013 1:13 PM, Öö Tiib wrote:
> Example from my sad practice: some non-std::ref (a member function accepting
> same argument) has been assumed by compiler into that std::bind. The error
> messages are strange and fail to tell anything about 'ref'. If to qualify that
> 'ref' then the problems disappear. Also, problems disappear if to rename that
> member function. That however is not what mine (non-genius) C++ programmer
> noob tries.

But what is the root cause? Not having that 'ref' thing in the wild?
What it does? I had situation where several libraries provided ref, but
all did the same thing -- so it worked fine with any, or if name was
ambiguous, it was properly reported. (IMO a direct name clash is not
hard to report, and is useful even it the poorest form, while better
compilers like gcc provide the list of candidates right there).

IMO it is part of good practice to for project management to avoid name
clashes with stuff under control (if that ref class is local, I'd remove
or rename it on discovery), or with third-party stuff have a policy and
known clashes short list compiled. (the policy may be "using directive
forbidden, all names must be used fully qualified", just it better be
considered per library with idea on costs/profits -- and likely limited
to rarely used ones.)

> He thinks that he misunderstood something about how std::bind or
> std::ref works. Googles and reads. Tries different things. Finally, when he
> asks for help frustrated the code is actually wrong too. Then I have to
> understand what he wanted to achieve, what he has written and what there
> actually should be.

On the bright side we have lambda already (I just discovered it works
fine even in VS2010), that can replace so many uses of bind.

> If he had never used 'using namespace std' then he could had written it
> himself under 5 minutes yes. So for him and me that 'using namespace std'
> is harmful, for you it apparently is not.

On the practical side, let's mention good alternatives. we can make a
list of using declarations for the most commonly used things, and
replace the using directive with that #include -- or use such include in
the first place instead of the direct ones. it's not hard to avoid
clashes on the closed set of names, and no more noise is needed further on.