seh_try_macros2-00
Gregory M. Turner
gmturner007 at ameritech.net
Fri May 16 01:21:42 CDT 2003
On Friday 16 May 2003 12:05 am, Dimitrie O. Paun wrote:
> On May 16, 2003 12:00 am, Gregory M. Turner wrote:
> > nope. 'cause it's illegal to have a break/continue hanging around
> > without something to break/continue out of. But we could have to have
> > "__TYPED_TRY" "__ACHEY_BREAKEY_TYPED_TRY" macros :(
>
> Greg,
>
> I think we're barking up the wrong tree. Vast majority of Windows apps
> nowadays are C++. Of the few that are C-only, most will compile with a
> C++ compiler. In other words, if we find a C++ solution for the SEH
> problem, we would have covered probably more than 95% of apps. Not
> perfect, but good enough.
>
> If I understand you guys correctly, the problem should be solvable in
> C++. Let's go for the low hanging fruit first, it makes good sense.
unfortunately, this doesn't help with MIDL-generated code, which is my primary
motivation here...
My concern, aside from that it won't work without all these gcc-isms, is that
by creating a similar syntax to __try and friends, which only implement some
of the real semantics of these constructs, we create a "false" sense of
security. Code utilizing these might compile, and then yield some horrible
and confusing result (of course, that's kind of what we have now, anyhow,
with dummy Rpc EH macros)...
goto is a good problem to mention, because unlike break/continue, if they did
a goto out of a try-block, it would compile, but fail to pop the exception
record or run finally... not sure if there is some way to prevent that.
--
"There is no dignity quite so impressive, and no independence quite
so important, as living within your means." --Calvin Coolidge
gmt
More information about the wine-devel
mailing list