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
When we need to handle JS arguments who are slices (string are slices, but we have also variadic arguments and arrays), we need to allocate them on the heap, before filling it with the JS values translated in Zig.
Right now those slices are not free after calling the API function.
We can free them automatically easily, right after the function call.
The good thing if we do so is that we use less memory.
The bad thing is that the API function will have the responsibility to duplicate them (ie. allocate), if needed.
It's not a problem per se, as the API function has already the possibility to ask an allocator in its arguments.
It's just something that the API function will be responsible of.
For example if a setter User.set_name(name: []const u8) takes a string, it can now just save the string in its internal fied, without worring about it.
With this change the setter signature will be User.set_name(alloc: std.mem.Allocator, name: []const u8) and the function will have to copy/duplicate the slice, only if it want to keep it for further usage of course.
The good thing of leaving the responsability to the API is that duplication (ie. allocation) will not be systematic: sometimes a function just want a slice to do some logic without storing it.
For example document.createElement(tag_name: []const u8) will not store the tag name, just using it to process the element creation. So in this case the change will reduce memory consumption.
The text was updated successfully, but these errors were encountered:
When we need to handle JS arguments who are slices (string are slices, but we have also variadic arguments and arrays), we need to allocate them on the heap, before filling it with the JS values translated in Zig.
Right now those slices are not free after calling the API function.
We can free them automatically easily, right after the function call.
The good thing if we do so is that we use less memory.
The bad thing is that the API function will have the responsibility to duplicate them (ie. allocate), if needed.
It's not a problem per se, as the API function has already the possibility to ask an allocator in its arguments.
It's just something that the API function will be responsible of.
For example if a setter
User.set_name(name: []const u8)
takes a string, it can now just save the string in its internal fied, without worring about it.With this change the setter signature will be
User.set_name(alloc: std.mem.Allocator, name: []const u8)
and the function will have to copy/duplicate the slice, only if it want to keep it for further usage of course.The good thing of leaving the responsability to the API is that duplication (ie. allocation) will not be systematic: sometimes a function just want a slice to do some logic without storing it.
For example
document.createElement(tag_name: []const u8)
will not store the tag name, just using it to process the element creation. So in this case the change will reduce memory consumption.The text was updated successfully, but these errors were encountered: