Repository navigation
custom allocator support #69
Description
I run into issues where I have a large number of strings to format for debug purposes in a game engine. The allocations that happen in this case are being a major drag.
An ideal solution would be to use a per-frame arena allocator. This is a typical way of dealing with issues like these. However, cppformat gives me no control over its internal allocations when the internal buffers aren't big enough and it gives me no control over the returned C++ string type (or its allocator) when using the simple/obvious API.
It would be nice to be able to override the allocator per invocation of cppformat. It would also be nice to either be able to override the string object type used or to at least provide the Allocator to the underlying std::basic_string.
Activity
vitaut commentedon Sep 16, 2014
You can control string allocation and override the string object type by providing a custom formatting function:
typedef std::basic_string<char, std::char_traits<char>, std::CustomAllocator> CustomString; // You can also pass allocator's parameters here if necessary. inline CustomString custom_format(StringRef format_str, const ArgList &args) { Writer w; w.write(format_str, args); return CustomString(w.data(), w.size()); } FMT_VARIADIC(CustomString, custom_format, StringRef)Or do you want to control allocations in
fmt::Writertoo?seanmiddleditch commentedon Sep 16, 2014
Preferably all allocations. Just about every piece of game middleware or library used in games allows at the very least a way to override global malloc/free (new/delete) in the library if not a more C++-y approach to controlling allocations.
I can imagine that there may be a nicer way to override string types than writing a custom format function, too, e.g. by using a template parameter on the existing functions:
vitaut commentedon Sep 17, 2014
I'll add support for custom allocators to the library. Thanks for the suggestion.
I'm not so sure about adding a generic overload to support custom strings. Specifying string type makes it rather verbose and it is easily done in a few lines of code by writing a custom formatting function. Do you have any practical example where the generic version can be useful?
seanmiddleditch commentedon Sep 17, 2014
Other than the many apps that use QString or CString or various other favors of string type... I guess not. It's admittedly very much an opinion whether the template syntax is easier or not, but my opinion is that the custom syntax you showed requires some knowledge of special macros and other details of cppformat while the template syntax is idiomatic C++.
seanmiddleditch commentedon Sep 17, 2014
There's also cases I suppose where cppformat may itself be used inside some other template that would want the composability, but I don't have a practical example or use case of that at the moment.
vitaut commentedon Sep 18, 2014
Initial support for custom allocators: a734f67
vitaut commentedon Sep 18, 2014
Oops, wrong commit. Here's the correct one: 6a98f42
vitaut commentedon Sep 25, 2014
Sorry, I've been a bit busy with some other stuff lately. Now that I have time to look into this issue again, I'm going to improve separation between memory management and formatting. Then custom allocator support can be completed.
vitaut commentedon Oct 1, 2014
Custom allocator support has been implemented and will be included in the next release. I've also written a small section on using custom allocators with the library: https://github.com/cppformat/cppformat/blob/master/doc/index.rst#custom-allocators
This also shows how to return a non-standard string from a formatting function.
microcai commentedon Nov 12, 2024
why not support std::pmr::string?
vitaut commentedon Nov 14, 2024
You can use
format_towithstd::pmr::string.