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

151–160 of 231 posts

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

#151

Post by IshKebab »

dlahoda wrote: post #63
IshKebab wrote: post #47

Earlier quoted context omitted.

Same for me. Mainly due to the packaging fiasco (and to a lesser extent, imports). The actual language is not awful. Some features are even nice, like infinite precision integers by default, and separate / and // operators. Language is ok. Setting everything up is atrocious. The other quite annoying thing is that the docs are extremely badly organised so Google rarely points you directly at what you want. Instead you…

poetry with poetry2nix with nix flakes will do magic in terms of setup. if stick with pyright(inference) it is as modern as rust. python speed increases heavily in all directions.

> poetry with poetry2nix with nix flakes will do magic in terms of setup.

I'm sure, but it also sounds like it will take about 2 weeks of reading manuals and learning Nix before I'll get to the same point as Rust and Go start at.

And that's not really an option for big teams, which is the only situation where I'm forced to use Python anyway.

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

#152

Post by beryilma »

b33j0r wrote: post #122
mindcrime wrote: post #3

Huh. The ISBN shown at the top of the page (currently "9780136816485") appears to be incorrect. That seems to be the ISBN for "A Tour of C++" from 2022. The ISBN for this book is, according to the Amazon product page[1], "9780138308681". [1]: https://www.amazon.com/Programming-Principles-Practice-Using... Edit: emailed Mr. Stroustrup and he just replied to say that the bad ISBN has been corrected.

Darn, I don’t think Bjarne sends $2.56 checks. I think you just earned yourself a coveted check for `sizeof(attaboy)`, and I’m jealous.

I still remember "reading" his entire 1000-page C++ book for the sole purpose of finding an error on it, for which I was handsomely rewarded with a $32 check from Bjarne. Still not cashed. Good times...

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

#153

Post by HarHarVeryFunny »

Kranar wrote: post #136
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.…

>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice. I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate. Reading a soup of std::thi…

> This to me seems like a cargo cult justification, where you've heard the argument ...

Well, no, I've been a professional programmer since 1982, and a hobbyist one both before then and to this day.

I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ...

Of course consise code is nice, and while you're in the heat of development it's easy to pretty much memorize an entire codebase, even a large one, but it's when you have to come back to it years later, and barely even recognize the code as your own, that you'll be happy it's self-documenting. Now, on a large team that "future self" may just be the new hire, or the guy who replaces you when you quit ...

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

#154

Post by Jtsummers »

chuckadams wrote: post #148
Jtsummers wrote: post #111

Earlier quoted context omitted.

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

It's certainly not every other language, but Unison has a novel approach to solving the problem of name clashes: function names are just local aliases for a content hash of the function's AST. Compiling involves replacing function names with those hashes, and putting the names back is a matter of pretty-printing. I'm sure there's an arsenal of footguns lurking in Unison's system, but for sure it opens up interesting…

Does that actually solve name clashes? If I have two functions compiled at the same time:

  def foo(n):
    return n + 2
  def foo(n):
    return n * 2
  foo(3) # which one is called?
(I don't know Unison syntax so using Python for the example)

It's still a name clash at compile time.

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

#155

Post by anonymous_union »

Mikhail_K wrote: post #43

[flagged]

c++ is so bad. when i see threads like this one praising it, i feel bad for all the mental energy these people have put into understanding an unorganized and unelegant garbage dump of ideas. even his coworkers at bell labs tried to convince him c++ was a bad idea.

ken thompson wouldn't use it. then he invented go to spite him.

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

#156

Post by HarHarVeryFunny »

nuancebydefault wrote: post #142
HarHarVeryFunny wrote: post #117

Earlier quoted context omitted.

What's the logic of that though? Longer more descriptive names (self-documenting code) help readability, not hinder it. Certainly time to enter code (which is increasingly going to be automated) should be the last consideration - if we're considering full software lifecycle then coding probably takes up some small single-digit percentage of the time we're interacting with the code.

Longer names are harder to read. Think about any math formula. Does energy=mass * math::powerf(speed_of_light, 2) read more fluently? Context matters. Make sure the context is ways clear and code is written there where it belongs. Then names can be shorter while being readable.

I'm not sure that's a great example. Of course e = mc^2 is so iconic and well known that most people know it, and will probably even perceive it as a whole. Once you recognize it then no need to explain what e, m and c are.

However, most code is not that obvious, and in the real world you're probably not looking at one mystery line of code who's function becomes obvious by context - you are more likely looking at entire functions or blocks of code, maybe without comments, trying to figure out what is going on. Try inheriting 10K of mostly undocumented code, and then you'd probably be a lot more grateful that the original author used descriptive names and comments, even though he knew what it all meant when he wrote it.

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

#157

Post by AnimalMuppet »

weinzierl wrote: post #107
AnimalMuppet wrote: post #95

Earlier quoted context omitted.

Having to use the wrong tool is not cool, ever. So I don't care how cool Rust is right now, I still am not going to use it for scripting.

Have you tried it? How would you know that Rust is the wrong tool. I'm indifferent when it comes to Python vs Rust for scripting, but I'd take Rust over a shell script (of any variety) any day.

There are many things I have not tried, ranging from Rust to heroin. "You don't know because you haven't tried it" is really bad epistemology.

It's also totally impractical. Rust isn't the only language I haven't tried; there are more than a thousand of them. I'm not using JOVIAL for scripting, or Fortran, or a bunch of others. No, I haven't tried any of those either. No, I'm not going to.

Turning specifically to Rust, I don't use it for scripting because it's not what I look for in a scripting language. It's compiled; I look for a language that doesn't have that extra step. It has the borrow checker; I don't write scripting code that needs that level of discipline and care.

In fact, most of my scripting is of the form "pick some bits out of a text file". For that, Perl is my tool of choice. Sure, other languages have regexes. None of them do it as cleanly and simply as Perl. (Note well: "clean" does not apply to the Perl syntax...)

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

#158

Post by [deleted] »

mindcrime wrote: post #3

Huh. The ISBN shown at the top of the page (currently "9780136816485") appears to be incorrect. That seems to be the ISBN for "A Tour of C++" from 2022. The ISBN for this book is, according to the Amazon product page[1], "9780138308681". [1]: https://www.amazon.com/Programming-Principles-Practice-Using... Edit: emailed Mr. Stroustrup and he just replied to say that the bad ISBN has been corrected.

[deleted]

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

#159

Post by PaulDavisThe1st »

rightbyte wrote: post #135
VHRanger wrote: post #129

Earlier quoted context omitted.

Let me carefully copy paste my personal stringutils.hpp file of string handling routines and I'll be right up to it!

Gotta have those "readfile()", "replace_substr()", "split()" etc! I do have a copy paste string util header. .. I really wish there were more string util functions in Cpp. I mean C had strtok()!

strtok() is one of the most dangerous string handling functions in any language!

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

#160

Post by xdavidliu »

aquir wrote: post #147

Great but I am unable to find an IDE or compiler that supports C++ 20 and every one of them complains about import std; Any recommendations?

I ran into this the last time I tried reading this book. It's supposed to be for beginners; how would a beginner get around this?
Post reply on HN