Where to create macros in C?

Asked

Viewed 661 times

5

In terms of good programming practices, if I want to create a macro, for example, a macro that has about 30 lines of code, I should implement it in the archive .c or in the .h? What is good practice?

2 answers

9


In terms of good practice you must do what is right for each situation. For this you need to gain experience. And has nothing worse to gain experience than reading "manuals" that say what is right or wrong to do because they give cake recipes and do not teach.

That being said, macros should be avoided as much as possible. In current compilers they rarely need to be created. And if a macro has 30 lines there is certainly something wrong with it. Create a function and dot. Today I think there is little case of using macro, even for a line, the reason I still give I do not like.

Why the macro instead of the function? To have more performance? It may get even worse. The compilers optimize the functions and they are "linearized" as with the macro, if it is really feasible (and the compiler knows this better than the programmer in almost all situations), with numerous advantages over the macro.

But if you want to insist on the error, in thesis nothing matters where you put it. Only that the default is that you use files with extension .h to include in other files. And since the macro source needs to be available when the code that uses it is compiled, it is best to include a file header. By the way, this is another disadvantage of the macro.

In C++ macros are absolutely unnecessary. In C there are still some rare cases where they are interesting, but not to replace complex codes that should be in a function.

In the OS has already been shown some problems of macro.

  • But if I have a block of code that will be called by the system constantly, it would not be useful, in this case use macro?

  • 2

    Almost certainly not. And if it’s useful, the compiler will know when to do it better than you. In this case it is almost certain that you will increase the size of the randomly generated code, this can cause performance problems (although small) and the gain will be tiny... in theory. In practice the balance may be negative.

  • But macro, is loaded along with the program, which makes your call faster. Anyway, I’m still not convinced that it’s better to use functions than macros in these rsrs situations, if you can give a practical example.

  • Then use, the problem will be yours. You are trying to do micro-optimization. which almost always either brings the opposite result or a better result so small that it does not make up for the effort. http://answall.com/q/29507/101

  • 1

    If your question is for a real case and you are not convinced with the explanation above, I suggest you benchmark by comparing the two solutions and post here a comparative. You’ll hardly find any significant difference, since as @bigown said, the compiler already does optimizations. Context is the key word: if you want such optimized code, for such a specific situation, you can turn to Assembly. As this is an exception, in my opinion, one should always opt for the clearest code, even if there is some (often unproven) performance loss.

4

First point: avoids the use of macros as functions, makes real functions.

Second point: in general macros should be created in header files as they define identifiers to be used by external components.

But in your case, I don’t think that’s what’s intended. You only want to create an "internal" macro, which is not to be used by other code files that make use of your functions.

You can place the macro in a ". c" extension file, or in a private ". h extension file".

#include "header.h"         // contem coisas publicas
#include "header-private.h" // contem coisas privadas

If you choose the real functions solution and want to make them private ... do not put the prototype of those functions in the header file and define them with static

static int private_big_function(int x) { return x + 42; }
  • Because I must avoid?

  • Because function macros bring more problems than the problems they solve.

  • What kind of trouble?

  • 1

    Mainly code interpretation problems when you need to change the "function" later. A 35-line macro is much more difficult to understand than a function (with proper spacing, with comments) with 100 lines.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.