C++, miejscowa wersja operatora new

Question

Witam, mam taki kod:

#include <iostream>
#include <new>

void f(){
    char buffer[100]; //tablica automatyczna o zasięgu wewnętrznym 
    
    
    int *pt = new(buffer) int{10}; //utworzenie 
    std::cout<<(void*)buffer<<std::endl; //adres (jedna z metod dostepu)
    std::cout<<*pt<<std::endl; //wartosc (jedna z metod dostepu)
}

int main(){
    f();
    
    int* s = (int*)0x6dfe68;  //&buffer[0] (popatrzcie na to z przymrużeniem oka)
    
    std::cout<< *s <<std::endl;
    *s = 45;    //normalna praca ma wskazniku 
    std::cout<< *s <<std::endl;
}

W funkcji f() dynamicznie tworzymy obiekt danych typu int pod adresem pierwszego elementu tablicy buffer (ona jest lokalna i podlega przydziałowi dynamicznemu więc ginie po zakończeniu działania bloku kodu w którym się znajduje). Do zapisania int'a potrzebujemy wykorzystać cztery pierwsze elementy tablicy buffer ( bo każdy element ma 1B a int u mnie zajmuje 4B).

Po zakończeniu działania funkcji odwołujemy się do adresu tablicy (dokładniej jej zerowego indeksu) gdzie został przydzielony dynamicznie obiekt danych. 0x6dfe68 to odpowiedni adres, wiem... funkcja f() mogła by go zwrócić ;)

Samo to że wartość zapisaną pod tym adresem można odczytać mnie nie dziwi ( bo wartości pozostają w ram'ie) . Jednak można na niej pracować:

 *s = 45;

Kiedy mamy zwykłą funkcje zwracającą adres zmiennej lokalnej to nie możemy nic pod nim grzebać bo program się wysypie ( albo kompilator nie dopuści do kompilacji czegoś takiego ). Tu na natomiast można traktować ten adres jak by był przez coś zarezerwowany. Czy wynika to z zasady działania operatora new? Czy może program działa poprawnie przypadkiem? Czy taka sytuacja jest poprawna?

A takie coś:

int* s = new((int*)0x6dfe56) int[3]{12,3,5};

std::cout<<s[0]<<std::endl;
std::cout<<s[1]<<std::endl;
std::cout<<s[2]<<std::endl;

Pod s[0] jest poprawna wartość a pod resztą głupoty... Jaki typ domyślnie jest pod tym (ogólnie przykładowym) niezarezerwowanym adresem?

Dziękuje wam bardzo za informacje i serdecznie pozdrawiam ;)

Answer 1

Czy wynika to z zasady działania operatora new?

Jeśli jest to adres lokalnej tablicy buffer, to odpowiedź jest prosta - to jest pamięć stosu, ona jest dostępna przez cały czas działania procesu.  new nie ma nic tutaj to rzeczy (zresztą w tym przypadku użycie placement new jest... przesadą. Zwykłe rzutowanie wystarczy).

Comments

Dziękuje, czyli rozumiem że całe:

int *pt = new(buffer) int{10};

To normalne tworzenie "zmiennej" dynamicznej tyle że w określonej lokalizacji?

Kwestia jest taka że tu tworzymy coś już pod adresem zarezerwowanym (użytkowanym), stare dane zostaną przykryte. A co jeśli chcemy tworzyć coś dynamicznie pod adresem nie zarezerwowanym przez nic? Np wiem że przykładowy adres 0x6dfe56

gdzieś tam jest w pamięci ram i nic na niego nie wskazuje ani nie ma pod nim żadnej zmiennej, czy gdy wykorzystamy taki adres do czegoś takiego:

int* s = new((int*)0x6dfe56) int[3]{12,3,5};

To jest to błąd?

Oczywiście chodzi mi tu o czysto teorytyczne zrozumienie a nie że takie coś już chce koniecznie stosować już w praktyce

---

To normalne tworzenie "zmiennej" dynamicznej tyle że w określonej lokalizacji?

Tak.

A co jeśli chcemy tworzyć coś dynamicznie pod adresem nie zarezerwowanym przez nic?

Jeśli adres nie jest zarezerwowany, to nie masz do niego dostępu. W przykładzie z pierwszego postu to działa, bo odwołujesz się do pamięci stosu, co nie zmienia faktu, że ta pamięć będzie użyta przy kolejnym wywołaniu jakiejś funkcji, więc dane zostaną zamazane.

 

To jest to błąd?

Zależy. Jeśli adres 0x6dfe56 nie jest dostępny, to tak.

 

---

Dziękuje za pomoc, teraz już wiem mniej więcej jak nie używać tej wersji operatora new.

---

Pisząc na Windowsa czy Linuksa praktycznie nie stosuje się odwołań do konkretnych adresów (chyba że piszesz cheaty do gry), bo one co kompilację czy co każde uruchomienie procesu mogą się zmieniać. Po to są nazwy zmiennych i funkcje przydzielające pamięć, żeby tego nie robić.

---

Wiem, wiem... Napisałem że chodzi mi o czysto teorytyczną wiedze ;)

---

To normalne tworzenie "zmiennej" dynamicznej tyle że w określonej lokalizacji?

Nie. Przez tę wersję new, nakazujesz mu zachować się nietypowo bez alokacji pamięci. Już ją alokowałeś tworząc bufor na stosie. Systemu od tego momentu nie interesuje skąd ten bufor masz bo "twierdzisz że wiesz lepiej". W Twoim przykładzie nie jest to także alokacja dynamiczna bo do systemu operacyjnego nie powędrowało żądanie o alokację pamięci w przestrzeni sterty (tu pomijam dla jasności dyskusję o nazewnictwie ze standardu C++). new wykonał jedynie konstrukcję obiektu umieszczając go w nakazanym buforze. Pamięć stosu jest stosunkowo "atrakcyjna" dla programów i z zasady ciągła. Jeśli wywołasz jakąś funkcję, masz dużą szansę że naruszysz pamięć która kiedyś była dostępna pod jakimś adresem na stosie bo z przestrzeni stosu pamięć jest wydzielana poprzez przestawienie adresu w jednym rejestrze (przestawienie ramki stosu).

Pamięć dynamiczna (sterty) jest dość pofragmentowana i system inaczej ją traktuje. Jeśli przeznaczony dla Ciebie obszar sterty jest za mały, jądro systemu przydzieli nowe strony pamięci. W przypadku stosu tak się nie dzieje. Jest on ograniczony dla każdego wątku do stałego rozmiaru (oczywiście można go zmienić wywołaniami systemowymi lub na etapie kompilacji).

Dlaczego alokowanie przez takie new powinno być świadome? Sprawdź program. Powiedz czy wywołany jest (zakomentowany) destruktor:

#include <iostream>

struct X {
    X() {
        std::cout << "X construct\n";
    }
    void foo() const {
        std::cout << "foo() in X\n";
    }
    ~X() {
        std::cout << "X destruct\n";
    }
};

X * newplace() {
    char p[sizeof(X)];
    X * px = new(p) X;
    // px->~X(); 
    return px;
}

int main() {
    X * p = newplace();
    p->foo();
}

Jeśli takiego działania oczekujesz i tego chcesz, powinieneś znać konsekwencje. Destruktor często wtedy trzeba wołać ręcznie.  W kodzie powyżej foo() najprawdopodobniej także zadziała ale nie masz pewności w każdym przypadku i przy każdym kodzie.

Oczywiście przykład kodu który podałem jest z gruntu patologiczny i nie należy bazować na takich technikach :)