Quote:Original post by nmi
Maybe you should read about LP32 and LP64:
http://www.opengroup.org/public/tech/aspen/lp64_wp.htm
I'd say that sums it up pretty well.
size_t to int conversion
I'd say that sums it up pretty well.
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.
It's actually about the only warning I ever disable and ignore.
Quote:Original post by Dave HuntQuote: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.
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]
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]
Quote:Original post by Dave HuntQuote:Original post by MaulingMonkeyQuote: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.
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 :)
Quote:Original post by DigitalDelusionQuote: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.
Quote:Original post by Dave HuntQuote:Original post by MaulingMonkeyQuote: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*
Quote:Original post by DigitalDelusionThe 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 =-/
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
