Иван Комиссаров
21 авг. 2014 г., в 14:37, Robert Knight <[email protected]> написал(а):
> 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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
