4 ms·
This is true for libraries that have a lot of variable sized types. There are however a lot of interesting problems where you don't need many of these apart fro
by bwindels 8y ago
This is true for libraries that have a lot of variable sized types. There are however a lot of interesting problems where you don't need many of these apart from, say, one big buffer you work with. A good example of this is a parser, or this TLS library: http://bearssl.org/ http://bearssl.org/. It makes integrating with a library maybe a bit more tedious but it comes with so much more control. And you could always build a layer on top that does malloc for when you don't need the control. It's great for code that will be used in many different scenarios.
- codehero 8y agoChoose the size representation that bests fits your use case: // Put this in header to help user calculate allocation needs but hide size from user size_t LIBNAME_alloc_size(param1, param2, ...); // Put this in the header to hide the size from user code but allow inlined size calculations extern const size_t LIBNAME_ALLOC_X; // Put this in the header to make size known to user (for static const allocation) #define LIBNAME_ALLOC_Y ((size_t)42)