On Tue, Feb 10, 2009 at 7:29 AM, Sean McBride wrote:
> On 2/9/09 6:48 PM, Clark Cox said:
>
>>> So, I belive #if defined(x) && (x) is good defensive programming.
>>
>>Nope, it's still redundant. And I am 100% sure of that.
>
> So is gcc's -Wundef a leftover from a pre-C89 era? Or is it to help
>
On Tue, Feb 10, 2009 at 10:29 AM, Sean McBride wrote:
> On 2/9/09 6:48 PM, Clark Cox said:
>
>>> So, I belive #if defined(x) && (x) is good defensive programming.
>>
>>Nope, it's still redundant. And I am 100% sure of that.
>
> So is gcc's -Wundef a leftover from a pre-C89 era? Or is it to help
>
On 2/9/09 6:48 PM, Clark Cox said:
>> So, I belive #if defined(x) && (x) is good defensive programming.
>
>Nope, it's still redundant. And I am 100% sure of that.
So is gcc's -Wundef a leftover from a pre-C89 era? Or is it to help
keep your code compatible with non-compliant compilers? Or is it
On Mon, Feb 9, 2009 at 8:55 PM, Nick Zitzmann wrote:
>
> On Feb 9, 2009, at 6:30 PM, Michael Ash wrote:
>
>> Not really sure what you mean by this. It's true that a constant such
>> as 11.2f is a less precise representation of 11.2 than the non-float
>> version. But aside from actually defining th
On Mon, Feb 9, 2009 at 3:17 PM, Steve Sisak wrote:
> At 12:52 PM -0800 2/9/09, Clark Cox wrote:
>>
>> On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride
>> wrote:
>> > On 2/9/09 11:24 AM, Clark Cox said:
>> >>That is, the preprocessor treats any undefined identifier in an '#if'
or '#elif"
On Feb 9, 2009, at 6:30 PM, Michael Ash wrote:
Not really sure what you mean by this. It's true that a constant such
as 11.2f is a less precise representation of 11.2 than the non-float
version. But aside from actually defining the constants (and note that
all exact integers under 2^23 and many
On Mon, Feb 9, 2009 at 2:02 PM, Nick Zitzmann wrote:
>
> On Feb 9, 2009, at 11:04 AM, Sean McBride wrote:
>
>> I agree with the OP that CGFloat is very annoying in this respect. My
>> solution has been to use the 'f' suffix for constants.
>
> The problem with that is, if you do a mathematical ope
On Mon, Feb 9, 2009 at 2:11 PM, Steve Sisak wrote:
> At 12:41 PM -0500 2/9/09, Michael Ash wrote:
>>
>> > A very bad idea as it would force usage of float in 64bits applications
>>>
>>> where NSSize expect 64 bits CGFloat.
>>
>> So? Float converts to double just fine. There are no bad consequenc
> You are definitely describing the behavior of the C++ preprocessor.
That behavior is also described at least as far back as Harbison & Steele
5th edtion 2002, and K&R 2nd edition 1988[*]. But I know for a fact that I
have used C compilers where #if with an undefined name was a compilation
error.
At 12:52 PM -0800 2/9/09, Clark Cox wrote:
On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride wrote:
> On 2/9/09 11:24 AM, Clark Cox said:
>>That is, the preprocessor treats any undefined identifier in an '#if'
or '#elif" as if it were defined to be zero.
> I'm not a language lawyer, but I bel
On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride wrote:
> On 2/9/09 11:24 AM, Clark Cox said:
>
>>> Apple's headers inconsistently use #if and #ifdef.
>>
>>Because #if and #ifdef will both give the proper result in this
>>instance (i.e. the GCC compiler either defines __LP64__ to true, or it
>>doesn'
On 2/9/09 11:24 AM, Clark Cox said:
>> Apple's headers inconsistently use #if and #ifdef.
>
>Because #if and #ifdef will both give the proper result in this
>instance (i.e. the GCC compiler either defines __LP64__ to true, or it
>doesn't define it at all), they are interchangeable.
>
>> I recommen
On Mon, Feb 9, 2009 at 11:11 AM, Steve Sisak wrote:
> At 12:41 PM -0500 2/9/09, Michael Ash wrote:
>>
>> > A very bad idea as it would force usage of float in 64bits applications
>>>
>>> where NSSize expect 64 bits CGFloat.
>>
>> So? Float converts to double just fine. There are no bad consequen
On Mon, Feb 9, 2009 at 10:04 AM, Sean McBride wrote:
> On 2/8/09 11:14 PM, Clark Cox said:
>
>>> A somehow related question:
>>> How does one find out, in which mode (32 vs. 64 bit) an app is running?
>>
>>#ifdef __LP64__
>
> Apple's headers inconsistently use #if and #ifdef.
Because #if and #ifd
At 12:41 PM -0500 2/9/09, Michael Ash wrote:
> A very bad idea as it would force usage of float in 64bits applications
where NSSize expect 64 bits CGFloat.
So? Float converts to double just fine. There are no bad consequences
for passing 11.2f to a function that takes double, aside from an
u
On 2/9/09 12:02 PM, Nick Zitzmann said:
>> I agree with the OP that CGFloat is very annoying in this respect. My
>> solution has been to use the 'f' suffix for constants.
>
>The problem with that is, if you do a mathematical operation on a
>double using a float (including constants), you will los
On Feb 9, 2009, at 11:04 AM, Sean McBride wrote:
I agree with the OP that CGFloat is very annoying in this respect. My
solution has been to use the 'f' suffix for constants.
The problem with that is, if you do a mathematical operation on a
double using a float (including constants), you wi
Le 9 févr. 09 à 19:04, Sean McBride a écrit :
On 2/9/09 11:59 AM, Jean-Daniel Dupas said:
Hmm, I think it might be "Implicit Conversion to 32 bit
type" (GCC_WARN_64_TO_32_BIT_CONVERSION).
IMHO, this flag is recommended only to compile 64 bits code. On 32
bits arch, as you saw, most of the w
On 2/9/09 11:59 AM, Jean-Daniel Dupas said:
>> Hmm, I think it might be "Implicit Conversion to 32 bit
>> type" (GCC_WARN_64_TO_32_BIT_CONVERSION).
>
>IMHO, this flag is recommended only to compile 64 bits code. On 32
>bits arch, as you saw, most of the warnings are irrelevant.
I disagree. It ca
On Mon, Feb 9, 2009 at 3:33 AM, Jean-Daniel Dupas
wrote:
>
> Le 9 févr. 09 à 06:37, Rob Keniger a écrit :
>
>>
>> On 08/02/2009, at 9:52 PM, Gerriet M. Denkmann wrote:
>>
>>> When I build a Cocoa Project with 32/64 bit, this line gets a warning:
>>>NSSize a = NSMakeSize( 11.2, 22.4);
>>> w
On Feb 9, 2009, at 1:50 AM, Rob Keniger wrote:
So what is the recommendation for 64-bit development? Do we really
have to litter our code with (CGFloat) casts all over the place, or
is there some way we can tell the compiler to treat our floating
point literals as float on 32-bit and doubl
On 9 Feb 2009, at 12:43, Rob Keniger wrote:
On 08/02/2009, at 9:52 PM, Gerriet M. Denkmann wrote:
When I build a Cocoa Project with 32/64 bit, this line gets a
warning:
NSSize a = NSMakeSize( 11.2, 22.4);
which went away using:
NSSize a = NSMakeSize( (CGFloat)11.2, (CGFloa
Le 9 févr. 09 à 10:14, Rob Keniger a écrit :
On 09/02/2009, at 7:07 PM, Jean-Daniel Dupas wrote:
Which warning flag have you enabled to have this warning. I don't
see it by default ?
Hmm, I think it might be "Implicit Conversion to 32 bit
type" (GCC_WARN_64_TO_32_BIT_CONVERSION).
I
On 09/02/2009, at 7:07 PM, Jean-Daniel Dupas wrote:
Which warning flag have you enabled to have this warning. I don't
see it by default ?
Hmm, I think it might be "Implicit Conversion to 32 bit
type" (GCC_WARN_64_TO_32_BIT_CONVERSION).
--
Rob Keniger
_
Le 9 févr. 09 à 09:50, Rob Keniger a écrit :
On 09/02/2009, at 6:33 PM, Jean-Daniel Dupas wrote:
NSSize a = NSMakeSize( 11.2f, 22.4f);
The "f" suffix is a hint to the compiler that it's a float value.
A very bad idea as it would force usage of float in 64bits
applications where NSSize e
On 09/02/2009, at 6:33 PM, Jean-Daniel Dupas wrote:
NSSize a = NSMakeSize( 11.2f, 22.4f);
The "f" suffix is a hint to the compiler that it's a float value.
A very bad idea as it would force usage of float in 64bits
applications where NSSize expect 64 bits CGFloat.
So what is the recomme
Le 9 févr. 09 à 06:37, Rob Keniger a écrit :
On 08/02/2009, at 9:52 PM, Gerriet M. Denkmann wrote:
When I build a Cocoa Project with 32/64 bit, this line gets a
warning:
NSSize a = NSMakeSize( 11.2, 22.4);
which went away using:
NSSize a = NSMakeSize( (CGFloat)11.2, (CGFloa
On Sun, Feb 8, 2009 at 3:52 AM, Gerriet M. Denkmann
wrote:
> When I build a Cocoa Project with 32/64 bit, this line gets a warning:
>NSSize a = NSMakeSize( 11.2, 22.4);
> which went away using:
>NSSize a = NSMakeSize( (CGFloat)11.2, (CGFloat)22.4);
> Is this the only and correct wa
On Feb 8, 2009, at 4:52 AM, Gerriet M. Denkmann wrote:
When I build a Cocoa Project with 32/64 bit, this line gets a warning:
NSSize a = NSMakeSize( 11.2, 22.4);
which went away using:
NSSize a = NSMakeSize( (CGFloat)11.2, (CGFloat)22.4);
Is this the only and correct way to use
On 09/02/2009, at 3:37 PM, Rob Keniger wrote:
Try this:
NSSize a = NSMakeSize( 11.2f, 22.4f);
The "f" suffix is a hint to the compiler that it's a float value.
To clarify further, the compiler treats number literals with a decimal
point as a double, so you need to use the f suffix to hav
On 08/02/2009, at 9:52 PM, Gerriet M. Denkmann wrote:
When I build a Cocoa Project with 32/64 bit, this line gets a warning:
NSSize a = NSMakeSize( 11.2, 22.4);
which went away using:
NSSize a = NSMakeSize( (CGFloat)11.2, (CGFloat)22.4);
Is this the only and correct way to use N
When I build a Cocoa Project with 32/64 bit, this line gets a warning:
NSSize a = NSMakeSize( 11.2, 22.4);
which went away using:
NSSize a = NSMakeSize( (CGFloat)11.2, (CGFloat)22.4);
Is this the only and correct way to use NSMakeSize() ? Looks kind of
ugly.
A somehow related q
32 matches
Mail list logo
