Можно, но это просто будет означать совсем другое. char* x = 0; даст указатель с null pointer value, а char* x = y - y; даст указатель с битовым значением, равным нулю. null указатель и нулевое битовое представление адреса - это в общем случае разные вещи. https://c-faq.com/null/machnon0.html
Главное, чтобы вы не заменяли профессионализм на ритуалы. Все эти приставки ТруЪ - это фанатизм в худшем его проявлении. Все эти ТруЪ стремятся поделить мир на белое и чёрное, на труъ и не труъ. Но не бывает хороших или плохих инструментов, бывают подходящие или неподходящие.
Бесполезное дело непрограммисту это все описывать. Все равно превратно будет понято. А чтобы это понять, нужно хотя бы два разных проекта целиком написать. Некоторым людям вообще лет 20 нужно пробыть в разработке, чтобы начать хоть что-то понимать. Автор наверняка меньше работает и его пост поэтому - это сплошной максимализм и лозунги.
Автор не прав по форме. Конкретные аргументы выглядят верными, но в целом это просто словесный эквилибризм. Автор выбрал позицию-оппонента "ООП - серебряная пуля" и остервенело её опровергает, резюмируя, что раз это не пуля, значит это скам. А на деле просто берется тот инструмент, который подходит к задаче (сюда относится и знание конкретных инструментов берущими). Все разнообразные определения, подходы и методики, описываемые в разных источниках, нужны лишь чтобы помочь сделать этот выбор более осознанно.
Мне кажется не совсем верно понят контекст. Здесь вообще не шло речи о том, что кто-то чего-то заставляет или не зставляет. Также не шло никакой речи о том, как делать можно и как нельзя. Речь лишь шла о том, почему полезно различать C++ и его диалекты не только с формальной точки зрения, но и с практической.
Отвечая на вопрос выше: нет, стандарт C++ не требует наличия throw\catсh в коде, но стандарт требует наличия обеспечения этих возможностей в компиляторе. Если компилятор не поддерживает эти возможности (или вы\мы их насильно отключили), то этот компилятор (или его текущая конфигурация) перестает считаться компилятором С++. Формально. Но тут есть нюанс. Весь этот формализм начинает стрелять по ногам во вполне реальных ситуациях. Допустим мы отключили исключения в своем коде и вызываем некую библиотечную функцию (не нашу), которая написана на С++. И эта функция бросает исключение. Стандарт С++ описывает что должно произойти, если в наш код попадёт это исключение, что произойдет если мы его поймаем и что произойдет, если не поймаем. Но наш код скомпилирован без поддержки исключений вообще. Что произойдет? Неизвестно. По крайней мере стандарт С++ тут нам уже точно не помощник. Так к чему же обращаться, как разъяснить вопрос? Правильно, мы обращаемся с документации компилятора и там скорее всего будет написано, что произойдет в этом случае. Но документация - это не стандарт С++. То есть буквально у нас теперь на руках код, который похож на С++, но часть поведения этого кода не описывается стандартом С++ и стандарт С++ даже не ссылается на какой-то implementation-defined источник, как это бывает в других случаях.
Но мне все равно кажется что переход от заявления:
> Нет исключений - не C++
претендующего на всеобщность и идентификацию языка С++ через исключения к скромному :
Это не переход, а пояснение. Я пояснил о чем шла речь. Формальный язык тем и отличается от естественного, что описать его очень просто с помощью формальной логики. Так что да, формально, С++ без исключений - это не С++, а какой-то другой, похожий на него язык (диалект). Потому что исключения входят в множество слов, образующих С++.
> Это как утверждать что американский язык это не английский язык. Аналогии с естественным языком и бытовыми примерами не работают в этом аспекте.
на сколько я это понимаю С++ есть смысл отличать только от чистого Си.
Конечно нет. C++ есть смысл отличать от его диалектов и, отключая исключения, мы переключаемся на диалект (который, к слову, по-разному будет реализован в разных компиляторах - и вот тут уже становится критично важным это различие, если мы хотим обеспечивать переносимость). Откройте любую документацию по любому компилятору, и вы увидите в ней описание поддерживаемых диалектов. Я ниже по ветке уже привел пример различий с диалектом GNU, у MS тоже есть в документации секции, описывающие диалект VC++.
Но корневой веткой которая делает из чистого Си -> С++ является наличие классов, но ни как не исключений.
Любой язык программирования - это формальный язык. Два формальных языка эквивалентны, если они содержат одинаковое множество слов. Так что когда вам говорят, что формально C++ перестает быть C++, если мы убираем из него исключения, то это как раз об этом.
возникает справедливый вопрос на который нет ответа: "Если это не С++ то что это?".
Это диалект.
-----
В общем и целом я нисколько не удивлен такой реакции от вас. Ниже по ветке тоже об этом писал.
Ну зря вы иронизируете. В контексте темы статьи это может быть и не важно, но когда речь заходит о переносимости приходится возвращаться к этим вопросам. Например, ведь GNU-диалект разрешает, как известно, массивы с размерностью времени исполнения, а C++ нет. И если мы уж используем эту фичу, то должны понимать, что это диалектная фича и работать она в других компиляторах не обязана.
В целом, в подобных дискуссиях всегда наблюдается некоторое недопонимание, ведь обычные программисты юридически мыслить в контексте используемых языков почти не умеют. Для них если компилируется, значит C++, а попытки разъяснить юридическую сторону вопроса чаще всего просто воспринимаются в штыки. Проще всего (для сохранения конструктива) просто быть на их волне и не поднимать этих тем.
Диалект. Собственно это не единичный пример. Вот когда человек берет и запускает компилятор, ну, скажем, G++, с параметрами по-умолчанию, он тоже нифига не С++ использует, а его диалект GNU. И чтобы получить C++, нужно еще поднастроить параметры сборки, добавив ключей.
Речь же не об этом. Напомню контекст: > Нет исключений - не C++. Де-юре это так. > если программист использует пол сотни других возможностей, но не использует какую-то одну ... А мой комментарий о том, что за отключением исключений потянется еще, никак не одна, возможность.
Есть языковые механизмы, которые полагаются на исключения вне зависимости от желания программиста. Например new бросает bad_alloc, dynamic_cast бросает bad_cast, стандартные контейнеры бросают исключения. То есть в целом недостаточно просто не использовать исключения, нужно еще знать какие языковые средства их используют и исключить их из кода тоже.
Но этот пример мимо же. Студенту дают задание, чтобы он научился, а не чтобы выполнить задачу по факту. Выполнение задачи в процессе обучения - это побочный эффект. Так что если слесарю дали кусок трубы, чтобы он научился пилить ручной пилой, ему нужно пилить ручной пилой, иначе никак.
Вместо Старуструпа можно взять Липпмана.
Который пришел туда из boost, где был c 2003 года.
Можно, но это просто будет означать совсем другое. char* x = 0; даст указатель с null pointer value, а char* x = y - y; даст указатель с битовым значением, равным нулю. null указатель и нулевое битовое представление адреса - это в общем случае разные вещи. https://c-faq.com/null/machnon0.html
Главное, чтобы вы не заменяли профессионализм на ритуалы. Все эти приставки ТруЪ - это фанатизм в худшем его проявлении. Все эти ТруЪ стремятся поделить мир на белое и чёрное, на труъ и не труъ. Но не бывает хороших или плохих инструментов, бывают подходящие или неподходящие.
Причем сам он точно также использует эти приёмы.
"Общеизвестный в сообществе факт..." - это приём называемый "апелляция к очевидности".
Бесполезное дело непрограммисту это все описывать. Все равно превратно будет понято. А чтобы это понять, нужно хотя бы два разных проекта целиком написать. Некоторым людям вообще лет 20 нужно пробыть в разработке, чтобы начать хоть что-то понимать. Автор наверняка меньше работает и его пост поэтому - это сплошной максимализм и лозунги.
Автор не прав по форме. Конкретные аргументы выглядят верными, но в целом это просто словесный эквилибризм. Автор выбрал позицию-оппонента "ООП - серебряная пуля" и остервенело её опровергает, резюмируя, что раз это не пуля, значит это скам.
А на деле просто берется тот инструмент, который подходит к задаче (сюда относится и знание конкретных инструментов берущими). Все разнообразные определения, подходы и методики, описываемые в разных источниках, нужны лишь чтобы помочь сделать этот выбор более осознанно.
Мне кажется не совсем верно понят контекст. Здесь вообще не шло речи о том, что кто-то чего-то заставляет или не зставляет. Также не шло никакой речи о том, как делать можно и как нельзя. Речь лишь шла о том, почему полезно различать C++ и его диалекты не только с формальной точки зрения, но и с практической.
Отвечая на вопрос выше: нет, стандарт C++ не требует наличия throw\catсh в коде, но стандарт требует наличия обеспечения этих возможностей в компиляторе. Если компилятор не поддерживает эти возможности (или вы\мы их насильно отключили), то этот компилятор (или его текущая конфигурация) перестает считаться компилятором С++. Формально. Но тут есть нюанс. Весь этот формализм начинает стрелять по ногам во вполне реальных ситуациях.
Допустим мы отключили исключения в своем коде и вызываем некую библиотечную функцию (не нашу), которая написана на С++. И эта функция бросает исключение. Стандарт С++ описывает что должно произойти, если в наш код попадёт это исключение, что произойдет если мы его поймаем и что произойдет, если не поймаем. Но наш код скомпилирован без поддержки исключений вообще. Что произойдет? Неизвестно. По крайней мере стандарт С++ тут нам уже точно не помощник. Так к чему же обращаться, как разъяснить вопрос? Правильно, мы обращаемся с документации компилятора и там скорее всего будет написано, что произойдет в этом случае. Но документация - это не стандарт С++. То есть буквально у нас теперь на руках код, который похож на С++, но часть поведения этого кода не описывается стандартом С++ и стандарт С++ даже не ссылается на какой-то implementation-defined источник, как это бывает в других случаях.
Это не переход, а пояснение. Я пояснил о чем шла речь.
Формальный язык тем и отличается от естественного, что описать его очень просто с помощью формальной логики. Так что да, формально, С++ без исключений - это не С++, а какой-то другой, похожий на него язык (диалект). Потому что исключения входят в множество слов, образующих С++.
> Это как утверждать что американский язык это не английский язык.
Аналогии с естественным языком и бытовыми примерами не работают в этом аспекте.
Я написал чего. В первом предложении:
Потому что <диалект> - это устоявшийся термин, используемый в документации к компиляторам.
Конечно нет. C++ есть смысл отличать от его диалектов и, отключая исключения, мы переключаемся на диалект (который, к слову, по-разному будет реализован в разных компиляторах - и вот тут уже становится критично важным это различие, если мы хотим обеспечивать переносимость). Откройте любую документацию по любому компилятору, и вы увидите в ней описание поддерживаемых диалектов. Я ниже по ветке уже привел пример различий с диалектом GNU, у MS тоже есть в документации секции, описывающие диалект VC++.
Любой язык программирования - это формальный язык. Два формальных языка эквивалентны, если они содержат одинаковое множество слов. Так что когда вам говорят, что формально C++ перестает быть C++, если мы убираем из него исключения, то это как раз об этом.
Это диалект.
-----
В общем и целом я нисколько не удивлен такой реакции от вас. Ниже по ветке тоже об этом писал.
Ну зря вы иронизируете. В контексте темы статьи это может быть и не важно, но когда речь заходит о переносимости приходится возвращаться к этим вопросам. Например, ведь GNU-диалект разрешает, как известно, массивы с размерностью времени исполнения, а C++ нет. И если мы уж используем эту фичу, то должны понимать, что это диалектная фича и работать она в других компиляторах не обязана.
В целом, в подобных дискуссиях всегда наблюдается некоторое недопонимание, ведь обычные программисты юридически мыслить в контексте используемых языков почти не умеют. Для них если компилируется, значит C++, а попытки разъяснить юридическую сторону вопроса чаще всего просто воспринимаются в штыки. Проще всего (для сохранения конструктива) просто быть на их волне и не поднимать этих тем.
Диалект.
Собственно это не единичный пример. Вот когда человек берет и запускает компилятор, ну, скажем, G++, с параметрами по-умолчанию, он тоже нифига не С++ использует, а его диалект GNU. И чтобы получить C++, нужно еще поднастроить параметры сборки, добавив ключей.
Что значит "тем не менее"? Я где-то говорил, что без исключений нельзя?
Речь же не об этом. Напомню контекст:
> Нет исключений - не C++. Де-юре это так.
> если программист использует пол сотни других возможностей, но не использует какую-то одну ...
А мой комментарий о том, что за отключением исключений потянется еще, никак не одна, возможность.
Есть языковые механизмы, которые полагаются на исключения вне зависимости от желания программиста. Например new бросает bad_alloc, dynamic_cast бросает bad_cast, стандартные контейнеры бросают исключения. То есть в целом недостаточно просто не использовать исключения, нужно еще знать какие языковые средства их используют и исключить их из кода тоже.
Потому что наверняка перевод делался с использованием нейросети.
Но этот пример мимо же. Студенту дают задание, чтобы он научился, а не чтобы выполнить задачу по факту. Выполнение задачи в процессе обучения - это побочный эффект. Так что если слесарю дали кусок трубы, чтобы он научился пилить ручной пилой, ему нужно пилить ручной пилой, иначе никак.