Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Vendor X (Was Re: address of virtual function (revisited))
Message-ID: <6590129@hplsla.HP.COM>
Date: 19 May 89 19:51:26 GMT
References: <6693@cbnews.ATT.COM>
Organization: HP Lake Stevens, WA
Lines: 47

> >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?)

I didn't realize you guys were making Ford Pintos.  I had hoped you were in
the process of developing a quality product!

A vendor's failure to provide critical information on a product to its potential
customer just lowers that vendor's credibility, and forces a customer to get
the information by other means.

As I, and others, continue to "reverse engineer" the AT&T product -- finding out
what code it generates, when, and when not, you can be sure we will share this
information over notes.  This will be especially important when 2.0 comes
out -- with all its new capabilities, and limitations.  If AT&T took the lead 
in presenting this information, AT&T could present this information from AT&T's 
standpoint -- perhaps giving a positive "spin" to it.  When you force others 
to find out this information the hard way -- chances are the information is
going to be presented in a negative fashion.

Not to mention the time you force us to waste in duplicating information AT&T
already knows.