Re: multiple string tokens

[Jamison Hope]

On Aug 17, 2011, at 5:27 PM, Riccardo Mottola wrote:

> Hi,
> > Hey,
> >
> > I don't like using PRIdPTR because it took me a while to figure out  
> > why it works (I had to look up that it's a format string for  
> > intptr_t, and then check the NSInteger definition to verify that  
> > that is also intptr_t…), and PRIdPTR introduces a dependency on how  
> > NSInteger is defined everywhere you use it.
> >
> > Personally I always cast NSInteger/CGFloat to a c89 type when I  
> > need to print them, since it will work on any Foundation  
> > implementation. Anyway, we just have to make sure we never have  
> > (@"foo: %f", someCGFloat) or  (@"foo: %d", someNSInteger)!
> Putting an explicit cast sounds like a more readable idea too. It  
> took me a bit to know what PRIdPTR actually does (well, I grep'd the  
> headers and discovered that on sparc it is for example "lu" even if  
> it is a 32bit sparc...).
>
> David did already a lot of work which needs to be updated again :(
>
> Any other have comments about this?

I'm a lurker, not a contributor, so assign my opinion whatever weight  
you see fit, but:

I would side with David on this. The PRI* macros are the correct,  
portable C99 way to construct a printf format that'll do the Right  
Thing regardless of host integer/pointer sizes. As such, this and any  
other project with a desire to promote correct coding practices should  
lead by example and use them appropriately. There have been several  
code bases which I have been tasked with making 64-bit clean in which  
the majority of the requisite changes involved replacing hard-coded  
format directives with inttypes.h macros.

Also, as David mentioned, the Apple docs define NSInteger to be the  
same size as a pointer, so by definition it is equivalent to intptr_t  
and should be formatted the same way. There's no implicit dependency  
or abstraction barrier violation introduced here.

The more the macros are used in real-world code, the more readable  
they will become.

--
Jamison Hope
The PTR Group
www.theptrgroup.com