In article h36@etca.etca.fr, chris@alofi.etca.fr (Christian Millour) writes:
>In article <199702170220.SAA05617@taumet.eng.sun.com>,
>Stephen.Clamage@eng.sun.com (Steve Clamage) writes:
>|>
>|> In the end, it was decided to leave C-style arrays alone. A complete
>|> fix is too incompatible, and a partial fix leading to partial
>|> incompatibility is pointless.
>
>compiler options, like "use-old-for-scope", are IMHO the right tool to
>deal with compatibility issues. Couldn't it have been appropriate here ?

Let's keep in mind the differences between a language definition and
an implementation of a language translator.

C++ follows C in not discussing things like "compiler options". The
standards just define what the language is. If implementors want to
provide alternative behaviors they can do so, but must make the defined
behaviors available to get certification.

C++ makes a few incompatible breaks with C, and a few incompatible
breaks with earlier versions of C++. In each case the seriousness of
the break was evaluated and compared with the benefits.

In the case of the old scope rules of "for" statements, the original
rules were vague, meaning implementations varied. The behavior of
the scoping rules was not intuitive or consistent -- or particularly
useful, for that matter. For those reasons, breaking compatibility
with earlier versions of C++ was not considered a huge liability.
(People can disagree about the seriousnes of the breakage, but I
don't think anyone can argue that the old rules were good. Certainly
not all programs using for-loops that define variables are affected.)

Suppose your favorite vendor provides a compiler option to keep the
old scoping rules in an otherwise standard-conforming compiler. You
can continue to use existing code unchanged with that compiler. Porting
it to other compilers becomes problematical. Since compilers use
different conventions for invoking compiler flags and combine
options in different ways, keeping track of the correct compiler options
in different environments is doomed to failure -- it is too error-prone.

The right thing to do is eventually to convert your code to follow
the new language rules. Determining the time at which to make the
change is a complicated subject, and I don't want to get into that.
(At least one company is maintaining a huge code base using a version
of Cfront from 1989 because they always felt they couldn't afford
to change the code to conform to newer language rules.)

Keep in mind that the C++ Committee's analysis said the amount of
pain caused the rule change was not great (overall), and was not
worse than the pain caused by leaving in place the inadequate rule.
Finally, C compatibility was not an issue -- you can't put declarations
in "for" statement headers in C.

The pointer-array conversion is a fundamental part of C, and thus
C++. If you remove the automatic conversion of arrays to pointers
in expressions and function parameters, you will break probably
every real program in existence. Hardly a single C program could be
compiled as C++ without extensive changes.

A compiler option to accept the old pointer-array rules allows you
to continue to use old code, but you still have mountains of troublesome
redesign and rewriting to do someday. (Apart from the portability
problems mentioned earlier.)

Breaking with tradition and requiring compilers optionally to accept the
old form of the pointer-array rules solves nothing. It merely assures
that old code will never be changed, and only new programs would ever
make use of the new language rule. New programs incorporating old
code would have to modify the old code, and the modified old code
could not be used with old programs. You just doubled your maintainance.

It is true that the pointer-array rules inherited from C cause much
confusion among programmers, and make code inherently unsafe. I'm not
defending the rules, just pointing out the consequences of change.

Happily, you can use array classes instead of C-style arrays, and
string classes instead of C char arrays. You can also continue to use
old-style code if you want, never having to change it, and mix it with
new code using classes. That seems to me a better solution than
changing a fundamental language rule.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]