Hi all,
I want to know what the difference is between "size_t" and "unsigned int". I'm a beginner to programming so could you explain it in simple terms.
Oh yeah, what is "puts()"? what does it do?
Thanks
help! size_t, unigned int and puts()
Hi all,
I want to know what the difference is between "size_t" and "unsigned int". I'm a beginner to programming so could you explain it in simple terms.
Oh yeah, what is "puts()"? what does it do?
Thanks
size_t and unsigned int can both be the same size in bytes, but size_t is defined in the headers whereas unsigned int is defined by the compiler itself.Originally Posted by Messi 10
puts is like printf except that puts does not expand formatting characters, nor does puts accept variadic argument lists like printf.
Other than that, they both print stuff to the screen, but puts includes a new-line automatically, whereas printf requires a \n in your string literal.
That's not true. size_t is specified by the compiler implementation, and the content of header files mirrors that. The sizeof() operator produces a value of type size_t, regardless of what header files have been #include'd.
To answer the original question, size_t and unsigned int are both unsigned integral values. size_t is able to represent the size of any object. unsigned int is only guaranteed to support values between 0 and 65535.
unsigned int can support larger values than 65535, but is not required to. On quite a few compilers, unsigned int and size_t support a different range of values.
puts() and printf() actually write to a device named stdout, and called the "standard output device". That device is not required to be a screen.
That's not true. size_t is specified by the compiler implementation, and the content of header files mirrors that. The sizeof() operator produces a value of type size_t, regardless of what header files have been #include'd.
To answer the original question, size_t and unsigned int are both unsigned integral values. size_t is able to represent the size of any object. unsigned int is only guaranteed to support values between 0 and 65535.
unsigned int can support larger values than 65535, but is not required to. On quite a few compilers, unsigned int and size_t support a different range of values.
puts() and printf() actually write to a device named stdout, and called the "standard output device". That device is not required to be a screen.
I kind of understand the "puts" thing, but I didnt get what you said about "size_t" and the "unsigned int". Could you elaborate further? thanks.
Ok. It appears that for compilers complying with C99, that size_t is defined by the compiler. However, I'm not on my Unix box at the moment and only have a copy of MingW to check. But here are the defines for size_t from stdlib.h lines 11 through 22 which make a conditional define of size_t if needed by including stddef.h
So it appears that size_t is still sometimes defined in the headers.Code:#ifndef _STDLIB_H_ #define _STDLIB_H_ /* All the headers include this file. */ #include <_mingw.h> #define __need_size_t #define __need_wchar_t #define __need_NULL #ifndef RC_INVOKED #include <stddef.h> #endif /* RC_INVOKED */
**EDIT**
It appears that gcc now dynamically creates the stddef.h file at compile time with internal definitions... So is it technically still defined in headers?
Last edited by twiki; 11-25-2012 at 06:20 AM.
size_t is required to be able to represent, in bytes, the size of an object of any type that can be examined by the sizeof() operator. So if you needed to represent say the length of a string, it is a rather logical choice, given that there are environmental, minimal limits on the size of an array (and other things) in standard C. The minimum limit of the size of an object, that means that the compiler must translate source containing an object of this size, is 2^16, in C99.
unsigned int is just an unsigned integer (read positive values only) type that can support different ranges on different platforms. It is a general purpose integer type.
I don't think you're wrong, that just doesn't matter. You're pointing out an implementation detail.So it appears that size_t is still sometimes defined in the headers.
Last edited by whiteflags; 11-25-2012 at 06:25 AM. Reason: 2^16 not 32
According to WG14/N1256 Committee Draft — Septermber 7, 2007 ISO/IEC 9899:TC3
The return value of sizeof is "implementation-defined" and is said to be an unsigned value. And it says that size_t IS defined in stddef.h and/or other headers...
You can read the full text at the following address...4 The value of the result is implementation-defined, and its type (an unsigned integer type)
is size_t, defined in <stddef.h> (and other headers).
http://www.open-std.org/jtc1/sc22/WG...docs/n1256.pdf
**EDIT**
Sorry... had to fully understand my own post...
Last edited by twiki; 11-25-2012 at 07:27 AM.
The standard agrees with my assessment of the facts AFAICT. If you want to argue, please don't quote my whole post as if I am entirely wrong.
If you want to verify what I said about the environmental limits you will have to read the section 5.2.4.1 Translation limits (which is under environmental limits, excuse me). By my reading, what you quoted says the value of the result is implementation defined, not the type. The type is actually defined in the same rule that you quoted (size_t). This is because the standard doesn't care how many bytes sizeof(foo) is where foo is practically anything other than char. Another way to say it is sizeof(int) could be 2 or 4 on a given C implementation, or it could be something else.
TL;DR -- A C implementation that does not meet or exceed the environmental limits is not a C implementation, saying "implementation defined" does not mean you can ignore the rest of the standard.
Finally:
If you don't know what a hosted environment is please consult this document with a brief explanation.— 65535 bytes in an object (in a hosted environment only)
My apologies. I did not mean to imply that you were wrong. I simply quoted your post with a reply.
I only wanted to make a point about size_t being defined in the headers. Which according to that draft, it is. GCC generating the stddef.h header at compile time is implementation specific it seems.
That's all... no argument. Sorry if you were offended.
