[tialaramex]

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.

[pjmlp]

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

[flohofwoe]

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.

[mananaysiempre]

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).

[flohofwoe]

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).

[uuidgen]

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).

[flohofwoe]

> 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.

[mananaysiempre]

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.

[tialaramex]

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.

[pjmlp]

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++

[tialaramex]

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.

[pjmlp]

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...

[tialaramex]

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.

[kaba0]

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.

[saagarjha]

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

[pjmlp]

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".

[saagarjha]

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 :(