Он не мой. Он Борландовский! Ну нету у меня ничего другого!   

  
И вообще - форум вещь добровольная. Я же не заставляю вас с паяльником в одном месте вести со мной диалог.   

Просто  на конкретно моем компиляторе (не скажу каком   ) форма delete[] употребленная к указателю void работает, мне интересно освобождает он память или дурку гонит... Видимо все-таки дурку, раз там UB. Если найду исходники стандартной библиотеки гляну как они устроены, интересно все-таки

см. стандартный хэдер <new>... а ещё можешь почитать раздел 18.4 Dynamic memory management - там описано стандартное поведение этих "заменителей malloc/free"

Это я уже читал утром.
Видимо в выделенном блоке где-то хранится размер объекта, прикольный уффект на таком коде:


Т.е. память я выделяю под 1 объект. А когда вызываю delete[] (шифорот навыворот) то деструктор вызывается 15 раз! Видимо блок памяти выделяется с запасом, а размер объекта считается 1 байт.
В общем ладно. Бог, с ними с этими операторами - все равно я никогда так не делал, всегда использовал адекватную связку. В общем лучше считать, что блок не освобождается (от греха подальше).   

Anikmar, как правило, размер выделенного блока хранится аккурат перед самим буффером... т. к. там мусор - не исключено, что будет вызван и миллион раз...

Откуда там мусор? Я же блок легальными средствами выделяю. Мне нигде не попадалось описание этого блока, но думаю, что там есть размер всего блока и размер элемента блока. В варианте замены malloc видимо размером объекта считается байт - вот он и вызывает деструктор соответственно количеству байтов в блоке.
В общем экспериментировать надо с осторожностью. Вот когда приспичит собственный менеджер памяти писать, тогда и буду серьезно копать   

ну как откуда - а что, по адресу 0x123456 не мусор? не знаешь?  я тоже  а всё, что мы не знаем - мы называем мусором... ну раньше эта страница принадлежала другой проге и она по этому адресу чё-то записала... это я и называю мусором...
ты легально получил кусок, но ты получил указатель именно на этот кусок... всё, что до и после этого куска нелегально и является мусором...

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

Просто уже понятно, что по большой части вариант со скобками и без скорее всего блок освобождают по-любому (правда пользоваться этим не стоит). Оператор со скобками получает на вход 2 параметра: адрес блока и имя класса , для которого вызвать деструктор (либо адрес деструктора). Дальше он смотрит в блоке размер объекта ( в данном случае это 1 байт) и вызывает для каждого объекта деструктор, ничего больше не предполагая. А затем просто помечает блок как свободный. За пределы памяти вроде как раз не вылезает - четко в рамках блока действует. А дальше все зависит от деструктора. Мне кажется (не пробовал), что цинничное освобождение памяти, выделенной по new при помощи free также сработает - раз new по сути является оберткой для malloc. Другой вопрос на долго ли такая ситуация продлится - все в жизни модернизируется, поэтому лучше действовать по стандарту. Но зная схему работы уже лишних ошибок точно не сделаешь. Видимо поэтому и исключение выкинуть нельзя - так как известен только адрес блока и адрес функции деструктора, а вот размер объекта не подпихивается и проверить валидность сложно.

мусор всё, и уж тем более какой-то там блок.
archimed7592, забей. видимо человеку нравится заниматься гаданием

Да в общем-то тема уже полностью обсосана - я просто прикололся ради интереса (моего, естественно).
И совсем не было у меня желания ,Daevaorn, вызвать у вас столько раздражения  . До жесткого флуда скатываться не нужно, 
это вы правы, но и ограничивать себя в общении я как-то не особо собираюсь. Тут никто никого не заставляет отвечать - не нравятся мои "гадания" можно на них просто не реагировать "дескать пускай себе придурок всякую фигню пишет"   
В общем подвожу итог: свое любопытсво я полностью удовлетворил, archimed7592, спасибо за диалог и помощь в переводе стандарта.

Anikmar, тебя интересует как по стандарту или как на практике? по стандарту UB - этот вопрос считаем закрытым...
на практике... мой последний тебе пример: я тебе не так давно рассказывал про пулы... для динамического распределения маленьких объектов... вот представь, что, эффективности ради, new для блоков, размером не большим, чем 64 байта будут использоваться пулы... быстро, эффективно и т. д... сам понимаешь, что ни о каких malloc/free уже речи быть не может... как и о пренебрежении связок new/delete, new[]/delete[]... повторяю: это всего лишь пример, но ни что не мешает написать такой менеджер памяти и преподнести его как стандартный... т. о. в билдере следующей версии, если будет применена эта идея, работать твои догадки не будут... тебе это надо? если да, то в добрый путь в форум посвящённый этому компилятору...

Добавлено через 1 минуту и 43 секунды
твой интерес уместен, но не помешало бы постараться выслушать ответы и/или более чётко формулировать вопросы(если ответы не устраивают)

Я что-то не припоминаю, что я  с этим спорил. Я попросил помочь с переводом - так как сам был не уверен, что правильно перевел.
Все мои эксперименты - чисто из познавательного любопытства.

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

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

Ладно, тему давайте закроем, а то на меня скоро матом уже будут ругаться   

эээ... писать свой менеджер памяти, который будет медленным, но будет отслеживать и неправильные связки usual/[] и многократное удаление одного блока и НЕудаление некоторых блоков и вообще чё душе угодно...

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




Ага, еще предложите свой компилятор написать, который вместо UB исключение выплевывает!   
Не, можно и так, конечно, но пока я на CodeGuard остановлюсь (да простят меня за упоминание о билдере)   

Предлагаю, когда возникнет вопрос отлова ошибки утечки - создать новую тему!

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

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

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

После которого я признался, что Xenon прав и думал, что в общем-то спора нет.


Панацеи в нашей жизни нет. Но так говорить тоже нельзя:


Раз вы не знаете что это такое, то почему не простят?!   Это так, шутка.

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


Да это понятно, это я так, прикололся - не проще ли компилер заставлять ругаться, чем заставлять программистов свои менеджеры памяти создавать. А по поводу 
 Тут я не знаю, у меня же не все ворнинги включены. Если все включить - может и ругнется, попробую как-нибудь.
К тому же очевидного UB я как раз не создал - я переприсвоил указатель, чтобы обмануть компилер. Если теоритически предстваить себе функцию, которая возвращает строку, память под которую сама выделяет (в общем то примерный вопрос этой темы), то в описании функции необходимо точно предупредить каким образом удалять данный блок - со скобками или без, ведь он может выделиться как 
char *Buf = new char[100];
и просто как 
char *Buf = (char*) new(100);
Последнее выглядит несколько извращенно, но допустимо.
Соответственно, если такая функция чужая, и ее разработчик забыл указать, что удалять строку надо delete[], а не delete - вот тут как раз и возникнет UB, который мне не нравится. Было бы абсалютно логично, что блок должен удалиться по-любому, а вот вызов деструкторов - по желанию (собственно почему я и засомневался, правильно я понял стандарт или нет, английский слабоват).
В общем баянище у нас получился - никак не оторваться