mlanett@yoyodyne.ncsa.uiuc.edu (Mark Lanett) (04/14/91)
Has anyone tried using destructors in objects descended from TObject? The destructors appear not to get called. This is very bizarre since the constructors _do_ get called. It's also irritating since I now have to explicitly call Free. Is this really the case or is it another linker bug? Mark Lanett --
anders@verity.com (Anders Wallgren) (04/14/91)
You probably shouldn't use constructors and destructor with classes descended from TObject unless you know that they will always be created with new. I know for a fact that objects instantiated by name (ie., from a 'view' resource) then the constructor will NOT be called, since Object Pascal knows nothing about C++ constructors. I wouldn't be surprised if there was a similar problem with destructors that means you just can't use this C++ feature (don't despair - MacApp 3.0 is being written in C++). MacApp/Object Pascal uses initializers and free methods. Every class descended from TObject has an Initialize method - use this to get your object into a freeable state in case something goes wrong later in the initialization stage. The IYourClass method usually calls it's superclasses IMySuperClass method and then does it's own initialization. Of course, if the object is being instantiated from a view resource, then IRes is used instead of IYourClass. This is one of the penalties of using an Object Pascal library from C++ - you also can't use multiple inheritance and I think overloading is also a no-no. anders
keith@Apple.COM (Keith Rollin) (04/14/91)
In article <1991Apr14.015647.3521@verity.com> anders@verity.com (Anders Wallgren) writes: >You probably shouldn't use constructors and destructor with classes >descended from TObject unless you know that they will always be >created with new. I know for a fact that objects instantiated by name >(ie., from a 'view' resource) then the constructor will NOT be called, >since Object Pascal knows nothing about C++ constructors. I wouldn't >be surprised if there was a similar problem with destructors that >means you just can't use this C++ feature (don't despair - MacApp 3.0 >is being written in C++). The fact that MacApp 3.0 is being written in C++ doesn't solve the problem of constructors not being called for TViews created from 'view' resources. Remember that TViews are still descended from PascalObject. Besides, constructors are called "inline" at the point the object is created. In other words, calls to the constructors are determined and inserted at compile time. Since you don't know what views are going to be created from 'view' resource templates until run-time, it will be difficult to call their constructors (though I don't think it would be impossible, and I don't think that such a solution would require MacApp being entirely in C++ anyway). -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
ksand@Apple.COM (Kent Sandvik, 120dB or more) (04/15/91)
In article <1991Apr14.015647.3521@verity.com> anders@verity.com (Anders Wallgren) writes: >This is one of the penalties of using an Object Pascal library from >C++ - you also can't use multiple inheritance and I think overloading >is also a no-no. overloading and virtual are the same, and they work OK with PascalObjects. MI won't work due to different method dispatching schemes. Pointers to members was broken but is fixed in later d-releases of MPW C++ (ETO CDs). There are a couple of things that won't work C++:wise, and a couple of things that are broken. I'm just finishing a Tech Note which will be released during the World Wide Developer Conference, and it's all about PascalObject limitations and known bugs. Kent -- Kent Sandvik, DTS junkie
lsr@Apple.COM (Larry Rosenstein) (04/16/91)
In article <1991Apr13.235903.26110@ux1.cso.uiuc.edu> mlanett@yoyodyne.ncsa.uiuc.edu (Mark Lanett) writes: >Has anyone tried using destructors in objects descended from TObject? The >destructors appear not to get called. This is very bizarre since the The problem might be that the destructor isn't declared as virtual. If the destructor is not virtual, then 'delete obj', where obj is declared as TObject* will try to call TObject's destructor, which doesn't exist. On the other hand, I'm not sure if you can declare a virtual destructor in a subclass of PascalObject. There's also a problem with doing this if your object descends from a MacApp class. MacApp classes assume that Free() is going to be called and do their clean up there, so Free() has to be called at some point. But TObject.Free() also deletes the storage for the object. The same is true of the statement 'delete obj'. It not only calls the destructor but also deletes the storage for the object. So either Free() doesn't get called (and superclasses don't get to clean up), or the object is deleted twice. You may be able to suppress the normal C++ deletion by overriding operator delete in the class, but I'm not sure that this is legal for a subclass of PascalObject. In general, if you are using subclasses of TObject, it is best to use the MacApp conventions for initializing and deleting them. If you want to use constructors/destructors you should declare a "native" C++ class (eg, a subclass of HandleObject). -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
lsr@Apple.COM (Larry Rosenstein) (04/16/91)
In article <1991Apr14.015647.3521@verity.com> anders@verity.com (Anders Wallgren) writes: > >This is one of the penalties of using an Object Pascal library from >C++ - you also can't use multiple inheritance and I think overloading >is also a no-no. Strictly speaking, this isn't true. Just because you are linking with MacApp doesn't mean you can't use the full power of C++ in classes that you write. You can implement the internals of your app with "native" C++ objects if you choose. Anders is right, however, that if you make a subclass of TObject or any other MacApp class then you are restricted in the features of C++ you may use. You can't use overloaded virtual functions, but I think you can use overloaded non-virtual functions. (This can be useful in order to define convenience functions that simply turn around and call a normal virtual function. For example, operator+ can calls Add. If you make these inline, then there's no extra function call.) -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
anders@verity.com (Anders Wallgren) (04/16/91)
In article <13080@goofy.Apple.COM>, lsr@Apple (Larry Rosenstein) writes: >In article <1991Apr14.015647.3521@verity.com> anders@verity.com (Anders Wallgren) writes: >> >>This is one of the penalties of using an Object Pascal library from >>C++ - you also can't use multiple inheritance and I think overloading >>is also a no-no. > >Strictly speaking, this isn't true. Just because you are linking with >MacApp doesn't mean you can't use the full power of C++ in classes that you >write. You can implement the internals of your app with "native" C++ >objects if you choose. > Correct - I didn't mean to imply that you couldn't use C++ to it's fullest in non-{MacApp/TObject} related classes. anders
Jim.Spencer@p510.f22.n282.z1.mn.org (Jim Spencer) (04/16/91)
Anders Wallgren writes in a message to All AW> You probably shouldn't use constructors and destructor with classes AW> descended from TObject unless you know that they will always AW> be created with new. I know for a fact that objects instantiated AW> by name (ie., from a 'view' resource) then the constructor will AW> NOT be called, since Object Pascal knows nothing about C++ constructors. AW> I wouldn't be surprised if there was a similar problem with destructors AW> that means you just can't use this C++ feature (don't despair AW> - MacApp 3.0 is being written in C++). As I understand it (and there will certainly be hell to pay if this is not true), the rewrite of MacApp in C++ will NOT use any features of C++ that Object Pascal doesn't have, e.g. constructors and destructors. To do so would be to abandon all of the Object Pascal users who have hung in with MacApp through thick and thin over the last 5 years or so.
ksand@Apple.COM (Kent Sandvik, 120dB or more) (04/24/91)
In article <671846404.0@mmug.mn.org> Jim.Spencer@p510.f22.n282.z1.mn.org (Jim Spencer) writes: >As I understand it (and there will certainly be hell to pay if this is not true), the rewrite of MacApp in C++ will NOT use any features of C++ that Object Pascal doesn't have, e.g. constructors and destructors. To do so would be to abandon all of the Object Pascal users who have hung in with MacApp through thick and thin over the last 5 years or so. That's right, no constructor/destructors with parameter passing, no function defaults, no const methods, no MI, no inline, in general everything that the class library exports should work from both OP and C++ with MacApp 3.0. The OP header files will reflect the possibilities, and any possible C++ semantic notion which is not supported by OP is not present in either header file. Note that the internals of the class could be implemented with C++ semantics. The internals should not be used by the programmer anyway... Also MacApp 3.0 will have some additional C++ features, like Point/Rect classes with operator overload, which only works from C++, but these are additions, not elementary pieces for MacApp. Kent -- Kent Sandvik, DTS junkie