From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-019 Date: Mon, 25 Apr 94 11:11:52 MET DST C.S.M.P. Digest Mon, 25 Apr 94 Volume 3 : Issue 19 Today's Topics: C Source Code Wanted: Beginer Examples Decompressing JPEG images: Help! Mac Game Programming Mixed Mode Manager statistics gathering - is it possible? Pure virtual call from a dtor Symantec C++ 7.0 (Full)- Initial Impressions Symantec technical support not home System 7 Pro & Drag Mgr. Using PBCatSearch 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 as comp.sys.mac.programmer.src. ------------------------------------------------------- >From Spiegs Subject: C Source Code Wanted: Beginer Examples Date: Fri, 1 Apr 1994 08:15:19 GMT Organization: University of Minnesota, Twin Cities I am a fairly novice C programmer. I am interested in obtaining all the C source code I can obtain, preferably simple code for now. I am looking for any FTP sites with C source code available to anonymous users. Thanks. BTW - I would spring for CodeWarrior in a hartbeat, if I had a CD-Rom. Spiegs spie0024@gold.tc.umn.edu +++++++++++++++++++++++++++ >From kenlong@netcom.com (Ken Long) Date: Fri, 1 Apr 1994 21:04:02 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Find the current MacFTP list and then connect to ftps on the list which reportedly have lots of Mac files. Stanford and the University of Michigan have the "largest stock" of source code. Look in their development and source directories and there are enough examples to either make you crave more or give up programming. Check the ftp that's home to the alt.sources.mac newsgroup, as well. -Ken- +++++++++++++++++++++++++++ >From chuck@gte.com (Chuck Hoffman) Date: Tue, 5 Apr 1994 12:43:49 GMT Organization: GTE Laboratories In article , Spiegs wrote: > I am a fairly novice C programmer. I am interested in obtaining all the C > source code I can obtain, preferably simple code for now. > > I am looking for any FTP sites with C source code available to anonymous > users. Thanks. > 1. There are good examples for beginners in "Macintosh C Programming Primer, Volume 1, second edition" by Mark and Reed. The book comes with a diskette. 2. There are several locations for Frequently Asked Questions (FAQs). Some of the FAQs include code snippets. You may be interested in these: ftp site: rtfm.mit.edu directory: /pub/usenet/news.answers/macintosh files (in order): 1. general 2. system 3. misc 4. apps ftp site: ftp.cs.uoregon.edu directory: /pub/mac files (in order): 1. csmp-faq-1 2. csmp-faq-2 ftp site: nada.kth.se directory: /pub/hacks/mac-faq file: CSMP_PD_FAQ ftp site: soda.berkeley.edu directory: /pub/jwang file: av-general-faq.txt 3. Chassis is a sample application shell upon which you can build other applications. Chassis is a good source of sample code. Chassis is in the following anonymous ftp locations. Do not use the version at Stanford University (sumex-aim) because it is not current, and is not 32-bit clean. Use these, instead: ftp.gte.com: /pub/chuck/Chassis_6.0.sea.hqx mac.archive.umich.edu: /mac/development/source/chassis6.0.cpt.hqx -- Chuck Hoffman GTE Laboratories, Waltham, MA, USA 617-466-2131 - ------------------------------------------------ I'm not sure why we're here, but I am sure that while we're here we're supposed to help each other. - ------------------------------------------------ +++++++++++++++++++++++++++ >From blob@apple.com (Brian Bechtel) Date: 9 Apr 1994 06:16:48 -0700 Organization: Apple Computer, Inc., Cupertino, California Spiegs writes: >I am a fairly novice C programmer. I am interested in obtaining all the C >source code I can obtain, preferably simple code for now. I have an html file (for Mosaic) on ftp.apple.com which points to several major source code sites. ftp.apple.com is not a MacHttp server, so you have to grab the file directly. The URL is file://ftp.apple.com/pub/blob/macsourcecode.html I'd welcome additions or corrections. Yes, I do plan to eventually have a HTTP server. --Brian Bechtel blob@apple.com "My opinion, not Apple's" --------------------------- >From cr@cs.strath.ac.uk (Chris Reid) Subject: Decompressing JPEG images: Help! Date: Wed, 06 Apr 1994 11:22:36 +0000 Organization: University of Strathclyde Hi Netters, I'm trying to decompress and display 32-bit JPEG images. I've (sort of) figured out how to do this. The problem is, the image doesn't appear on screen properly, because the palette isn't quite right. At the same time, I'd like to convert it to PICT format. I'm using QuickTime to do the 'dirty work' for me. The quality of the decompressed image should be as high as possible. The destination screen is 8 bits deep. Here's what I'm doing: OpenCPicParams header; ImageDescriptionHandle desc; PicHandle thePic; [Set up desc and get image dimensions (header.srcRect)] /* Create a gWorld for the decompressed data */ e = NewGWorld(&theGWorld, (*desc)->depth, &header.srcRect, NULL, NULL, 0); if (e != noErr) { [blah, blah] } /* Set the port and open picture */ SetGWorld(theGWorld, NULL); thePic = OpenCPicture(&header); /* Now do the actual decompression */ e = FDecompressImage( data, desc, GetGWorldPixMap(theGWorld), &header.srcRect, NULL, ditherCopy, (RgnHandle) NULL, (PixMapHandle) NULL, (Rect *) NULL, codecMaxQuality, bestFidelityCodec, 0, (DataProcRecordPtr) NULL, (ProgressProcRecordPtr) &myProgressRec); if (e != noErr) { [more blah, blah] } /* Done! */ ClosePicture(); /* Now get the (supposedly) ideal 8 bit palette */ /* popularMethod or medianMethod doesn't improve things, btw. */ e = GetPixMapInfo(GetGWorldPixMap(theGWorld), &thePictInfo, returnPalette, 256, systemMethod, 0); [tidy up etc] /* Display picture and set palette to match */ SetPalette(myWindow, thePictInfo.thePalette, TRUE); DrawPicture(thePic, &(*thePic)->picFrame); Everythings works, the picture displays fine. It's just not quite right. The palette returned doesn't seem to fit the image. GifConverter manages slightly better, JPEGView displays the image perfectly. What am I doing wrong? I'll be forever grateful for any hints or solutions! A deadline is looming. Please e-mail me as our news server is *very* unreliable. I'll summarise to the net, probably to alt.sources.mac if I can come up with some source code. Many thanks in advance, Chris PS: I can save my converted JPEG image in it's new PICT form. Again, JPEGView displays it like a charm. Aaron, how the heck do you do it :-) +-----------------------------------------------------------------+ |Chris Reid e-mail: cr@cs.strath.ac.uk | |Dept. Computer Science, Strathclyde University, Glasgow, Scotland| +-----------------------------------------------------------------+ +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 11 Apr 94 17:13:12 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , cr@cs.strath.ac.uk (Chris Reid) writes: > > I'm trying to decompress and display 32-bit JPEG images. I've (sort of) > figured out how to do this. The problem is, the image doesn't appear > on screen properly, because the palette isn't quite right. > > /* Now get the (supposedly) ideal 8 bit palette */ > /* popularMethod or medianMethod doesn't improve things, btw. */ > > e = GetPixMapInfo(GetGWorldPixMap(theGWorld), &thePictInfo, returnPalette, > 256, systemMethod, 0); The basic problem is that the Picture Utilities package doesn't understand anything about QuickTime-compressed PixMaps. It's a pity. They did a good job of integrating QuickTime into all the rest of QuickDraw, but they never got around to fixing this. You could always decompress to a regular PixMap, do a GetPixMapInfo on this, then go back and use that palette with the original compressed data. Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division 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+12:00 --------------------------- >From Shinya Fujimoto Subject: Mac Game Programming Date: Thu, 7 Apr 1994 13:33:28 -0400 Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA Hi, I am not sure if this is the right place to post, but if I'm wrong, please redirect me. I am a beginner in Macintosh program and am now in the step of programming a simple game. I wonder if there is any good way to move objects around the screen. I currently use scroll, but this becomes extremely slow if the region is a little too big. Redrawing the object will flash the object as it erases and redraws. Is there any good way?? Thanks! Takoyaki Master - --------------------------------- Shinya Fujimoto Carnegie Mellon University Carnegie Institue of Technology Electrical & Computer Engineering E-mail: sf1x+@andrew.cmu.edu fujimoto+@cmu.edu - --------------------------------- +++++++++++++++++++++++++++ >From alex@metcalf.demon.co.uk (Alex Metcalf) Date: Fri, 8 Apr 1994 10:38:53 GMT Organization: Demon Internet In article , Shinya Fujimoto wrote: > Hi, > > I am not sure if this is the right place to post, > but if I'm wrong, please redirect me. > > I am a beginner in Macintosh program and am now in > the step of programming a simple game. > > I wonder if there is any good way to move objects around > the screen. I currently use scroll, but this becomes > extremely slow if the region is a little too big. > Redrawing the object will flash the object as it erases > and redraws. > > Is there any good way?? > > Thanks! > > Takoyaki Master Don't worry, you're in the right place! The best way is to keep copying the graphic in the new position. However, to avoid the flicker, you need to create an "offscreen graphics world", as described in Inside Mac 6. Just think of it as a screen you can't see. You draw all the graphics to this world, and then copy them all onto the screen (in the new positions) using CopyBits, described in Inside Mac 1 and 5. Let me know if I can be of more help! Alex -- Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler Internet, AOL, BIX: alex@metcalf.demon.co.uk "Surely you AppleLink: alex@metcalf.demon.co.uk@internet# can't be CompuServe: INTERNET:alex@metcalf.demon.co.uk serious?" Delphi: alex@metcalf.demon.co.uk@inet# FirstClass: alex@metcalf.demon.co.uk,Internet "I'm serious... Fax (UK): (0570) 45636 and don't call Fax (US / Canada): 011 44 570 45636 me Shirley." +++++++++++++++++++++++++++ >From declipse@aol.com (DEclipse) Date: 7 Apr 1994 17:02:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , Shinya Fujimoto writes: >I wonder if there is any good way to move objects around >the screen. I currently use scroll, but this becomes >extremely slow if the region is a little too big. >Redrawing the object will flash the object as it erases >and redraws. Well, I don't normally answer posts like this, but since it's for a CMU person (I grad in '90), here's a start. It works for B & W, but you can change it to color. Determine the size of the object you want to scroll, add twice the maximum scroll amount for both horiz. and vert. So: short H = ObjectH + 2 * DeltaH; short V = ObjectV + 2 * DeltaV; Translate H to bits and round to the nearest word: short RowBytes = ((H +7) / 8 + 1) & 0xFFFE; in non-optimized code. So you need a block of memory sized V * RowBytes. Allocate this block and create a BitMap record. Set the fields in the BitMap and set the base addr to the block of memory you allocated. Create a GrafPort. SetPortBits to the BitMap. Get the oldPort, SetPort to the GrafPort, Draw your object in the center of the BitMap, close the port, SetPort to the oldPort. Now you can use CopyBits from the BitMap you created to qd.screenBits with the appropriate rects and regions. This is a lot of work, but the fastest compatible method. Keep your mask regions nil or rects for speed. The white space around the objects is so that you can erase the old image and copy the new image without having to call EraseRect. (Calling EraseRect and then CopyBits isn't bad, but there may be some minor flicker if the Rects overlap.) Howard Fukuda +++++++++++++++++++++++++++ >From Reid Ellis Date: Sun, 10 Apr 1994 01:51:37 GMT Organization: Alias Research, Inc., Toronto ON Canada Shinya Fujimoto wrote: |> I wonder if there is any good way to move objects around |> the screen. I currently use scroll, but this becomes |> extremely slow if the region is a little too big. |> Redrawing the object will flash the object as it erases |> and redraws. Alex Metcalf writes: | The best way is to keep copying the graphic in the new position. |However, to avoid the flicker, you need to create an "offscreen graphics |world", as described in Inside Mac 6. [..more good advice deleted] An alternative is to use the SpriteWorld library, available at an FTP site near you. It handles very fast blitting of sprites around the screen, using offscreen GWorlds and CopyBits() and even non-CopyBits() [very *compatible* direct-to-screen memory access]. I haven't used it myself; these opinions have been formed by reading feedback in this group over time. Reid -- - - Reid Ellis, Alias Research Inc. +1 416 362 9181 +++++++++++++++++++++++++++ >From alex@metcalf.demon.co.uk (Alex Metcalf) Date: Sun, 10 Apr 1994 10:34:32 GMT Organization: Demon Internet In article <1994Apr10.015137.5181@alias.com>, Reid Ellis wrote: > Shinya Fujimoto wrote: > |> I wonder if there is any good way to move objects around > |> the screen. I currently use scroll, but this becomes > |> extremely slow if the region is a little too big. > |> Redrawing the object will flash the object as it erases > |> and redraws. > > Alex Metcalf writes: > | The best way is to keep copying the graphic in the new position. > |However, to avoid the flicker, you need to create an "offscreen graphics > |world", as described in Inside Mac 6. > > [..more good advice deleted] > > An alternative is to use the SpriteWorld library, available at an FTP > site near you. It handles very fast blitting of sprites around the > screen, using offscreen GWorlds and CopyBits() and even non-CopyBits() > [very *compatible* direct-to-screen memory access]. > > I haven't used it myself; these opinions have been formed by reading > feedback in this group over time. > > Reid The non-CopyBits direct screen memory access stuff isn't that hard.... the best place to start is to read the "Graphics" folder of the Mac Game Developer's Handbook on the Developer CDs. It has loads of excellent technotes relating directly to game development, such as non-CopyBits and dithering graphics for mono screens. I could also post some code I've written in assembler: it copies a rectangle from an offscreen world to either another offscreen world or to the screen. It works quite well, and beats the hell out of CopyBits. Alex -- Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler Internet, AOL, BIX: alex@metcalf.demon.co.uk "Surely you AppleLink: alex@metcalf.demon.co.uk@internet# can't be CompuServe: INTERNET:alex@metcalf.demon.co.uk serious?" Delphi: alex@metcalf.demon.co.uk@inet# FirstClass: alex@metcalf.demon.co.uk,Internet "I am serious... Fax (UK): (0570) 45636 and don't call Fax (US / Canada): 011 44 570 45636 me Shirley." --------------------------- >From sbarta@magnus.acs.ohio-state.edu (Scott Barta) Subject: Mixed Mode Manager statistics gathering - is it possible? Date: 6 Apr 1994 09:58:08 -0400 Organization: The Ohio State University I have been thinking for a while that a really neat app/init/cdev to write for the PowerMacs would be one that sits on top of the Mixed Mode Manager and gathers statistics for the number of mode switches that occur, the amount of time the system spends emulated, the time spent native, the overhead for a mode switch, etc. The utility could collect stats for the system as a whole and possibly by application. Obviously it would greatly increase the overhead for a mode switch, so it isn't something one would want running constantly, but it would be very interesting and informative for those who are curious about what's going on under the covers. The question is, how could you do it? I looked at the interface for the MMM last night, and understandably, there isn't any sort of interface that would allow you to patch in and install your own routines into a mode switch. (I think I can hear the Apple guys groaning somewhere in the distance). I tried tracing into some native traps with MacsBug, but, little to my surprise, a 680X0 debugger didn't give me much help with native code. But I figure there must be a way, since it sounds like exactly the sort of thing the Apple engineers would use while developing OS code on the machine. Anyone out there care to drop a hint or two (or perhaps bestow a gift of the utility if it indeed exists)? /************************************************************************/ /* Scott Barta */ /* Eisenhower National Clearinghouse */ /* The Ohio State University */ /* sbarta@enc.org */ /************************************************************************/ +++++++++++++++++++++++++++ >From jlscott@tigr.org (John L. Scott) Date: 6 Apr 1994 14:17:43 -0500 Organization: Self In article <199404061358.JAA13146@bottom.magnus.acs.ohio-state.edu>, sbarta@magnus.acs.ohio-state.edu (Scott Barta) wrote: > Obviously it would greatly increase the overhead for a mode switch, so it > isn't something one would want running constantly, but it would be very > interesting and informative for those who are curious about what's going on > under the covers. Actually, the patch itself would only need to increment a couple of longs each time a mode switch occurs. That's not a great increase in overhead. The application that monitors those longs could be set to update them every second or so. No great overhead there. Sounds doable to me--if you can figure out what to hook into. --John L. Scott +++++++++++++++++++++++++++ >From Brian Strull Date: Mon, 11 Apr 1994 22:43:27 GMT Organization: Apple Computer, Inc. The Macintosh Debugger for PowerPC, available with the Macintosh on RISC SDK, includes some features for performance gathering. It uses pc sampling to give an estimate of % emulated time vs. % native time, and breaks native time up into which libraries you were in, and which functions within libraries. Since parts of the system are libraries, this gives you some of the information you want. This doesn't do everything you asked. It doesn't count mixed mode switches, or measure absolute time spent on mixed mode overhead. +++++++++++++++++++++++++++ >From tim@toad.com (Tim Maroney) Date: 11 Apr 94 20:52:51 GMT Organization: As Little As Possible In article <199404061358.JAA13146@bottom.magnus.acs.ohio-state.edu> sbarta@magnus.acs.ohio-state.edu (Scott Barta) writes: >I have been thinking for a while that a really neat app/init/cdev to write >for the PowerMacs would be one that sits on top of the Mixed Mode Manager >and gathers statistics for the number of mode switches that occur, the >amount of time the system spends emulated, the time spent native, the >overhead for a mode switch, etc. > >The question is, how could you do it? Great idea! Let's see, is it possible? Here's a first stab at a design, for which I make absolutely no promises: (1) Use the millisecond timer for collecting statistics on time spent in each mode. Your timer routine should merely increment a counter which will be used by the intercepts below. (2) Detect mode switches from 68K->PPC by intercepting the mixed mode pseudo-trap in the 68K emulator. A little challenging but you should be able to use a debugger to find out where the code you need to patch lives: just step through an execution of an instance of _MixedModeMagic. (2a) Catching the return to 68K mode is tricky. You'll need to either munge the switch stack frame to return to a routine that does the statistics gathering (see IM: PPC System Software, p. 2-11) or figure out what the Mixed Mode Manager does when it sees that bit and intercept the action another way. The former is probably easier. Your intercept for _MixedModeMagic can push a return address to a 68K routine that will notice the mode switch back to 68K and then return to the caller of _MixedModeMagic. (3) Detect mode switches from PPC-68K by the method in (2a) as well as by patching CallUniversalProc and CallOSTrapUniversalProc. Again you will probably need to push a return-interception code address onto the stack. (4) A drop-dead-easy Control Panel interface to turn the thing on and off and report the statistics, with an INIT to install these patches. I'd give it about a week, maybe two weeks if the interception of _MixedModeMagic turns out to be especially tricky. But I haven't looked into this in a real way at all, and this design might not work for that reason. -- Tim Maroney, Communications and User Interface Engineer {apple!sun}!hoptoad!tim, tim@toad.com "God must be a Boogie Man." -- Joni Mitchell --------------------------- >From rmah@panix.com (Robert S. Mah) Subject: Pure virtual call from a dtor Date: Sun, 03 Apr 1994 07:12:50 -0500 Organization: One Step Beyond I have the following code... class Test{ public: Test() { } virtual ~Test(); virtual int Pure() = 0; virtual int Foo(); }; Test::~Test() { Pure(); } int Test::Foo() { return Pure(); } In Symantec C++ (Mac v7.0) it returns the error... 'Test::Pure' is a pure virtual function in the d'tor. If I use an empty d'tor, it compiles fine like it should. However, Metrowerks C++ compiles the Pure() call in the d'tor without complaining. Which is right? Is this legal C++ code? I can't imagine why I can't call a pure virtual function from a dtor, but C++ is a strange language... Cheers, Rob ________________________________________________________________________ Robert S. Mah One Step Beyond rmah@panix.com +++++++++++++++++++++++++++ >From pjl@graceland.att.com (Paul J. Lucas) Date: Sun, 3 Apr 1994 19:55:48 GMT Organization: AT&T In rmah@panix.com (Robert S. Mah) writes: >I have the following code... > class Test{ > public: > Test() { } > virtual ~Test(); > virtual int Pure() = 0; > virtual int Foo(); > }; > Test::~Test() { Pure(); } > int Test::Foo() { return Pure(); } >In Symantec C++ (Mac v7.0) it returns the error... > 'Test::Pure' is a pure virtual function >in the d'tor. If I use an empty d'tor, it compiles fine like it should. >However, Metrowerks C++ compiles the Pure() call in the d'tor without >complaining. >Which is right? Is this legal C++ code? I can't imagine why I can't call >a pure virtual function from a dtor, but C++ is a strange language... The code is legal. I can find nothing forbidding it in the ARM; *con*structors are another matter. -- - Paul J. Lucas AT&T Bell Laboratories Naperville, IL +++++++++++++++++++++++++++ >From neeri@iis.ee.ethz.ch (Matthias Neeracher) Date: 3 Apr 94 23:51:00 Organization: Integrated Systems Laboratory, ETH, Zurich In article , pjl@graceland.att.com (Paul J. Lucas) writes: > In rmah@panix.com (Robert S. Mah) writes: >>I have the following code... >> class Test{ >> public: >> Test() { } >> virtual ~Test(); >> virtual int Pure() = 0; >> virtual int Foo(); >> }; >> Test::~Test() { Pure(); } >> int Test::Foo() { return Pure(); } >>In Symantec C++ (Mac v7.0) it returns the error... >> 'Test::Pure' is a pure virtual function >>in the d'tor. If I use an empty d'tor, it compiles fine like it should. >>However, Metrowerks C++ compiles the Pure() call in the d'tor without >>complaining. >>Which is right? Is this legal C++ code? I can't imagine why I can't call >>a pure virtual function from a dtor, but C++ is a strange language... > The code is legal. I can find nothing forbidding it in the ARM; > *con*structors are another matter. I think we have different readings of ARM 12.7, pg. 294, then: # Member functions may be called in constructors and destructors. This implies # that virtual functions may be called (directly or indirectly). The function # called will be the one defined in the constructor's (or destructor's) own # class or its bases, but *not* any function overriding it in a derived class. # This ensures that unconstructed objects will not be accessed during # construction or destruction. While the sentence on page 295 talking about pure virtuals only talks about constructors, it seems clear to me that it applies equally to destructors, and thus Symantec C++ is IMHO right (as a syntax checker, SC++ definitely has its merits :-). This behavior makes perfect sense: Once a virtual destructor is called, any of the "derived objects" have already been destructed and thus their "class invariants" no longer hold, which makes calling members defined there very dangerous. Matthias - --- Matthias Neeracher neeri@iis.ethz.ch "Evidently the cleaning lady found him slumped over his Macintosh" -- Jay McInerney, _Brightness Falls_ +++++++++++++++++++++++++++ >From pjl@graceland.att.com (Paul J. Lucas) Date: Sun, 3 Apr 1994 22:42:41 GMT Organization: AT&T In neeri@iis.ee.ethz.ch (Matthias Neeracher) writes: >In article , pjl@graceland.att.com (Paul J. Lucas) writes: >> In rmah@panix.com (Robert S. Mah) writes: >>>I have the following code... >>> class Test{ >>> public: >>> Test() { } >>> virtual ~Test(); >>> virtual int Pure() = 0; >>> virtual int Foo(); >>> }; >>> Test::~Test() { Pure(); } >>> int Test::Foo() { return Pure(); } >>>In Symantec C++ (Mac v7.0) it returns the error... >>> 'Test::Pure' is a pure virtual function >>>in the d'tor. If I use an empty d'tor, it compiles fine like it should. >>>However, Metrowerks C++ compiles the Pure() call in the d'tor without >>>complaining. >>>Which is right? Is this legal C++ code? I can't imagine why I can't call >>>a pure virtual function from a dtor, but C++ is a strange language... >> The code is legal. I can find nothing forbidding it in the ARM; >> *con*structors are another matter. >I think we have different readings of ARM 12.7, pg. 294, then: ># Member functions may be called in constructors and destructors. This implies ># that virtual functions may be called (directly or indirectly). The function ># called will be the one defined in the constructor's (or destructor's) own ># class or its bases, but *not* any function overriding it in a derived class. ># This ensures that unconstructed objects will not be accessed during ># construction or destruction. >While the sentence on page 295 talking about pure virtuals only talks about >constructors, Bingo! >it seems clear to me that it applies equally to destructors, There is no room for supposition. It either says it or it doesn't. Given that it is not expressly forbidden, it is allowed. >This behavior makes perfect sense: Once a virtual destructor is called, any >of the "derived objects" have already been destructed and thus their "class >invariants" no longer hold, which makes calling members defined there very >dangerous. While the poster's code has a virtual destructor, that's not the issue; the issue is whether a pure virtual *function* can be called from a destructor. Since objects are destroyed bottom up, the most-derived function *can* be called it seems. Obviously, this is not true for CONstruction since the most derived part hasn't been constructed yet. So perhaps the "omission" in the ARM is intentional. -- - Paul J. Lucas AT&T Bell Laboratories Naperville, IL +++++++++++++++++++++++++++ >From b91926@fsgt01.fnal.gov (David Sachs) Date: 3 Apr 1994 17:52:56 -0500 Organization: FERMILAB, Batavia, IL It is perfectly legal (from the compiler's point of view) to call a function, that has been declared as pure virtual, either by calling the function directly or indirectly from a constructor or destructor, or by calling the function with an explicit scope qualifier. The C++ language permits explicitly defining a function that has been declared as pure virtual, specifically for the purpose of supporting such calls. If a pure virtual function, which has NOT been defined, is called, the effects at run time are unspecified. Two common methods used by various C++ implementations are: Execute random garbage or generate an immidiate failure by jumping to location 0. Execute a function that prints a message about the improper call and ends the program. +++++++++++++++++++++++++++ >From bobzim@interaccess.com (Bob Zimmerman) Date: 3 Apr 1994 15:46:20 GMT Organization: InterAccess, Chicagoland's Full Service Internet Provider Robert S. Mah (rmah@panix.com) wrote: > I have the following code... > class Test{ > public: > Test() { } > virtual ~Test(); > virtual int Pure() = 0; > virtual int Foo(); > }; > Test::~Test() { Pure(); } > In Symantec C++ (Mac v7.0) it returns the error... > 'Test::Pure' is a pure virtual function > in the d'tor. If I use an empty d'tor, it compiles fine like it should. > Which is right? Is this legal C++ code? I can't imagine why I can't call > a pure virtual function from a dtor, but C++ is a strange language... One reason the compiler could be complaining is: A Destructor will call all of the "sub-classes" destructors... and the compiler is concerned that these destructors... will have "thrown away" information needed by the pure virtual funciton... This (IMHO) isn't valid for the compiler to enforce in a d'tor since the order of execution is that the current d'tor runs first (destroying local stack stuff - as opposed to a sub-classs) so the sub-class stuff should always be available. I know in the constructor - this is definilty true... I am not sure why it would be enforced for the d'tor... -- - ------------------------------------------------- | Bob Zimmerman bobzim@interaccess.com | | Voice: (708) 402-4664 | | | | If it's worth reading, | | you found it on Internet! | - ------------------------------------------------- +++++++++++++++++++++++++++ >From rmartin@rcmcon.com (Robert Martin) Date: Mon, 4 Apr 1994 15:28:47 GMT Organization: R. C. M. Consulting Inc. 708-918-1004 rmah@panix.com (Robert S. Mah) writes: > class Test{ > public: > virtual ~Test(); > virtual int Pure() = 0; > }; > Test::~Test() { Pure(); } >Is this legal C++ code? No. It is illegal to call a pure virtual function from either a constructor or destructor. The reason is simple. When constructing a derived class, the base class constructor is called first. While it is executing the object under construction is an instance of the "base" NOT an instance of the derived (in fact the vtbl pointer is set at the vtbl for the base class). Thus there IS NO IMPLEMENTATION for the pure function. C++ has a rule. No member function will ever be called unless all the bases and members for that class have been constructed first. If a constructor could call and deploy a virtual function to a class lower in the hierarchy than the currently executing constructor, then this rule would be violated. Moral: Don't call pure virtual functions from constructors or destructors. Period. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ +++++++++++++++++++++++++++ >From neeri@iis.ee.ethz.ch (Matthias Neeracher) Date: 5 Apr 94 16:49:40 Organization: Integrated Systems Laboratory, ETH, Zurich In article , pjl@graceland.att.com (Paul J. Lucas) writes: > In neeri@iis.ee.ethz.ch (Matthias Neeracher) writes: >>In article , pjl@graceland.att.com (Paul J. Lucas) writes: >>> In rmah@panix.com (Robert S. Mah) writes: >>>>Which is right? Is this legal C++ code? I can't imagine why I can't call >>>>a pure virtual function from a dtor, but C++ is a strange language... >>> The code is legal. I can find nothing forbidding it in the ARM; >>> *con*structors are another matter. >>I think we have different readings of ARM 12.7, pg. 294, then: >># Member functions may be called in constructors and destructors. This implies >># that virtual functions may be called (directly or indirectly). The function >># called will be the one defined in the constructor's (or destructor's) own >># class or its bases, but *not* any function overriding it in a derived class. >># This ensures that unconstructed objects will not be accessed during >># construction or destruction. [...] >>This behavior makes perfect sense: Once a virtual destructor is called, any >>of the "derived objects" have already been destructed and thus their "class >>invariants" no longer hold, which makes calling members defined there very >>dangerous. > While the poster's code has a virtual destructor, that's not the > issue; the issue is whether a pure virtual *function* can be > called from a destructor. Since objects are destroyed bottom > up, the most-derived function *can* be called it seems. I'm not sure what you mean by "bottom up". The destructor calling order is exactly the opposite of the constructor calling order, so at the time the virtual destructor is called, the most-derived function definitely *cannot* be called. Look again at the ARM quote above: # The function called will be the one defined in the constructor's (or # destructor's) own class [...] but *not* any function overriding it [...] > Obviously, this is not true for CONstruction since the most > derived part hasn't been constructed yet. And because at DEstruction time, the derived part is not constructed *anymore*, the same argument applies there. > So perhaps the "omission" in the ARM is intentional. Since we are arguing about the ARM rather than the Old Testament here, I am more inclined to consider this an unintentional imprecision. No matter what is and is not mentioned on page 295, the language quoted above from page 294 makes it clear that a call from the destructor could only call the pure virtual, and that is undefined even if page 295 doesn't explicitly say so. Matthias - --- Matthias Neeracher neeri@iis.ee.ethz.ch "Johannes Scotus Eriugena, the greatest European philosopher of the 9th century, said that if reason and authority conflict, reason should be given preference. And if that doesn't sound reasonable to you, you'll just have to accept it..." +++++++++++++++++++++++++++ >From rmartin@rcmcon.com (Robert Martin) Date: Tue, 5 Apr 1994 14:00:07 GMT Organization: R. C. M. Consulting Inc. 708-918-1004 pjl@graceland.att.com (Paul J. Lucas) writes: [regarding the calling of pure virtual functions from destructors...] > There is no room for supposition. It either says it or it doesn't. > Given that it is not expressly forbidden, it is allowed. Bah. This is a fine example of legalism clouding rational thought. > [...]the issue is whether a pure virtual *function* can be > called from a destructor. Since objects are destroyed bottom > up, the most-derived function *can* be called it seems. > Obviously, this is not true for CONstruction since the most > derived part hasn't been constructed yet. > So perhaps the "omission" in the ARM is intentional. No. The "most-derived" function is unimplemented when a PVF is called from its own destructor. The concrete object being destroyed has already be partially destructed. The class that provided the implementation for the PVF no longer exists. While it is true that the ARM does not explicitly disallow calling PVFs from destructors, I think it is clear that this is an omission, and not intended to imply that calling PVFs from destructors is either legal or advisable. There is a "hint" in the ARM regarding this. Section 12.1, in the commentary, "...virtual functions will work only after construction and before destruction of an object..." The bottom line, in any case, is that if you call a PVF from a destructor, your program will crash. That, I think, is the most powerful indictment of all. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ +++++++++++++++++++++++++++ >From kanze@us-es.sel.de (James Kanze) Date: 05 Apr 1994 19:30:55 GMT Organization: SEL In article pjl@graceland.att.com (Paul J. Lucas) writes: |> In neeri@iis.ee.ethz.ch (Matthias Neeracher) writes: |> >In article , pjl@graceland.att.com (Paul J. Lucas) writes: |> >> In rmah@panix.com (Robert S. Mah) writes: |> >>>I have the following code... |> >>> class Test{ |> >>> public: |> >>> Test() { } |> >>> virtual ~Test(); |> >>> virtual int Pure() = 0; |> >>> virtual int Foo(); |> >>> }; |> >>> Test::~Test() { Pure(); } |> >>> int Test::Foo() { return Pure(); } |> >>>In Symantec C++ (Mac v7.0) it returns the error... |> >>> 'Test::Pure' is a pure virtual function |> >>>in the d'tor. If I use an empty d'tor, it compiles fine like it should. |> >>>However, Metrowerks C++ compiles the Pure() call in the d'tor without |> >>>complaining. |> >>>Which is right? Is this legal C++ code? I can't imagine why I can't call |> >>>a pure virtual function from a dtor, but C++ is a strange language... |> >> The code is legal. I can find nothing forbidding it in the ARM; |> >> *con*structors are another matter. |> >I think we have different readings of ARM 12.7, pg. 294, then: |> ># Member functions may be called in constructors and destructors. This implies |> ># that virtual functions may be called (directly or indirectly). The function |> ># called will be the one defined in the constructor's (or destructor's) own |> ># class or its bases, but *not* any function overriding it in a derived class. |> ># This ensures that unconstructed objects will not be accessed during |> ># construction or destruction. |> >While the sentence on page 295 talking about pure virtuals only talks about |> >constructors, |> Bingo! |> >it seems clear to me that it applies equally to destructors, |> There is no room for supposition. It either says it or it doesn't. |> Given that it is not expressly forbidden, it is allowed. |> >This behavior makes perfect sense: Once a virtual destructor is called, any |> >of the "derived objects" have already been destructed and thus their "class |> >invariants" no longer hold, which makes calling members defined there very |> >dangerous. |> While the poster's code has a virtual destructor, that's not the |> issue; the issue is whether a pure virtual *function* can be |> called from a destructor. Since objects are destroyed bottom |> up, the most-derived function *can* be called it seems. |> Obviously, this is not true for CONstruction since the most |> derived part hasn't been constructed yet. Since when are objects destroyed bottom up? The most derived class is destructed first, then the next, and the base class is destructed last. (Destruction is in the opposite order of construction.) In particular, when executing the destructor for a class, all derived classes have already been destructed. |> So perhaps the "omission" in the ARM is intentional. I don't think so. -- James Kanze email: kanze@lts.sel.alcatel.de GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France Conseils en informatique industrielle -- -- Beratung in industrieller Datenverarbeitung +++++++++++++++++++++++++++ >From thor@telerama.lm.com (Tom Moertel) Date: 5 Apr 1994 18:59:34 -0400 Organization: MSA, Inc., CSG Technologies Division Robert S. Mah (rmah@panix.com) wrote: : I have the following code... : : class Test{ : public: : Test() { } : virtual ~Test(); : virtual int Pure() = 0; : virtual int Foo(); : }; : : Test::~Test() { Pure(); } : : int Test::Foo() { return Pure(); } : In Symantec C++ (Mac v7.0) it returns the error... : 'Test::Pure' is a pure virtual function : in the d'tor. If I use an empty d'tor, it compiles fine like it should. [Snip] : Which is right? Is this legal C++ code? I can't imagine why I can't call : a pure virtual function from a dtor, but C++ is a strange language... Strictly speaking, it's legal, but like calls from constructors, calls from destructors do not use virtual lookup to call member functions of derived classes. For example, calling Pure() from Test's destructor is equivalent to calling Test::Pure(). When SC++ complains about calling a pure virtual function from a destructor, it's actually trying to do you a favor. It reasons that because Pure() is pure virtual, Test::Pure() doesn't exist (faulty conclusion), and therefore you have made a mistake. What's weird is that if you actually define Test::Pure(), which is a perfectly legitimate thing to do, SC++ still gives you the error. There is a solution, however: just call Test::Pure() explicitly. Not only does this work, it helps readers of your code better understand what is really happening. I've tried this, and it works fine: class Test { virtual int Pure() = 0; virtual ~Test(); }; int Test::Pure() { return 0; } Test::~Test() { Test::Pure(); } // doesn't compile: Test::~Test() { Pure(); } -- Tom Moertel Interests: Software Engineering, Symbolic Mathematics, MSA, CSG Technologies Division Algorithms, thor@telerama.lm.com Itchy-Scratchy Theory. +++++++++++++++++++++++++++ >From Reid Ellis Date: Sat, 9 Apr 1994 21:17:33 GMT Organization: Alias Research, Inc., Toronto ON Canada Robert Mah wrote: |I have the following code... | | class Test{ | public: | Test() { } | virtual ~Test(); | virtual int Pure() = 0; | virtual int Foo(); | }; | | Test::~Test() { Pure(); } | | int Test::Foo() { return Pure(); } | |In Symantec C++ (Mac v7.0) it returns the error... | 'Test::Pure' is a pure virtual function |in the d'tor. If I use an empty d'tor, it compiles fine like it should. In "The C++ Programming Language, 2nd Edition", in section r.12.7 [p 582] it talks about constructors [but not destructors] and pure virtual methods: The effect of calling a pure virtual function directly or indirectly for the object being constructed from a constructor, except using explicit qualification, is undefined (see section r.10.3). In every other case w.r.t. virtual functions, constructors and destructors mirror each other, so I would gather that this case is no exception. Seems like Symantec C++ is justified in signalling an error. Other implementations may do other things, since this use is explicitly "undefined". Making it an error keeps you from writing non-portable code, IMHO. Reid -- - - Reid Ellis, Alias Research Inc. +1 416 362 9181 --------------------------- >From radicallib@aol.com (RadicalLib) Subject: Symantec C++ 7.0 (Full)- Initial Impressions Date: 8 Apr 1994 16:58:05 -0400 Organization: America Online, Inc. (1-800-827-6364) I haven't had time to evaluate the new state of the C++ translator, or other compile/code-generation issues... But here's some comments for what they are worth. The THINK Project Manager hasn't changed much. The addition of a trivially configurable scripts menu being the major, and a welcome, change. One minor change that I think will also be welcomed is a Preferences dialog for C++ Warnings... Every warning is now individually toggleable. It is in the additions, (those things only in the $150 upgrade, NOT in the free update), that things get interesting... 1) THINK Class Library 2.0 - What we've been waiting for: A true C++ application framework. Since this is real C++, the TCL is no longer supported by the C compiler... C TCL users will have to stick with 1.1.3. Some features: -Real constructors and destructors, (the old IClassName methods are still there for backwards compatibility). -Multiple inheritance is used in the TCL. -Exceptions are supported via macros, which will smoothly become native exception handling when they introduce it in the compiler. -A large subset of the proposed Run-Time Type Identification (RTTI) standard is also implemented in macros. See section 13.5 in The C++ Programming Language, 2nd Ed. by Stroustrup for an explanation of the usefulness of RTTI, if you are unfamiliar with this. -A new feature called Object I/O provides an IOStream-based binary object reading/writing mechanism. -A new class called CSaver is built with Object I/O to provide persistence for documents, (e.g. window size and position are stored with saved documents auto-magically). -Apple Event support is now comprehensive: For example, the new TCL starter app, AEStarter, is now scriptable, recordable, has 15 Apple Events besides the Required Suite and 13 AE Classes. A few examples of the new Events and classes: move, delete, duplicate, close, application, character, document, file and word. Seems like a pretty nice base-line to me. 2) THINK Inspector - Anyone who has already been doing object-oriented programming will immediately recognize a new best friend. What we'd been doing already by a lot of dereferencing and typing is now handled in a smooth and user-friendly fashion by this application which can be launched from the THINK Debugger. Each Inspector window provides three panes: A Class pane, a Data pane and a Function pane. -By clicking on "::" in the Class pane you see your global functions. -By double-clicking on a function in the Function pane the debugger Code window goes to that function's code. -If you select a class name in the Class pane, the class's methods are displayed in the Function window and any current instances are displayed in the data window. -Objects displayed in the data window have a triangle... Which, when turned down, shows you the name and current value of the object's members. -If one of the object's members is itself an object, it also has a triangle. -One or more non-contiguous selections can be made of member data, which you can then bump over to the debugger's Data window... Though there is a slight bug with this and data members of type double, (it's reported and acknowledged by Symantec). -When an object is selected in the Inspector's Data window, you can have the Inspector go to the line of code that was responsible for allocating the object. (!) -By doing a "Select All" in the Class pane, ALL current objects will be displayed. Yes, that includes those that aren't pointed to by anything. (!!) -The Inspector is a user-interface triumph. There is NO typing at all in the Inspector, everything is clicked, using interface elements we already know and love. 3) Visual Architect- This application provides a resource building environment similar to ResEdit/AppMaker with the code generation capabilities I am familiar with from AppMaker. But it's a lot more powerful. Explicitly based on the TCL, it facilitates the derivation of new classes for custom interface elements/views. Basically, if you ObjectThink you'll love this application builder. A couple observations: -It is well integrated with the THINK Project Manager, even going so far as to close files that are open in the TPM which it is about to re-generate, (Apple Events begin to really pay off!). -Has double-file generation, like AppMaker, so that for each new class introduced there are two files generated, one for your custom code, (the higher-level file), one with code that is entirely written by the Visual Architect, (the lower-level file). -The lower-level files, which in AppMaker are called p-files for the p in the filename that denotes them, are denoted with a prepended "x_" by the Visual Architect which will undoubtedly lead to them being called the x files, (pun surely intended). -Has excellent Balloon Help support. -Has the usual stuff we expect from this sort of thing: a tear-off Tools menu, good Alignment support, drawing tools, etc. I've suffered as much as anyone with the buggy C++ 6.0 release. But all in all, this release is well on its way to restoring my faith. I think the Inspector, in particular, will really raise the bar on the sort of help we start to expect from our Macintosh development tools. I am Radical Liberation. +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sun, 10 Apr 1994 05:16:07 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) What are the new manuals like? John Nagle +++++++++++++++++++++++++++ >From radicallib@aol.com (RadicalLib) Date: 11 Apr 1994 02:55:05 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , nagle@netcom.com (John Nagle) writes: > What are the new manuals like? Very big. And quite improved. I was going through the tutorials to learn the Visual Architect and was having a fairly fun time. The section to help you begin to understand the TCL is much better than before, (I wish it had been there when I was trying to get over that initial learning hump). Otherwise, the new manuals are pretty much like the 6.0 manuals... even the same cover design. --------------------------- >From haney@maverick.llnl.gov (Scott W. Haney) Subject: Symantec technical support not home Date: 29 Mar 94 20:13:55 GMT Organization: Magnetic Fusion Energy - LLNL I received a flier from Symantec advertising C++ version 7.0 and had some problems parsing the marketing-speak description of the features. Foolishly thinking that they'd be happy to help out a long-time customer who was thinking about spending $250 on their products (7.0 upgrade + PPC kit), I thought I call them up to find out more about these features. I called there NON-toll-free number and, after listening to a long announcement about how they were going to start charging me for technical support, I got a person who the phone menu said knew about "product information". Unfortunately, the "product information" I asked for was too specific so they said I must talk to technical support. I asked if they could transfer me and they said they couldn't. OK, I called the number again and listend to the long message and chose the technical support option. I stayed on hold for 30 minutes (yes you read that right) and never got to talk to a person (although I did get to listen to a lot of elevator music and hear the message "your phone call is very important to us" about 200 times). I called back customer support and calmly explained that I couldn't get through to customer support so could I leave a number so they could get back to me. I was informed that with the new "fee-for-support" plan, they never did call-backs, even to give information to potential customers. I then asked the customer support rep. what I should do to get my question answered and she said my only option was to talk to technical support. Since I had already, I thought, made a reasonable attempt to do this I asked to talk to her supervisor. Unfortunately, he was at lunch. I asked if I could leave my number for him to call me back. She said he wouldn't call me back and reminded me that they offer a 60 day money back guarantee, so why didn't I just buy the product and if it didn't have the features I needed I could get a refund. Remaining calm, I said that I wouldn't do business with Symantec under these circumstances. She said she was sorry to hear that but there was nothing she could do. I've seen Symantec get flamed almost continuously for the past several months and, quite frankly, I thought some of it was a bit unfair. However, this experience has left me feeling that the company doesn't really care very much about keeping customers. In particular, I've never before had a company make me jump through hoops in order to get info about a product. I'm fairly close to deciding not to give Symantec any more of my business. However, I'm willing to grant that I hit a bad day in technical support land and give Symantec another chance. Therefore, I wonder if someone from Symantec could contact me via email to answer a few brief questions about the THINK Project Manager. Scott -- - ----------------------------------------------------------------------- Scott W. Haney || Lawrence Livermore N'Lab || The above views are haney@random.llnl.gov || P.O. Box 808; L-637 || mine and not neces- (510) 423-6308 || Livermore, CA 94550 || sarily LLNL's. +++++++++++++++++++++++++++ >From sbill@informix.com (Bill Stackhouse) Date: 29 Mar 1994 23:39:37 GMT Organization: Informix Software, Inc. In article haney@maverick.llnl.gov (Scott W. Haney) writes: > I received a flier from Symantec advertising C++ version 7.0 and had >some problems parsing the marketing-speak description of the features. >Foolishly thinking that they'd be happy to help out a long-time >customer who was thinking about spending $250 on their products (7.0 >upgrade + PPC kit), I thought I call them up to find out more about >these features. I called there NON-toll-free number and, after [bunch of complaints deleted] Phil Shapiro is a great resource and always gets a response back to me in short order. His email address is phils@bedford.symantec.com If you read the programming group, you know about Phil. You should have tried him first since you probably knew that your questions were more technical than could be answered by a sales person. Did you do that just to have a reason to complain? Yes they handled the call very badly and I would have been pissed off. If you had had a real technical support question and not a sales question I bet you could have gotten it answered. If you have been a Think C user, you have a good feel for what any version of Think C will look like. The 60 day MBG is a great way to test drive the new version if you have some nagging unanswered questions. It sounds like the person handled that part correctly given that tech support was not an option and this person did not have an answer for you. May be she/he should have but they did not. They probably get 100's of calls a day and many of them from people that probably never planned to buy. They have to make a business decission about how to allocate their dollars. Faning the flames does not help anyone. If you don't like Symantec then you just don't like them. There are many people who still do. Except for some C++ bugs, Think C is still a great product. Again, give Phil some direct questions and see if that helps. Flame me if you want, I will not listen. I am tired of the petty complaints over the upgrage fees and what a bad product Think C has become. $150/$250 is cheap if you are doing real development and if you are just playing around, then stick with version 6. There are some of us that have to have one of each compiler so that the others can have development tools. Bill +++++++++++++++++++++++++++ >From mahboud@aggroup.com (mahboud) Date: Tue, 29 Mar 1994 16:26:38 -0800 Organization: AG Group, Inc. In article , haney@maverick.llnl.gov (Scott W. Haney) wrote: > [description of hellish phone experience] > Scott > > Scott, please let us know what you find out. I am tempted to go through and print out all the flames and mail them to Symantec. Maybe that'll wake them up. I have had similar experience with calling Symantec. I had a profiler problem with THINK C and after being on the phone for quite a long time, the person answering couldn't help me (he read me some passages out of the manual!) and told me that there is no one there who know much about the profiler. And they expect us to start paying for this sort of service?? -mahboud - ------------------------------------------------------------- Mahboud Zabetian mahboud@aggroup.com ag group, inc. 2540 camino diablo, suite 200 walnut creek, ca 94596 510-937-7900 voice 510-937-2479 fax 510-937-6704 ara ftp.aggroup.com anonymous ftp +++++++++++++++++++++++++++ >From howard@netcom.com (Howard Berkey) Date: Wed, 30 Mar 1994 04:57:09 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) In article haney@maverick.llnl.gov (Scott W. Haney) writes: [unfortunately typical tale of Symantec phone support woe deleted] > I've seen Symantec get flamed almost continuously for the past several months >and, quite frankly, I thought some of it was a bit unfair. However, this >experience has left me feeling that the company doesn't really care very >much about keeping customers. In particular, I've never before had a company >make me jump through hoops in order to get info about a product. While your story is pretty ugly, and indeed I'm saddened (but not surprised) to hear that Symantec is now charging for tech support on a product which (in general) requires it to some extent, all I can say is if you think that was bad try dealing with IBM sales sometime. At work I had to talk to a salesman for 30 minutes once just trying to convince him that I had a RS/6000 when all I wanted to buy was an OS upgrade or something similar. The conversation went something like: Sales droid: "I'm veree sorree, all we show at your site are AS/400 computers." Me: "Trust me. I develop on this RS/6000 for a living. Here's what uname -a says. Here's the serial number. [etc]". Sales droid: "Please hold." (5 mins later) Droid: "I'm veree sorree..." That went on for a half hr. until he got ahold of our regular sales rep. So good luck with Symantec... at least they believe you when you call :-) -H- -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Howard Berkey howard@netcom.com Kill the Wabbit! +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 30 Mar 1994 07:53:19 GMT Organization: The Royal Institute of Technology In haney@maverick.llnl.gov (Scott W. Haney) writes: > I'm fairly close to deciding not to give Symantec any more of my business. >However, I'm willing to grant that I hit a bad day in technical support land >and give Symantec another chance. Therefore, I wonder if someone from Symantec Actually, I think you hit the bad product for Symantec. Symantec should be selling word processors, mail applications and project organization chart drawing programs, not development tools. They should separate out development tools into a whole subsidiary company, with its OWN support channels, management, marketing budget, ... That's about the only way they can believably stay at the forefront of the tools business. -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- Not speaking for the Liberian Government. +++++++++++++++++++++++++++ >From d88-jwa@mumrik.nada.kth.se (Jon Wätte) Date: 30 Mar 1994 07:56:09 GMT Organization: The Royal Institute of Technology In <2nae7p$5bg@infmx.informix.com> sbill@informix.com (Bill Stackhouse) writes: >Phil Shapiro is a great resource and always gets a response back to me >in short order. His email address is phils@bedford.symantec.com If you >Again, give Phil some direct questions and see if that helps. I would say DON'T. Phil works on the compiler. He has better things to do than answering technical support letters. The only time I sent a direct letter was regarding some reproducible bug in the compiler which didn't quite make it through the normal tech support channels. -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- Not speaking for the Liberian Government. +++++++++++++++++++++++++++ >From haney@maverick.llnl.gov (Scott W. Haney) Date: 30 Mar 94 16:42:03 GMT Organization: Magnetic Fusion Energy - LLNL sbill@informix.com (Bill Stackhouse) writes: >In article haney@maverick.llnl.gov (Scott W. Haney) writes: >> I received a flier from Symantec advertising C++ version 7.0 and had >>some problems parsing the marketing-speak description of the features. >>Foolishly thinking that they'd be happy to help out a long-time >>customer who was thinking about spending $250 on their products (7.0 >>upgrade + PPC kit), I thought I call them up to find out more about >>these features. I called there NON-toll-free number and, after >[bunch of complaints deleted] >Phil Shapiro is a great resource and always gets a response back to me >in short order. His email address is phils@bedford.symantec.com If you >read the programming group, you know about Phil. You should have tried >him first since you probably knew that your questions were more >technical than could be answered by a sales person. Did you do that just >to have a reason to complain? Bill, I think you misunderstood my message. Let me explain. Over the past few years I *have* sent mail, usually from CompuServe, to people at Symantec, including Phil Shapiro. Generally, I did not receive a reply. The messages were generally questions or comments, written civilly. I don't hold the lack of replies against Symantec, I simply determined that this was not a good way to get my questions answered. Apparently your experience has been different. Fair enough. Second, I spent 1/2 on hold waiting for TECHNICAL support. Contrary to your assertion, they were the correct people to answer my question. Furthermore, they have promptly answered this sort of question for me in the past. Third, I called Symantec with the inclination to plunk down $250 bucks on the 7.0+PPC upgrade. Believe me, I have much better things to do with my time than sit on the phone for an hour listening to music. Symantec would have my order now if I could have simply talked to a person who was willing to get about 5 minutes of technical questions answered. >Yes they handled the call very badly and I would have been pissed off. >If you had had a real technical support question and not a sales question >I bet you could have gotten it answered. I called the Technical support line three times. When you call Symantec Technical Support you go through a phone menu in order to have your call directed. The 1st time I called I chose customer service (option 2). I was told they only knew general information. They said to call technical support. Fair enough. I then called again and chose technical support (option 4). I then waited 1/2 hour ON HOLD before I hung up. I never talked to a human. My call was not screened. I then called customer service, told them I couldn't get through. I was basically told that my only two options were to buy the product or to try technical support again. They wouldn't even take my number to call me back when things had calmed down. I've been dealing with computer companies for many years and have never run into this. Heck, people from Symantec have called me back in the past. >If you have been a Think C user, you have a good feel for what any >version of Think C will look like. The 60 day MBG is a great way to >test drive the new version if you have some nagging unanswered >questions. It sounds like the person handled that part correctly given >that tech support was not an option and this person did not have an >answer for you. May be she/he should have but they did not. They >probably get 100's of calls a day and many of them from people that >probably never planned to buy. They have to make a business decission >about how to allocate their dollars. I think you've missed the point. I couldn't talk to people that Symantec said would answer my questions. I made, I think, a reasonable attempt to do this. Or are you saying I should haved stayed on hold for longer than a half hour. >Faning the flames does not help anyone. If you don't like Symantec >then you just don't like them. There are many people who still do. >Except for some C++ bugs, Think C is still a great product. Actually, I do like Symantec. I've spent lots of money with them in the past and recommended their products to others. I was getting ready to spend more money with them. You're clearly misreading my motives. I was puzzled by this episode, plus a little pissed off. I can't believe you'd feel any different if it happened to you. >Again, give Phil some direct questions and see if that helps. >Flame me if you want, I will not listen. I am tired of the petty >complaints over the upgrage fees and what a bad product Think C >has become. $150/$250 is cheap if you are doing real development >and if you are just playing around, then stick with version 6. >There are some of us that have to have one of each compiler so that >the others can have development tools. I don't intend to flame you. However, I hope you will listen to what I am actually saying rather than reading in stuff based on other people's posts. For instance, I never complained about the fee. I also explicitly said that I may have hit a bad day for technical support and was willing to give Symantec the benefit of the doubt. You should have read my message as an invitation to Symantec to try to set things right with a long-time customer who was, for whatever reason, treated very poorly. Symantec has taken me up on this invitation: I just got a mail message Tom Emerson of Symantec saying he would answer my questions. Scott >Bill -- - ----------------------------------------------------------------------- Scott W. Haney || Lawrence Livermore N'Lab || The above views are haney@random.llnl.gov || P.O. Box 808; L-637 || mine and not neces- (510) 423-6308 || Livermore, CA 94550 || sarily LLNL's. +++++++++++++++++++++++++++ >From Chris Russo Date: 30 Mar 1994 21:45:50 GMT Organization: Sonic Systems, Inc. In article <2nae7p$5bg@infmx.informix.com> Bill Stackhouse, sbill@informix.com writes: >In article haney@maverick.llnl.gov (Scott W. Haney) writes: >> I received a flier from Symantec advertising C++ version 7.0 and had >>some problems parsing the marketing-speak description of the features. >>Foolishly thinking that they'd be happy to help out a long-time >>customer who was thinking about spending $250 on their products (7.0 >>upgrade + PPC kit), I thought I call them up to find out more about >>these features. I called there NON-toll-free number and, after > >[bunch of complaints deleted] > >Phil Shapiro is a great resource and always gets a response back to me >in short order. His email address is phils@bedford.symantec.com If you >read the programming group, you know about Phil. You should have tried >him first since you probably knew that your questions were more >technical than could be answered by a sales person. Did you do that just >to have a reason to complain? Bill, I don't think that you're being very fair with Scott. The internet, albeit an awesome resource, should not be a developer's only option when confronted with a technical support problem. Just as a reality-check, Scott, I had a problem VERY similar to the one you had. I wanted to call Symantec to report a few Source Server bugs and to find out when the next revision was due. After resolving the phone alias that they give you in the manual, I waited on hold for _45_ minutes!! Long distance, no less. If it were an 800 number, I could maybe understand; but not even offering some type of callback service was a bit much. After I got through to the tech support guy, I received only further frustration. He didn't know anything about ANY of the bugs that I was wondering about. "Uh, we haven't encountered that one." Yeah, right. They only happen on several of our machines here with only BASIC use of the Source Server stuff. >Yes they handled the call very badly and I would have been pissed off. >If you had had a real technical support question and not a sales question >I bet you could have gotten it answered. Well, I can say that I wasn't given any satisfactory answer. I consider my Technonsupport experience with Symantec to have been a total waste of my time and my company's money. I don't plan on going through it again in the future. >If you have been a Think C user, you have a good feel for what any >version of Think C will look like. The 60 day MBG is a great way to >test drive the new version if you have some nagging unanswered >questions. It sounds like the person handled that part correctly given >that tech support was not an option and this person did not have an >answer for you. May be she/he should have but they did not. They >probably get 100's of calls a day and many of them from people that >probably never planned to buy. They have to make a business decission >about how to allocate their dollars. And WE have to make business decisions about how to handle ours. I wish I would have paid more attention to the net in the first place, and I appreciate real life experiences as related by Scott Haney. They help me to make choices. The only better teacher than experience is other peoples' experience. >Faning the flames does not help anyone. If you don't like Symantec >then you just don't like them. There are many people who still do. >Except for some C++ bugs, Think C is still a great product. Once again, I appreciate reports like Scott's. I don't think that he was trying to fan any flames. He was just trying to warn others by relating his personal experiences. There are many people out there who value good technical support over other features of a product. He might be saving those people a lot of frustration. >Again, give Phil some direct questions and see if that helps. > >Flame me if you want, I will not listen. I am tired of the petty >complaints over the upgrage fees and what a bad product Think C >has become. $150/$250 is cheap if you are doing real development >and if you are just playing around, then stick with version 6. >There are some of us that have to have one of each compiler so that >the others can have development tools. > >Bill I, for one, don't consider his _complaints_ to be petty. Chris Russo Chris Russo Macintosh Software Developer Sonic Systems, Inc. (408) 736-1900 Ext #107 Sunnyvale, California, US +++++++++++++++++++++++++++ >From Joe Francis Date: 31 Mar 1994 01:28:50 GMT Organization: Smooth Roo Software Bill Stackhouse, sbill@informix.com writes: > Phil Shapiro is a great resource and always gets a response back to me > in short order. His email address is phils@bedford.symantec.com If you > read the programming group, you know about Phil. You should have tried > him first since you probably knew that your questions were more > technical than could be answered by a sales person. I think you need to rent a clue. When you have technical questions about a product, sales and/or tech support are the people in the business of answering your questions. Bugging the product engineers to do, on their own time, what the support staff is paid to do, is not the correct solution. > Did you do that just to have a reason to complain? Did you write this just to get flamed? - ------------------------------------------------------------------------ No matter how subtle the wizard, a knife between the shoulder blades will seriously cramp his style. - ------------------------------------------------------------------------ +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Wed, 30 Mar 1994 16:02:27 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA sbill@informix.com (Bill Stackhouse) writes: > Yes they handled the call very badly and I would have been pissed off. > If you had had a real technical support question and not a sales > question I bet you could have gotten it answered. Rule Number One of Commercial Software: Do not piss off the customers. Rule Number Two: See Rule Number One. It doesn't matter if he was calling about the color of the box; Symantec should have enough people to answer their phones. There's more to selling software than making pretty yellow boxes, after all. > $150/$250 is cheap if you are doing real development and if > you are just playing around, then stick with version 6. Or just chuck it and use MPW... Amanda Walker InterCon Systems Corporation -- "Ah, prune juice: a warrior's drink." -- Star Trek: The Next Generation +++++++++++++++++++++++++++ >From philip@cs.wits.ac.za (Philip Machanick) Date: Mon, 04 Apr 1994 15:29:40 +0200 Organization: Computer Science Dept, U of Witwatersrand In article <2nbb5f$i0f@news.kth.se>, d88-jwa@mumrik.nada.kth.se (Jon Wtte) wrote: > Actually, I think you hit the bad product for Symantec. > Symantec should be selling word processors, mail applications > and project organization chart drawing programs, not development > tools. They should separate out development tools into a whole > subsidiary company, with its OWN support channels, management, > marketing budget, ... > > That's about the only way they can believably stay at the forefront > of the tools business. It seems they did do this, only they didn't think to maintain a financial interest in the new company - isn't a large chunk of the Metrowerks Codewarrior project based on ex-Symantec people? -- Philip Machanick philip@cs.wits.ac.za Department of Computer Science, University of the Witwatersrand 2050 Wits, South Africa phone 27(11)716-3309 fax 27(11)339-7965 +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Mon, 4 Apr 1994 19:56:14 GMT Organization: The World Public Access UNIX, Brookline, MA >It seems they did do this, only they didn't think to maintain a financial >interest in the new company - isn't a large chunk of the Metrowerks >Codewarrior project based on ex-Symantec people? Actually, there are only 3 ex-Symantec employees at Metrowerks, plus Greg Dow who did the TCL on contract for Symantec. Metrowerks itself has quite a few more people than that. -- John +++++++++++++++++++++++++++ >From Stuart Cheshire Date: 9 Apr 1994 16:47:29 GMT Organization: Stanford University In article John McEnerney, johnmce@world.std.com writes: >Actually, there are only 3 ex-Symantec employees at Metrowerks Yeah, but WHICH three? Stuart Cheshire * WWW * Stanford Distributed Systems Group Research Assistant * Escondido Village Resident Computer Coordinator * Macintosh Programmer --------------------------- >From interealm@aol.com (Interealm) Subject: System 7 Pro & Drag Mgr. Date: 2 Apr 1994 11:53:04 -0500 Organization: America Online, Inc. (1-800-827-6364) Hi... Can someone tell me what version of the Finder ships with System 7 Pro and whether or not Sys7Pro comes stock with built in Drag Manager Support from the Finder? Thanks in advance... Jack +++++++++++++++++++++++++++ >From gdl@stlawrence.maths (Greg Landweber) Date: 04 Apr 1994 22:15:41 GMT Organization: (none) In article <2nk7tg$nvk@search01.news.aol.com> interealm@aol.com (Interealm) writes: Can someone tell me what version of the Finder ships with System 7 Pro and whether or not Sys7Pro comes stock with built in Drag Manager Support from the Finder? System 7 Pro uses Finder 7.1.3, which supports the drag manager if the Drag Manager is present. System 7 Pro contains a limited version of the Drag Manager which is used by Finder 7.1.3, but it cannot be used by any other application. If you want other applications to support drag manager features, you need the "Macintosh Drag and Drop" extension. -- Greg "Browser" Landweber gdl@maths.ox.ac.uk +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 5 Apr 94 13:00:13 +1300 Organization: University of Waikato, Hamilton, New Zealand In article <2nk7tg$nvk@search01.news.aol.com>, interealm@aol.com (Interealm) writes: > > Can someone tell me what version of the Finder ships with System 7 Pro and > whether or not Sys7Pro comes stock with built in Drag Manager Support from the > Finder? System 7 Pro comes with Finder 7.1.3. This is the same version that supports the Drag Manager Clipping Extension, Finder scripting, and QuickDraw GX beta 3. By the way, the Power Macs come with Finder 7.1.4. System 7 Pro has some kind of built-in Drag Manager, but I don't think the API for that is available to ordinary mortals--you still need to install the Drag Manager extension to get the public API. That built-in Drag Manager is interesting: it lets you drag stuff about in Finder windows without bringing the Finder to the front--not until you let go the mouse button. Lawrence (trying to think of an excuse for wanting that feature in my own programs :-)) +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 7 Apr 1994 00:51:21 GMT Organization: Apple Computer Lawrence D'Oliveiro, ldo@waikato.ac.nz writes: > That built-in Drag Manager is interesting: it lets you drag stuff about > in Finder windows without bringing the Finder to the front--not until you let > go the mouse button. > > Lawrence > (trying to think of an excuse for wanting that feature in my own programs :-)) This is the preferred HI for draggable apps. You want to be able to drag something from a background window without having that window immediately come to the front and obscure your intended destination. Finder 7.0 fixed this for the Finder->Finder drag situation, and with the Drag Manager they've generalized it into an HI guideline for all apps. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world --------------------------- >From mjg001@acad.drake.edu Subject: Using PBCatSearch Date: Tue, 5 Apr 1994 21:18:19 GMT Organization: Drake University, Des Moines, Iowa, USA I seem to be having a problem with a difference between the described record in IM and what I actually find in the C interface libraries for the Mac. Let me explain. I'm trying to access a field in a struct of CInfoPBRec, I'm trying to access the ioNamePtr field in the record by using a CInfoPBPtr. The problem is that whenever I compile the compiler says that there is no such member in that struct. I looked in the C interface libraries for THINK C and found that there is no ioNamePtr in the struct CInfoPBRec like described in IM. I'm trying to search a disk using PBCatSearch() and this is where I have ended up. If you have any code or examples for this in C then please send them to me. Thanks for any help. -Mike +++++++++++++++++++++++++++ >From greer@utdallas.edu (Dale M. Greer) Date: 5 Apr 1994 21:39:04 GMT Organization: The University of Texas at Dallas mjg001@acad.drake.edu wrote: > I seem to be having a problem with a difference between the described > record in IM and what I actually find in the C interface libraries for the > Mac. Let me explain. I'm trying to access a field in a struct of CInfoPBRec, > I'm trying to access the ioNamePtr field in the record by using a CInfoPBPtr. > The problem is that whenever I compile the compiler says that there is no > such member in that struct. I looked in the C interface libraries for THINK > C and found that there is no ioNamePtr in the struct CInfoPBRec like > described in IM. > I'm trying to search a disk using PBCatSearch() and this is where I have ended > up. If you have any code or examples for this in C then please send them > to me. Thanks for any help. I found an example of using PBCatSearch at ftp.apple.com. It looks for a file by Type and Creator. Once it finds the file, the name is in csBlockPtr->ioMatchPtr[0].name. Before searching, the field csBlockPtr->ioSearchInfo1->hFileInfo.ioNamePtr is set to nil. The structure csBlockPtr is a CSParamPtr. CInfoPBPtr begins with an HFileInfo, which in turn begins with a ParamBlockHeader which also contains an ioNamePtr. I can send you the DTS PBCatSearch example or post it if you don't have access to ftp.apple.com. -- Dale Greer, greer@utdallas.edu +++++++++++++++++++++++++++ >From allon@intercon.com (Allon Stern) Date: Tue, 5 Apr 1994 23:51:31 -0400 Organization: InterCon Systems Corporation, Herndon VA. In article <2nslpo$fga@news.utdallas.edu>, greer@utdallas.edu (Dale M. Greer) writes: > mjg001@acad.drake.edu wrote: > > I'm trying to search a disk using PBCatSearch() and this is where I > > have ended up. If you have any code or examples for this in C then > > please send them to me. Thanks for any help. > > I found an example of using PBCatSearch at ftp.apple.com. It looks for > a file by Type and Creator. Once it finds the file, the name > is in csBlockPtr->ioMatchPtr[0].name. Before searching, the field > csBlockPtr->ioSearchInfo1->hFileInfo.ioNamePtr is set to nil. The > structure csBlockPtr is a CSParamPtr. CInfoPBPtr begins with an > HFileInfo, which in turn begins with a ParamBlockHeader which > also contains an ioNamePtr. When writing your code, keep in mind that not all volumes support PBCatSearch. The proper way to check to see if it is supported is to call PBHGetVolParams and check the appropriate bit (bHasCatSearch = 7). Reference: IM-Files pages 2-147 through 2-150 Also, on page 2-205 of IM-Files, it states: "Not all volumes support the PBCatSearch function [...] even though AFP volumes support PBCatSearch, they do not support all of its features that are available on local volumes." In other words, your mileage may vary 8^) -- Allon | Allon Stern | 703-709-5557 | Ring around the Internet | | allon@intercon.com | KE4FYL | A packet with a bit not set | +--------------------+--------------+ ENQ ACK ENQ ACK | | All opinions above are my own. | We all go down! | |------------------------------------------------------------------| +++++++++++++++++++++++++++ >From blob@apple.com (Brian Bechtel) Date: 9 Apr 1994 17:48:49 -0700 Organization: Apple Computer, Inc., Cupertino, California mjg001@acad.drake.edu writes: >I'm trying to search a disk using PBCatSearch() and this is where I have ended >up. If you have any code or examples for this in C then please send them >to me. Thanks for any help. ftp://ftp.apple.com/dts/mac/sc/morefiles.1.1.1.hqx contains excellent sample code for using PBCatSearch, among other functions. --Brian Bechtel blob@apple.com "My opinion, not Apple's" --------------------------- End of C.S.M.P. Digest **********************