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 ;)