1.
I am developing for both x86 and x64. I stop mouse on size_t in the code,
and "typedef unsigned int size_t" is always displayed. I think it is not
correct for x64. Since x64 size_t is 64-bit and unsigned int on x64 is
32-bit. So, the first question is how to let mouse display the correct
typedef?
2.
But when I select size_t and click go to Definition/Declaration, but always
failed. Where are they defined?
thanks in advance,
George
>Hello everyone,
>
>
>1.
>
>I am developing for both x86 and x64. I stop mouse on size_t in the code,
>and "typedef unsigned int size_t" is always displayed. I think it is not
>correct for x64. Since x64 size_t is 64-bit and unsigned int on x64 is
>32-bit. So, the first question is how to let mouse display the correct
>typedef?
You're not going to find some IDE setting called "Display correct typedefs
in tooltips." If you want to report the bug, you can do so here:
http://connect.microsoft.com/feedback/default.aspx?SiteID=210
>2.
>
>But when I select size_t and click go to Definition/Declaration, but always
>failed. Where are they defined?
Try to compile this fragment:
size_t x;
Last time I checked, it will compile, because VC makes size_t an intrinsic
type. This is a (minor) deviation from the standard, which requires size_t
to be a typedef defined in various header files.
--
Doug Harrison
Visual C++ MVP
It is defined in the required headers (which George perhaps forgot to
include? :-), but as it is also the return type of the sizeof
operator, the compiler will have to know about it anyway. That's a
quirk of the language!
Bo Persson
Windows comes with an excellent search tool
You must learn to use the search tools yourself.
findstr typedef.*size_t *.h
You'll find this in crtdefs.h:
#ifndef _SIZE_T_DEFINED
#ifdef _WIN64
typedef unsigned __int64 size_t;
#else
typedef _W64 unsigned int size_t;
#endif
#define _SIZE_T_DEFINED
#endif
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
1. Do you think it is an IDE bug to prevent mouse to show the correct
definition and also go to the wrong definition of 32-bit when developing
64-bit application?
2. I have tried without any header files, size_t x will compile. It proves
size_t is a built-in type? But I searched MSDN never mentions this and never
describes size_t is for 32-bit for x86 and 64-bit for x64.
regards,
George
How do you prove size_t is using definitions in crtdefs.h? I have tried
without any header files included, size_t x could compile. Any comments?
regards,
George
I am confused about your comments. Do you mean we need include some header
file to use size_t or not? From testing, seems we do not need to include any
header file in order to use size_t.
My test environment, VC 2008.
regards,
George
We need to include a header to get access to size_t, because it is a
typedef.
>
> My test environment, VC 2008.
VC2008 knows about size_t even without a header, because the compiler
uses the type itself. When you use it, you should include the
appropriate header.
Bo Persson
I understand your point is size_t is actually defined in some header, not
built in type, correct?
If so, which header file defines it? I actually find a couple of definitions
when do a search for size_t typedef.
regards,
George
That's a remnant from the C language. In C, one library header is not
allowed to include any other, so some things like size_t and NULL are
defined several times.
Just pick one!
Bo Persson
1.
> That's a remnant from the C language. In C, one library header is not
> allowed to include any other, so some things like size_t and NULL are
> defined several times.
I am not quite sure what do you mean library header? .h file or? Could you
show me a sample which means "one library header is not allowed to include
any other" please?
2.
It is fine if there is multiple definitions because of the limitation of C
itself as you mentioned, but how to find which definition is the one I am
currently using?
regards,
George
Yes, standard .h files provided with the C compiler.
> Could you show me a sample which means "one library header is not
> allowed to include any other" please?
>
> 2.
>
> It is fine if there is multiple definitions because of the
> limitation of C itself as you mentioned, but how to find which
> definition is the one I am currently using?
They are required to be identical, so you have to worry. In C
"stddef.h" is a good choice to standard typedefs, like size_t or NULL.
In C++ you could use <cstddef> instead.
If you use Visual Studio, just type size_t and press F1. The help page
will tell you.
Bo Persson
or you rather *don't* have to worry. :-)
>Thanks Doug,
>
>
>1. Do you think it is an IDE bug to prevent mouse to show the correct
>definition and also go to the wrong definition of 32-bit when developing
>64-bit application?
Yeah, I think it's a bug. A good hint was contained in what I originally
told you, namely, "If you want to report the bug..."
>>You're not going to find some IDE setting called "Display correct typedefs
>>in tooltips." If you want to report the bug, you can do so here:
>>http://connect.microsoft.com/feedback/default.aspx?SiteID=210
>2. I have tried without any header files, size_t x will compile. It proves
>size_t is a built-in type?
Again, the answer to your question may be found in what I originally told
you, namely:
>>Try to compile this fragment:
>>
>>size_t x;
>>
>>Last time I checked, it will compile, because VC makes size_t an intrinsic
>>type. This is a (minor) deviation from the standard, which requires size_t
>>to be a typedef defined in various header files.
>
>But I searched MSDN never mentions this
MSDN doesn't mention a lot of things.
>and never describes size_t is for 32-bit for x86 and 64-bit for x64.
But I'm pretty sure it describes size_t WRT x86 and x64. If it doesn't,
well, you can report the documentation bug using the link I gave you in my
first message.
What? You are one of the people whose posts I hesitate to challenge, but I
don't understand where that sentence came from. To my knowledge, that
restriction has NEVER been part of the C language, and I have never seen
that sentence in writing before. Are you suggesting this was a policy goal
in the ISO standard?
I don't need to prove it. Doug and Bo gave you an excellent analysis of
why this happens. However, IF the crtdefs.h definition was different from
what the compiler had built-in, there would be a compile-time error.
From what I understand, this follows from the requirements of "7.1.3
Reserved identifiers" of the C standard (C99).
One of the bullets says:
"Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for
use as a macro name and as an identifier with file scope in the same
name space if any of its associated headers is included."
So if you don't include a header, its names are not reserved. This
would break if standard headers included each other.
Bo Persson
1.
> >> That's a remnant from the C language. In C, one library header is
> >> not allowed to include any other, so some things like size_t and
> >> NULL are defined several times.
> >
> > I am not quite sure what do you mean library header? .h file or?
>
> Yes, standard .h files provided with the C compiler.
Confused. Do you mean in C standard header file design, like memory.h, it
does not include any other files? If yes, I doubt it since I found it
memory.h, it includes other files. If my understanding is wrong, could you
clarify what do you mean please? :-)
2.
> If you use Visual Studio, just type size_t and press F1. The help page
> will tell you.
Thanks. I find it out.
regards,
George
Today, I have made more experiment, which is, enable the "Generate
Preprocessed Files" of VC, but the output is quite surprising. Any ideas?
#line 1 "d:\\visual studio 2008\\projects\\testsizet1\\testsizet1\\main.cpp"
#include <wnidows.h>
int main()
{
size_t x;
return 0;
}
regards,
George
"Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for
use as a macro name and as an identifier with file scope in the same
name space if any of its associated headers is included." -- I read it a
couple of time, but very confused. Could you provide a sample to show what
does it mean or point me to some samples please? :-)
regards,
George
> What? You are one of the people whose posts I hesitate to challenge, but I
> don't understand where that sentence came from. To my knowledge, that
> restriction has NEVER been part of the C language, and I have never seen
> that sentence in writing before. Are you suggesting this was a policy goal
> in the ISO standard?
I have checked C standard library header file, like memory.h, it does
include other header files. So, I doubt the above points. Any comments?
regards,
George
> But I'm pretty sure it describes size_t WRT x86 and x64. If it doesn't,
> well, you can report the documentation bug using the link I gave you in my
> first message.
WRT is short for?
regards,
George
> why this happens. However, IF the crtdefs.h definition was different from
> what the compiler had built-in
Your above statement makes me confused. Do you mean size_t is defined in
crtdefs.h or a built-in type? Could you clarify your point please? :-)
regards,
George
I didn't say that it cannot include other files, I said that it cannot
include other standard headers. :-)
For example, if this is legal in a .c file:
#include <memory.h>
void printf()
{ int x = 5; }
because printf isn't reserved until I include <stdio.h>. This means
that <memory.h> cannot include <stdio.h>, or vice versa.
That <memory.h> includes a file <crtdefs.h> is an implementation
detail. It is not a standard header, and it only contains names
starting with underscore+uppercase or a double underscore. These names
are always reserved to the implementation, so I cannot use these
anyway.
The rules about reserved names goes all the way back to the earliest
C, that didn't always use headers, and didn't require function
protoypes either. The dark ages!
If you want the language to be backwards compatible, you cannot change
these rules.
Bo Persson
Sorry, skip the 'if' here. This IS legal in a .c file!
>WRT is short for?
Try googling "define WRT" (minus the quotes).
Why is this surprising? You have specified an include file that does not
exist, so it cannot be expanded (NB: the name is misspelled).
The real <windows.h> expands to about a quarter million lines of code.
The paragraph Bo quoted is from the 1999 C Standard. Microsoft currently
implements the 1990 C Standard.
I'm not yet convinced I truly believe that interpretation. I have to go do
some more research.
However, George, please allow me to give you a little advice. This is a
very picky point that is of interest only to people who are writing the
standards and building compilers. It has no implications for the ordinary
programmer, and I suggest you move on to another topic.
It shouldn't make you confused. I'm merely summarizing what was said
earlier in the thread. size_t is defined in <crtdefs.h>, as the standard
requires. However, for somewhat picky technical reasons, it is also a
built-in type.
Nothing more complicated than that.
I have continue the discussion here. Any comments?
regards,
George
1.
Do you know why standard C header file can not include other standard C
header file? What is the root reason behind this rule, e.g. this rule could
help us to achieve some benefits?
2.
For a header file, in which rule could you decide whether it is standard
header file or not?
regards,
George
My point is, I think the people who writes the standard is the people who is
most experienced. The decision and reason they made must be of good reason
for us to learn.
So, I am looking forward to your reply why standard header file is not
allowed to include other standard files. I am also looking forward to seeing
your analysis for the ideas behind the decision, and to see whether such
great ideas could improve our daily coding work. :-)
regards,
George
There are various definitions. Have you tried to search "define WRT" from
Google? :-)
have a good weekend,
George
Looks like size_t is quite special thing and in our current theory we can
not explain gracefully. Right? :-)
I mean our theory is,
- built-in type does not need to include any files;
- we trust MSDN document which mentioned size_t is defined in crtdef.h.
regards,
George
There is no benefit except backward compatibility with ancient,
pre-standard C. Initially there was no library and no headers, so you
could use any names in your program.
>
> 2.
>
> For a header file, in which rule could you decide whether it is
> standard header file or not?
I look in the standard. :-)
Right after the quote I gave from chapter 7.1, there are lots of 7.x
sections each describing one header file and the names declared in it.
Bo Persson
>There are various definitions. Have you tried to search "define WRT" from
>Google? :-)
When in doubt, go with the first one, taking into account the context in
which the acronym was used. It isn't hard to figure out.
Listen, I gave you the correct explanation in my first post to you. Why are
you still talking about it? Here it is again, and I hope this thread will
cease and desist:
<q>
Try to compile this fragment:
size_t x;
Last time I checked, it will compile, because VC makes size_t an intrinsic
type. This is a (minor) deviation from the standard, which requires size_t
to be a typedef defined in various header files.
</q>
It ain't some profound mystery of the universe. :)
Well, *I* am not going to be the one to tell you why, because I remain
unconvinced that the requirement follows from that paragraph. In Visual
C++ 8.0, for example, <stdio.h> includes <crtdefs.h>, and <stdlib.h>
includes both <crtdefs.h> and <limits.h>.
Now, I fully grant that, just because that Visual C++ does it does NOT
automatically mean that the standard allows it. Also, as I said, the
section Bo quoted was from the 1999 standard, whereas Microsoft implements
the 1990 standard.