Развейте мои сомнения: упростится ли программирование при переходе от C к C++?

Цитата Олег М @ 13.03.17, 06:58

Речь вроде было о том, что программа на C++ требует подключения большего количества библиотек, чем аналогичная на Си.

Только в двух случаях: используется плюсовые аналоги вместо исходных ламповых; если вместо плюсовых аналогов в исходных ламповых изначально были написаны костыли.

Добавлено 17.03.17, 15:07

Цитата Олег М @ 13.03.17, 06:58

Речь вроде было о том, что программа на C++ требует подключения большего количества библиотек, чем аналогичная на Си.

Только в двух случаях: используется плюсовые аналоги вместо исходных ламповых; если вместо плюсовых аналогов в исходных ламповых изначально были написаны костыли.

Цитата Flex Ferrum @ 13.03.17, 07:35

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

Цитата Qraizer @ 17.03.17, 15:03

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

Раздел language support в стандарте. Возможно, что игрой с опциями компиляции можно полностью выпилить и RTTI, и исключения, и менеджмент памяти.

Цитата applegame @ 13.03.17, 08:43

Идеальный сферический язык (и компилятор) не должен требовать никаких линтеров и анализаторов.

Тю, сферический... Ада.

Добавлено 17.03.17, 15:14

Цитата JoeUser @ 13.03.17, 08:45

А SFINAE вообще вершина маразма.

Маразм был его отсутствие.

void f(int);
void f(char*);
 
/* ... */
 
f(123);

Тут должна быть ошибка компиляции со ссылкой на вторую функцию... ой, не, не должно... не должно же? А почему? Ведь 123 не кастуется к char*. JoeUser, SFINAE – логическое продолжение этого поведения, только не для параметров функций, а для параметров шаблонов.

Добавлено 17.03.17, 15:20

Цитата Flex Ferrum @ 17.03.17, 14:57

Я тоже сначала так подумал. Потом посмотрел на код вызова (последняя строчка). Тут что-то близкое к UB.

Да, если говорим о гарантиях Стандарта, нет, если вменяемую среду разработки. Но в целом, подобные вещи легко нивелируются интерфейсами, которые проектируются правильно, а не представляют собой винегрет из легаси и мейнстрима.

Добавлено 17.03.17, 15:21

Цитата Flex Ferrum @ 17.03.17, 15:09

Возможно, что игрой с опциями компиляции можно полностью выпилить и RTTI, и исключения, и менеджмент памяти.

Не обязательно. Вообще же, я даже могу намекнуть на hosted и freestanding.

Сообщение отредактировано: Qraizer - 17.03.17, 15:21

Цитата Астарот @ 17.03.17, 10:44

А некоторые таковыми и остаются Sad, but...

... but it's too early to put an end on it so far

Цитата Qraizer @ 17.03.17, 15:09

Но в целом, подобные вещи легко нивелируются интерфейсами, которые проектируются правильно, а не представляют собой винегрет из легаси и мейнстрима.

Допустим. Как разрулить конкретный пример интерфейсами, которые спроектированы правильно? Особенно учитывая, что подобное запросто может встретиться при их реализации.

Цитата Flex Ferrum @ 17.03.17, 14:57

Если после push_back в пятой строчке произойдёт реаллокация - то наступит жопа.

Я, кстати, так и не понял - является ли формально UB первый push_back, или нет. Но все проверенные компиляторы его выполняют нормально.

Цитата Flex Ferrum @ 17.03.17, 14:57

Я тоже сначала так подумал. Потом посмотрел на код вызова (последняя строчка). Тут что-то близкое к UB. Если после push_back в пятой строчке произойдёт реаллокация - то наступит жопа.

По-моему, жопа там наступит уже в первом push_back. Разве не сначала выделяется память, а потом вызывается конструктор, в данном случае копирования?

Цитата Астарот @ 17.03.17, 06:53

Ну, перепутал чувак с Dart'ом, ну с кем не бывает? Rust, dart... Адна мадна.

Правда. Перепутал с дартом.
Прошу понять. И простить.

Цитата Олег М @ 18.03.17, 05:47

По-моему, жопа там наступит уже в первом push_back. Разве не сначала выделяется память, а потом вызывается конструктор, в данном случае копирования?

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

Цитата OpenGL @ 18.03.17, 05:10

является ли формально UB первый push_back, или нет

Зависит от состояния вектора. Надо заполнить вектор до вместимости, а потом выполнить вызов. Желательно, чтобы у элемента был конструктор перемещения или реально разрушающий объект деструктор. Это для того, чтобы разрушенный объект не мог изобразить из себя рабочий.

Цитата OpenGL @ 18.03.17, 05:10

Допустим. Как разрулить конкретный пример интерфейсами, которые спроектированы правильно? Особенно учитывая, что подобное запросто может встретиться при их реализации.

Очень простой, но для некоторых очень неожиданный ответ: функция push_twice() хоть с каким интерфейсом вообще не должна существовать в её нынешней реализации. Обоснование: она не удовлетворяет строгой гарантии отказоустойчивости. Если эту её проблему решить, интерфейс внезапно перестанет быть важным фактором.

Сообщение отредактировано: Qraizer - 18.03.17, 18:32

Цитата Qraizer @ 18.03.17, 18:31

Очень простой, но для некоторых очень неожиданный ответ: функция push_twice() хоть с каким интерфейсом вообще не должна существовать в её нынешней реализации. Обоснование: она не удовлетворяет строгой гарантии отказоустойчивости.

Пф. Тогда бы уж сразу сказал "неправильный код не должен писаться" - этот подход избавляет не только от описанной мной, а вообще от любых ошибок Да и с чего бы не должна существовать? std::sort с компаратором по такой логике тоже существовать не должна - поскольку программист в ней может порушить нафиг сортируемый вектор, она не удовлетворяет строгой гарантии отказоустойчивости. Выпиливаем её из С++17?

Цитата OpenGL @ 18.03.17, 20:05

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

Прости, я как-то не догадался сказать очевидное. std::sort<>() вообще-то гарантирует строго, push_twice() же предоставляет лишь базовую гарантию, а вызывающая сторона, можно сказать, нарушает даже Стандарт C. О чём тут вообще говорить? К слову, подобные ошибки на ура должны обнаруживаться даже анализаторами, и я не удивлюсь, если и компиляторы такие найдутся.

Цитата Qraizer @ 19.03.17, 02:30

std::sort<>() вообще-то гарантирует строго

Эм? Что именно она гарантирует? В процессе сортировки итераторы не должны инвалидироваться, и на этот счёт у std::sort нет и не может быть никаких гарантий - она полагается на то, что программист не сделает это случайно. Это по большому счёту ничем не отличается от требований push_twice.

Цитата Qraizer @ 19.03.17, 02:30

К слову, подобные ошибки на ура должны обнаруживаться даже анализаторами, и я не удивлюсь, если и компиляторы такие найдутся.

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

Цитата Qraizer @ 17.03.17, 15:09

SFINAE – логическое продолжение этого поведения, только не для параметров функций, а для параметров шаблонов.

Я в курсе. И, тем не менее, помогать компилятору помогать тебе контролировать тебе свои типы - нехорошая черта (типизированного) языка. ИМХО.

Цитата OpenGL @ 19.03.17, 05:13

В процессе сортировки итераторы не должны инвалидироваться, и на этот счёт у std::sort нет и не может быть никаких гарантий - она полагается на то, что программист не сделает это случайно. Это по большому счёту ничем не отличается от требований push_twice.

Но по крайней мере std::sort сама итераторы не портит.