Re: Comparing @encode() output

[Richard Frith-Macdonald]

On 18 Jun 2009, at 01:53, Stefan Bidigaray wrote:

> Pretty straight forward quesiton, how do I compare the output of  
> @encode?  Instead of using "bits per sample" in the NSSound plug-in  
> implementation I decided to use encoding since int and float both  
> have the same number of bits.  The only way I figured this would  
> work would be to use @encode()... I went poking around in the Apple  
> docs and can see it outputs a (const char *), but I noticed in  
> NSPortCoder.m and NSArchiver.m compare using a switch(*type).  So is  
> the return value of @encode a string or int?  I guess another  
> question would also be if I should be using @encode to find the data  
> type?

@encode() returns a C-string
I can't remember for sure where the contents of the string are  
documented (probably the ObjC language book, snce @encode() is part of  
the language), but for most data types the string contains a single  
character identifying the type.

On the second question I don't see how you can use @encode() to find  
the type of something ... it's done at compile time, and if the  
compiler knows the type of a thing, then presumably you should too.   
What @encode() does for you is provide a string describing a type,  
which can then be passed to other parts of your program at runtime, to  
tell them what type you are using.   Personally, if I was passing that  
information around at runtime, I'd probably do it more explicitly in  
the API.
eg.
- processSamples: (void*)data bitsPerSample: (unsigned)bits  
numberOfSamples: (unsigned)samples floatingPoint: (BOOL)floatOrInt;

rather than

- processSamples: (void*)data type: (const char *)encodedType  
numberOfSamples: (unsigned)samples;

Apart from the greater clarity of putting the information explicitly  
in the API, the contents of the string produced by @encode() are  
processor dependent, so using it makes things trickier if you ever  
want to allow distributed objects to offload processing to another  
machine (I know thats unlikely, but it costs nothing to design with it  
in mind).