Dotaz: Jakasi magie pri dynamickem alokovani pameti [C++]

[Bundas]

Jakto, ze tohle:

using namespace std;

int main()
{
    int n = 7;
    int *slova2 = new int[n];
    slova2[0] += 23;
    slova2[0] += 32;
    cout << slova2[0] << endl;
    return 0;
}

na vystupu vyhodi pokazde random cislo? Treba tohle: 6230608

---

---

Odpovědi

[Murry]

Protože čteš neinicializovanou paměť na 3. řádku v těla main() operátorem +=.

[lofcek]

Presne tak .. suvisi to s tym, ze nepoznate zaklady. Premenne v C su defaultne neinicialovane - co znamena slova2 = new int[n], naalokuje 7 prvkov. Ale nikto vam nezaruci, aku hodnotu ma slova2[0], slova2[1] .. atd. Zvysok programu uz len k neznamenu cislu pripocita 55 a vypisuje.

[Michal Kubeček]

Premenne v C su defaultne neinicialovane

Jen pro pořádek: tohle není C. Takže přesnější vysvětlení je, že typ int nemá defaultní konstruktor, který by hodnotu inicializoval.

[Michal Kubeček]

Premenne v C su defaultne neinicialovane

A pro úplnost: tohle ani není obecně pravda.

[Šangala]

A pro úplnost:

V C jsou static a „globální“ proměnné inicializované (zjednodušeně na 0).

[lertimir]

Možná není na škodu očekávat vždy a všude neinicializované proměnné. Já se tímto řídím už 30 let ve všech jazycích, které jsem používal, (Algol, FORTRAN, Basic, Ada, Pascal, C, C++, perl, python, php, java, javascript, co si pamatuji). To že to inciální přiřazení má člověk explicitně zapsané v kódu mu dá jistotu, že ví, co v proměnné je. A to nejen při psaní, ale zvláště po čase, kdy si nad kódem říká: Sakra co jsem tím myslel. A duplicita takového přiřazení v případě, že to jazyk dělá sám je zanedbatelná.

[Šangala]

Nic než souhlas(, nesouhlasil bych s „povinnou“ inicializací při deklaraci ;)).

Přemýšlet nad tím jinak v C(/C++) je vždy kravina, bo tam je to nebo to(, ne ‚a‘), a „auto inicializace“ v těchto specifických případech je tam tak nějak z pohledu programátora navíc.

static int i = 0;

je to samé(, nebo by mělo být) co

static int i;

bo „auto inicializace“ se děje jen v 2. případě.
u:

static int i;
i = 0;

už může být incicializace (bez optimalizace) 2×.

[Sten]

Není to to samé.

static int i;

Tohle tu proměnnou vytvoří vynulovanou při startu programu a pak už s ní nic nedělá.

static int i = 0;

Tohle tu proměnnou nastaví ještě jednou při inicializaci statických proměnných v dané kompilační jednotce. Tedy pokud jiná statická inicializace z jiné kompilační jednotky tu hodnotu změní, tohle ji může a nemusí přepsat (protože pořadí statických inicializací mezi kompilačními jednotkami není definované).

To první se využívá u nifty counteru.

[Michal Kubeček]

Tedy pokud jiná statická inicializace z jiné kompilační jednotky tu hodnotu změní

Ta proměnná je static, takže ji z jiné kompilační jednotky z definice přepsat nemůžete.

[Sten]

Pravda, není to vlastně static member.

[ebik]

Kdyz pouzijes nejake bloky co maji __attribute__((constructor)), tak ty se mohou provest drive nez inicializace globalni staticke promenne. Svanda je, z takoveho bloku zavolat funkci, ktera pristupuje ke globalni staticke promenne, a predpoklada, ze je naicializovana. Co hur, v C++ u globalnich statickych objektu typicky predpoklada, ze se provedl konstruktor.

Rozlisovani ruznych typu konstruktoru a pretizeni operatoru = v C++ je pak kapitola sama o sobe.

[ebik]

Můžete ale z jiné kompilační jednotky zavolat funkci, která k té proměnné přistupuje (a třeba ji přepisuje). To se v C udělá zavoláním z bloku s __attribute__((constructor)) a v na to staci C++ proste volani z konstruktoru globalniho statickeho objektu.

[ebik]

... a v C++ n to staci ...

[Šangala]

Pominu-li, že __attribute__((constructor)) je GCC specific (není to standard), tak se stejně provádí až po inicializací static proměnných, nepletu-li se.

[Šangala]

Jak?

Jsem přesvědčen, že ty zápisy jsou identické a gcc generuje identický kód.

[Sten]

Tak jsem si prošel standard a je to takto:

1. Prvně se provede zero inicializace
2. Poté se provede konstantová inicializace; standard dovoluje tohle spojit s předchozím
3. Nakonec se provede inicializace výrazy a tady nastává problém, protože není definováno pořadí

Takže v C se to stát nemůže, protože nezná inicializaci výrazy (pokud pominu __attribute__((constructor))).

Ale aby to nebylo tak snadné, tak konstantová inicializace se provádí jen compile-time konstantami, tj. literály či constexpry, nikoliv const proměnnými. Ten problém, co jsem měl, byl právě použití constu k inicializaci na 0 (v pre-C++11 jsem měl nullptr nadefinovaný jako const).

[Šangala]

Jsem si myslel, a nechce se mi to hledat, že 1. je tak, že inicializace static se má dít v jednom kroku a buď se inicializuje na „0“, nebo na hodnotu, která je při deklaraci explicitně uvedena a const tam nehraje žádnou roli.

[Sten]

Nikoliv inicializace proměnné, která je const, ale inicializace proměnné hodnotou jiné proměnné, která je const.

[lertimir]

Já to téměř vždy dělal tím 3. způsobem. Právě proto, že takto mi to umožní každý jazyk, dostanu tím oddělený kus kodu

// inicializace promměných
i=0;
...
// konec inicializace

po kterém vím, že všechny proměnné musí mít hodnotu. A jak jsem říkal, ten řádek kódu navíc mi nevadil ani v dobách Fortranu, děrných štíků a mainframu s 256 kB operační paměti, natož dnes.

[Šangala]

Blbé je, když je to právě static a, tak máš inicializace dvě, jedna při deklaraci a druhá při tvé inicializaci. Asi to v 99% případech nevadí, ale já když to vím, tak mě to žere…

[lertimir]

To máš pravdu. Je to síla zvyku. Ale to víš, FORTRANský programátor může psát aritmetické IF v jakémkoliv jazyce. (A odkaz pro ty, co neví, co je artimetické IF)

[Op]

Mám pocit, že s tou dvojí inicializací příliš podceňuješ inteligenci dnešních kompilátorů.

[Šangala]

Mám pocit, že moc věříš optimalizaci, která by, dle mého, mohla být nad rámec povoleného.

Zatímco s static int j = 0; a static int j; gcc generuje identický kód, s static j; j = 0; již jiný/delší (nenamáhám se to disasemblovat, stačí fstat a md5sum).

Zkus si:

//use: gcc -O3 test.c -o test && md5sum ./test
//cygwin use: gcc -O3 test.c -o test.exe && md5sum ./test

#include <stdio.h>
#include <limits.h>

int main(){
  int iii = INT_MAX;
  /* 1. --- explicit --- */
  static int i = 0;
  /* ---------------- */
  
  /* 2. --- implicit --- */
  //static int i;
  /* ---------------- */
  
  /* 3. ---- twice ---- */
  //static int i;
  //i = 1;
  /* ---------------- */
  
  printf("%d",iii - i);
  return 0;
}

[ebik]

O tom ze 3. je jine nez 1. a 2. snad nepochybuje nikdo. main() je totiz funkce jako kazda jina, 3. /musi/ nastavit "i" pri /kazdem/ zavolani. (A v pripade 3 nedava moc velky smysl mit takovou promennou jako statickou. Snad jen ze nebude na zasobniku, nebo kdyz bude nekdo vymyslet reentrant detection.)

Myslim, ze predrecnici se bavili o optimalizaci v pripade nestatickych lokalnich promennych.

[Šangala]

O tom ze 3. je jine nez 1. a 2. snad nepochybuje…

No a o tom to právě je, že jsou tam ty dvě inicializace, které nemohou/by neměly být při kompilaci optimalizovány, i když by to v tomto případě, nemělo žádný faktický dopad.

Myslim, ze predrecnici se bavili o optimalizaci v pripade nestatickych lokalnich promennych.

Co to?, mně přijde, že se bavíme o static od začátku, a pak píšu právě o static a na to je reakce o podcenění optimalizace.

PS: Ad. pochyby o smyslu, on ten příklad nedává smysl ani jako celek, to je častý úděl moc krátkých příkladů. Tak si představ, že je tam nějaké if a fce se volá opakovaně.

[ebik]

Omlouvam se, myslel jsem jeste na jine veci, a cetl jsem jiz jen par poslednich prispevku, mate samozrejme pravdu ze o static se jedna.

Co se tyce disasemblovani, tak na produkty gcc lze spustit objdump. Tim se napriklad zjisti, ze standardni elf na linuxu inicializuje lokalni staticke promenne (C) nactenim sekce .data do pameti. Tedy stara se o to elf loader a nikoli program samotny. Take se tim zjisti, ze "static int foo = 12;" se vubec nikam neulozi, pokud se do te lokalni promenne foo nikdy nezapise. Tedy kompilator to zoptimalizuje jako konstantu.

[kuka]

Jestlize uvadis javu, tak tam je toto antipattern. Pokud se ponecha neinicializovana (plati pro lokalni promennou), kompilator vyhodi chybu, pokud by se v tomto stavu pouzila. Tim se odchyti pripady, kdy ucelem bylo hodnotu pozdeji naplnit smysluplne (napriklad vekem cloveka), ale v kodu je chyba, treba if vetveni nepokryva vsechny pripady apod. Pokud si tam dam inicialne 0, tak se mi to prelozi a zavola s nulou, coz jsem nechtel.