Re: RFA: Deprecate C++ options

[George Garvey <tmwg at inxservices dot com>]

On Fri, Sep 07, 2001 at 09:02:43AM -0700, Mark Mitchell wrote:
> There's no need to be sarcastic.  If you don't like Nathan's proposal,
> just say so.

   Its an expression of frustruation. Whether its necessary or not you've
now told me, and I apologize for tastelessly expressing the way I see it.
   What I really object to is one person stating the consequences for
thousands of people unknown to that one, rather than asking. Yes, I know,
Nathan asked.

> Would you rather have support for these old constructs, or other
> improvements to the compiler, including better support for the lanaguage
> as specified in the standard, better optimizations, and (especially)
> fewer bugs?

   I can't answer that, since I've now been informed its an either/or. I
don't know:
      1. The degree of effort required, due to no personal experience on
         this particular subject;
      2. The man-power available; for the same reason.
So I would not trust any decision I made.
   Were this a project I were personally developing; and I came across this
problem; and saw that it could not be done: I would question the design of
the system I was working on.
   I'm not saying its not good, but I'd certainly question it and get the
answer to whether it has an intrinsic design flaw since it can't support
continuing the feature easily. That's is the first impression without
enough hands-on experience with this project to know if its valid.
   Here I'm a user, and I don't have a valid opinion so I won't express
one. But, in bad taste or not, you now have the point of view of one user,
and the consequences of the decision which you (as a group) will make, who
may or may not be representative. That's what I would prefer the developers
do: ask the users, rather than saying they know the consequences for them.
   We are hoping to move away from the unsupported code, but cannot say
when, because it must be replaced, not discarded. Suspect there's quite a
few folk in this position.
   Perhaps you could take this into account when you make an informed
decision, which makes more sense than asking me to make an uninformed
decision. Because, as a user, the answer is I want both.
   The only opinion I can properly express: I would like to have a compiler
that is not so incredibly slow and produces working code. If that requires
removing those features, so be it. I'll take my lumps. I did not hear that.
I heard "its hard" not "its necessary". I suspect it may be necessary due
to problems with the design of gcc, but don't know for sure. If that's
true, I would question continuing that design. I know that's another issue
entirely.
   FYI, we've upgraded a number of computers for developers twice now: once
due to the doubling of memory needs for EGCS (pretty simple and
inexpensive); once for the doubling of compile times for GCC 3 (equally
simple, but not as inexpensive, and less effective). But we bought the
ability to turn off all the defines for EGCS bug work-arounds that were
reported, if there was a response (not always), it was: fixed in 3.
   Truth is, I would have kept the mouth shut if there hadn't been such a
sweeping statement about the effects on people who are unknown to you.
   I hope that answers your question.