Path: utzoo!attcan!uunet!odi!valens!dlw
From: dlw@valens.odi.com (Dan Weinreb)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Message-ID: <328@odi.ODI.COM>
Date: 16 May 89 19:02:01 GMT
References: <904@garya.Solbourne.COM> <6590126@hplsla.HP.COM>
Sender: news@odi.com
Lines: 39
In-reply-to: jima@hplsla.HP.COM's message of 15 May 89 16:35:35 GMT

In article <6590126@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:

   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? 

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

Yes, the state of things right at the moment is not very good for the
present users; things are still young, and the users are still
pioneers to some extent.  I think most of us are using C++ because we
are reasonably confident that the vendors intend to put in the effort
to stabilize the language definition, and produce compilers and other
tools that will be mature and well-debugged.

The user community should try to provide criticism and feedback that
is productive and useful to the implementors, such as specific bug
reports, feedback about what language features seem to be particularly
confusing or troublesome, indications of what needs users have that
are not being fulfilled by the present language/compiler, etc.  That's
the best way we can encourage them, and help them produce the
high-quality product that we're all looking forward to.

Dan Weinreb     Object Design, Inc.     dlw@odi.com