size_t literals?

[Bo Persson]

+ guarantying that the most containers allocate continuous memory
space and thus their members can also be accessed with regular
pointers.

Well, std::vector at least. From what I understand, that was the
intention all along. The committee just failed to write it down
explicitly in the 1998 release of the standard.


Bo Persson

 

[Ioannis Vranos]

K&R2 includes C89 towards the end of the book, and there, size_t is
mentioned as "implementation-defined".

Yes, but implementation defined contains limits. It a typedef
to an implementation defined unsigned integral type. It must be
an unsigned integral type. In §6.1.2.5 (C90): "There are four
signed integer types[...] For each signed integer type, there is
a corresponding (but different) unsigned integar type[...] "The
type char, the signed and unsigned integer types, and enumerated
types are collectively called integral types." And in the
above, "integral types" is in italics, which means that this is
the definition of the term (as used in the standard).

I verified what you said in clc for C90/C95 and it appears you are
right. Under C++03 any typedef of an implementation-defined
signed/unsigned integer type is a typedef of one of the 4 built in
signed/unsigned integer types respectively.

So, I think case is closed for this.


The "34-bits" issue remains open. AFAIK long is at least 32 bits, so I
can't get your reference that it is 34 bits at least.

 

[James Kanze]

Pete Becker wrote: [...]
And if there is any doubt, here is the relevant quote:
[basic.fundamental]
2 "There are four signed integer types: ... ; the other signed
integer types are provided to meet special needs.
3 For each of the signed integer types, there exists a
corresponding (but different) unsigned integer type: ..."
In my understanding, if the application chooses to provide the "other
signed integer types", it should also provide unsigned equivalents for
those.

Except that "other", in this specific context, unambiguously means
"other than int", since it directly follows an explanation of "plain
ints". If this had been written by anyone else, I'd suspect you were
being deliberately misleading.

Note that, in all this, I'm speaking only of the actual text of the
Standard. I have my suspicions that this isn't what was actually
intended by the writers (you'd have to ask them); I think this is
especially likely since they appear to have remedied it for the
upcoming standard.

Actually, I think it was intended. In 1990, long long and other
extended integral types weren't considered an issue.

 

[James Kanze]

Well, std::vector at least. From what I understand, that was the
intention all along. The committee just failed to write it down
explicitly in the 1998 release of the standard.

That's the justification. From what I understand, some of
the people who voted for the text of the original standard did
think this. IMHO, it's obviously an extension, but since
extensions weren't allowed in C++03, the committee "invented" an
original intent so that it could be considered a bug fix.
(IMHO, to consider it "original intent" would mean that the
committee as a whole had actually thought about it. I don't
think anyone had.)

 

[James Kanze]

James Kanze wrote: [...]
The "34-bits" issue remains open. AFAIK long is at least 32
bits, so I can't get your reference that it is 34 bits at
least.

The 34 bits refered to being able to treat 4294967296 as a long
literal. Since the actual value here requires 33 bits to
represent, and long must have a bit for the sign as well, this
value can only be represented in a long if long has at least 34
bits.

According to the C++ standard, a decimal literal without a
suffix *must* be representable as a long, or an error occurs.
And in one place, the standard explicitly says that this error
makes the program ill-formed (which means that a diagnostic must
be issued).

This is, of course, an incompatibility with C, since C allows
unsigned long even for a decimal.

 

[Ioannis Vranos]

This is, of course, an incompatibility with C, since C allows
unsigned long even for a decimal.

I did not understand your last sentence above.

 

[Gerhard Fiedler]

I did not understand your last sentence above.

"decimal integer literal"?

Gerhard

 

[Micah Cowan]

I did not understand your last sentence above.

He means that a decimal literal without one of the suffixes, that
specifies a number greater than LONG_MAX is undefined in C++ (which
requires it to be representable as a long), but not in C (incuding
C90), which allows (requires) it to be represented as an unsigned
long.

 

[James Kanze]

He means that a decimal literal without one of the suffixes, that
specifies a number greater than LONG_MAX is undefined in C++ (which
requires it to be representable as a long), but not in C (incuding
C90), which allows (requires) it to be represented as an unsigned
long.

Exactly, although when I reread the sentence I actually wrote,
it's not surprising the Ioannis didn't understand it.