Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

71–80 of 470 posts

Re: In Defense of C++

#71

Post by BeetleB »

im3w1l wrote: post #16
sunshowers wrote: post #4

Earlier quoted context omitted.

Lambdas, a modern C++ feature, can borrow from the stack and escape the stack. (This led to one of the more memorable bugs I've been part of debugging.) It's hard to take any claims about modern C++ seriously when the WG thought this was an acceptable feature to ship. Of course, the article doesn't mention lambdas.

Why wouldn't it be acceptable to ship? This is how everything works in C++. You always have to mind your references.

This is like writing an article entitled "In Defense of Guns", and then belittling the fact it can kill by saying "You always have to track your bullets".[1]

[1] Not me making this up - I started getting into guns and this is what people say.

Re: In Defense of C++

#72

Post by AaronAPU »

loeg wrote: post #45

> in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language. This... doesn't really hold water. You have to learn about what the insane move semantics are (and the syntax for m…

I’ve been programming C++ on a daily basis for more than 20 years and literally never use the >> operator. Never. Not rarely, never.

Re: In Defense of C++

#73

Post by jandrewrogers »

butterisgood wrote: post #49

A pet peeve of mine is when people claim C++ is a superset of C. It really isn't. There's a lot of little nuanced differences that can bite you. Ignore the fact that having more keywords in C++ precludes the legality of some C code being C++. (`int class;`) void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit behavior in C++). C…

> You can do it in C++, but sizeof(EmptyStruct) is 1.

Unless you use the C++20 [[no_unique_address]] attribute, in which case it is 0 (if used correctly).

Re: In Defense of C++

#74

Post by jasperry »

the_af wrote: post #35
jasperry wrote: post #10

The author argues that if rewriting a C++ codebase in Rust makes it more memory-safe, that's not because Rust is memory-safe. What?

You left out the full argument (to be clear, I don't agree with the author, but in order to disagree with him you have to quote the full argument): The author is arguing that the main reason rewriting a C++ codebase in Rust makes it more memory-safe is not because it was done in Rust, but because it benefits from lessons learned and knowledge about the mistakes done during the first iteration. He acknowledges Rust wi…

The argument could be made that rewriting in general can make a codebase more robust, regardless of the language. But that's not what the article does; it makes it specifically about memory safety:

> That’s how I feel when I see these companies claim that rewriting their C++ codebases in Rust has made them more memory safe. It’s not because of Rust, it’s because they took the time to rethink and redesign...

If they got the program to work at all in Rust, it would be memory-safe. You can't claim that writing in a memory-safe language is a "minor" factor in why you get memory safety. That could never be proven or disproven.

Re: In Defense of C++

#75

Post by Night_Thastus »

zahlman wrote: post #39
Night_Thastus wrote: post #23

When it comes to programming, I generally decide my thoughts based on pain-in-my-ass levels. If I constantly have to fiddle with something to get it working, if it's fragile, if it frequently becomes a pain point - then it's not great. And out of all the tools and architecture I work with, C++ has been some of the least problematic. The STL is well-formed and easy to work with, creating user-defined types is easy, it…

> I never want to see another Wheel error until the day I die. What exactly do you mean by a "Wheel error"? Show me a reproducer and a proper error message and I'll be happy to help to the best of my ability. By and large, the reason pip fails to install a package is because doing so requires building non-Python code locally, following instructions included in the package. Only in rare cases are there problems due to…

Unfortunately that Wheel situation was far enough back now that I don't have details on hand. I just know it was awful at the time.

As for significant whitespace, the problem is that I'm often dealing with files with several thousand lines of code and heavily nested functions. It's very easy to lose track of scope in that situation. Am I in the inner loop, or this outer loop? Scrolling up and down, up and down to figure out where I am. Feels easier to make mistakes as well.

It works well if everything fits on one screen, it gets harder otherwise, at least for me.

As for types, I'm not claiming it's unique to Python. Just that it makes working with Python harder for me. Being able to see the type of data at a glance tells me a LOT about what the code is doing and how it's doing it - and Python doesn't let me see this information.

As for debugging, it's great if you have pure Python. Mix other languages in and suddenly it becomes pain. There's no way to step from another language into Python (or vice-versa), at least not cleanly and consistently. This isn't always true for compiled->compiled. I can step from C++ into Fortran just fine.

Re: In Defense of C++

#76

Post by jandrewrogers »

MontagFTB wrote: post #37

When NIST released its summary judgement against C++ and other languages it deemed memory unsafe, the problem became less technical and more about politics and perception. If you're looking to work within two arms' length of the US Government, you have to consider the "written in C++" label seriously, regardless of how correct the code may be.

Nothing is going to happen for the foreseeable future, at least in the parts of government I tend to work with. It doesn't even come up in discussions of critical high-reliability system. They are still quite happy to buy and use C++, so I expect that is what they will be getting.

Re: In Defense of C++

#77

Post by wvenable »

butterisgood wrote: post #55
loeg wrote: post #45

> in C++, you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language. This... doesn't really hold water. You have to learn about what the insane move semantics are (and the syntax for m…

Overloaded operators were a terrible mistake in every programming language I've encountered them in. (Yes, sorry Haskell, you too!) I don't think move semantics are really that bad personally, and some languages move by default (isn't that Rust's whole thing?). What I don't like is the implicit ambiguous nature of "What does this line of code mean out of context" in C++. Good luck! I have hope for C++front/Cpp2. http…

Overloaded operators are great. But overloaded operators that do something entirely different than their intended purpose is bad. So a + operator that does an add in your custom numeric data type is good. But using << for output is bad.

Re: In Defense of C++

#78

Post by sunshowers »

bluGill wrote: post #27
sunshowers wrote: post #4

Earlier quoted context omitted.

Lambdas, a modern C++ feature, can borrow from the stack and escape the stack. (This led to one of the more memorable bugs I've been part of debugging.) It's hard to take any claims about modern C++ seriously when the WG thought this was an acceptable feature to ship. Of course, the article doesn't mention lambdas.

They can, but I find in practice that I never do this so it doesn't matter.

I'm glad, but my problem is with the claim that modern C++ is safer. They added new features that are very easy to misuse.

Meanwhile in Rust you can freely borrow from the stack in closures, and the borrow checker ensures that you'll not screw up. That's what (psychological) safety feels like.

Re: In Defense of C++

#79

Post by beej71 »

It doesn't mention the horrific template error messages. I'd heard that this was an area targeted for improvement a while ago... Is it better these days?

Re: In Defense of C++

#80

Post by zahlman »

Night_Thastus wrote: post #75
zahlman wrote: post #39

Earlier quoted context omitted.

> I never want to see another Wheel error until the day I die. What exactly do you mean by a "Wheel error"? Show me a reproducer and a proper error message and I'll be happy to help to the best of my ability. By and large, the reason pip fails to install a package is because doing so requires building non-Python code locally, following instructions included in the package. Only in rare cases are there problems due to…

Unfortunately that Wheel situation was far enough back now that I don't have details on hand. I just know it was awful at the time. As for significant whitespace, the problem is that I'm often dealing with files with several thousand lines of code and heavily nested functions. It's very easy to lose track of scope in that situation. Am I in the inner loop, or this outer loop? Scrolling up and down, up and down to fig…

Pip has changed a lot in the last few years, and there are many new ecosystem standards, along with greater adoption of existing ones.

> I'm often dealing with files with several thousand lines of code and heavily nested functions.

This is the problem. Also, a proper editor can "fold" blocks for you.

> Being able to see the type of data at a glance tells me a LOT about what the code is doing and how it's doing it - and Python doesn't let me see this information.

If you want to use annotations, you can, and have been able to since 3.0. Since 3.5 (see https://peps.python.org/pep-0484/; it's been over a decade now), there's been a standard for understanding annotations as type information, which is recognized by multiple different third-party tools and has been iteratively refined ever since. It just isn't enforced by the language itself.

> Mix other languages in and suddenly it becomes pain.... This isn't always true for compiled->compiled.

Sure, but then you have to understand the assembly that you've stepped into.

Post reply on HN