[Development] QOptional

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

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

21 авг. 2014 г., в 14:37, Robert Knight <robertknight at gmail.com> написал(а):

> I've written a basic Option<T> class with a minimal interface to
> address the problems with bool* OK args Julien mentioned and found it
> useful - both
> in terms of communicating that something may not have a value and also
> it avoids the need for an invalid/null/empty version of T to be
> defined.
> 
> *However*, there is a problem when introducing this into an existing
> codebase in that it takes time to determine best practices and
> appropriate usages
> of an idiom like this, to figure out what methods such a class really
> needs and what can be left out or written as a separate utility
> function.
> 
> The problem with trying to introduce such a class to a foundational
> library like Qt first is that you don't have this experience and it
> isn't obvious what
> API is most important or what idioms will turn out to be widely used.
> This is how std::future ended up with some pretty basic problems in
> C++11.
> 
> I would suggest that a better approach would be to find a real app
> that is suffering the pains of the existing API - maybe Qt Creator?,
> introduce the class there first of all
> and then promote it once it has proven effective.

Good remark:) Actually, we're using plain c++ here at work and we have a simple maybe type (just bool and T with operator* -> and bool; no == or < > operators or different access methods). And you know what? We're using it much more often than you can imagine. Settings class has maybe<T> value<T>(string key) const; method. A lot of functions return maybe just because they can occasionally fail - when dealing with containers it's quite easy to get out of bounds; however crashing is not an option sometimes.

Also, we have an Error class which is {bool ok; union {T value, std::string errosString; }; } - this is used when function want to notify what is the exact problem.

With support of c++11 autos maybe and error classes appeared quite simple and intuitive way to deal with errors. Unlike exceptions that can be caught at any point of the code or error codes that are hard to check - you see what method can fail and you're forced to check if returned value is valid