kprateek88@yahoo.com (Prateek R Karandikar) writes:
[snip]
> By the way, has the 2003 standard been finalised?

> If yes,

Yes.

> from where
> can I get a complete
> list of differences between it and the 1998 standard?

www.research.att.com/~ark/c++std/2003/pdf/revisions.pdf

The by section indices of the core language and standard library
    issues are sometimes easier to navigate. You can find them at:
    http://anubis.dkuug.dk/jtc1/sc22/wg21
    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_index.html
    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-index.html

However the issues lists also contain issues where were resolved as
    NAD (Not A Defect), issues still under discussion, issues which
    did not make it into TC1 (C++ 2003), etc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kprateek88@yahoo.com (Prateek R Karandikar) writes:

> A backward compatible suggestion for the next standard
>
> The next version of the standard could simultaneously define 2
> versions of the language.

Subsetting the language will make it harder to write portable
    code. What is the compensating advantage?

> One would be the "classic" or "usual"
> version. Another would be the "pure" version, where features
> supported just for the sake of backward compatibility, deprecated
> features, and redundant keywords would be removed. Other useful
> changes, including additions to the language can also be made to
> this version, which cannot be made now merely because they would
> break existing code.

In other words, an new language, requiring new source code to be
    written in order to take advantage of it.

Such a language might be good enough to justify the cost of
    switching. And, I suppose, a standard-mandated translator might
    lower the cost. But such a language would need to offer some
    compelling new advantage the backward-compatible C++ doesn't
    have. Something more important than backward-compatiblity.

[snip]
> As far as separate compilation goes, there can be a few
> possibilities, depending on the extent of the differences between
> the pure and the classic versions.: 1) Do not allow linking pure and
> classic translated translation units. 2) There can be extern "pure"
> and extern "classic" linkage specifications. 3) Allow pure and
> classic translated translation units to be linked.
[snip]

I think a complete, and convienient specification for sharing
    interfaces and linking together objects of the two different
    langauges would be almost a necessity.

Even today, a large portion of C++ applications link to libraries
    written in C. (I don't believe I've ever worked on a non-trivial
    application that doesn't, even if the system-provided standard C
    library is discounted.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

A backward compatible suggestion for the next standard

The next version of the standard could simultaneously define 2
versions of the language.
One would be the "classic" or "usual" version. Another would be the
"pure" version, where
features supported just for the sake of backward compatibility,
deprecated features, and
redundant keywords would be removed. Other useful changes, including
additions to the
language can also be made to this version, which cannot be made now
merely because
they would break existing code. This "pure" version could be indicated
by a directive, maybe
#pure, at the beginning of a source file. Unless specified, the source
file will be treated as a
"classic" program. Resolving whether a source file is #pure or not
would be done in one of
the early phases of translation. The standard library of the pure and
classic versions can
differ wherever required.

As far as separate compilation goes, there can be a few possibilities,
depending on the
extent of the differences between the pure and the classic versions.:
1) Do not allow linking pure and classic translated translation units.
2) There can be extern "pure" and extern "classic" linkage
specifications.
3) Allow pure and classic translated translation units to be linked.

The purpose of having a pure version is so that new programmers can
directly start using
the pure version. When viewed independently, the pure version would be
better than the
classic version. New programmers would not be bothered with features
like allowing a struct
and a function in the same scope to have the same name, which, when
viewed in isolation,
rather than in historic context, seem absurd. The pure version would
also give a chance to
streamline the entire standard library ( "For historical reasons,
bitset differs somewhat in
style from other standard library classes.", TC++PL by Stroustrup 3rd
edition 17.5.3 ). is...
functions from <cctype> should return bool. New features from C99
could be incorporated
where suitable. wchar_t can be renamed to something more normal like
wchar.

Redundant keywords which could be removed ( The less, the merrier):
* auto
* int !!! ( unsigned, signed, short, and long can together express any
type which int and
these four keywords together can express)
* any one of struct and class
* double and float can be replaced by one keyword (eg, short float
(single precision), float
(double precision), long float(extended precision))
* register

By the way, has the 2003 standard been finalised? If yes, from where
can I get a complete
list of differences between it and the 1998 standard?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]