dzaima

62 ms·

901.
by dzaima 5y ago
mathematically, yes. In practice, NaN!=NaN just kills any hope of having any amount of sanity for operations that don't care about floating-point and just want to generally compare things. It's not very nice to say "sorting,
902.
by dzaima 5y ago
greater-than and less-than already make no sense around NaN, you won't get much worse, I don't get what you're trying to point out with them. This is less a question about mathematical correctness (which there isn't much
903.
by dzaima 5y ago
I guess all I can say is one man's thrash is another man's treasure. I personally don't have much a reason to care about mamory safety of my programs, so I would hate to have restrictions on what and how I can do things, it
904.
by dzaima 5y ago
That's pretty much always a problem of memory corruption, which, imo, is very much a separate thing from undefined behavior. Yes, double-free, use-after-free, or reading out-of-bounds is undefined behavior, but -Onone won't make t
905.
by dzaima 5y ago
Using C is a tradeoff. I personally wouldn't write unsandboxed mission-critical code that has to interpret untrusted remote user input in C. But for anything that's not that, the freedom it gives over everything is awesome, and it
906.
by dzaima 5y ago
It definitely depends on the project. There are plenty of domains where hashmaps are useless, and some where half the things you do need one, and many in between. The in-between is the worst - if you need a hashset/hashmap just once, y
907.
by dzaima 5y ago
If those utilities make up an excessively large portion of your program, C probably isn't the best choice. As long as you don't care about performance lost from the non-zero costs of "zero cost abstractions". If you&#x27
908.
by dzaima 5y ago
I really don't get why everyone is so afraid of undefined behavior. It's really not that bad. Learn and use it as another tool, instead of blindly hoping you won't encounter it and be surprised when you do. Sure, C has some c
909.
by dzaima 5y ago
You might want to move around some file descriptors if you don't want the child process to inherit your stdin/stdout/stderr (e.g. if you want to read the stdout of the process you launched, or give it some stdin). And there d
910.
by dzaima 5y ago
X11 doesn't provide anything for opening a file dialog. afaik you have to just call GTK-specific things to achieve that (hell there's a C library specifically for just opening a file/folder open/save dialog). X11 itself
911.
by dzaima 5y ago
The kernel ABI barely matters for most things. You'd hope libc wouldn't break. What's important is window managing APIs, graphics APIs, file system structure (your program location, user config location), environment variab
912.
by dzaima 5y ago
heh, the tag names in that demo video follow a hierarchical structure - .didget.Name, .didget.SHA1, .fileSystem.Ancestor, .fileSystem.Folder, .... So now not only do you have a hierarchical (but optional, which is worse imo) structure for f
913.
by dzaima 5y ago
I've been working on my own text editor (which I'm apparently not the only one doing that here), and my plan is to switch to using a single B-tree, where the leaf nodes, besides holding the text (and also a color list for basic sy
914.
by dzaima 5y ago
That depends on the project. There definitely are projects in which micro-optimizations such as this wouldn't be beneficial for one reason or another, but there definitely also are ones where they're make-or-break. For those, C is
915.
by dzaima 5y ago
The common case may be fast, but it's still slower than not having a rare case in the first place. The untaken branch will still affect register allocation (out of the ~15 x86-64 general-purpose registers, only 5 (6 if you count rbp) p
916.
by dzaima 5y ago
linked lists - true, but at least when you write them you'll be certain of what they do, and, coupled with knowledge of cache performance, precisely how bad they are. About reallocation I don't even mean the copying, but just the
917.
by dzaima 5y ago
In C it's possible (and, to some level, very much encouraged) to write your own things to replace whatever built in thing you don't like for whatever reason, be it speed, size, portability. C not having fancy built-in structures m
918.
by dzaima 5y ago
but there is, see: document.querySelector(".zci__body").textContent.charCodeAt(0) document.querySelector(".zci__body").textContent.substring(1)
919.
by dzaima 5y ago
Here's my random x86 extension: the byte sequence 0xc5,0xfd,0xd4,0x00 sorts the 64-bit floats in ymm0. It conflicts with AVX2. :)
920.
by dzaima 5y ago
There's no way to prevent overlapping extensions. One could easily make an x86 extension that overlaps with some existing one. There's just as much an incentive to not do that for x86 as there is for RISC-V. See AMD's SSE5 vs
921.
by dzaima 5y ago
In practice, at least C compilers don't automatically generate code for multiple extensions, so you get the performance of the base ISA by default. This does indeed mean that every C program for x86-64 that isn't compiled with a s
922.
by dzaima 5y ago
C doesn't exactly have "runtime code that you didn't have to write yourself" though. There's libc, but you can easily disable it, and having any form of defer be unavailable then is just bad. Everything else comes f
923.
by dzaima 5y ago
defer, as proposed here, isn't a library feature though, it's a part of the core language. I'd like to be able to use it, but if it can ever do a malloc (which is horrifically slow compared to not having one), it's just
924.
by dzaima 5y ago
It's not the mutexes that'd be stack-allocated, but the list of things to call back to at the end of the function. The locks list could be modified or freed by the end of the function, but something still must hold the list of t
925.
by dzaima 5y ago
..Except that in C that'll turn into stack allocations and will easily segfault due to a stack overflow. So you can't actually use it like that in practice (unless you can guarantee your loop will be called a small number of times
926.
by dzaima 5y ago
Why not also, while at it, disallow spaces too? They can very easily cause problems too, if you split by spaces instead of newlines. Quotes and backslashes obviously are also bad. How about all of non-ASCII unicode? That'd break all co
927.
by dzaima 5y ago
> It's a full word, not a single letter operator. Its uses add up to noise pretty fast. But it's still 1) a different color; 2) always in the same place (along with static/final). For me to call something "noise"
928.
by dzaima 5y ago
> Imagine that every time I write a sentence I prepend "Banana699 says" or "Banana699 thinks" It's more like starting paragraphs with ">" here. It'll also consistently be at the start of single
929.
by dzaima 5y ago
'public:' / 'private:' / whatever may save you a couple milliseconds when defining a new class, sure. At the cost of having to scan arbitrarily far backwards to find the visibility of a given thing. I personall
930.
by dzaima 5y ago
Using casts between types with different generics can cause "heap corruption", but the compiler will give warnings on them (except if explicitly suppressed). The article doesn't use any such casts, but can still "cast&qu

More ›