f



When to use "INT" or "int"?

In windef.h there is a type definition
    typedef int INT;

Windows itself uses both types. For example, in the declaration of
SetSysColors:

BOOL WINAPI SetSysColors(
  int cElements,                                  // number of elements
to change
  CONST INT *lpaElements,                 // address of array of
elements
  CONST COLORREF *lpaRgbValues   // address of array of RGB values
);

Then I have a question: What is the consideration beneath the choice of
using either "int" or "INT"? In this case, why cElements should better
be declared as "int" and *lpaElements as "INT"?

0
senator
11/19/2006 3:53:57 AM
comp.os.programmer.win32 14523 articles. 0 followers. Post Follow

15 Replies
349 Views

Similar Articles

[PageSpeed] 15

"senator" <senatorcheng@gmail.com> wrote in message
news:1163908437.362321.171110@k70g2000cwa.googlegroups.com
> In windef.h there is a type definition
>    typedef int INT;
>
> Windows itself uses both types. For example, in the declaration of
> SetSysColors:
>
> BOOL WINAPI SetSysColors(
>  int cElements,                                  // number of elements
> to change
>  CONST INT *lpaElements,                 // address of array of
> elements
>  CONST COLORREF *lpaRgbValues   // address of array of RGB values
> );
>
> Then I have a question: What is the consideration beneath the choice
> of using either "int" or "INT"? In this case, why cElements should
> better be declared as "int" and *lpaElements as "INT"?


It makes no difference which one you use now, and it is unlikely to make a 
difference in the future. The way in which it could conceivably make a 
difference in the future is that an int will always be an int, whereas the 
meaning of INT can change in the future if the typedef is changed. This, 
however, is extremely unlikely.

When interracting with the Windows API, the safe thing to do is to use the 
same type names as the API.If the API uses an INT and the typedef changes in 
the future, then your code will still work. Personally, I think it so 
unlikely that an INT will stop being an int in the future, that I use int 
all the time.

-- 
John Carson 


0
John
11/19/2006 6:16:52 AM
"John Carson" <jcarson_n_o_sp_am_@netspace.net.au> wrote in message
news:455ff6da$0$4673$61c65585@un-2park-reader-01.sydney.pipenetworks.com.au...
> "senator" <senatorcheng@gmail.com> wrote in message
> news:1163908437.362321.171110@k70g2000cwa.googlegroups.com
> > In windef.h there is a type definition
> >    typedef int INT;
> >
> > Windows itself uses both types. For example, in the declaration of
> > SetSysColors:
> >
> > BOOL WINAPI SetSysColors(
> >  int cElements,                                  // number of elements
> > to change
> >  CONST INT *lpaElements,                 // address of array of
> > elements
> >  CONST COLORREF *lpaRgbValues   // address of array of RGB values
> > );
> >
> > Then I have a question: What is the consideration beneath the choice
> > of using either "int" or "INT"? In this case, why cElements should
> > better be declared as "int" and *lpaElements as "INT"?
>
>
> It makes no difference which one you use now, and it is unlikely to make a
> difference in the future. The way in which it could conceivably make a
> difference in the future is that an int will always be an int, whereas the
> meaning of INT can change in the future if the typedef is changed. This,
> however, is extremely unlikely.
>
> When interracting with the Windows API, the safe thing to do is to use the
> same type names as the API.If the API uses an INT and the typedef changes
in
> the future, then your code will still work. Personally, I think it so
> unlikely that an INT will stop being an int in the future, that I use int
> all the time.
>
> -- 
> John Carson
>
>

I thought of the possiblilities you stated as well.  If by any chance it
should change
int the future, INT was certainly a poor choice for the typedef :-).


0
Barry
11/19/2006 12:56:06 PM
"Barry" <barryg@nullhighstream.net> wrote in message
news:12m0l2lo82ta72c@corp.supernews.com...
>
> "John Carson" <jcarson_n_o_sp_am_@netspace.net.au> wrote in message
>
news:455ff6da$0$4673$61c65585@un-2park-reader-01.sydney.pipenetworks.com.au...
> > "senator" <senatorcheng@gmail.com> wrote in message
> > news:1163908437.362321.171110@k70g2000cwa.googlegroups.com
> > > In windef.h there is a type definition
> > >    typedef int INT;
> > >
> > > Windows itself uses both types. For example, in the declaration of
> > > SetSysColors:
> > >
> > > BOOL WINAPI SetSysColors(
> > >  int cElements,                                  // number of elements
> > > to change
> > >  CONST INT *lpaElements,                 // address of array of
> > > elements
> > >  CONST COLORREF *lpaRgbValues   // address of array of RGB values
> > > );
> > >
> > > Then I have a question: What is the consideration beneath the choice
> > > of using either "int" or "INT"? In this case, why cElements should
> > > better be declared as "int" and *lpaElements as "INT"?
> >
> >
> > It makes no difference which one you use now, and it is unlikely to make
a
> > difference in the future. The way in which it could conceivably make a
> > difference in the future is that an int will always be an int, whereas
the
> > meaning of INT can change in the future if the typedef is changed. This,
> > however, is extremely unlikely.
> >
> > When interracting with the Windows API, the safe thing to do is to use
the
> > same type names as the API.If the API uses an INT and the typedef
changes
> in
> > the future, then your code will still work. Personally, I think it so
> > unlikely that an INT will stop being an int in the future, that I use
int
> > all the time.
> >
> > -- 
> > John Carson
> >
> >
>
> I thought of the possiblilities you stated as well.  If by any chance it
> should change
> int the future, INT was certainly a poor choice for the typedef :-).

Isn't it a leftover of 16-bit windows? In those days, an INT wasn't an int.

[Jw]


0
jongware
11/19/2006 1:00:12 PM
John Carson skrev:
> "senator" <senatorcheng@gmail.com> wrote in message
> news:1163908437.362321.171110@k70g2000cwa.googlegroups.com
>> In windef.h there is a type definition
>>    typedef int INT;
>>
>> Windows itself uses both types. For example, in the declaration of
>> SetSysColors:
>>
>> BOOL WINAPI SetSysColors(
>>  int cElements,                                  // number of elements
>> to change
>>  CONST INT *lpaElements,                 // address of array of
>> elements
>>  CONST COLORREF *lpaRgbValues   // address of array of RGB values
>> );
>>
>> Then I have a question: What is the consideration beneath the choice
>> of using either "int" or "INT"? In this case, why cElements should
>> better be declared as "int" and *lpaElements as "INT"?
> 
> 
> It makes no difference which one you use now, and it is unlikely to make a 
> difference in the future. The way in which it could conceivably make a 
> difference in the future is that an int will always be an int, whereas the 
> meaning of INT can change in the future if the typedef is changed. This, 
> however, is extremely unlikely.

I think it would be the other way arround.

An int is what the compiler/platform defines as an int,
it might change if the compiler run on another platform,
ie an 64 bit int on future and 16 bit on old compilers.

An INT will always be an INT, but not necessarily an int.

-- 
Just another homepage:
http://damb.dk
But it's mine - Bertel
0
Bertel
11/19/2006 4:12:48 PM
"Bertel Brander" <bertel@post4.tele.dk> wrote in message
news:4560827f$0$20288$edfadb0f@dread16.news.tele.dk
> John Carson skrev:
>> "senator" <senatorcheng@gmail.com> wrote in message
>> news:1163908437.362321.171110@k70g2000cwa.googlegroups.com
>>> In windef.h there is a type definition
>>>    typedef int INT;
>>>
>>> Windows itself uses both types. For example, in the declaration of
>>> SetSysColors:
>>>
>>> BOOL WINAPI SetSysColors(
>>>  int cElements,                                  // number of
>>> elements to change
>>>  CONST INT *lpaElements,                 // address of array of
>>> elements
>>>  CONST COLORREF *lpaRgbValues   // address of array of RGB values
>>> );
>>>
>>> Then I have a question: What is the consideration beneath the choice
>>> of using either "int" or "INT"? In this case, why cElements should
>>> better be declared as "int" and *lpaElements as "INT"?
>>
>>
>> It makes no difference which one you use now, and it is unlikely to
>> make a difference in the future. The way in which it could
>> conceivably make a difference in the future is that an int will
>> always be an int, whereas the meaning of INT can change in the
>> future if the typedef is changed. This, however, is extremely
>> unlikely.
>
> I think it would be the other way arround.
>
> An int is what the compiler/platform defines as an int,
> it might change if the compiler run on another platform,
> ie an 64 bit int on future and 16 bit on old compilers.

Does that mean that an int ceases to be an int?

> An INT will always be an INT, but not necessarily an int.

The fact that an INT may not be an int in the future is the point I was 
making, so how is your view "the other way around". Of course an INT is an 
INT, but since an INT could be a typedef for an int or, say, an array of 
ints, that doesn't tell you anything.

-- 
John Carson 


0
John
11/19/2006 4:29:59 PM
"[jongware]" <IdontWantSpam@hotmail.com> wrote in message
news:eb027$45605554$50394ae2$3689@news.chello.nl...
> "Barry" <barryg@nullhighstream.net> wrote in message
> news:12m0l2lo82ta72c@corp.supernews.com...
> >
> > "John Carson" <jcarson_n_o_sp_am_@netspace.net.au> wrote in message
> >
>
news:455ff6da$0$4673$61c65585@un-2park-reader-01.sydney.pipenetworks.com.au...
> > > "senator" <senatorcheng@gmail.com> wrote in message
> > > news:1163908437.362321.171110@k70g2000cwa.googlegroups.com
> > > > In windef.h there is a type definition
> > > >    typedef int INT;
> > > >
> > > > Windows itself uses both types. For example, in the declaration of
> > > > SetSysColors:
> > > >
> > > > BOOL WINAPI SetSysColors(
> > > >  int cElements,                                  // number of
elements
> > > > to change
> > > >  CONST INT *lpaElements,                 // address of array of
> > > > elements
> > > >  CONST COLORREF *lpaRgbValues   // address of array of RGB values
> > > > );
> > > >
> > > > Then I have a question: What is the consideration beneath the choice
> > > > of using either "int" or "INT"? In this case, why cElements should
> > > > better be declared as "int" and *lpaElements as "INT"?
> > >
> > >
> > > It makes no difference which one you use now, and it is unlikely to
make
> a
> > > difference in the future. The way in which it could conceivably make a
> > > difference in the future is that an int will always be an int, whereas
> the
> > > meaning of INT can change in the future if the typedef is changed.
This,
> > > however, is extremely unlikely.
> > >
> > > When interracting with the Windows API, the safe thing to do is to use
> the
> > > same type names as the API.If the API uses an INT and the typedef
> changes
> > in
> > > the future, then your code will still work. Personally, I think it so
> > > unlikely that an INT will stop being an int in the future, that I use
> int
> > > all the time.
> > >
> > > -- 
> > > John Carson
> > >
> > >
> >
> > I thought of the possiblilities you stated as well.  If by any chance it
> > should change
> > int the future, INT was certainly a poor choice for the typedef :-).
>
> Isn't it a leftover of 16-bit windows? In those days, an INT wasn't an
int.
>
> [Jw]
>
>

Just out of curiousity I checked real quick and my 16-bit compiler didn't
have INT at all.  It defined the lpaElements in the call to SetSysColor as a
const int FAR*.  Unless I am not thinking clearly that isn't actually the
same
thing.  That is a 32-bit pointer to a 16-bit int.


0
Barry
11/19/2006 4:34:57 PM
John Carson skrev:
>> An int is what the compiler/platform defines as an int,
>> it might change if the compiler run on another platform,
>> ie an 64 bit int on future and 16 bit on old compilers.
> 
> Does that mean that an int ceases to be an int?

An int is typically the natural word size of the processor,
it is at least 16 bits.
On typical compilers used on DOS 10 years ago an int was
normmaly 16 bits.
Today everyone assumes it is 32 bits, but it might be
64 bits in the future.

But an int is an int is an int.

>> An INT will always be an INT, but not necessarily an int.
> 
> The fact that an INT may not be an int in the future is the point I was 
> making, so how is your view "the other way around". Of course an INT is an 
> INT, but since an INT could be a typedef for an int or, say, an array of 
> ints, that doesn't tell you anything.

My point is that an INT will be the same number of bits in the
future, an int might be something else.

-- 
Just another homepage:
http://damb.dk
But it's mine - Bertel
0
Bertel
11/19/2006 6:57:26 PM
Bertel Brander wrote:
> My point is that an INT will be the same number of bits in the
> future, an int might be something else.

That's very unlikely, 64bit platform is optimal for c++ types
char - 1byte, short int - 2bytes, int - 4 bytes and long int - 8bytes.

I think if we'll have a need for 128 or 256bit computer new types will 
be invented.

There are lot of remnants in Windows SDK for backward compatibility with 
win16, starting from WinMain (it's entry point is WinMain16 and some of 
it's parameters are obsolete), then you have types like LPVOID and PVOID 
and other long and near pointers, BOOL type from times C++ didn't have 
bool and so on.
I generally use Windows types when using windows API, in my own 
functions I use the ones provided by language.

-- 
Grzegorz Wr�bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
0
ISO
11/19/2006 9:36:02 PM
Grzegorz Wr�bel skrev:
> Bertel Brander wrote:
>> My point is that an INT will be the same number of bits in the
>> future, an int might be something else.
> 
> That's very unlikely, 64bit platform is optimal for c++ types
> char - 1byte, short int - 2bytes, int - 4 bytes and long int - 8bytes.

A long is normally 32 bits today.

But no, I don't think they will change the int again,
it will break to much code.

-- 
Just another homepage:
http://damb.dk
But it's mine - Bertel
0
Bertel
11/19/2006 11:07:19 PM
"Bertel Brander" <bertel@post4.tele.dk> wrote in message
news:4560a915$0$20239$edfadb0f@dread16.news.tele.dk
> John Carson skrev:
>>
>> The fact that an INT may not be an int in the future is the point I
>> was making, so how is your view "the other way around". Of course an
>> INT is an INT, but since an INT could be a typedef for an int or,
>> say, an array of ints, that doesn't tell you anything.
>
> My point is that an INT will be the same number of bits in the
> future, an int might be something else.

Nothing guarantees that an INT will be the same number of bits in the 
future. If the typedef doesn't change, then an INT will change its number of 
bits whenever int does.

The typedef might be changed to preserve a constant number of bits, or might 
not change, or might change in other ways.


-- 
John Carson 


0
John
11/20/2006 3:54:57 AM
Bertel Brander wrote:
> Grzegorz Wr�bel skrev:
>> Bertel Brander wrote:
>>> My point is that an INT will be the same number of bits in the
>>> future, an int might be something else.
>>
>> That's very unlikely, 64bit platform is optimal for c++ types
>> char - 1byte, short int - 2bytes, int - 4 bytes and long int - 8bytes.
> 
> A long is normally 32 bits today.
only on 32bit machines. If you go on 64 bit machine it is 64 bits.

I remember, ages ago as a student I wrote some prime number sieving 
algorithm. I was using unsigned long type for the number representation 
and to compute primes beyond 4294967295 I had to run my program on alpha 
station instead of win NT. :)


-- 
Grzegorz Wr�bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
0
ISO
11/20/2006 9:24:41 AM
Grzegorz Wr�bel wrote:
> Bertel Brander wrote:
>> A long is normally 32 bits today.

That statement is wrong, long-existing 64 bit platforms assigned long a 64
bit type.

> only on 32bit machines. If you go on 64 bit machine it is 64 bits.

Also, and in particular considering the newsgroup we are in, this is
unfortunately wrong. The win64 API advocates an LLP64 API, i.e. a 'long
long' (which is not even a C++ datatype!) is 64 bits there, a stupid
decision that was probably made to 'help' idiots that assumed that a long
was always 32 bits or didn't use typedefs so they could adapt to changes.
Now, instead, we get an API that you can't use with C++ properly because
you need types not covered by the standard. </rant>

> I remember, ages ago as a student I wrote some prime number sieving
> algorithm. I was using unsigned long type for the number representation
> and to compute primes beyond 4294967295 I had to run my program on alpha
> station instead of win NT. :)

An Alpha station running some Unix probably, the NT that ran on those
machines still was a 32 bit system, IIRC.

cheers

Uli

0
Ulrich
11/20/2006 9:51:10 AM
Ulrich Eckhardt wrote:
> Grzegorz Wr�bel wrote:
>> Bertel Brander wrote:
>>> A long is normally 32 bits today.
> 
> That statement is wrong, long-existing 64 bit platforms assigned long a 64
> bit type.
> 
>> only on 32bit machines. If you go on 64 bit machine it is 64 bits.
> 
> Also, and in particular considering the newsgroup we are in, this is
> unfortunately wrong. The win64 API advocates an LLP64 API, i.e. a 'long
> long' (which is not even a C++ datatype!) is 64 bits there, a stupid
> decision that was probably made to 'help' idiots that assumed that a long
> was always 32 bits or didn't use typedefs so they could adapt to changes.
> Now, instead, we get an API that you can't use with C++ properly because
> you need types not covered by the standard. </rant>
> 
I never used long long since it's not C++ specific as you said. If you 
want non standard 64bits integer you can use _int64 or INT64 or so. I am 
not familiar with 64bit version of windows but are you trying to tell me 
that long will (is!) be 32bit there? If so it would be (is!) terrible 
design flaw.

And if some idiots assumed that long is 32bits in their code, that's 
pure excuse for keeping long 32bit. The code that would be assuming this 
would need to be extremely old (from times of win16) because only a fool 
would be making such assumption in 32bit environment (where int would be 
much appropriate candidate). I personally would like to believe that 
64bit version of Windows doesn't use original win16 parts of code 
anymore, and if it does then those parts have been completely rewritten.

>> I remember, ages ago as a student I wrote some prime number sieving
>> algorithm. I was using unsigned long type for the number representation
>> and to compute primes beyond 4294967295 I had to run my program on alpha
>> station instead of win NT. :)
> 
> An Alpha station running some Unix probably, the NT that ran on those
> machines still was a 32 bit system, IIRC.

But of course! That is what I was demonstrating here: 64bit machine + 
64bit OS versus 32bit machine + 32bit OS.


-- 
Grzegorz Wr�bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
0
ISO
11/20/2006 10:21:39 AM
"Grzegorz Wr�bel" </dev/null@localhost.localdomain> wrote in message
news:ejrvoi$gbh$1@atlantis.news.tpi.pl
>
> I am not familiar with 64bit version of windows but are you trying to
> tell me that long will (is!) be 32bit there? If so it would be (is!)
> terrible design flaw.


long is indeed 32 bits on 64 bit Windows.

-- 
John Carson 


0
John
11/20/2006 1:34:42 PM
John Carson wrote:
> "Grzegorz Wr�bel" </dev/null@localhost.localdomain> wrote in message
> news:ejrvoi$gbh$1@atlantis.news.tpi.pl
>> I am not familiar with 64bit version of windows but are you trying to
>> tell me that long will (is!) be 32bit there? If so it would be (is!)
>> terrible design flaw.
> 
> 
> long is indeed 32 bits on 64 bit Windows.
> 

That's really sad. It's seems quite obvious they decided to do that for 
backward compatibility. One wonders only why they did go trough the 
effort of redefining all basic types like int with INT long with LONG, 
etc if they still have to rely on size of the long.

If they really needed only LONG to be 32bit for backward compatibility 
they could get away with 64bit long and define LONG as int on 64bit 
versions.

-- 
Grzegorz Wr�bel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D
0
ISO
11/20/2006 2:26:46 PM
Reply: