-
-
Notifications
You must be signed in to change notification settings - Fork 91
Added a simple custom allocator system #110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Added json_write_minified_ex() using the new allocator scheme
| json_free_func_t *free; | ||
| /* Custom user data pointer. */ | ||
| void *user_data; | ||
| /* Padding to align struct. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this padding?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alignment padding is always a good idea.
Sure you can leave that out, but i always do this. Its a habit, i am a low-level programmer and i care about CPU cache alignment a lot.
| }; | ||
|
|
||
| json_weak struct json_allocator_s json_create_allocator(struct json_allocator_s *custom_allocator) { | ||
| if (json_null == custom_allocator || json_null == custom_allocator->alloc || json_null == custom_allocator->free) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about this - so if you mess up one of the allocators it just falls back to the default allocator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, you don't want an allocator that is half-baked / mixed. Either you specify it or not.
| json_weak struct json_value_s * | ||
| json_parse_ex(const void *src, size_t src_size, size_t flags_bitset, | ||
| void *(*alloc_func_ptr)(void *, size_t), void *user_data, | ||
| struct json_allocator_s *allocator, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What gives me pause with this is that this can imply that we would call free in this function, which we definitely will not. I think I'd rather keep the old API and just explicitly add another argument for free_func_ptr on the write functions that need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added that which makes the most sense for me. Also i really hate such long prototypes defined directly in an argument. If you could at least make a typedef for that, then it would be much cleaner. But you can do whatever you want. I wrap your library anyway, which i do for all external libraries i use.
I added a simple, but powerful custom allocator scheme to your library, that fully replaces all malloc/free calls - but still uses malloc as its default allocator, when not overridden by the user.
In addition i added json_write_minified_ex() and json_write_pretty_ex(), to support a custom allocator in there as well.
I would really appreciate it, if you could merge that into your master branch. Thanks!