Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Message-ID: <6590126@hplsla.HP.COM>
Date: 15 May 89 16:35:35 GMT
References: <904@garya.Solbourne.COM>
Organization: HP Lake Stevens, WA
Lines: 88

> If you are really getting hassled for simply trying to get some facts
> about cfront 2.0 out in the broad daylight, then that is obviously a
> travesty.  I am reminded of the DoD's tendency to cloak even the most
> innocent research in secrecy.  I believe that many uproars have been
> caused by the DoD barring foreigners from various conferences, etc.
> The uproar comes when people realize that a free flow of information
> is one of the fundamental ingredients of progress.  I believe that
> that applies to C++ as well.

Well, again, my frustration is that AT&T people are able to comment
openly on 2.0, and I'm not.  I can appreciate that company's have
many legitimate and illigitamate reasons to keep new product
releases quiet, but to have AT&T people be able to comment, and not
I, I find frustrating.  Either the cat in the bag, or out of the bag --
but halfway is too wierd.  Not to imply 2.0 was ever *in* the bag.

Regards "free flow of information," I feel once 2.0 is discussed on notes,
then I should be free to discuss it too.  But I haven't gotten permission
to do so.  And so since I don't like being stomped on, I feel this
continuing frustration of not being to speak freely.

I continue to believe that the main source of this problem is a
failure to cleanly differentiate between C++ *the language* and
C++ *vendor XYZ's product*.
 
> >When 2.0 does comes out, how are people going to know what it can,
> >or can't do?
> 
> Try it!  Then post your results here.  I'm sure that a lot of us
> (me especially) would like to see some good test cases posted
> here which show either things that do work or things that don't.

I'm getting sick and tired trying to reverse engineer C++ compilers --
including g++.  [By reverse engineer I mean trying to understand
what kind of code its going to produce in various situations.]
Does the language include such-a-such?  Write code
to try it.  Then unscamble the so-called "C" code that the AT&T
compiler produces.  Or stare at the assembly g++ produces.  Did
you make a mistake in your coding?  Does the compiler have a bug?
Is this an unimplemented feature?  Did you misunderstand that feature
of the language?  Can you mentally uncipher the name encodings used?
Is this a "feature" of the language or the compiler you're fighting with.
Etc, etc, etc.

Wouldn't it be easier if compiler writers just wrote a 20 page user's guide
that states how their compilers handles various major issues in C++?
In-line functions? Virtual functions? Name encoding?  Operator overloading?
etc?  Multiple inheritence? Parameterized classes? .....Rather than forcing 
each user to try to reverse engineer these things on each compiler on each 
new release? 
 
> Does HP publish such lists for its own software products?  I think
> not.  Let he who is without sin cast the first stone.  In general,
> I expect hell to freeze over before total honesty with customers
> becomes the norm in the software end of the business.

There certainly are some such lists for some such software products.
If anyone needs any information on HP products, I, among many others,
will do their best to get it for you.  My phone number is (206)-335-2138.

But, I cannot pretend to represent HP.  I am one person in 100,000.
Gnu people seem to confuse individuals with the companies they work
for.  Which is strange -- at least unless those individuals confuse 
themselves with the company they work for.  The above is not to imply
I'm satisfied with the way HP does business.  I'm not.  For example,
I'd like HP to support C++ directly....

If we waited for people without sin to throw the first stone, there
would be no notes discussions.  Total honesty is like the skins of an 
onion.  I do not see software as more dishonest than other businesses.
Like real estate :-)

> >Or are customers expected to buy a pig in a poke?
> 
> No. If you think that you are being mislead I suggest that you *not*
> buy the product.

I look forward to the day when I can get "complete" C++ compilers from
a dozen vendors.  Presently my two choices are from AT&T and Gnu.
Which sometimes feels like getting stuck between a rock and a hard 
place.  No matter whose compiler I use I am forced to "buy" into
learning it, and "reverse engineering it."  Which is the true cost.

I trust C++ *the language* and feel it is headed in the right direction.

I feel frustrated by C++ *the vendor XYZ's product* [incl Gnu], which are
not well enough supported for my tastes.  Recent software reviews seem
to echo these frustrations.