new и delete предназначены для другого..  для работы с памятью смотрите уже упомяннутые Вами стл-аллокаторы.


для того что массив не плоских объектов создавать логично именно таким способом. 


Ну это смотря откуда смотреть. 



В процессе удаления происходит поочередное удаление всех объектов входящих в состав массива.
delete - удалить один, delete [] удалить много - все логично.


из за незнания средств и политики c++.



И за это же  ненавидят многие другие.. 


чуть позже - сейчас времени нет..

>для того что массив не плоских объектов создавать логично именно таким способом.

Ну так создать и удалить - это маловато;).

>delete - удалить один, delete [] удалить много - все логично.

Логично delete на все. И пусть сам разбирается, объект там или массив объектов. Ну зачем приделали эти две чертовые скобочки?:). Мне, когда я освобождаю память, в общем-то уже наплевать, что там, и как оно удалится. Вся механика внутри.

>из за незнания средств и политики c++

И из-за отсутствия в нем казалось бы очевидной фичи.

я не против .


у gcc например в файле <bits/stl_uninitialized.h> представлен типоориентированный выбор способа копирования массива (memmove или цикл)


причины две :
1. необходимость универсального доступа посредством указателя, в связи с чем отсуствуют статическая информация о типе
(в противном случае можно было сделать разницу между  int *p и int[] p и общий delete)
2. позиционирование c++ как языка без ненужных оверхедов, в связи с чем необходимая информация, которая могла бы присутствовать в рантайм, также отсуствует. 
(хоть некоторые реализации и идут на встречу пользователю, но это не в счет).


Это сообщение отредактировал(а) mes - 6.12.2009, 21:22

bsa, да мы наверное почти закончили:).

>у gcc например в файле <bits/stl_uninitialized.h> представлен типоориентированный выбор способа копирования массива (memmove или цикл)

А сначала звучало все более многообещающе и фундаментально. Впрочем и то неплохо. Надеюсь, существует возможность и ручной настройки, потому как многие простые классы поддаются memcpy/memmove.

>причины две :

Я так и думал, что это единственные причины. Но что malloc, что new кроме того, что выделяют память и отдают указатель на нее, еще и создают структуры, ассоциированные с этим указателем, в которых описано как минимум, сколько памяти выделено, чтобы потом не оттяпать лишнего. New, видимо, еще хранит какую-то ассоциацию с типом или деструктором типа. Очевидно, что new[] в довесок еще пишет, сколько элементов он создал, а delete[] эту информацию читает. Так почему было не научить обычный delete пользоваться этой информацией? В таком случае при каждом обычном new в эту структуру добавлялся еще один член - длина массива, равная единице. А вот допустим ли оверхед в несколько байт на каждый new, я не знаю. Казалось бы на одни выравнивания вылетает гораздо больше, но они то отключабельны.

Добавлено через 1 минуту и 17 секунд
bsa, ох, я успел сюда ответить. Перенесите это сообщение пожалуйста.

что значит _эффективная_работа_с_памятью_? почему в С++ она не эффективная?


ну вообще delete в состоянии удалить и массив, но это противоречит стандарту языка

>что значит _эффективная_работа_с_памятью_? почему в С++ она не эффективная?

Не предоставляет _методов_. Плюсовые методы неэффективны, потому как например копирование/перемещение/изменение размера блока делается через одно место. Это было хорошо видно из комментариев в начале топика, откуда нас выгнали.

>ну вообще delete в состоянии удалить и массив, но это противоречит стандарту языка 

Может быть, но по стандарту нужно delete[], а мне кажется, что это лишнее. А если поведение отличается от стандарта, значит остается уповать на реализацию delete в конкретной системе и в случае непредвиденного поведения пинать лишь себя. Valgrind например детектит ошибку в себе:





Хотя память таки освобождается

а через какое место, оно должно делаться?
нужно понимать, что просто взять и скопировав память не POD объекта в принципе нельзя, так-как там могут быть указатели/ссылки на другие объекты, если нужно свободно перемещать/копировать/изменять размер/освобождать участки памяти, то можно ограничиться POD объектами, или в некоторых случаях можно использовать аллокатор для не POD объектов

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

еще, следует помнить, что С++, это не Си, программа на Си, по сути описывает работу с памятью, программа на С++, описывает типы, описывающие объекты, размещаемые в памяти и их семантику, то-есть, работа с памятью как в Си, по сути - хак, позволяющий обойти любые правила  

а собственно, почему бы и нет   

Lazin, вы конечно все правильно говорите, но не договариваете. И ни единого тухлого яйца не получите. Даже надгрызанного:).

Смотрите, создаем массив. Вдруг нам не хватает памяти (да, это очень низко; скажем на языке более высокого уровня - не хватает места в массиве), хотим его расширить. Через какое место? Через то самое: создаем новый массив, копируем (естественно поэлементно, ибо кусками копировать - это низко и по-сишному), удаляем старый. Захотели скопировать массив? Проделали все операции кроме последней. Почему нельзя было ввести более широкий арсенал действий, который кроме всего прочего еще и применяли бы оптимизированные техники при работе с простыми типами и "плоскими" объектами. Вот это была бы красота.

Вы можете возразить, что это все есть в стл векторе. Но раз уж есть кошерный вектор, нахрена вообще было new[] и delete[] создавать? Наверное на момент их создания вектора еще не было, но тогда опять исходный вопрос:).

MAKCim, суть кода - показать, что можно напрямую вызвать деструктор? Да, здорово;). Имхо из сообщения Lazin'а не следует обратного.

а кто мешает работать с массивом POD типа как одним большим куском памяти?


сначала хотел что-нибудь возразить, из принципа , но потом подумал, что и сам редко пользуюсь этими операторами, как правило тогда, когда нужно использовать массив фиксированного размера

>а кто мешает работать с массивом POD типа как одним большим куском памяти?

Скопировать/переместить можно. Но опять malloc + memчто-то. Ну так это геморно и по-сишному. Хочу, грубо говоря, так: 


Вот это по-плюсовому было бы. И опять же нафиг изначально использовать new[], если потом все равно придется пускаться в низкоуровневый пляс?

А расширить блок нормально вообще никак. Realloc по идее плюнется на указатель, созданный new[]. А хочется что-то вроде


Вот такие они, мои эротические фантазии.

Пока писал, проверил. Не плюнулся. Может быть просто из-за минималистичности примера, а может и более или менее нормально сработало. Хотя valgrind опять хорошенько проматерился. Тут опять видимо тонкости реализации, на которые нельзя полагаться: new и malloc, с которым работает realloc, создают "разные" указатели.

нет, мне просто в тот момент нечего было делать ;) код бессмысленен