Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cwjcc!gatech!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: goodbye cpp ??? (macros vs. inline functions)
Message-ID: <11001@ulysses.homer.nj.att.com>
Date: 14 Dec 88 16:19:43 GMT
References: <6590072@hplsla.HP.COM> <1757@dataio.Data-IO.COM> <3637@pt.cs.cmu.edu> <1304@cod.NOSC.MIL> <3663@pt.cs.cmu.edu> <1309@cod.NOSC.MIL> <33500@bbn.COM>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector.UUCP (Jerry Schwarz)
Organization: AT&T Bell Laboratories
Lines: 30

In article <33500@bbn.COM> lpringle@labs-n.bbn.com (Lewis G. Pringle) writes:
>
>
>It is not quite true that Inlines preserve the semantics of function calls.
>At least - in cfront 1.2.  Here is an example.
>
>inline Catch()
>{
>	return (setjmp (failureHandlers[which++]));   // sb !setjmp???
>}

This code has undefined semantics.  Once you return from Catch. the
effect of jumping to the saved buffer is undefined.  It may happen to
have the desired effect in one compilation system becasue the inline
causes "macro-like" expansion, but this does not mean that it will
have the desired effect in all C++ compilation systems.

"Preserving semantics" means that the code generated by inlined
functions must conform to C++ semantics for function calls.   It does
not mean that it must have the identical effect to what would be
generated in the absense of inline. For example, the order of
evaluation of function arguments is not specificed in C++.
Declaring a function inline might cause that order to be different.

Also note, that setjmp/longjmp must be used very carefully (if at
all) in C++ programs because destructors are not called when longjmp
unwinds the stack.


Jerry Schwarz
AT&T Bell Labs, Murray Hill