seh_try_macros2-00
Gregory M. Turner
gmturner007 at ameritech.net
Sat May 17 16:17:58 CDT 2003
On Friday 16 May 2003 08:15 am, Dimitrie O. Paun wrote:
> On May 16, 2003 02:21 am, Gregory M. Turner wrote:
> > unfortunately, this doesn't help with MIDL-generated code, which is my
> > primary motivation here...
>
> I know, but I was hoping to use your hard earned knowladge to solve
> this big hole that we have in Winelib... :) Any chance you can look
> at it from the C++ angle? BTW, can't we compile the MIDL-generated
> code with a C++ compiler?
This is a possibility. Another, which I never thought of until now, would be
to define macros to support RpcTryExcept syntax, which have the useful
advantage of a trailing __ENDTRY-type syntax.
Also, I have learned that gcc 3.3 has a new preprocessing feature: directives
may be embedded in macros; I think this means we could do stuff like #define
return something_else, within our macros. This could maybe fix break,
return, even goto... obviously it would be a while before it was widely
available. Just brainstorming here...
Dimi, here's an evident C++ angle, how does this strike you? We use g++ to
generate the exceptions, and then unwind them through our C code, using
-fexceptions. Probably easy, if inefficient, compared to the mess I've been
proposing:
In wine's first C++ file, we implement the following C api:
extern seh_te_outcome try_except_beastie( tryblk_fn_ptr, filter_fn_ptr,
except_fn_ptr )
extern seh_tf_outcome try_finally_beastie( tryblk_fn_ptr,finally_fn_ptr ).
The former uses catch(...) to handle exceptions; the latter uses a destructor
to achieve unwind goodness. Each calls through the function pointers it is
provided by C macros, which still use gcc-specific nested functions as
before.
We still have the lexical constraints of C to deal with, in C code, so we
still lose break and continue, I guess, at least until gcc 3.3. But these
generate nice compile failures that will get fixed at design-time.
Meanwhile, goto out of a tryblock should work, if I understand how gcc would
implement this.
Pros:
Actually sort of works, and actually somewhat portable.
Presumably allows C++ winelib apps to work better; makes
wine play nicer with C++ eh and other -fexceptions libs.
Might be a good "excuse" to start allowing portions of wine which
are C++-specific.
Cons:
Wine binaries are much bloated, and maybe less optimised. -fexceptions is
known to cause huge size increases, I'm afraid.
If we call through libs compiled without -fexceptions, bad things will
happen.
Depending on how much we want to rely on this, we now need g++ for a working
wine. Perhaps, this is inevitable and we shouldn't worry about it.
Presumably, there are some known caveats to mixing C++ and wine?
Might be a good "excuse" to start allowing portions of wine which
are C++-specific.
Not sure this is workable with "return"... ?
Any of the above ideas strike anyone's fancy?
I guess the first question to ask, before all of the above is: which is a
worse sacrifice for wine? Requiring compiler support for this, or an extra
parsing phase? Or just having a broken dummy implementation like we do now?
OK, sorry to harp on this subject, I will shut up now, as I am sure you are
all sick of this ;)
--
"A just security to property is not afforded by that government,
under which unequal taxes oppress one species of property and
reward another species." --James Madison
gmt
More information about the wine-devel
mailing list