Главное, чтобы вы не заменяли профессионализм на ритуалы. Все эти приставки ТруЪ - это фанатизм в худшем его проявлении. Все эти ТруЪ стремятся поделить мир на белое и чёрное, на труъ и не труъ. Но не бывает хороших или плохих инструментов, бывают подходящие или неподходящие.
Бесполезное дело непрограммисту это все описывать. Все равно превратно будет понято. А чтобы это понять, нужно хотя бы два разных проекта целиком написать. Некоторым людям вообще лет 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, стандартные контейнеры бросают исключения. То есть в целом недостаточно просто не использовать исключения, нужно еще знать какие языковые средства их используют и исключить их из кода тоже.
Но этот пример мимо же. Студенту дают задание, чтобы он научился, а не чтобы выполнить задачу по факту. Выполнение задачи в процессе обучения - это побочный эффект. Так что если слесарю дали кусок трубы, чтобы он научился пилить ручной пилой, ему нужно пилить ручной пилой, иначе никак.
Эм, но проект же про корпус, а не про материнку. Кому надо, тот в своей реализации заменит материнская плату на правильную, видеокарты опустит ниже и все получится.
Это просто формализация того, что и так уже было. Только было как раз неочевидно (потому в разных реализациях, бывало, понималось по-разному). А сейчас просто взяли и привели это все в систему. Да, получилась она не самая простая, но это явно лучше, чем оставлять все как было. Так что нет, вы со своим оценочным и явно больше эмоциональным, чем конструктивным, суждением - не правы.
Главное, чтобы вы не заменяли профессионализм на ритуалы. Все эти приставки ТруЪ - это фанатизм в худшем его проявлении. Все эти ТруЪ стремятся поделить мир на белое и чёрное, на труъ и не труъ. Но не бывает хороших или плохих инструментов, бывают подходящие или неподходящие.
Причем сам он точно также использует эти приёмы.
"Общеизвестный в сообществе факт..." - это приём называемый "апелляция к очевидности".
Бесполезное дело непрограммисту это все описывать. Все равно превратно будет понято. А чтобы это понять, нужно хотя бы два разных проекта целиком написать. Некоторым людям вообще лет 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, стандартные контейнеры бросают исключения. То есть в целом недостаточно просто не использовать исключения, нужно еще знать какие языковые средства их используют и исключить их из кода тоже.
Потому что наверняка перевод делался с использованием нейросети.
Но этот пример мимо же. Студенту дают задание, чтобы он научился, а не чтобы выполнить задачу по факту. Выполнение задачи в процессе обучения - это побочный эффект. Так что если слесарю дали кусок трубы, чтобы он научился пилить ручной пилой, ему нужно пилить ручной пилой, иначе никак.
Так они просто сделали лучше, чем было в Eclipse. Поэтому и не помешало.
Эм, но проект же про корпус, а не про материнку. Кому надо, тот в своей реализации заменит материнская плату на правильную, видеокарты опустит ниже и все получится.
Это просто формализация того, что и так уже было. Только было как раз неочевидно (потому в разных реализациях, бывало, понималось по-разному). А сейчас просто взяли и привели это все в систему. Да, получилась она не самая простая, но это явно лучше, чем оставлять все как было. Так что нет, вы со своим оценочным и явно больше эмоциональным, чем конструктивным, суждением - не правы.