[Development] QOptional

[Иван Комиссаров]

You're forgetting that we're talking about private API for now, which means we also need to look at the toInt implementation:

QString::toInt() calls:
QString::toIntegral_helper() (which has "if (ok)" check) which calls:
QLocaleData::stringToLongLong (which again has "if (ok)" check); calls:
QLocaleData::numberToCLocale (return bool, fuuuh) OR QLocaleData::bytearrayToLongLong (has 4 (FOUR) "if (ok)" checks)

Conclusion - we have 6 identical checks which can be avoided using QOptional

So, i still think that simply returning QNothing() from these functions is a great improvement.

Иван Комиссаров

21 авг. 2014 г., в 15:01, Poenitz Andre <Andre.Poenitz at digia.com> написал(а):

Julien Blanc wrote:
> 
> Logically, in the presence of more than two alternatives, an argument 
> against the current solution is not necessarily an argument in favour
> of QOptional, let alone a 'strong' one.
> 
> The first "laziness" issue would e.g. also be addressed by the aforementioned
> bool QString::isInt(int *value) setup which provides an obvious way to 
> check success without giving the programmer the feeling to need to 
> jump through hoops before being able to check for errors. 
> 
> I am actually not quite sure what you mean with the second item.
> 
> Something like the following?
> 
> struct S { int m_a, int m_b, int m_c);
> 
> // "Tradtional, wrong result"
> bool S::parse(QString a, QString b, QString c)
> {
>    bool ok;
>    m_a = a.toInt(&ok);
>    m_b = b.toInt(&ok); // Oops, overwrites first ok value.
>    m_c = c.toInt(&ok);
>    return ok;
> }
> 
> vs 
> 
> // "Tradtional, right result"
> bool S::parse(QString a, QString b, QString c)
> {
>    bool oa, ob, oc;
>    m_a = a.toInt(&oa);
>    m_b = b.toInt(&ob); 
>    m_c = c.toInt(&oc);
>    return oa && ob && oc;
> }
> 
> vs
> 
> // "Optional"
> bool S::parse(QString a, QString b, QString c)
> {
>    auto oa = a.toInt();
>    auto ob = b.toInt();
>    auto oc = c.toInt();
>    m_a = *oa;
>    m_b = *ob;
>    m_c = *oc;
>    return oa && ob && oc;
> }
> 
> vs 
> 
> // "isInt"
> bool S::parse(QString a, QString b, QString c)
> {
>    bool oa = a.isInt(&m_a);
>    bool ob = b.isInt(&m_b);
>    bool oc = c.isInt(&m_c);
>    return oa && ob && oc;
> }
> 
> vs 
> 
> // "something else"
> bool S::parse(QString a, QString b, QString c)
> {
>    return a.isInt(&m_a) && b.isInt(&m_b) && c.isInt(&m_c);
> }
> 
> 
> If so, the "Optional" variant doesn't look much simpler than any 
> of the others, even less so when one doesn't accept the use of 
> 'auto' there.
> 
> 
>> Still, the issue about the semantic of “if(value)” when value == 0 /
>> false is still a concern (and one of the reason optional is not part of
>> the standard iirc)
> 
> ... and a show-stopper when it comes to using it with QString::toInt
> (with exactly that 'toInt' function name)
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140821/4cfe9d53/attachment.html>