Skip to content
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

Add support for string view? #21

Closed
thealastair opened this issue Feb 23, 2022 · 3 comments
Closed

Add support for string view? #21

thealastair opened this issue Feb 23, 2022 · 3 comments

Comments

@thealastair
Copy link

Would it be possible to add support for printing non-null terminated string views using the precision spec, e.g.

 std::string_view s = "world";
 pprintf("hello {}!\n", s);

would generate

printf("%.*s\n", s.size(), s.data());
@tfc
Copy link
Owner

tfc commented Feb 23, 2022

Hi,

this seems possible to me. A way to implement this would be to upgrade the part of the algorithm to be able to look at the next two types instead of only one, and pop them both off if there is a size_t and a char* coming.
For implementation mechanics, this means that at this code line we could feed the list of the remaining types to the format_str function, so it can consume as many as it wants. Then, it could return the rest of the list. Looking at this, my gut feel says that we would not need to change much around that.

I would however certainly not implement this like in your example where writing {} suffices, because i think it is too dangerous to have just the order of a size_t and a char* types in the arguments and then imply "so this must be a string view".
In that scenario i would at least have some kind of {sv} so the user can express "yes the following size_t and char* values are really from a string view and you can use them like that", similar as we already do that for string pointers where the user has to write {s}.

What do you think?

@thealastair
Copy link
Author

I was hoping there would be a way to not have to provide the size and data pointer directly, rather just the string view itself
have this library add the argument, but I guess that's not possible? The {sv} option would definitely be useful.

@tfc
Copy link
Owner

tfc commented Feb 23, 2022

Oh right, i missed that detail of your example.

It is possible, but then we'd be creating custom code again (Just like the template-based printf function in Bjarne's original C++ book).
The point of pprintpp is that it only creates the format string and leaves the rest of the printf call as is, resulting in zero extra code per printf call.

It seems like libfmt is what you need.

@tfc tfc closed this as completed Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants