From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-075 Date: Mon, 12 Dec 1994 16:16:53 +0100 (MET) C.S.M.P. Digest Mon, 12 Dec 94 Volume 3 : Issue 75 Today's Topics: AppleScript FTP-site? C++ and handles Finding out whether text is selected in a dialog How to get default 'aeut' resource? MacsBug - what is it and why? how to get PB in PPC completion routine? oops.. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From bafutsel@knoware.nl (Anton Futselaar) Subject: AppleScript FTP-site? Date: Mon, 21 Nov 1994 22:43:42 GMT Organization: Dieren / The Netherlands Hi, Is there somewhere out there an FTP-site for AppleScript. Thanks, Anton. +++++++++++++++++++++++++++ >From decartwr@newstand.syr.edu (Dana Cartwright 3rd) Date: 22 Nov 1994 02:36:16 GMT Organization: Syracuse University, Syracuse NY, USA Anton Futselaar (bafutsel@knoware.nl) wrote: : Is there somewhere out there an FTP-site for AppleScript. gaea.kgs.ukans.edu +++++++++++++++++++++++++++ >From drk00@cas.org () Date: Wed, 23 Nov 1994 17:02:14 GMT Organization: Chemical Abstracts Service, Columbus, Ohio In article bafutsel@knoware.nl (Anton Futselaar) writes: >Hi, > >Is there somewhere out there an FTP-site for AppleScript. > >Thanks, Anton. Try ftp://gaea.kgs.ukans.edu/applescript Dan Kelsey (drk00@cas.org) --------------------------- >From Richard Kennaway Subject: C++ and handles Date: 3 Nov 1994 13:52:44 GMT Organization: SYS, University of East Anglia I recently ported a C program to C++, which wasn't too difficult, but when I tried to convert some of the data structures to classes, I ran into a problem which seems so simple, everyone using C++ on a Mac must have encountered it. However, I don't see any nice solution. How do I use a relocatable block for storing a class object? Suppose I define a class xclass containing a member function foo(), and declare an object x of type **xclass, initialised by a call of NewHandle( sizeof(xclass) ). I can't safely call (*x)->foo(), since the implicit "this" argument to foo() is a dereferenced handle. If foo() is capable of allocating memory, then x may get relocated, invalidating the value of "this". Possible workarounds: (1) Don't use relocatable memory to allocate class objects. (Leads to memory fragmentation.) (2) Lock handles before calling member functions and restore their state afterwards. (Error-prone and tedious.) (3) Have each member function first locate the parent handle of "this" and then either lock it, or always use the handle to access components. (Memory fragmentation, error-prone, tedious, and how expensive is a call to RecoverHandle()?) (4) Abandon C++ on the Mac. Any other ideas? I'm using CodeWarrior, but the manual doesn't mention this problem. ___ \X/ Richard Kennaway, jrk@sys.uea.ac.uk, Univ. of East Anglia, Norwich +++++++++++++++++++++++++++ >From amasson@ensem.u-nancy.fr (Arnaud MASSON) Date: 3 Nov 1994 18:27:22 GMT Organization: Ensem, Nancy, France In article <39apvc$h98@cpca3.uea.ac.uk>, Richard Kennaway writes: |> I recently ported a C program to C++, which wasn't too difficult, but |> when I tried to convert some of the data structures to classes, I ran |> into a problem which seems so simple, everyone using C++ on a Mac must |> have encountered it. However, I don't see any nice solution. |> |> How do I use a relocatable block for storing a class object? Suppose I |> define a class xclass containing a member function foo(), and declare an |> object x of type **xclass, initialised by a call of NewHandle( |> sizeof(xclass) ). I can't safely call (*x)->foo(), since the implicit |> "this" argument to foo() is a dereferenced handle. If foo() is capable |> of allocating memory, then x may get relocated, invalidating the value of |> "this". |> |> Possible workarounds: |> |> (1) Don't use relocatable memory to allocate class objects. (Leads to |> memory fragmentation.) |> |> (2) Lock handles before calling member functions and restore their state |> afterwards. (Error-prone and tedious.) |> |> (3) Have each member function first locate the parent handle of "this" |> and then either lock it, or always use the handle to access components. |> (Memory fragmentation, error-prone, tedious, and how expensive is a call |> to RecoverHandle()?) |> |> (4) Abandon C++ on the Mac. |> |> Any other ideas? I'm using CodeWarrior, but the manual doesn't mention |> this problem. |> |> ___ |> \X/ Richard Kennaway, jrk@sys.uea.ac.uk, Univ. of East Anglia, Norwich Hello, this is my first experience of answering something on the Internet! About the C++ and handles, I would say that handles are an old system of memory managment. Now there is virtual memory (and many more RAM of course) than in 1984, so handles are not needed anymore for small blocks like usual objects of user interface. On powerPC, it seems that the segment loader (= handles of code) is not really necessary anymore(I'm not sure, new Inside Mac cost too much). I think also that multiple inheritance require pointers since it's impossible to have handle to something inside handle, if you see what I mean. So, there is today no reason to have C++ objects as handles. PS: sorry for my bad English. Please, could someone answer me by email ? I'm student and I would like to know who is on the Internet. +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Thu, 3 Nov 1994 14:48:03 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA It is impossible to have a C++ object class as a handle. Highly developped classes may create a whole slew of pointers to themselves and the bitwise copies that the Memory Manager uses would tear C++ objects to shreds. Nathaniel +++++++++++++++++++++++++++ >From howardb@enlil.premenos.com (Howard Berkey) Date: 3 Nov 1994 20:42:04 GMT Organization: Weyland-Yutani thinking machines division In article , Nathaniel P Woods wrote: >It is impossible to have a C++ object class as a handle. Highly >developped classes may create a whole slew of pointers to themselves and >the bitwise copies that the Memory Manager uses would tear C++ objects >to shreds. > >Nathaniel Really? You are sure about this? :-) -H- (note that I'm NOT arguing in favor of handle based objects) +++++++++++++++++++++++++++ >From brett@process.oz.au (Brett Powley) Date: 4 Nov 1994 14:37:47 +1100 Organization: Telecom Australia - CSSC Nathaniel P Woods writes: >It is impossible to have a C++ object class as a handle. Highly >developped classes may create a whole slew of pointers to themselves and >the bitwise copies that the Memory Manager uses would tear C++ objects >to shreds. I'm not sure what this somewhat confused ramble follows on from but... C++ allows you to use any allocation mechanism you like, by overriding the new operator. You may notice that THINK C with object extensions has "indirect" classes (i.e. handle-based) while Symantec C++ allows a __machdl attribute on a class to specify that it is to be handle- rather than pointer- based. I haven't found any equivalent mechanism built into CodeWarrior (yet). Brett Powley brett@process.oz.au Process Software Wollongong, Australia +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Fri, 4 Nov 1994 08:57:39 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA >Really? You are sure about this? :-) Well not all will do this. But when you make objects loaded with virtual inheritance, other complex classes inside of it, you will see that effect. That is why you should override operator = to do an assign for your class when you do stuff that would cause a bitwise copy to invalidate your class. Nathaniel +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Fri, 4 Nov 1994 09:00:33 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA >C++ allows you to use any allocation mechanism you like, by overriding the >new operator. Thats true, but lets say one of your member classes puts a pointer to itself somewhere else. If the class was derived from some type of handle, there would be no way to update that other pointer. Im not saying it isnt possible to have Handle classes, but when you get heavy into C++ they will become unusable. Nathaniel +++++++++++++++++++++++++++ >From pcastine@prz.tu-berlin.de (Peter Castine) Date: Fri, 4 Nov 1994 17:08:25 GMT Organization: Process Control Center In article <39ba2a$r8l@arcturus.ciril.fr>, amasson@ensem.u-nancy.fr (Arnaud MASSON) wrote (regarding classes as handles): > About the C++ and handles, I would say that handles are an old system of memory > managment. Now there is virtual memory (and many more RAM of course) than in 1984, > so handles are not needed anymore for small blocks like usual objects of user interface. > On powerPC, it seems that the segment loader (= handles of code) > is not really necessary anymore(I'm not sure, new Inside Mac cost too much). > I think also that multiple inheritance require pointers since it's impossible to have > handle to something inside handle, if you see what I mean. > > So, there is today no reason to have C++ objects as handles. As has been discussed extensively in c.s.m.p, handles still have a place within the Macintosh memory model, despite the relative inexpense of memory nowadays. However, C++ objects is not one of them. Arnaud is correct in stating that multiple inheritance is incompatible with handle-based C++ objects. This has been documented in _develop_ (and, presumably other places). If you have a class that inherits from superclasses A and B, the object will look something like this on the heap: +-------------------+ | Data members | | inherited from | | Class A | +-------------------+ | Data members | | inherited from | | Class B | +-------------------+ | more members | +-------------------+ If you need to execute a method inherited from B, the compiler passes a pointer to where the data members from class B are. With pointer-based classes, this is just an offset. If you have any experience with handles, you know that you can't just calculate an offset and pass it to any old function... memory may get moved somewhere along the line, the pointer is no longer valid, and general bad kharma. You will notice that both Smalltalk and THINK C with objects used handles and implement single-inheritance only . This is no coincidence. Since Richard is using CW, reverting to THINK C w/objects is not an option. (Footnote: I'm only 90% sure about Smalltalk & handles. With THINK I know) The short answer is to use pointers with C++. Your library classes will use standard handle-based data structures for accessing the Toolbox. If your class library's hot, it will have lots of tweaks to minimize heap fragmentation when using objects (I don't think any of the available class libraries is particularly hot :-\ ) > PS: sorry for my bad English. Please, could someone answer me by email ? > I'm student and I would like to know who is on the Internet. Arnaud--hey, your English is better than my French. And, I've seen native speakers use worse English on the net. -- Peter Castine | Useful approximations: pcastine@prz.tu-berlin.de | Pi seconds is a nanocentury. Process Control Center | Electricity travels a foot per nanosecond. Technical University Berlin | One ostrich egg will feed 24 people for brunch. +++++++++++++++++++++++++++ >From rbar@starbase.neosoft.com (Richard Bartel) Date: 5 Nov 1994 08:21:09 GMT Organization: NeoSoft Internet Services +1 713 684 5969 Nathaniel P Woods (nw2d+@andrew.cmu.edu) wrote: : >C++ allows you to use any allocation mechanism you like, by overriding the : >new operator. : Thats true, but lets say one of your member classes puts a pointer to : itself somewhere else. If the class was derived from some type of : handle, there would be no way to update that other pointer. : Im not saying it isnt possible to have Handle classes, but when you get : heavy into C++ they will become unusable. : Nathaniel I'm new to C++ but I have programmed extensively in Consular 68000 assembler. So please excuse me for discussing C++ objects as purely data structures and for any ignorance of C++ specifics. If a data structure is created via NewHandle (i.e. is a relocatable block), then it is unadvisable to store "a pointer to itself" except as a temporary variable while the handle is locked via HLock. A Mac handle is not a pointer to a pointer but is a pointer to a "master pointer". If a relocatable block relocates, the master pointer is updated to point to the block's new address. Therefore, if you need to maintain self-reference within a relocatable block, then you must store a copy of its handle. There may be further restrictions that C++ may require that render handles and relocatable blocks "unusable" as data structures for objects. I don't know of any restrictions but then again I am not qualified to comment on that. If they are unusable, then I am disappointed. While pointers are generally preferred over handles (due to speed and simplicity), there are times when it is nice to have the ability to increase the size of an object or to allow the object to move so another block may grow. And while machines today typically have more RAM than earlier Macs, there's never too much RAM and virtual memory is not without its costs. Also, new apps are getting bigger and lots of older Macs are still out there and still being used. As an example, we had to bump up my 8100/80 from 24 to 40Mb of RAM because Illustrator ran out of memory on some of the larger GIS documents we are producing, and even still the limitation has not been eliminated. R.L. Bartel +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Sat, 5 Nov 1994 09:58:28 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA >I'm new to C++ but I have programmed extensively in Consular 68000 >assembler. So please excuse me for discussing C++ objects as purely data >structures and for any ignorance of C++ specifics. No prob >If a data structure is created via NewHandle (i.e. is a relocatable >block), then it is unadvisable to store "a pointer to itself" except as a >temporary variable while the handle is locked via HLock. A Mac handle is >not a pointer to a pointer but is a pointer to a "master pointer". If a >relocatable block relocates, the master pointer is updated to point to the >block's new address. Therefore, if you need to maintain self-reference >within a relocatable block, then you must store a copy of its handle. Thats exactly the point Ive been making - why C++ classes cant work with handles. Classes often have member classes. With a pointer, these can be stored as offsets from the beginning of the block, but this wont work with Handles because as soon as the object gets relocated these other pointers become invalid. This is not to say that Handles are not possible with C++. One can still reference data with Handles the way one could always, just that you cant just make C++ classes based from Handles Nathaniel +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 5 Nov 1994 16:59:20 GMT Organization: The University of Texas at Austin, Austin, Texas In article <39apvc$h98@cpca3.uea.ac.uk>, Richard Kennaway wrote: < I recently ported a C program to C++, which wasn't too difficult, but < when I tried to convert some of the data structures to classes, I ran < into a problem which seems so simple, everyone using C++ on a Mac must < have encountered it. However, I don't see any nice solution. < < How do I use a relocatable block for storing a class object? Suppose I < define a class xclass containing a member function foo(), and declare an < object x of type **xclass, initialised by a call of NewHandle( < sizeof(xclass) ). I can't safely call (*x)->foo(), since the implicit < "this" argument to foo() is a dereferenced handle. If foo() is capable < of allocating memory, then x may get relocated, invalidating the value of < "this". < < Possible workarounds: < < (1) Don't use relocatable memory to allocate class objects. (Leads to < memory fragmentation.) < < (2) Lock handles before calling member functions and restore their state < afterwards. (Error-prone and tedious.) < < (3) Have each member function first locate the parent handle of "this" < and then either lock it, or always use the handle to access components. < (Memory fragmentation, error-prone, tedious, and how expensive is a call < to RecoverHandle()?) < < (4) Abandon C++ on the Mac. < < Any other ideas? I'm using CodeWarrior, but the manual doesn't mention < this problem. < < ___ < \X/ Richard Kennaway, jrk@sys.uea.ac.uk, Univ. of East Anglia, Norwich If you're using CodeWarrior then your classes are pointers, not handles. If you have data structures that are handles, they should become data members of your new classes. You create your classes in the usual way by calling operator new. In the constructor you call NewHandle() to allocate the data member. You access the data member as you would any handle from the methods of the class. Something like this: class foo { foo::foo() { itsData = NewHandle( kASize); } foo::~foo() { if (itsData) DisposeHandle( itsData ); } Handle itsData; }; -- Brian Stern :-{)} Toolbox commando and Menu bard Jaeger@fquest.com +++++++++++++++++++++++++++ >From jbennett@umich.edu (Jeremy Ford Bennett) Date: 4 Nov 1994 20:21:02 GMT Organization: University of Michigan In article <39caab$le@slug.cssc-syd.tansu.com.au>, Brett Powley wrote: >Nathaniel P Woods writes: > [snip] > >I'm not sure what this somewhat confused ramble follows on from but... > >C++ allows you to use any allocation mechanism you like, by overriding the >new operator. You may notice that THINK C with object extensions has >"indirect" classes (i.e. handle-based) while Symantec C++ allows a >__machdl attribute on a class to specify that it is to be handle- rather >than pointer- based. I haven't found any equivalent mechanism built >into CodeWarrior (yet). > >Brett Powley >brett@process.oz.au >Process Software >Wollongong, Australia Would you mind going into more detail on the _machdl attribute? I'm currently working on a small project where I will have an array of class objects in SC++ that will end up in a global structure that is a handle. I'm writing a small AfterDark module for a class so the handle is not my idea. Any info provided would be appreciated. Jeremy -- jbennett@umich.edu Student of Computer Science, University of Michigan For PGP key finger jbennett@ttl.engin.umich.edu In the end, there can be only one. +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 7 Nov 1994 21:02:56 GMT Organization: Apple Computer Nathaniel P Woods, nw2d+@andrew.cmu.edu writes: > It is impossible to have a C++ object class as a handle. Highly > developped classes may create a whole slew of pointers to themselves and > the bitwise copies that the Memory Manager uses would tear C++ objects > to shreds. Nope. You can have objects in handles, as long as the compiler knows they are in handles -- both cfront and Symantec C++ have extensions to the language that do this. There is of course additional overhead for all the double-dereferencing, and you have to be careful to lock the handle when necessary. What _is_ impossible is to use multiple inheritance with handle-based objects, because MI requires multiple objects inside an object, and you can't put a relocatable block inside another relocatable block. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 8 Nov 1994 20:57:24 GMT Organization: The University of Texas at Austin, Austin, Texas In article <39ff9l$s0g@uuneo.neosoft.com>, rbar@starbase.neosoft.com (Richard Bartel) wrote: < While pointers are < generally preferred over handles (due to speed and simplicity), there are < times when it is nice to have the ability to increase the size of an < object or to allow the object to move so another block may grow. < R.L. Bartel You might resize a handle used as a data member, but resizing the actual object is very unlikely. -- Brian Stern :-{)} Toolbox commando and Menu bard Jaeger@fquest.com +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 9 Nov 1994 01:00:56 GMT Organization: Apple Computer Nathaniel P Woods, nw2d+@andrew.cmu.edu writes: > Im not saying it isnt possible to have Handle classes, but when you get > heavy into C++ they will become unusable. This is untrue. Before you keep trying to insist on this, please read the Symantec or MPW documentation about "HandleObject" or the "__machdl" attribute. Both of these allow you to have full C++ objects in handles. The only limitation is no multiple inheritance. Very large systems like MacApp and MacApp-based applications have been built using this type of object. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Wed, 9 Nov 1994 02:37:58 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA >This is untrue. Before you keep trying to insist on this, please read the >Symantec or MPW documentation about "HandleObject" or the "__machdl" >attribute. Both of these allow you to have full C++ objects in handles. The >only limitation is no multiple inheritance. Very large systems like MacApp >and MacApp-based applications have been built using this type of object. Does MacApp use full C++ extensions in ways like PowerPlant does with multiple inheritance, objects declared in the global scope or anything else? Or are handle-classes only possible with second-rate OOP implementations that dont use constructors/destructors? If they managed to make a compiler that used handles with multiple inheritance etc it would make the most awkward looking classes imaginable. Nathaniel +++++++++++++++++++++++++++ >From isi@panix.com (Atman Jacob Binstock) Date: 9 Nov 1994 12:34:56 -0500 Organization: Integrated Software Inc. In article <1994Nov9.010056.26498@gallant.apple.com>, Jens Alfke wrote: >This is untrue. Before you keep trying to insist on this, please read the >Symantec or MPW documentation about "HandleObject" or the "__machdl" >attribute. Both of these allow you to have full C++ objects in handles. The >only limitation is no multiple inheritance. Very large systems like MacApp I don't have any experience with HandleObjects, so my comments will only be about Symantec's __machdl classes. I found __machdl classes to pose significant problems. First, there is no safe and simple way to use access functions for a member M of a __machdl class E (i.e. return a reference or pointer to a member). You have several choices: return a normal reference and hope the object doesn't move (fine for short term, bad for extended references), or cook up a reference class template Href that contains a __machdl pointer to E and an offset to M. However, the second solution is not recursive - it fails for M's access functions. Which means M needs to know whether it is IN a normal object or a __machdl object. Which means that it has to return an envelope object that can either be a normal reference or an Href. Sound like a pain? If M is to return an Href, how does it get the __machdl pointer to E that it needs? Well, M will have to be "parented" - aware of the particular object that it is contained in. This is a terrible bother for perhaps a simple class that sometimes won't even be used inside a __machdl class, and this problem occurs every time you need to use a pointer or reference to a member of a __machdl object. The solutions I outlined are doable if you really really want C++ objects in movable memory. However, I found Symantec C++ 7.0.3's __machdl's much too buggy to make a simple class work correctly. Classes mixing __machdl's and templates would rarely compile, and those that did would often had faulty code generated. I would strongly suggest avoiding __machdl classes, unless you have very simple classes and you are very tight on memory. -- Atman Binstock Integrated Software Inc. isi@panix.com speaking only for myself +++++++++++++++++++++++++++ >From pgontier@novell.com (Pete Gontier) Date: Wed, 09 Nov 1994 14:12:01 -0800 Organization: Novell, Inc., Walnut Creek/Macintosh Site In article <1994Nov9.010056.26498@gallant.apple.com>, Jens Alfke wrote: > ...please read the > Symantec or MPW documentation about "HandleObject" or the "__machdl" > attribute. Both of these allow you to have full C++ objects in handles. The > only limitation is no multiple inheritance... The only limitation is that you must remove the '=' key from your keyboard... :-) -- The views expressed here do not necessarily reflect those of my employer. +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 10 Nov 1994 00:07:03 GMT Organization: Apple Computer Nathaniel P Woods, nw2d+@andrew.cmu.edu writes: > Thats exactly the point Ive been making - why C++ classes cant work with > handles. Classes often have member classes. With a pointer, these can > be stored as offsets from the beginning of the block, but this wont work > with Handles because as soon as the object gets relocated these other > pointers become invalid. I think you mean "member objects" -- instance variables of an object which themselves are C++ objects. You can use these (and I have) with handle-based objects, provided that the member object is not a handle (obvious, since you can't put a handle inside a handle) and that pointers to the member object are not kept around for a long time -- you can keep pointers to the member object around as long as you are not calling any Toolbox routines or as long as the owning handle object is locked down, but not longer than that. Provided you obey those rules (which are very much like any other handle-based Mac techniques) you can use handle-based C++ objects just fine. You may want to say that this is bad programming practice -- I disagree with you on that, but it's better than saying "it's impossible", which is flat out wrong. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Thu, 10 Nov 1994 08:12:43 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA >I think you mean "member objects" -- instance variables of an object which >themselves are C++ objects. You can use these (and I have) with handle-based >objects, provided that the member object is not a handle (obvious, since you >can't put a handle inside a handle) and that pointers to the member object >are not kept around for a long time -- you can keep pointers to the member >object around as long as you are not calling any Toolbox routines or as long >as the owning handle object is locked down, but not longer than that. >Provided you obey those rules (which are very much like any other >handle-based Mac techniques) you can use handle-based C++ objects just fine. I do _not_ mean member objects. I mean superclasses of objects. Watch this code: class A { public: short a; short z; }; class B { public: short b; short x; }; class C : public A, public B { public: short c; }; C is now an object that contains five shorts, the offset values will be something like this: +0 a +2 z +4 b +6 x +8 c There are two inherited classes, and none use handles. You cant reference the 'B' superclass with a handle because they are inside the block of memory itself. Nathaniel +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 10 Nov 1994 19:43:16 GMT Organization: Apple Computer Nathaniel P Woods, nw2d+@andrew.cmu.edu writes: > Does MacApp use full C++ extensions in ways like PowerPlant does with > multiple inheritance, objects declared in the global scope or anything > else? Or are handle-classes only possible with second-rate OOP > implementations that dont use constructors/destructors? MacApp doesn't use MI, which I keep pointing out is impossible with handle based objects. Handle-based objects cannot also be used as global variables since they don't live in the global data space. However, I would not call these restrictions "second-rate OOP". HandleObjects support the full C++ constructor/destructor notion. And I know several OOP experts who consider MI to be too dangerous and complex to use. As I said before, I am not arguing with you that HandleObjects are more restricted than C++ objects. I'm just peeved that you keep saying it's impossible to put objects in handles, when it is not only possible but common. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 10 Nov 1994 21:59:13 GMT Organization: Apple Computer Brian Stern, Jaeger@fquest.com writes: > You might resize a handle used as a data member, but resizing the actual > object is very unlikely. No, you can resize the object. I've used dynamic-array classes like: class Stack :HandleObject { public: void Push( long ); long Pop( ); private: long nItems; long item[]; }; The implementation of Push uses PtrAndHand to append the new item to the end of the handle. It's just like regular use of handles to store dynamic data types, except that the handle happens to be treated as an object by the compiler. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Thu, 10 Nov 1994 22:22:08 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA >MacApp doesn't use MI, which I keep pointing out is impossible with handle >based objects. Handle-based objects cannot also be used as global variables >since they don't live in the global data space. >However, I would not call these restrictions "second-rate OOP". HandleObjects >support the full C++ constructor/destructor notion. And I know several OOP >experts who consider MI to be too dangerous and complex to use. ...which is exactly what I keep pointing out. Second-rate is merely a term that I am using for objects that are limited in their power. MI is not dangerous and complex to use, no more than your automobile is. You have to know how it works or else it becomes a killing machine. Some of C++'s greatest strengths is being able to have multiple inheritance which increases the power of modularity. C++'s main reason for its wide acceptance is the fact it can be used on a function-based language, OOP-based language or what have you. >As I said before, I am not arguing with you that HandleObjects are more >restricted than C++ objects. I'm just peeved that you keep saying it's >impossible to put objects in handles, when it is not only possible but common. I _never_ said it was impossible to put some types of C++ objects in Handles, only the ones that lose all of the features that seperate C++ from OOP extensions like the one in THINK C. Handles as objects are less common everyday, because OOP implementations are being switched over to full C++. Nathaniel +++++++++++++++++++++++++++ >From Nathaniel P Woods Date: Fri, 11 Nov 1994 10:32:32 -0500 Organization: Freshman, CIT Undeclared, Carnegie Mellon, Pittsburgh, PA >class Stack :HandleObject { >public: > void Push( long ); > long Pop( ); > >private: > long nItems; > long item[]; >}; What this means is that you cannot define a subclass of this class. +++++++++++++++++++++++++++ >From mnc@netcom.com (Miguel Cruz) Date: Sun, 13 Nov 1994 04:08:49 GMT Organization: Unaffiliated I sure wish more of this thread were still hanging around here. Anyway, here's a dopey question: I understand how to do C++ in a more normal memory environment, and I understand how to do C on the Mac. What I don't understand is the way to create C++ objects into memory I got as a handle from the Memory Manager (without copying them there "by hand"). I'm sure it's obvious, but I can't find any information about it on the CodeWarrior CD (or any particularly germane code samples). Any pointers to a code snippet or so to get me started? Thanks, miguel +++++++++++++++++++++++++++ >From mnc@netcom.com (Miguel Cruz) Date: Sun, 13 Nov 1994 05:21:39 GMT Organization: Unaffiliated In article , Miguel Cruz wrote: >understand how to do C on the Mac. What I don't understand is the way to >create C++ objects into memory I got as a handle from the Memory Manager Okay, I downloaded TECplusSample from ftp.apple.com and they used some mysterious class HandleObject. I tried that and it appears to work just fine. However, I'd really like to find the documentation of this. In desperation, I searched my entire hard disk for the text 'HandleObject' and it was nowhere (except in TECPlusSample). Furthermore, in my mad haste to switch CDs, I dragged the Inside Mac CD-ROM icon to the trash and when the Mac ejected it, the tray pushed a glass of grape juice off my desk and into my lap. Let that be a lesson to development tool vendors: all this would have been avoided with better documentation. miguel +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Sun, 13 Nov 1994 02:44:46 -0500 Organization: One Step Beyond mnc@netcom.com (Miguel Cruz) wrote: ) > understand how to do C on the Mac. What I don't understand is the ) > way to create C++ objects into memory I got as a handle from the ) > Memory Manager ) ) Okay, I downloaded TECplusSample from ftp.apple.com and they used some ) mysterious class HandleObject. I tried that and it appears to work just ) fine. However, I'd really like to find the documentation of this. In ) desperation, I searched my entire hard disk for the text 'HandleObject' ) and it was nowhere (except in TECPlusSample). HandleObject was a hack used by Apple and Symantec to provide Handle based objects in C++ (and the Think "object C") before multiple inheritance became an issue in the C++ world. "Real" C++ can't use handle based objects because of thorney issues with vtables, invisible pointers used in multiple inheritance and other such C++ compiler minutia. Can someone who knows more about the theoretical reasons behind this prohibition chime in with more detailed info. Basically, forget about it. One of the few benefits handle based objects would provide is dynamically resizable objects, but since C++ objects can be stack based, you can simply add a handle field to it and get the same result and be safer to boot. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Sun, 13 Nov 1994 10:49:30 -0800 Organization: Internet for the Olympic Peninsula In article , rmah@panix.com (Robert Mah) wrote: > "Real" C++ can't use handle based objects because of thorney issues with > vtables, invisible pointers used in multiple inheritance and other such > C++ compiler minutia. Can someone who knows more about the theoretical > reasons behind this prohibition chime in with more detailed info. Multiple inheritance causes requirements for pointers into the middle of objects. Pointers into the middle of [unlocked] handles are (for practical purposes) impossible. Hence no MI in HandleObject. Apple went further: since no MI, no need for the double-sized vtables which were used in CFront-like C++ implementations to support MI. So HandleObject used the older vtables. So did SingleObject. And of course PascalObject used Apple Object Pascal style method lookup (no vtables in the CFront sense). [Verb tense is strange above: Apple's CFront-based C++ is still around, but they say phase out of using it. So I used past tense.] --John -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] Sorry...clever signatures require cleverness, not found here. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From Richard Kennaway Date: 14 Nov 1994 09:43:04 GMT Organization: SYS, University of East Anglia In article John W. Baxter, jwbaxter@olympus.net writes: > Multiple inheritance causes requirements for pointers into the middle of > objects. Pointers into the middle of [unlocked] handles are (for > practical purposes) impossible. Hence no MI in HandleObject. In discussions with colleagues here, someone suggested that the problem of pointers into unlocked handles might be solved by representing such "pointers" as a pair consisting of a handle and an offset. This would be at the implementation level, the user would still write *p and the code generated would do a double dereference + offset. I'll leave to the experts the question of whether this would work or be practical. ___ \X/ Richard Kennaway, jrk@sys.uea.ac.uk, Univ. of East Anglia, Norwich +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Mon, 14 Nov 1994 17:29:48 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) isi@panix.com (Atman Jacob Binstock) writes: >The solutions I outlined are doable if you really really want C++ >objects in movable memory. However, I found Symantec C++ 7.0.3's >__machdl's much too buggy to make a simple class work correctly. >Classes mixing __machdl's and templates would rarely compile, and those >that did would often had faulty code generated. I would strongly >suggest avoiding __machdl classes, unless you have very simple classes >and you are very tight on memory. Yes. I reported many bugs in this area to Symantec back in late 1993, as long-time readers of this group may remember. In general, trying to do anything with a "Pascal object" or "handle object" in SC++ that isn't required for Think C compatibility probably won't work. John Nagle +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Mon, 14 Nov 1994 17:38:39 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Jens Alfke writes: >I think you mean "member objects" -- instance variables of an object which >themselves are C++ objects. You can use these (and I have) with handle-based >objects, provided that the member object is not a handle (obvious, since you >can't put a handle inside a handle) and that pointers to the member object >are not kept around for a long time -- you can keep pointers to the member >object around as long as you are not calling any Toolbox routines or as long >as the owning handle object is locked down, but not longer than that. >Provided you obey those rules (which are very much like any other >handle-based Mac techniques) you can use handle-based C++ objects just fine. Doesn't work for member objects with constructors. The member's constructor gets called with the owning handle object not locked down. If the member's constructor does an allocation, the owning handle object may move. The user can't program around this, because there's no place where user code has control that the locking could be performed. The owning handle object's constructor doesn't get called until it's too late, and the member's constructor doesn't know it's inside a handle. If C++ is to be used with handles, the compiler is going to have to generate HLock/HUnlock calls in some situations. There's too much automatic object behavior in C++ for manual locking to work. John Nagle +++++++++++++++++++++++++++ >From greg@cosc.canterbury.ac.nz (Greg Ewing) Date: 15 Nov 1994 00:44:15 GMT Organization: University of Canterbury, Christchurch, New Zealand In article <3a7bf8$1vm@cpca3.uea.ac.uk>, Richard Kennaway writes: |> representing such |> "pointers" as a pair consisting of a handle and an offset. |> |> I'll leave to the experts the question of whether this would work or be |> practical. I have no doubt that it could be made to work; whether it would be worth the effort is another matter. This scheme would have to be used consistently for every single pointer of any kind whatsoever. Every pointer dereference would involve doing something quite complicated, since it would have to take account of the case where it's really just an ordinary pointer, and if not, do a double-dereference-and-add. C++ programmers might not be very impressed when they find that an innocent-looking piece of code like *p++ = *q++; generates about a dozen instructions! Some optimisations may be possible if the compiler can prove that a given pointer is referencing something that won't move during some region of code. How often the compiler could prove this I don't know. Also, some provision would need to be made for interfacing with the toolbox and other pieces of code that don't know about all of this. So, it could be done, but it would have far-reaching consequences. Probably it's much better to forget about handles and hope that Apple comes up with a decent virtual-address-space OS. |> \X/ Richard Kennaway, jrk@sys.uea.ac.uk, Univ. of East Anglia, Norwich Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.| greg@cosc.canterbury.ac.nz +--------------------------------------+ +++++++++++++++++++++++++++ >From pgontier@novell.com (Pete Gontier) Date: Mon, 14 Nov 1994 19:39:21 -0800 Organization: Novell, Inc., Walnut Creek/Macintosh Site In article <2867511363@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) wrote: > Nathaniel P Woods writes: > > Jens wrote: > > > I've used dynamic-array classes... > > What this means is that you cannot define a subclass of this class. > You can subclass it fine, as long as you don't add any data mambers. This holds true until you try to compile such classes with a compiler which wants to put the hidden data members (the ones that point into the various tables, including but not limited to the virtual function dispatcher) at the *end* of the object instead of at the beginning. Since ARM says compilers can put these members anywhere it's convenient, it's likely some compiler somewhere does or will do this. Personally, I find that it's easier to put dynamically sized structures in their own allocated block, with only a pointer or handle in the object, since it's easier and less expensive to do reference counting for copies that way. However, I do think it would be nice for ANSI to specify that the hidden members be placed at the beginning of an object *and* specify rules the compiler could enforce for unbounded array declarations within classes. Perhaps there are implementation restrictions of which I am not aware. -- The views expressed here do not necessarily reflect those of my employer. +++++++++++++++++++++++++++ >From pgontier@novell.com (Pete Gontier) Date: Mon, 14 Nov 1994 19:45:23 -0800 Organization: Novell, Inc., Walnut Creek/Macintosh Site In article , rmah@panix.com (Robert Mah) wrote: > One of the few benefits handle based objects > would provide is dynamically resizable objects, but since C++ objects can > be stack based... ...you need to make the constructor protected and provide a static member function which calls it in the right way. There's always a smart-ass ready to step in and snipe, eh? :-) -- The views expressed here do not necessarily reflect those of my employer. "Furthermore, in my mad haste to switch CDs, I dragged the Inside Mac CD-ROM icon to the trash and when the Mac ejected it, the tray pushed a glass of grape juice off my desk and into my lap. Let that be a lesson to development tool vendors: all this would have been avoided with better documentation." -- Miguel Cruz +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 16 Nov 1994 21:55:24 +1300 (NZDT) Organization: (none) pgontier@novell.com (Pete Gontier) writes: > However, I do think it would be nice for ANSI to specify that the hidden > members be placed at the beginning of an object *and* specify rules the > compiler could enforce for unbounded array declarations within classes. > Perhaps there are implementation restrictions of which I am not aware. Well, yeah, there are good reasons that they can't always go at the front. Consider: class a { void dosomething(); int calculatethis(); int i; char c; }; class b: public a { virtual void dosomethingelse(); }; Now, class "a" dosn't have any virtual functions, and therefore doesn't have a vptr. Class "b" has a virtual function, and needs a vptr, and so it has to go after class "a"'s data members, unless you want to break lots of programs. It *would* be possible to make use of the mechanism provided for multiple inheritence to put the vptr at the front, and have a cast from a* to b* (or the revers) add a constant. But I don't think people would expect that. -- Bruce +++++++++++++++++++++++++++ >From shahid@mail.utexas.edu (Shahid M. Alam) Date: Wed, 16 Nov 1994 08:19:12 -0600 Organization: The University of Texas at Austin In article , pgontier@novell.com (Pete Gontier) wrote: > ...you need to make the constructor protected and provide a static member > function which calls it in the right way. or an argument-taking ctor to do the same (while protecting the default ctor). ______________________ Shahid M. Alam shahid@mail.utexas.edu +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 16 Nov 1994 21:55:24 +1300 (NZDT) Organization: (none) pgontier@novell.com (Pete Gontier) writes: > However, I do think it would be nice for ANSI to specify that the hidden > members be placed at the beginning of an object *and* specify rules the > compiler could enforce for unbounded array declarations within classes. > Perhaps there are implementation restrictions of which I am not aware. Well, yeah, there are good reasons that they can't always go at the front. Consider: class a { void dosomething(); int calculatethis(); int i; char c; }; class b: public a { virtual void dosomethingelse(); }; Now, class "a" dosn't have any virtual functions, and therefore doesn't have a vptr. Class "b" has a virtual function, and needs a vptr, and so it has to go after class "a"'s data members, unless you want to break lots of programs. It *would* be possible to make use of the mechanism provided for multiple inheritence to put the vptr at the front, and have a cast from a* to b* (or the revers) add a constant. But I don't think people would expect that. -- Bruce +++++++++++++++++++++++++++ >From shahid@mail.utexas.edu (Shahid M. Alam) Date: Wed, 16 Nov 1994 08:19:12 -0600 Organization: The University of Texas at Austin In article , pgontier@novell.com (Pete Gontier) wrote: > ...you need to make the constructor protected and provide a static member > function which calls it in the right way. or an argument-taking ctor to do the same (while protecting the default ctor). ______________________ Shahid M. Alam shahid@mail.utexas.edu +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 16 Nov 1994 21:55:24 +1300 (NZDT) Organization: (none) pgontier@novell.com (Pete Gontier) writes: > However, I do think it would be nice for ANSI to specify that the hidden > members be placed at the beginning of an object *and* specify rules the > compiler could enforce for unbounded array declarations within classes. > Perhaps there are implementation restrictions of which I am not aware. Well, yeah, there are good reasons that they can't always go at the front. Consider: class a { void dosomething(); int calculatethis(); int i; char c; }; class b: public a { virtual void dosomethingelse(); }; Now, class "a" dosn't have any virtual functions, and therefore doesn't have a vptr. Class "b" has a virtual function, and needs a vptr, and so it has to go after class "a"'s data members, unless you want to break lots of programs. It *would* be possible to make use of the mechanism provided for multiple inheritence to put the vptr at the front, and have a cast from a* to b* (or the revers) add a constant. But I don't think people would expect that. -- Bruce +++++++++++++++++++++++++++ >From shahid@mail.utexas.edu (Shahid M. Alam) Date: Wed, 16 Nov 1994 08:19:12 -0600 Organization: The University of Texas at Austin In article , pgontier@novell.com (Pete Gontier) wrote: > ...you need to make the constructor protected and provide a static member > function which calls it in the right way. or an argument-taking ctor to do the same (while protecting the default ctor). ______________________ Shahid M. Alam shahid@mail.utexas.edu +++++++++++++++++++++++++++ >From sandvik@apple.com (Kent Sandvik) Date: Fri, 25 Nov 1994 15:19:01 -0800 Organization: Apple Computer, Inc. Developer Technical Support In article , mnc@netcom.com (Miguel Cruz) wrote: > In article , Miguel Cruz wrote: > >understand how to do C on the Mac. What I don't understand is the way to > >create C++ objects into memory I got as a handle from the Memory Manager > > Okay, I downloaded TECplusSample from ftp.apple.com and they used some > mysterious class HandleObject. I tried that and it appears to work just > fine. However, I'd really like to find the documentation of this. In > desperation, I searched my entire hard disk for the text 'HandleObject' > and it was nowhere (except in TECPlusSample). HandleObject (and PascalObject) were and are documented int the MPW C++ documentation. --Kent -- Kent Sandvik sandvik@apple.com New Media Analyst/Programmer Private activities on Internet. --------------------------- >From kurisuto@babel.ling.upenn.edu (Sean Crist) Subject: Finding out whether text is selected in a dialog Date: 11 Nov 1994 18:33:16 GMT Organization: University of Pennsylvania, Linguistics Department My application has modeless dialogs containing editable text items, and I want to tell whether some text is actually selected so that I can enable/disable the Cut and Copy commands appropriately. There's lots of handy routines going back as far as OldIM Vol. I to handle the actual cutting and pasting, but I don't see any prescribed way to tell whether some text is selected. The solution appears to be to look at the TextH field of the dialog record to get the currently active TEHandle, and then look in that TEHandle to see whether any text is selected. What I want to know is whether this is kosher; mucking around in the Toolbox's data structures like this seems to be discouraged, but I don't see any other way to do this. \/ __ __ _\_ --Kurisuto (kurisuto@unagi.cis.upenn.edu) --- | | \ / _| ,| ,| ----- For a free copy of the Bill of Rights, finger _| ,| ,| [_] this account. | | | [_] +++++++++++++++++++++++++++ >From bjaques@wimsey.com (Barton Jaques) Date: Tue, 15 Nov 1994 12:21:44 -0700 Organization: Wimsey Information Services The solution appears to be to look at the TextH field of the dialog record to get the currently active TEHandle, and then look in that TEHandle to see whether any text is selected. Yes, that's exactly what you should do. Check TERec.selStart and TERec.selEnd to see if any characters are selected, then find them in TERec.hText (handle to text). You're not actually mucking with Apple's precious data structures, you're just spying on them. Anyway, in my ModalDialogs I quite freely discard Apple's hTexts and replace them with my own. Just call TECalText (and maybe TESetSelect) and TEUpdate afterward to make sure everything still displays right. -- bjaques@wimsey.com +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Thu, 24 Nov 1994 10:37:29 +0800 Organization: Department of Computer Science, University of Western Australia In article <3a0ddc$e14@netnews.upenn.edu>, kurisuto@babel.ling.upenn.edu (Sean Crist) wrote: >The solution appears to be to look at the TextH field of the dialog record >to get the currently active TEHandle, and then look in that TEHandle to see >whether any text is selected. What I want to know is whether this is >kosher; mucking around in the Toolbox's data structures like this seems to >be discouraged, but I don't see any other way to do this. Welcome to the world of the Dialog Manager, where lots of things just can't be done nicely. You have to either accept that and do them horribly or eschew the Dialog Manager and do it all yourself. For an official DTS line on this, take at look at the following TechNote... M.TB.ToolboxKarma M.TB39 TN227 "Toolbox Karma" This Technical Note discusses Macintosh Toolbox compatibility and what you can do to help the Macintosh continue evolving in the future. Share and Enjoy. -- Quinn "The Eskimo!" "Some-kind-of-secret-weapon-came-out-of-nowhere- and-took-Captain-Bipto-to-his-dooooooooom!" May the Force be with you! --------------------------- >From gmcgath@condes.mv.com (Gary McGath) Subject: How to get default 'aeut' resource? Date: Fri, 18 Nov 1994 15:52:29 GMT Organization: Conceptual Design I'm trying to figure out the right way to access the 'aeut' resource of the default scripting component. OpenComponentResFile() looks as if it might provide a key portion of the answer, but the documentation implies it can only be called from within a component. Either general advice or pointers to sample source code would be welcome. If convenient, please copy to me by E-mail. -- Gary McGath gmcgath@condes.mv.com +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 23 Nov 1994 00:32:20 GMT Organization: Apple Computer Gary McGath, gmcgath@condes.mv.com writes: > I'm trying to figure out the right way to access the 'aeut' resource of > the default scripting component. OpenComponentResFile() looks as if it > might provide a key portion of the answer, but the documentation implies > it can only be called from within a component. There is an undocumented OSAGetSysTerminology call that AppleScript implements (this is what the Script Editor calls) but it appears to have been sanitized out of the shipping OSA.h and AppleScript.h headers. However, it is safe to call OpenComponentResFile on another component, so you can do it that way. Just remember to detach the resource and make it unpurgeable, of course. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 25 Nov 94 11:25:56 +1300 Organization: University of Waikato, Hamilton, New Zealand In article <1994Nov23.003220.3519@gallant.apple.com>, Jens Alfke writes: > > There is an undocumented OSAGetSysTerminology call that AppleScript > implements (this is what the Script Editor calls) but it appears to have been > sanitized out of the shipping OSA.h and AppleScript.h headers. I believe you'll find this call in ASDebugging.h/.p. It looks like this: CONST kASSelectGetSysTerminology = 0110BH; PROCEDURE OSAGetSysTerminology ( scriptingComponent : ComponentInstance; modeFlags : AESendMode; terminologyID : ShortInt; VAR terminologyList : AEDesc ) : OSAError; CODE 02F3CH, 10, kASSelectGetSysTerminology, 07000H, 0A82AH; Lawrence D'Oliveiro fone: +64-7-856-2889 Computer Services Dept fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 --------------------------- >From sjm@mole.bio.cam.ac.uk (Steven J. Mcclue) Subject: MacsBug - what is it and why? Date: Mon, 21 Nov 1994 10:19:23 +0000 Organization: Dept of Genetics, University of Cambridge Apologies if this is the wrong place for this, but could someone tell me what programmers use MacsBug for? I'm a real newbie at programming (ie, I'm about half way through Dave Mark's book "Learn C on the Mac" and not finding it easy!!), and I've often seen mention of MacsBug. I used to have a copy, but on the rare occasions it popped up, it seemed full of unintelligible stuff. Now that I'm deling with lots of unintelligible stuff, maybe some kind soul could enlighten me as to what it all means? Thanks! Steve McClue sjm@mole.bio.cam.ac.uk +++++++++++++++++++++++++++ >From jaks@netcom.com (Eric Jackson) Date: Mon, 21 Nov 1994 16:27:23 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) In article , Steven J. Mcclue wrote: >Apologies if this is the wrong place for this, but could someone tell me what programmers use MacsBug for? I'm a real newbie at programming (ie, I'm about half way through Dave Mark's book "Learn C on the Mac" and not finding it easy!!), and I've often seen mention of MacsBug. I used to have a copy, but on the rare occasions it popped up, it seemed full of unintelligible stuff. Now that I'm deling with lots of unintelligible stuff, maybe some kind soul could enlighten me as to what it all means? > >Thanks! >Steve McClue >sjm@mole.bio.cam.ac.uk Yes this is exactly the place to post questions like this. The idea behind this news group was to provide a place for newbies to post questions with out having to feel embarassed about it. What is MacsBug, that would take a while to explain in detail. In one sentince its a LowLever debugger, and a good one. This means that it takes you down into the assemble language lever. I have never writen any assemble language code but I still like to look at it. After a while you will start to learn more and more about it. Here are a couple of basic tips. You can get into MacsBug by calling: DebugStr("\p your debugger comment goes here"); with the think Use Debugger option turned of. Once your in the debugger you can go again assuming things are not messed up by typing g, to step one step at a time type s, to get out of your application type ea for exit application, if your application is already messed up type rb for reboot. You can also type es for exit shell. Type h for help and get a list of all the commands, type il for instruction list and get an assembly language list of your code. If you look at it you might be able to see some tool box routines that you recognise to get an idea of where you are. Normally you use a lowlever debugger when your high level debugger is not working correctly in finding a bug. There is quite a lot more to know about MacsBug, but this will give you a really short overview. Eric Jackson jaks@netcom.com +++++++++++++++++++++++++++ >From coopem@panix.com (Marc Cooperman) Date: Tue, 22 Nov 1994 10:07:55 -0500 Organization: Jumpstart Technologies I don't claim to be a MacsBug expert. It's a low-level debugger - which means, generally, you don't see source code in it, but you can look directly at the Macs memory, registers, and program counter, which describe its state, at a level below such higher level languages like C. You enter MacsBug in 2 situations - the machine encounters a heinous processing error in a particular program from which it can't recover, so it gives up, and deposits you into the aesthetically pleasing MacsBug screen, in the vain hope the you too speak hexdecimal and will be able to diagnose the problem. In this case you can type es [Return] to try and cleanly exit the program and recover to the finder, or ea [Return] to try restarting the offending program from scratch. If you're feeling brave, you can try the sc or sc7 commands to do a "stack crawl" which basically shows you a heirarchy of function calls leading up to the crash. If the program was compiled with debugging info, you may actually see readable function names, and if this a development project of your own, it may give you a clue where to look for a bug in your code. The other situation is a forced MacsBug entry where you either hit the interrupt switch on your Mac (I think this causes an "NMI" Non Maskable Interrupt? on the processor) which puts you immediately in MacsBug with the "NMI" message, or by calling DebugStr() from your code, which can print a message of your choice, say if you detect an error condition like a NULL pointer BEFORE it actually hoses your machine. In article , sjm@mole.bio.cam.ac.uk (Steven J. Mcclue) wrote: > Apologies if this is the wrong place for this, but could someone tell me what programmers use MacsBug for? I'm a real newbie at programming (ie, I'm about half way through Dave Mark's book "Learn C on the Mac" and not finding it easy!!), and I've often seen mention of MacsBug. I used to have a copy, but on the rare occasions it popped up, it seemed full of unintelligible stuff. Now that I'm deling with lots of unintelligible stuff, maybe some kind soul could enlighten me as to what it all means? > > Thanks! > Steve McClue > sjm@mole.bio.cam.ac.uk +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Mon, 28 Nov 1994 15:56:13 -0500 Organization: The Pitt, Chemistry In article , jaks@netcom.com (Eric Jackson) wrote: > Normally you use a lowlever debugger when your high level debugger > is not working correctly in finding a bug. There is quite a lot > more to know about MacsBug, but this will give you a really short > overview. [tips omitted] If you [original poster] are interested in getting a handle on more info, consider buying a copy of: _MacsBug Reference and Debugging Guide_ by Apple Computer $35 Addison Wesley, 1990, ISBN: 0-201-56768-7 just started chewing on it myself. But it seems to be the only reference for MacsBug. BTW, anyone know if there is a chance that this will eventually wind up in DocViewer format on a _develop_ bookmark or Developer reference CD? I'm kind of surprised it hasn't, maybe Apple is waiting for version 6.5 final release before doing it...? Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ --------------------------- >From telesis@ecf.toronto.edu (Telesis North) Subject: how to get PB in PPC completion routine? Date: Thu, 24 Nov 1994 23:53:56 GMT Organization: sparodic Does anyone out there have a good strategy for writing completion routines that compile for both PPC and 68K? My problem is that I have to write a completion routine for the serial driver. I would _really_ like to get access to the parameter block; unfortunately, it's not passed as a parameter. (That would be too sensible.) For 68K, A0 comes in pointing to the PB, and a bit of assembly will put it into a local variable. Clearly this isn't going to work on a PowerMac. (I realize that I could leave the completion routine as 68K without a significant performance hit - at least until Copland - but I'd prefer not to complicate my build process with mixed code.) Anyone have any ideas? (What does DTS think?) -- Roger Pantos Telesis North, Inc. telesisnorth Mac Software Guy telesis@ecf.toronto.edu (AppleLink) "They want better products for free." -- from "Dilbert" +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 24 Nov 1994 23:55:12 -0500 Organization: America Online, Inc. (1-800-827-6364) In article , telesis@ecf.toronto.edu (Telesis North) writes: >My problem is that I have to write a completion routine for the serial >driver. I would _really_ like to get access to the parameter block; >unfortunately, it's not passed as a parameter. (That would be too >sensible.) > > (a bunch ommitted ) > > Anyone have any ideas? (What does DTS think?) Look in Files.h and you'll find what you need for IOCompletion routines. If you're compiling native, the parameter block pointer is passed to your completion routine as a parameter. However, for the time being I'd leave completion routines in 68K code because the Device Manager is still emulated 68K code. You'd have the overhead of a couple of mixed mode switches if your completion routine was written in PowerPC code. Since you shouldn't be doing processor intensive processing at completion time anyway, writing PowerPC completion routines shouldn't help your performance (and quite possibly will hurt it under System 7). - Jim Luther +++++++++++++++++++++++++++ >From paul@architecture.mcgill.ca (Paul Lalonde) Date: Fri, 25 Nov 1994 07:46:39 -0400 Organization: McGill University School of Architecture In article , telesis@ecf.toronto.edu (Telesis North) wrote: > Does anyone out there have a good strategy for writing completion routines > that compile for both PPC and 68K? > > My problem is that I have to write a completion routine for the serial > driver. I would _really_ like to get access to the parameter block; > unfortunately, it's not passed as a parameter. (That would be too > sensible.) If you're using CodeWarrior, you can declare a function argument as residing in a register (68K only). You would then have a slightly different function declaration for your completion proc, depending if you're compiling for the PPC or not: #if USESCODEFRAGMENTS extern void MyCompletionProc(ParmBlkPtr pbPtr); #else extern void MyCompletionProc(ParmBlkPtr pbPtr : __A0); #endif And the code would look like this: #if USESCODEFRAGMENTS void MyCompletionProc(ParmBlkPtr pbPtr) #else void MyCompletionProc(ParmBlkPtr pbPtr : __A0) #endif { ParmBlkPtr pb = pbPtr; // do stuff here -- don't forget to set up A5! } Hope this helps Paul Lalonde lalonde@metrowerks.ca +++++++++++++++++++++++++++ >From h+@metrowerks.com (Jon W{tte) Date: Sat, 26 Nov 1994 15:59:48 +0100 Organization: The Conspiracy In article , telesis@ecf.toronto.edu (Telesis North) wrote: >My problem is that I have to write a completion routine for the serial >driver. I would _really_ like to get access to the parameter block; >unfortunately, it's not passed as a parameter. (That would be too >sensible.) Oh, but on the PowerPC runtime architecture, it IS passed as a parameter. And you can force the compiler to use a parameter in A0 under 68K by using #pragma parameter. So your callback can have a declaration like any function, with a pointer-to-param-block argument. >For 68K, A0 comes in pointing to the PB, and a bit of assembly will put it >into a local variable. Clearly this isn't going to work on a PowerMac. The PowerMacs have one, well-defined calling convention, used *everywhere* >(I realize that I could leave the completion routine as 68K without a >significant performance hit - at least until Copland - but I'd prefer not >to complicate my build process with mixed code.) Not only that, but you'll SEE a large performance hit for the NATIVE callback, because the serial drivers are 68K code. You can of course build a routine descriptor that describes the calling convention of the callback and use that. Cheers, / h+ -- Jon Wdtte (h+@metrowerks.com), Hagagatan 1, 113 48 Stockholm, Sweden ~r ~/.signature --------------------------- >From chopps@water.emich.edu (Christian E. Hopps) Subject: oops.. Date: 20 Nov 1994 09:27:55 GMT Organization: University of Michigan EECS Dept. I caught myself (luckily) making a big mistake today. void func(SomeHandle joe) { (**joe).j_rgn = NewRgn(); /* bug */ I think this should be in the FAQ regarding handles. Not many programmers (I think) deal with Order of Evaluation issues like this one. At least for me, handles are something new and so the above code didn't seem bad. Incase you haven't caught the bug (its probably patently obviuos to long time mac people). NewRgn() will move memory (or so you should assume) and C (most languages?), except in the case of &&, ||, comma, and ?:, does not specify order of evaluation. Therefore assuming worst case, the compiler evaluates the handle, i.e. locates the memory to store to and then calls NewRgn(). Finally it stores the result in the afore mentioned memory. Oops except NewRgn() moved memory so the result is stored in bogusville. Thus the proper thing to do is: RgnHandle rh; rh = NewRgn(); (**joe).j_rgn = rh; Things like ap[i] = i++; are obvious to me. Being new to handles however hid the order of evaluation issue from me. Maybe this should go in the FAQ? Chris. +++++++++++++++++++++++++++ >From stk@dobag.in-berlin.de (Stefan Kurth) Date: 21 Nov 1994 00:34:28 +0100 Organization: none In article <3an4qr$q7s@zip.eecs.umich.edu>, chopps@water.emich.edu (Christian E. Hopps) wrote: > void > func(SomeHandle joe) > { > (**joe).j_rgn = NewRgn(); /* bug */ > > I think this should be in the FAQ regarding handles. There's an explicit warning about this in Inside Macintosh (both the old IM Vol I and NIM:Memory). BTW, I'd strongly suggest to get yourself a copy of QC; it does a terrific job at finding such bugs for you (and many others too). A demo is available at the common Mac archives, the full version is something like $99. Well worth the money. ________________________________________________________________________ Stefan Kurth Berlin, Germany stk@dobag.in-berlin.de +++++++++++++++++++++++++++ >From asunta@convex.csc.FI (Miika Asunta) Date: 24 Nov 1994 23:15:23 GMT Organization: Sibelius Academy, Helsinki In <3an4qr$q7s@zip.eecs.umich.edu> chopps@water.emich.edu (Christian E. Hopps) writes: >I caught myself (luckily) making a big mistake today. >void >func(SomeHandle joe) >{ > (**joe).j_rgn = NewRgn(); /* bug */ >Thus the proper thing to do is: > RgnHandle rh; > rh = NewRgn(); > (**joe).j_rgn = rh; Or as well: MoveHHi(joe); HLock(joe); (**joe).j_rgn = NewRgn(); HUnlock(joe); -- Miika Asunta asunta@convex.csc.fi Double Bass Player tel. +358-31-255 9461 Macintosh Programmer +++++++++++++++++++++++++++ >From chopps@water.emich.edu (Christian E. Hopps) Date: 25 Nov 1994 05:40:49 GMT Organization: University of Michigan EECS Dept. Miika Asunta (asunta@convex.csc.FI) wrote: : In <3an4qr$q7s@zip.eecs.umich.edu> chopps@water.emich.edu (Christian E. Hopps) writes: : >I caught myself (luckily) making a big mistake today. : >void : >func(SomeHandle joe) : >{ : > (**joe).j_rgn = NewRgn(); /* bug */ : >Thus the proper thing to do is: : > RgnHandle rh; : > rh = NewRgn(); : > (**joe).j_rgn = rh; : Or as well: : MoveHHi(joe); HLock(joe); : (**joe).j_rgn = NewRgn(); : HUnlock(joe); Have you profiled that? I recommend highly that you do it my way. :) Chris. --------------------------- End of C.S.M.P. Digest **********************