Re: When int meets bool over ==
On Mar 7, 11:39 pm, Gennaro Prota <clcppm-pos...@this.is.invalid>
wrote:
On Sat, 3 Mar 2007 08:56:40 CST, James Kanze wrote:
On Mar 2, 4:18 pm, Gennaro Prota <clcppm-pos...@this.is.invalid>
wrote:
[...]
In general I'm all for wrapping whenever the interface of the function
can (easily) be misused. Returning a "fake bool" is just one case of
this. From my code:
//! If no match is found (in particular when an empty string
//! is passed for \p name) returns an empty string.
Which is wrong. An empty string is not no string. In this
case, the original interface has that part right: you need to
distinguish. If you want to return a string (instead of char
const*), you'll need to use fallible, or pass something
elsewhere, since std::string doesn't support null values.
[...]
I'll confess that I've seen time( &t ) so often that I forgot you
could pass a null pointer and get the time_t as a true return value
:-) (Frankly, I've never understood why this double possibility exists
at all --one could even write time_t t; t = time( &t )!)
History. In the very earliest implementations, it wasn't
time_t, it was long, and passing a long or returning one was
either unsupported, or very inefficient. The return value and
the support for a null pointer as argument were added later (for
obvious reasons). Support for the pointer argument was
maintained for reasons of backward compatibility.
For the same reason, functions like localtime return a pointer,
rather than the struct.
(I wonder: would it be worth adding text in the C++ standard to
say that time() has a default argument of NULL?)
[...]
Sentinal values are tricky. But normally, you'd write the test
out in full, and be done with it:
time_t t = time( NULL ) ;
if ( t != (time_t)( -1 ) ) {
// OK, I have the time...
}
(The function time may be a bad choice as an example.
It was the first one that came to my mind :-) I'd still prefer a named
constant in lieu of "(time_t)( -1 )", on which we seem to agree
(judging from what you say below about INVALID_HANDLE_VALUE).
True. INVALID_TIME_VALUE would be nice.
None of the code I write has to be portable to a system where the
time isn't available, and I generally neglect testing the return
value completely.)
Well, I sleep better at night if I check it (then, the real point is
whether you can deal with the failure locally or not. But, throw or
not, checking the return value makes it explicit in the code that the
possibility of failure exists, however small its likelihood can be).
If I checked it, I'd probably just abort if I got a -1. If my
code needs the time, and can't get it, it can't work.
Of course, for a lot of uses (e.g. logging timestamps), it
really doesn't matter, and outputting -1 is as good as anything
else if you can't get the real time.
Incidentally, the standard gives no guarantee that a specific call
can't fail, even on a system which in general supports time.
Posix does:-). Maybe, at least: it says explicitly "The time()
function shall return the value of time in seconds since the
Epoch" (and specifies that this is an extention with regards to
the C standard); under Errors, it also says that "No errors are
defined.".
(One could imagine that a bad pointer would cause it to fail,
but at least under Solaris, it causes a core dump.)
--
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! ]