Re: Microsoft chooses to leave C++ compiler broken

On Mar 20, 7:17 am, "Balog Pal" <p...@lib.hu> wrote:


All compilers I know of have some bugs in that category as well.
It's true that they generally agree to fix them as soon as
possible when they are pointed out (for some definition of "as
soon as possible").

Since I'm apparently at the source of this, I'd like to
relativize it somewhat:

  -- The bug takes a very particular combination of conditions to
     appear; VC++ doesn't just drop destructors at random.

  -- IMHO, in most application domains, that combination of
     conditions simply won't appear, unless you're coding so
     badly that nothing is going to work anyway.

On the other hand:

  -- There are a few domains, particularly where complex
     numerical analysis is involved (but possibly others as well)
     where it can reasonably appear; it won't ever appear in code
     I write, because my style (usually SESE) will never create
     the particular combination of conditions, but the code where
     I did find it wasn't unreasonable, and

  -- It cost me three weeks to track down, three weeks of my
     time, paid for by my employer (which means that a new
     feature which we should currently be testing hasn't been
     implemented yet).

It is, obviously, that last point which made me bring the issue
up to begin with. I don't care if it's one in a million, if I
happen to be that one. (Similarly, I don't care if its 999999
in a million, if I'm the one exception.)

Anyway, I can understand Microsoft's original decision, even if
I don't agree with it, and I'm thankful for Herb's intervention
now. (Now how do I get him to go about intervening on the two
other bugs I've encountered. Particularly since one involves
something that I don't think is even officially supported.)

      [...]


Only the younger generation:-). I can remember a time when
almost all compilers I used had some problems in this regard.
(G++ 1.49 generated the destructor calls at the end of the
block. Immediately behind the ret instruction it generated if
there was a return statement in the block:-).)


If you refuse to use a compiler with any bugs, then you won't be
doing much C++.


First, it only occurs if you return the local. Conditionally.
And there is no other return statement in the function. I don't
think that that's a common case. It does occur, obviously
(since I encountered it), but I don't think it would ever occur
naturally in code implementing, say, a compiler. Which
doubtlessly explains why the compiler team at Microsoft thought
it was rare enough to be ignored.

      [...]


In the case of large companies, like Microsoft and Sun, all it
takes is a big enough customer. Presumably, no large customer
had complained. If Herb didn't know me, and intervene
personally in the problem, they probably wouldn't have reacted.
(On the other hand, if the work-around hadn't been so simple, my
bosses might have had purchasing intervene, and we're probably
a big enough customer to get some reaction.) This isn't
particular to Microsoft---it's just the way things are (and I've
had similar experiences with Sun: when my one-man firm posted an
error, it was noted; when my customer, who was Sun's largest
account in Europe that the time, complained, one week later
there were three engineers from California on site to find out
what the problem was.)


Like most companies, they're mixed. If you use them, you take
the bad with the good.

--
James Kanze

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]