Danny Backx wrote: > I'd like to have two discussions. We're already having them both, that's > very good. I'd like to discuss design goals, and implementation. Both > are important. You'll find I might change the topic from one to the > other at times. > > Maybe I'm too vague, allow me to clarify. > > Design goals would e.g. state that you want all functions to potentially > have an exception handler - like what SEH says - or that you want > non-main threads to have an exception handler. > > The implementation discussion might be about whether you do this in > macros - your current suggestion - or in the compiler itself. The latter > idea is probably too hard anyway but I wanted to bring it up for the > sake of discussion. >
Certainly in the compiler would be best. But that would be a few months (hard) work. I'm not holding my breath to see someone doing it for us, so ... Macros would be the seconds best. It's the way people do it in gcc/x86 currently. Unfortunately, the table based SEH means the macros are much inconvenient that on x86, where SEH is stack based. > Back to our topic. I think you said that : > D1. __try and its friends are a construction which we'd like to support. > Basically this is part of SEH, isn't it? It is. It is syntactic sugar on top of SEH, that win32 compilers (minus gcc) support. > D2. Have a wrapper for function definitions so you can install an > exception handler on any function. > D3. Use that to implement a default exception handler for WinMain. > D4. A developer can choose to use that wrapper on the function that > implements other threads. > I1. Don't change the entry point in crt*.o. (I'm not sure I understand > why, maybe this is purely related to D3/D4.) Maybe I was to harsh on this part. I mean, I prefer a solution that doesn't force us into changing the entry point into asm. > I2. Use macros to implement the wrapper around function definitions. > >>> Haven't done that for C++ yet because Kevin's message prompted me to >>> reveal what I was playing with. I am in the process of figuring out >>> which C++ constructs this should use, and (depending on that) how the >>> hook from C++ into the mingw startup should work. >>> >> It shouldn't. It should not be on by default. C++ exceptions are >> one thing. SEH is another. Unless they are properly integrated at >> the compiler level, they should only be mapped by the user. Let's >> make it easy for the user to choose to use it instead. > > D5. You want to offer SEH as an option, the developer can choose not to > use it. Not sure I understand what you mean as an option... I think you are mixing SEH and c++ exceptions. I was saying that we shouldn't wrap SEH in c++ exceptions by default, and we shouldn't force a c++ hierarchy on the user. I mean, this can be done on contrib type lib, so why force it? In fact, this could modeled on _set_se_translator. http://msdn2.microsoft.com/en-us/library/5z4bw5h5(VS.80).aspx > D6. The developer may also want to use C++ exceptions, they should not > be mandatory (as my example and the accompanying text suggested). > gcc's c++ exceptions are perfectly usable without SEH in the mix. > >> Think of it as func() being the __try {} block, and handler() being >> the __except block. The user can use this to wrap seh into gcc's C++ >> exceptions. I certainly wouldn't want this in most of my c++ code. >> I hate when try {} catch (...) { } catches access violations. > > Why do you hate that ? > Because it swallows too much. I want my C++ catch blocks to catch C++ exceptions, as specified by the language. If I want to catch access violations I want to use __try/__except. Different problems, different solutions. As you've seen, it is the same in unix. You have c++ exceptions and signals (SEGV p.ex) - different beasts. > I hate it when applications on my PDA disappear without a trace. > "Something must have gone wrong" is all you've got. That's the reason I > started on all this. > I understand that. I also get bitten by this from time to time. I'm with you. This is different from the 'wrap in c++' discussion. > I'll add a couple more : > D7. We should have both a C and a C++ solution. > The CegccSetExceptionHandler in my example could be that. > D8. We should offer some examples and tools. > I3. The classes WindowsException, AccessViolation, .. from my example > could be one of these tools. > > As you know, I'm writing all this for the sake of discussion, not > because I feel strongly about something. I understand that. Cheers, Pedro Alves ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
