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

401–410 of 470 posts

Re: In Defense of C++

#401

Post by jcelerier »

o11c wrote: post #350
jcelerier wrote: post #205

Earlier quoted context omitted.

Not sure I understand, since they're available in c++ designated initializes are one of the features I use most, to the point of making custom structs to pass the arguments if a type cannot be changed to be an aggregate. It makes a huge positive difference in readability and has helped me solve many subtle bugs ; and not initializing things in order will throw a warning so you catch it immediately in your ide

The problem is that there are a lot of APIs (even system and system-ish ones) that don't want to specify the order of their fields (or outright differ between platforms). Or that can't use a meaningful order due to ABI compatibility, yet the caller wants to pass fields in a meaningful order.

platform APIs like this are likely much less less than 1% of the things I call in my codebases. The few files i have open right now have absolutely no such call.

Re: In Defense of C++

#402

Post by jcelerier »

zbentley wrote: post #309
jcelerier wrote: post #200

Earlier quoted context omitted.

> Overloaded operators like operator*() and operator you don't need to understand what an overloaded operator is doing any more than you have to understand the implementation of every function you call, recursively

I mean, you kinda do. Otherwise you won’t understand why bit-shifting to std::cout prints something, which is pretty much day 1 of C++ hello world introduction (yes, I know there are introductions that don’t use that silly syntax sugar. They’re rare, like it or not.) Like, sure, you don’t have to understand cout’s implementation of operator That’s … a lot more to learn than, say, printf.

> I mean, you kinda do. Otherwise you won’t understand why bit-shifting to std::cout prints something,

but it's not bit-shifting, it's "<<", which can do different operations in different contexts.

Re: In Defense of C++

#403

Post by tialaramex »

jandrewrogers wrote: post #69
butterisgood wrote: post #55

Earlier quoted context omitted.

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…

A benefit of operator overloads is that you can design drop-in replacements for primitive types to which those operators apply but with stronger safety guarantees e.g. fully defining their behavior instead of leaving it up to the compiler. This wasn't possible when they were added to the language and wasn't really transparent until C++17 or so but it has grown to be a useful safety feature.

However C++ offers several overloads where you don't get to provide a drop-in replacement.

Take the short-circuiting boolean operators || and &&. You can overload these in C++ but you shouldn't because the overloaded versions silently lose short-circuiting. Bjarne just didn't have a nice way to write that so, it's not provided.

So while the expression `foo(a) && bar(b)` won't execute function bar [when foo is "falsy"] if these functions just return an ordinary type which doesn't have the overloading, if they do enable overloading both functions are always executed then the results given to the overloading function.

Edited:: Numerous tweaks because apparently I can't boolean today.

Re: In Defense of C++

#404

Post by magnushiie »

QuiEgo wrote: post #329
estimator7292 wrote: post #316

Earlier quoted context omitted.

Have you written significant amounts of C or C++? Most people don't write C, nor use the C compiler, even when writing C. You use C++ and the C++ compiler. For (nearly) all intents and purposes, C++ has subsumed and replaced C. Most of the time when someone says something is "written in C" it actually means it's C++ without the +± features. It's still C++ on the C++ compiler. Actual uses of actual C are pretty esoter…

Sending out a strong disagree from the embedded systems world. C is king here. (Broad, general, YMMV statement): The general C++ arc for an embedded developer looks like this: 1.) discover exceptions are way too expensive in embedded. So is RTTI. 2.) So you turn them off and get a gimped set of C++ with no STL. 3.) Then you just go back to C.

Skype was written without exception handling and RTTI, although using a lot of C++ features. You can write good C++ code without these dependencies. You don't use STL but with cautious use of hand-built classes you go far.

Today I wouldn't recommnend Skype built in any language except Rust. But the Skype founders Ahti Heinla, Jaan Tallinn and Priit Kasesalu found exactly the right balance of C and C++ for the time.

I also wrote a few lines of code in that dialect of C++ (no exceptions). And it didn't feel much different from modern C++ (exception are really fatal errors)

And regarding to embedded, the same codebase was embedded in literally all the ubiquitous TVs of the time, even DECT phones. I bet there are only a few (if any) application codebases of significant size to have been deployed at that scale.

Re: In Defense of C++

#405

Post by palata »

Defletter wrote: post #385
palata wrote: post #378

Earlier quoted context omitted.

> But this is why Debian is so revered: they understand this dynamic and so maintain repositories that can be trusted. So you do understand my point about AUR. AUR is like adding a third-party repo to your Debian configuration. So it's not a good example if you want to talk about official repositories. Debian is a good example (it's not the only distribution that has that concept), which proves my point and not yours…

Your defensiveness is completely hindering you and I cannot be bothered with that so here are some much needed clarifications: > I am not a C/C++ cultist at all, and I actually don't like C++ (the language) so much (I've worked with it for years). I, for one, do not love it when there is an exploit in a language package manager. If you do neither of those things then did it ever occur to you that this might not be ab…

> Your defensiveness

Start by not calling everybody disagreeing with you a cultist, next time.

> I said system package, not official repository. I don't know why you keep insisting on countering an argument I did not make. Yes, system packages can be installed from unofficial repositories. I don't know how I could've made this clearer.

It's not that it is unclear, it's just that it doesn't make sense. When we compare npm to a system package manager in this context, the thing we compare is whether or not is it curated. Agreed, I was maybe not using the right words (I should have said curated package managers vs not curated package managers), but it did not occur to me that it was unclear because comparing npm to a system package manager makes no sense otherwise. It's all just installing binaries somewhere on disk.

AUR is much like npm in that it is not curated. So if you find that it is a security problem: great! We agree! If you want to pull something from AUR, you should read its PKGBUILD first. And if it pulls tens of packages from AUR, you should think twice before you actually install it. Just like if someone tells you to do `curl https://some_website.com/some_script.sh | sudo sh`, no matter how convenient that is.

Most Linux distributions have a curated repository, which is the default for the "system package manager". Obviously, if users add custom, not curated repositories, it's a security problem. AUR is a bad example because it isn't different from npm in that regard.

> though the part where you harp on about doing dependencies properly compared to me and not elaborating one bit is very funny

Well I did elaborate at least one bit, but I doubt you are interested in more details than what I wrote: "What do I do then? Well exactly the same as what your system package manager does."

I install the dependencies somewhere (just like the system package manager does), and I let my build system find them. It could be with CMake's `find_package`, it could be with pkg-config, whatever knows how to find packages. There is no need to install the dependencies in the place where the system package manager installs stuff: it can go anywhere you want. And you just tell CMake or pkg-config or Meson or whatever you use to look there, too.

Using git submodules is just a bad idea for many reasons, including the fact that you need all of them to use the same build system (which you mentioned), or that a clean build usually implies rebuilding the dependencies (for nothing) or that it doesn't work with package managers (system or not). And usually, projects that use git submodule only support that, without offering a way to use the system package(s).

Re: In Defense of C++

#406

Post by Klonoar »

fithisux wrote: post #216
charlieflowers wrote: post #118

Earlier quoted context omitted.

> "while C++ continues to dominate ... performance-critical domains" Why performance-critical domains? Does C++ have a performance edge over Rust?

That is what the article says.

The article is not an authority, so if you’re going to appeal to it when someone presses you on the topic, you should probably be ready to back it up.

Re: In Defense of C++

#407

Post by einpoklum »

fluoridation wrote: post #400
einpoklum wrote: post #363

> Yes, C++ can be unsafe if you don’t know what you’re doing. But here’s the thing: all programming languages are unsafe if you don’t know what you’re doing. C++ can be unsafe even when you know what you're doing, since it is quite easy get something wrong by accident: index off-by-one can mean out-of-bounds access to an array, which can mean anything really. So, it's not that "all languages" are like that. That seem…

>So, it's not that "all languages" are like that. That seems like a "moving the goalpost" type of logical fallacy. I think what's mean is that Rust's type system only removes one specific kind of unsafety, but if you're clueless you can still royally screw things up, in any language. No type system can stop you from hosing a database by doing things in the wrong order, say. Whether trading for that additional safety…

> only removes one specific kind of unsafety

the word "only" doesn't really belong in that sentence, because these are very common in root-cause analysis of flaws by the "Common Weakness Enumeration" initiative:

https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html

and having said that - I agree with you back :-) ... in fact, I think this is basically "the plan" for C++ regarding security: They'll make some static analysis warnings be considered errors for parts of your code marked "safe", and let them fly in areas marked "unsafe".

If the C++ committe can make that stick - in the public discourse and in US government circles I guess - then they will have essentially "eaten Rust's lunch". Because Rust is quite restrictive, it's somewhat of a moving target, it's kind of fussy w.r.t. use on older systems, and - it's said to be somewhat restrictive. If you take away its main selling point of safety-by-default, then there would probably not be enough of a motivation to drop C++, decades of backwards compatibility, and a huge amount of C++ and C libraries, in favor of Rust.

And this would not be the first time C++ is eating the lunch of a potential successor/competitor language; D comes to mind.

Re: In Defense of C++

#408

Post by sunshowers »

account42 wrote: post #288
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.

Not an issue if you make use of the tools available: https://godbolt.org/z/xW14hGeoj

It looks like (a) this is a warning, not an error (why? the code is always wrong) and (b) the warning was added in clang 21 which came out this year. I also suspect that it wouldn't be able to detect complex cases that require interprocedural analysis.

The bug I saw happened a few years ago, and convinced me to switch to Rust where it simply cannot happen.

Re: In Defense of C++

#409

Post by worik »

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…

No. To everything

Python is up there (down there?) with Windows as a poster child for popularity does not imply quality

If it stayed in its lane as a job control language, and they used semantic versioning then it would be OK.

But the huge balls of spaghetti Python code, that must be run in a virtual environment cause versions drive me mental

Re: In Defense of C++

#410

Post by einpoklum »

jonstewart wrote: post #14
franky47 wrote: post #5

What’s a good (ie: opinionated) code formatter and unit test framework for C++ these days? I just had a PR on an old C++ project, and spending 8 years in the web ecosystem have raised the bar around tooling expectations. Rust is particularly sweet to work with in that regard.

Catch2 is great as a unit test framework. Running unit tests with the address sanitizer and UB sanitizer enabled go a long way towards addressing most memory safety bugs. The kind of C++ you write then is a far cry from what the haters complain about with bad old VC6 era C++.

> Catch2 is great as a unit test framework.

It's "great" mainly in the sense of being very large, and making your code very lage - and slow to build. I would not recommend it unless you absolutely must have some particular feature not existing elsewhere.

Here's a long list of C++ unit testing frameworks: https://en.wikipedia.org/wiki/List_of_unit_testing_framework...

And you might consider:

* doctest: https://github.com/doctest/doctest

* snitch: https://github.com/snitch-org/snitch

* ut/micro-test: https://github.com/boost-ext/ut

Post reply on HN