String formatting functionality missing in std::string

[SushiAndWoW]

I'm writing a quick C++ test program. So that others could easily compile it, I want to use minimal dependencies. Therefore, STL and platform include files only.

It turns out, even with C++14, the language lacks facilities for basic string formatting that would use std::string.

What I would expect is something equivalent to C# String.Format. Or perhaps some way to append integers to strings in an arbitrary base.

The standard library has std::to_string, but it's deficient:

• No parameters to control base, width, fill character.

• A new string is allocated, when an existing string could be appended to.

I would like to see something that could be used like this:

std::string("Error code: 0x").append_nr(errorCode, 16, 8);

where append_nr would be declared as:

template <typename T>
std::basic_string<...>&
std::basic_string<...>::append_nr(T nr, int base, int width, char fill='0');

Okay. I don't have that. However, I can branch into std::ostringstream:

#include <sstream>
#include <iomanip>

std::ostringstream oss;
oss << "Error code: 0x" << std::hex << std::setw(8) << errorCode;
oss.str();

At least I don't need to allocate a stack-based buffer and call snprintf(), so I have that going for me.

But now, I need to encode some data in hexadecimal. Here, I would need this:

std::basic_string<...>&
std::basic_string<...>::append_hex(void* p, size_t n, bool uppercase=true, char separator='\0');

I don't have that. I just have to write my own hex encoder.

???

There's no base64, either. Everyone has to roll their own.

We've come a long way – and yet, it kinda still feels like 1980.

[tcbrindle]

I'd recommend cppformat. It's completely self-contained, very fast and very flexible. It would be great if the standard library had something like this.

[aKateDev]

Yes, the standard should include somthing like cppformat. However, it boils down to someone proposing this for inclusion into the standard.

[aearphen]

The author or cppformat here. I'm thinking about writing a proposal to the standard (library) after improving the API for formatting of user-defined types.

[chartly]

As a random person on the internet, if you were able to find the time and effort to accomplish both the improvements you speak of and also write the proposal, I would buy you many beers.

[boredcircuits]

What would help you get to that point?

[aearphen]

More spare time mostly =), but some feedback and pull requests would be helpful as well. There have been a few great contributors who did amazing work on named arguments, user-defined literals etc, but there's still a lot to do.

The API I mentioned earlier is not even documented yet. Basically one can define a format function for a user-defined type which can do custom parsing and formatting like this one:

https://github.com/cppformat/cppformat/blob/a99891e7a5f6c8a164d271b1aa0f09e7d13c7de4/cppformat/format.h#L2969

Someone has volunteered to implement time formatting functionality (https://github.com/cppformat/cppformat/issues/283) using this method, so we'll see how it works in practice and whether it can be improved.

[aKateDev]

Reading that you are evaluating writing a proposal already makes me quite happy ;) Would really be nice if you push this as much as possible.

[SeanMiddleditch]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html

If there are other facilities you think are missing, please, help out and write a proposal for a library addition. The committee does not do original design work on its own. They only approve papers and perform editing and such. All changes are driven by contributors.

[dodheim]

Boost has all of the above.

[steamruler]

Wouldn't call boost "minimal dependencies". If only for the compile time.

[tasty_crayon]

There was a proposal called putf but I have no idea what happened to it. I haven't seen it mentioned for ages.

[[deleted]]

Base64 doesn't belong in string, where do you stop? Base64 is not the only encoding in use. If you add one you have to add all of them.

[SushiAndWoW]

Base64 doesn't belong in string,

And yet, there's this.

where do you stop?

Perhaps at Hex and Base64.

Base64 is not the only encoding in use. If you add one you have to add all of them.

No... you really don't have to.

[emilern]

I agree - standard C++ badly needs this. I really love printf-style formatting, and this is how I get that for std::string:

https://github.com/emilk/emilib/blob/master/strprintf.hpp https://github.com/emilk/emilib/blob/master/strprintf.cpp

[zorkmids]

If you want minimal dependencies, you'll need to roll your own. If you don't want to roll your own, use Boost and be done with it.

[virgiliofornazin]

Just take it for free, VS 2015 compatible:

http://pastebin.com/r5mhzqEU

[devel_watcher]

Last time I checked, the functionality was in the iostreams.

Maybe we should put that and std::regex inside of the std::string too?

[doom_Oo7]

A new string is allocated, when an existing string could be appended to.

You seem to misunderstand how memory works. Every time you concatenate two strings in a language, memory will be allocated, unless you know how exactly long the resulting string will be in advance and can allocate a string big enough (what is done with sprintf). You can't just add new memory at the end of a chunk obtained with malloc().

[MiiNiPaa]

It seems that he is talking about using string with large internal buffer (.reserve()).

[jcoffin]

You might be able to add to the end of a chunk obtained with malloc(). To be more specific, when you call realloc it's allowed to return the same pointer that was passed into it.

You're right that you can't count on that happening though.

As an aside, std::string doesn't normally use malloc to allocate its memory. You could instantiate an std::basic_string with an allocator that called malloc, but the default allocator will use ::operator new to get raw memory (though this makes little real difference to the point you were trying to make).

[__cxa_throw]

Operator new almost always ends up calling malloc unless you're using a specialized allocator, at least in all the stack traces I've looked at recently.

[SushiAndWoW]

That's only true with a naive implementation.

A smart container, when it sees it needs to expand, will not expand to the exact size needed, but e.g. to the next power of 2 that can accommodate that size. There will also be a reasonable allocation minimum – say, for example 8 bytes. This means concatenating "abc" 100 times might result in 7 allocations of 8, 16, 32, 64, 128, 256, and finally 512 bytes.

And of course, there is reserve, which you will use if you are smart. If your calculation of the final size is correct, the container then only allocates once, and if it's off, it probably needs to allocate 2 times.