-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Documentation issues #320
Comments
Or in other words, while everything there might be common knowledge for someone doing formatting every day, 99% of the time I just do |
One use case I have is efficiently formatting a lot of floating point numbers into a large file. My plan was to open a new file in append mode, creating a writer, reserving some memory, and in a loop: clear the writers contents (without freeing the memory), formating into the writer, appending writer contents to a file. However it doesn't seem to be possible to neither reserve nor clear a writers memory, so maybe I shouldn't be using the writer API for this. |
Thanks for the detailed feedback.
I've tried to clarify this in f765832. You can view the development docs here: http://fmtlib.net/dev/api.html
Do you mean examples in the syntax or API section?
Good idea.
Floating-point formatting is currently based on
No, but it should be easy to add. I think you have nice ideas for improving the docs. Would you by any chance be interested in contributing? |
Sounds reasonable. The buffer will grow dynamically and subsequent writes can reuse it without reallocation. There are undocumented methods to get access to and clear the buffer called |
(cherry picked from commit f765832)
Migrated the item about examples to #213. |
I was going through the documentation and found out the following minor issues:
But the docs do not mention much more about this. There is a link to a benchmark page but in my opinion the documentation should make it very explicit which API to use to get the fastest code (the documentation of the writer API should say this), and the documentation of the slower API (the format API) should have disclaimers that indicate that, while possibly nicer/more convenient, that API is slower.
{:+03.2f}
. ).f
org
ore
the syntax page would show, next to the option, how a particular floating point number would get formatted out. That is, it would be nice to have one or two examples of "number + syntax + result" next to each option. It would be nice if the examples would range for simple{:e}
to more complicated involving also+/-
, precision, positional arguments, corner cases (inf, nan). For example there is a situation where it is explained how to translate from C fprintf syntax to fmt syntax. While this is nice, I actually had to google what the C fprintf syntax actually meant.BasicMemoryWriter
? I thought this would be very important for performance but it doesn't seem to be possible.These are just nitpicks, all the information is there, but the docs make me in my opinion invest too much effort into putting it all together. Complicated examples that make use of all the features would really help.
The text was updated successfully, but these errors were encountered: