Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!rutgers!att!cbnews!mjs
From: mjs@cbnews.ATT.COM (martin.j.shannon)
Newsgroups: comp.lang.c++
Subject: Vendor X (Was Re: address of virtual function (revisited))
Message-ID: <6693@cbnews.ATT.COM>
Date: 18 May 89 18:14:09 GMT
References: <904@garya.Solbourne.COM> <6590127@hplsla.HP.COM>
Reply-To: mjs@cbnews.ATT.COM (martin.j.shannon)
Organization: AT&T Bell Laboratories
Lines: 42

In article <6590127@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>(Lost attribution here, sorry. -mjs)
>> The folks from AT&T have stated, in this newsgroup, on several
>> occasions, that they are working on a complete reference manual for
>> C++, intended to provide a full specification of the language.  They
>> already know that such a thing is urgently needed; it won't do any
>> good to keep reminding them.  I'm as eager to receive a final and
>> complete spec as everyone else, but I understand that these things are
>> quite a lot of work, and they take time.
>
>I'm not talking about a complete up-to-date language reference -- although
>g*d knows we need such a thing.  I'm talking about a reference on how
>a *compiler* "works" -- what kind of code it generates, and why, in
>a variety of situations?  And what are its limitations, where does it
>fail to generate code?  The areas I listed before are what confuses me
>the most about existing compilers -- also how they handle automatic
>generation of functions to handle assignment, initialization, how temporaries
>are handled etc.

Although I sympathize with Jim's position to some extent, my experience in
using commercial software products is that *most* companies specifically
refuse to make any claims about most of what Jim is asking for.  And, I have
come to believe that their refusal is probably a good thing.  It gives them
the flexibility to make changes to their product that they couldn't make if
they'd already made a claim that "property X is true of our product", where
property X is an "internal property" of the product (which customers are
thereby prevented from depending on), and typically is implemented by a set
of heuristics.

I've *never* in my 15+ years of using commercial computer software seen a
compiler vendor state "here are the (valid according to the specification
of the language) conditions under which our compiler emits wrong code/
provides a core dump (//SYSABEND DD SYSOUT=A)/rejects code inappropriately".

Yes, it would be nice to see such statements.
No, it is not reasonable to expect them.

(Did Ford Pinto's have labels on their rear bumpers?)

-- 
Marty Shannon; AT&T Bell Labs; Liberty Corner, NJ
(Affiliation given for identification only.)