Earlier quoted context omitted.
C23 includes constexpr for some constructs, by the way.
I know, and its very broken.
In what way? I haven't had the opportunity to try it out myself yet.
Problems of C, and how Zig addresses them
91–100 of 290 posts
Re: Problems of C, and how Zig addresses them
#92I'm no expert on either languages, but I tried Zig for the first time properly the other day. I really liked it up until I hit hashmaps. One thing that I think goes under-appreciated about C (and other languages with a similar paradigm) is thats its pretty upfront and clear about what it can and can't do out of the box. If you want hashmaps in C, you need to create your own implementation, otherwise think of a way ro…
As counter point, the way that Zig implements hash maps is absolutely instrumental for TigerBeetle. Zig hashmaps _are_ quite a bit more cumbersome than, eg, in Rust --- you need to decided whether you want the allocator to be bundled with the hasmap, and its also up to the user of the hash map to provide equality and hash code (and, of course, there's manual defer instead of RAII). However, this flexibility and verbo…
> No other language I know has an equivalent tool.
I completely agree: this has been my experience as well.
Re: Problems of C, and how Zig addresses them
#93OK, so Zig to C is like Typescript to Javascript.
TS is just modern JS with type annotations.
Zig OTH is "just C" but with a modern syntax, much more correctness, comptime, reflection, generics, a rich standard library, an integrated build system, cross-compiling that 'just works'.
(I'm sure I forgot a couple of things)
Re: Problems of C, and how Zig addresses them
#94Earlier quoted context omitted.
> If I were to use indices out of range, presumably that would that give me a compile time error? Yes, if all operands are comptime-known (or comptime-length-known), bounds checks happen eagerly at compile time. > Could I use variables as the indices and, if so, could I get a seg fault at runtime or are there some sort of guards on there? Yes you can use variables. If they're out of range, behavior depends on the bui…
Why not just compile your whole program safe and then demarcate which functions you want to not be safety checked?
Careful, you're dangerously close to suggesting an effects system. If the function explicitly marked as doing unsafe math operations calls another that doesn't specify a preference, should its math operation be safe or unsafe? If the former, this makes it likely a better default, but limiting in its usefulness. If the later, then your compiler now has to keep track of this information for the entire call graph.
Re: Problems of C, and how Zig addresses them
#95I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…
Don’t even need operator overloading for vectors/matrices. It would be fine if we could simply define new operators (functions with infix notation) and use those. This would allow us to define an operator for matrix multiplication, matrix-vector product, dot product, and cross product.
Having to define these operators as functions with unique text names is extremely ugly and serves no purpose that I can see.
Re: Problems of C, and how Zig addresses them
#96Earlier quoted context omitted.
Pretty much a matter of optimization isn't it? Try disabling them. But I take it that this was never the point anyway. I think the point is that the representation of language objects and the runtime are rather straightforward compared to many other languages.
Only one of those (inlining) is an optimization. Two are language features (implicit casts and volatile) and the other is a calling convention (passing arguments on registers vs. stack).
Calling conventions aren't (mainly) a C feature either though, but are defined by the ABI specified for a specific OS/CPU combination (and all languages which want to talk to system APIs need to implement that ABI, not just C).
Re: Problems of C, and how Zig addresses them
#97One thing Zig is missing is Exception Handling. Now before you complain about exception handling grossly bloating the size of a program, know that there are ways to trigger exceptions that do not involve the "throw" keyword. You get processor exceptions when you access a bad pointer, divide by 0, etc. If you don't want the program to instantly terminate, you need to be able to handle those exceptions.
So far, it seems that the only way to handle exceptions is to use another programming language. Zig allows you to mix in C or C++ code.
Re: Problems of C, and how Zig addresses them
#98Earlier quoted context omitted.
It's true and false at the same time. The operations C gives you map 1-to-1 with assembly. Given some C code you can quite accurately predict which loads/stores will be elided by the compiler and what the resulting assembly will be. I can't name another language for which this is true. I get that you're hinting at the insane level of undefined behaviour enforcement by compilers, but I don't think it matters all that…
In C, unlike pretty much every other language, you can't even know how big an integer is.
Of course you can, but this is implementation defined. So you need to create code that does different things based on the underlying implementation. Every reasonably large C code base checks the current implementation to define what type of integers, pointers, etc. they're dealing with.
This is by design, because C was created do deal with disparate processors and OSs. When it was crated it would be difficult and unwise to assume that an integer has size of 2 bytes, for example, since each machine would define its own preferred length.
Re: Problems of C, and how Zig addresses them
#99Earlier quoted context omitted.
Do you mean in zig? It's possible to do arbitrary, bounded computation (compiler quits if you expend "too many tokens") at comptime in zig, unless there is strange statefulness. This is sensible since you want changes in, e.g. your code tree to taint compiled resources. If your code can go read from the filesystem in an untracked way, you break the incremental compilation model.
This was sort of a general question, although Zig confused me a bit by placing the annotation at the call site rather than on the function declaration. I guess this choice was made to keep compilation times under control.
A function should not have to be labelled as comptime to be run at comptime. There are cases when you might want to run the same function at comptime as at runtime (for example, if you want to do a thing with algorithm X but cache the result for a series of trivial cases as a lookup table).
Putting it at the callsite is more explicit actually and for example generating precompiled arrays clearly ties comptimeness to the actual artifact created instead of making it inferred from the signature of the function (which may be very far away in code)
Re: Problems of C, and how Zig addresses them
#100Earlier quoted context omitted.
Why not just compile your whole program safe and then demarcate which functions you want to not be safety checked?
Careful, you're dangerously close to suggesting an effects system. If the function explicitly marked as doing unsafe math operations calls another that doesn't specify a preference, should its math operation be safe or unsafe? If the former, this makes it likely a better default, but limiting in its usefulness. If the later, then your compiler now has to keep track of this information for the entire call graph.
The form of safety we are talking about here is not like rust's "safety", it does not color functions, and is strictly scoped to the compiled unit (in this case, function)