combs@sumex-aim.stanford.edu (Dave Combs) (08/29/89)
Gang, In the StepStone manuals, there is a section showing and describing the C code that is generated by the Objective-C part of the compiler (i.e., method names are reduced to functions, messages are replaced by calls to _msg, etc). One is supposed to be able to get this by giving the -C option to the compiler. However, the NeXT version of the GNU compiler uses the -C option for something completely different (of course! :-( ) Does anyone know of any way that I can get access to this "intermediate" C code, for tracking down a very strange bug? Perhaps I can get help on the problem behind all this. I have a subclass of Object that contains a TextFieldCell * as an instance variable named "cell". The new method for this class (Item) contains the statement cell = [TextFieldCell newTextCell:""]; On the first invocation of this Item "new" method, everything is fine. On the second, the "self" variable for the new Item is somehow used by TextFieldCell, because after the above statement, even though self has not changed, [self name] reports "TextFieldCell" as the class, and the data (dumped in gdb) is all set to look like a TextFieldCell. Help!!! Dave (combs@sumex-aim.stanford.edu) P.S. Of course, this all used to work fine all the time. I'm not sure if I've uncovered 1)a strange preprocessor bug, 2)a bug in TextFieldCell, 3)a bug in my code, or 4)a bug that's already known about. Any assistance is GREATLY appreciated.
ali@polya.Stanford.EDU (Ali T. Ozer) (08/31/89)
In article <24042@labrea.Stanford.EDU> Dave Combs writes: >In the StepStone manuals, there is a section showing and describing the >C code that is generated by the Objective-C part of the compiler ... > ... One is supposed to be able to get this by giving the -C >option to the compiler. However, the NeXT version of the GNU compiler >uses the -C option for something completely different ... The NeXT ObjC compiler is a ObjC in, assembly out compiler. Thus no intermediate C code can be generated. > ... The new method for this class (Item) contains the statement > cell = [TextFieldCell newTextCell:""]; > >On the first invocation of this Item "new" method, everything is fine. >On the second, the "self" variable for the new Item is somehow >used by TextFieldCell, because after the above statement, even though >self has not changed, [self name] reports "TextFieldCell" as the class, >and the data (dumped in gdb) is all set to look like a TextFieldCell. Hmm. Trying to look at self through gdb can sometimes be confusing & misleading; "print *someid" might not be correct, depending on the context. Try using "print *self->isa" to see what class "self" is... If it does seem like it is TextFieldClass, then try "make clean" and remake, just to eliminate any problems that might arise from an inconsistency between the header files and classes. If the problem still exists, please post (or mail me) the class (or the +new method) and we can take a look at it. Ali Ozer, NeXT Developer Support aozer@NeXT.com
jacob@gore.com (Jacob Gore) (09/01/89)
/ comp.sys.next / ali@polya.Stanford.EDU (Ali T. Ozer) / Aug 31, 1989 / > Trying to look at self through gdb can sometimes be confusing & > misleading; "print *someid" might not be correct, depending on the context. > Try using "print *self->isa" to see what class "self" is... If it does > seem like it is TextFieldClass, then try "make clean" and remake, just to > eliminate any problems that might arise from an inconsistency between > the header files and classes. Another thing to do is to make sure that "-O" flag was not used during compilation. If it was, you indeed get the most amusing answers from gdb about anything concerning 'self'... especially in a '+new'-type factory method, after 'self' is assigned the value of an instance (as in "self=[super new];"): the value of 'self' stays unchanged (i.e., poining to the factory), and none of the instance variables are visible. If you are using the Interface Builder and the Makefiles that it generates, just make sure that you do "make debug" instead of just "make". That will compile all files with option "-gg" instead of the usual "-g -O". Jacob -- Jacob Gore Jacob@Gore.Com {nucsrl,boulder}!gore!jacob
combs@sumex-aim.stanford.edu (Dave Combs) (09/01/89)
Ali, Thanks for your message. It turns out the problem was a misunderstanding I had about how the Storage class works. In trying to follow the documentation, I was calling "free" on some items I had put into a Storage instance, in the mistaken belief that what Storage was doing was to allocate storage for managing pointers to items that I created (much as the List class does). It turns out, however, that Storage is actually COPYING my data into storage it allocates for itself (which is obvious, given the request for the item sizes when creating Storage, but I of course missed this). When the docs talk about "freeing" items from Storage, I believe that they really mean "do any processing you need to do before the pointer to the item is lost forever", rather than "free the storage that I'm using to hold your data". Anyway, when I realized this, I ceased trying to free pointers in the Storage object, and everything worked fine. Thanks again, Dave (combs@sumex-aim.stanford.edu) P.S. Maybe somebody should expand the documentation on Storage just a bit, to make the above points a bit more clear? Just a suggestion.