Re: [boost] expected/result/etc
On 12 Feb 2016 11:20 a.m., "Niall Douglas"
LLVM, for the record, has implemented a very similar "universal" exception handling mechanism which allows exception throws to traverse language boundaries within LLVM, and my great hope is that once LLVM becomes universal on POSIX platforms someone will go ahead and replace signals with structured exception handling.
As far as I know LLVM simply implements unwinding as mandates by the Itanium ABI, which is already the de facto standard on many unices. Is this what you are referring to? This is completely orthogonal with handling OS/machine exceptions (segfaults, division by zero, etc..). And with right compiler and flag there are ways to convert (synchronous) signals to exceptions. This actually required to support the semantics of languages other than the C family, like Java and Ada. Notably, it doesn't actually work with LLVM, but it does with gcc. -- gpd
On 13 Feb 2016 at 10:26, Giovanni Piero Deretta wrote:
LLVM, for the record, has implemented a very similar "universal" exception handling mechanism which allows exception throws to traverse language boundaries within LLVM, and my great hope is that once LLVM becomes universal on POSIX platforms someone will go ahead and replace signals with structured exception handling.
As far as I know LLVM simply implements unwinding as mandates by the Itanium ABI, which is already the de facto standard on many unices. Is this what you are referring to?
LLVM provides a general purpose compile time and a second runtime library which allows (live) manipulation of exceptional behaviour. You can add stuff to be called on stack unwind according to a simple programmable logic, and intercept unwinds to perform simple logic to decide what to do next. In other words, exactly what win32 structured exception handling does. clang extends that infrastructure with the extra goodies needed to implement C++ exception semantics, and mostly focuses on the compile time graph building for obvious reasons. Exactly the same way MSVC in the past extended win32 structured exception handling to implement C++ exception semantics (to my knowledge, recent MSVCs no longer do this by default mainly because win32 structured exception handling is quite slow and extremely non-optimisable due to being runtime modifiable). The last time I looked at that internal library was 2013 or so, but I do remember being surprised at a number of substantial differences in the implementation compared to win32's. The deviations were sufficient that reusing that infrastructure to implement win32 structured exception handling support would be very tricky, and I suspect much of the work making winclang since has been refactoring this very core library. But I haven't looked since 2013, anything could have happened since. And memory can be faulty, so any of the above may be lies. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (2)
-
Giovanni Piero Deretta -
Niall Douglas