Hi All,
I was looking over some sample code of ARM projects using winarm and yagarto
toolchain
what is the reason of creating your own types.h file when you can include
stdint.h or inttypes.h or similar?
#ifndef INC_TYPES_H
#define INC_TYPES_H
/* typedefs are here */
typedef unsigned char uint8_t;
typedef signed char int8_t;
typedef unsigned short uint16_t;
typedef signed short int16_t;
typedef unsigned long uint32_t;
typedef signed long int32_t;
typedef unsigned long long uint64_t;
typedef signed long long int64_t;
typedef enum {False, True} boolean;
#endif
include files, newbie question
Started by ●March 21, 2013
Reply by ●March 21, 20132013-03-21
On Wed, 2013-03-20 at 15:56 -0700, Dan Abc wrote:
> what is the reason of creating your own types.h file when you
> can include stdint.h or inttypes.h or similar?
Hi Daniel,
The reason for your own types.h header file is that you
want to have uniform variable lengths between different
compilers. An integer or double can be of different
lengths on different processors. But when you use int16_t
you know it is a 16 bit variable no matter the processor.
stdint.h does the same but has a lot more typedef's (and
can be handy when porting software).
I for instance use my own types.h for all the 8, 16 and
32 bit processors I use.
roelof
> what is the reason of creating your own types.h file when you
> can include stdint.h or inttypes.h or similar?
Hi Daniel,
The reason for your own types.h header file is that you
want to have uniform variable lengths between different
compilers. An integer or double can be of different
lengths on different processors. But when you use int16_t
you know it is a 16 bit variable no matter the processor.
stdint.h does the same but has a lot more typedef's (and
can be handy when porting software).
I for instance use my own types.h for all the 8, 16 and
32 bit processors I use.
roelof
Reply by ●March 21, 20132013-03-21
I think the short answer to your question is personal preference. I include
stdint.h since it seems to be the "standard" way to lock down integer data types
for portability.
Jeff
--- In l..., Dan Abc wrote:
>
> Hi All,
>
>
> I was looking over some sample code of ARM projects using winarm and yagarto toolchain
>
> what is the reason of creating your own types.h file when you can include stdint.h or inttypes.h or similar?
>
>
>
> #ifndef INC_TYPES_H
> #define INC_TYPES_H
>
> /* typedefs are here */
> typedef unsigned char uint8_t;
> typedef signed char int8_t;
> typedef unsigned short uint16_t;
> typedef signed short int16_t;
> typedef unsigned long uint32_t;
> typedef signed long int32_t;
> typedef unsigned long long uint64_t;
> typedef signed long long int64_t;
>
> typedef enum {False, True} boolean;
>
> #endif
>
>
>
>
Jeff
--- In l..., Dan Abc wrote:
>
> Hi All,
>
>
> I was looking over some sample code of ARM projects using winarm and yagarto toolchain
>
> what is the reason of creating your own types.h file when you can include stdint.h or inttypes.h or similar?
>
>
>
> #ifndef INC_TYPES_H
> #define INC_TYPES_H
>
> /* typedefs are here */
> typedef unsigned char uint8_t;
> typedef signed char int8_t;
> typedef unsigned short uint16_t;
> typedef signed short int16_t;
> typedef unsigned long uint32_t;
> typedef signed long int32_t;
> typedef unsigned long long uint64_t;
> typedef signed long long int64_t;
>
> typedef enum {False, True} boolean;
>
> #endif
>
>
>
>
Reply by ●March 21, 20132013-03-21
OK thanks,
I just saw the same definitions in stdint.h and types.h
similar to bool
there is one version in type.h True and False
then in bool.h it's true and false
and maybe another one else where TRUE and FALSE
since C is case sensitive these are all different
________________________________
From: roelof 't Hooft
To: l...
Sent: Thursday, March 21, 2013 12:51:36 AM
Subject: Re: [lpc2000] include files, newbie question
On Wed, 2013-03-20 at 15:56 -0700, Dan Abc wrote:
> what is the reason of creating your own types.h file when you
> can include stdint.h or inttypes.h or similar?
Hi Daniel,
The reason for your own types.h header file is that you
want to have uniform variable lengths between different
compilers. An integer or double can be of different
lengths on different processors. But when you use int16_t
you know it is a 16 bit variable no matter the processor.
stdint.h does the same but has a lot more typedef's (and
can be handy when porting software).
I for instance use my own types.h for all the 8, 16 and
32 bit processors I use.
roelof
I just saw the same definitions in stdint.h and types.h
similar to bool
there is one version in type.h True and False
then in bool.h it's true and false
and maybe another one else where TRUE and FALSE
since C is case sensitive these are all different
________________________________
From: roelof 't Hooft
To: l...
Sent: Thursday, March 21, 2013 12:51:36 AM
Subject: Re: [lpc2000] include files, newbie question
On Wed, 2013-03-20 at 15:56 -0700, Dan Abc wrote:
> what is the reason of creating your own types.h file when you
> can include stdint.h or inttypes.h or similar?
Hi Daniel,
The reason for your own types.h header file is that you
want to have uniform variable lengths between different
compilers. An integer or double can be of different
lengths on different processors. But when you use int16_t
you know it is a 16 bit variable no matter the processor.
stdint.h does the same but has a lot more typedef's (and
can be handy when porting software).
I for instance use my own types.h for all the 8, 16 and
32 bit processors I use.
roelof
Reply by ●March 22, 20132013-03-22
2013/3/21 Dan Abc
> **
> OK thanks,
>
> I just saw the same definitions in stdint.h and types.h
>
> similar to bool.
>
stdbool.h I suppose )
--
CMake build environment project
for micro-controllers (use
it or
addyou
favorite MCU )
> **
> OK thanks,
>
> I just saw the same definitions in stdint.h and types.h
>
> similar to bool.
>
stdbool.h I suppose )
--
CMake build environment project
for micro-controllers (use
it or
addyou
favorite MCU )
Reply by ●March 26, 20132013-03-26
--- In l..., Dan Abc wrote:
>
> Hi All,
>
>
> I was looking over some sample code of ARM projects using winarm and yagarto toolchain
>
> what is the reason of creating your own types.h file when you can include stdint.h or inttypes.h or similar?
>
>
>
> #ifndef INC_TYPES_H
> #define INC_TYPES_H
>
> /* typedefs are here */
> typedef unsigned char uint8_t;
> typedef signed char int8_t;
> typedef unsigned short uint16_t;
> typedef signed short int16_t;
> typedef unsigned long uint32_t;
> typedef signed long int32_t;
> typedef unsigned long long uint64_t;
> typedef signed long long int64_t;
>
> typedef enum {False, True} boolean;
>
> #endif
>
>
>
>
When you port your application to that new 97 bit processor, you will only have to change the definitions in one place. The rest of your application should remain unchanged. Assuming a lot of other stuff...
Richard
>
> Hi All,
>
>
> I was looking over some sample code of ARM projects using winarm and yagarto toolchain
>
> what is the reason of creating your own types.h file when you can include stdint.h or inttypes.h or similar?
>
>
>
> #ifndef INC_TYPES_H
> #define INC_TYPES_H
>
> /* typedefs are here */
> typedef unsigned char uint8_t;
> typedef signed char int8_t;
> typedef unsigned short uint16_t;
> typedef signed short int16_t;
> typedef unsigned long uint32_t;
> typedef signed long int32_t;
> typedef unsigned long long uint64_t;
> typedef signed long long int64_t;
>
> typedef enum {False, True} boolean;
>
> #endif
>
>
>
>
When you port your application to that new 97 bit processor, you will only have to change the definitions in one place. The rest of your application should remain unchanged. Assuming a lot of other stuff...
Richard
