Dotaz: Můžu v céčku inizializovat pole mimo funkci?

[sad]

tímto způsobem:

int pole[3];
pole[0] = 666; pole[1] = 777; pole[2] = 888;

int main()
{
return 0;
}

Vím, že by to šlo udělat int pole[3]= {666, 777, 888}; jenže tenhle způsob mi nevyhovuje, jelikož těch prvků v poli mám hodně a rád bych viděl jejich indexy kvůli přehlednosti.

---

---

Odpovědi

[Tarmaq]

k cemu to ma byt dobre? nemuze to byt takto?

int main()
{
    int pole[3];
    pole[0] = 666;
    pole[1] = 777;
    pole[2] = 888;
    return 0;
}

asi uplne nerozumim otazce

[sad]

Právě, že takhle to nechci. Protože mám velké množství slov, které je uloženo v poli řetězců char *pole[30]; a abych ten zdroják trochu zpřehlednil, rád bych dal ty řetězce do jiného souboru a inkludoval ho #include "texty.c", jenže v tom jiném souboru jsou inicializace mimo funkci a překladač hlásí chybu.

[Martin Tůma]

rád bych dal ty řetězce do jiného souboru a inkludoval ho #include "texty.c", jenže v tom jiném souboru jsou inicializace mimo funkci a překladač hlásí chybu.

Includování vůbec nemusí být na začátku souboru, klidně je možné (čímž neříkám, že je to vhodné!) to napsat takto:

int main()
{
    int array[3];
    #include "array.c"

    return 0;
}

a v array.c mít:

array[0] = 0;
array[1] = 1;
array[2] = 2;

Je potřeba si uvědomit, že preprocesor při #include prostě jenom vkládá obsah souboru na dané místo, nic víc.

[Josef Kufner]

A co si udělat preprocesor, který převede např. CSV na C? Je to jen o seřazení, vyplnění mezer nulama a trochy formátování. A třeba by se dalo použít i lepší editor (záleží na datech).

Ono totiž tohle přiřazování je výrazně pomalejší než inicializace při deklaraci pole (benchmark jsem nedělal, ale mělo by to tak být). Takže při větším objemu dat by to mohlo zdržovat start programu.

[Martin Tůma]

Ono totiž tohle přiřazování je výrazně pomalejší než inicializace při deklaraci pole (benchmark jsem nedělal, ale mělo by to tak být). Takže při větším objemu dat by to mohlo zdržovat start programu.

Nemyslim, že by se to mělo lišit, dobrej kompilátor by to měl přeložit stejně. To naplnění pole datama se musí při startu programu provést tak jako tak.

[Šangala]

Protože si myslím totéž co Josef Kufner v druhém odstavci a protože bych nečekal (dokonce je mi to proti srsti), že by compiler optimalizoval takovou věc, tak jsem si zkusil malý test a gcc-čko se chová tak jak bych čekal, tedy je v tom rozdíl (samozřejmě nepatrný, ale jasně měřitelný) a co mě překvapilo, je citelný rozdíl v době kompilace.
gcc verze 4.3.2 na slabším PC mi dalo tyto výsledky:

Results:
 Normal {}, compile: 0.205938; run: 0.003925
 Assign [], compile: 1.220017; run: 0.004166
Binary filesize:
-rwxr-xr-x 1 imega users 139K 2011-11-25 16:00 ./normal
-rwxr-xr-x 1 imega users 331K 2011-11-25 16:01 ./assign

PS: Zdroje přiloženy a ./test.bash je třeba spustit z aktuálním adresáře v rozbalené složce.

[pavlix]

Mohl jsi přiložit alespoň informaci o tom, jak se kompilace spouští, nebudu kvůli tomu stahovat .tar.gz a rozbalovat.

protože bych nečekal (dokonce je mi to proti srsti), že by compiler optimalizoval takovou věc

Já bych čekal, že při některé volbě optimalizace bude kompilátor takovouto věc optimalizovat. Protože to jde.

[l4m4]

A co když je tam někde funkce s __attribute__(constructor), která to pole čte, a čeká, že bude v tu chvíli plné nul? Nebo cokoli podobného. Kompilátor to může zoptimalizovat pouze v případě, že je výsledný kód ekvivalentní.

[Šangala]

Tady se jedná opravdu jen o (v případě těch testů):

int main(int argc, char **argv) {
  int array[MAX_ARRAY]={
    1,  //0
...
    32768  //32767
  };
  if(argc == 2)
  {
    int n = atoi(argv[1]);
    if((n < 0)||(n >= MAX_ARRAY))
      printf("Bad 1st parameter (0 - 32767)\n");
    else printf("%d\n",array[n]);
  } else printf("Bad 1st parameter (0 - 32767)\n");
  return 0;
}

a

int main(int argc, char **argv) {
  int array[MAX_ARRAY];
  array[0] = 1;
...
  array[32767] = 32768;
  if(argc == 2)
  {
    int n = atoi(argv[1]);
    if((n < 0)||(n >= MAX_ARRAY))
      printf("Bad 1st parameter (0 - 32767)\n");
    else printf("%d\n",array[n]);
  } else printf("Bad 1st parameter (0 - 32767)\n");
  return 0;
}

PS: ten výpis dole je tam jen pro jistotu aby nedošlo k nějaké nechtěné optimalizaci

[pavlix]

A co když je tam někde funkce s __attribute__(constructor), která to pole čte, a čeká, že bude v tu chvíli plné nul?

Tak minimálně u lokálních proměnných ta inicializace může klidně proběhnout tak nebo tak. Je to sice odchýlení od samotného dotazu,

Kompilátor to může zoptimalizovat pouze v případě, že je výsledný kód ekvivalentní.

Záleží v jaké ekvivalenci, že :). Asi nepožaduješ, aby byl výsledný kód totožný, a pokud není totožný, je v něm nějaká odlišnost, která u céčka vždy může vést na odlišnou funkcionalitu, pokud se sejde s nějakou chybou... takže tohle tvrzení je idealisticky správné, ale dost ošemetné.

[pavlix]

Kus jsem omylem nedopsal...

Je to sice odchýlení od samotného dotazu, ale to už je naše vlákno. Takže hodně záleží, jestli se držíš původního požadavku, a taky jestli je opravdu použit konstruktor, nebo jestli je výsledkem program s funkcí main().

[l4m4]

To je celkem jedno, program s přiřazováním v main() je progra, který do té paměti zapíše hodnoty po spuštění funkce main(). Kompilátor může například optimalizovat pořadí, protože to dá ekvivalentí program, nebo to přiřazení po hodnotách změnit na nakopírování bloku paměti z .rodata, ale nemůže je tam přiřadit někdy jindy. Přehnaná (příliš optimisitická) optimalizace je jedna z velmi častých a záludných chyb v kompilátoru.

[pavlix]

Takže?

[Šangala]

Mohl, chtěl a zapomněl jsem.
Níže uvedené výsledky (ty výše na které jsi odpověděl jsou z rozepsaného textu, kde jsem měl drobnou chybu při počítaní průměru a nevím jak jsem jej odeslal ) jsou bez optimalizace tedy jen:
gcc files.c -o files
Problém mé zkušebny (což jsem chtěl taky naspat, ale dělám více věcí najednou, mám v hlavě jen jedno jádro s minimem chybující paměti…) je, že pokud ten test, který běží 16× pro každou variantu, bych chtěl spustit s -O1 až -O3 tak to pojede kvůli compilaci „dlouho“ (což by napovídalo, že pro gcc-čko varianta [] není vhodná pro rcyhlou kompilaci).
Takže výsledek jen z měření 1× při gcc files.c -O1 -o files:

Results:
 Normal {}, compile:   0.210428; run: 0.003084
 Assign [], compile: 189.525205; run: 0.003943
Binary file size:
-rwxr-xr-x 1 imega users 139K 2011-11-25 16:52 ./normal
-rwxr-xr-x 1 imega users 331K 2011-11-25 16:56 ./assign

A výsledek jen z měření 1× při gcc files.c -O3 -o files:

Results:
 Normal {}, compile:   0.217521; run: 0.003655
 Assign [], compile: 199.537881; run: 0.003962
Binary file size:
-rwxr-xr-x 1 imega users 139K 2011-11-25 16:57 ./normal
-rwxr-xr-x 1 imega users 331K 2011-11-25 17:00 ./assign

Je tam vidět i nelogický rozptyl u '{}' a O1 a O3, ale jsou to tak malé časy a měření bylo jen jedno, tak bych tomu nepřikládal váhu.
Že optimalizace je možná, je nasnadě, ale je to C-éčko, které by mělo dělat co chci já a pokud řeknu, že chci kus neinicializované paměti a pak ji inicializuji jako pole po jednom, tak by to tak mělo být - ale není se třeba o tom přít .

[l4m4]

pokud řeknu, že chci kus neinicializované paměti a pak ji inicializuji jako pole po jednom

Kdyby byla neinicializovaná (tedy s nedefinovaným obsahem), nic by nebránilo tomu, aby ,náhodou` od začátku obsahovala správné hodnoty. Ale je inicializovaná na nulu.

[Šangala]

Od kdy? (tam není žádné new, případně malloc a memset)

#include <stdio.h>
int main(void){
  int a[16];
  int i;
  for(i=0;i<16;i++)
    printf("%d\n",a[i]);
  return 0;
}

Vypsalo to nuly? Ano stát se to může, ale obecně to vypíše cokoliv.

[Michal Kubeček]

V tomto případě ano, ale pokud byste to pole deklaroval jako static nebo ho deklaroval globálně (mimo funkci), bylo by podle normy inicializované nulami.

[Šangala]

To je pravda, ale odklon od původního zadání, je na začátku tohoto vlákna, kde je proměnná ve fci main.

[l4m4]

To není žádný odklon, to je korekce odklonu, viz původní dotaz, kde je proměnná mimo funkce (file scope).

[Michal Kubeček]

Ono si bohužel ani dost programátorů, kteří v C píší, neuvědomuje, jak podstatný rozdíl je mezi tím, jestli se to pole nadeklaruje "ve funkci" nebo "mimo ni".

[Šangala]

Je zbytečné se o tom dohadovat co to je.
Původní dotaz se podle mě vyčerpal odpovědí.
Já jsem nereagoval na původní dotaz, ale na věci z tohoto vlákna, proto mě ani nenapadlo, že se vracíme k původnímu dotazu, takže jestli „Od kdy?“ bylo moc ostré, tak sorry, ale byl jsem překvapen…

[Šangala]

Příloha:

• initatest.tar.gz (326402 bytů)

Protože si myslím totéž co Josef Kufner v druhém odstavci a protože bych nečekal (dokonce je mi to proti srsti), že by compiler optimalizoval takovou věc, tak jsem si zkusil malý test a gcc-čko se chová tak jak bych čekal, tedy je v tom rozdíl (samozřejmě nepatrný, ale jasně měřitelný) a co mě překvapilo (aniž by mě to před tím napadlo), je citelný rozdíl v době kompilace.
gcc verze 4.3.2 na slabším PC mi dalo tyto výsledky:

Results:
 Normal {}, compile: 0.193979; run: 0.003683
 Assign [], compile: 1.155712; run: 0.003907
Binary file size:
-rwxr-xr-x 1 imega users 139K 2011-11-25 16:16 ./normal
-rwxr-xr-x 1 imega users 331K 2011-11-25 16:16 ./assign

PS: Zdroje přiloženy a ./test.bash je třeba spustit z aktuálním adresáře v rozbalené složce. A vypíše to 32× 18124 a pak výsledek…

[Šangala]

Ups, nevím jak se mi double-post podařil, pokud se někdo dívá, klidně ten předchozí smažte… dík.

[Šangala]

Příloha:

• initatest.tar.gz (821622 bytů)

Není to důležité, ale když už jsem to udělal a možná to někdy někoho bude zajímat, když bude honit milisekundy .
Test jsem doplnil o uvedenou inicializaci i s indexy a také o deklaraci proměnné jako globální.
Závěr je jednoduchý, každý kód generuje jiné výsledné kódy, ale rozdíly v čase provádění jsou minimální a z logiky věci se můžou rozdíly kumulovat jen opakovaný stejným zápisem, takže by se výkonově projevily jen na (nereálně) velmi dlouhém kódu.
Nicméně nárust času kompilace při „přiřazení po jednom“ je extrémní, zvláště při optimalizaci -O1 a výš (téměř 1000× pomalejší a s nárokem na paměť cca 50MiB - ostatní způsoby neměřitelná spotřeba paměti), tudíž použití tohoto způsobu je nevhodné.
Jedná se o pole 32768 int-ů (a test byl spuštěn na jiném stroji než předchozí).
Spuštěno jako time ./test.bash 8 -O0 -O1 -O2 -O3, což znamená každý test 8× pro každý optimalizační level.

model name	: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
model name	: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz

Linux xxxxxx 2.6.26-2-amd64 #1 SMP Wed Sep 21 03:36:44 UTC 2011 x86_64 GNU/Linux

gcc (Debian 4.3.2-1.1) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Step/Steps: 80/320  
Results, options '-O0':
 Global Normal {},      compile:   0.146788; run: 0.002238
 Global Normalext {[]}, compile:   0.179682; run: 0.002302
 Normal {},             compile:   0.158238; run: 0.002349
 Normalext {[]},        compile:   0.181676; run: 0.002380
 Assign [],             compile:   0.795377; run: 0.002504
Binary file size:
 140267 2011-11-26 18:28 ./normalglb
 140270 2011-11-26 18:28 ./normalextglb
 140439 2011-11-26 18:28 ./normal
 140442 2011-11-26 18:28 ./normalext
 336762 2011-11-26 18:29 ./assign
Step/Steps: 160/320  
Results, options '-O1':
 Global Normal {},      compile:   0.156615; run: 0.002246
 Global Normalext {[]}, compile:   0.186430; run: 0.002221
 Normal {},             compile:   0.163063; run: 0.002709
 Normalext {[]},        compile:   0.203456; run: 0.002376
 Assign [],             compile: 134.493765; run: 0.002863
Binary file size:
 140237 2011-11-26 18:29 ./normalglb
 140240 2011-11-26 18:29 ./normalextglb
 140442 2011-11-26 18:29 ./normal
 140445 2011-11-26 18:29 ./normalext
 369484 2011-11-26 18:47 ./assign
Step/Steps: 240/320  
Results, options '-O2':
 Global Normal {},      compile:   0.167169; run: 0.002356
 Global Normalext {[]}, compile:   0.189548; run: 0.002286
 Normal {},             compile:   0.168951; run: 0.002427
 Normalext {[]},        compile:   0.197387; run: 0.002398
 Assign [],             compile: 140.032527; run: 0.002529
Binary file size:
 140237 2011-11-26 18:48 ./normalglb
 140240 2011-11-26 18:48 ./normalextglb
 140442 2011-11-26 18:47 ./normal
 140445 2011-11-26 18:48 ./normalext
 369468 2011-11-26 19:07 ./assign
Step/Steps: 320/320  
Results, options '-O3':
 Global Normal {},      compile:   0.163279; run: 0.002395
 Global Normalext {[]}, compile:   0.188072; run: 0.002230
 Normal {},             compile:   0.178390; run: 0.002411
 Normalext {[]},        compile:   0.206708; run: 0.002562
 Assign [],             compile: 140.651527; run: 0.002566
Binary file size:
 140237 2011-11-26 19:07 ./normalglb
 140240 2011-11-26 19:07 ./normalextglb
 140442 2011-11-26 19:07 ./normal
 140445 2011-11-26 19:07 ./normalext
 369468 2011-11-26 19:26 ./assign

real	58m33.521s
user	54m51.146s
sys	0m15.661s

[Josef Kufner]

Ono totiž je ftip v tom, že pokud máš inicializované statické pole, tak překladač ty data umístí tak jak jsou do výsledné binárky a při spuštění to natáhne do paměti jádro spolu s kódem. V ideálním případě to prolítne skrz DMA řadič a procesor se jen fláká v povzdálí.

Kdežto pokud si to pole initializuješ jednu hodnotu podruhé, tak překladač musí vyrobit kód té inicializace (hromadu movů nebo něčeho takového) a při spuštění to procesor musí přechroupat a zapsat do paměti.

Všimni si také velikosti výsledné binárky. Je třikrát větší než v ostatních případech. Tedy krom jednoho intu tam jsou ještě cca dvě instrukce k jeho zápisu do paměti.

Při současných rychlostech procesorů je doba provádění celkem malá, ale na pomalých strojích, kdy DMA řadič je výrazně rychlejší než CPU, by byl velký rozdíl i v době běhu. Hlavně když by se kód a pole nevešly do L1/2 cache.

[Šangala]

Já to chápu (a proto tam i to 'ls' je, aby byla patrná velikost filesu), ale abych si krokoval instrukce, tak zas tak důležité to pro mě nebylo.
Chtěl jsem jen dokázat, že „dobrý“ compiler takovou věc neoptimalizuje i když je to teoreticky možné.
Ale aspoň je z toho jeden poznatek: jak se to hezky „zamyslí“ při kompilaci .
PS: Na DX486@100 je ten rozdíl běhu také zanedbatelný

[l4m4]

Tímto způsobem to samozřejmě nejde (a nejde to ani obejít).

Takže zbývá leda rozšíření gcc, ktero umožňuje to zapsat takhle:

int array[3] = { [0] = 666, [1] = 777, [2] = 888 };

přičemž neuvedené prvky se normálně inicializují na nulu podle standardu.

[sad]

Díky.

[elenril]

Tohle není rozšíření gcc, je to standardní zápis podle C99.

[Tarmaq]

opravdu?

$ cat test.c
int main()
{
    int array[3] = { [0] = 666, [1] = 777, [2] = 888 };
    return 0;
}
$gcc -pedantic test.c
test.c: In function `main':
test.c:3: warning: ISO C90 forbids specifying subobject to initialize
test.c:3: warning: ISO C90 forbids specifying subobject to initialize
test.c:3: warning: ISO C90 forbids specifying subobject to initialize

[Šangala]

  if (std::string("C99").compare("C90") == 0)
    std::cout << "Tvrzení bylo vyvráceno" << std::endl;
  else std::cout << "Tvrzení nebylo vyvráceno" << std::endl;

[Tarmaq]

no fajn tak jsem se prehlidl no :] kazdopadne C99 > C90 takze je otazkou jestli "rozsirenim gcc" nemyslel l4m4 neco v tom smyslu ze to nebude kompatibilni s C90

[l4m4]

To prostě ilustruje, jak jsem starý... <sigh> Ano, už přes deset let je to ve standardu.

Na druhé straně stále ani GCC nepodporuje C99 na 100%, tudíž default je stále C89 a je zapotřebí kompilátor postrčit -- v tomto případě -std=gnu99 (nebo nějak podobně).

[Ondrej 'SanTiago' Zajicek]

Rekl bych, ze ten default je tam spis kvuli kompatibilite.

[l4m4]

Říkej si, co chceš, ale není to tak.

The default, if no C language dialect options are given, is `-std=gnu90'; this will change to `-std=gnu99' in some future release when the C99 support is complete.

[elenril]

ISO/IEC 9899:1999:
[...]
6.7.8.6
If a designator has the form
[ constant-expression ]
then the current object (defined below) shall have array type and the expression shall be
an integer constant expression. If the array is of unknown size, any nonnegative value is valid.
[...]
6.7.8.33
EXAMPLE 9
designators:
Arrays can be initialized to correspond to the elements of an enumeration by using

enum { member_one, member_two };
const char *nm[] = {
[member_two] = "member two",
[member_one] = "member one",
};

[Josef Kufner]

Občas je k vidění toto:

int pole[3] = {
  /*  0 */  666,
  /*  1 */  777,
  /*  2 */  888
};

Užitečné hlavně pokud místo čísel jsou použity nějaké konstanty z předcházejícího enumu.

[sad]

Vidíte, to mě nenapadlo, a je to i takové "čistší". Takhle to napíši, děkuji.

[Ondrej 'SanTiago' Zajicek]

No, tohle je spis takova znouzectnost. IMHO reseni vyuzivajici navrzene l4m4ou vyse (vyuzivajici C99 inicializaci) je vyrazne elegantnejsi.

[dustin]

Přesně tak, nebo se píše komentářový index třeba po pěti prvcích, na konci řádku

[l4m4]

Obojí má svoje použití; chce-li někdo incializovat všechny prvky a zachovat čitelnost pro člověka, komentáře zcela vyhovují. U struktur jsou cílené (designated) inicializátory neocenitelné.

[Kill_Bill]

...jelikož těch prvků v poli mám hodně... Data by nemela byt linkovana. Data patri do vstupniho souboru - odtud si je aplikace nacte.

[Kit]

... nebo do databáze. Dnes se už nevyplatí vymýšlet vlastní formáty souborů.

[Šangala]

<joke>Aha, proto jsou aplikace pomalejší a pomalejší</joke> ... reakce na oba příspěvky.
Pokud je dat malé rozumné statické množství a aplikace má být spouštěna často a má být rychlá - vložit do kódu.
Pokud je dat velké statické množství určitě do binárního souboru (ovšem může to být nepřenositelné, tak případně do textového) - načtení je velmi efektivní.
Pokud jsou to nějaká „nekonečná“ data, ktera se mají měnit či s nimi nějak sofistikovaně pracovat, tak teprve DB. Používat na kdejakou věc DB je docela, byť moderní, pohroma…
A teď si to schytám…

[Kit]

Schytáš, i když máš pravdu. Souhlasím s tím, že pokud potřebuješ načíst všechna data, nejrychlejší je skutečně zakompilovat nebo uložit do nepřenositelného binárního souboru.

Pokud však v aplikaci potřebuji použít jen některá data nebo hodlám data v aplikaci průběžně doplňovat a nechce se mi pokaždé kompilovat, je použití databáze na místě. Není DB jako DB, na netu se válí spousta jednoduchých a rychlých databází pro specifická použití s vhodnou licencí. Stačí si jen vybrat.

[Sten]

Pokud v aplikaci potřebuji použít jen některá data, tak ta nepotřebná linker vyhodí

[Kit]

A jak linker ví, která data má a která nemá vyhodit, když se aplikace teprve za běhu ze vstupních dat dozví, které z konstant bude potřebovat?

[l4m4]

Nejrychlejší je často nepoužívat žádné tabulky, ale vygenerovat kód, který v sobě ty různé konstanty obsahuje natvrdo a nechat kompilátor, ať se snaží (pokud možno s profily, aby trefil správně branch predicition). Umožní se tím optimalizace výrazů, odstraní relokace, apod.

I pro velmi jednoduchou DB bude v případech, o nichž se bavíme, jen samotný kód pracující s tou DB nejspíš mnohem větší než všechny ty tabulky dohromady...

[Josef Kufner]

... nebo zakompilovat do binárky jako resources. Třeba ikonky se takto běžně ukládají v aplikacích (Qt, Windows). Výhodou je, že se to rychle načte a ve výsledku je jen jedna binárka (jednodužší/žádná instalace).

[pavlix]

No... to je věc, která na linuxu možná ani není potřeba :).

[pc2005]

Jsem chtěl napsat, že to je zatraceně dobrý řešení jednoho mýho problému, až jsem si vzpomněl, že ty data jsou na mikrokontroléru .