Mixing
Is it ok to include .c source file for maintainability of embedded C code?
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I am not an expert C programmer and I know that including .c source file from another is considered bad practice, but I have a situation where I think it could help maintainability.
I have a big structure with a lot of elements and I use #define to keep the indexes.
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
static const MyElements elems =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
Since I need to access the structure from index, I need to keep synchronized the #define and the structure declaration. That means that I must insert new elements at the right place and update the #define accordingly.
It is error prone and I don’t really like it (but for performance consideration, I didn’t find any better solution).
Anyway, this file also contains a lot of functions to handle this structure.
I also want to keep separation of code and avoid global variable.
To make things “easierâ€Â, I was thinking about moving this “error prone definition†to a single .c source file which would only contain this structure. This file would be “the dangerous be careful file†and include it in my actual “normal functional†file.
What do you think about it? Is it a valid situation for including .c source file? Is there another better way of handling my structure?
Thanks in advance for your advices.
c performance embedded stm32 maintainability
asked 2 hours ago
ncenerar
940620
add a comment |Â
up vote
6
down vote
favorite
I am not an expert C programmer and I know that including .c source file from another is considered bad practice, but I have a situation where I think it could help maintainability.
I have a big structure with a lot of elements and I use #define to keep the indexes.
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
static const MyElements elems =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
Since I need to access the structure from index, I need to keep synchronized the #define and the structure declaration. That means that I must insert new elements at the right place and update the #define accordingly.
It is error prone and I don’t really like it (but for performance consideration, I didn’t find any better solution).
Anyway, this file also contains a lot of functions to handle this structure.
I also want to keep separation of code and avoid global variable.
To make things “easierâ€Â, I was thinking about moving this “error prone definition†to a single .c source file which would only contain this structure. This file would be “the dangerous be careful file†and include it in my actual “normal functional†file.
What do you think about it? Is it a valid situation for including .c source file? Is there another better way of handling my structure?
Thanks in advance for your advices.
c performance embedded stm32 maintainability
asked 2 hours ago
ncenerar
940620
I'd say in such a case it's OK.
– Jabberwocky
2 hours ago
3
Even if the file contains a variable definition, you could still name the file with a.hending.
– Some programmer dude
1 hour ago
1
Maybe better if you name the file to be included as "file.inc" or "file.c.inc"?
– pmg
1 hour ago
1
Are you aware that every other C file that requires the#definestuff, also will get its own copy of the array if this file is included?
– Gerhardh
1 hour ago
Why would this bestatic constinstead ofextern const? In these situations, x-macros can be helpful, as long as your programming team won't hurt you for using them. But it's also likely you are doing something wrong, since having hardcoded defines means you need to use these exact constants at compile time. Post some code where the defines are being used.
– Groo
1 hour ago
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I am not an expert C programmer and I know that including .c source file from another is considered bad practice, but I have a situation where I think it could help maintainability.
I have a big structure with a lot of elements and I use #define to keep the indexes.
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
static const MyElements elems =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
Since I need to access the structure from index, I need to keep synchronized the #define and the structure declaration. That means that I must insert new elements at the right place and update the #define accordingly.
It is error prone and I don’t really like it (but for performance consideration, I didn’t find any better solution).
Anyway, this file also contains a lot of functions to handle this structure.
I also want to keep separation of code and avoid global variable.
To make things “easierâ€Â, I was thinking about moving this “error prone definition†to a single .c source file which would only contain this structure. This file would be “the dangerous be careful file†and include it in my actual “normal functional†file.
What do you think about it? Is it a valid situation for including .c source file? Is there another better way of handling my structure?
Thanks in advance for your advices.
c performance embedded stm32 maintainability
asked 2 hours ago
ncenerar
940620
I am not an expert C programmer and I know that including .c source file from another is considered bad practice, but I have a situation where I think it could help maintainability.
I have a big structure with a lot of elements and I use #define to keep the indexes.
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
static const MyElements elems =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
Since I need to access the structure from index, I need to keep synchronized the #define and the structure declaration. That means that I must insert new elements at the right place and update the #define accordingly.
It is error prone and I don’t really like it (but for performance consideration, I didn’t find any better solution).
Anyway, this file also contains a lot of functions to handle this structure.
I also want to keep separation of code and avoid global variable.
To make things “easierâ€Â, I was thinking about moving this “error prone definition†to a single .c source file which would only contain this structure. This file would be “the dangerous be careful file†and include it in my actual “normal functional†file.
What do you think about it? Is it a valid situation for including .c source file? Is there another better way of handling my structure?
Thanks in advance for your advices.
c performance embedded stm32 maintainability
c performance embedded stm32 maintainability
asked 2 hours ago
ncenerar
940620
asked 2 hours ago
ncenerar
940620
asked 2 hours ago
ncenerar
940620
asked 2 hours ago
ncenerar
940620
asked 2 hours ago
ncenerar
940620
940620
I'd say in such a case it's OK.
– Jabberwocky
2 hours ago
3
Even if the file contains a variable definition, you could still name the file with a.hending.
– Some programmer dude
1 hour ago
1
Maybe better if you name the file to be included as "file.inc" or "file.c.inc"?
– pmg
1 hour ago
1
Are you aware that every other C file that requires the#definestuff, also will get its own copy of the array if this file is included?
– Gerhardh
1 hour ago
Why would this bestatic constinstead ofextern const? In these situations, x-macros can be helpful, as long as your programming team won't hurt you for using them. But it's also likely you are doing something wrong, since having hardcoded defines means you need to use these exact constants at compile time. Post some code where the defines are being used.
– Groo
1 hour ago
add a comment |Â
I'd say in such a case it's OK.
– Jabberwocky
2 hours ago
3
Even if the file contains a variable definition, you could still name the file with a.hending.
– Some programmer dude
1 hour ago
1
Maybe better if you name the file to be included as "file.inc" or "file.c.inc"?
– pmg
1 hour ago
1
Are you aware that every other C file that requires the#definestuff, also will get its own copy of the array if this file is included?
– Gerhardh
1 hour ago
Why would this bestatic constinstead ofextern const? In these situations, x-macros can be helpful, as long as your programming team won't hurt you for using them. But it's also likely you are doing something wrong, since having hardcoded defines means you need to use these exact constants at compile time. Post some code where the defines are being used.
– Groo
1 hour ago
I'd say in such a case it's OK.
– Jabberwocky
2 hours ago
I'd say in such a case it's OK.
– Jabberwocky
2 hours ago
3
3
Even if the file contains a variable definition, you could still name the file with a
.h ending.– Some programmer dude
1 hour ago
Even if the file contains a variable definition, you could still name the file with a
.h ending.– Some programmer dude
1 hour ago
1
1
Maybe better if you name the file to be included as "file.inc" or "file.c.inc"?
– pmg
1 hour ago
Maybe better if you name the file to be included as "file.inc" or "file.c.inc"?
– pmg
1 hour ago
1
1
Are you aware that every other C file that requires the
#definestuff, also will get its own copy of the array if this file is included?– Gerhardh
1 hour ago
Are you aware that every other C file that requires the
#definestuff, also will get its own copy of the array if this file is included?– Gerhardh
1 hour ago
Why would this be
static const instead of extern const? In these situations, x-macros can be helpful, as long as your programming team won't hurt you for using them. But it's also likely you are doing something wrong, since having hardcoded defines means you need to use these exact constants at compile time. Post some code where the defines are being used.– Groo
1 hour ago
Why would this be
static const instead of extern const? In these situations, x-macros can be helpful, as long as your programming team won't hurt you for using them. But it's also likely you are doing something wrong, since having hardcoded defines means you need to use these exact constants at compile time. Post some code where the defines are being used.– Groo
1 hour ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
6
down vote
You could use designated initializers to initialize the elements of elems without having to know the explicit value of each index identifier (or macro).
const MyElements elems =
[TOTO_IND] = "TOTO", 18, "French",
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
;
The array elements will be initialized the same way, even if you change the order they appear in the source code:
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
If the array length is set automatically from the initializer as above (i.e. by using rather than [NUM_ELEMS]), then the length will be the one more than the maximum element index.
This allows you to keep the index values and external declaration of the elems array in a .h file, and define the elems array contents in a separate .c file.
answered 1 hour ago
Ian Abbott
2,526513
This is the correct answer in modern C. I posted an answer with additional advise based on this.
– Lundin
1 hour ago
This still doesn't prevent OP from writing[TOTO_IND] = "TITI", 27, "English"though.
– Groo
40 mins ago
add a comment |Â
up vote
2
down vote
You should use designated initializes as shown in the answer by Ian Abbot.
Additionally, if the array indices are adjacent as seems to be the case here, you can use an enum instead:
toto.h
typedef enum
TOTO_IND,
TITI_IND,
...
TATA_IND,
TOTO_N // this is not a data item but the number of items in the enum
toto_t;
toto.c
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
And now you can verify the data integrity of the array as whole with a static assert:
_Static_assert(sizeof elems/sizeof *elems == TOTO_N,
"Mismatch between toto_t and elems is causing rain in Africa");
answered 1 hour ago
Lundin
102k16149252
add a comment |Â
up vote
1
down vote
You are defining the const as static. But you want to use it in multiple files. This is a contradiction. The static qualifier needs to be removed.
Here is a suggested solution.
in file.h
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
#define MAX_ELEMS 51
extern const MyElements elems[MAX_ELEMS];
in file.c
#include "file.h"
const MyElements elems [MAX_ELEMS] =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
You can then #include "file.h" in the required .c files.
answered 1 hour ago
Rishikesh Raje
4,3591725
“Contradiction†is not the right word to describe astatic constdesired for use in multiple files. There are some benefits to it. Making the array externally linked instead prevents some optimizations.
– Eric Postpischil
1 hour ago
@EricPostpischil If the array is required in multiple files, making it static will have multiple copies of the array. The OP mentioned that the array had a large size, so this option was disregarded.
– Rishikesh Raje
1 hour ago
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
You could use designated initializers to initialize the elements of elems without having to know the explicit value of each index identifier (or macro).
const MyElements elems =
[TOTO_IND] = "TOTO", 18, "French",
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
;
The array elements will be initialized the same way, even if you change the order they appear in the source code:
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
If the array length is set automatically from the initializer as above (i.e. by using rather than [NUM_ELEMS]), then the length will be the one more than the maximum element index.
This allows you to keep the index values and external declaration of the elems array in a .h file, and define the elems array contents in a separate .c file.
answered 1 hour ago
Ian Abbott
2,526513
This is the correct answer in modern C. I posted an answer with additional advise based on this.
– Lundin
1 hour ago
This still doesn't prevent OP from writing[TOTO_IND] = "TITI", 27, "English"though.
– Groo
40 mins ago
add a comment |Â
up vote
6
down vote
You could use designated initializers to initialize the elements of elems without having to know the explicit value of each index identifier (or macro).
const MyElements elems =
[TOTO_IND] = "TOTO", 18, "French",
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
;
The array elements will be initialized the same way, even if you change the order they appear in the source code:
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
If the array length is set automatically from the initializer as above (i.e. by using rather than [NUM_ELEMS]), then the length will be the one more than the maximum element index.
This allows you to keep the index values and external declaration of the elems array in a .h file, and define the elems array contents in a separate .c file.
answered 1 hour ago
Ian Abbott
2,526513
This is the correct answer in modern C. I posted an answer with additional advise based on this.
– Lundin
1 hour ago
This still doesn't prevent OP from writing[TOTO_IND] = "TITI", 27, "English"though.
– Groo
40 mins ago
add a comment |Â
up vote
6
down vote
up vote
6
down vote
You could use designated initializers to initialize the elements of elems without having to know the explicit value of each index identifier (or macro).
const MyElements elems =
[TOTO_IND] = "TOTO", 18, "French",
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
;
The array elements will be initialized the same way, even if you change the order they appear in the source code:
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
If the array length is set automatically from the initializer as above (i.e. by using rather than [NUM_ELEMS]), then the length will be the one more than the maximum element index.
This allows you to keep the index values and external declaration of the elems array in a .h file, and define the elems array contents in a separate .c file.
answered 1 hour ago
Ian Abbott
2,526513
You could use designated initializers to initialize the elements of elems without having to know the explicit value of each index identifier (or macro).
const MyElements elems =
[TOTO_IND] = "TOTO", 18, "French",
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
;
The array elements will be initialized the same way, even if you change the order they appear in the source code:
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
If the array length is set automatically from the initializer as above (i.e. by using rather than [NUM_ELEMS]), then the length will be the one more than the maximum element index.
This allows you to keep the index values and external declaration of the elems array in a .h file, and define the elems array contents in a separate .c file.
answered 1 hour ago
Ian Abbott
2,526513
answered 1 hour ago
Ian Abbott
2,526513
answered 1 hour ago
Ian Abbott
2,526513
answered 1 hour ago
Ian Abbott
2,526513
2,526513
This is the correct answer in modern C. I posted an answer with additional advise based on this.
– Lundin
1 hour ago
This still doesn't prevent OP from writing[TOTO_IND] = "TITI", 27, "English"though.
– Groo
40 mins ago
add a comment |Â
This is the correct answer in modern C. I posted an answer with additional advise based on this.
– Lundin
1 hour ago
This still doesn't prevent OP from writing[TOTO_IND] = "TITI", 27, "English"though.
– Groo
40 mins ago
This is the correct answer in modern C. I posted an answer with additional advise based on this.
– Lundin
1 hour ago
This is the correct answer in modern C. I posted an answer with additional advise based on this.
– Lundin
1 hour ago
This still doesn't prevent OP from writing
[TOTO_IND] = "TITI", 27, "English" though.– Groo
40 mins ago
This still doesn't prevent OP from writing
[TOTO_IND] = "TITI", 27, "English" though.– Groo
40 mins ago
add a comment |Â
up vote
2
down vote
You should use designated initializes as shown in the answer by Ian Abbot.
Additionally, if the array indices are adjacent as seems to be the case here, you can use an enum instead:
toto.h
typedef enum
TOTO_IND,
TITI_IND,
...
TATA_IND,
TOTO_N // this is not a data item but the number of items in the enum
toto_t;
toto.c
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
And now you can verify the data integrity of the array as whole with a static assert:
_Static_assert(sizeof elems/sizeof *elems == TOTO_N,
"Mismatch between toto_t and elems is causing rain in Africa");
answered 1 hour ago
Lundin
102k16149252
add a comment |Â
up vote
2
down vote
You should use designated initializes as shown in the answer by Ian Abbot.
Additionally, if the array indices are adjacent as seems to be the case here, you can use an enum instead:
toto.h
typedef enum
TOTO_IND,
TITI_IND,
...
TATA_IND,
TOTO_N // this is not a data item but the number of items in the enum
toto_t;
toto.c
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
And now you can verify the data integrity of the array as whole with a static assert:
_Static_assert(sizeof elems/sizeof *elems == TOTO_N,
"Mismatch between toto_t and elems is causing rain in Africa");
answered 1 hour ago
Lundin
102k16149252
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You should use designated initializes as shown in the answer by Ian Abbot.
Additionally, if the array indices are adjacent as seems to be the case here, you can use an enum instead:
toto.h
typedef enum
TOTO_IND,
TITI_IND,
...
TATA_IND,
TOTO_N // this is not a data item but the number of items in the enum
toto_t;
toto.c
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
And now you can verify the data integrity of the array as whole with a static assert:
_Static_assert(sizeof elems/sizeof *elems == TOTO_N,
"Mismatch between toto_t and elems is causing rain in Africa");
answered 1 hour ago
Lundin
102k16149252
You should use designated initializes as shown in the answer by Ian Abbot.
Additionally, if the array indices are adjacent as seems to be the case here, you can use an enum instead:
toto.h
typedef enum
TOTO_IND,
TITI_IND,
...
TATA_IND,
TOTO_N // this is not a data item but the number of items in the enum
toto_t;
toto.c
const MyElements elems =
[TITI_IND] = "TITI", 27, "English",
[TATA_IND] = "TATA", 45, "Spanish",
[TOTO_IND] = "TOTO", 18, "French",
;
And now you can verify the data integrity of the array as whole with a static assert:
_Static_assert(sizeof elems/sizeof *elems == TOTO_N,
"Mismatch between toto_t and elems is causing rain in Africa");
answered 1 hour ago
Lundin
102k16149252
answered 1 hour ago
Lundin
102k16149252
answered 1 hour ago
Lundin
102k16149252
answered 1 hour ago
Lundin
102k16149252
102k16149252
add a comment |Â
add a comment |Â
up vote
1
down vote
You are defining the const as static. But you want to use it in multiple files. This is a contradiction. The static qualifier needs to be removed.
Here is a suggested solution.
in file.h
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
#define MAX_ELEMS 51
extern const MyElements elems[MAX_ELEMS];
in file.c
#include "file.h"
const MyElements elems [MAX_ELEMS] =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
You can then #include "file.h" in the required .c files.
answered 1 hour ago
Rishikesh Raje
4,3591725
“Contradiction†is not the right word to describe astatic constdesired for use in multiple files. There are some benefits to it. Making the array externally linked instead prevents some optimizations.
– Eric Postpischil
1 hour ago
@EricPostpischil If the array is required in multiple files, making it static will have multiple copies of the array. The OP mentioned that the array had a large size, so this option was disregarded.
– Rishikesh Raje
1 hour ago
add a comment |Â
up vote
1
down vote
You are defining the const as static. But you want to use it in multiple files. This is a contradiction. The static qualifier needs to be removed.
Here is a suggested solution.
in file.h
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
#define MAX_ELEMS 51
extern const MyElements elems[MAX_ELEMS];
in file.c
#include "file.h"
const MyElements elems [MAX_ELEMS] =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
You can then #include "file.h" in the required .c files.
answered 1 hour ago
Rishikesh Raje
4,3591725
“Contradiction†is not the right word to describe astatic constdesired for use in multiple files. There are some benefits to it. Making the array externally linked instead prevents some optimizations.
– Eric Postpischil
1 hour ago
@EricPostpischil If the array is required in multiple files, making it static will have multiple copies of the array. The OP mentioned that the array had a large size, so this option was disregarded.
– Rishikesh Raje
1 hour ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
You are defining the const as static. But you want to use it in multiple files. This is a contradiction. The static qualifier needs to be removed.
Here is a suggested solution.
in file.h
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
#define MAX_ELEMS 51
extern const MyElements elems[MAX_ELEMS];
in file.c
#include "file.h"
const MyElements elems [MAX_ELEMS] =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
You can then #include "file.h" in the required .c files.
answered 1 hour ago
Rishikesh Raje
4,3591725
You are defining the const as static. But you want to use it in multiple files. This is a contradiction. The static qualifier needs to be removed.
Here is a suggested solution.
in file.h
#define TOTO_IND 0
#define TITI_IND 1
…
#define TATA_IND 50
#define MAX_ELEMS 51
extern const MyElements elems[MAX_ELEMS];
in file.c
#include "file.h"
const MyElements elems [MAX_ELEMS] =
"TOTO", 18, "French",
"TITI", 27, "English",
...,
"TATA", 45, "Spanish"
You can then #include "file.h" in the required .c files.
answered 1 hour ago
Rishikesh Raje
4,3591725
answered 1 hour ago
Rishikesh Raje
4,3591725
answered 1 hour ago
Rishikesh Raje
4,3591725
answered 1 hour ago
Rishikesh Raje
4,3591725
4,3591725
“Contradiction†is not the right word to describe astatic constdesired for use in multiple files. There are some benefits to it. Making the array externally linked instead prevents some optimizations.
– Eric Postpischil
1 hour ago
@EricPostpischil If the array is required in multiple files, making it static will have multiple copies of the array. The OP mentioned that the array had a large size, so this option was disregarded.
– Rishikesh Raje
1 hour ago
add a comment |Â
“Contradiction†is not the right word to describe astatic constdesired for use in multiple files. There are some benefits to it. Making the array externally linked instead prevents some optimizations.
– Eric Postpischil
1 hour ago
@EricPostpischil If the array is required in multiple files, making it static will have multiple copies of the array. The OP mentioned that the array had a large size, so this option was disregarded.
– Rishikesh Raje
1 hour ago
“Contradiction†is not the right word to describe a
static const desired for use in multiple files. There are some benefits to it. Making the array externally linked instead prevents some optimizations.– Eric Postpischil
1 hour ago
“Contradiction†is not the right word to describe a
static const desired for use in multiple files. There are some benefits to it. Making the array externally linked instead prevents some optimizations.– Eric Postpischil
1 hour ago
@EricPostpischil If the array is required in multiple files, making it static will have multiple copies of the array. The OP mentioned that the array had a large size, so this option was disregarded.
– Rishikesh Raje
1 hour ago
@EricPostpischil If the array is required in multiple files, making it static will have multiple copies of the array. The OP mentioned that the array had a large size, so this option was disregarded.
– Rishikesh Raje
1 hour ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52757696%2fis-it-ok-to-include-c-source-file-for-maintainability-of-embedded-c-code%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I'd say in such a case it's OK.
– Jabberwocky
2 hours ago
3
Even if the file contains a variable definition, you could still name the file with a
.hending.– Some programmer dude
1 hour ago
1
Maybe better if you name the file to be included as "file.inc" or "file.c.inc"?
– pmg
1 hour ago
1
Are you aware that every other C file that requires the
#definestuff, also will get its own copy of the array if this file is included?– Gerhardh
1 hour ago
Why would this be
static constinstead ofextern const? In these situations, x-macros can be helpful, as long as your programming team won't hurt you for using them. But it's also likely you are doing something wrong, since having hardcoded defines means you need to use these exact constants at compile time. Post some code where the defines are being used.– Groo
1 hour ago