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]

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 <[email protected]>:

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.

 

[Alf P. Steinbach]

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++std/2002/pdf/revisions.pdf
http://www.acceleratedcpp.com/authors/koenig/c++std/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 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]

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

One feature removed in C++ 2003 is the old equivalence between
&a 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?

 

[Alf P. Steinbach]

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

One feature removed in C++ 2003 is the old equivalence between
&a 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&...GsAtZ22%24EwxZ%40jgharris.demon.co.uk&rnum=10>


or the subject line?

"a not equivalent to *(a+i)?"

Or the reference in the C++ standard?

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

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]

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.

 

[Pete Becker]

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]

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.

No. Seems like a perfectly reasonable topic.

The thread was originated
by the notorious troll ERT, and deliberately and maliciously
cross-posted.

Quite an indictment, given the innocuous nature of the question.

 

[Pete Becker]

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.

 

[Rob Williscroft]

Alf P. Steinbach wrote in

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.

 

[Richard Heathfield]

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/H/Hanlons-Razor.html

 

[Alf P. Steinbach]

Alf P. Steinbach wrote in

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... ;-)).

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

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... ;-)).

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.

 

[Alf P. Steinbach]

Alf P. Steinbach wrote in

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... ;-)).

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

On 14 Dec 2003 17:32:44 GMT, Rob Williscroft

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++std/2002/pdf/revisions.pdf

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.