Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > New to C++

Reply
Thread Tools

New to C++

 
 
Tiib
Guest
Posts: n/a
 
      12-29-2012
On Saturday, 29 December 2012 11:35:27 UTC+2, Juha Nieminen wrote:
> Tiib <(E-Mail Removed)> wrote:
>
> > The authors say (when asked about that practice) that it makes the
> > examples shorter and so simpler to read.

>
> In the vast majority of cases they make the examples "shorter" by making
> them longer? (After all, you need to write "std::" at least 5 times in
> order to make the program longer than if you had used "using namespace std;"
> instead.


That is what they say. 5 is actually typically reached, most
examples use stream i/o:

std::cout << "octal 42: " << std:ct << 42 << '\n'
<< "decimal 42: " << std::dec << 42 << '\n'
<< "hexadecimal 42: " << std::hex << 42 << std::endl;

However ... not sure, why they believe that it ^ is oh so long
and complex to read.

 
Reply With Quote
 
 
 
 
Tobias Müller
Guest
Posts: n/a
 
      12-29-2012
Juha Nieminen <(E-Mail Removed)> 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.
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.

Tobi
 
Reply With Quote
 
 
 
 
Tiib
Guest
Posts: n/a
 
      12-29-2012
On Saturday, 29 December 2012 16:47:18 UTC+2, Tobias Mller wrote:
> Juha Nieminen <(E-Mail Removed)> 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. 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.

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

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'? 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?

Whole point of namespace std and namespaces in general seems to be is
apparently too dim for so lot of people. First they use "using namespace"
a lot. Then they get clashes. Then they fall back to age of in-name
qualifiers.

Result: the 30+ character names are not too uncommon and the code base
looks as an inelegant pile of bloat that it is.

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      12-30-2012
On Sat, 2012-12-29, Tiib wrote:
> On Saturday, 29 December 2012 16:47:18 UTC+2, Tobias Mller wrote:
>> Juha Nieminen <(E-Mail Removed)> 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


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

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      12-31-2012
On 12/30/2012 10:55 PM, Jorgen Grahn wrote:
>>> I can't see why this should be harmful in case of namespace std. Sure, for
>>> other namespaces it's a different story.


Shouldn't be so much different. IME namespaces appear high on the 'most
abused feature' list. They were introduced so we can handle the clash
problem with 3rd party stuff in some sensible way, that is not in our
control.

Then I see it used to add a ton of noise to our code, and to
deliberately create clashes just to force that noise everywhere.

Another antipattern I see probably comes from java worls in form of
nested, even deeply nested namespaces.

In a project I worked a few years ago, for 40KLOC of code there were
~300 namespaces, at least 3 level deep, with average name count below 5.
And despite heavy use using directives the code was infested with 20+
letter prefixes making it utterly unreadable.

Fortunately no one objected my motion to eliminate all the namespaces in
a single refactoring step.

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


 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      12-31-2012
Juha Nieminen <(E-Mail Removed)> wrote:
> Tobias Müller <(E-Mail Removed)> wrote:
>> Actually, I don't understand, why this flame comes up each and every time
>> someone writes "using namespace std;".

>
> Because teaching people out of their bad habits is a good thing.
> *Not* pointing out those bad habits is not going to help anybody.
>
>> I can't see why this should be harmful in case of namespace std. Sure, for
>> other namespaces it's a different story.
>> 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.

>
> What's the point in having namespaces in the first place if they are not
> going to be used?


What's the point if having namespaces over simple prefixes, if you never
use its members unqualified?

> The whole idea with namespaces is to avoid name collisions. And this is
> not just theoretical. There have been actual concrete projects that have
> become broken because they used, for example, the name "shared_ptr"
> unqualified from the Boost project, after the compiler updated to the
> new C++ standard (which, surprise surprise, these projects also used
> with unqualified names.)


I never suggested using boost namespace unqualified, just namespace std.
But I still don't see why this is dangerous. It's clear that switching to a
new language standard may break some code and it's also easy to fix. It
gives you a compliation error, not a runtime crash.

> Also, using the std:: prefix increases readability and makes the code
> easier to understand. You can spot the usages of standard utilities with
> a quick visual scan, without even having to decipher the code in detail.


std should be used everywhere and as much as possible.

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


So then you are probably also using hungarian notation? It really would be
a shame if you could not read every single detail out of a class or
variable name.
In those rare cases where I don't recognize the use of a std utility I rely
on Intellisense (or similar features in other IDEs).

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


Actually I'm quite sure that you don't use hungarian notation. If someone
uses it here, it often provokes similar comment as yours.
Still, the reason for using qualified namespaces and hungarian notation is
very similar.

I do use hungarian notation sometimes where the type of a variable is not
expressive enough, for example char*: pChar for generic pointer vs.
szString for zero terminated string.
I use qualified namespaces alot, but I can also see the use of unqualified
names.

Tobi
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      12-31-2012
Öö Tiib <(E-Mail Removed)> wrote:
> On Saturday, 29 December 2012 16:47:18 UTC+2, Tobias Müller wrote:
>> Juha Nieminen <(E-Mail Removed)> 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.

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

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

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

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

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

> Then they fall back to age of in-name
> qualifiers.


Huh, why that? Are they C programmers?

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

Tobi
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      12-31-2012
On Mon, 2012-12-31, Balog Pal wrote:
> On 12/30/2012 10:55 PM, Jorgen Grahn wrote:

(attribution lost)
>>> 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?
How about 'Book find(const Library&)', for example?
Would you prefer find_book(), find_in_library(), ... ?

(Here I should point out that I don't know if my find() would be a
problematic name clash -- I never trade away the std:: in std::find.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      12-31-2012
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 .

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

So I could possibly pass something like 'const Book& find(const Library&
where, BookID id)'. If some one part is implied, it will need a name
reflecting it. If it returns a copy of the located item, it should
reflect that too.

> (Here I should point out that I don't know if my find() would be a
> problematic name clash -- I never trade away the std:: in std::find.)


No, functions with the same name don't clash except for really special
cases -- they either hide or form an overload set, and work fine on
invocation. So majority of times they work fine without prefixes on
invocation. Sometimes you may hit ambiguity and need to help out for a
technical reason.

But the important thing is that just reading the code it shall suggest
what is happening really. The is the area name clashes hurt really,
not the technical ground. Reusing the same names for different purposes
usually just create confusion and bugs. You can dodge this problems if
the contexts are distinct. But std:: I consider as an omnipresent
thing, relevant in every context. If not used today, it can be picked up
tomorrow. So I suggest to avoid whatever names it uses -- except when
you aim to exactly match them.


 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      12-31-2012
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.

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

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

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.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Javascript new-new-new-new-newbee weblinkunlimited@gmail.com Javascript 2 03-11-2008 01:15 AM
New computer, New OS, New Wireless Problem :-\ =?Utf-8?B?RGFu?= Wireless Networking 3 07-31-2005 02:11 PM
[Firefox] Use New Tab instead of New Window? paul j Firefox 7 04-07-2005 09:40 PM
Why can not register a new .net passport or a new hotmail account Alick Lv MCSD 1 01-04-2004 06:12 PM



Advertisments