On Wednesday 12 February 2003 01:44 pm, Alexandre Julliard wrote:
"Gregory M. Turner" gmturner007@ameritech.net writes:
Let me know what you think of these. So far, I like them better than the original versions, although in solving some limitations of the old macros, I've created some new ones.
Of course the main limitation is that this requires gcc, which means the macros can't be used in Wine itself. They might be useful for Winelib apps though.
actually, since I got rid of "({ })" in this revision, I'm not sure it's gcc-specfic at all... or did I miss something?
Otherwise, these are better macros. They are slightly more easily understood (although still pretty darn confusing, especially in the debugger), probably more resiliant against compiler optimizations, and have much less awful performance. Best of all, they ought to properly re-raise exceptions after executing finally clauses.
You cannot re-raise exceptions after finally, the finally block has to run at unwind time, not from the exception filter. You should probably use the existing __FINALLY macro for that.
This, OTOH, sounds like a more significant issue... I'll look into it.
Sooo.... Anyone want to help me decide what's the best way to get a thread-local global variable instantiated? Probably, my previous attempt with TlsAlloc was semantically correct, but that was /way/ too fat a solution, I'd like something much quicker if its at all possible.
IMO you shouldn't use a variable at all, you should do everything on the stack. Otherwise it won't work when an exception happens in the middle of the exception code.
Yup. I'd prefer this myself... but unfortunately, I haven't found a way to achieve it. The problem is that the finally clause provided by the user needs to be outside any lexical scope I can create (this is simply because I have no way to put some close-brackets after the finally clause like __ENDTRY). So, if I'm going to use the approach of turning the user's finally clause into a function, there's no way to get at it without inheriting it from the "global" (relative to the place the macros are invoked) lexical scope... which I can't do before I begin the scope because I don't know what __LINE__ will be when the user creates their finally clause during the __try.... Sorry, that's pretty unclear, but suffice it to say that there are some nasty issues at play :)
However, there is probably some creative solution that just hasn't come to me yet. In fact I have a couple of ideas already. I'll go back to the drawing board with these one more time and try to get this issue sorted out ... expect at least one more post to wine-devel before I submit a patch on this.
Thanks for looking these over,