custom allocator support

[seanmiddleditch]

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.

[vitaut]

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::Writer too?

[seanmiddleditch]

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:

format<my_string_type>(format_string, arg1, arg2, arg3);

[vitaut]

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]

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]

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]

Initial support for custom allocators: a734f67

[vitaut]

Oops, wrong commit. Here's the correct one: 6a98f42

[vitaut]

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]

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.