Gennadiy Rozental a écrit, le 23/11/2009 17:37:
No. This is really low level function, which is using snprintf:
As I am currently updating boost.format (to answer feature requests, and also improve performance : iostreams used to be so much slower than printf that optimizing boost.format didn't make much sense - now it seems g++ streams/locale were significantly improved so I got back to it, and aims for 10%-20% overhead compared to equivalent stream operations) Anyway, it's interesting to hear about various formatting usages. There is probably a few incompatible constraints between those that require low-level low-flexibility and those who need more flexibility (at a cost), with C++0x on the horizon it could be a good time to rethink how boost want to handle formatting (and the different kinds of formattings).
2. There is a requirement of no memory allocations
Why ? Is it no memory allocations per-se, or rather no memory allocations each and every call (because of performance impact) ? If it is the latter, reusing a static format object (or stringstream, or a modified version that could write to a static buffer - like the custom stringstream written for boost.format) can solve the issue in single thread. And "thread_local static" makes it work in multi-thread too, but of course that keyword can not be relied on yet. If you really can not allow any memory allocation then you're on your own if you can not use snprintf either.
3. I do not need any fancy formatting. I just want to validate that there is not preallocated buffer overrun.
Really basic formatting, like just dumping integers into a char buffer can be portably coded in a few lines if snprintf is not available. Or you could maybe implement an output iterator that writes into the char buffer (and checks for end of buffer) and use it with the num_put facet. So, if snprintf really can not be made available on (almost) all platforms, it might make sense to implement some basic number-to-char-buffer facility in boost, that does not rely on snprintf (nor locales, maybe). But that kind of basic function would not directly replace snprintf for some of Boost.Test lines : (in debug.ipp:320) ::snprintf( title_str, sizeof(title_str), "%*s %ld", (int)(dsi.binary_path.end()-it), it, dsi.pid ); Couldn't Comeau just make snprintf available to its C++ compiler ? And is there any other platform that lacks snprintf ? -- Samuel