Re: Returning const ref
On Mar 9, 2:51 pm, Lourens Veen <lour...@rainbowdesert.net> wrote:
Seungbeom Kim wrote:
James Kanze wrote:
On Mar 7, 2:41 pm, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
2. Return a boost::optional.
Rather a misnomer in this case, isn't it. The "standard" idiom
is fallible (which is very close to boost:optional in
implementation---except that it fails if you access the element
and it isn't there, rather than throwing an exception).
It may be due to my limited experience, but I haven't seen much of
the word "fallible" used in this context. "Fallible" in English
means "not perfect" or "can make mistakes", which doesn't describe a
function that always correctly reports the result of a lookup. :)
Well, you could argue that it depends on whether the goal of the
function is to search or to find. I would think that "find" can only
succeed if the wanted item is there, while "search" always succeeds,
but doesn't return a result if the wanted item does not exist.
Thus, "find" should return fallible, while "search" should return
optional.
In my mind, optional implies a choice, which isn't present in
either search or find. And it's a strong implication. I
associate "fallible" with "fail", perhaps because of
emtymological or phonetic reasons, and it makes sense to me to
speak of a search failing, just as much as it does to speak of
find failing.
On the other hand, I've also used it (because it worked) for
managing a cached value, with isValid() representing cache
validity. In which case, speaking of either a conscious choice
or failure is a misnomer.
In practice, we're dealing with a very specific technical issue,
so any general English word is bound to be off a bit. My
personal feeling is that the notion of choice in optional is
very strong, which makes it too far off to be appropriate, but
it's quite possible that others don't feel this as strongly.
If you expect a function to succeed or throw, then fallible
should throw if there is no result,
My fallible expects the user to check the validity, and
attempting to use an invalid value is a fatal error. Of
course, it, like the concept itself, was developed long before
compilers supported exceptions. But I still feel that that is
the better soluton. If an exception is the prefered mechanism
for reporting the failure, then the function itself should
throw, and there's no need for the class to begin with.
Of course, as a result of intensive use for over 10 years, some
improvements have been made.
and optional should not, which if
I understand correctly is the opposite of what's happening now. This
would lead to programmes that use "find" wherever the wanted item is
expected to exist unless there's something seriously wrong,
and "search" when the wanted item may not exist under perfectly
normal circumstances. That strikes me as elegant.
Maybe a little bit too elegant, or at least too subtle.
Of course, whether you call your search function find or search is
more or less arbitrary. The STL uses find for linear search of a
single item and search for linear search of a sequence of items.
Whatever else one may think of the STL, I don't think anyone
would argue that it is a good example for naming conventions:-).
(Note that std::string uses the word find in all of its member
lookup functions. I believe this part of std::string pre-dates
STL; at any rate, the naming conventions are a lot better.)
And
then there's lower_bound, upper_bound and binary_search for binary
search.
Interestingly enough, I've never heard the algorithm refered to
as anything but binary search. You use a binary search
algorithm to find something?
In all cases it returns the end marker if the result is not
found. Whether to interpret that as success/not-found or as failure
is left to the caller. Which ultimately gives the same results as I
sketched above in a somewhat more low-level way.
It's an arbitrary convention, which begs the question. If I'm
returning a pointer, I generally don't use Fallible, but return
a null pointer in case of error. (The only reason I might use
Fallible is because my version of Fallible has been extended to
support error codes.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]