I was wondering if there was any good reason why gnustep-make doesn't
enable native exceptions by default if the compiler supports it.
I think the answer is that we can't readily install a default handler
for uncaught exceptions or support NSSetUncaughtExceptionHandler()
with the current stat
On Fri, Jun 27, 2008 at 8:35 AM, Richard Frith-Macdonald <[EMAIL PROTECTED]>
wrote:
> I was wondering if there was any good reason why gnustep-make doesn't enable
> native exceptions by default if the compiler supports it.
> I think the answer is that we can't readily install a default handler for
On 27 Jun 2008, at 16:35, Richard Frith-Macdonald wrote:
I was wondering if there was any good reason why gnustep-make
doesn't enable native exceptions by default if the compiler supports
it.
There are some overheads in enabling native exceptions.
I'm not too familiar with the issue, I on
On Fri, Jun 27, 2008 at 9:57 AM, Nicola Pero
<[EMAIL PROTECTED]> wrote:
> I'm not too familiar with the issue, I only know that when I added support
> for native exceptions to gnustep-make and tried to make it the default,
> someone
> else came out and turned it off again by default claiming that t
On 27 Jun 2008, at 17:57, Nicola Pero wrote:
On 27 Jun 2008, at 16:35, Richard Frith-Macdonald wrote:
I was wondering if there was any good reason why gnustep-make
doesn't enable native exceptions by default if the compiler
supports it.
There are some overheads in enabling native except
On Fri, Jun 27, 2008 at 10:14 AM, Richard Frith-Macdonald <[EMAIL PROTECTED]>
wrote:
> So this would appear to be a rather severe drawback as invocations are used
> quite extensively. Maybe the stack unwinding works if you used libffi for
> your invocations, but libffi doesn't work on some platfo
On 27 Jun 2008, at 18:23, Andrew Pinski wrote:
On Fri, Jun 27, 2008 at 10:14 AM, Richard Frith-Macdonald
<[EMAIL PROTECTED]> wrote:
So this would appear to be a rather severe drawback as invocations
are used
quite extensively. Maybe the stack unwinding works if you used
libffi for
your in
The only overhead is data size increases.
Yes - that's right - it was the data size increase that was considered
by some
(I think it was Alex Malmberg) too high. IIRC their point was
precisely that
when you turn on native exceptions, all of your object files are
bloated no
matter if yo
Hi,
On 27 Jun 2008, at 18:14, Richard Frith-Macdonald wrote:
That's really bad news when using distributed objects ... you might
make a call to another application, an exception is raised in that
application, passed back and re-raised in your application which
then aborts your app!
Isn
On 27 Jun 2008, at 18:47, Richard Frith-Macdonald wrote:
On 27 Jun 2008, at 18:23, Andrew Pinski wrote:
On Fri, Jun 27, 2008 at 10:14 AM, Richard Frith-Macdonald <[EMAIL PROTECTED]
> wrote:
So this would appear to be a rather severe drawback as invocations
are used
quite extensively. Mayb
Graham J Lee schrieb:
> On 27 Jun 2008, at 18:14, Richard Frith-Macdonald wrote:
>>
>> That's really bad news when using distributed objects ... you might
>> make a call to another application, an exception is raised in that
>> application, passed back and re-raised in your application which then
>
Native exceptions should have more overhead when they are used, and no
overhead when they are not used (which is why they are also called
'zero cost' exceptions). The other problem is that they break the ABI
- you can't mix setjmp/longjmp and native exceptions in the same
file. This is wh
12 matches
Mail list logo
