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

191–200 of 231 posts

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

#191

Post by Jtsummers »

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

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.

C++ has had namespaces for a very long time (since the beginning? not sure, I wasn't using computers when it was created), just like those other languages. The name collision issue that it has is the same as them.

And with those C++ namespaces you can do `using some_namespace::some_specific_name;`. Which resolves the issue just like in those other languages.

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

#192

Post by Jtsummers »

tylerchurch wrote: post #181
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…

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.

C++:

  using std::vector;
https://en.cppreference.com/w/cpp/language/namespace#Using-d...

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

#193

Post by _gabe_ »

tialaramex wrote: post #174
CyberDildonics wrote: post #121

Earlier quoted context omitted.

I don't even know what you are trying to say here. C++ is great to program in and has a fantastic eco system of tools and libraries. It is something you can safely base a business around. You won't get "extreme performance" from C++ because it is buried under the weight of decades of compatibility hacks. This doesn't even make sense. What is an example of something that can't be fast because it is done in C++? What "…

> This doesn't even make sense. What is an example of something that can't be fast because it is done in C++? What "compatibility hacks" are slowing programs down? Let's look at two very different perf leaks in ISO C++. Firstly move assignment which is right at the heart of the language. Initially C++ doesn't have move semantics at all, which is a problem because in a bunch of cases that's key to "extreme performance…

In addition to what CyberDildonics already said, C++ is also an (almost) superset of C. You can also inline assembly. If you find particular hot loops that need to be optimized at any point while profiling, it’s trivial to drop down levels of the stack to get the extreme performance you may need. There is no FFI needed in C++ to drop down a level. There is no barrier at all. You can write your code directly for the CPU, inline it into your code, and fine tune it as much as you want. I don’t know how that wouldn’t qualify as extreme performance.

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

#194

Post by JonChesterfield »

jbandela1 wrote: post #91
JonChesterfield wrote: post #38

Earlier quoted context omitted.

I felt some nostalgia for Fortran a while ago. Spent half an hour programming in it, cured. Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process.

>Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process. I have used this library in the past and was actually pretty easy https://github.com/nlohmann/json

A mere 25k lines of self contained C++, bundled in a single header as the one true distribution format. I note the CI cmake script at a thousand lines of cmake. That's a very idiomatic representation of a C++ library, thank you for the example.

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

#195

Post by JonChesterfield »

pantsforbirds wrote: post #114
JonChesterfield wrote: post #38

Earlier quoted context omitted.

I felt some nostalgia for Fortran a while ago. Spent half an hour programming in it, cured. Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process.

If you have any problem that isn't vector math, it's absolutely awful. Even IO is unpleasant

Vector math on raw floating point that is. If you want to wrap that float in a type to force (physical) dimensional consistency, you are going to have a bad time.

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

#196

Post by SubjectToChange »

iso8859-1 wrote: post #84
tejohnso wrote: post #37

Oh, he switched to QT for the GUI chapter. That's a significant change from FLTK. Should be well received as QT is popular in industry. Not sure how the learning curve will be affected.

I wonder what Stroustrup thinks about the Meta Object Compiler. In a way Qt is its own dialect of C++.

The MOC is just a code generation tool, it's about as objectionable as bison. A far greater sin, especially in the eyes of Stroustrup, is disabling exceptions

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

#197

Post by germandiago »

rightbyte wrote: post #167
germandiago wrote: post #144

Earlier quoted context omitted.

Python does well for several reasons. Some that come to my mind: its versatility binding native code and its easy-to-fit in your brain mental model for many tasks. The fact that you can script with Python without a compilation step also helped a lot to spread its popularity I think.

The way you define the entry point function is so bizarre I assume scripting was the original use case.

Could be. But it also gives you the flexibility to set tests inside the module files.

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

#198

Post by SubjectToChange »

JonChesterfield wrote: post #194
jbandela1 wrote: post #91

Earlier quoted context omitted.

>Maybe take a shot at parsing JSON in C++ and see if the nostalgia survives the process. I have used this library in the past and was actually pretty easy https://github.com/nlohmann/json

A mere 25k lines of self contained C++, bundled in a single header as the one true distribution format. I note the CI cmake script at a thousand lines of cmake. That's a very idiomatic representation of a C++ library, thank you for the example.

A mere 25k lines of self contained C++,…

Oh come on now, about 7.5k of those lines are comments and/or blank lines. Furthermore, a good chunk of the code is devoted to type checking, thorough error handling, compiler compatibility and/or workarounds, etc, all within the restrictions of C++11.

… bundled in a single header as the one true distribution format.

Yes, build systems are a significant pain point for C++ and C. Many users prefer to largely avoid the issue and use header-only libraries. That said, Conan and vcpkg are making genuine strides at improving the issue.

I note the CI cmake script at a thousand lines of cmake.

This is ridiculous. It’s a CI script running multiple test suites over dozens of compiler versions, of course it’s going to be a lot. Would it make you feel better if that CI script didn’t exist? If not, then what’s the “correct” size for CI script?

That's a very idiomatic representation of a C++ library, thank you for the example.

The library is genuinely good. It’s portable, well tested, user friendly, and widely supported. Your snark is unwarranted.

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

#199

Post by tialaramex »

boppo1 wrote: post #177
tialaramex wrote: post #109

Earlier quoted context omitted.

Sure, I do not advise people to go learn COBOL either. In fact, I never learned COBOL, they were writing COBOL at the first place I "worked" as a teenager† and it was clearly not the future. † in the UK there was a discrepancy between what happens to the sort of teenager who exhibits talent and interest in an area like writing software, who is sent to just watch adults doing that and mostly doesn't do any actual work…

What is the future?

What is the future now? Or what was the future when I was watching grown-ups programming in COBOL over thirty years ago?

Thirty years ago the future was C++. How did that work out? Seems like it was pretty popular, this thread is about the third edition of a book about it.

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

#200

Post by tialaramex »

_gabe_ wrote: post #193
tialaramex wrote: post #174

Earlier quoted context omitted.

> This doesn't even make sense. What is an example of something that can't be fast because it is done in C++? What "compatibility hacks" are slowing programs down? Let's look at two very different perf leaks in ISO C++. Firstly move assignment which is right at the heart of the language. Initially C++ doesn't have move semantics at all, which is a problem because in a bunch of cases that's key to "extreme performance…

In addition to what CyberDildonics already said, C++ is also an (almost) superset of C. You can also inline assembly. If you find particular hot loops that need to be optimized at any point while profiling, it’s trivial to drop down levels of the stack to get the extreme performance you may need. There is no FFI needed in C++ to drop down a level. There is no barrier at all. You can write your code directly for the C…

> You can also inline assembly.

That's not C++ any more, you can inline assembly into several other languages for whatever that's worth, which isn't much in this context. "But I could use assembly language" is no more C++ having "extreme performance" than "But I could book a minicab" would give the London Underground "24/7 service".

Post reply on HN