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 <spie0024@student.tc.umn.edu>
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 <CnKMty.Eq2@news.cis.umn.edu>, Spiegs
<spie0024@student.tc.umn.edu> 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 <spie0024@student.tc.umn.edu> 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-060494112236@mac-13.cs.strath.ac.uk>, 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 <fujimoto+@CMU.EDU>
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 <Mhd4DcG00Vpg0xEWYf@andrew.cmu.edu>, Shinya Fujimoto
<fujimoto+@CMU.EDU> 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 <Mhd4DcG00Vpg0xEWYf@andrew.cmu.edu>, Shinya Fujimoto
<fujimoto+@CMU.EDU> 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 <rae@alias.com>
Date: Sun, 10 Apr 1994 01:51:37 GMT
Organization: Alias Research, Inc., Toronto ON Canada
Shinya Fujimoto <fujimoto+@CMU.EDU> 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 <alex@metcalf.demon.co.uk> 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 <rae@Alias.com>
+++++++++++++++++++++++++++
>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 <rae@alias.com>
wrote:
> Shinya Fujimoto <fujimoto+@CMU.EDU> 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 <alex@metcalf.demon.co.uk> 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 <strull@apple.com>
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-030494071250@rmah.dialup.access.net> 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.765402948@graceland.att.com>, pjl@graceland.att.com (Paul J. Lucas) writes:
> In <rmah-030494071250@rmah.dialup.access.net> 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.94Apr3235100@yggdrasil.ethz.ch> neeri@iis.ee.ethz.ch (Matthias Neeracher) writes:
>In article <pjl.765402948@graceland.att.com>, pjl@graceland.att.com (Paul J. Lucas) writes:
>> In <rmah-030494071250@rmah.dialup.access.net> 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.765412961@graceland.att.com>, pjl@graceland.att.com (Paul J. Lucas) writes:
> In <NEERI.94Apr3235100@yggdrasil.ethz.ch> neeri@iis.ee.ethz.ch (Matthias Neeracher) writes:
>>In article <pjl.765402948@graceland.att.com>, pjl@graceland.att.com (Paul J. Lucas) writes:
>>> In <rmah-030494071250@rmah.dialup.access.net> 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.765412961@graceland.att.com> pjl@graceland.att.com
(Paul J. Lucas) writes:
|> In <NEERI.94Apr3235100@yggdrasil.ethz.ch> neeri@iis.ee.ethz.ch (Matthias Neeracher) writes:
|> >In article <pjl.765402948@graceland.att.com>, pjl@graceland.att.com (Paul J. Lucas) writes:
|> >> In <rmah-030494071250@rmah.dialup.access.net> 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 <rae@alias.com>
Date: Sat, 9 Apr 1994 21:17:33 GMT
Organization: Alias Research, Inc., Toronto ON Canada
Robert 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.
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 <rae@Alias.com>
---------------------------
>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 <nagleCo12Mv.Irs@netcom.com>, 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.764972035@maverick> 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.764972035@maverick>, 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.764972035@maverick> 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!
+++++++++++++++++++++++++++