Sign in to follow this  
Decept

size_t to int conversion

Recommended Posts

Hi What is the prefered way to convert a size_t variable to an (usigned) int? Some functions that I use return size_t, for example strlen(). size_t is an unsigned int, but is there a "safer" way to convert it than just unsigned int temp = strlen( someString ); I get warnings about this when I compile and it annoys me pretty good. I use VC++ 2003. thanks

Share this post


Link to post
Share on other sites
I believe the warning may be caused by setting "Detect 64-bit Portabilities Issues" to "Yes". Try changing it to "No" and they should go away.

Alternativly, just use std::size_t instead of unsigned int, then problem solved!

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
Quote:
Original post by desertcube
Alternativly, just use std::size_t instead of unsigned int, then problem solved!


Quoted for emphisis. You can even do using std::size_t and then just type size_t instead of unsigned int.


size_t is actually a typedef in the global namespace, so you don't need the std:: or the using statement.

Share this post


Link to post
Share on other sites
but is it 64bit-safe to do?:

unsigned int temp = (unsigned int)strlen( someString );

I know a string will hardly require a 64bit variable to hold the length :) but for other cases?

Share this post


Link to post
Share on other sites
Quote:
Original post by Decept
but is it 64bit-safe to do?:

unsigned int temp = (unsigned int)strlen( someString );

I know a string will hardly require a 64bit variable to hold the length :) but for other cases?
I don't see why thet could cause problems, if it's a 64bit machine, then an int with be 64-bits too, won't it?

Share this post


Link to post
Share on other sites
size_t is typically defined as unsigned long. As to 64-bit safe-ness, it would just depend on where and how it is being used. If you "know" that the return value won't exceed 32-bits, then it's safe (but bad form) to cast them to unsigned int. If you don't "know", then it's not safe.

You would probably be better off declaring variables intended to hold values from functions return size_t as size_t.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
I don't see why thet could cause problems, if it's a 64bit machine, then an int with be 64-bits too, won't it?

I'm not sure that's guaranteed, though it is probably true in practice. The standard only requires that an int be at least 16-bits. The intention was for an int to be the natural word size of the processor/platform, but it isn't a requirement.

Share this post


Link to post
Share on other sites
Also note that vc2k3 has a nasty habbit on warning when you try to output the darn thing... if you're using streams there doesn't seem to be an overload for size_t (or more correctly it's underlying type) so it gets converted into a unsigned int spewing warnings all over the place... 64bit compatibility warnings are horrible and even ms own headers from the latest platform SDK gives warnings about it.

It's actually about the only warning I ever disable and ignore.

Share this post


Link to post
Share on other sites
Quote:
Original post by Dave Hunt
Quote:
Original post by Evil Steve
I don't see why thet could cause problems, if it's a 64bit machine, then an int with be 64-bits too, won't it?

I'm not sure that's guaranteed, though it is probably true in practice. The standard only requires that an int be at least 16-bits. The intention was for an int to be the natural word size of the processor/platform, but it isn't a requirement.

I used to run 64bit linux and int was 32, long was 64.

Share this post


Link to post
Share on other sites
I can't find the link, but some of the MSDN Subscriber docs said that int would remain 32 bits for MS compilers. The C++ standard I believe says it should be otherwise though:

3.9.1 Fundamental types 3 Basic concepts
Paragraph 2

"There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural size suggested by the architecture of the execution environment..."

[Edited by - mfawcett on March 29, 2005 3:02:25 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Dave Hunt
Quote:
Original post by MaulingMonkey
Quote:
Original post by desertcube
Alternativly, just use std::size_t instead of unsigned int, then problem solved!


Quoted for emphisis. You can even do using std::size_t and then just type size_t instead of unsigned int.


size_t is actually a typedef in the global namespace, so you don't need the std:: or the using statement.

I'm pretty sure that size_t is only in namespace std in C++. Some versions of the Visual C++ compiler have size_t in the global namespace but I don't believe that is standard. Checking the standard on this.

Share this post


Link to post
Share on other sites
Quote:
Original post by Polymorphic OOP
I'm pretty sure that size_t is only in namespace std in C++. Some versions of the Visual C++ compiler have size_t in the global namespace but I don't believe that is standard. Checking the standard on this.


dunno... but it's declared in stddef.h so I my guess is that it's in the global namespace.

Eagerly awaiting what you find in the holy standard :)

Share this post


Link to post
Share on other sites
Quote:
Original post by DigitalDelusion
Quote:
Original post by Polymorphic OOP
I'm pretty sure that size_t is only in namespace std in C++. Some versions of the Visual C++ compiler have size_t in the global namespace but I don't believe that is standard. Checking the standard on this.


dunno... but it's declared in stddef.h so I my guess is that it's in the global namespace.

No, it's not declared in stddef.h in C++. In C++ there is no such standard file as stddef.h. It's in cstddef. The C++ versions of old C headers include the contents in the std namespace (I.E. ::std::memcpy etc).

The quote from the standard is:

Quote:
17.4.3.1.4
1 For each type from the Standard C library, the types ::T and ::std::T are reserved to the implementation and, when defined, ::T shall be identical to ::std::T.


A footnote identifies size_t as one of those types, so I retract my comment -- it is safe to use either the global namespace version or the std namespace version and they are guaranteed to be equal types.

Share this post


Link to post
Share on other sites
Quote:
Original post by Dave Hunt
Quote:
Original post by MaulingMonkey
Quote:
Original post by desertcube
Alternativly, just use std::size_t instead of unsigned int, then problem solved!


Quoted for emphisis. You can even do using std::size_t and then just type size_t instead of unsigned int.


size_t is actually a typedef in the global namespace, so you don't need the std:: or the using statement.


Interesting! *becomes even more of a lazy ****tard*

Share this post


Link to post
Share on other sites
Quote:
Original post by DigitalDelusion
Also note that vc2k3 has a nasty habbit on warning when you try to output the darn thing... if you're using streams there doesn't seem to be an overload for size_t (or more correctly it's underlying type) so it gets converted into a unsigned int spewing warnings all over the place... 64bit compatibility warnings are horrible and even ms own headers from the latest platform SDK gives warnings about it.

It's actually about the only warning I ever disable and ignore.
The really bad thing is that many WinAPI functions now have versions that are '64 bit safe', but are defined to the 32 bit versions on 32-bit machines, thus giving you the warnings anyways =-/

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
Quote:
Original post by DigitalDelusion
Also note that vc2k3 has a nasty habbit on warning when you try to output the darn thing... if you're using streams there doesn't seem to be an overload for size_t (or more correctly it's underlying type) so it gets converted into a unsigned int spewing warnings all over the place... 64bit compatibility warnings are horrible and even ms own headers from the latest platform SDK gives warnings about it.

It's actually about the only warning I ever disable and ignore.
The really bad thing is that many WinAPI functions now have versions that are '64 bit safe', but are defined to the 32 bit versions on 32-bit machines, thus giving you the warnings anyways =-/


Exactly! I changed my code to use the 64 bit safe version of some functions only to get the same warnings again.

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
Quote:
Original post by DigitalDelusion
It's actually about the only warning I ever disable and ignore.
The really bad thing is that many WinAPI functions now have versions that are '64 bit safe', but are defined to the 32 bit versions on 32-bit machines, thus giving you the warnings anyways =-/

If you really don't want it to detect portability issues then in Project Properties -> C/C++ -> General, turn Detect 64-bit portability issues to "No".

Share this post


Link to post
Share on other sites
Quote:
Original post by Polymorphic OOP
If you really don't want it to detect portability issues then in Project Properties -> C/C++ -> General, turn Detect 64-bit portability issues to "No".


The issue us more that of wanting to detect general portability issues but having broken headers to work with supplied with the compiler. Since there are 64bit safe functions it would be nice if the compiler also thougth they were, as it is now we have to trust MSDN on that. Same goes with trying to output a size_t through a ostream shouldn't that be quite portable?

Share this post


Link to post
Share on other sites
Quote:
Original post by Decept
Quote:
Original post by Extrarius
Quote:
Original post by DigitalDelusion
Also note that vc2k3 has a nasty habbit on warning when you try to output the darn thing... if you're using streams there doesn't seem to be an overload for size_t (or more correctly it's underlying type) so it gets converted into a unsigned int spewing warnings all over the place... 64bit compatibility warnings are horrible and even ms own headers from the latest platform SDK gives warnings about it.

It's actually about the only warning I ever disable and ignore.
The really bad thing is that many WinAPI functions now have versions that are '64 bit safe', but are defined to the 32 bit versions on 32-bit machines, thus giving you the warnings anyways =-/


Exactly! I changed my code to use the 64 bit safe version of some functions only to get the same warnings again.
Yup. I had that too. Damn you, SetWindowLongPtr(). I just got fed up with the warnings and disabled 64-bit portability. I'll burn that bridge when I come to it [wink]

Share this post


Link to post
Share on other sites
Quote:
Original post by Polymorphic OOP
Quote:
Original post by DigitalDelusion
Quote:
Original post by Polymorphic OOP
I'm pretty sure that size_t is only in namespace std in C++. Some versions of the Visual C++ compiler have size_t in the global namespace but I don't believe that is standard. Checking the standard on this.


dunno... but it's declared in stddef.h so I my guess is that it's in the global namespace.

No, it's not declared in stddef.h in C++. In C++ there is no such standard file as stddef.h. It's in cstddef. The C++ versions of old C headers include the contents in the std namespace (I.E. ::std::memcpy etc).

The quote from the standard is:

Quote:
17.4.3.1.4
1 For each type from the Standard C library, the types ::T and ::std::T are reserved to the implementation and, when defined, ::T shall be identical to ::std::T.


A footnote identifies size_t as one of those types, so I retract my comment -- it is safe to use either the global namespace version or the std namespace version and they are guaranteed to be equal types.


Though one is deprecated, while the other isn't.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this