That doesn’t tell me what the issue is.
Casting pointers to ints and back in that code is completely unnecessary and looses the little type safety you have left, that being the function signatures
Totally agree… but that is how I would have done it in C, so until I am more clever that will have to do 
As, this does not care what is comptime known
I’m assuming print and printB dont take *anyopaque, but do take different pointer types?
either change the functions, or make a wrapper then you can just
var s = MyStructA {};
// etc...
if (s.b > 200) {
MyStructA.print(&s);
} else {
MyStructA.printB(&s);
}
also when casting pointers use @ptrCast, it prevents you from doing something silly, the silly casts have their own builtins as they are sometimes needed but should be avoided.
Thanks for you recommendations. Will have a look. The documentation on some of the pointer operations are definitely a little bit inadequate, or I am trying to read too much into it. I really don’t have the time to look at assembly to understand it, but will investigate.
I think a lot of the Ziggit topics about adding language features would go more smoothly if this was plastered everywhere. I think when people think of simple code what comes to mind is terse, readable code rather than longer code with limited syntax/keywords.
1 Like
I have no complaints at this point. Zig fits the gap neatly as a “super-C” for me. The language has some getting-used-to items that catches me often. That said, I quite like it (Zig). The biggest issue stopping me from committing wholeheartedly is the fact that I have very little confidence in 3rd part libraries at this point, that while Zig is really bare-bones even on simple take for granted items.
What I particularly like (over C):
- The file organization and “implied” namespaces.
- The struct that can have both receiver, static methods and other types.
- A consistent error mechanism, that mimics “exceptions”. This is my biggest issue with GoLang (1 of 2 actually).
- It is not opinionated in its threading, memory sharing model. It fits my brain pattern wise.
- No nonsense cross compilation (a must for me) and many more (no GC etc)
I can also totally understand why/if the status quo is to keep it un-opinionated.
What I think is going to hurt me most if/when I convert existing code or really start to do utilities in Zig is… the near complete absence of strings. (I have started my own old Pascal String type library - to ease the pain…). Bare bones…
3 Likes
One of the great things about zig is you can use c libraries, some trivial wrappers are needed if you want to use zig pointers/errors
but without those it’s basically c with defer, still a massive improvement
you also get to use the zig build system instead of whatever the library uses, ofc that’s optional if you don’t want to put in the time or effort
2 Likes
Understood @vulpesx … Obviously one want to avoid that unless really necessary as that cause other complexities, e.g. platform, architecture, handling errors etc. I am not saying that the C libraries does not include it, but I would hope that in future that since Zig is multiplatform, that the developed libraries will be Zig friendly (or mostly) across platform and architecture - like GoLang?
1 Like
Also, don’t have a feel yet for how foreign C imports will be - will have a look. I understand that there is the option but need to investigate. Foreign meaning how trivial the wrappers are and how awkward the “proxy” code is, that you speak of.
its just that zig distinguishes between single item pointers and multi item pointers and slices and sentinal termination as part of the type.
c just has a pointer
zig supports c pointers [*c] which coerce to and from zig pointers.
wrappers are just to have an api that yells at you for providing a non terminated pointer etc
also to convert to zig errors.
if you dont want to bother with that, then you deal with the vagueness of c pointers
4 Likes
I have now integrated with various Linux libs (most using *c) - sweet as honey and easy as cake. On Windows however, sour as a lemon :-), still struggling there (but fortunately not too important at this time) / not with Zig though - more with the sheer number of conditionals and crap you have to do as the simplest things are intertwined with a 1000 others.
@vulpesx
This probably needs to be on a different thread… but I have, in my limited testing, found that structs are “never” copy elision-ed. Like in C++ where the return value on the stack is not copied but simply rolled up onto the stack.
I definitely assumed that it would do this… This also is not the end of the world it is just an understanding opportunity.
1 Like