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

C++: "model of the hardware" vs. "model of the compiler" (2018)

ithare.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#21

Post by captainmuon »

simonask wrote: post #11
TuxSH wrote: post #10

Earlier quoted context omitted.

> C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). They are, they are extensively used by software like ScyllaDB which itself is used by stuff like Discord, BlueSky, Comcast, etc. C++ coroutines and "stackless coroutines" in general are just compiler-generated FSMs. As for allocation, you can override operator new for the promise types and that operator new gets forwarde…

They are compiler-generated FSMs, but I think it's worth noting that the C++ design was landed in a way that precluded many people from ever seriously considering using them, especially due to the implicit allocation. The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble. Rust gets it right, but has its own warts, especially if you're com…

> The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble.

I wouldn't say that applies to everybody. I use C++ because it interfaces with the system libraries on every platform, because it has class-based inheritance (like Java and C#, unlike Rust and Zig) and because it compiles to native code without an external runtime. I don't care to much about allocations.

For me the biggest fumble is that C++ provides the async framework, but no actual async stdlib (file io and networking). It took a while for options to be available, and while eg Asio works nicely it is crazily over engineered in places.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#22

Post by TuxSH »

simonask wrote: post #11
TuxSH wrote: post #10

Earlier quoted context omitted.

> C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). They are, they are extensively used by software like ScyllaDB which itself is used by stuff like Discord, BlueSky, Comcast, etc. C++ coroutines and "stackless coroutines" in general are just compiler-generated FSMs. As for allocation, you can override operator new for the promise types and that operator new gets forwarde…

They are compiler-generated FSMs, but I think it's worth noting that the C++ design was landed in a way that precluded many people from ever seriously considering using them, especially due to the implicit allocation. The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble. Rust gets it right, but has its own warts, especially if you're com…

You can write stuff like this:

  void *operator new(std::size_t sz, Foo &foo, Bar &bar) { return foo.m_Buffer; /* should be std::max_align_t-aligned \*/ }
and force all coroutines of your Coroutine type to take (Foo &, Bar &) as arguments this way (works with as many overloads as you like).

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#23

Post by Trex_Egg »

flohofwoe wrote: post #9
adrianN wrote: post #8

Earlier quoted context omitted.

At least we can build software systems that are a few orders of magnitude more complex than in the 90s for approximately the same price. The question is whether the extra complexity also offers extra value.

True, but a lot of that complexity is also just pointless boilerplate / busywork disguised as 'best practices'.

I am eager to have an example to explain how a "best practices" is making the software unbearable or slow?

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#24

Post by gpderetta »

simonask wrote: post #11
TuxSH wrote: post #10

Earlier quoted context omitted.

> C++ coroutines turned out quite the mess (are they actually usable in real world code by now?). They are, they are extensively used by software like ScyllaDB which itself is used by stuff like Discord, BlueSky, Comcast, etc. C++ coroutines and "stackless coroutines" in general are just compiler-generated FSMs. As for allocation, you can override operator new for the promise types and that operator new gets forwarde…

They are compiler-generated FSMs, but I think it's worth noting that the C++ design was landed in a way that precluded many people from ever seriously considering using them, especially due to the implicit allocation. The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble. Rust gets it right, but has its own warts, especially if you're com…

The required allocation make them awkward to use for short lived automatic objects like generators. But for async operations were you are eventually going to need a long lived context object anyway, it is a non-issue especially given the ability to customize allocators.

I say this as someone that is not a fan of the stackess coroutines in general, and the C++ solution in particular.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#25

Post by gpderetta »

gsliepen wrote: post #14
lmm wrote: post #4

Earlier quoted context omitted.

Isn't that the tail wagging the dog? If you build the language to fit current compilers then it will be impossible to ever redesign those compilers.

Why would that be impossible? Most programming languages are still Turing complete, so you can build whatever you want in them.

"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy."

- Alan Perlis, Epigrams on Programming

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#26

Post by flohofwoe »

Trex_Egg wrote: post #23
flohofwoe wrote: post #9

Earlier quoted context omitted.

True, but a lot of that complexity is also just pointless boilerplate / busywork disguised as 'best practices'.

I am eager to have an example to explain how a "best practices" is making the software unbearable or slow?

Some C++ related 'best practices' off the top of my head:

- put each class into its own header/source file pair (a great way to explode your build times!)

- generally replace all raw pointers with shared_ptr or unique_ptr

- general software patterns like model-view-controller, a great way to turn a handful lines of code into dozens of files with hundreds of lines each

- use exceptions for error handling (although these days this is widely considered a bad idea, but it wasn't always)

- always prefer the C++ stdlib over self-rolled solutions

- etc etc etc...

It's been a while since I closely followed modern C++ development, so I'm sure there are a couple of new ones, and some which have fallen out of fashion.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#27

Post by aw1621107 »

flohofwoe wrote: post #26
Trex_Egg wrote: post #23

Earlier quoted context omitted.

I am eager to have an example to explain how a "best practices" is making the software unbearable or slow?

Some C++ related 'best practices' off the top of my head: - put each class into its own header/source file pair (a great way to explode your build times!) - generally replace all raw pointers with shared_ptr or unique_ptr - general software patterns like model-view-controller, a great way to turn a handful lines of code into dozens of files with hundreds of lines each - use exceptions for error handling (although the…

> put each class into its own header/source file pair (a great way to explode your build times!)

Is that really sufficient to explode build times on its own? Especially if you're just using the more basic C++ features (no template (ab)use in particular).

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#28

Post by deterministic »

gsliepen wrote: post #2

Early programming languages had to work with the limited hardware capabilities of the time in order to be efficient. Nowadays, we have so much processing power available that the compiler can optimize the code for you, so the language doesn't have to follow hardware capabilities anymore. So it's only logical that the current languages should work the limitations of the compilers. Perhaps one day those limitations wil…

Nope. Performance really matters. Even today. And even for web applications! Just remember how you feel using a slow sluggish website vs. a snappy fast one. It's night and day.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#29

Post by pjmlp »

captainmuon wrote: post #21
simonask wrote: post #11

Earlier quoted context omitted.

They are compiler-generated FSMs, but I think it's worth noting that the C++ design was landed in a way that precluded many people from ever seriously considering using them, especially due to the implicit allocation. The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble. Rust gets it right, but has its own warts, especially if you're com…

> The reason you are using C++ in the first place is because you care about details like allocation, so to me this is a gigantic fumble. I wouldn't say that applies to everybody. I use C++ because it interfaces with the system libraries on every platform, because it has class-based inheritance (like Java and C#, unlike Rust and Zig) and because it compiles to native code without an external runtime. I don't care to m…

I like what Rust offers over C++ in terms of safety and community culture, but I don't enjoy being a tool builder for ecosystem gaps, I rather spend the time directly using the tools that already exist, plus I have Java and .NET ecosystems for safety, as I am really on the automatic resource management side.

Zig, is really Modula-2 in C's cloathing, I don't like the kind of handmade culture that has around it, and its way of dealing with use after free I can also get in C and C++, for the last thirty years, it is a matter of actually learning the tooling.

Thus C++ it is, for anything that isn't can't be taken over by a compiled managed language.

I would like to use D more, but it seems to have lost its opportunity window, although NASA is now using it, so who knows.

Re: C++: "model of the hardware" vs. "model of the compiler" (2018)

#30

Post by pjmlp »

flohofwoe wrote: post #26
Trex_Egg wrote: post #23

Earlier quoted context omitted.

I am eager to have an example to explain how a "best practices" is making the software unbearable or slow?

Some C++ related 'best practices' off the top of my head: - put each class into its own header/source file pair (a great way to explode your build times!) - generally replace all raw pointers with shared_ptr or unique_ptr - general software patterns like model-view-controller, a great way to turn a handful lines of code into dozens of files with hundreds of lines each - use exceptions for error handling (although the…

> - put each class into its own header/source file pair (a great way to explode your build times!)

Only if you fail to use binary libraries in the process.

Apparently folks like to explode build times with header only libraries nowadays, as if C and C++ were scripting languages.

> - generally replace all raw pointers with shared_ptr or unique_ptr

Some folks care about safety.

I have written C applications with handles, doing two way conversions between pointers and handles, and I am not talking about Windows 16 memory model.

> - general software patterns like model-view-controller, a great way to turn a handful lines of code into dozens of files with hundreds of lines each

I am old enough to have used Yourdon Structured Method in C applications

> - use exceptions for error handling (although these days this is widely considered a bad idea, but it wasn't always)

Forced return code checks with automatic stack unwinding are still exceptions, even if they look differently.

Also what about setjmp()/longjmp() all over the place?

> - always prefer the C++ stdlib over self-rolled solutions

Overconfidence that everyone knows better than people paid to write compilers usually turns out bad, unless they are actually top developers.

There are plenty of modern best practices for C as well, that is how we try to avoid making a mess out of people think being a portable assembler, and industries rely on MISRA, ISO 26262, and similar for that matter.

Post reply on HN