question about new and delete operator

[Richard Herring]

Exactly. And if the language defines a type T such that T - T
-> T, then that type isn't an abstraction of the natural
numbers. For a type to be usable as an abstraction of the
natural numbers, the results of subtraction must be another
type, or subtraction must not be supported. (Modula-2, for
example, takes that latter course.) C++ doesn't have such a
type; the closest we can come is int.

Mhmm. You got me thinking here.

[...]
In the end, a language is designed the way it is designed. You
can fight it, but you won't win. Kernighan and Richie decided
that the principal integral type in C would be int; all other
types have been added for specific needs, but int remains THE
integral type. Anytime you use anything else (for integral
values, of course), you're fighting the language: introducing
additional complexity and additional possibilities for errors.

Mhmm. Then who added 'size_t' to be used for sizes
to this language?

I don't know. That came a lot later. (Don't forget, however,
that size_t was originally designed to represent something very
low level, which often wouldn't fit in an int.)

It is recycled throughout most of the C++ std lib (as
'size_type').

I know. That's obviously an error in the conception of the
library, but it's too late to change it now, despite the
problems it causes.

I'm still not convinced, the choice of unsigned for counting
objects throughout the whole std lib is wrong.

[If you'll forgive a linguistic nitpick, that's ambiguous in English. I
take it you mean you're not convinced *that* the choice of unsigned is
wrong. ]

It's fine for *counting*. The problem is that it's used for several
other things as well. An index is not a count, though it can be mapped
to one. The difference of two indices is definitely not a count.

 

[Richard Herring]

James Kanze wrote:
Mhmm. Then who added 'size_t' to be used for sizes
to this language?
I don't know. That came a lot later. (Don't forget, however,
that size_t was originally designed to represent something very
low level, which often wouldn't fit in an int.)
It is recycled throughout most of the C++ std lib (as
'size_type').
I know. That's obviously an error in the conception of the
library, but it's too late to change it now, despite the
problems it causes.
I'm still not convinced, the choice of unsigned for counting
objects throughout the whole std lib is wrong.

[If you'll forgive a linguistic nitpick, that's ambiguous in
English. I take it you mean you're not convinced *that* the choice of
unsigned is wrong. ]

[Thanks. Actually I wish I was corrected more. How could I
improve otherwise. And, yes, your guess was correct.]

It's fine for *counting*. The problem is that it's used for several
other things as well. An index is not a count, though it can be mapped
one. The difference of two indices is definitely not a count.

Wait. I see that the difference between two indices should
not be expressed as an unsigned value. But what is this
about an index? Are you saying an index shouldn't be an
unsigned value?

No. Just that an index is not quite the same kind of thing as a count.
Don't forget that there are languages where indexes don't start at 0 (or
even 1;-)

 

[James Kanze]

On Aug 4, 8:29 pm, Hendrik Schober <[email protected]> wrote:

[...]

I'm still not convinced, the choice of unsigned for counting
objects throughout the whole std lib is wrong.

If all we did was count them, there'd be no problem. The
problems start when we start subtracting pointers or iterators.

In C++ (and C), there are also problems when mixing the types,
because the implicit conversions are signedness preserving, not
value preserving. The C committee doubtlessly had some reason
for doing this (earlier C compilers were value preserving), but
it does cause some confusing results when comparing values with
different types:
unsigned u = 10 ;
if ( u > -5 ) // ...
Logically, the if should always be true, but in fact, in the
above case, it's false. Good compilers warn about this,
however, and you can (and should) explicitly convert to
whichever is more appropriate, e.g.:
unsigned u = 10 ;
if ( static_cast< int >( u ) > -5 ) // ...
// or checked_cast, if you can't guarantee that
// u is representable as an int.
Still, having to do so is a pain; it's much easier to just use
int everywhere. (Alternatively, a language could support ranged
types, with range checking. All conversions would be value
preserving, or cause a bound check error.)

 

[Alf P. Steinbach]

* James Kanze:

[...]

I'm still not convinced, the choice of unsigned for counting
objects throughout the whole std lib is wrong.

If all we did was count them, there'd be no problem. The
problems start when we start subtracting pointers or iterators.

In C++ (and C), there are also problems when mixing the types,
because the implicit conversions are signedness preserving, not
value preserving.

I think you meant to write the opposite, yes?

The C committee doubtlessly had some reason
for doing this (earlier C compilers were value preserving), but
it does cause some confusing results when comparing values with
different types:
unsigned u = 10 ;
if ( u > -5 ) // ...

E.g., how does this preserve the signedness of the -5?

 

[James Kanze]

* James Kanze:

James Kanze wrote:
[...]
I'm still not convinced, the choice of unsigned for counting
objects throughout the whole std lib is wrong.

If all we did was count them, there'd be no problem. The
problems start when we start subtracting pointers or iterators.
In C++ (and C), there are also problems when mixing the types,
because the implicit conversions are signedness preserving, not
value preserving.

I think you meant to write the opposite, yes?

No. The implicit conversions do not preserve the value. What I
actually should have written is "unsigned preserving" vs. "value
preserving". See §3.2.1.1 of the Rationale for C
(http://www.quut.com/c/rat/title.html).

(Curiously enough, the Rationale justifies choosing value
preserving semantics over unsigned preserving, but the C
standard, and C++ after it, do just the opposite. But this
section is speaking mainly about things like unsigned short to
int or to unsigned int. And confuses me more than anything
else. But misremembered, it is my source for the terminology.)