[Development] New feature to qstring | QString::toBool()
thiago at kde.org
Wed Oct 26 08:10:02 CEST 2011
On Tuesday, 25 de October de 2011 23.33.04, Frans Klaver wrote:
> > 1) document very well what is true and what isn't
> Restricting the use to e.g. English only, would not be really useful when
> parsing (localized) user input, although I don't think this would happen a
> lot. I only know of a few cases where an end-user is expected to
> explicitly type yes or no into an input field, and those are command line
> tools. Wouldn't that be pretty much the only use case?
> I might have overlooked things. It's getting late anyway.
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
> > 2) make sure all three classes work the same way. If not, change them so
> > that they all have toBool() const and they all operate equally.
> > 3) add unit tests
> > 4) ensure that QVariant::toBool calls into QString::toBool and
> > QByteArray::toBool, as applicable. Note pending the commits by Jędrzej
> > that are refactoring the QVariant internals.
> 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.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development