On Dec 27, 2012, at 5:46 PM, Brad Roberts <[email protected]> wrote:
> On Thu, 27 Dec 2012, Walter Bright wrote: > >> On 12/27/2012 1:52 AM, deadalnix wrote: >>> On Thursday, 27 December 2012 at 09:29:08 UTC, Walter Bright wrote: >>>> D does use Windows SEH for win32, but not for win64. But still, you gotta >>>> ask >>>> yourself, what do expect Windows to do with a D exception? >>> >>> I think it has several advantages to use the same ABI : >>> - Exception cal bubble from D to C++ then back to D to be handled. C++ >>> will >>> run RAII code properly, even if it can't do anything useful with the D >>> exception. This is common when using function pointer or virtual methods. >>> - The same thing goes the other way around : C++ Exception can go throw D >>> code, unwinding stack cleanly. Even if D program cannot do anything really >>> ith >>> the C++ exception, it can at least fail safely and with a stack trace. >>> >>> In many cases, exception are more about exit cleanly than actually catch >>> them >>> and recover. For such a case, common ABI is useful. >> >> There is some merit to your argument, and that was the original idea behind >> building D exceptions out of Win32 SEH. I did the same for the Digital Mars >> C++ compiler. >> >> But in practice, and I include a decade with DMC++, I've just never seen a >> useful application of it. > > It doesn't matter if you can see the utility in it or not. What matters > is some combination of user expectations and general usability, both of > which are fairly subjective. Additionally, for most of that decade, > mixing languages was fairly rare. These days it's becoming increasingly > common. Presenting c++ libraries with c wrappers is much more common now. > Using call backs and registration hooks for plugins and other > extensibility mechanisms is WAY more common now than it was 10 years ago. > In short, the landscape has and continues to change, so past history is a > poor measuring stick for future code bases. > > IMHO, having the unwinders NOT be common and uniform in behavior is a > major usage problem. It might not be important enough to hit the top of > the todo list right now, but at some point it's going to be. Either way, > not being interoperable is a bug in my mind (and I include all the > platform here, not just windows) and will need to be addressed. It's > roughly in the same category as supporting shared libraries. They're not > important at small scale, but at large scale they start to become > critical. If I can't rely on proper unwinding, there's going to be > problems. > > I'm not familiar with the windows side, but on the posix side, the c++ > world developed a fairly sane, multi-language, unwinding system. There's > little reason NOT to use it, other than that it takes a little time to > understand and hook into it, and going off on your own path is potentially > simpler. This. Is there some reason we really need a different unwinding mechanism?
