size-t

Is size_t the word size of the machine that compiled the code? Parsing with g++, my compiler views size_t as an long unsigned int . Does the compiler internally choose the size of size_t , or is size_t actually typdefed inside some pre-processor macro in stddef.h to the word size before the compiler gets invoked? Or am I way off track? In the C++ standard, [support.types] (18.2) /6: "The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object." This may or may not be the same as a "word size", whatever that means. Jonathan

My question is that I have a size_t data, but now I want to convert it to double or int. If I do something like size_t data = 99999999; int convertdata = data; the compiler will report warning. because it maybe overflow. Do you have some method like the boost or some other method to do the convert? A cast, as Blaz Bratanic suggested : size_t data = 99999999; int convertdata = static_cast<int>(data); is likely to silence the warning (though in principle a compiler can warn about anything it likes, even if there's a cast). But it doesn't solve the problem that the warning was telling you about,

I'm trying to get SIZE_MAX in C89. I thought of the following way to find SIZE_MAX : const size_t SIZE_MAX = -1; Since the standard (§6.2.1.2 ANSI C) says: When a signed integer is converted to an unsigned integer with equal or greater size, if the value of the signed integer is nonnegative, its value is unchanged. Otherwise: if the unsigned integer has greater size, the signed integer is first promoted to the signed integer corresponding to the unsigned integer; the value is converted to unsigned by adding to it one greater than the largest number that can be represented in the unsigned

Is there a standard (or MSVC proprietary) typedef for a signed type that can contain the full range of size_t values? I.e. on a 64-bit system, it would be a 128-bit signed integer. It's not possible in general to define such a type. It's perfectly legal for an implementation to make size_t the largest supported unsigned type, which would mean that no signed type can hold all its values. ptrdiff_t is not necessarily wide enough. It's the result of subtracting two pointers, but there's nothing that says a pointer subtraction cannot overflow. See section 5.7 of the C++ standard: When two pointers

The C standard guarantees that an int is able to store every possible array size. At least, that's what I understand from reading §6.5.2.1, subsection 1 (Array subscripting constraints): One of the expressions shall have type ‘‘pointer to object type’’, the other expression shall have integer type, and the result has type ‘‘type’’. Since we shall use int s as array subscripts, why are we supposed to use size_t to determine the size of an array? Why does strlen() return size_t when int would suffice? The term "integer type" doesn't mean int - for example, char , and short are integer types.

In C I see a lot of code that adds or assigns an integer literal to a size_t variable. size_t foo = 1; foo += 1; What conversion takes place here, and can it ever happen that a size_t is "upgraded" to an int and then converted back to a size_t ? Would that still wraparound if I was at the max? size_t foo = SIZE_MAX; foo += 1; Is that defined behavior? It's an unsigned type size_t which is having a signed int added to it (that may be a larger type?) and the converted back to a size_t . Is there risk of signed integer overflow? Would it make sense to write something like foo + bar + (size_t)1

i wanted to declare a very large array. i found that the max size of an array is size_t, which is defined as UINT_MAX so i wrote the code like this int arr[UINT_MAX]; when i compile this, it says overflow in array dimension but when i write like this size_t s = UINT_MAX; int arr[s]; it compiles properly. what's the difference First error: size_t is not necessarily unsigned int , thus its maximum value can be different from the one of unsigned int ( UINT_MAX ); moreover, in C++ to get informations about the limits of a type you should use std::numeric_limits . #include <limits> size_t s=std:

In this blog entry by Andrey Karpov entitled, "About size_t and ptrdiff_t " he shows an example, for (ptrdiff_t i = 0; i < n; i++) a[i] = 0; However, I'm not sure if that's right, it seems that should be for (size_t i = 0; i < n; i++) a[i] = 0; Is this correct? I know we should also likely be using something like memset , but let's avoid that entirely. I'm only asking about the type Pascal Cuoq In a blog post , I argue that you should always refrain from allocating memory blocks larger than PTRDIFF_MAX (*), because doing so will make compilers such as Clang and GCC generate nonsensical code