Is size_t a special keyword in ICC?

[abhijeet_thatte]

Hi,

I have been porting a working project from VC++ to ICC. While compilation it game me an error

error: invalid redeclaration of type name "size_t"
typedef ADDRESS size_t

I dont see any problem with this typedef. Only thing which comes to my mind is usage of keyword size_t. If ICC alreday has this keyword then it may not allow me to redifne me.
Can any one tell me if there is any other reason for the error.

Thanks,
Abhi

[chhenning_1977]

Abhi, size_t is used inside the "std" namespace. For instance, asking a std::vector for its size is of type std::size_t.

I would restrain from using size_t in c++ code.

Regards,

Christian

[TimP]

Perhaps this should be rephrased along the lines of "refrain from re-defining size_t in C or C++." I would not like to express approval of the school of thought which says compilers where int and size_t aren't interchangeable are broken. I've wasted months of work myself trying to work with those who hold such opinions.
In the past, some Microsoft C++ programmers disdained the use of size_t in C and C++ standards, and ICL also avoided its use, preferring to introduce portability problems between ia32 and X64. I notice that my current ICL installation has introduced size_t in the definition of local variations on malloc() and mmap() so as to fix such problems.
Correctness could easily depend on not defeating the use of size_t in C and C++ standard function prototypes by attempting to redefine it. If you have a data type of your own which you want to typedef to whatever you choose, you shouldn't be using a name for it which is reserved by the standards.

[ILevi1]

size_t is used in C++ (stddef.h, stdlib.h) and operator sizeof() evaluates to size_t. It is a reserved word which should not be redefined. Same goes for ptrdiff_t.

What today's schools do not teach developers is that size_t is used to overcome portability problems.

In general, if sizeof(int) != sizeof(ptr) on a particular architecture, you have to use size_t instead of int or you will have to write two versions of each function which has int as a parameter.

There is a very good explanation here:
http://www.viva64.com/en/a/0050/

I suggest that those developers who are engineering and writing IPP library API at Intel read it as well. It can save them a lot of effort in the future now that people are asking for 64-bit support in IPP functions.