1

I am working on a personal project and I only want to expose 3 ou 4 function. One of the problems of this is that my .c file is getting more and more static functions. Currently it already has 21 static functions.

What would be the best way to organize a .c file that contains lots of static functions? Is it ok (good practice) to maybe separate those static functions into their own .c files and then just include them in the main .c file? I would prefer an approach where I could have separate file so that it is simpler to move from one function to another (no scrolling just switching between files).

Thanks

EDIT

For a better understanding of the problem here is a direct link to the .c file where I am experiencing the difficulty of managing the static functions:

https://github.com/AntonioCS/mustache/blob/master/src/mustache.c

AntonioCS
  • 8,335
  • 18
  • 63
  • 92
  • I don't think there is anything wrong with including the files. – 5gon12eder Sep 18 '14 at 17:04
  • This is not a good question for Stackoverflow... however... it is not unusual for a file to have many static functions to hide functionality you want to keep private. Sort of like private methods in a class, in C++. One way would be to consider if you can rearrange so functions which are related stay in the same C file. – Prof. Falken Sep 18 '14 at 17:04
  • @5gon12eder, technically no, however, it's generally frowned upon to include code. – Prof. Falken Sep 18 '14 at 17:04
  • 1
    I'd rather use a “generally frowned upon” technique if it helps write better structured and maintainable code in my particular case. It depends on the actual circumstances, of course. – 5gon12eder Sep 18 '14 at 17:07
  • why you are not satisfying with static functions? if they are necessary, let them be. they won't corrupt the global namespace anyway. i think it's the right way to organize code using bunch of static functions(as long as you don't copy some of them around). – Jason Hu Sep 18 '14 at 17:15
  • @HuStmpHrrr I don't understand your question. The problem I have is that I am starting to have too many static functions and it's getting complicated to navigate in the code. It's hard to scroll up and down, it's much simpler to just change files – AntonioCS Sep 18 '14 at 18:21
  • @Prof.Falken Where should I post this question? I want to include code because I still want the functions to be hidden (static) but have everything in one .c file is getting complicated – AntonioCS Sep 18 '14 at 18:23
  • 1
    @AntonioCS: How about uinsg a editor that supports folding, tags and scope navigation? – datenwolf Sep 18 '14 at 18:30
  • @AntonioCS oh i see. so include then. – Jason Hu Sep 18 '14 at 18:36
  • This question belongs to codereview.stackexchange.com – Alexandre C. Sep 18 '14 at 18:43
  • 2
    Note: suggest `pmustache mustache_init()` --> `pmustache mustache_init(void)` – chux - Reinstate Monica Sep 18 '14 at 18:45
  • @datenwolf I use netbeans and it does support folding but every time you add code and the code analysis kicks in the folds expand. – AntonioCS Sep 18 '14 at 20:36

4 Answers4

3

Including can work to split apart a large compilation unit into multiple files. However, I strongly discourage naming the included files .c, because that extension indicates a separate compilation unit both to tools and other developers. Consider naming them something like .inl instead.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
1

With a large set of functions, some static, some not, the problem can reach into 100s of functions. To manage that namespace consider these 2 approaches

  1. Split the static functions into 2 groups: truly static ones that exist only in the one .c file that needs it. They use the static keyword.

    A 2nd group of functions that exist in various .c files like your other global functions. They do not use the static keyword. These functions should also begin with mustache_. The difference between these and your other global functions is that the include file that declares them is private to your code and not public. So code has mustache.h and mustache_private.h.

    This technically pollutes the global namespace, but since a user of your "mustache" objects needs, in general, to avoid collisions with any object beginning with mustache_, there will be no surprising conflict with these "private" functions.

  2. 2nd approach is to use library management of your mustache routines to control the names visible to the rest of code. This solution is platform/compiler specific.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
0

organizing a C program to reduce global calls, means that you want to modularize the program logic and have each module resposible to for its own data & functions, thats called encapsulation its a OOP principle. Since your already familiar with C , just read about OO with C++, and update your code base, unless there are technical constraits.

cyber101
  • 2,822
  • 14
  • 50
  • 93
  • What are you saying? I should just change to c++ to help me with the static functions?? – AntonioCS Sep 18 '14 at 20:38
  • @AntonioCS, Im just suggesting that you could achieve better organization with proper C++, if it is technically possible for you. I have seen seen C programs grow out control with 10,000+ lines of code & files that have 1000+ lines of code each with static calls everywere. With proper Object Orientation you could create classes that encapsulate methods(functions) & data that they are resposible for & nothing more. – cyber101 Sep 18 '14 at 21:44
0

If your project is compiled (on Linux) into a shared library (not an executable, or a static library) you could use the visibility pragmas and function attributes. You want to declare all the internal functions with the hidden visiblity. So if your libaa.so is compiled from a1.c and a2.c with some "hidden" function h, that h function -declared in some private header as e.g. void h(int) __attribute__ ((visibility ("hidden"))); is visible inside a1.c (where it could be also defined) & a2.c but not inside any outside program linking libaa.so ...

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547