String constructor: specify significant figures?

Could we get an additional String constructor to specify the number of significant figures in a float value (as apposed to decimal places).

When using certain values with a large range - such as frequency - it’s nice to be able to keep the displayed values a consistent length (20.000, 200.00, 2000.0, 20000). At the moment I can manage this with a rather ugly if-else block and setting the String’s decimal places based on the value but it would be nice to be able to do this in one line.

2 Likes

https://github.com/WeAreROLI/JUCE/commit/41e72515199e71c4a9bf9ab14bac8b61f8c82202

5 Likes

This is great, thanks @t0m!

btw, what’s the easiest way to get a String with a fixed number of decimals ?

i.e. to get :

10.     ->  "10.00"
910.0   ->  "910.00"
10.003  ->  "10.00"
String(decimalValue, numDecimalPlaces);

String(10.0, 2) == "10.00";

nope.

DBG (String (10., 2));
DBG (String (910.0, 2));
DBG (String (10.003, 2));

10.0
910.0
10.0

That’s strange, this has always worked for me! :face_with_raised_eyebrow:

perhaps it has changed recently but in the tip the argument is ‘maxNumberOfDecimalPlaces’

/** Creates a string representing this floating-point number.
    @param doubleValue              the value to convert to a string
    @param maxNumberOfDecimalPlaces if this is > 0, it will format the number using no more
                                    decimal places than this amount, and will not use exponent
                                    notation. If 0 or less, it will use a default format, and
                                    exponent notation if necessary.
    @see getFloatValue, getIntValue
*/
String (double doubleValue, int maxNumberOfDecimalPlaces);

Oops, I was looking at master, not develop! You have the most recent version…

Here’s the commit where the change was made…

ah… ok! that’s why I noticed that only recently too!
Perhaps that’s something that should be added to the “breaking change” file?
it won’t “break” things, but it can have a strong impact on the UI (like on the sliders values…).
btw: sorry that I did not start a new thread. It was just supposed to be a side question at first, not a bug report :slight_smile:

I agree, it’s not going to cause any crashes (touches wood) but will likely cause some UI weirdness as you said. To be honest, I’d rather have the old functionality back too!

@t0m, could I propose something like:
(in String::NumberToStringConverters, juce_String.cpp line 499)

static char* doubleToString (char* buffer,
                             int numChars,
                             double n,
                             int numDecPlaces,
                             size_t& len,
                             bool ensureDecimalPlaces = false) noexcept
{
    if (numDecPlaces > 0 && numDecPlaces < 7 && n > -1.0e20 && n < 1.0e20)
    {
        auto* end = buffer + numChars;
        auto* t = end;
        auto v = (int64) (std::pow (10.0, numDecPlaces) * std::abs (n) + 0.5);
        *--t = (char) 0;
        
        if(!ensureDecimalPlaces)
        {
            // skip trailing zeros
            while (numDecPlaces > 1 && (v % 10) == 0)
            {
                v /= 10;
                --numDecPlaces;
            }
        }

        while (v > 0 || numDecPlaces >= 0)
        {
            if (numDecPlaces == 0)
                *--t = '.';

            *--t = (char) ('0' + (v % 10));

            v /= 10;
            --numDecPlaces;
        }

        if (n < 0)
            *--t = '-';

        len = (size_t) (end - t - 1);
        return t;
    }

    StackArrayStream strm (buffer);
    len = strm.writeDouble (n, numDecPlaces);
    jassert (len <= charsNeededForDouble);
    return buffer;
}

Where a bool is used to decide whether or not to stick to the exact number of decimal places are specified or if trailing zeros should be removed.

Wow, what a crazy change, and breaking …

Any normal person will thing that maxNumberOfDecimalPlaces = 0, means that “Number Of decimal Places” - well is … zero :ok_man:

Whats is even more mean, you cannot even search your whole codebase, because its the constructor which has changed its behaviour, so you have probably have a lot of wrong hits when you search for the String() constructor

1 Like

This is creating problems for me too, we have a lot of code that relies on the old String(double doubleValue, int numberOfDecimalPlaces) behavior. When upgrading to JUCE 5.4.1 a lot of our tests are now failing. It would be nice to re-instate the old behavior and to have a different API for the new approach.

1 Like

there is another dedicated thread about that : String breaking change

1 Like

Nice!
String display is now consistant, keeping the same number of decimal digits…