[Development] New feature to qstring | QString::toBool()

[Frans Klaver]

On Wed, Oct 26, 2011 at 8:10 AM, Thiago Macieira <thiago at kde.org> wrote:

> I agree with your argument, I just don't think it's applicable. QString is not
> localised and has never promised to be. QString::number generates C-locale
> numbers and toInt/toDouble parse C-locale; QDate::toString generates C-locale
> dates (or should), etc. If you want localised information, you should use
> QLocale.

Given that information and assuming that the results match QVariant,
I don't see any reason not to include QString::toBool(). The
assumption will obviously always be valid if QVariant uses
QString::toBool() for parsing.


>> If QString::toBool() is added, would there also be a need for something
>> like static QString::boolean(bool value, char format = 't')?
>
> It's much easier to use the ternary operator and just select which option you
> want to use.

Consider:

bool b = true;

QString str1 = b?"treu":"false";
if (str1.toBool()) {
    // we never get here...
}

QString str2 = QString::boolean(b);
if (str2.toBool()) {
    // we will get here
}

This example might be a bit far-fetched and I do agree that the
advantage, if any, would be fairly small. QString::boolean() would
always produce a value that is guaranteed to be correctly parsed by
QString::toBool(). The ternery operator not so much. Also the user
doesn't have to explicitly know about which values evaluate to true in
QString::toBool() to enter the correct value; from an API perspective
I think it would make sense to enable a black-box round-trip.

Cheers,
Frans