Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Type and value of basic_string::npos

Reply
Thread Tools

Type and value of basic_string::npos

 
 
Heinz Ozwirk
Guest
Posts: n/a
 
      10-29-2005
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


 
Reply With Quote
 
 
 
 
John Harrison
Guest
Posts: n/a
 
      10-29-2005
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
 
Reply With Quote
 
 
 
 
Jonathan Mcdougall
Guest
Posts: n/a
 
      10-29-2005
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

 
Reply With Quote
 
Ivan Vecerina
Guest
Posts: n/a
 
      10-29-2005
"Heinz Ozwirk" <(E-Mail Removed)> wrote in message
news:4363216a$0$21956$(E-Mail Removed)-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


 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      10-29-2005
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)
 
Reply With Quote
 
Valentin Samko
Guest
Posts: n/a
 
      10-29-2005
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
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      10-29-2005
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)
 
Reply With Quote
 
Ivan Vecerina
Guest
Posts: n/a
 
      10-30-2005
"Valentin Samko" <(E-Mail Removed)> wrote in message
news:43639575$0$5396$(E-Mail Removed) 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"raise (type, value, traceback)" and "raise type, value, traceback" Jack Bates Python 0 05-02-2011 05:23 PM
#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type))) Yevgen Muntyan C Programming 10 02-13-2007 02:52 AM
compiler error: argument of type "VALUE *" is incompatible with parameter of type "VALUE" me2faster@excite.com Ruby 1 05-05-2005 11:23 PM
Re: Type casting- a larger type to a smaller type pete C Programming 4 04-02-2004 05:19 PM
Re: Type casting- a larger type to a smaller type heyo C Programming 3 04-01-2004 06:35 PM



Advertisments