[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #6286] NSBezierPath encode/decode improperly implemented
From: |
David Ayers |
Subject: |
Re: [patch #6286] NSBezierPath encode/decode improperly implemented |
Date: |
Thu, 06 Dec 2007 09:55:52 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20070113) |
Fred Kiefer schrieb:
> A few days ago I replied to a patch send in by Christopher Wojno:
>
> Fred Kiefer wrote:
>
>>Update of patch #6286 (project gnustep):
>>In your error message I can see that an NSKeyedArchiver gets used. As far as
>>I can see, your patch doesn't implement the missing keyed archiving for
>>NSBezierPath, so how does it help you?
>>
>>In my code NSBezierPathElement is always an enumeration, why would the
>>encoding stuff need the additional hint that it really is an enum? As far as I
>>can see there is no struct called NSBezierPathElement.
>>
>
>
> It turned out that it really makes a difference if we use
> @encode(NSBezierPathElement) or @encode(enum NSBezierPathElement). Could
> somebody explain this to me? Why isn't NSBezierPathElement resolved to
> an unsigned int?
Hello Fred,
an enum should be encoded as an int (as opposed to an unsigned int) on
most platforms (See NSComparisonResult for usage of negative values).
Yet there are platforms(/gcc options) for which small enums can be
stored in smaller signed base types.
But I do believe that:
typedef {
VAL1,
VAL2
} ENumType;
@encode(ENumType);
and
@encode(enum ENumType);
should always return the same string (on our platforms "i").
Cheers,
David