Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

stroustrup.com

Post reply on HN
Print view View original

181–190 of 231 posts

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#181

Post by tylerchurch »

Jtsummers wrote: post #111
winwang wrote: post #105

Earlier quoted context omitted.

Yep, although I do like not having clashing names. But I mean... somehow every other language solved this.

> But I mean... somehow every other language solved this. Did they? C, Lisp, Rust, Python, Ada, Go, Java, C#, ... They all require you to qualify conflicting names if some other characteristics (for instance the number or types of arguments) don't provide enough information, or outright don't permit it (C, since it has no notion of name spaces). Can you point to the "every other language[s]" which have solved this pr…

If C++ was JavaScript you would do:

import {vector} from 'std';

Which I think is a reasonable compromise, you're only bringing vector into scope rather than all of the standard library.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#182

Post by randomname93857 »

xdavidliu wrote: post #165

I find it really problematic that the "classic first program" in this book includes "import std;" as the very first line, and as far as I know not a single compiler with the possible exception of MSVC supports that out of the box. Writing this on a debian machine, and trying "g++ --std=c++23 -fmodules-ts" does not work, and from https://en.cppreference.com/w/cpp/23 looks like the "paper" for this is P2465R3, for whic…

would this help with your problem with modules, it's referenced on the book's page: https://www.stroustrup.com/module_use.html ?

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#183

Post by yellowstuff »

pklausler wrote: post #96
ChuckMcM wrote: post #90

Earlier quoted context omitted.

I was teaching one of the local highschool kids how to program in C and they asked "So why does everybody use i,j, and k for their indexes in loops?"

I only use 'j' and 'k', not 'i ' -- the rarely-used letters are easier to search for.

ii is also good.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#184

Post by HarHarVeryFunny »

Kranar wrote: post #170
HarHarVeryFunny wrote: post #169

Earlier quoted context omitted.

> But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names? Do you always suppose that the people you are talking to are morons and cargo-cultists? Rhetorical question - have fun.

I like to present questions to people to justify their position so that others reading the advice can better evaluate it, understand the reasons and make a more informed judgement on it. I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming…

> which is that longer names are better than shorter names, or whether the advice you learned was that descriptive names are better than non-descriptive names

Are you even a developer?

In the programming world "longer names" is universally understood (except apparently by you) to mean "longer due to being more descriptive". NOBODY thinks that making identifier names longer just for the hell of it beneficial.

It's as if a chess player is describing to you the importance of controlling the center of the board, and you are wondering out load if they mean controlling it by clamping it to the table.

Perhaps you think suggestions like this make you sound smart. They don't.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#185

Post by wakawaka28 »

ryandrake wrote: post #175
HarHarVeryFunny wrote: post #94

Earlier quoted context omitted.

It depends ... You should NEVER have "using namespace" (for any namespace) in a header file, since that is how you create name clashes, which is what the namespaces are there to avoid. I don't personally like "using namespace std;" even in implementations, since I think it makes code less readable, and the contents of std:: is so large, and growing, that I'd again prefer to just avoid the possibility of name clashes.…

Not only that, but you have no idea what's going to be put into the standard tomorrow. If code I write today has a class called bubble_sorter, and then one day, the C++ standard library decides to add std::bubble_sorter, then: 1. If I had "using namespace std;" then all of my code is suddenly broken. 2. If I didn't have it, I'm fine. Also, and this is just personal preference, but I simply like to be able to clearly…

>If I had "using namespace std;" then all of my code is suddenly broken.

If this happened and if you included that specific header, you would get a simple compiler error due to ambiguous methods. Then you can simply add a namespace somewhere and move on. I know sometimes this can involve a lot of changes (if we're talking about other `using namespace ...` usage) but in general you're not gonna have problems.

If you're really worried about this, you can move the statement closer to where you need it. This is very helpful for dense code that you normally want to be verbose.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#186

Post by Kranar »

HarHarVeryFunny wrote: post #184
Kranar wrote: post #170

Earlier quoted context omitted.

I like to present questions to people to justify their position so that others reading the advice can better evaluate it, understand the reasons and make a more informed judgement on it. I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming…

> which is that longer names are better than shorter names, or whether the advice you learned was that descriptive names are better than non-descriptive names Are you even a developer? In the programming world "longer names" is universally understood (except apparently by you) to mean "longer due to being more descriptive". NOBODY thinks that making identifier names longer just for the hell of it beneficial. It's as…

Which is why that advice confuses the metric for the principle.

This is your exact quote:

"We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice."

And the point being made is that there are cases where shorter names are actually more readable than longer names and one of those cases is when every name shares a common prefix. By prefixing everything with something common code becomes more uniform, and names become less distinctive and consequently less readable because it's harder to identify and differentiate sections of code. Code ends up looking like a soup of std::s everywhere.

It would be like a chess player who only tries to control the center because someone told them that controlling the center is important, but then repeatedly loses to the King's Indian Defense [1] because they never took the time to fundamentally understand why the center is important and so they don't realize how the King's Indian Defense is used precisely to destabilize the center of the board with sharp angles of attack.

They just blindly apply what they hear... and let me tell you there are plenty of mediocre chess players who do just that.

In almost any field from programming to chess to sports, you can find guidelines and good rules of thumb and I do not want to discourage people from knowing those rules because having heuristics certainly improves productivity. But don't ever let those rules become dogma; at some point it's worth understanding what the principles behind those rules are, when do they apply and when don't they apply.

>Are you even a developer?

Note that you keep trying to make this discussion personal whereas I have kept this discussion about the topic and the argument.

I would respectfully ask you to do the same, let's discuss the topic and avoid making this personal. It's irrelevant how long you've been programming for or how long I've been programming for or even if I am a programmer at all.

Trying to justify arguments on the basis of who you are or who I am is a poor way to go about engineering best practices.

What matters is whether your points can be justified.

[1] https://en.wikipedia.org/wiki/King%27s_Indian_Defence

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#187

Post by spacechild1 »

Kranar wrote: post #134
spacechild1 wrote: post #65

Earlier quoted context omitted.

Not sure what you are trying to say here. Qt, the library, and QtCreator, the IDE, are completely separate products. You can use QtCreator without Qt and vice versa. Now, I'm pretty sure you know that, hence my confusion...

Qt Creator makes working with Qt a heck of a lot easier in a way that working with Visual Studio or vim does not. It comes with an integrated Qt form designer, Quick Designer for QML, supports Qt's moc syntax out of the box, integrated support for Qt Test Integration, native support for Qt Assistant and documentation and integration with Qt's internationalization tools. The idea that "QtCreator" is some totally indep…

> that just coincidentally happens to have the letters Qt at the beginning

That's not what I was trying to say. I just thought it's worth pointing out that QtCreator is really a general-purpose C++ IDE. (It's my favourite C++ IDE, btw.)

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#188

Post by Kranar »

spacechild1 wrote: post #187
Kranar wrote: post #134

Earlier quoted context omitted.

Qt Creator makes working with Qt a heck of a lot easier in a way that working with Visual Studio or vim does not. It comes with an integrated Qt form designer, Quick Designer for QML, supports Qt's moc syntax out of the box, integrated support for Qt Test Integration, native support for Qt Assistant and documentation and integration with Qt's internationalization tools. The idea that "QtCreator" is some totally indep…

> that just coincidentally happens to have the letters Qt at the beginning That's not what I was trying to say. I just thought it's worth pointing out that QtCreator is really a general-purpose C++ IDE. (It's my favourite C++ IDE, btw.)

It can be a general-purpose C++ IDE and also very tightly coupled to Qt at the same time.

Visual Studio is also a general-purpose C++ IDE and yet I don't think anyone would say it's independent of Windows.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#189

Post by Kranar »

Jtsummers wrote: post #111
winwang wrote: post #105

Earlier quoted context omitted.

Yep, although I do like not having clashing names. But I mean... somehow every other language solved this.

> But I mean... somehow every other language solved this. Did they? C, Lisp, Rust, Python, Ada, Go, Java, C#, ... They all require you to qualify conflicting names if some other characteristics (for instance the number or types of arguments) don't provide enough information, or outright don't permit it (C, since it has no notion of name spaces). Can you point to the "every other language[s]" which have solved this pr…

Most languages you mention let you import the individual names that you want, and you can resolve potential clashes at the point of import. In C++ you basically ```#include``` a file and with it comes a flood of names that are often times unpredictable.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#190

Post by adrian_b »

xdavidliu wrote: post #165

I find it really problematic that the "classic first program" in this book includes "import std;" as the very first line, and as far as I know not a single compiler with the possible exception of MSVC supports that out of the box. Writing this on a debian machine, and trying "g++ --std=c++23 -fmodules-ts" does not work, and from https://en.cppreference.com/w/cpp/23 looks like the "paper" for this is P2465R3, for whic…

The current gcc documentation (13.2.1) says:

  "_Standard Library Header Units_
     The Standard Library is not provided as importable header units.
     If you want to import such units, you must explicitly build them
     first.  If you do not do this with care, you may have multiple
     declarations, which the module machinery must merge--compiler
     resource usage can be affected by how you partition header files
     into header units."
So for now any "import" can work only if one writes appropriate module files first.

Nevertheless, I do not expect that the updating of the standard C++ library of gcc will take a long time, so later this new book will become directly usable as it is.

For someone who already knows older C++ and just wants to update their knowledge, writing the corresponding module files can be a good learning experience in itself.

Post reply on HN