c ++ динамические массивы и указатели - PullRequest
1 голос
/ 30 апреля 2011

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

Diagram

Возможно, немного небрежно.Но я сталкиваюсь с проблемой ограничения памяти в указателях на детские классы, в основном я хочу получить доступ к «связанным» детским классам через вектор детских классов, к которому он подключен.Есть какие-нибудь умные идеи здесь?

И прежде чем кто-нибудь скажет мне, что это глупый способ делать вещи, разве этот тип функциональности не является основой ОО-программирования?

1 Ответ

2 голосов
/ 07 мая 2011

Из болезненного любопытства я снова посетил этот вопрос, чтобы посмотреть, расшифровал ли его кто-либо.

Единственная очевидная проблема, которую я вижу с исходным кодом, заключается в BabyLayer :: GetBaby ():

    Baby n = Baby();
    n.setNull(true);
    if(x >= Width || x <0)
        return &n;             // Bad.
    if(y >= Height || y < 0)
        return &n;             // Bad.

Вы объявляете новый экземпляр Baby в стеке, а затем возвращаете указатель на него.Экземпляр Baby с именем 'n' разрушается, когда возвращается GetBaby (), и возвращаемый указатель теперь недопустим.

Я не знаю, какой компилятор вы используете, но Visual Studio 2010 испускает ", предупреждение C4172: возвращение адреса локальной переменной или временной "в этих строках.Обратите внимание, что ваш пример кода неполон и на самом деле ничего не делает, мне пришлось объявить экземпляр BabyCube для получения этого предупреждения.

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

...