fbkr

Raspberry Pi Pico is ARM though.

> Madrigal Elektromotoren GmbH

Wait, isn't this a fictitious company from breaking bad?

> Stray away from this model (e.g., relaxed atomics)

Relaxed atomics are still data-race free, did you mean non-atomic accesses?

I, along with everyone in the embedded space, have been using separate function sections forever for --gc-sections and I would be very surprised if they really cause any bloat and duplication at runtime. Do you mean bloat for intermediate files?

> There are linker flags that allow some deduplication but those have their own drawbacks

As long as you use --icf=safe I don't see any drawback, and most of the time it results in almost identical reductions to --icf=all since not many real programs compare addresses of functions.

You cannot overload operators of integral types in C++, if you mean you can overload `int operator+(int, int)` to be saturating. You can create `saturating_int` kind of types easily though.

Can you actually connect HDMI input to a thunderbolt only display? I have the LG 5K thunderbolt-only display and cannot use it with a desktop PC due to this issue.

Isn't this supposed to be a strength of framework? Their machines are pretty modular. Users should get to pick and choose AMD vs Intel, keyboard layouts, wifi chipsets without framework having to design different machines for each configuration.

I've been using `expected`, i.e. value-or-error type, for a while in C++ and it works just fine, but the article shows it has some noticeable overhead for the `fib` workload for instance. Not sure if the Rust implementation has a different design to make it perform better though.

Have you checked section 9.1 of the System V ABI doc?

There is no double indirection and allocation here, it stores the FILE* directly, not as a pointer to a FILE*.

Section 2.1.1 talks about fixed stack sizes though, so you only get to do 1 allocation, and in general it is not possible to precisely compute the necessary transitive stack size given a function due to recursion/indirect calls.

Stackless coroutines do not have this requirement, it is enough to be able to know the required frame size locally, without considering recursion/indirection. And fallback heap allocations are not surprising since we do not statically know the required frame size at the call site. Segmented stacks have their own tradeoffs too, checking if you have enough stack space at every function entry is not cheap.

I doubt that's possible with the C++98 preprocessor.

Disclaimer: I dislike iostreams and in our environment <iostream> is completely banned.

However, in C++98, how else would you handle when you have an arbitrary number of things to print in a type-safe way? e.g.

    cout << myInt << ": " << something << " - " << otherthing << " - " << etc << '\n';

printf is not type-safe, nor supports user defined types. I'd rather not write 8 lines of functions calls for the same thing either.

I think it made some sense C++98, though it is an awful API in 2021.

I thought Zircon is the kernel and Fuchsia is the operating system. Though that wouldn't prevent Google from building Android on top of Fuchsia.

Could you explain how cmake stuff isn't portable or broken between different flavors of Unix? I comfortably maintain CMake builds that work on linux (with centos, ubuntu and arch), macos and windows without much trouble.

If you mean cmake versions, I'm not sure what you expect, should cmake just freeze in time and stop adding features so someone gets to use cmake from 5 years ago?

Also, the bit about autotools on windows is silly. If it can't build native windows stuff, it's not at all viable for windows.

I also dislike cmake (particularly dependency management) and wish for something better, but I think our criticisms should be well-founded.

This fails when you want `4 + c` or `c + 4.f` etc. So you either have a gross number of overloads doing the same thing, or you just put an implicit constructor to `complex`.

Also, I agree that implicit conversions in general should be avoided, but this complex number example feels like the perfect use case.

> C language has some very limited implicit type conversions

What? C will happily compile this:

    void g() {
        float f = 3.14;
        int* ip = &f;
    }

C++ has no such _craziness_. Your strawman actually has pretty good uses:

    complex c = 3i;
    ... = c + 4;

Would you rather have the last line not compile because 4 is not a complex number? Because one _could_ argue that 4 is a complex number, and C++ can represent this with an implicit constructor.

The issue with C++ is that implicit is the default, not that it exists.

This is not correct, what you are thinking is implementation defined or maybe unspecified behavior.

Please do explain the behavior of calling an uninitialized function pointer on x86 if you insist.

Maybe I'm missing it but I wish there was an ESP8266 board with a proper JTAG connector.

I have hacked something on a protoboard for nodemcus before, but it ended up being pretty messy.

It's for bare metal microcontroller development. It _can_ work for those, but you probably already have relatively better alternatives for those environments.