By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,513 Members | 1,611 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,513 IT Pros & Developers. It's quick & easy.

Type and value of basic_string::npos

P: n/a
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
Oct 29 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Heinz Ozwirk wrote:
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
Oct 29 '05 #2

P: n/a
Heinz Ozwirk wrote:
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

Oct 29 '05 #3

P: n/a
"Heinz Ozwirk" <ho**********@arcor.de> wrote in message
news:43***********************@newsread2.arcor-online.net...
: 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
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact
form
Brainbench MVP for C++ <> http://www.brainbench.com
Oct 29 '05 #4

P: n/a
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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Oct 29 '05 #5

P: n/a
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.
--

Valentin Samko - http://www.valentinsamko.com
Oct 29 '05 #6

P: n/a
Valentin Samko wrote:
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.


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

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Oct 29 '05 #7

P: n/a
"Valentin Samko" <c+***********@digiways.com> wrote in message
news:43**********************@authen.white.readfre enews.net...
: 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
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact
form
Oct 30 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.