@cblake I think it should be handled at nim level, because it can be hadled at
Nim level. The more things can be resolved at the Nim side, the more powerful
the language is. On the other side, Nim does not only have a C backend, it also
has an LLVM backend. I do not know the state of this
You are right that C compilers already strive to ensure ABI struct compatiblity
which is why I think having Nim leverage that effort is better than reproducing
it at the Nim level, though using backends themselves to pre-generate things
may help. My point was to get truly Nim-time resolved
@Araq
I just looked at `magicsAfterOverloadResolution`, since you said it is the
preferred way. I tried to find the `mSizeOf` handling in there for an example,
but it is not handled there. I would like to know what I am actually supposed
to do in this procedure. What information do the
@cblake To my research Each platform (x86 arm powerpc) may have different
alignment rules. But there is definitively no alignment rule distinction
between compilers, otherwise it would be impossible to use structs as
interfaces in C. This makes header files in C compatible between different
> For my use case it is very important, that I can get all the sizes at compile
> time
You may not be able to make all these things available at Nim-compile-time
because they are not fully determined until the C (or whatever) backend compile
is reached. For example,
type foo
There are multiple ways to do this in the compiler and you need to play around
to see what works best for sizeof and alignof and offsetof.
* Add new `mAlignOf`, `mOffsetOf` to the `ast.TMagic` enum.
Either add the handling to:
1\. `magicsAfterOverloadResolution` in `semmagic.nim`
Or:
2\.
What do you mean by 'bind'?
Currently I improve the proceduer `computeSize` in `types.nim`. I worked now
quite a bit on the procedure, but I don't understand, how `system.sizeof`
eventually calls `types.computeSize`. I know that in some cases the call
system.sizeof was not able to be evaluated at compile time. I would
