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

131–140 of 470 posts

Re: In Defense of C++

#131

Post by [deleted] »

benreesman wrote: post #109
duped wrote: post #57

Earlier quoted context omitted.

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

clang++ $(pkg-config --cflags --libs libtorch) qwen-3-nvfp4.cpp -o ./qwen-3-infer Your move.

[deleted]

Re: In Defense of C++

#132

Post by vlovich123 »

worik wrote: post #116
duped wrote: post #57

Earlier quoted context omitted.

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

None of that is a problem There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle. Then repeated foot guns going off, no toes left, company bankrupt and banking system crashed, again

> There are a lot of problems, but having to carefully construct the build environment is a minor one time hassle.

I've observed the existence in larger projects of "build engineers" whose sole job is to keep the project building on a regular cadence. These jobs predominantly seem to exist in C++ land.

Re: In Defense of C++

#133

Post by pornel »

gmueckl wrote: post #24

C++ will always stay relevant. Software has eaten the world. That transition is almost complete now. The languages that were around when it happened will stay deeply embedded in our fundamental tech stacks for another couple decades at least, if not centuries. And C and C++ are the lion's share of that. COBOL sticks around 66 years after its first release. Fortran is 68 years old and is still enormously relevant. Muc…

It seems likely that C++ will end up in a similar place as COBOL or Fortran, but I don't see that as a good future for a language.

These languages are not among the top contenders for new projects. They're a legacy problem, and are kept alive only by a slowly shrinking number of projects. It may take a while to literally drop to zero, but it's a path of exponential decay towards extinction.

C++ has strong arguments for sticking around as a legacy language for several too-big-to-rewrite C++ projects, but it's becoming less and less attractive for starting new projects.

C++ needs a better selling point than being a language that some old projects are stuck with. Without growth from new projects, it's only a matter of time until it's going to be eclipsed by other languages and relegated to shrinking niches.

Re: In Defense of C++

#134

Post by ameliaquining »

s20n wrote: post #121

I believe most C++ gripes are a classic case of PEBKAC. One of the most common complaints is the lack of a package manager. I think this stems from a fundamental misunderstanding of how the ecosystem works. Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies. Another…

> Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies.

Okay, but is that actually a good idea? Merely saying that something is idiomatic isn't a counterargument to an allegation that the ecosystem has converged on a bad idiom.

For software that's going to be distributed through that same package manager, yes, sure, that's the right way to handle dependencies. But if you're distributing your app in a format that makes the dependencies self-contained, or not distributing it at all (just running it on your own machines), then I don't see what you gain from letting your operating system decide which versions of your dependencies to use. Also this doesn't work if your distro doesn't happen to package the dependency you need. Seems better to minimize version skew and other problems by having the files that govern what versions of dependencies to use (the manifest and lockfile) checked into source control and versioned in lockstep with the application code.

Also, the GCC codebase didn't start incorporating C++ as an implementation language until eight years after Linus wrote that message.

Re: In Defense of C++

#135

Post by ryao »

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…

If you are willing to give up incremental compilation, concatenating all C++ files into a single file and compiling that on a single core will often outperform a multi-core compilation. The reason is that the compiler spends most of its time parsing headers and when you concentrate everything into a single file (use the C preprocessor for this), it only needs to parse headers once.

Merely parsing C++ code requires a higher time complexity than parsing C code (linear time parsers cannot be used for C++), which is likely where part of the long compile times originate. I believe the parsing complexity is related to templates (and the headers are full of them), but there might be other parts that also contribute to it. Having to deal with far more abstractions is likely another part.

That said, I have been incrementally rewriting a C++ code base at a health care startup into a subset of C with the goal of replacing the C++ compiler with a C compiler. The closer the codebase comes to being C, the faster it builds.

Re: In Defense of C++

#136

Post by jlarocco »

duped wrote: post #57
jandrese wrote: post #12

Earlier quoted context omitted.

In Linuxland you at least have pkg-config to help with package management. It's not perfect but neither is any other package management solution. If I'm writing a small utility or something the Makefile typically looks something like this: CC=clang PACKAGES=libcurl libturbojpeg CFLAGS=-Wall -pedantic --std=gnu17 -g $(shell pkg-config --cflags $(PACKAGES)) LDLIBS=$(shell pkg-config --libs $(PACKAGES)) ALL: imagerunner…

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it.

On Windows and OSX it's even easier - if you're okay writing only for those platforms.

It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated with the language or compiler, too.

Re: In Defense of C++

#137

Post by viraptor »

s20n wrote: post #121

I believe most C++ gripes are a classic case of PEBKAC. One of the most common complaints is the lack of a package manager. I think this stems from a fundamental misunderstanding of how the ecosystem works. Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies. Another…

> find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies.

It's really not about being hard to grasp. Once you need a different dependency version than the system provides, you can't easily do it. (Apart from manual copies) Even if the library has the right soname version preventing conflicts (which you can do in C, but not really C++ interfaces), you still have multiple versions of headers to deal with. You're losing features by not having a real package manager.

Re: In Defense of C++

#138

Post by AdieuToLogic »

ryao wrote: post #125
s20n wrote: post #121

I believe most C++ gripes are a classic case of PEBKAC. One of the most common complaints is the lack of a package manager. I think this stems from a fundamental misunderstanding of how the ecosystem works. Developers accustomed to language-specific dependency managers like npm or pip find it hard to grasp that for C++, the system's package manager (apt, dnf, brew) is the idiomatic way to handle dependencies. Another…

GCC was originally written in GNU C. Around GCC 4.9, its developers decided to switch to a subset of C++ to use certain features, but if you look at the codebase, you will see that much of it is still GNU C, compiled as GNU C++. There is nothing you can do in C++ that you cannot do in C due to Turing Completeness. Many common things have ways of being done in C that work equally well or even better. For example, you…

> There is nothing you can do in C++ that you cannot do in C due to Turing Completeness.

While this is technically true, a more satisfying rationale is provided by Stroustrup here[0].

> Many common things have ways of being done in C that work equally well or even better. For example, you can use balanced binary search trees in C without type errors creating enormous error messages from types that are sentences if not paragraphs long. Just grab BSD’s sys/tree.h, illumnos’ libuutil or glib for some easy to use balanced binary search trees in C.

Constructs such as sys/tree.h[1] replicate the functionality of C++ classes and templates via the C macro processor. While they are quite useful, asserting that macro-based definitions provide the same type safety as C++ types is simply not true.

As to the whether macro use results in "creating enormous error messages" or not, that depends on the result of the textual substitution. I can assure you that I have seen reams of C compilation error messages due to invalid macro definitions and/or usage.

0 - https://www.stroustrup.com/compat_short.pdf

1 - https://cgit.freebsd.org/src/tree/sys/sys/tree.h

Re: In Defense of C++

#139

Post by jandrewrogers »

monkeyelite wrote: post #97

The complexity argument is just not true. You do have to know this stuff in c++, you run into it all the time. I wish I didn’t have to know about std::launder but I do

You need something like std::launder in any systems language for certain situations, it isn’t a C++ artifact.

Before C++ added it we relied on undefined behavior that the compilers agreed to interpret in the necessary way if and only if you made the right incantations. I’ve seen bugs in the wild because developers got the incantations wrong. std::launder makes it explicit.

For the broader audience because I see a lot of code that gets this wrong, std::launder does not generate code. It is a compiler barrier that blocks constant folding optimizations of specific in-memory constants at the point of invocation. It tells the compiler that the constant it believes lives at a memory address has been modified by an external process. In a C++ context, these are typically restricted to variables labeled ‘const’.

This mostly only occurs in a way that confuses the compiler if you are doing direct I/O into the process address space. Unless you are a low-level systems developer it is unlikely to affect you.

Re: In Defense of C++

#140

Post by nine_k »

binary132 wrote: post #89
ktpsns wrote: post #29

Earlier quoted context omitted.

As long as people write software (no pun intended), software will follow trends. For instance, in many scientific ecosystems, Matlab was successfully replaced by Scipy. Which happens to get replaced by Julia. Things don't neccessarily have to stay the same. Interestingly, such a generational trend currently happens with Rust, despite there has been numerous other popular languages such as D or Zig which didn't have t…

You’re thinking of software that is being written today. GP is talking about software we use every day in every device on the planet that hasn’t changed since it was written 30+ years ago.

What is this software? E.g. Linux is 33 years old; barely a few percent of Linux 1.0 remains in a modern kernel, if we count lines of code.

Maybe GNU Emacs has a larger percentage remaining intact; at least it retains some architectural idiosyncrasies from 1980s.

As of Fortran, modern Fortran is a pretty nice and rich language, very unlike the Fortran-77 I wrote at high school.

Post reply on HN