Допустимые операции с нулевым указателем

Не if (all) delete all;, а delete []all;

	Комментарий модератора
	Эта ветка была вырезана из другой темы, т.к. количество оффтопа превысило все допустимые рамки.

0

Сообщение от Fulcrum_013 росто к тому что Билдер не Дельфа, он не для формошлепства а для серьезных задач.

ой ли подход то один и тот же

0

Сообщение от ValeryS нахрена козе баян пара файлов привязки к железу, все остальное стандартный код, и никаких проблем

Вот так собственно Керниган и Ритч и мыслили себе С. точно так же его мыслит и борланд - пару файлов привязки к железу и смена паттернов под другой машкод - и шлепаем формы для ATTiny

Добавлено через 38 секунд

Сообщение от ValeryS ой ли подход то один и тот же

Подход к чему?

Добавлено через 4 минуты

Сообщение от daslex Изначально появилась необходимость в принятии стандарта, чтобы не было слишком больших различий между одним языком.

Тогда было два перспективных языка. Один жестко стандартизировали. Называется Ада. Тошнило от нее всех и долго (Вирта к тому времени вообще шиза готобоязни и указателефобии зажрала).

0

Я о С++ и только о С++. Ни С ни Ада тут не причем. Стандарт С++ появился не в первый год жизни С++

Добавлено через 3 минуты

Сообщение от Fulcrum_013 Но с тем насколько бурно развиваются в последнее время процы

а как бурно они будут развиваться? Их больше маркетологи чем технологи развивают.

Добавлено через 2 минуты

0

Сообщение от daslex Стандарт С++ появился не в первый год жизни С++

Чтобы что то начали стандартизировать оно должно быть либо широко распространено (С++) либо куплено Пентагоном (Ада). А по поводу стандартизации - появляется как и компиляция расширений синтаксиса (борланд-MS -Intel) так и возможность юзать lib-ы в чужом формате, а то и чужой компилятор цеплять к своей IDE. Так что получается свой комитет по стандартизации, и ложили они на все остальные комитеты, потому как процы(машкод), ОС и нововведения в синтаксисе/разработке/подходу к проектированию именно эта троица двигает, а соответственно они будут подстраивать язык под свои нужды, а не подстраиваться под какой то коммитет. Диалекты для микроконтроллеров не берем, там отдельная песня и STL лямбды и foreach там сто лет не улыбалась (там такие отклонения от нормы лечатся ассемблерными вставками), а там где улыбалось оно уже обогнало по производительности/возможностям видео и переферии те компы на которых Билдер и VS начинали.
А все попытки что то там еще в STL стандартизировать чтоб safe-pointers и програмист даже забыл что у массива есть размер, ну это по большому счету попытка плюсы шарпнуть, но при этом типа чтоб плюсами остались. Вообще кстати только здесь узнал что основными плюсами плюсов считается STL(наверное кресты). Всегда думал что главные плюсы - добавление ООП, перегрузки операторов и т.п.

0

Добавлено через 58 секунд
Чего там с компиляторами?

0

Добавлено через 5 минут

Сообщение от daslex Чего там с компиляторами?

А что с компиляторами - у интела поддержка AVX на уровне оптимизатора, У борланда inline asm инструкции понимает но сам в код ни сует - значит что-то знают и выжидают. скорее всего новый набор команд который определит направление перехода к арифметике над массивами.

Добавлено через 1 минуту

Сообщение от ValeryS ой ли подход то один и тот же

Ну да. Я вот подоумываю не выкинуть ли из текущего большого проекта последнюю форму чтобы не мешала.

0

0

Добавлено через 4 минуты

Сообщение от daslex Чего там с компиляторами?

А вот кстати bcc64 в отличии от bcc32 не идет по деструкторам.

0

пойдет ли по деструкторам'

Сообщение от ForEveR Fulcrum_013, Не пойдет. Если пойдет значит компилятор не следует стандарту.

Даже собственного стандарта удержаться не могут. Куда им до тех, на которые ориентируются программисты.

Добавлено через 1 минуту
...

Сообщение от Fulcrum_013 А вот кстати bcc64 в отличии от bcc32 не идет по деструкторам.

0

Сообщение от daslex Даже собственного стандарта удержаться не могут. Куда им до тех, на которые ориентируются программисты.

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

0

Судя по всему в обсуждении имеет место легкое недопонимание стандарта. Давайте посмотрим еще раз (м.б. косяки в нумерации так что извиняйте). Пункт 5.3.5/7

If the value of the operand of the delete-expression is not a null pointer value, the delete-expression will call a deallocation function (3.7.4.2). Otherwise, it is unspecified whether the deallocation function will be called.

Здесь говорится о том, что стандарт не специфицирует (т.е. не требует) вызова деаллокатора любого вида для nullptr указателя. Оно и понятно, смысла по большому счету-то не много. НО. Как мы видим, если вдруг разработчик компилятора все же решит встроить такой вызов, то, как видно из текста, такой случай автоматически попадает под ограничения из упомянутого (3.7.4.2). Давайте посмотрим на него.

The value of the first argument supplied to a deallocation function may be a null pointer value; if so, and if the deallocation function is one supplied in the standard library, the call has no effect.

Все вроде бы понятно. Тут делается акцент на требовании не делать абсолютно ничего если будет вызван стандартный деаллокатор, но не наложено никаких ограничений на "пользовательские". Очевидно, что такие должны быть написаны грамотно. Но как эти пункты работают в паре? А рассмотрев их оба, можно сделать следующий вывод, который, кстати, не будет идти вразрез. А именно.
Поведение будет считаться определенным (well-defined) если:
1) используется стандартный деаллокатор;
2) используется пользовательский деаллокатор, который корректно обрабатывает nullptr.
Собственно все.

0

0

HighPredator, да не в этом дело. Тему полностью не читали. У нас стандарты - это устаревший материал. Ветхий завет своего рода.
А Новый завет - это у нас Builder. Он выше всех стандартов. Типа стандарт под Builder подгонять будут.
И не поймите меня неправильно. Это не мое мнение.

При этом вопрос не про nullptr, а про NULL, проверки перед удалением и удаление со скобками [],
95% ориентируются на стандарт и говорят, что проверка не обязательна и это UB
а 5% убеждены, что проверка обязательна, но при этом скобки [] вообще лишний хлам
(речь об высвобождении памяти выделенной для массива)

Добавлено через 6 минут
И если что, Стандартом не убедить. Стандарт - изжитки прошлого Такие вот дела.

0

Сообщение от daslex а 5% убеждены, что проверка обязательна,

скажем так по трассировке bcc32 идет по деструкторам, bcc64 нет. Соответственно если код делается и под 32 и под 64 то придется ставить проверку.

Сообщение от daslex о при этом скобки [] вообще лишний хлам

Если менеджер кучи сделан толково то [] они таки не нужны.

Добавлено через 9 минут

Сообщение от daslex И если что, Стандартом не убедить. Стандарт - изжитки прошлого Такие вот дела

компилятор - инструмент. и если я этот инструмент использую то наиболее авторитетным взглядом на то каким он ДОЛЖЕН быть будет мой взгляд. Точно так же на то каким он должен быть при использовании вами наиболее авторитетным есть ваш взгляд. Ну а реально он такой как увидел Borland, Microsoft, Intel и т.д. Вообще я так считаю надо идти не по пути жесткой стандартизации синтксиса, а по пути увеличения гибкости настройки парсера и кодогенератора, при этом сами настройки тоже писать в заголовочную часть. Тогда получим очень гибкий инструмент, способный подстраиваться пофайлово под любой уже существующий код, и под потребности программера. Т.е. будет позволять объеденить в результате в одном проекте код к примеру написаный мной и вами, при том что мы даже не знаем какие настройки компилятора друг у друга. Builder в этом плане штука наиболее продвинутая, т.к умеет даже вообще заменить парсер на парсер другого языка

0

Да Вы не меня убеждайте. Я еще в яслях
Я ни один компилятор не называл плохим НИКОГДА. Если компилятор полностью позволяет решать возникающие задачи, то этого компилятора достаточно, чтобы решать возникающие задачи.

Если для решения задач подходит Turbo C, значит Turbo C хороший компилятор для решения этих задач.
Если Buider, то Builder хороший компилятор
и т.д.

Дело не в этом.
В идеале должно быть так, что ВСЕ компиляторы придерживаются единой документации и поддерживают ее. В то же время любой из компиляторов обязан развиваться, поэтому отклонения от стандарта неизбежны, а уж если отклонения признали разные сообщества, то эти отклонения должны включаться в новые стандарты.

А у нас что, а у нас - БАРДАК.
Если используешь то, что не придерживается ни общепринятого стандарта, ни даже своего собственного, то проверки нужны вообще абсолютно везде. Либо нужно досконально изучать стандарт своего инструмента.

0

Сообщение от daslex В идеале должно быть так, что ВСЕ компиляторы придерживаются единой документации и поддерживают ее.

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

0

Ну и на что им ориентироваться, чтобы выдавать единый псевдокод. Друг к другу в офисы бегать?

Добавлено через 2 минуты
В идеале должен быть только 1 компилятор

0

Сообщение от daslex В идеале должен быть только 1 компилятор

И я о том же. А в качестве его настроек - диаграммы Бэкуса-Наура Собственно говоря реализацию этого сейчас и пишу.

0

и этот компилятор bcc

0

Сообщение от daslex и этот компилятор bcc

Ну если мыслить как учили в ликбезе - то это компилятор блок-схем.

0