So I've been going through some code, and there's some things I can't understand.
I have two header files. One is called 'args.h' and in that there are these statements, amongst others:
#if (defined(__cplusplus) || defined(__STDC__) || defined(c_plusplus))
#define NEW_STYLE 1
#define VOID void
#define ARGS(parenthesized_list) parenthesized_list
#else
#define NEW_STYLE 0
#define VOID
#define ARGS(parenthesized_list) ()
#define const
#endif
#if !defined(EXIT_SUCCESS)
#define EXIT_SUCCESS 0
#define EXIT_FAILURE 1
#endif
In the other header file, function prototypes are declared like this:
#if defined(__cplusplus)
extern "C" {
#endif
extern void yyerror ARGS((const char *s_));
extern int yylex ARGS((void));
extern int yyparse ARGS((void));
extern int yywrap ARGS((void));
#if defined(__cplusplus)
}
#endif
and a bunch of other stuff.
So my questions are:
1> What exactly does #define const do?
2> Why is arg declared in the other header file? Couldn't we simply declare the functions like a normal extern void a(const char *s__)? Or is this simply a preference of style?
Thanks.
This is to allow the code to compile with a pre-standard C compiler. It turns a function prototype into a function declaration, and simply removes const completely.
If you need to use a compiler so ancient that it doesn't understand prototypes or const, you have little choice but to use something like this. Otherwise, you're generally best off eliminating these horrible kludges.
20 years ago, code like this was common and necessary. It seems harder to excuse today, but I suppose there may still be a few platforms for which a reasonably modern compiler isn't available.
That are tweaks to make the code portable among compilers lacking this or that feature
is removing const everywhere (for sure not a good idea if you have a modern compiler)
this has to do with the ANSI C Syntax
Related
I'm looking at some microcontroller C headers and there is code like this:
#define OSCCONL OSCCONL
extern volatile uint8_t OSCCONL __attribute__((__sfr__));
#define OSCCONH OSCCONH
extern volatile uint8_t OSCCONH __attribute__((__sfr__));
#define CLKDIV CLKDIV
extern volatile uint16_t CLKDIV __attribute__((__sfr__));
__extension__ typedef struct tagCLKDIVBITS {...}
What is the purpose of those repetitive "#define A A" ?
As the preprocessor does not know anything about the C language and variables you need to add some definitions know if the variable (variable) will be defined in the C code. You can use those definitions later in the code.
Example:
#if defined(OSCONL)
OSCONL = something;
#endif
And if your microcontroller does not have this register this part of the code will not be compiled. It is a very common technique.
EDIT:
But wouldn't that work the same if it just had #define OSCCONL
The idea is to have the same #define as variable or function name. It makes code consistent and easy to remember.
Otherwise, you would have to have different #define and object name making coding more difficult, as our would have to remember both. In this convention, you can read the documentation of the uC and use the same name to check if this object exists without remembering how the #define is called.
One purpose could be that it can be used in a macro check such as
#ifdef or #ifndef
This allows for conditional compiling where only parts of the source code will be compiled into the binary.
In the code below, I don't understand the defined() function used inside #if; where is it defined?
Can anyone point me to a good resource in C language, where I could go deeper in these kinds of kinds of stuff?
#include <stdio.h>
#define Macro 7
void initMSP(void){
printf("OKay with MSP platform\n");
}
void initKine(void){
printf("Done with Kine\n");
}
//#define KINETICS
#define MSP
int main(){
printf("Hello world program\n");
printf("%d\n",Macro);
#if defined(KINETICS) && !defined(MSP)
initKine();
#elif defined(MSP) && !defined(KINETICS)
initMSP();
#else
#error "Please define a Platform "
#endif
}
defined is not a function. It is a syntactic construct of the C preprocessor, just like #define, #ifdef, and so forth. The C language proper (to the extent that you can divorce C from its preprocessor) never directly interacts with defined. It exists during preprocessing and that's that.
I am going through a C code and I found something like this:
#define __UNUSED__
char buf[MAX_BUF_LENGHT];
int errors=0;
What does this mean?
I am not aware that __UNUSED__ is a predefined preprocessor symbol. So it must be a user defined symbol.
I myself have sometimes (test) code or obsolete code in a c-file that I mark-out with #ifdef BLIEP (and BLIEP is normally not defined), but can put it back into compilation by placing a #define BLIEP. Probably the original author of this code did something similar with __UNUSED__.
I have to turn back to (embedded) C after some lengthy time with C++, and have the following problem:
I have a source module which is included a lot of times, let's call it utilities.h and utilities.c
In it, I have an important array, let's call it
#define IMPORTANT_ARRAY_LENGTH 10000
char important_array[IMPORTANT_ARRAY_LENGTH];
I have a lot of other functions in this utilities module, and they all work fine. However, in one of the other source files, let's call it worker.c, I have to use this array. What is the "official", elegant way to do this, without having to put extern char important_array[IMPORTANT_ARRAY_LENGTH] and the macro definition in the worker.c ?
If I do the following:
utilities.h
#ifndef _UTILITIES_H_
#define _UTILITIES_H_
#define IMPORTANT_ARRAY_LENGTH 10000
extern char important_array[IMPORTANT_ARRAY_LENGTH];
// ...
utilities.c
#ifndef _UTILITIES_C_
#define _UTILITIES_C_
#include "utilities.h"
char important_array[IMPORTANT_ARRAY_LENGTH];
// ...
worker.c
#include "utilities.h"
// ...
important_array[0] = 0;
then my array will be an undefined symbol in worker.c. If I don't use the extern keyword in utilities.h, then of course, it's a duplicate symbol. (Strangely, it compiles with just a warning, and I can see from the linker file that the size is allocated multiple times.)
Do I really have to declare my array in worker.c? I want to keep everything clean, and have all declarations in one place only: in a header file. And I want to have the macro definition only once (this is secondary, because I could use a const, but I want the preprocessor to handle it, and not take up place)
What you have is the canonical way to do it: have an extern declaration in the header file, and define the variable in the .c file.
my array will be an undefined symbol in worker.c
No, it won't. Your code will compile and link just fine.
I often put the definition in the header (this is frowned upon, I know).
It keeps the definition and declaration close together, which is a Good Thing.
/* file.c */
#define FILE_C 1
#include "file.h"
.
/* file.h */
#ifndef FILE_H
#define FILE_H 1
#define BIG_SIZE 13
#if FILE_C
char the_array[BIG_SIZE];
#else
extern char the_array[BIG_SIZE];
#endif
#endif /* FlLE_H */
.
/* other_file.c */
#include "file.h"
There is no risk of doing it wrong: the linker will complain if you do it wrong.
BTW a similar way to basically do the same, but maybe a bit more readable, is:
/* file.h */
#ifndef FILE_H
#define FILE_H 1
#if FILE_C
#define EXTERN /**/
#else
#define EXTERN extern
#endif
#define BIG_SIZE 13
EXTERN char the_array[BIG_SIZE];
...
#undef EXTERN
#endif /* FlLE_H */
Having one declaration (extern...) in each translation unit and exactly one definition is the most elegant way to do this.
So leave the extern char important_array in the header and char important_array in one of the .c files.
Create a new function at utilities.c called something like "get_important_array" that just returns a pointer to array and put the prototype at utilities.h. After that, when you put the utilities.h at worker.c you'll have important_array access in a simple, and organized way.
// common.h
// This is foo function. It has a body.
__inline void foo() { /* something */ }
// a.cpp
#include "common.h" // for foo function
// Call foo
// b.cpp
#include "common.h" // for foo function
// Call foo
I would like to inline the foo function only when I build for release. I don't want to inline functions for Debug build.
I tried it but linker errors annoyed me.
In this case, foo function's body is defined in common.h header file.
so if I just do
//common.h
#if !defined(_DEBUG)
__inline
#endif
void foo() { /* something */ }
It will be met a link error in DEBUG build. Because two modules try to include common.h.
I have no idea to solve it.
Is it possible?
The "easy" solution would be this:
#if !defined(_DEBUG) || defined(NDEBUG)
#define INLINE inline
#else
#define INLINE static
#endif
static is necessary to silence linking errors and get around the One Definition Rule.
A better solution would be to simply disable inlining project wide for debugging. GCC supports the -wno-inline-functions and -fno-inline-small-functions options to counteract those optimizations, and it also does not enable inlining for -O1 or lower (and probably -Os as well). Most compilers have similar options.
I call the latter a better solution because it should instruct the compiler to ignore the inline hint, eliminating the need for pesky preprocessor directives.
The fundamental thing to realize is that the inline keyword (or Microsoft's __inline extension for C - since MSVC doesn't support C99) is essentially a pass to violate the one definition rule. If you think about it - that's all it really is, since the compiler is under no obligation to actually perform any inlining.
So, when you have an inline function you're allowed to have the function defined in more than one module. In fact, you're obligated to have it defined in any module that actually uses the function.
However, if you don't declare the function as inline, you have to ensure that you have no more than one definition (exactly one if it actually gets used). For non-member functions (all function in C), there are a few ways around this:
declare the function as static to change it's linkage to internal (note that you can have static inline functions to begin with).
in C++ you can place them in an anonymous namespace (which has an effect similar to declaring the static)
you can use preprocessor manipulation to handle this. It's kind of ugly, but it works, and I've seen the technique used successfully in the wild. Whether it's worth the effort is another thing altogether - you'll have to decide that yourself.
Basically, what you need to do is have an implementation of the function in a separate .c file, just like if you were following the tradition of a-single-function-per-module coding standard (actually you can do this just as well putting several inline functions in the .c module - but they should all be inline or not inline as a group to keep things from getting too out of hand). The implementation of the function needs to arrange to be able to be included in a header - so it needs include guards, just like any other header. Then you use the preprocessor to conditionally include the implementation as part of the header when you want inline functions (so the implementation will be available to all modules), but don't include it if you're not inlining (so you follow the one definition rule in that case):
The common.h header:
// common.h
#ifndef COMMON_H
#define COMMON_H
#ifdef RELEASE
#define USE_INLINE
#define INLINE __inline
#else
#define INLINE
#endif
INLINE void foo(void);
#ifdef USE_INLINE
#include "foo.c"
#endif
#endif /* COMMON_H */
The implementation of foo():
// foo.c
#ifndef FOO_C
#define FOO_C
#include <stdio.h>
#include "common.h"
INLINE void foo()
{
printf("foo\n");
}
#endif /* FOO_C */
And an example program:
// main.c
#include<stdio.h>
#include "common.h"
int main()
{
foo();
return 0;
}
Now if you compile for release:
cl /DRELEASE main.c foo.c
foo() will be inline (or __inline as the case may be).
If you compile for non-release:
cl test.c foo.c
you have a non-inline foo().
And both the compiler and linker are happy in either case.
All that said, I kind of like the suggestion to maybe redefine INLINE to be static for debugging purposes.
However, ultimately I'm not sure I see the point to any of this really - modern debuggers are able to step through functions that are inline, and the debugger probably won't inline function calls if you disable optimizations. So you can set breakpoints inside the inline function as well and have it work fine in non-optimized builds.
I'm not sure exactly what you're end-goal in this really is. What's the drawback to leaving the functions as inline in debug/non-optimized builds?
#ifdef RELEASE
#define INLINE __inline
#else
#define INLINE
#endif
Then
// common.h
INLINE void foo() { /* something */ }
// a.cpp
#include "common.h" // for foo function
// Call foo
// b.cpp
#include "common.h" // for foo function
// Call foo
then define RELEASE for the release version. of course you can see from this there are lots of ways to do it.
You can't declare header only functions as non-inline. You could declare them as static (a.k.a. C-style static), but that will generate a copy of the function (including local static variables, if any) in each translation unit. A better solution is to leave it as inline. In debug mode when optimizations are disabled compilers usually don't inline any functions.
In most cases release flags are not defined. Typically debug flags are defined.
_DEBUG is defined by most compilers, so there is no need to define a release flag:
More practical:
#ifndef _DEBUG
__inline void foo() { /* something */ }
#else
//some alternative
#endif
Use compiler conditionals and define a compile time flag.
Example:
#ifdef RELEASE_BUILD_FLAG
//Run inline function
#else
//some alternative
#endif