Am Mon, 22 Jul 2013 19:28:10 +0200 schrieb Marco Leise <marco.le...@gmx.de>:
> Am Fri, 19 Jul 2013 21:43:38 +0200 > schrieb Johannes Pfau <nos...@example.com>: > > > Am Fri, 19 Jul 2013 12:38:45 +0200 > > schrieb Marco Leise <marco.le...@gmx.de>: > > > > Would be nice to know if this is working with gdc or ldc. In theory > > it should work as we use gcc's exception handling/stack unwinding > > so it's probably a dmd bug. > > That's good to know. Is it possible to port that code into > DMD ? Probably not. It's implemented in libgcc and I don't know if it's tied to the compiler code gen. Porting is probably not possible because of the license. GCC's exception handling also has its own problems: For example we don't implement exception chaining right now. I just had another look at this and my last statement was not 100% accurate. GCC uses unwind tables instead of frame pointers so it can indeed work without frame pointers. But for C unwind tables are not generated by default unless -fexceptions is used. Interestingly enough it always worked for me ;-) > How many C libraries do you think are prepared for > exceptions ? They might have to clean up memory or system > resources. Probably very few. I was only talking from the compiler/codegen point of view but any C library that doesn't explicitly allow throwing exceptions probably won't work. > > > If with @nothrow you mean the nothrow keyword, it has no value > for compiler backends, because assert errors can be thrown > anyways. But I probably misunderstood you. Yeah well that's the general perception in the D community. But we need an authoritative statement here. According to TDPL, chapter 9.4 page 307: "Essentially Throwable is considered unrecoverable, so the compiler is relieved of the responsibility of "thinking" of what should happen in case of an exception and consequently _optimizes code under the assumption that nothing is thrown_." That's probably why Iain implemented it so that we directly map nothrow to gcc attribute(__nothrow__). However, I think this statement is supposed to talk about skipping destructors not necessarily unwinding. I don't really have a strong opinion here but according to Walter the backend can optimize quite a lot if it knows for sure that a function can't throw. As asserts can be optimized away anyway it might be useful to rewrite throw(Error) statements in nothrow functions to simply dump a stack trace and message to the console instead of proper exception handling. But as I said I don't have a string opinion here.
