Hacker News Reader

> that would be very weird on Linux. The x86_64 linux ABI mandates that the first arguments go on registers afaik (I'm assuming x86_64 here since the post mentions linux distros which are overwhelmingly x64). What compiler would default to a pure stack-based calling convention ? Certainly not GCC or clang, no ?

The System V i386 ABI passes parameters through the stack. Perhaps that is what the author is referring to, although I wouldn't be surprised if he mixed it up with the x64 ABI.

The 32-bit Linux kernel uses a register-based ABI internally, rather than System V.

In case it is talking about the x64 calling convention, there is actually some kind of an odd case where you would get something that looks like an argument was pushed on the stack:

When a non-trivially-copyable object is passed by value to a function, you need to ensure that through the lifetime of the copy, it's address will never change because the constructor may have stored address of some of the field (for instance, a pointer to a field). The way this is handled at list in the SystemV x84_64 ABI is that the object is created on the caller's stack, and a pointer to it is stored in a register, so just like if it was passed as a pointer.

I have seen several cases where a header would have an "ifdef c++" clause with copy constructors and destructors in them ("It does not add field so it should be OK, right ?"), which make the object non trivially-copyable, leading to clashing calling convention between C and C++ codes. I am curious about if this may be the issue he encountered.

Too late to edit so I'll just write a message here: The hypothesis written above would not explain the author's complains as he mentions he was able to fix it with a compilation flag, whereas I doubt the compiler would change non-trivially-copyable being handled as reference to a copy since it would break correctness.

> The System V i386 ABI passes parameters through the stack.

No. The C/C++ ABI is quite uniform across architectures. The first 1..N (N is ISA dependant) parameters that can fit into a CPU register are passed via registers. The first input parameter that _can't_ fit into a register (e.g. a structure passed by value) is pushed onto the stack, with every other following parameter being pushed onto the stack as well. N+1… parameters are always passed through the stack.

> No. The C/C++ ABI is quite uniform across architectures. The first 1..N (N is ISA dependant) parameters that can fit into a CPU register are passed via registers.

Here is the "System V i386 ABI" mentioned above: https://refspecs.linuxfoundation.org/elf/abi386-4.pdf (from https://refspecs.linuxfoundation.org/). It clearly passes all arguments on the stack, and none on registers ("Function Calling Sequence" starting on page 35). That is the ABI used on 32-bit x86 Linux if you don't specify -mregparm (which the kernel uses); since the author was calling the compiler directly (which was necessary because the kernel makefiles only have rules for building C files, not C++ files), there was a mismatch between the -mregparm used by the kernel and the default ABI used by the C++ compiler, which was fixed by also passing -mregparm to the C++ compiler.

You are not incorrect, and I shall ruminate on why I had thought that the SysV ABI on i386 used %rax ÷ %rex as input function parameters without having to resort to the use -mpregparm. Thanks for the correction.

> The C/C++ ABI is quite uniform across architectures.

How can it be? What about an architecture without conventional registers? And for example I work on an implementation of C/C++ that logically uses the heap for its ABI.

Quite uniform != completely uniform.

Especially when it comes to C (less so C++), it is a remarkably adaptable language that has been able to attune to a variety of vastly incompatible hardware architectures, including stack based ones, heap based ones and some esoteric ones as well. Yet, in the case of conventional, register based ISA's, the ABI has been remarkably similar: nonwithstanding actual ISA specific register names, registers 0…N (apart from RISC ISA's where storing into/loading from the register 0 is a no-op / zero constant) are used as input parameters and register 0 (where available) is used as the function return value (provided it can fit in); otherwise the return result is returned via stack.

> Quite uniform != completely uniform

Don't know if you're a non-native speaker, but no 'quite' usually does means 'completely'!

https://dictionary.cambridge.org/dictionary/english/quite

Only when used with non-gradable adjectives/adverbs (from the same surce: https://dictionary.cambridge.org/grammar/british-grammar/qui... ) (and yes, uniform, is quite non-gradable)

(non-native speaker here, quite frustrated about the quite different meanings of 'quite')

'Quite dead' for example means completely dead.

Only because dead is so binary. Any moderately intense modifier on "dead" signifies complete death, even though it won't mean 'completely' with most terms.

> so, how is that a problem with C++ and not [...]

I don't think you should see this article as a criticism of C++. Just a rent on how hard it is to use in the Linux kernel which is openly against it.

Perhaps the article is old enough to have been written in the 32-bit era?

The Page Info I see says this:

> article:published-time 2016-10-28T11:40:06+00:00

which is well into the era of 64-bit code.

People are still complaining about macOS dropping 32bit despite the last 32bit hardware having been dropped a decade ago.

Some people (especially game devs) are bizarrely obsessed with 32bit :-/

The LDD3 mentioned is 32-bit era, and 2.6.x kernel, which had a CONFIG_REGPARM to allow passing parameters in registers (because the default was not to do that).

AVRs don't have enough storage for templated code to explode into an unmanageable problem.

Somehow C64 can deal with them.

"CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”"

https://www.youtube.com/watch?v=zBkNBP00wJE

"C++20 For The Commodore 64"

https://www.youtube.com/watch?v=EIKAqcLxtT0

But a C64 is still only talking about 64kB of RAM. The post you're replying to claims that Template complexity gets unreasonable on a large machine, such as a Linux system. Not sure I agree, but "it's fine on a C64" isn't evidence in your favour unless you've forgotten Linux doesn't even run on a Commodore 64.

So it is fine on a 64KB system, but unmanageable on a platform that gets all the different kinds of boilerplate to run cloud workloads, got it

I mean, apparently this is confusing, but yes, obviously.

If your Commodore 64 template is dealing with say, foozles that might be 8-byte, 12-byte or 16-byte, the complexity incurred is pretty small, bugs with foozle<16> are likely to be something mere mortals can understand and fix.

On a more complicated system like a cloud Linux setup the template may be for foozles that can be in any colorspace and on a remote machine or locally, and now sometimes the bug with foozle<HSV,remove> involves a fifty line error message because the compiler doesn't realise all that happened is you meant to write foozle<HSV,remote> ...

It's not even as if the C++ committee isn't aware that templates are a problem. Remember template meta-programming wasn't really intended from the outset, and a big part of the point of Concepts was to at last let you write code that compilers can provide readable errors for when it's wrong.

The whole issue with Linux and C++ is political, there are other OSes that don't suffer from such issues and gladly accept templates.

https://developer.apple.com/documentation/driverkit

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-...

https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...

https://genodians.org/nfeske/2019-01-22-conscious-c++

To be fair, DriverKit runs in userspace. IOKit, its spiritual predecessor, only allowed for the use of Embedded C++.

True, but that isn't the case for the other more modern examples.

Also IO Kit is no more, unless one is running an outdated macOS installation.

And talking about the past, maybe discussing about dynamic dispatch of Objective-C messsages on NeXTSTEP drivers with the previous Driver Kit, would also be quite interesting regarding "bloat".

IOKit remains the only way to write kernel extensions, which are still supported but discouraged if DriverKit does the job. NeXtTSTEP using Objective-C for drivers was certainly very cute but I guess they just didn’t want to have driver makers learn the language :(

> Devices supported on macOS 11 and later require DriverKit. Use IOKit in your apps and services to discover and use devices.

https://developer.apple.com/documentation/iokit

Going forward not for long.

I understand that for C++ programmers "That's possible" versus "That's a good idea" is a distinction without a difference, however for the rest of us the fact you can use templates as much as you like in, say, Windows drivers, does not magically mean it's a good idea to write complex templated code in Windows drivers.

The constraints in /kernel like forbidding exceptions are because otherwise they (Microsoft) need to do a bunch of extra work to support your bad idea. But your use of templates has no impact on their work, so knock yourself out adding as much complexity as you like this way.

Here is another example, running C++ straight on car firmware free of Linux politics via AUTOSAR certification standard.

https://www.parasoft.com/blog/breaking-down-the-autosar-c14-...

But what do they state specifically? Ah, right.

> "The document allows in particular the usage of dynamic memory, exceptions, templates, inheritance and virtual functions."

https://www.autosar.org/fileadmin/user_upload/standards/adap...

It definitely feels like we're talking past each other. I keep telling you why people think it's a bad idea, and you keep showing that you're allowed to do it anyway. We know. That's the difference between impossible and a bad idea.

You keep saying it is a bad idea like it is a given. He keeps saying 5 bazillion programmers are quite successful with your "bad idea" so maybe it isn't so bad. Is there any evidence either way on the effects of templates on code quality?

Nope, it is the difference regarding politics of what goes into the Linux kernel and the rest of the world, and it is quite clear to which side each of us belong.

Why exactly? They are a compile time concept which only generates code for types where it is needed. That C devs instead copy-paste the same code 10s of times, use some shitty slow linked list, or the worst, use textual macros doesn’t make any of them a better tradeoff imo.

C++ or even C isn't exactly "fine" on any 8-bit system though. It's nice for a little demo, it can even be tolerable for some real-world projects when mixed with large amounts of inline assembly, but those 8-bit ISAs have been designed mainly for manual assembly coding, not high level compiled languages like C.

Honestly unless you’re on something like an ATtiny with < 1K of RAM or doing cycle-counted stuff a properly adapted high-level language is fine. I mean, Forth (doesn’t have to but usually) uses an interpreted virtual machine and people have used and liked it on 6502s since those were the new hotness.

As far as I’ve seen, two things make C and C++ specifically problematic on 8-bitters: automatic promotion to int for all expressions, with int required to be at least 16 bits (a language problem); and subpar codegen on accumulator architectures and other things that are not like desktops (a compiler problem).

Forth is much better for creating tiny executables than C on 8-bit ISAs though, performance takes a hit because of all the calls/jmps, but it's still surprisingly good. C compilers on the other hand often create "obviously" dumb and inefficient code, at least in my experience (6502 may be better than Z80 in that regard though).

C translates directly to ASM in many cases. It just makes managing offsets and other stuff easier.

C++ adds type-safety on top of that for no cost. It's great when your compiler tells you that there is no operator =|(PORTD, PINA). Did you mean |=(PORTD,PIND) or =|(PORTA,PINA).

If you really want that in C, you can either use functions and wrap everything in (incompatible but internally identical) structs, or use Sparse and annotate those integer types to be incompatible. Not that you must prefer that to C++ (even if I do), just to note that you can make do with C if you want to.

> C translates directly to ASM in many cases.

But usually much worse ASM than what a human would write on such CPUs, because the C compiler is still restricted by artificial high-level concepts like calling conventions, and it needs to wrestle with instruction sets that are not very compiler-friendly and tiny non-orthogonal register sets. C++ just adds a whole level of code obfuscation on top, so it's harder to tweak what code the compiler actually generates.

I love these videos, Jason is doing fantastic work with his YouTube channel and C++ Weekly series.

Check his CppCon 2021 presentation, done on a C64 emulator thanks constexpr. :)

Thanks, I will :)

What do templates have to do with storage, though? My primary attraction to C++ templates is that they let me write very expressive code that will compile down to a handful of instructions. Now, actually compiling complex C++ templates on a storage-constrained system can be a problem, since templates are compile-time beasts, not runtime. Once compiled, though, they have a Cheshire-cat existence.

Edit: Unless you're doing something rather silly with the templates, but again, that's not a template problem.

The general complaint with templates is they are instantiated and if you’re not careful can bloat the binary with multiple versions of a piece of code. But this is usually something pretty easy to solve: just don’t do something that would cause that to happen :P

I have _never_ had any issue with C++ templates on _modern_ µControllers such as the ESP32. Unless you have an incredibly minuscule flash, modern GCC or LLVM are very good at deleting unused code when you compile everything with -Os. Even -Og isn't that critical either.

C++ templates are unwound at the compile time before the «expanded» template code passes along into the optimiser where most of the unused code is elided.

Unless the templates have been externalised (i.e. defined as «extern template …», of course). Even then, a modern compiler+linker combo will optimise most of the unused code away at the linking time thus reducing the final binary size. I do understand that the LTO might not be available for every embedded platform, though.

P.S. That is exactly the point of the C++ template metaprogramming – the hard lifting is delegated to the compiler, which leads to increased compile times but also to more efficient and very compact runtime code.