C 99 -- C++ 2003 diffs

[E. Robert Tisdale]

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

[Servé Lau]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:3F**************@jpl.nasa.gov...

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

Where to find a summary of the C++2003 standard?

[Wolfgang Kaufmann]

* Thus spoke E. Robert Tisdale <E.**************@jpl.nasa.gov>:

Hallo,

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

In which world exists an ANSI/ISO C++ 2003 standard already?

- <http://david.tribble.com/text/cdiffs.htm>

[ f'up2 -> clc++ ]

Wolfgang.
--
"Es gibt Dinge, die man bereut, ehe man sie tut. Und man tut sie doch."
-- Christian Friedrich Hebbel

[Alf P. Steinbach]

On Sat, 13 Dec 2003 19:42:16 -0800, "E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

http://www.research.att.com/~ark/c++.../revisions.pdf
http://www.acceleratedcpp.com/author.../revisions.pdf

Not exactly what you ask for, since just the revisions are listed.

Picking just two current threads from [comp.lang.c++.moderated]:

One feature removed in C++ 2003 is the old equivalence between
&a[i] and a+i for the array element just past the end of an array.
That's just silly, IMHO.

A feature added in C++ 2003 is guaranteed zero-initialization of
POD elements of T when you write 'new T' instead of 'new T()'.

Things like that.

[Bob Hairgrove]

On Sun, 14 Dec 2003 10:47:10 GMT, al***@start.no (Alf P. Steinbach)
wrote:

Picking just two current threads from [comp.lang.c++.moderated]:

One feature removed in C++ 2003 is the old equivalence between
&a[i] and a+i for the array element just past the end of an array.
That's just silly, IMHO.
Are you referring to vectors or arrays?

Do you have a link to this thread, or the subject line?
Or the reference in the C++ standard?
A feature added in C++ 2003 is guaranteed zero-initialization of
POD elements of T when you write 'new T' instead of 'new T()'.

Isn't this the other way around, i.e. "new T();" gives me default
initialization (0 for POD), whereas "new T;" is uninitialized?
--
Bob Hairgrove
No**********@Home.com

[Alf P. Steinbach]

On Sun, 14 Dec 2003 11:24:09 GMT, wouldnt_you_like@to_know.com (Bob Hairgrove) wrote:

On Sun, 14 Dec 2003 10:47:10 GMT, al***@start.no (Alf P. Steinbach)
wrote:

Picking just two current threads from [comp.lang.c++.moderated]:

One feature removed in C++ 2003 is the old equivalence between
&a[i] and a+i for the array element just past the end of an array.
That's just silly, IMHO.
Are you referring to vectors or arrays?

Do you have a link to this thread

<url:
http://www.google.com/groups?hl=no&lr=&ie=UTF-8&oe=UTF-8&threadm=pADhGsAtZ22%24EwxZ%40jgharris.demon.co.u k&rnum=10&prev=/groups%3Fq%3Da%255Bi%255D%2Bgroup:comp.lang.c%252B %252B.moderated%26hl%3Dno%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd%26selm%3DpADhGsAtZ22%2524EwxZ%2540 jgharris.demon.co.uk%26rnum%3D10>

or the subject line?
"a[i] not equivalent to *(a+i)?"

Or the reference in the C++ standard?

§24.1/5, which is revised in C++ 2003.

A feature added in C++ 2003 is guaranteed zero-initialization of
POD elements of T when you write 'new T' instead of 'new T()'.

Isn't this the other way around, i.e. "new T();" gives me default
initialization (0 for POD), whereas "new T;" is uninitialized?

C++ 2003 adds a new term "value-initialized". "new T;" is the new
thing, value-initialization.

[CBFalconer]

"E. Robert Tisdale" wrote:

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

Will readers on c.l.c++ PLEASE remove c.l.c from all replies to
this and anything else in the thread. The thread was originated
by the notorious troll ERT, and deliberately and maliciously
cross-posted.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Pete Becker]

"E. Robert Tisdale" wrote:

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

All of them.

The 2003 C++ revision deals only with defect reports.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

Pete Becker wrote:

"E. Robert Tisdale" wrote:

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

All of them.

The 2003 C++ revision deals only with defect reports.

I should add that the C++ committee is currently working on a library
TR, which will add to C++ the C library math functions added in C99. See

wwwold.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1503.txt.

In addition, the TR adds a bunch of special math functions (bessels,
elliptical integrals, riemann zeta, ...). See

wwwold.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1542.pdf

This proposal is also being actively considered for the next revision of
the C standard.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Rob Williscroft]

Alf P. Steinbach wrote in news:3f****************@News.CIS.DFN.DE:

A feature added in C++ 2003 is guaranteed zero-initialization of
POD elements of T when you write 'new T' instead of 'new T()'.

Isn't this the other way around, i.e. "new T();" gives me default
initialization (0 for POD), whereas "new T;" is uninitialized?

C++ 2003 adds a new term "value-initialized". "new T;" is the new
thing, value-initialization.

You do appear to have it the wrong way around, the new standard replaces
default intialization (T *t = new T()) with value initialization. When
you write T *t = new T, you get a T that is, in the absence of default
ctor, unintialized. The new behaviour occurs when you write T *t = new T().

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Richard Heathfield]

CBFalconer wrote:

"E. Robert Tisdale" wrote:

Can anybody summarize the [new] features of ANSI/ISO C 99 standard
that were *not* adopted by the ANSI/ISO C++ 2003 standard?
Or point me to such a summary.

Will readers on c.l.c++ PLEASE remove c.l.c from all replies to
this and anything else in the thread. The thread was originated
by the notorious troll ERT, and deliberately and maliciously
cross-posted.

Hanlon's Razor applies.

http://www.catb.org/~esr/jargon/html...ons-Razor.html

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Alf P. Steinbach]

On 14 Dec 2003 15:49:42 GMT, Rob Williscroft <rt*@freenet.REMOVE.co.uk> wrote:

Alf P. Steinbach wrote in news:3f****************@News.CIS.DFN.DE:

A feature added in C++ 2003 is guaranteed zero-initialization of
POD elements of T when you write 'new T' instead of 'new T()'.

Isn't this the other way around, i.e. "new T();" gives me default
initialization (0 for POD), whereas "new T;" is uninitialized?
C++ 2003 adds a new term "value-initialized". "new T;" is the new
thing, value-initialization.

You do appear to have it the wrong way around, the new standard replaces
default intialization (T *t = new T()) with value initialization.

That's right, sorry for writing haste (also about a[i]... ;-)).

When
you write T *t = new T, you get a T that is, in the absence of default
ctor, unintialized.
That's incorrect. The relevant text is §5.3.4. And it says, if T is
non-POD you get default-initialization, which is effectively
zero-initialization for POD elements.
The new behaviour occurs when you write T *t = new T().

Righto.

In this case, the difference from C++ 98, if T doesn't have a user-
defined constructor you're still guaranteed zero-initialization of
POD elements.

As Andrew Koenig explained in another thread (he originated the change)
the purpose was to remove the subtlety of
struct T { foo bar; int x; };

...
p = new T();
where without this change guaranteed initialization of x would depend on
the PODness of T, that is, whether foo is a typedef or what.

[Rob Williscroft]

Alf P. Steinbach wrote in news:3f*************@News.CIS.DFN.DE:

You do appear to have it the wrong way around, the new standard
replaces default intialization (T *t = new T()) with value
initialization.

That's right, sorry for writing haste (also about a[i]... ;-)).

When
you write T *t = new T, you get a T that is, in the absence of default
ctor, unintialized.

That's incorrect. The relevant text is õ5.3.4. And it says, if T is
non-POD you get default-initialization, which is effectively
zero-initialization for POD elements.

Right, but just to be clear if T *is* a POD then it will be
uninitialized.

I must admit this is an odd "corner case" that I don't think I'll be
exploiting any time soon :).

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Alf P. Steinbach]

On 14 Dec 2003 17:32:44 GMT, Rob Williscroft <rt*@freenet.REMOVE.co.uk> wrote:

Alf P. Steinbach wrote in news:3f*************@News.CIS.DFN.DE:

You do appear to have it the wrong way around, the new standard
replaces default intialization (T *t = new T()) with value
initialization.

That's right, sorry for writing haste (also about a[i]... ;-)).

When
you write T *t = new T, you get a T that is, in the absence of default
ctor, unintialized.

That's incorrect. The relevant text is õ5.3.4. And it says, if T is
non-POD you get default-initialization, which is effectively
zero-initialization for POD elements.

Right, but just to be clear if T *is* a POD then it will be
uninitialized.

I must admit this is an odd "corner case" that I don't think I'll be
exploiting any time soon :).

I'm sorry to the n'th degree. THIS IS NOT MY DAY. What I wrote was
again incorrect; it seems my thoughts are truly muddled (and I convinced
you of an incorrect reading of the standard). And no, I didn't party last
night. Perhaps a bit of the flu. Also, problems with electricity supply,
snow on the TV image, and more.

Just don't be surprised by more technical inaccuracies from me for the next
few days.

Okay?

[Rob Williscroft]

Alf P. Steinbach wrote in news:3f**************@News.CIS.DFN.DE:

On 14 Dec 2003 17:32:44 GMT, Rob Williscroft
<rt*@freenet.REMOVE.co.uk> wrote:

When
you write T *t = new T, you get a T that is, in the absence of
default ctor, unintialized.

That's incorrect. The relevant text is õ5.3.4. And it says, if T
is non-POD you get default-initialization, which is effectively
zero-initialization for POD elements.

I read this:

— If the new-initializer is omitted:
— If T is a (possibly cv-qualified) non-POD class type (or array
thereof), the object is defaultinitialized (8.5). If T is a
const-qualified type, the underlying class type shall have a
user-declared default constructor.

— Otherwise, the object created has indeterminate value. If T is a
const-qualified type, or a (possibly cv-qualified) POD class type
(or array thereof) containing (directly or indirectly) a member of
const-qualified type, the program is ill-formed;

In Andrew Koenig's unofficial revision's list page 20: "Replace
subclause 5.3.4, paragraph 15." (the above from the replacment
part).

http://www.research.att.com/~ark/c++.../revisions.pdf

Right, but just to be clear if T *is* a POD then it will be
uninitialized.

I must admit this is an odd "corner case" that I don't think I'll be
exploiting any time soon :).

I'm sorry to the n'th degree. THIS IS NOT MY DAY. What I wrote was
again incorrect; it seems my thoughts are truly muddled (and I
convinced you of an incorrect reading of the standard). And no, I
didn't party last night. Perhaps a bit of the flu. Also, problems
with electricity supply, snow on the TV image, and more.

I think (from the above) you where right.

Though (to me at least) it doesn't matter as if I want default-
initialization (value-initialization when I get a compiler that
supports it) I would write new T(), I'd only write new T if I knew
that T had a default ctor or for some reason I knew it didn't matter
wether I got a T (or its POD members) which is zero initialized.

Rob.
--
http://www.victim-prime.dsl.pipex.com/