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

111–120 of 231 posts

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

#111

Post by Jtsummers »

winwang wrote: post #105
chuckadams wrote: post #60

Know what I like about Stroustrup's code? "using namespace std;". The typical convention of sticking std:: in front of std::every std::last std::bloody std::thing drives me std::insane.

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

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

#112

Post by swatcoder »

UncleOxidant wrote: post #89
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.

All of the 4 AI coding assistants I've tried (claude3, gemini, gpt4, deepseek) used SFML for graphics when I asked them to code boids and game of life in C++. I'm wondering if that's because it's cross platform or that there's more code out there using SFML that these models got trained on? SFML seems relatively recent compared to Qt or even FLTK, so it seems kind of odd that there would be more SFML training data. I…

SFML is more accessible for lightweight/exploratory/educational use, and so I wouldn't be surprised if it appears more often in training data associated with those simple "let's learn" sized projects.

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

#113

Post by spacechild1 »

cuanim wrote: post #74
spacechild1 wrote: post #68

Earlier quoted context omitted.

I started because I became interested in graphics and audio programming. Audio plugin development in particular is completely dominated by C++.

Do you have any recommendations for someone interested in audio programming?

Personally, I started by writing externals for Pure Data, then started to contribute to the core. Later I took the same path for SuperCollider.

You may start with simple audio plugins. Have a look at JUCE (https://juce.com/)!

Realtime audio programming has some rather strict requirements that you don't have in most other software. Check out this classic article: http://www.rossbencina.com/code/real-time-audio-programming-...

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

#114

Post by pantsforbirds »

JonChesterfield wrote: post #38
jdlyga wrote: post #17

I miss my days working with C++. It's moved further down the development stack than where it used to be. We used to handle UI, API parsing, and pretty much everything using C++.

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

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

#115

Post by culi »

HarHarVeryFunny wrote: post #94
chuckadams wrote: post #60

Know what I like about Stroustrup's code? "using namespace std;". The typical convention of sticking std:: in front of std::every std::last std::bloody std::thing drives me std::insane.

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

Conversely,

We write code once, but read it many times, so longer names seems like a poor efficiency choice.

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

#116

Post by steveklabnik »

gorjusborg wrote: post #58
01HNNWZ0MV43FF wrote: post #44

Earlier quoted context omitted.

Not gp but I prefer rust to python and I'm itching to try that "just write your build scripts and stuff in rust too" Sure the builds are slow and Python _kinda_ has static typing, but rust just has a lot of stuff I like and it's practical to install and use natively without learning all the jargon like venvs and eggs and wheels and which package manager and package manager manager (rye?) to use this year I tried Pyth…

The idea of using Rust for scripting is bizaar. I can understand not wanting to use Python for everything, but I see the problem being the 'use it for everything' not the language choice. Use the tool that excels at the job. There is no language that is good at everything.

Incidentally, this thing comes up a lot: Python vs Rust for scripts. I wrote a comparison four years ago:

https://news.ycombinator.com/item?id=22712441

And updated it six months later:

https://news.ycombinator.com/item?id=24595081

That's still how I'd do this task today.

Anyway, I don't think that Rust is always a great choice for scripting, but if you already know Rust, it's totally fine at it.

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

#117

Post by HarHarVeryFunny »

culi wrote: post #115
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.…

Conversely, We write code once, but read it many times, so longer names seems like a poor efficiency choice.

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.

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

#119

Post by OnionBlender »

nicce wrote: post #81
OnionBlender wrote: post #46

My problem with newer C++ books is that all of my projects are stuck using C++17.

If they are purely your projects, then it is just a matter of will :-D

I mean the work projects I work on. Mostly Android NDK stuff that uses C++17.

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

#120

Post by m_nyongesa »

hedora wrote: post #42
hnthrowaway0328 wrote: post #11

Earlier quoted context omitted.

If I just use C with classes, plus smart pointers and auto, for my emulator project(s), would that be a reasonably good approach? I once heard that the C++ language contains 4 components: the first catalog is "C", the second is for OOP, the third is for productivity and flexibility such as stl and templates, and the last one is for special cases such as volatile, asm, etc. He then recommends to use catalog 1 with car…

These days, OO programing is mostly frowned upon. OO added the idea of implementation inheritance to interfaces, and that's mostly a bad idea. Newer languages and modern C++ favor composition instead. You define interfaces that provide some well-defined capability, and then you write things that wrap the interfaces to provide additional functionality. In C++ you can use templates to do this without any runtime overhe…

Do you have a recommended link to a book or tutorial that teaches one how to do composition rather than inheritance in C++ (the way you are describing)?

Thank you in advance!

Post reply on HN