fbkr

6 ms·

1.
by fbkr 4y ago
Raspberry Pi Pico is ARM though.
2.
by fbkr 4y ago
> Madrigal Elektromotoren GmbH Wait, isn't this a fictitious company from breaking bad?
3.
by fbkr 4y ago
> Stray away from this model (e.g., relaxed atomics) Relaxed atomics are still data-race free, did you mean non-atomic accesses?
4.
by fbkr 4y ago
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 f
5.
by fbkr 5y ago
> 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
6.
by fbkr 5y ago
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.
7.
by fbkr 5y ago
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.
8.
by fbkr 5y ago
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 conf
9.
by fbkr 5y ago
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 diffe
10.
by fbkr 5y ago
Have you checked section 9.1 of the System V ABI doc?
11.
by fbkr 5y ago
There is no double indirection and allocation here, it stores the FILE* directly, not as a pointer to a FILE*.
12.
by fbkr 5y ago
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. Stackl
13.
by fbkr 5y ago
I doubt that's possible with the C++98 preprocessor.
14.
by fbkr 5y ago
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 << myI
15.
by fbkr 5y ago
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.
16.
by fbkr 6y ago
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 cm
17.
by fbkr 6y ago
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 avoid
18.
by fbkr 6y ago
> 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 go
19.
by fbkr 6y ago
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.
20.
by fbkr 6y ago
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.
21.
by fbkr 7y ago
It's for bare metal microcontroller development. It _can_ work for those, but you probably already have relatively better alternatives for those environments.