In article <25937@alice.att.com>, bs@alice.att.com (Bjarne Stroustrup) writes:
>
> PS I think we have a decent chance at meeting the September '94 deadline for a
> draft standard.

This has to be good news. I understand the difficulty of encouraging a variety of intelligent people to achieve agreement, and pray that you do, indeed, meet your deadline.

The lack of a standard, and the acknowledged deficiencies in de facto ones such as cfront3 and the ARM, is making life very difficult for those of us producing industrial software using C++, as I'm sure the committee understands.

Firstly, learning a new language and programming paradigm is hard enough: having to learn where the holes are as well is like trying to learn how to ride a bike on a switchback.

Secondly, whilst compiler vendors appear to be gravitating towards cfront3, the ARM, and customer feedback as some kind of de facto standard, it is difficult to write software which is portable across several platforms - you can do it, but with the variances amongst compilers it's hard to estimate costs with any confidence. What you learn about one switchback doesn't apply to the next.

All this means that it is hard to introduce C++ to large industrial projects - not impossible, but hard, because the risks are expensive to manage.

It is a significant leap of faith for a manager to decide that the benefits of C++ - data abstraction, encapsulation, inheritance and polymorphism - outweigh the increased risks and costs of managing learning curves and quirky tools.

Having a standard, even a draft one, for the language would be a significant help in making the leap of faith and bringing the benefits of OO programming to a wider spread of industrial projects.

I have a copy of K&R 2nd edition, dated 1988. It was "based on Draft Proposed ANSI C", which was at the time of publication "in the final stages of public review." For practical purposes, it was a useful standard.

How close to the final version can we expect the September '94 draft to be?

I submit that if the core part is close to final, and the unresolved core areas are clearly identified, this would be an invaluable standard for much practical industrial programming: we could afford to wait a while longer for the extensions to stabilise.

Pat

--
Pat Dey               Email:    dey@us-es.sel.de
Alcatel SEL AG. Lorenzstrasse 10, D-70435 Stuttgart, Germany
(Opinions are mine, not necessarily SEL's)