Type and value of basic_string::npos

[Heinz Ozwirk]

Does the standard require that

1. the type of basic_string::npos is an unsigned type?
2. the value of basic_string::npos is the largest possible value of that
type?

And - only if both are true - basic_string::npos + 1 == 0 ?

Tnx
Heinz

 

[John Harrison]

Does the standard require that

1. the type of basic_string::npos is an unsigned type?
2. the value of basic_string::npos is the largest possible value of that
type?

And - only if both are true - basic_string::npos + 1 == 0 ?

Tnx
Heinz

Yes, yes and yes.

john

 

[Jonathan Mcdougall]

Does the standard require that

1. the type of basic_string::npos is an unsigned type?
Yes.

2. the value of basic_string::npos is the largest possible value of that
type?

Yes. It is actually required to be -1.

And - only if both are true - basic_string::npos + 1 == 0 ?

Yes. However, npos is required to be an unsigned *integral*, no more.
Be careful to use only values of type basic_string::size_type when you
compare them to npos. A comparison with an unsigned int (or whatever
other type) is not portable.


Jonathan

 

[Ivan Vecerina]

: Does the standard require that
:
: 1. the type of basic_string::npos is an unsigned type?
Yes.
: 2. the value of basic_string::npos is the largest possible value of
that
: type?
Yes.

: And - only if both are true - basic_string::npos + 1 == 0 ?
Not necessarily, as far as I understand.
If basic_string::npos is of type 'unsigned short' (16 bits),
and int is 32 bits, then npos+1 would be promoted to
a (32-bit) int, and the result would be: 65536

The following however shall always be true:
~basic_string::npos == 0


Ivan

 

[Pete Becker]

If basic_string::npos is of type 'unsigned short' (16 bits),
and int is 32 bits, then npos+1 would be promoted to
a (32-bit) int, and the result would be: 65536

That's the right answer, but you've got the promotion in the wrong
place. Since 1 is of type int and npos is of type unsigned short (in
this example), npos will be promoted to int. Once that promotion has
been done, the sum has type int.

 

[Valentin Samko]

That's the right answer, but you've got the promotion in the wrong
place. Since 1 is of type int and npos is of type unsigned short (in
this example), npos will be promoted to int. Once that promotion has
been done, the sum has type int.

But still, when unsigned 16bit integer which was assigned -1 is promoted to int, we get
65535 in that int. And then we add 1 to that, getting 65536.

typedef unsigned short ushort;
std::cout<<(ushort(-1) + 1)<<std::endl;

outputs 65536 on vc7.1, g++ 3.4 and intel 9, as I expected.

 

[Pete Becker]

But still, when unsigned 16bit integer which was assigned -1 is promoted
to int, we get 65535 in that int. And then we add 1 to that, getting 65536.

Yes, that's what "That's the right answer" means.

 

[Ivan Vecerina]

: Pete Becker wrote:
: > Ivan Vecerina wrote:
: >> If basic_string::npos is of type 'unsigned short' (16 bits),
: >> and int is 32 bits, then npos+1 would be promoted to
: >> a (32-bit) int, and the result would be: 65536
: >>
: >
: > That's the right answer, but you've got the promotion in the wrong
: > place. Since 1 is of type int and npos is of type unsigned short
(in
: > this example), npos will be promoted to int. Once that promotion
has
: > been done, the sum has type int.
:
: But still, when unsigned 16bit integer which was assigned -1
: is promoted to int, we get
: 65535 in that int. And then we add 1 to that, getting 65536.
:
: typedef unsigned short ushort;
: std::cout<<(ushort(-1) + 1)<<std::endl;
:
: outputs 65536 on vc7.1, g++ 3.4 and intel 9, as I expected.

Yes.

What Pete's point was is that the following statement I made
was inaccurate: << npos+1 would be promoted to a (32-bit) int >>
It is 'npos' itself that is first promoted to an int *prior* to
adding the integer value '1'.

Lack of clarity on my side -- pointed out by Pete in his personal
style
that often makes it sound like everything previously said is 'crap'.

Cheers,
Ivan