On 17 May 2008, at 0:58, Bill Bumgarner wrote:
BTW: Nice paintings.
Thanks
I post the complete solution as an example and to check that I'm
not running close to the wind by using a dummy class definition.
The code gets no compiler warnings.
You don't need the dummy class.
I'd do
The difficulty is methods in ObjC are dispatched messages rather than
hardcoded functions so going from call to method execution has some
hidden intermediate steps. And there can be more than one method with
the same name from different classes/protocols. This is one of the
pillars to
On Fri, 16 May 2008 10:12:24 -0600 Michael Vannorsdel wrote
I've tried the code here and it works as expected. Could you give
more detail on your build setup? Like what arch you're building for,
This is running as stand alone app. on Mac Pro 10.5.2
how you're executing the program,
From
- (void) callPrintConstFloat:(id)pId {
[pId printFloat:98.76]; // pId is object of
class AnonTargetClass
}
This is probably compiled in file which does not include the declaration of
class AnonTargetClass, so the compiler assumes that printFloat takes an int,
casts
On May 16, 2008, at 2:17 PM, Julius Guzy wrote:
On 16 May 2008, at 19:23 Scott Ribe [EMAIL PROTECTED] wrote
- (void) callPrintConstFloat:(id)pId {
[pId printFloat:98.76]; // pId is object of
class AnonTargetClass
}
This is probably compiled in file which does not
...if the method
name is unique, the types of the parameters are determined.
Not unless a declaration is visible. Your reasoning is that there's no other
printFloat: so the compiler should know, but this is still (sort of) C--if
you don't include a declaration that tells the compiler what the
Just to add, it's generally important to include compiler warnings
with your problem description as they provide valuable clues. The
compiler issues warnings when something doesn't look right, make
sense, or lacking information. Usually the compiler will make guesses
and assumptions as
Just to add, it's generally important to include compiler warnings
with your problem description...
Yo, any list moms listening? This is a really good suggestion that seems
like something that should perhaps be incorporated into monthly email
summarizing the list how to ask questions.
--
Yo, any list moms listening? This is a really good suggestion that
seems
like something that should perhaps be incorporated into monthly email
summarizing the list how to ask questions.
Yeah, it's been awhile since Scott Anguish's monthly mailing,
hasn't it? Lots of traffic recently that
Thanks to all who replied to my pleas for help.
I took Bill and Scott's suggestions to heart and produced the answer
I needed: Dynamic Typing which allows me to avoid circularity etc.
I post the complete solution as an example and to check that I'm not
running close to the wind by using a
On May 16, 2008, at 4:51 PM, Julius Guzy wrote:
Thanks to all who replied to my pleas for help.
I took Bill and Scott's suggestions to heart and produced the answer
I needed: Dynamic Typing which allows me to avoid circularity etc.
Good. BTW: Nice paintings.
I post the complete solution
On 16 May '08, at 2:34 PM, Bill Bumgarner wrote:
An almost universal rule of Mac OS X programming: If you see a
compiler warning, you are doing something wrong.
Amen. One of the first things I do to any Xcode project I work on is
turn on Treat warnings as errors in the build settings. For
Amen. One of the first things I do to any Xcode project I work on is
turn on Treat warnings as errors in the build settings. For some
reason almost all of Obj-C's type-checking errors appear as
warnings, and you ignore those at your peril.
VERY good advice. A little self-discipline is
This block is probably causing some corruption. You're assigning 123
to a uchar pointer and not the uchar, then passing the address of a
pointer to a method that tries to printout the pointer as an int
rather than the intended uchar value.
On May 14, 2008, at 7:19 PM, Julius Guzy wrote:
14 matches
Mail list logo
