Может ли класс C ++ определить, в стеке он или в куче?

Вам нужно задать нам реальный вопрос ^(a) :-) вам может быть очевидно, почему вы считаете это необходимым, но это почти наверняка нет. На самом деле, это почти всегда плохая идея. Другими словами, почему вы думаете, что вам это нужно?

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

Обновление:

Теперь, когда вы прояснили свои причины в вопросе, прошу прощения, вы, вероятно, нашли одну из немногих областей, в которых то, что вы спрашиваете, имеет смысл (запуск ваших собственных процессов сборки мусора). В идеале вы должны переопределить все операторы выделения и отмены выделения памяти, чтобы отслеживать, что создается и удаляется из кучи.

Однако я не уверен, что это простой вопрос перехвата нового / удаления для класса, поскольку могут быть ситуации, когда delete не вызывается, и, поскольку метка / очистка зависит от счетчика ссылок, вам нужно иметь возможность перехватывать указатель задания для его правильной работы.

Вы думали, как с этим справиться?

Классический пример:

myobject *x = new xclass();
x = 0;

не приведет к вызову удаления.

Кроме того, как вы обнаружите, что указатель на один из ваших экземпляров находится в стеке? Перехват new и delete может позволить вам сохранить, является ли сам объект стеком или кучей, но я не понимаю, как вы определяете, куда будет назначен указатель, особенно с таким кодом, как:

myobject *x1 = new xclass();  // yes, calls new.
myobject *x2 = x;             // no, it doesn't.

Возможно, вам захочется изучить интеллектуальные указатели C ++, которые существенно помогут сделать ручное управление памятью устаревшим. Сами по себе общие указатели могут страдать от таких проблем, как циклические зависимости, но разумное использование слабых указателей может легко решить эту проблему.

Возможно, в вашем сценарии ручная сборка мусора больше не требуется.

^(a) Это известно как X/Y problem. Часто люди задают вопрос, предполагающий класс решения, тогда как лучший подход - просто описать проблему без никаких предубеждений относительно того, какое будет лучшее решение.

Хакерский способ сделать это:

struct Detect {
   Detect() {
      int i;
      check(&i);
   }

private:
   void check(int *i) {
      int j;
      if ((i < &j) == ((void*)this < (void*)&j))
         std::cout << "Stack" << std::endl;
      else
         std::cout << "Heap" << std::endl;
   }
};

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

(Наверняка есть системы, где это не сработает)

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

Я бы начал искать разные способы достижения вашей цели - возможно, у вас может быть совершенно другой тип, который будет служить «корнем» в вашей схеме, или потребовать от пользователей (правильно) аннотировать выделенные в стеке типы как таковые с помощью специального конструктора .

Это возможно, если вы сравните значение this с текущим значением указателя стека. Если это ‹sp, значит, вы были размещены в стеке.

Попробуйте это (используя gcc в x86-64):

#include <iostream>

class A
{
public:
    A()
    {
        int x;

        asm("movq %1, %%rax;"
            "cmpq %%rsp, %%rax;"
            "jbe Heap;"
            "movl $1,%0;"
            "jmp Done;"
            "Heap:"
            "movl $0,%0;"
            "Done:"
            : "=r" (x)
            : "r" (this)
            );

        std::cout << ( x ? " Stack " : " Heap " )  << std::endl; 
    }
};

class B
{
private:
    A a;
};

int main()
{
    A a;
    A *b = new A;
    A c;
    B x;
    B *y = new B;
    return 0;
}

Он должен выводить:

Stack 
Heap 
Stack 
Stack 
Heap

Я не уверен в том, что вы спрашиваете, но переопределение оператора new может быть тем, что вы пытаетесь сделать. Поскольку единственный безопасный способ создать объект в куче в C ++ - использовать оператор new, вы можете различать объекты, существующие в куче, и другие формы памяти. Google "перегрузка нового в c ++" для получения дополнительной информации.

Однако вам следует подумать, действительно ли необходимо различать два типа памяти изнутри класса. Различное поведение объекта в зависимости от того, где он хранится, звучит как рецепт катастрофы, если вы не будете осторожны!

Как упоминалось выше, вам нужно контролировать, как ваш объект выделяется с помощью перегруженного оператора new. Однако обратите внимание на две вещи: во-первых, оператор «нового размещения», который инициализирует ваш объект внутри буфера памяти, предварительно выделенного пользователем; во-вторых, ничто не мешает пользователю просто преобразовать произвольный буфер памяти в ваш тип объекта:

char buf[0xff]; (Foo*)buf;

Другой способ заключается в том, что большинство сред выполнения используют немного больше памяти, чем запрашивается при выделении кучи. Обычно они помещают туда некоторую служебную структуру для определения правильного освобождения по указателю. Вы можете проверить свою реализацию среды выполнения на наличие этих шаблонов, хотя это сделает ваш код действительно непереносимым, опасным и неподдерживаемым излишним.

Опять же, как упоминалось выше, вы действительно запрашиваете детали решения («как»), когда вам следует спросить о первоначальной проблеме, для которой вы разработали это решение («почему»).

Более прямым и менее навязчивым методом было бы поиск указателя в картах областей памяти (например, /proc/<pid>/maps). У каждого потока есть область, выделенная для его стека. Статические и глобальные переменные будут находиться в разделе .bss, константы - в сегменте родата или константы. , и так далее.

Нет, это невозможно сделать надежно или разумно.

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

Но что тогда, если объект создается как член класса, а класс-владелец выделяется в куче?

Вот третий пример кода, который нужно добавить к двум, которые у вас есть:

class blah {
  Foo foo; // on the stack? Heap? Depends on where the 'blah' is allocated.
};

А как насчет статических / глобальных объектов? Как бы вы отличили их от стека / кучи?

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

Так что на самом деле лучший ответ - «есть причина, почему сборщики мусора mark & ​​sweep не используются с C ++». Если вам нужен правильный сборщик мусора, используйте другой язык, который его поддерживает.

С другой стороны, наиболее опытные программисты на C ++ обнаруживают, что потребность в сборщике мусора практически исчезает, если вы изучите необходимые методы управления ресурсами (RAII).

Способ для классов MFC:

.H

class CTestNEW : public CObject
{
public:
    bool m_bHasToBeDeleted;
    __declspec(thread) static void* m_lastAllocated;
public:
#ifdef _DEBUG
    static void* operator new(size_t size, LPCSTR file, int line) { return internalNew(size, file, line); }
    static void operator delete(void* pData, LPCSTR file, int line) { internalDelete(pData, file, line); }
#else
    static void* operator new(size_t size) { return internalNew(size); }
    static void operator delete(void* pData) { internalDelete(pData); }
#endif
public:
    CTestNEW();
public:
#ifdef _DEBUG
    static void* internalNew(size_t size, LPCSTR file, int line)
    {
        CTestNEW* ret = (CTestNEW*)::operator new(size, file, line);
        m_lastAllocated = ret;
        return ret;
    }

    static void internalDelete(void* pData, LPCSTR file, int line)
    {
        ::operator delete(pData, file, line);
    }
#else
    static void* internalNew(size_t size)
    {
        CTestNEW* ret = (CTestNEW*)::operator new(size);
        return ret;
    }

    static void internalDelete(void* pData)
    {
        ::operator delete(pData);
    }
#endif
};

.CPP

#include "stdafx.h"
.
.
.
#ifdef _DEBUG
#define new DEBUG_NEW
#endif

void* CTestNEW::m_lastAllocated = NULL;
CTestNEW::CTestNEW()
{
    m_bHasToBeDeleted = (this == m_lastAllocated);
    m_lastAllocated = NULL;
}

Перегрузите new () для вашего класса. Таким образом, вы сможете различать распределение кучи и стека, но не между стеком и статическим / глобальным.

На мета-вопрос, заданный pax, задается вопрос «зачем вам это нужно?», Вы, вероятно, получите более информативный ответ.

Теперь, предполагая, что вы делаете это «по уважительной причине» (возможно, просто из любопытства), можно добиться такого поведения, переопределив операторы new и delete, но не забудьте переопределить все 12 вариантов, включая:

новое, удаление, новое без выброса, удаление без выброса, новый массив, удаление массива, новый массив без выброса, удаление массива без выброса, новое размещение, удаление размещения, размещение нового массива, удаление массива размещения.

Одна вещь, которую вы можете сделать, - это поместить это в базовый класс и унаследовать от него.

Это своего рода боль, так какого другого поведения вы хотели?

Вместо этого я бы рекомендовал использовать умные указатели. По замыслу, у класса должны быть данные и информация о классе. Бухгалтерские задачи следует делегировать вне класса.

перегрузка new и delete может привести к большему количеству дыр, чем вы можете себе представить.

Чтобы ответить на ваш вопрос, надежный способ (при условии, что ваше приложение не использует более одного потока), предполагая, что все, что не содержится в вашем интеллектуальном указателе, не находится в куче:

-> Перегрузка нового, чтобы вы могли хранить список всех выделенных блоков с размером каждого блока. -> Когда конструктор вашего умного указателя, найдите блок, которому принадлежит этот указатель. Если его нет в каком-либо блоке, вы можете сказать, что он «в стеке» (на самом деле это означает, что он не управляется вами). В противном случае вы знаете, где и когда был размещен ваш указатель (если вы не хотите искать бесхозные указатели и быстро освободившуюся память, или что-то в этом роде ...). Это не зависит от архитектуры.

Решение есть, но оно вызывает наследование. См. Мейерс, Более эффективный C ++, пункт 27.

РЕДАКТИРОВАТЬ:
Предложение Мейерса кратко изложено в статье написано Роном ван дер Валем, на которое сам Майерс указал в своем блоге (в этом посте):

Отслеживание объектов на основе кучи

В качестве альтернативы подходу с глобальными переменными Мейерс представляет класс HeapTracked, который использует список для отслеживания адресов экземпляров класса, выделенных из кучи, а затем использует эту информацию, чтобы определить, находится ли конкретный объект в куче. Реализация выглядит так:

class HeapTracked {
  // Class-global list of allocated addresses
  typedef const void *RawAddress;
  static list<RawAddress> addresses;
public:
  // Nested exception class
  class MissingAddress {};

  // Virtual destructor to allow dynamic_cast<>; pure to make
  // class HeapTracked abstract.
  virtual ~HeapTracked()=0;

  // Overloaded operator new and delete
  static void *operator new(size_t sz)
  {
    void *ptr=::operator new(sz);
    addresses.push_front(ptr);
    return ptr;
  }

  static void operator delete(void *ptr)
  {
    // Remove ‘ptr’ from ‘addresses’
    list<RawAddress>::iterator it=find(addresses.begin(),

    addresses.end(), ptr);
    if (it !=addresses.end()) {
      addresses.erase(it);
      ::operator delete(ptr);
    } else
      throw MissingAddress();
  }

  // Heap check for specific object
  bool isOnHeap() const
  {
    // Use dynamic cast to get start of object block
    RawAddress ptr=dynamic_cast<RawAddress>(this);
    // See if it’s in ‘addresses’
    return find(addresses.begin(), addresses.end(), ptr) !=
      addresses.end();
  }
};

// Meyers omitted first HeapTracked:: qualifier...
list<HeapTracked::RawAddress> HeapTracked::addresses; 

К исходной статье можно прочитать больше: Рон ван дер Валь комментирует это предложение, а затем демонстрирует другие альтернативные методы отслеживания кучи.

Взгляните на программу здесь: http://alumni.cs.ucr.edu/~saha/stuff/memaddr.html. С помощью нескольких приведений он выводит:

        Address of main: 0x401090
        Address of afunc: 0x401204
Stack Locations:
        Stack level 1: address of stack_var: 0x28ac34
        Stack level 2: address of stack_var: 0x28ac14
        Start of alloca()'ed array: 0x28ac20
        End of alloca()'ed array: 0x28ac3f
Data Locations:
        Address of data_var: 0x402000
BSS Locations:
        Address of bss_var: 0x403000
Heap Locations:
        Initial end of heap: 0x20050000
        New end of heap: 0x20050020
        Final end of heap: 0x20050010