mh7
The only time signed vs unsigned matters is for comparisons and mul/div, and those have explicit names so you're never surprised that 0xFFFFFFFF is less than 0 when doing signed_less_than().
Then you can have explicit operators for the operation you want: signed_mul(), signed_less_than(), unsigned_greater_than(), add_assume_no_overflow(), etc. (add your favorite syntactic sugar/opeator symbols for these).
Is there an example of a program that was crap, implemented telemetry and then got better afterwards? (and of course controlled for factors that might have improved the program anyway)
I mean since telemetry advocates are so into how useful data is, surely they must have data on whether telemetry itself works?
So to me when trying to measure anything it seems so blatantly obvious that it has to change the outcome - you will interact in some way with the system to get any information out, and this will change the tracejctory, energy, momentum or whatever of the particles.
I mean is that it? That's the mystery?
Unless someone finds a way of scaling up production and/or reducing the cost, you're not gonna see organs popping up everywhere, hence limited access.
Only ISO C can reserve things, no one else, and ISO C does not reserve the _t suffix.
Because on your typical arm mcu, x/y is a function call to a definitively non-constant time function.
And lets not forget soft-fp. Every single floating point op is a function call...
Yes there is.
Take the union of C and C++ which is valid syntax (and same semantics) in both languages, voila; C/C++.
A big downside is that you you can't easily take ownership of an existing buffer and treat it as this string type.
string s;
char some_buf[];
string_take(&s, some_buf, some_capacity);
Also you would of course never dynamically allocate string structs, just the data member if needed.
Only ISO C can officially reserve names, everyone else just has their personal code/naming style that you can chooseto follow or not.
Which they will probably steal from the regular drivers, so you will be effectively paying for your own data.
I had to set hibernate on lid-close because Windows kept waking it up all the time even while closed.
Using proofs just shifts the bugs into the assumptions/axioms (i.e you think your proof is proving X but it's actually proving Y)
Does that include storage costs?
Because a windfarm alone cannot replace a nuclear power plant no matter how cheaper or how much electricity the windturbines generate because on days without wind they generate zero Wh.
Unfortunately consoles have become normal PCs in this regard - if you wanna play online you'll be forced to update the console OS and applyvgame patches.
No one is stopping anyone from writing a compiler backend/optimizer in rust, yet it hasn't happened.
Complete madness and inefficiency.
There's no reason for the name "+" to be anymore special than "add" - especially in any language supporting unicode identifiers which allows even more crazy names.
Modular arithmetic makes it work. Try a few examples close to UINT_MAX if you want to convince yourself.
You can use the entire buffer and not waste one slot by doing:
push: buf[writeidx % bufsize] = x;
writeidx++;
pop: x = buf[readidx % bufsize];
readidx++;
Unsigned integers, you get size by doing: writeidx - readidx; Then you check size==0 or size==bufsize to detect empty/full.
No allocation = no leaks, no use after free, no dangling pointers.
No multi core = no atomics or concurrency to worry about.
Ring buffers solve 99% of my interrupt data sharing = no need to worry about synchronization.
Bounds/safety checks? Need to run and test release builds most of the time because of space/memory constraints.
Another is storing pointers in a hash table - you need to do arithmetic on the pointer bits to compute the hash.
It becomes an infinite recursion of "how do we know the proof of the proof of the..." is what we actually want?
Gets us on the path to more worlds.