Hacker News Reader

Comment by jdsully | Hacker News Reader

Python is likely the best example of this working, however even in Python the boundaries between high and low performance sections are very formal. It's a lot simpler to go in and optimize a piece of code the profiler has pointed out with C++.

I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.

View on HN

I am a C++ developer by career. Me and many other C++ developers I know do not really like the language. It is what it is. It has useful parts, but complexity is a weight.

How do you end up being a C++ developer that hates the language? I’m a C++ developer as well, and if I ever decided that’s I didn’t like what I was doing every day I’d learn a different language and try to get hired for that.

I’ve been an iOS engineer for 7 years and I’m not exactly a fan of Objective-C. I’m good at it though, I know where all the sore spots are and part of my value is I can stop people from hurting themselves with the language. One day, inshallah, our team can eventually move on to swift (thank you ABI compatibility).

Until then I work in it because my goal (and my job) is to deliver amazing products and experiences to my customers and if I had to do that in COBOL, I’d do that too. My job is not about the language for me, it’s about what I’m doing with it.

Non-C++ developers are usually awed by it. The animosity comes from people with experience in C++ that decided not to use it.

Pre-11 C++ was a bad language. The gains of leaving it to something like Java (that isn't even good by today's standards) were huge. The new standards are making it possible to create better code on the language, but it is still far from a modern language and the added features can not remove complexity, they can just add to it.

> the added features can not remove complexity, they can just add to it

There are countless examples of the so-called modern C++ features reducing complexity in code.

For example, it is now considered a code smell to ever write "new" or "delete" in your code. Imagine that, never using these words to manually allocate and delete memory in C++! But it's true, unique_ptr in particular makes so much simpler and safer.

Type inference with auto doesn't just save typing, it improves performance in many cases and reduces a lot of complexity, while also avoiding uninitialized variables.

These are just a few of at least a dozen examples that come to mind about reducing code complexity with more modern C++ features.

I hate unique_ptr and shared_ptr, using them is so glaringly inconsistent. Half the time you can’t construct a unique_ptr when it’s easy, because you don’t have the information until just enough later (like after a calculation or two in the body of your constructor) that you can’t use the easy way. So how do you transfer a unique_ptr? Well, the obvious ways don’t compile, and you eventually learn you have to move it, which involves using std::move(), but it always seems to go in the place I don’t expect it. And then how do you use a unique_ptr outside of your class? You can’t pass by value, for obvious reasons. Pass by reference, maybe? I think that’s frowned upon, I think you’re supposed to pass a naked pointer, and Modern C++ code is supposed to understand that naked pointers mean I’m loaning you this pointer. But I thought the point of Modern C++ was to get rid of pointers? Anyway, shared_ptr works completely the opposite way. You are supposed to pass the pointer by value. Now you can argue that of course it’s supposed to be that way, and the arguments are all cogent and when you spend half a day figuring it all out it makes sense. Until tomorrow when you forget it all and have to actually use the things. Plus I hate underscores with a passion, it hurts to type them. Modern C++ also seems to like making a line of code longer and longer, because you can’t just make a unique_ptr or shared_ptr with a constructor, no, you need make_unique<typename>(...), and the arguments are magically the same as the type’s constructor, even though it’s obviously a different function. Yuck! At least new and delete are pretty obvious how to use, and only have one special case to worry about ([]). Granted, the *_ptr are better, but I hate using them and wish I could use something that was shorter and easier to remember.

The vast majority of the time you just want to pass a reference to the pointed-to object (for both unique_ptr and shared_ptr). Once you've decided what you're actually going to do with the object, that usually determines how you're going to want to pass it.

FYI, you can use a constructor with a shared/unique ptr.

auto p = unique_ptr<Foo>(new Foo());

Totally works, and may be easier to remember if you dont like the "magic" parameter forwarding.

Careful with that if it's not the only thing happening in the statement. It might be a while between the 'new' and the unique_ptr ctor. If an exception happens in between the object will leak.

e.g. foo(unique_ptr<X>(new X), unique_ptr<Y>(new Y)) is a leak waiting to happen.

https://stackoverflow.com/questions/37514509/advantages-of-u...

Very good point! I was only thinking about the specific case of a statement that just makes an object and shoves it into a unique_ptr (e.g. does what make_unique does in the linked Herb Sutter article), in response to the comment about not being able too use a normal constructor. You are totally right that this isn't exception safe in cases like you mentioned.

Small note that this is fixed in C++17: https://stackoverflow.com/questions/38501587/what-are-the-ev...

> I hate unique_ptr and shared_ptr, using them is so glaringly inconsistent.'

They're glaringly inconsistent because they behave differently with regards to ownership, and the fact that you can't copy them or pass them around in certain cases is because they're designed to stop you from doing this as it would undermine the reason you're using the class.

Yes, but that fact is I can't ever remember how to use them properly (unique_ptr in particular). It's not often that you need to pass a unique_ptr to a function outside your class so that it can do something with it (without transferring ownership), so I can never remember how I'm supposed to do it. But it seems like if I want to hand a pointer to a short-lived function, doing it ought to be pretty consistent, whether I'm passing an old-skool naked pointer, a unique_ptr, or a shared_ptr, and it's not.

Like I said, if you look at all the logic, there's a good reason why everything is the way it is. The problem is I can't use the things without looking them up. Usability of my language is a big deal for me, which is why I hate unique_ptr.

> But I thought the point of Modern C++ was to get rid of pointers?

no it's not, it never has been. The point of modern C++ is to get rid of owning pointers.

New features can reduce the complexity of code, but they cannot reduce the complexity of the language.

C++ programmers still need to know what "new" and "delete" do, so they can work with older code that uses them. They also need to learn what "auto" does, so they can work with newer code that uses it. (The behavior of "auto" isn't trivial; how many C++ programmers understand the difference between "auto v = <expr>;" and "decltype(<expr>) v = <expr>;"?)

Why would you ever use or see the latter? Fabricated examples aren't helpful.

Not sure why this was downvoted, decltype was introduced with C++11 alongside of auto for declarations: the example given isn't accurate of reality. A better one might be a function returning auto vs returning decltype(some expression).

Which specific example is choosen doesn't seem all that relevant for the point of "there's these two similar but not identical things people have to/might not understand the difference of"

Picking an example that never occurs is not relevant, because nobody needs to learn the thing that never comes up in practice.

But as you show with your other example, the difference between auto and decltype does come up in practice, even if the example is not a typical one.

Sure: that's why I provided one that reflected the real world more closely.

re-reading: My first comment was addressing the "why might this have been downvoted part", I didn't make that clear enough.

You wouldn't...

...instead you'd use "decltype(auto) v = <expr>", which is equivalent. And people certainly use decltype(auto), or else it wouldn't have been added to the language, 3 years after regular auto.

How does auto improve performance? Doesn't it just expand to whatever type a human would have manually had to put there in the first place?

It allows automatic generic specialization in some cases by the compiler, as you don't have to do template-fu or use a nonspecific type or manually write multiple specializations.

Plus it usually makes the code cleaner by focusing on structure not types. As any construct, it can of course be abused.

I disagree that pre-11 C++ was bad. It would be bad now to make a new language that looked like pre-11 C++ but there is a reason it was so popular.

Its a bit like IE6. A big upgrade over C but the next update took so long that it was hated at the end of its life. Which coincidentally is exactly why C++ now does timed releases.

I worked full-time in C++ from 2012 to 2017, and I don't like the language. I also did feel like I had to use it: I was a developer on an Apache/Nginx webserver plugin, and since those are written in C our choices were (1) C, (2) C++, or (3) a C shim that communicates with some other language. None of these options were ideal, but of them (2) was our best one.

Reply on news.ycombinator.com