2016-07-21 8 views
0

Давайте рассмотрим следующий класс, напримерГде (в каком сегменте памяти) находятся объекты (класса), хранящиеся в C++?

class Shape{ 
    public: 
     Circle (int x): number(x){} 
     virtual area() {return x**2;} 

    private: 
     int number; 
} 

В основном мы создать объекты

int main(){ 
    Shape *foo = new Shape(8); 
    Shape *bar = new Shape(65); 
    Shape &obj1 = *foo, &obj2 = *bar; 
} 

Я считаю, что объекты 1 и 2 хранятся в куче. Почему это? Как побочный вопрос. Определяет ли ключевое слово virtual, или/и пути объекты (например, obj1 = * foo), влиять на их размещение в памяти?

+9

'foo' и' bar' имеют динамическую продолжительность хранения и хранятся в * freestore *. Спецификация языка C++ не упоминает * «кучу» * в качестве хранилища. 'obj1' и' obj2' ** ссылки **. Они являются псевдонимами для существующих объектов и существуют только во время компиляции (как и все переменные). Они (обычно) не отражаются в исполняемом изображении или в памяти во время выполнения. – IInspectable

+0

Ссылка: http://stackoverflow.com/questions/10157122/object-creation-on-the-stack-heap –

ответ

0

Существует (в общем) два типа объектов W.R.T. их управление памятью:

  1. объекты An может быть полностью построены во время компиляции
  2. Объект может быть полностью построен только с использованием некоторой информации, которая не является не доступна только после выполнения программы

Например , любой объект типа constexpr может быть полностью оценен и сконструирован во время компиляции и как таковой может быть помещен в сегмент данных памяти в качестве оптимизации (с точки зрения пуриста он является действительным, но далеко не оптимальным, для создания таких объектов во время выполнения -time. Но это будет тратить процессорные циклы и инициализировать/запускать больше).

Вот несколько примеров таких объектов:

const char * const helloWorld = "Hello, world!"; 
struct TSilly{ 
    TSilly(int _i = 0) : i(_i) {} 
    int i; 
}; 
const TSilly silly1; 
const TSilly silly2(42); 
TSilly silly3; // doesn't have to be constexpr to qualify for static allocation. 
       // This one you can declare as /*extern TSilly silly3;*/ in 
       // header file and access from other compilation units 
static TSilly silly4; // can be local to compilation unit, too 

int main() 
{ 
    return 0; 
} 

Все остальные объекты должны ждать, пока время выполнения не будет построено.

Примеры таких объектов:

const char * exeName1; // statically allocated by compiler 

int main(int argc, char **argv) 
{ 
    exeName1 = argv[0]; // now points to a string 

    // buffer is allocated in free storage (heap) bu variable itself is on stack 
    char * exeName2 = new char[strlen(argv[0] + 1]; 
    strcpy(exeName2, argv[0]); // now contains a COPY of a string 

    char exeName3[1024]; // likely allocated on stack, be careful with that as stack space is limited 
    strncpy(exeName3, argv[0], 1024); // will COPY at most 1023 characters from a string 

    delete [] exeName2; // don't forget to clean up 
    // exename3 will be auto-cleaned when we exit the function 

    return 0; 
} 

Как можно видеть объект в C++ будет введена в сегмент данных, или в свободное хранилище (кучи) в зависимости от его срока службы.

Только динамически выделяется Объекты будут помещены в бесплатное хранилище. Я не думаю, что спецификация обещает использовать сегменты данных для статически выделенных объектов - это зависит от того, компилятор должен выполнить и использовать эту оптимизацию.

Для получения дополнительной информации goggle "C++ storage classes".

Есть много передовых тем управления памятью, которые вы, возможно, захотите изучить. Наиболее актуальным для этого обсуждения является, вероятно, конструктор на месте, который позволяет иметь объект времени выполнения, построенный в памяти, выделенной в сегменте данных исполняемого файла.

+0

В моем примере, что делает объекты динамически распределенными? –

+0

Что это значит? Не могли бы вы задать свой вопрос по-другому? – YePhIcK