Tablica zdefiniowana w indywidualnym dla niej pliku: .c czy .h?

Mam zdefiniowaną stałą tablicę:

const int arr[234] = {1, -44, 137, 23, -9, 9, ... };

w środku jest pewny niezmienny liczbowy pattern istotny dla działania programu.

Tablica będzie używania w trzech funkcjach w trzech różnych plikach:

• foo1() w file1.c
• foo2() w file2.c
• foo3() w file3.c

Ponieważ definicja tej tablicy jest obszerna, chciałbym stworzyć specjalny wydzielony plik dla niej: arr.c \ arr.h.

Pytanie co jest lepszym rozwiązaniem?

Trzymanie definicji:

const int arr[234] = {..};

w arr.c, a w arr.h:

extern const int arr[234];

i następnie includowanie arr.h do plików foo1.c, foo2.c i foo3.c.
...czy może od razu trzymać definicję tablicy w arr.h?

Spotkałem się z dwoma opiniami stricte adresującymi mój problem, chciałbym zasięgnąć dodatkowy feedback.

Jeśli jest obszerna to trzymałbym ją w osobnym pliku (arr.c). Mniej roboty dla linkera, a w przypadku modyfikacji rekompilujesz tylko jeden TU.

@kq: Do tej pory miałem definicję w odosobnionym do tego pliku .c, ale spotkałem się z taką opinią adresującą konkretnie mój problem:

I also saw a variable declared in a c-code file called arr[234] = {........}, this is a configuration, and should go in a header file. Leave the c-code files for functional code and the headers for all your different kinds of configurations and namespace management.

Czyli ten cytat to po prostu niekoniecznie musi być prawda?

Deklarowanie tablicy jako wypełnionej danymi nie czyni jej magicznie "konfiguracją" - szczególnie biorąc pod uwagę dane przedstawione w pierwszym poście. W każdym raize, nie wiem czy byłbym zadowolony trzymaniem konfiguracji zahardkodowanej w programie. Możliwe, że w tamtym przypadku miało to sens, ale jeśli pytasz o generalne rady - duże tablice z danymi chowałbym w plikach .c/.cpp, albo poza binarką (t.j. wczytywał w czasie działania programu)

kq napisał(a):

W każdym raize, nie wiem czy byłbym zadowolony trzymaniem konfiguracji zahardkodowanej w programie.

Jeśli ta konfiguracja jest z zasady niezmienna – w sensie że użytkownik nie potrzebuje nigdy w niej grzebać, albo nie chcemy żeby grzebał – to moim zdaniem jej zahardkodowanie jest uzasadnione.
Jako przykład mogę podać różnego rodzaju kodeki (np. mp3) gdzie są potrzebne różne tablice współczynników. Jest to w pewnym sensie konfiguracja, ale wyciąganie jej gdzieś na widok użytkownika nie ma sensu, bo i tak (przynajmniej w teorii) te liczby się nigdy nie zmieniają.

Skoro już o includach, mam taką strukturę programu:

Pliku key_codes.c nie ma. W pliku key_codes.h mam sporą listę definów. Korzystam z wszystkich tych definów w keys_pqueue.c. Ale z jednego defina (niekoniecznie wiadomo którego) z tego pliku key_codes.h korzystam w recording.c.

Pytanie: dlaczego w takiej sytuacji muszę specjalnie includować key_codes.h do recording.c, żeby skorzystać z tego defina? Mam przecież zchainowane includy i jest to implicitly zaincludowane do tego pliku tak czy siak. Czy tak to po prostu nie działa?

Azarien napisał(a):

Jeśli ta konfiguracja jest z zasady niezmienna – w sensie że użytkownik nie potrzebuje nigdy w niej grzebać, albo nie chcemy żeby grzebał – to moim zdaniem jej zahardkodowanie jest uzasadnione.
Jako przykład mogę podać różnego rodzaju kodeki (np. mp3) gdzie są potrzebne różne tablice współczynników. Jest to w pewnym sensie konfiguracja, ale wyciąganie jej gdzieś na widok użytkownika nie ma sensu, bo i tak (przynajmniej w teorii) te liczby się nigdy nie zmieniają.

Jasne, ale jeśli jest tej konfiguracji odpowiednio dużo, to nie widzę powodu "zaśmiecania" nagłówków. Możesz to powiedzieć np. o parametrach generatorów pseudolosowych z <random> w C++, gdzie std::mt19937 to alias dla std::mersenne_twister_engine<std::uint_fast32_t, 32, 624, 397, 31, 0x9908b0df, 11, 0xffffffff, 7, 0x9d2c5680, 15, 0xefc60000, 18, 1812433253>, a std::mt19937_64 to td::mersenne_twister_engine<std::uint_fast64_t, 64, 312, 156, 31, 0xb5026f5aa96619e9, 29, 0x5555555555555555, 17, 0x71d67fffeda60000, 37, 0xfff7eee000000000, 43, 6364136223846793005>, ale to są detale implementacyjne, które byłyby ukryte w osobnym pliku gdyby nie fakt, że ukryte być nie mogą (bo szablon). Anyway, napisałem jedynie że umieszczanie danych w nagłówkach na pewno nie byłoby moim pierwszym (ani drugim) pomysłem, a nie że jest to zbrodnia.