Re: Variable arguments at runtime modification
Re: Variable arguments at runtime modification
- Subject: Re: Variable arguments at runtime modification
- From: Sailor Quasar <email@hidden>
- Date: Sun, 12 Oct 2003 14:12:58 -0400
On Sunday, October 12, 2003, at 01:41 PM, Bertrand Mansion wrote:
Thanks for this list of solutions and the info about va_ macros.
'tis my pleasure :).
I have also thought about subclassing NSData and overriding
-description. I
could create a new type of object for my framework and have the users
use it
instead of NSData when they will need to deal with binary data. The
problem
with categories and -poseAsClass is that some users might rely on the
original -description method somewhere else in their code so it might
give
them unexpected behavior.
This is almost always the exact problem with dealing with any
overriding of built-in methods, which is why OOP design principles say
that it should be done to augment rather than to replace functionality
except in specific cases.
Do you think a subclass is a viable solution ?
It will probably be faster than having to parse a given format myself.
Plus
writing the parser seems beyond my skills for now :)
It's a viable solution, and it will work, but it does depend on no
other part of your program relying upon the otuput of -description for
NSData. Certainly it will MUCH faster and FAR less error-prone than
writing your own parser (no reflection on your skills; printf-parsers
are astonishingly complicated and the standards can change between OS
versions).
Just one more question, do you know what the -description method from
NSData
actually outputs ? Could this output be actually reread and imported by
another NSData method, in which case I could maybe use it instead of
my own
encode/decode functions. Their goal is to convert a binary to a
readable and
writable string. I am writing a framework for working with sqlite
databases
and this db only accepts strings.
I just ran a quick test program to check the output. Given /etc/motd
which on my system contains "Welcome to Darwin", this code:
#import <Foundation/Foundation.h>
int main(int argc, char **argv)
{
NSLog(@"%@\n", [NSData dataWithContentsOfFile:@"/etc/motd"]);
return 0;
}
outputs this (minus the messages about me not creating an autorelease
pool :)
2003-10-12 13:58:11.103 test[12487] <57656c63 6f6d6520 746f2044
61727769 6e210a>
Stripped of the NSLog() packaging, that boils down to:
<57656c63 6f6d6520 746f2044 61727769 6e210a>
which is the raw ASCII data enclosed in angle brackets and with spaces
added. You can convert that to raw hex-string data with the following
sequence:
NSMutableString *rawdata = [[[myNSDataVar description] mutableCopy]
autorelease];
[rawdata deleteCharactersInRange:NSMakeRange(0, 1)];
[rawdata deleteCharactersInRange:NSMakeRange([string length] - 1, 1)];
// leave the spaces in so it can be converted back later
// rawdata = [[[[rawdata componentsSeparatedByString:@" "]
componentsJoinedByString:@""] mutableCopy] autorelease];
// I did all this copying and autoreleasing to follow Cocoa memory
management rules and to match the static typing, it's not really
completely necessary.
As for getting that back into NSData, the easiest way I can think of is
to reread the string one hex byte at a time and insert it back into an
NSMutableData, i.e.:
- (NSData *)rawdataStringToData:(NSString *)rawdata
{
NSScanner *scan;
NSMutableData *dat;
unsigned val, maxbytes, scanned = 0, cur = 0;
scan = [NSScanner scannerWithString:rawdata];
dat = [NSMutableData data];
maxbytes = [rawdata length] / 2;
while (![scan isAtEnd] && scanned < maxbytes)
{
if (![scan scanHexInt:&val])
break; // something went wrong
cur = (maxbytes - scanned);
[dat appendBytes:&val length:(cur >= 4 ? 4 : cur)];
scanned += (cur >= 4 ? 4 : cur);
}
return dat;
}
This should work (I typed it in Mail so no guarantees), but it will be
SLOW, especially if you're working with large amounts of data.
Thanks for the hints :)
You're welcome =).
-- Sailor Quasar, High Codemaster of the Web, scourge of systems
MacOS is to Windows as Terminus is to Trantor.
Email: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.