Re: Best Practices For Thread-Safe errno
On Oct 7, 7:10 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
Like others, I am follwing the general model of letting functions
return true/false to indicate success/failure, then setting an error
to indicate exactly what happened in the case of failure.
I would like to know if there is an portable or semi-portable
equivalent of Microsoft's SetLastError():
You are not explicit as to what the point
this is, so I'm going to infer from the Subject
line that you want a thread-safe thing
like Unix "errno" -- a global varible which
functions as a hidden argument to many
(but not all) functions in certain libraries
for carrying an error code.
It's certainly possible to make "errno" thread-safe.
Solaris has some magic to make "errno" thread-specific.
"Portable" is problematic because threading isn't
"portable" -- it depends upon the thread library.
But the real question is: why would you do it
this way when the alternatives -- exceptions
and return codes -- are 100% portabale, thread-safe,
and much more straightforward?
My impression is that general wisdom has moved
on since the early days of Unix, which is when
"errno" became irretrievably fixed in the Unix
API, and that way of handling error codes is
now considered a bad idea. I notice that POSIX
threads don't have an "errno," even though
they could do it in a thread-safe, portable way.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]