On Tue, Feb 10, 2009 at 10:29 AM, Sean McBride s...@rogue-research.com 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
On Tue, Feb 10, 2009 at 7:29 AM, Sean McBride s...@rogue-research.com 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
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,
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
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
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).
On 9 Feb 2009, at 12:43, Rob Keniger r...@menumachine.com 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(
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
On Mon, Feb 9, 2009 at 3:33 AM, Jean-Daniel Dupas
devli...@shadowlab.org 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,
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 can help
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
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
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 lose a
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
On Mon, Feb 9, 2009 at 10:04 AM, Sean McBride s...@rogue-research.com 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
On Mon, Feb 9, 2009 at 11:11 AM, Steve Sisak sgs-li...@codewell.com 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
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 recommend:
#if
On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride s...@rogue-research.com 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,
At 12:52 PM -0800 2/9/09, Clark Cox wrote:
On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride s...@rogue-research.com 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
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 KR 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.
On Mon, Feb 9, 2009 at 2:11 PM, Steve Sisak sgs-li...@codewell.com 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
On Mon, Feb 9, 2009 at 2:02 PM, Nick Zitzmann n...@chronosnet.com 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
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
On Mon, Feb 9, 2009 at 3:17 PM, Steve Sisak sgs-li...@codewell.com wrote:
At 12:52 PM -0800 2/9/09, Clark Cox wrote:
On Mon, Feb 9, 2009 at 12:10 PM, Sean McBride s...@rogue-research.com
wrote:
On 2/9/09 11:24 AM, Clark Cox said:
That is, the preprocessor treats any undefined identifier
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
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 have
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 Sun, Feb 8, 2009 at 3:52 AM, Gerriet M. Denkmann
gerr...@mdenkmann.de 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
28 matches
Mail list logo
