| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
> So there seems to be a choice between: > > 1 - DWARF - Fast but not robust with foreign frames. (any code generated > by other compiler, in a plugin / DLL / static lib from 3rd party). > > 2 - SJLJ - A bit slower but robust recovery in a mixed/plugin environment. "A bit slower". Try a whole hell of lot slower, as in: java is completely unusable in 4.3-sjlj. > For me, the choice is 2 since I work with extensible apps. Since there > are so many compilers for Windows and run-time binary linking (plugin/ > COM) is common, it seems SJLJ is a better match. For those people who RIGHT THIS MINUTE must have exceptions-across-foriegn-frames working -- and are willing to stick with C/C++/Fortran (NOT java, and NOT Ada -- because the AdaCore stuff on which gcc's Ada relies now only supports DW2, AFAIK), then perhaps current 4.3.x-sjlj technology is a better choice. For those who need foreign-frame support and are willing to continue to use 3.4.5 for another few months, while (1) the rest of us try to get DW2 stabilized for non-foreign-frame use, and (2) then start to solve the foreign-frame problem with DW2, I have a request of all the complainers: Either get out of the way, and let those of us who don't need foreign frame support get on with (1) faster, so we can get to (2) sooner -- or start contributing code to gcc to fix (2) now. Bellyaching and harassing Mr. LaFramboise is not helping ANYTHING. It's amazing the number of folks coming out of the woodwork NOW to complain about the way Aaron is doing things -- where were YOU five months ago when Danny stepped down? Or a year ago when he asked for help? Thank [whatever you hold holy] for Aaron's efforts... > If there is a try block inside a crucial tight inner loop, I'd just move > the try block out of there (I imagine one can shift the design slightly > in most cases). It's not just "tight loops". And using STL at all, imposes a lot of try/catch inside the implementation. I don't want to "slightly" redesign the STL, nor eliminate its use, all so you can stick with old -- poorly supported by upstream gcc -- sjlj. > If the choice is between: > > - Robust recovery in a mixed binary environment (with a cost for > every 'try' block) > > - Very optimized performance in a controlled homogeneous environment > (limited, special circumstances, particularly on Windows) All cygwin programs. Any computational program on windows. There's lots of stuff that is not GUI, and not networked. Or, perhaps IS gui/networked, but simply doesn't use the callback model. > then that choice is easy enough for me. And as upstream support for sjlj gets worse and worse, win32 becomes even more of a third-class citizen. Yippee. How about we begin the switch to DW2, but maintain a separate C/C++/Fortran-only 4.3.x-sjlj UNTIL the foreign-frame problem with DW2 is solved. then drop sjlj. -- Chuck ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ MinGW-users mailing list MinGW-users You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
© 2004-2008 readlist.com