Есть ли механизм проверки валидности указателей в C++?

Question

[Алексей]

Доброго времени суток!
Можно ли как-то в С++ проверить указатель на доступность области памяти, на которую он указывает?

Ситуация следующая. Есть dll, определяющая класс Delegate, который является представлением функции какого-либо класса (служит для колбэков). Его конструктор имеет примерно следующую сигнатуру:

template<typename T, typename ... Args> 
explicit Delegate(T* owner, (T::*function), Args ... args);

Так же перегружен operator(), что позволяет сделать примерно следующее:

class Foo
{
public:
    void func() {}
};

Foo* f = new Foo;
Delegate d(f, &Foo::func);
d(); // вызовется f->func();

В классе Delegate, в перегрузке оператора (), как проверить валидность переданного указателя в конструкторе? Сейчас, при следующем раскладе, программа крашнется:

Foo* f = new Foo;
Delegate* d = new Delegate(f, &Foo::func);
delete f;
(*d)(); // здесь будет необработанное исключение

На последней строчке произойдет обращение к недоступной области памяти. В этой части, я разрабатываю только класс Delegate, поэтому я не могу быть уверен, что пользователь после удаления указателя обнулит его. Более того, в следующей ситуации (которая и является целевой) это вроде как и невозможно:

class A
{
public:
    A() : delegate_(this, &A::funcA) {}
    Delegate callback() const { return delegate_; }
    void funcA() {}
private:
    Delegate delegate_;
};
class B
{
public:
    void setCallback(const Delegate& d)
    { delegate_ = d; }
    void event()
    { delegate_(); }
private:
    Delegate delegate_;
};
// -------------------------------------
A* classA = new A;
B* classB = new B;
classB->setCallback(classA->callback());
delete classA;
classB->event(); // печаль-беда

Собственно, как мне в классе Delegate, перед вызовом функции на переданном в конструкторе указателе, проверить его на валидность? Программа крашится с "необработанным исключением" по причине "обращения к недоступной области памяти", но даже блок try{} catch(...){} ничего не перехватывает... Как мне обработать такую ситуацию и узнать, что указатель указывает на мусор?

Comments

[Лолшто]

Почему бы не использовать std::function вместо велосипеда?

[Алексей]

@Lol4t0 Мой класс позволяет хранить указатель на любую функцию, любого класса с любым количество аргументов, в отличие от std::function, которой надо специфицировать шаблон, ее можно было бы разве что использовать во внутренней реализации Delegate, но не вместо него

[Лолшто]

вместе с std::bind std::fuction тоже это может

Answer 1

[tsarevfs]

Для отладки существует такая штука, как дебажная куча. Насколько я понимаю, в релизе адекватного варианта проверить валидность указателя быть не может. Можно попытаться как-то это обойти. Например получать shared_ptr, что намекнет пользователю что не надо раньше времени удалять объект.

Comments

[Алексей]

С std::shared_ptr рассматривался вариант, но вот не знаю, нормально ли будет смотреться конструкция:
Delegate d(std::shared_ptr< Class >(this), &Class::func)

[Миша Кринкин]

@Renzo ru.cppreference.com/w/cpp/memory/enable_shared_fro...

[tsarevfs]

@Renzo Как-то не очень. Получается кто-то нас создал (и имеет прямую ссылку) а мы создаем shared_ptr о котором пользователь не догадывается.
Можно конечно сделать приватный конструктор и статический метод возвращающий shared_ptr на новый инстанс, но слишком мудрено получается.

[Миша Кринкин]

@tsarevfs специально, чтобы создавать из this shared_ptr есть такая штука как enable_shared_from_this, более того она теперь часть стандарта.

[tsarevfs]

@kmu1990 это решает половину проблемы. Можно сделать так:

struct A: std::enable_shared_from_this<A>
{
private:
	A(){};
public:
	static shared_ptr<A> get_instance()
	{
		return shared_ptr<A>(new A);
	}

    Delegate *get_delegate()
    {
    	retuern new Delegate(shared_from_this(), func);
    }
};

main()
{
	shared_ptr<A> a = A::get_instance();
	Delegate * d = a->get_delegate();

	a.reset();

	d();
}

иначе можно написать:

A *a = new A();
Delegate * d = a->get_delegate();

[Миша Кринкин]

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

[tsarevfs]

@kmu1990 а что будет делать share_from_this с объектом на стеке?

[Миша Кринкин]

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

[tsarevfs]

@kmu1990 в том и дело, что если класс внутри своей реализации использует share_from_this то выбора нет. Получается, что пользователю надо догадаться, что класс можно хранить только как shared_ptr.

[Миша Кринкин]

@tsarevfs сам факт наследования от enable_shared_from_this не обязывает использовать shared_ptr, можете спокойно аллоцировать его на стеке, но если объект управляется умным указателем, то share_from_this позволяет создавать shared_ptr безопасно из this.

Answer 2

[Миша Кринкин]

Собственно, как мне в классе Delegate, перед вызовом функции на переданном в конструкторе указателе, проверить его на валидность?

никак, стандартного способа нет.

Более того, в следующей ситуации (которая и является целевой) это вроде как и невозможно:

я тут вас не совсем понял, у вас целевой ситуацией является код с ошибкой? Или вы хотите как-то отловить такие ошибки, чтобы исправить? Если первое - то полная печаль, если второе, то можете попробовать статические анализаторы, cppcheck, clang scan-build, etc... Они с переменным успехом могут такие ошибки находить. Можете попробовать valgraind (точнее его замену под Windows stackoverflow.com/questions/413477/is-there-a-good... ), он тоже такие ошибки находит, но в отличие от статического анализатора, только если такая ошибка произошла при конкретном запуске.

Comments

[Алексей]

второе - моя цель, написать класс, который не будет крашить программу в случае, если пользователь не обнулит указатель после удаления, который ранее был передан в мой класс

[Миша Кринкин]

@Renzo то что пользователь обнулит указатель у себя никак вам не поможет, у вас этот указатель все еще будет не нулевым.

Answer 3

[Лолшто]

Вам нужна архитектура с контролем удаления объекта. Сделать такое можно, но сложность довольно сильно возрастает:

#include <unordered_set>


class delegate;

class delegate_object_impl
{
public:
    void setDelegate(delegate* delegate)
    {
        _d.insert(delegate);
    }

    void clearDelegate(delegate* delegate)
    {
        _d.erase(delegate);
    }
    virtual ~delegate_object_impl();

private:
    std::unordered_set<delegate*> _d;
};

template <typename T>
struct delegate_object: T, delegate_object_impl
{
    template<typename...Args>
    delegate_object(Args... args):
        T(args...)
    {}
};

class delegate
{
public:
    template<typename T, typename ... Args> 
    explicit delegate(delegate_object<T>* owner, void(T::*)(), Args ... args):
        _owner(owner)
    {
        //...
        owner->setDelegate(this);
    }

    delegate_object_impl* _owner;

    ~delegate()
    {
        if (_owner) {
            _owner->clearDelegate(this);
        }
    }

    void operator()()
    {

    }

    void forget()
    {
        _owner = 0;
    }
};

delegate_object_impl::~delegate_object_impl()
{
    for (delegate* d : _d) {
        d->forget();
    }
}

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

Comments

[Алексей]

Это ведь будет контролировать удаление delegate, что у меня и так реализовано, проблема в контроле за указателем owner, переданным в конструктор, на котором, в дальнейшем, вызывается функция

[Лолшто]

owner вызывает forget у делегата в деструкторе, и его внутренний указатель на owner обнулятся

Answer 4

[xandox]

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