> Is your process 64-bit or 32-bit? CGFloat is float in 32-bit processes and
> double in 64-bit processes.
I'm not sure what you mean? The app is intended to work on both 32-bit
and 64-bit architectures. My iPad3 is a 32-bit device, and my iPhone-6
is a 64-bit device. On both of those devices
On Oct 18, 2016, at 00:04 , Patrick J. Collins
wrote:
>
>> Is your process 64-bit or 32-bit? CGFloat is float in 32-bit processes and
>> double in 64-bit processes.
>
> I'm not sure what you mean? The app is intended to work on both 32-bit
> and 64-bit architectures. My iPad3 is a 32-bit dev
> > CGFloat is a float, yet it returns 0??? WTF?
>
> It isn’t a float. What you’re seeing in the debugger *confirms* that CGFloat
> is 64 bits.
Hmm.. I guess I don't understand that then. My logic was because
casting as a double returns the expected value, and casting as a CGFloat
does n
> Hmm.. I guess I don't understand that then. My logic was because
> casting as a double returns the expected value, and casting as a CGFloat
> does not, that it couldn't be a double...
Err sorry, I mean casting as a float does not.
Patrick J. Collins
http://collinatorstudios.com
_
On Oct 18, 2016, at 01:56 , Patrick J. Collins
wrote:
>
> The scale code I discovered was breaking due to a protocol's interface
> being used on a class that defined a different type.
>
> So, it went like this:
>
> @protocol MenuInteractable
>
> -(void)setScale:(CGFloat)scale;
> // other stu
> Exactly so. The bug is that you declared ‘setScale’ in your protocol with
the wrong return type. It’s a weakness of Obj-C that its dynamism prevents
the compiler from statically checking return types in all cases, and float
vs. double is one of the particularly dangerous cases.
I get what you're
On Oct 18, 2016, at 1:56 AM, Patrick J. Collins
wrote:
>>> CGFloat is a float, yet it returns 0??? WTF?
>>
>> It isn’t a float. What you’re seeing in the debugger *confirms* that CGFloat
>> is 64 bits.
>
> Hmm.. I guess I don't understand that then. My logic was because
> casting as
On Oct 18, 2016, at 10:56 , Patrick Collins
wrote:
>
> I still am at a total loss as why that still resulted in the correct values
> getting passed around on 64-bit iPhone 6 and iPhone 6+ devices. Why would
> that behavior be different just on an iPad pro?
I don’t know the answer exactly, be
> On Oct 18, 2016, at 11:34 AM, Quincey Morris
> wrote:
>
> There is a compiler warning that can be turned on for this (one of the
> “mismatched selector” warnings), but in my experience there are too many
> false negatives *and* false positives, making the warning useless.
“Strict Selector
