Den 21-08-2014 11:43, Иван Комиссаров skrev:
>
> Иван Комиссаров
>
> 21 авг. 2014 г., в 13:25, Simon Hausmann <simon.hausm...@digia.com>
> написал(а):
>
>> On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
>>
>> To be honest: I find the "bool ok" variant much easier to read.
>>
>> "if (value)" on an auto variable can mean so many things. In the
>> above example you could very easily think: Ah, toInt returns an int,
>> so the type of "value" is probably int, so if (value) checks if it's
>> non-zero.
>>
>> I don't think that makes for a very intuitive API. Yes, it's less to type,
>> but
>> less isn't always more :)
>
> Writing toInt() method itself becomes more easier too:
> QOptional<int> toInt()
> {
> ....
> if (error)
> return QNothing();
> return value;
> }
>
> Compare with
> int toInt(bool *ok = 0)
> {
> ....
> if (ok)
> *ok = !error;
> if (error)
> return 0;
>
> return value;
> }
>
> Also, using Optional/Maybe types can lead to a more functional-style code -
> you can store error state in a member variable or return using bool as shown
> above (which leads to extra code if (error) { ok = false; return T(); }) or
> you can use maybe-type. I used this approach for parsing network messages -
> without optionals i had to use a reentrant class that stored an error state,
> with optionals i removed the entire class and replaced it with a pack of
> thread-safe functions (taking QByteArray and returning Optional<QVariantList>
> where QVariantList is parsed data (yes, empty list is valid))
I have been monitoring this thread with a bit of scepticism.
And I'm sorry, but I don't see this as an improvement. It seems more
like clutter with classes instead of clutter in the syntax supported
version. The new object based version seems to me like overengineering
to solve a non-existing problem. And it's even slower than the current
version, not that I see this as an important argument, though.
I do support the argument to not implement a class that will come with
stl later. Yes, there might be a slight advantage to introduce it now,
in case there are cases in Qt where those classes could help solve real
problems instead of the above example. But if those conversion functions
is all you can come up with, I think it's a bad idea to get ahead of stl
here. So what if we have to wait for Qt 7 instead of Qt 6 to use
std::optional, if the gain is marginal anyway? *Please* don't add more
stl copied classes just because the stl committee is slow.
Please stay with the current implementation.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
