[Parseval]

Cześć,

Mam taki kawałek kodu jak na screenie.
Dlaczego w drugiej deklaracji tablicy toEncrypt widnieją w niej stare dane, skoro po wyjściu z pierwszej pętli zostaje niszczona? W przypadku takiej samej nazwy kompilator rezerwuje pamięć pod tym samym adresem? Jak to działa?

#programowanie #programista15k #cpp

[Metaprogrammer]

bo nie została wyzerowana. A co do rezerwacji to może ale nie musi, ot magia niskopoziomowego programowania :)

[Metaprogrammer]

A i tej pamięci nie rezerwuje kompilator tylko to jest pamięć na stosie gdzie akurat jest ten program wykonywany

[Ardeo]

W przypadku takiej samej nazwy kompilator rezerwuje pamięć pod tym samym adresem?

@Parseval: może tak być, ale to jest nie istotne. Korzystanie z tablicy, której wartości nie zostały wcześniej zainicjalizowane prowadzi do niezdefiniowanego zachowania i jest błędem. Nie interesuje cię, co znajduje się w tablicy po jej stworzeniu, bo może tam być cokolwiek. Powinieneś ją czymś wypełnić, np. zerami, po stworzeniu żeby jej zawartość miała sens.

[lionbest]

@Parseval: Korzystanie z nie niezainicjowanej pamięci to UB. Domyślny konstruktor dla typów POD ich nie inicjalizuje. Jak masz C++11 to masz coś takiego jak zero-initialization, ale akurat w tym wypadku to kyprtogradicznie bardzo nierozsądne rozwiązanie. Najbezpieczniej to nadpisz do końca bufora losowe dane.

[Parseval]

Rozumiem, dzięki wszystkim :)

[Bixkog]

@Parseval: Ta tablica jest alokowana na stosie, więc w tym wypadku zawsze zajmie to samo miejsce co przed dealokacją. Na przykład gdybyś stworzył zmienną uint8_t przed ifem to wartości nowej tablicy byłyby przesunięte, ponieważ została zaalokowana o jeden bajt dalej. Undefined behaviour pojawia się kiedy jakaś operacja nie została zdefiniowana przez standard, wtedy pozostawia się to w kwestii twórców kompilatorów. Więc jak się zna dobrze co siedzi pod spodem, to nie

[Kaczus2B]

@Bixkog: mylisz UB z Unspecified behavior a nawet z Implementation-defined