[comp.lang.c++] Vendor X

mjs@cbnews.ATT.COM (martin.j.shannon) (05/19/89)

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

jima@hplsla.HP.COM (Jim Adcock) (05/20/89)

> >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.