Доброго всем времени суток, столкнулся с такой проблемой - вот код:



Можно ли при сохранении структуры классов создать массив фигур без указателей и конструкций аля new-delete?

Заранее спасибо за помощь!

Без указателей в один массив разные типы загнать нельзя. А вот без delete обойтись вполне можно. Используй умные указатели, например из буста. Насчет new - если есть желание и смысл заморачиваться, можно какую-нибудь фабрику организовать. Но где-то все равно будет new, естественно.

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



А как дальше? Нужно же поменять размер массива. Переместить элементы 2 и 3 на место 1 и 2 соответственно. Это я победить так и не смог.

std::vector и erase, remove_if?

+ std::unique_ptr хранить в векторе, а не голые указатели.

Guinness, а можно небольшой примерчик использования?

vinter, это не буст случаем?

Это не буст, это стандартный C++. Правда требует более-менее свежего компилятора.
P.S. я не собирал пример.

Это сообщение отредактировал(а) vinter - 25.9.2013, 12:48

Точно? Это же аналог auto_ptr с некоторыми улучшениями? А такой тип указателей не рекомендуется хранить в контейнерах. Лучше, std::shared_ptr( если C++11 ) или boost::shared_ptr( в более ранних версиях ).

Я же вроде ссылку дал на вики с примером. Или какой-то конкретный момент непонятен?

Это то, чем должен был быть auto_ptr, но так и не стал в связи с отсутствием понятия "перемещение" в ранних версиях стандарта. Насчёт "не рекомендуется использовать": впервые слышу, какие аргументы? std::shared_ptr накладывает определенные накладные расходы, которые в данном случае не нужны. Если нет потребности в std::shared_ptr его использования стоит избегать, это не бесплатная сущность. В отличие от std::unique_ptr.

auto_ptr ведет себя вот так:

Судя, по описанию unique_ptr он ведет себя схожим образом:


Может я чего-то не допонял или не так перевел? Но вызов foreach для вектора как показано ниже приведет к печальным последствиям:

Или я не прав?

Это сообщение отредактировал(а) Guinness - 25.9.2013, 14:05

  
std::unique_ptr как раз таки можно хранить в контейнерах.

Добавлено через 1 минуту и 45 секунд
http://en.cppreference.com/w/cpp/memory/unique_ptr
Typical uses of std::unique_ptr include:

• providing exception safety to classes and functions that handle objects with dynamic lifetime, by guaranteeing deletion on both normal exit and exit through exception
• passing ownership of uniquely-owned objects with dynamic lifetime into functions
• acquiring ownership of uniquely-owned objects with dynamic lifetime from functions
• as the element type in move-aware containers, such as std::vector, which hold pointers to dynamically-allocated objects (e.g. if polymorphic behavior is desired)

Так, я там проглядел, но у unique_ptr есть следующие объявления:

Т.е. копирование запрещено как таковое. Получается, что мой пример с for_each мне выкинет ошибку на этапе компиляции? А контейнеры в любом случае будут возвращать ссылку на unique_ptr. Получается избегаем проблем связанных с auto_ptr.

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

Не правы, приведённые пример просто не соберется, по причине, которая приведена выше. 
А вот так соберётся:

Чтобы Ваш пример собирался и работал for_each должен выглядеть как-то так:

Само собой, никакого std::move в стандартной версии нет ибо это бы ломало контейнеры. А так контейнеры вполне хорошо работают с объектами, которые не могут быть скопированы, а могут лишь быть перемещёнными.

Ну да, либо функция должна принимать ссылку на unique_ptr.

vinter, спасибо за пример, попробую в свободное от работы время.


Не заметил ссылку, спасибо.

Для тех кому интересна информация об умных указателях, нашёл статейки, может кому пригодится:
unique_ptr
unique_ptr vs shared_ptr

Это сообщение отредактировал(а) Guinness - 25.9.2013, 16:53

тогда еще свою статью оставлю тут

Никто не прокомментировал, но


Синтаксическая ошибка, так что пример вообще не должен компилиться. Но даже, если здесь использовать 


Программа будет падать, т.к. это попытка удалить память, выделенную на стеке при помощи delete. Но даже если программа не упадёт, будет утечка памяти, т.к. элементы массива в коде не удаляются.

Да в общем случае можно, но это будет неудобно (не так быстро или ещё варианты). Да и скажем, в одном из вариантов не обойтись без указателей, а в другом случае нужны ссылки.
Вообще "std::vector" яляется не более чем оболочкой для массива с переменной, указывающей количество используемых элементов в массиве. Далее, С в помощь настойчивому программисту и подобные задачи уже писались до ООП. И решались не так уж сложно. Как сделать смещение в массиве с удалением элемента - это просто. Но это уже не ООП в чистом виде.
malloc в зубы - и вот тебе уже capacity контейнера vector


А чем вызвана причина необходимости именно такого подхода? Может, сначала стоит оценить реальную мотивировку?


Это сообщение отредактировал(а) akizelokro - 26.9.2013, 19:32

А как тогда должна выглядеть правильная очистка? Во всех примерах, подобного рода, память освобождали именно таким образом  

Salatovec, delete figures[1];
delete figures[] - синтаксически неверно, а
delete []figures можно применять только после figures = new Figure*[4];
А у тебя автоматический массив указателей. Он уничтожается тоже автоматически. Но объекты, на которые ссылаются члены массива уничтожать надо вручную.

bsa, правильно ли я понимаю, что нужно сделать так:



Так?

так

Salatovec, да. Правильно.
Но всеже рекомендую использовать умные указатели ВЕЗДЕ.