Re: Necessity of multi-level error propogation
* Jeff Schwab:
Alf P. Steinbach wrote:
* Jeff Schwab:
James Kanze wrote:
On Mar 11, 7:54 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
The only know alternative to exceptions is return codes
For a very liberal meaning of "return code". You can use out
parameters, global variables (ever heard of errno?)
errno isn't a global variable
errno is a global variable.
That was true in POSIX.1, but would be completely unworkable in a
multithreaded environment.
I'm sorry but that's a meaningless statement/assertion; it's contrary to readily
available fact.
, it's a macro.
And yes, errno is required to be a macro.
In the first case 'errno' refers to a concept and/or bottom level
implementation of that concept.
'errno' refers to a macro, period.
Yes, 'errno' is a macro: nobody's contested that, so you're trying to (huff,
puff) blow down a wide open door here.
The "bottom level concept" typically
isn't a global variable,
Of necessity it must be a global variable, because that's what it is. :)
either, but some thread-local storage.
A global variable can be in tread-local storage, yes. Any variable in
tread-local storage is global, for any reasonable meaning of global in this
context. I noted else-thread, however, that today it seems you have severe
difficulties understanding that a word generally is meant to stand for its
contextually most sensible meaning instead of some least sensible meaning, which
is an issue that IMHO you really should look into (it starting to annoy).
In the second case 'errno' refers to a very limited tech detail view
that few if any find useful to know about, but the purpose of which is
to provide the first case's concept in a way such that people don't
have to worry about the details.
The purpose of errno, as is often the case with macros, is to support
modern usage patterns, while conforming to ancient syntax.
Yes.
On the system I'm using to post this message, it maps to a function
call.
Really?
extern int * __error(void);
#define errno (*__error())
The name 'errno' has to behave as a direct reference to a variable, so
in C it can at most map to an expression that dereferences the pointer
result of a function call (but it can there not map to a direct
function call).
Right: it maps to a function call *and a dereference*.
That's markedly different from mapping to a function call.
This is a
markedly different case from your mistaken claim that errno must somehow
map to a global variable.
I'm sorry but I'm unable to see any single misconception that could make you
utter such a completely meaningless statement, so I'm assuming it's purely
argumentative: noise inserted with the intention of misleading some hypothetical
other reader than us two. Well that's just stupid. Get on the level, please, and
that means: stop micro-nit-picking and stop choosing inane meanings of words.
In C++ it can conceivably map directly to a function call, but it
would be rather silly to implement it differently in C++ and C.
C++ compilers are not required to support C at all, so implementing the
two "differently" does not necessary come into play. Of course, it does
in every real-world implementation I've ever used.
Yes, it does matter in real world, and real world was what I referred to, while
in your reply now you chose to add reference to some purely academic POV.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!