2

Essentially what I want to do is the C equivalent of:

translation_unit_list.cpp

std::vector<std::string> list;
bool addListItem(std::string str){
    list.push_back(str);
    return true;
}
int main(int argc, char **argv){
  for(std::string translation_unit_name : list){
    cout << translation_unit_name << endl;
  }
  return 0;
}

some_file.cpp

static bool initialized = addListItem("some file!");

some_file2.cpp

static bool initialized = addListItem("some other file!");

this way, translation_unit_list knows every translation unit that was compiled into the final executable. this allows the user to selectively compile what they want to be included. is there a way of achieving the same result with c?

Example desired behavior:

g++ -o exec1 translation_unit_list.cpp some_file.cpp 
./exec1
some file!

g++ -o exec1 translation_unit_list.cpp some_file2.cpp 
./exec1
some other file!

g++ -o exec1 translation_unit_list.cpp some_file.cpp some_file2.cpp 
./exec1
some file!
some other file!
jxh
  • 69,070
  • 8
  • 110
  • 193
chacham15
  • 13,719
  • 26
  • 104
  • 207
  • 1
    To a first approximation, the answer is "NO". Second and subsequent approximations come up with slightly less emphatic denials — it is hard enough work that if you want to do it, you use C++ where it is readily manageable, rather than in C where it isn't. – Jonathan Leffler Feb 14 '20 at 06:50
  • A Turing-complete language like C can implement any kind of container. – Some programmer dude Feb 14 '20 at 06:52
  • 1
    A bigger problem is when you say "this allows the user to selectively compile what they want to be included". This can't be done. Once a program is compiled and linked, it's a fixed executable unit that can't be "selectively" modified. If you want dynamic loadable modules, look into *shared libraries*. – Some programmer dude Feb 14 '20 at 06:53
  • @Someprogrammerdude does the example help clarify the desired behavior? – chacham15 Feb 14 '20 at 06:58
  • If you accept there is no portable solution in C, can you provide a compiler and operating system for a system specific solution? – jxh Feb 14 '20 at 07:05
  • Not really, since I fail to see what problem it's supposed to solve. If you want different executable using different sets of source-files, then configure your build-system to support it (for example by having multiple executable targets, each listing a valid set of source files). But that's not to mention that all symbols used in a program *must* be defined. So if e.g. `some_file2.cpp` defines the function `foo` and it's used somewhere else, then the linking will fail if you don't include `some_file2.cpp` when building. – Some programmer dude Feb 14 '20 at 07:08
  • @jxh if there is no cross platform solution, then are there ways of doing this with gcc/clang/msvc? – chacham15 Feb 14 '20 at 07:16
  • If the code in `translation_unit_list.cpp` uses a symbol from `some_file2.cpp`, then `g++ -o exec1 translation_unit_list.cpp some_file.cpp` will give you linker errors. There's simply no easy way around that, besides dynamically loaded modules (a.k.a. shared libraries/shared objects) and pointers initialized at runtime. – Some programmer dude Feb 14 '20 at 07:17
  • There's also the problem that you can't use functions as initializers in C for global variables. Global variables iniitalizers must be compile-time constant expressions. You could possibly use "constructor" or "initialization" functions/variables which will be called before the `main` function is called, but note that these are very compiler-specific and will very likely be very different between e.g. GCC and MSVC. – Some programmer dude Feb 14 '20 at 07:19
  • 3
    If you agree that [this answer](https://stackoverflow.com/a/2390626/315052) works for you, I can mark this question as a duplicate. – jxh Feb 14 '20 at 07:21
  • 1
    I thought your original question was quite clear. I think I mostly followed why you want to do something like this, but there are lots of reasons to want a global constructor, so I didn't really need to hear your particular motivation. Do realize, though, the naysayers were still trying to help. – jxh Feb 14 '20 at 07:35

0 Answers0