You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, I have to say his project is incredibly impressive. Most of it is exactly how I'd do it myself if I made this, or even better than what I would come up with.
There are a few things though which I see missing. Or I wish could change.
There needs to be some way to control struct alignment. Such as the GCC align attribute. But I'd also like to be able to use the C Bitfield syntax in struct declaration.
I would like to be able to optionally deal with strings entirely on the stack. Allocate and manipulate strings entirely in stack buffers. Have methods like tostring be able to write them out to stack buffer. Forcing strings to be dealt with on the heap is disruptive to some of the C style of programming.
More control of allocators in general would be good. I think maybe taking a few notes from odin or zig might be good here. Where anything that creates an allocation has to have an allocator explicitly passed to it. Or that you could switch the default allocator for an entire scope and have everything in that scope automatically use that. Nothing should be using the heap by default and not be controllable.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
First, I have to say his project is incredibly impressive. Most of it is exactly how I'd do it myself if I made this, or even better than what I would come up with.
There are a few things though which I see missing. Or I wish could change.
There needs to be some way to control struct alignment. Such as the GCC align attribute. But I'd also like to be able to use the C Bitfield syntax in struct declaration.
I would like to be able to optionally deal with strings entirely on the stack. Allocate and manipulate strings entirely in stack buffers. Have methods like tostring be able to write them out to stack buffer. Forcing strings to be dealt with on the heap is disruptive to some of the C style of programming.
More control of allocators in general would be good. I think maybe taking a few notes from odin or zig might be good here. Where anything that creates an allocation has to have an allocator explicitly passed to it. Or that you could switch the default allocator for an entire scope and have everything in that scope automatically use that. Nothing should be using the heap by default and not be controllable.
Someway to make use of data stored in macros in C headers. A lot of Khronos libraries encode a bunch of useful data as C macros. Can see an example here: https://github.com/KhronosGroup/OpenXR-SDK/blob/main/include/openxr/openxr_reflection.h Someway to be able to access that and use it in the nelua preprocessing would be useful.
Beta Was this translation helpful? Give feedback.
All reactions