uecker

13 ms·

301.
by uecker 5mo ago
Well, you give the explanation yourself: The size for the outermost array is not always needed, and then C allows it to be omitted. But my recommendation is to always give the size and then everything is regular and the compiler can use the
302.
by uecker 5mo ago
The point is much easier to propagate information (and not accidentally lose it) than to deduplicate after specialiation, so I do not agree that this is only of theoretical relevance. I agree that monomorphization has explicit rules that fo
303.
by uecker 5mo ago
But since you mentioned it, the interoperation of vec/span and arrays is also really nice in my opinion: https://godbolt.org/z/nYe48jh5d
304.
by uecker 5mo ago
The example shown does not use vec from my experimental library. But yes, I was thinking about making a custom-allocator version of vec.
305.
by uecker 5mo ago
It is a struggle though to get the improvements through the committee. Especially the C++ folks from the Clang side fight very hard against it, this is - for example - why we not have forward declarations where I already had weak consensus,
306.
by uecker 5mo ago
I don't know. I see people increasingly make use of it. The problem was that in the past compilers ignored this completely, so there was simply no point. Nowadays GCC uses it for warning (the length for bounds and "static" f
307.
by uecker 5mo ago
"breaks completely" I rather would say it works nicely in auto-generating the complex indexing operation for n-dimensional arrays which makes it a lot more convenient and less error-prone to write such code. The compiler may also
308.
by uecker 5mo ago
We are working towards this though and a lot of this already works: https://godbolt.org/z/EP3cP3qGs
309.
by uecker 5mo ago
No, I don't think this is true and just the usual nonsense used as justification. Some people continue to develop X, so I hope this is sufficient that I can continue to avoid Wayland.
310.
by uecker 5mo ago
It can always specialize where you could do monomorphization.
311.
by uecker 5mo ago
The vtable can be removed in all cases where you specialize by monomorphization, so the overhead compared to it is not really inherent. Type-erasure can be undone by specialization. In contrast, monomorphization specializes the code first,
312.
by uecker 5mo ago
What inherent overhead does type-erasure have? The optimizer can always specialize just like for monomorphization. The difference is that it does not have to do this. Monomorphization specializes everything before the optimizer even has a
313.
by uecker 5mo ago
Well, one could consider Mozilla's management of firefox to be outrageous, but then, Google pays, so what to expect?
314.
by uecker 5mo ago
It would also, but nobody cares enough because qsort is already fast enough for most things, and if you cared it is simply enough to do yourself. Are you doubting that C compilers can devirtualize function calls? Here is a small example t
315.
by uecker 5mo ago
I remember the story, but it was considered outrageous for a reason.
316.
by uecker 5mo ago
Some of Rust's problems may be fixable, but they are not being fixed at the moment and with something as complex as Rust, this is unlikely. I do not think monomorphization is an implementation detail, rather than a fundamental language
317.
by uecker 5mo ago
Yes, attacker controlled size without limit is bad (and this is also true for heap allocations). For VLAs there is -Wvla-larger-than that can be used to ensure there is a hard limit. To understand the risks of VLAs one also has to compare i
318.
by uecker 5mo ago
Why do you think they are dangerous?
319.
by uecker 5mo ago
Not sure what numbers you are talking about. If you use qsort from the C library the comparison function will not be inlined, but if you provide your own, this is no problem.
320.
by uecker 5mo ago
Assuming you mean the standard does not provide features for numa and simd? It doesn't necessarily have to. I think it is not surprising that you seem always bewildered that people still use C (as per your comments), as it seems you fu
321.
by uecker 5mo ago
Ah, the "what is not standardized does not exist" argument again.
322.
by uecker 5mo ago
Yes, a static_cast would be safe, but then most C++ seems to use a C-style cast because it is less clunky and then is less safe than the corresponding C code. The issue is not that the downcast is unsafe (it is, but once you have a void p
323.
by uecker 5mo ago
It doesn't have to be ISO, but some organization which follows some official rules and not some entity dependent on industry donations.
324.
by uecker 5mo ago
They make sense but reduce type safety, because once you add the cast the case might hide some real typing issue. I sympathize with the idea that the down-cast should be explicit though.
325.
by uecker 5mo ago
More complex != stronger. A weak type system would imply that the type systems forgives type mismatches. C had this before it imported prototypes from C++ where you could call a function without declaring it first and if you got it wrong
326.
by uecker 5mo ago
The correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in C this works nicely. The problem with mo
327.
by uecker 5mo ago
What IMHO Rust does not get right and why I do not use it: long compilation times, high complexity, its syntax, polymorphism based on monomorphization, the requirement for many dependencies to get anything done, an ecosystem susceptible to
328.
by uecker 5mo ago
It has no fundamental architectural advantages. That some newer features are now only implemented on Wayland makes the situation worse.
329.
by uecker 5mo ago
I think Rust has similar flaws as C++: too much unneeded complexity and abysmal compilation times.
330.
by uecker 5mo ago
Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the

More ›