ric129

7 ms·

1.
by ric129 9mo ago
I do like that the article touches exactly this, and even though I'm a stranger to the entire concept, it makes sense: >Hardly anyone hitchhikes any more, which is a shame because it encourages the habit of generosity from drivers,
2.
by ric129 1y ago
that’s the submitters‘ user name, not the submission date
3.
by ric129 2y ago
There's an inherent trade-off in everything Besides, in this case.. it does not help that you'd also have to exchange hardware
4.
by ric129 2y ago
I recall plenty of implementations turning into the same as a memory_order_acquire, which seems fine these days
5.
by ric129 4y ago
What if your young 'uns just do not... participate? I am in a position where I am doing TL-level decisions, and try quite hard to demo, discuss, share the details and rationale. I write design proposals, documentation, do demo sessions
6.
by ric129 6y ago
Yes, all allocators (except perhaps OpenBSDs from what I see in this thread) do this. It is also why `calloc` exists - because zero-initializing every single allocation is really, really expensive.
7.
by ric129 7y ago
I'm fairly confident that SQLite deals well with filesystem crashes nowadays, see https://www.sqlite.org/testing.html and https://www.sqlite.org/atomiccommit.html
8.
by ric129 8y ago
>I'd never heard of the Robson bounds but they seem quite crucial to know about I'd argue it's not really important in modern systems due to the use of virtual memory. With virtual memory, you can massive reduce fragmentat
9.
by ric129 8y ago
By "mobile" I'm guessing you mean laptops, and not phones. Energy consumption of AMD's x86-64 CPUs are only impressive when comparing with Intel, they're not competitive with current ARM CPUs.
10.
by ric129 8y ago
>It's applicable to C because most realistic implementations of malloc(3) store the size of the malloc'd area to the nearest word[2] This is not so true anymore, and I'd be very careful with that sort of tricks. While the
11.
by ric129 8y ago
There's malloc_usable_size[1], assuming you mean asking the memory allocator what the array size is. But chances are that wouldn't work correctly, because what the amount of memory a malloc calls gives you and the amount you reque
12.
by ric129 9y ago
What if you lose your Yubikey?
13.
by ric129 9y ago
Only virtual functions behave as you described, and even them don't exactly cause a function pointer to be stored in an object.
14.
by ric129 9y ago
Browsers have already taught us how useless this is, users will always click through.
15.
by ric129 10y ago
>The funny thing is Microsoft’s linked lists are faster than C++ standard vectors. If I had to guess, it's because the std::vector is more conservative in memory use and it causes more malloc/array copy calls.
16.
by ric129 10y ago
That sounds very economically taxing.
17.
by ric129 10y ago
It's C++, I recall using C++11 constructs on a recent Arduino project.