In article <769866446snz@iplbath.demon.co.uk> mishad@iplbath.demon.co.uk writes:
>Hi,
>
>We (IPL) are a supplier of (testing) tools for C, C++ and Ada.
>I (Misha Dorman) am looking at our C++ language support plans
>for the future.

[]

>Q: How are *YOU* handling/intending to handle this problem?

 The committee generally refrains from breaking
old C++ code unless there is a good reason.

>Q: Is there a list of changes (those that have already been accepted)
>detailing in what circumstances old code may be broken?

 The Working Paper contains a "Compatibility" Appendix.

>Q: Is there a way to get hold of papers that have been proposed so far?

 I believe they are available from CEBMA.

>The situation is only made worse by the fact that many of the features
>are still not finalised, and there are still many proposals that may
>be included in the final standard which have not yet been accepted.

 The difficulty of tracking the changes gives an advantage
to larger, and/or smarter tool builders. If everything were
quite Standardised, there would be less competition. I guess
its consumers that pay in the short term.

>
>Q: Is there a deadline before which proposals MUST be submitted (even
>one like 1996 :-)?

 No. But as the document proceeds through ISO and ANSI
processes the nature of changes will rapidly become editorial
rather than substantive. (I hope :-)
>
>Q: Is it feasible to provide the facility to switch the new features
>on and off (command line switches, maybe) individually, or is that going
>to introduce massive complexity?
>
>I foresee problems in particular with the scoping effects of RTTI,
>template changes and namespaces all being difficult to implement
>in a switchable manner (especially all at once!)

 Neither RTTI nor namespaces have any impact on code not
using them. Some changes to templates will; the new requirement
that template specialisations must be declared will break
some code. Other things to watch for .. mutable means
most cast-away-const operations are now broken.
>
>It's not just C++ that has these problems, but C and ADA already have
>standards to work to - currently the only C++ standard is the ARM,
>which is (a) old hat, and (b) inconsistent/wrong.

 There is not much point in an expensive new hat which hasn't
yet been sewn up.  The old one, although battered, is familiar
and serviceable.

>If you have any ideas on how to solve these problems, please mail/post
>them.

>Misha Dorman
>United Kingdom       E-mail: mishad@iplbath.demon.co.uk
 ^^^^^^^^^^^^^^
 Sure: you can join the UK Standardisation panel.
Your company can join the ANSI committee X3J16 for a fee.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

Hi,

We (IPL) are a supplier of (testing) tools for C, C++ and Ada.
I (Misha Dorman) am looking at our C++ language support plans
for the future.

Clearly we would like to support as many C++ users as possible.
However, we have a problem - because different compiler implementors
are incorporating features from the standardisation process at
different times (Borland has exceptions and RTTI, while many UNIX
cfont compilers still don't have exceptions...), we have to support
many different feature levels. (I believe we still have one user with
a cfront 2.0-based compiler!).

We cannot afford to support only those users with the latest compilers.
There are many cases where existing code is broken using the new rules.

As a *tools*, not a *compiler* supplier, we have less control over users
compiler choice (they may change their testing tool because it doesn't
support their compiler, but they are unlikely to change their compiler
because it isn't supported by their testing tool, and they are very
unlikely to change their code simply because it isn't supported by
their testing tool).

I assume there are many other people out there with similar problems.

Q: How are *YOU* handling/intending to handle this problem?

Q: Is there a list of changes (those that have already been accepted)
detailing in what circumstances old code may be broken?

I guess that each change proposal will include a summary of what old
code is broken by the change.

Q: Is there a way to get hold of papers that have been proposed so far?

The situation is only made worse by the fact that many of the features
are still not finalised, and there are still many proposals that may
be included in the final standard which have not yet been accepted.

Q: Is there a deadline before which proposals MUST be submitted (even
one like 1996 :-)?

Ideally we would support ALL current compilers (ie those on MSDOS and
popular UNIX platforms :-)

Q: Is it feasible to provide the facility to switch the new features
on and off (command line switches, maybe) individually, or is that going
to introduce massive complexity?

I foresee problems in particular with the scoping effects of RTTI,
template changes and namespaces all being difficult to implement
in a switchable manner (especially all at once!)

It's not just C++ that has these problems, but C and ADA already have
standards to work to - currently the only C++ standard is the ARM,
which is (a) old hat, and (b) inconsistent/wrong.

If you have any ideas on how to solve these problems, please mail/post
them.
--


Misha Dorman
IPL Information Processing Ltd
Eveleigh House                   Tel: +44 (0)225 444888
Grove Street                     Fax: +44 (0)225 444400
Bath  BA1 5LR
United Kingdom       E-mail: mishad@iplbath.demon.co.uk