strf should warn you when using 0 as a fill character about strf HOT 10 CLOSED

I have no idea how that could be implemented. But I will think about.

from strf.

@robhz786 : Well, could arrange it so that non-character integers have their own overload, which static-asserts false.

Also, you could perhaps consider preventing this from happening altogether by dynamically checking the fill value to not be zero.

from strf.

Well, could arrange it so that non-character integers have their own overload, which static-asserts false.

Yes, that's certainly possible. But in this case, we would get an error instead of a warning. If that's fine with you, it is fine with me.

Also, you could perhaps consider preventing this from happening altogether by dynamically checking the fill value to not be zero.

In this case, we need to decide what the library should do when it is zero. Typically, strf prints a replacement character when there is something wrong ( U'\uFFFD' or '?' ). But in this case, maybe it could instead print the zero digit '0'. But I think like more the idea of using a static_assert

from strf.

Yes, that's certainly possible. But in this case, we would get an error instead of a warning. If that's fine with you, it is fine with me.

It is fine by me. If somebody wants something else, let them file an issue :-) No need to cater to unrealistic and purely theoretical use-cases.

from strf.

The proposed solution is on master branch now, but I'm not satisfied. I've been thinking that if people are using '0' as the fill character then perhaps something else should change in the library.

What I now think that should actually be done is to add two new format functions for integer and floating points:

• operator~ : same effect as the space flag in printf: insert a space before non-negative numbers
• zeros(unsigned sub_width) or just z(unsigned sub_width): insert '0' before the digits and after the sign or base indication such that the total number of non-fill character is at least sub_width

Examples:

assert(strf::to_string(~fmt(123))      == " 123");
assert(strf::to_string( fmt(123).z(6)) == "000123");
assert(strf::to_string(fmt(-123).z(6)) == "-00123");
assert(strf::to_string(~fmt(123).z(6)) == " 00123");
assert(strf::to_string(+fmt(123).z(6)) == "+00123");
assert(strf::to_string(~fmt(1.5).z(6)) == " 001.5");

Note that the argument passed to z function is independent from the witdh passsed to the alignment functions:

assert(strf::to_string(~fmt(123) < 10)      == " 123      ");
assert(strf::to_string( fmt(123).z(6) < 10) == "000123    ");
assert(strf::to_string(fmt(-123).z(6) < 10) == "-00123    ");
assert(strf::to_string(~fmt(123).z(6) < 10) == " 00123    ");
assert(strf::to_string(+fmt(123).z(6) < 10) == "+00123    ");
assert(strf::to_string(+fmt(1.5).z(6) ^ 10) == "  +001.5  ");

After that, I think I should remove the p(unsigned) option for integers and operator% for all types.

I would like to know what you think about idea.

from strf.

No, I think this solution I just proposed is not ideal either. I will think more about it and maybe reopen this issue later, or maybe open another one.

from strf.

Just had a look at this. Well, I don't like super-short identifiers like z. I also don't like non-intuitive operator overloads, like ~. It's enough that we need to memorize C string formatting codes, and C++ stream manipulator names, and in C++20 also std::format codes... so the less you add to that, the better.

from strf.

Instead of creating z, perhaps we could change the meaning of operator%?

assert(strf::to_string( fmt(1) % 6) == "000001");
assert(strf::to_string(+fmt(1) % 6) == "+00001");
assert(strf::to_string(*hex(1) % 6) == "0x0001");

So operator% would almost continue to do what it does today, except that:

• It would insert zeros before the digits and after the sign or base indication
• It could only be used for numeric types.
• NaN and infinite floating-point values would not be prefixed by zeros.

The fill character would appear when the '0' should not, like in the case of NaN values and when space() is used:

constexpr auto nan = std::numeric_limits<double>::quiet_NaN();
assert(strf::to_string(+strf::fmt(nan).fill('*') % 6) == "**+nan");
assert(strf::to_string(~strf::fmt(1.5).fill('*') % 6) == "*001.5");
assert(strf::to_string(*strf::hex(1).fill('*') % 6)   == "0x0001");

And the global function split ( that invokes operator% and fill() ) would be renamed to something else, like zeros:

assert(strf::to_string( strf::zeros(nan, 6, '*')) == "***nan");
assert(strf::to_string(+strf::zeros(nan, 6, '*')) == "**+nan");
assert(strf::to_string( strf::zeros(1.5, 6, '*')) == "0001.5");
assert(strf::to_string(+strf::zeros(1.5, 6, '*')) == "+001.5");
assert(strf::to_string(~strf::zeros(1.5, 6, '*')) == "*001.5");

However, I don't know what function name could be used instead of operator~. Maybe space(), but it would be misleading since it's not actually a space character ( but the fill character ) that is printed.

from strf.

I'd rather see something which says "fill" or "pad" or "width" etc.

from strf.

Created issue #29 to deal with this matter.

from strf.