Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!oberon!nunki.usc.edu!jeenglis
From: jeenglis@nunki.usc.edu (Joe English)
Newsgroups: comp.lang.c++
Subject: Re: Some Questions from a C++ beginner
Message-ID: <2997@nunki.usc.edu>
Date: 10 Mar 89 06:33:13 GMT
References: <10508@ibmpcug.UUCP>
Reply-To: jeenglis@nunki.usc.edu (Joe English)
Organization: University of Southern California, Los Angeles, CA
Lines: 66


thawk1@ibmpcug.UUCP (Timothy Hawkins) writes:
[example using class 'database':]
>
>	database xx;             // un-named database with no structure
>
>	void	copy_dbf( char *name )
>	{
>
>		xx.create( database( "TEST" ) );
>
>		.......... other statements ..........
>
>	}
>
>	My first question is; is the scope of " database( "TEST" ) " ( a 
>	tempoary class created soley to obtain the structure of another
>	database) the scope of the whole function "copy_dbf" or is its scope
>	limited to the stage of constructing the stack frame for the 
>	" xx.create( ... ); " call.. 

database("TEST") creates a temporary object that is only guaranteed
to exist for the duration of the call to xx.create().  It will get
destroyed before the enclosing function (copy_dbf) exits; exactly *when*
this happens is not specified, though it typically (in Zortech at least)
will happen right after the function (xx.create) returns.

>Second Question... 
>
>	I am trying to implement a generic error handler class
>
[stuff deleted]
>
>	inline  virtual int error( void )
       [I think this is supposed to be error_handler::error(void) --J]
>	{
>		return( setjmp( error_point));	
>	}
>
[more stuff deleted]
>	Can anybody think of any good reason for not using this scheme 

I can:  This will break badly.  Since the function is virtual,
it will be called through a function pointer in the virtual
function table.  Which means that it won't get inlined.  Which
means that an actual function call is made, setjmp() does
its thing, then the *function returns*, rendering the error_point
jmpbuf totally invalid.

Even if you were to make it non-virtual, I still wouldn't do 
it.  Inline functions are supposed to have the exact same semantics
as real functions.   (I think of 'inline' the same way I think
of 'register,' as a hint to the compiler.  In some ways, this is
exactly the case because not all compilers will in fact inline all functions
that are supposed to be inlined --  Zortech for one.)

And thirdly, I wouldn't use setjmp() and longjmp() in a C++
program at all until the problems with exception handling get
worked out.  (What happens when you have a whole bunch of
local objects with non-trivial destructors that get skipped over
by the longjmp()?)  Unless your error handler is just going
to bail out and exit(), this is *not* a good idea.

--Joe English

  jeenglis@nunki.usc.edu