←back to thread

In Defense of C++

(dayvster.com)
185 points todsacerdoti | 1 comments | | HN request time: 0.207s | source
Show context
fouronnes3 ◴[] No.45268145[source]
This is a good article but it only scratches the surface, as is always the case when it comes to C++.

When I made a meme about C++ [1] I was purposeful in choosing the iceberg format. To me it's not quite satisfying to say that C++ is merely complex or vast. A more fitting word would be "arcane", "monumental" or "titanic" (get it?). There's a specific feeling you get when you're trying to understand what the hell is an xvalue, why std::move doesn't move or why std::remove doesn't remove.

The Forest Gump C++ is another meme that captures this feeling very well (not by me) [2].

What it comes down to is developer experience (DX), and C++ has a terrible one. Down to syntax and all the way up to package management a C++ developper feels stuck to a time before they were born. At least we have a lot of time to think about all that while our code compiles. But that might just be the price for all the power it gives you.

[1] https://victorpoughon.github.io/cppiceberg/

[2] https://mikelui.io/img/c++_init_forest.gif

replies(4): >>45268251 #>>45271645 #>>45273605 #>>45277835 #
jandrese ◴[] No.45268251[source]
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

    imagerunner: imagerunner.o image_decoder.o downloader.o
replies(1): >>45268768 #
duped ◴[] No.45268768[source]
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 also need a linker

- That linker also doesn't know where to find things, so you need the external tool to use it

- Oh and you still have to use a package manager to install those dependencies to work with pkg-config, and it will install them globally. If you want to use it in different projects you better hope you're ok with them all sharing the same version.

Now you can see why things like IDEs became default tools for teaching students how to write C and C++, because there's no "open a text editor and then `c++ build file.cpp` to get output" for anything except hello world examples.

replies(7): >>45269381 #>>45270904 #>>45270987 #>>45271280 #>>45273544 #>>45277859 #>>45343902 #
worik ◴[] No.45270987[source]
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

replies(2): >>45271224 #>>45273765 #
vlovich123 ◴[] No.45271224[source]
> 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.

replies(5): >>45271408 #>>45271555 #>>45272069 #>>45272581 #>>45273222 #
wojciii ◴[] No.45271408[source]
How is that even possible?

Wasn't CI invented to solve just this problem?

replies(1): >>45271451 #
vlovich123 ◴[] No.45271451[source]
You have a team of 20 engineers on a project you want to maintain velocity on. With that many coooks, you have patches on top of patches of your build system where everyone does the bare minimum to meet the near term task only and it devolves into a mess no one wants to touch over enough time.

Your choice: do you have the most senior engineers spend time sporadically maintaining the build system, perhaps declaring fires to try to pay off tech debt, or hire someone full time, perhaps cheaper and with better expertise, dedicated to the task instead?

CI is an orthogonal problem but that too requires maintenance - do you maintain it ad-hoc or make it the official responsibility for someone to keep maintained and flexible for the team’s needs?

I think you think I’m saying the task is keeping the build green whereas I’m saying someone has to keep the system that’s keeping the build green going and functional.

replies(2): >>45271627 #>>45302380 #
1. wojciii ◴[] No.45302380[source]
I worked in companies that did this .. 20 years ago. I didn't imagine that this was still possible.

For me it's just about rules/discipline: Commit working code with passing unottests. Everyone is responsible for fixing stuff. You break something you'll fix it.