Hacker News Reader

Comment by uwuemu | Hacker News Reader

For me 2022 was the year of learning C++ (background in C# and Php) and I must say that after being intimidated by the language (extensive use of pointers, stack/heap compile/run time allocation and deallocation, templates) for years, when I really took a proper look and got some practice, it is an incredible language. The command an control you get by working with memory and the system on a lower level is amazing. I found it so much easier to learn (once I got the grasp of the cpp way of doing things) than something like Rust. All the higher level advanced concepts work and flow beautifully as you'd expect based on the lower level of the language... and the amount of "magic" is kept to minimum... you can just open std and look at what is being done and it all males sense. I understand why people want to move from C++ but as a newbie in this language, I find it amazing.

View on HN

It's all sunny until valgrind / asan fail to reveal the source of an elusive "Uninitialised value was created by a stack allocation"

I work on a C++ project and actually sympathise with this sentiment. It's a massive strategic risk to our org, we pay a consistent tax in reduced productivity and stupid bugs, and I will advocate migrating away as soon as we have a suitable destination (Carbon looks promising).

But, I do also really enjoy writing C++! I'm optimistic that writing Carbon/Val/whatever ends up gaining traction in the industry will be just as good though.

Are you using legacy C++ or modern C++?

Quite modern! A few of the latest features we don't use yet but overall it's pretty up-to-date. Also no exceptions.

> I find it amazing.

This shall pass :)

The main beef with C++ is that it's just a mass of every single feature possible held together with some goo. It works, but there's no grace and elegance.

It is really only the fact that everyone writes C++ a little bit differently. From the outside this looks like C++ is a mess, but in reality, you can pick and choose what you like, and that's exactly what people do. You can be as safe or as unsafe as you need to be. That, of course, also opens the door for beginners to accidentally write unsafe code for a long time before they know all the footguns.

I think the real dent in C++ comes from wholesale improvements to languages by adding package management, one-liner built-in toolchains, built-in testing and build system. I could write paragraphs about why this is a good thing but we all know why.

CMake is making an effort in making it easy to fetch content for your build system, including Git repos, so there are paths to take today, but you need to learn a lot of separate things just to get started with C++. What are the chances that a beginners C++ tutorial gives you all the best practices in a way that a newer language does by default?

Learning C++ will probably look like the experience of using a web server with poor defaults, a strange configuration language, and thousands of different tutorials detailing a 20-year period of changes.

If I were to host content today I would not use Apache or nginx - I would probably start with Caddy and go from there.

> improvements to languages by adding package management, one-liner built-in toolchains, built-in testing and build system. I could write paragraphs about why this is a good thing but we all know why.

Not everybody shares this sentiment. I think it's great to be able to get yourself up and running quickly, and start dabbling with the language immediately, but I also think that at the same it is not so great because there is no "one size fits all purpose". I, for instance, happen to value the latter more than the former.

FWIW, I also wrote a lot of C++ for the first time last year, and found the lack of

> package management, one-liner built-in toolchains, built-in testing and build system

To be by far the least pleasant things about the language, especially C++20 where things like concepts are wonderful to use, but then you can't rely on having a toolchain that actually supports it. The most recent xcode/Apple Clang do not, so on Mac you need to find your lib(std)c++ elsewhere.

It'd be great if there were at least some way to make this easy, e.g. to create a virtual environment that sets all paths correctly. Or if the compiler from a toolchain would default to using its own headers and libraries instead of defaulting to the system's. (I assume they don't for a combination of historical reasons, and that you'd then you may be unable to link to system libraries due to things like mismatched std libraries).

Preferably, there would also be a GitHub Action to do it to make CI easier to set up.

> but then you can't rely on having a toolchain that actually supports it.

C++20 is still a bleeding edge so I'd advise you to pick C++17 or even C++14 if you want to have pleasant cross-platform coverage. That's what most companies with the goal of true cross-platform support will do. 3-year window time for compiler and library devs is really hard, especially given how many new features were introduced to C++20. And now consider how many different vendors there are ... https://en.cppreference.com/w/cpp/compiler_support numers them 12 but it doesn't count the ones from embedded space for example and probably some other are missing too, so 20? What we want to see on the paper hardly can match the much more complex reality.

> The most recent xcode/Apple Clang do not

It's a PITA, as usually found with Apple, especially considering that all other major compilers including GCC, Clang, MSVC and ICC work just fine: https://godbolt.org/z/Mj6ehq57v

> so on Mac you need to find your lib(std)c++ elsewhere.

This wouldn't work because concepts aren't a library feature but a compiler feature so perhaps your best bet would be to see if you can use vanilla clang or GCC to compile the code on Apple machines. I am not an expert here.

Generally it is the people coming from C or C++98 who write unsafe code. People picking up C++20 start out using it safely, and continue.

While C++ is the one with more features, the same can be said about Java 20, Python 3.11, C# 11, Haskell 2021,... when comparing against their version 1.0.

The problem of C++ is that its features are not just additive. In most languages, if you take two features and use them both, they add up. In C++, they may actively interfere with one another.

I gather you don't have much use of the latest versions of the languages I mentioned, in all of them I can think of examples that don't add up.

I’d be curious which Python features don’t work together?

One example sorted out with Python 3 would be old style classes and new style ones.

Other would be tracking down if attributes get dynamically changed via __dict__, __slots__, and how __slots__ interact with each other if multiple definitions happen to exist.

The way numeric division and remainder changed between Python 2 and 3.

I think you’re talking about a different issue here.

The person you replied to previously was talking about how certain new C++ features don’t work together. For example move with a lambda can cause UB.

You’re talking about changes to the language or if you have a conflict of definition.

All of that are changes/features regardless of which form they take.

No.

They’re talking about feature incompatibility within a single version.

You’re talking about feature differences between different versions.

Completely different things.

I doubt you can present even just a single example. All languages' features combine multiplicatively.

The rule of 0/3/5 literally exists because the default behaviours misinteract with any override of the rest.

Yeah, that doesn't qualify. It is all one feature: override copy or move semantics, and there is a prescribed way to do it. Rule of zero, of course, is the norm, and is an extremely beneficial interaction.

2nd try?

> Yeah, that doesn't qualify.

It absolutely does.

> It is all one feature: override copy or move semantics, and there is a prescribed way to do it.

And yet rather than force you to do it the language just goes into the weed and generates complete nonsense.

C++ gets special treatment for some reason when it comes to backwards compatibility and modern language features.

Oh no! we got threads and timers! C++ recognized the existence of file systems and regular expressions, woe I say! Polymorphic lambdas? I've got std::bind1st haha! Wait, not atomic! Anything but that!

> In most languages, if you take two features and use them both, they add up.

Java nio vs. io

Java Reader vs. InputStream (not necessarily the interfaces themselves, but the redundancy between them eg should I use InputStream -> BufferInputStream -> InputStreamReader? Or InputStream -> InputStreamReader -> BufferedReader?)

Java float[] vs. ArrayList<Float> vs Vector<Float> vs. FloatVector vs. FloatBuffer - just how many ways can we describe "a linear allocation of numbers" in Java at this point? And they're still adding new ones!

So no, other languages don't just magically handle this more gracefully than C++ does. If a language is successful, it will either suffer from this or it'll stagnate - it's the natural consequence of preserving backwards compatibility while adding new features & capabilities.

Don't forget Date/Time classes. Absolute mess.

Something that .NET also missed to fix.

Reader is for text/characters while InputStream is for bytes. An InputStream always lays at the heart of a Reader. Java's I/O may not be the most elegant of simplest, but it makes additive sense assuming you don't just have a bone to pick with the language.

The float examples are artifacts of pragmatism between plain old data types versus heap allocated objects. Though I do admit Vector<Float> is absolutely obsolete and should be avoided. The others have a clear purpose and raison d'être.

Now java.util.Date on the other hand…

> The others have a clear purpose and raison d'être.

Yes, but they don't compose cleanly together. As in, I can't just use FloatVector in all places that took a FloatBuffer previously or whatever. They aren't additive in an incremental migration sense, they are additive in the "these are just wholly unrelated APIs in their own wholly distinct silos" sense. Aka, the thing C++ is regularly slammed for doing even though it's additions aren't even this clunky.

... are there really people who go into their office job and think "oh this tool I'm using needs more grace or elegance?". If I had a carpentry company and my employees complained that their hammers and nails weren't elegant enough... I'd quickly look for new employees.

Yes, but I think this is the ultimate fate of most successful languages. New languages start small and elegant, and everyone raves over them, then over time new features get added, and added ... and eventually the elegance and othogonality disappear. If this was a program rather than a language, now would be the time to refactor, but you can't because of backwards compatibility, so eventually you get to c++-like bloat. I actually like c++ -, but it's definitely out of control at this point.. although many people just ignore the bleeding edge features and basically code in something closer to c++11.

Languages really need to evolve to stay alive, but the evolution will eventually kill them!

I agree. It is honestly a fine language IMO and while I have nothing against Rust, I also haven’t had much of an interest or incentive to use it. Yes, buffer overflow is a thing - it’s never been an issue in my experience. Use after free and memory leaks are infrequent, easy to fix, and caught early.

Golang is not a real replacement because 1. Golang core devs are too opinionated on random shit and make some things very hard to do without reinventing the wheel because “you shouldn’t do that” partially because it’s a corporate-owned language 2. GC. There are other minor things but those are the big ones, it’s still an excellent backend language but can’t replace C++.

Besides Rust everything else is a toy without stability and backwards compatibility and/or lack of libraries. Rust is fine, it’s just that the problems it tries to solve aren’t something that experienced C++ devs often struggle with.

> Besides Rust everything else is a toy without stability and backwards compatibility and/or lack of libraries. Rust is fine, it’s just that the problems it tries to solve aren’t something that experienced C++ devs often struggle with.

The single main reason for Rust's success is that this statement was proven wrong again, again and again. C/C++ devs kept repeating it, severe bugs keep getting discovered.

Yep, I totally agree. I took a long break from C++ after I learned the basics at university. I got into it again one and a half years ago when I needed really fast code and I was pleasantly surprised how easy it is. I'm exclusively using smartpointers and I very rarely run into scenarios where I have problems with memory leakage, etc.

Since I had written the prototype in Java and now interface with Javascript/Typescript, I'm really amazed how clean and well-reasoned my C++ side of the program is. So yeah, I'm also really happy with the state C++ is in right now.

Why was this comment flagged? C++ haters... really?

It doesn't deserve a flag, but the sunny optimism feels delusional. It's obvious that C++ has problems and there's obvious red flags like why someone like Linux Torvalds vehemently hates the entire language.

The poster addresses none of this and has a overly positive attitude towards C++. There's obvious nuance on this topic that the post fails to address and he instead just preaches to a biased choir. At least he admits he's a beginner.

> All the higher level advanced concepts work and flow beautifully as you'd expect

Are we talking about the same language? C++?

Also started learning C++ last year. Can concur.

What resources were you using to learn C++ that made "All the higher level advanced concepts work and flow beautifully"?

A tour of C++, third edition.

Reply on news.ycombinator.com