OberonCore
https://forum.oberoncore.ru/

Критика С++
https://forum.oberoncore.ru/viewtopic.php?f=61&t=5959
Страница 1 из 8

Автор:  prospero78 [ Среда, 23 Ноябрь, 2016 18:12 ]
Заголовок сообщения:  Критика С++

Сидел, читал, и вот нашёл:https://ru.wikiversity.org/wiki/%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_C%2B%2B#.D0.9D.D0.B5.D1.84.D0.BE.D1.80.D0.BC.D0.B0.D0.BB.D1.8C.D0.BD.D0.B0.D1.8F_.D0.BA.D1.80.D0.B8.D1.82.D0.B8.D0.BA.D0.B0
Упоминаются Вирт, Шиперски, Дейкстра, Керниган, Торвальдс.
Короче, я угорал)))

Вообще, я искал релевантный ответ на вопрос "почему препроцессор -- зло". Но там эта тема, тоже малость затронута. Один из возможных ответов в этой статье:"Однако, само существование в спецификации языка препроцессора препятствует анализу исходных кодов программ (даже простому профилированию), а следовательно, и развитию функциональности интегрированных сред разработки, обеспечивающих поддержку разработки крупномасштабных]] ruen прикладных программ — из-за необходимости полного парсинга кода (на языке с неразрешимой грамматикой) с учётом возможности дублирования (не обязательно взаимозаменяемых) фрагментов[62][61][60][63]. Одной из основных функций, ради которых была придумана условная компиляция в Си, является повышение портируемости, но на практике именно портируемость она и снижает[62]."

Вот ещё вкусняшка:"Повышение быстродействия за счёт перевода управления памятью в ручной режим является заблуждением[72]."; "Ключевым свойством, гарантирующим небезопасность[93], является отсутствие и принципиальная невозможность реализации в С++ встроенного автоматического управления памятью"

"Для обеспечения безопасности мало статических проверок — безопасность в первую очередь является следствием простоты[80], так что сложность С++ сама по себе означает существенное снижение безопасности."

"Система проверки согласования типов С++ принимает программы, некорректность которых очевидна, за корректные, вызывая недоумение у сторонников статической типизации[97]. В дополнение, С++ предоставляет много способов вообще обойти систему типов, что приводит к внедрению ошибок, остающихся незамеченными до момента серьёзного отказа]] ruen"

А вот и возражения Кемету в давешней его аргументации по быстродействию:
"Более того, для ссылочно-прозрачных]] ruen языков возможен глобальный анализ потока управления, за счёт чего компилятор в принципе способен производить такие оптимизации программ, какие компилятор небезопасного языка в принципе не способен, что временами позволяет высокоуровневым языкам уверенно конкурировать в быстродействии с Си."

"Испытания показывают, что оптимизированная вручную реализация сборщика мусора средствами языка Си существенно отстаёт по эффективности от стандартного сборщика мусора, встроенного в язык[120][72][64], а в распределённых системах автоматическое выведение представления указателей компилятором высокоуровневого языка обеспечивает кратный прирост быстродействия по сравнению с решениями по их реализации, которые принимают живые программисты[121]."

"У С++ отсутствует то, что имеет большинство языков программирования — формальное определение грамматики[89]. С++ не проектировался как формальная система — вместо этого он рос и мутировал[89][143]. "

Вирт:"С++ — это нападение на человеческий мозг."

"Унаследованный от Си препроцессор предоставляет возможность буквально за минуту внедрить в гигантскую программу труднообнаружимую ошибку, приводящую к непредсказуемому поведению программы[60] (что принципиально невозможно на типобезопасных языках[264])."

Короче, тихий ужос. Мне жаль два месяца потраченных на изучение С++)))))

Автор:  Artyemov [ Четверг, 24 Ноябрь, 2016 15:24 ]
Заголовок сообщения:  Re: Критика С++

Цитата:
Короче, тихий ужос. Мне жаль два месяца потраченных на изучение С++)))))

Если после этого была сделана соответствующая запись в зачётке, то… ;)

Автор:  prospero78 [ Пятница, 25 Ноябрь, 2016 19:59 ]
Заголовок сообщения:  Re: Критика С++

Моё программирование закончилось зимой на втором курсе института, экзамен зачтён автоматом.
Фортран-77 и GW-Basic. Как радиоинженер, занимаясь программированием, я давно перешагнул планку достаточности радиоинженеру))

Автор:  prospero78 [ Понедельник, 24 Июль, 2017 11:31 ]
Заголовок сообщения:  Re: Критика С++

Зачётная статья на хабре по теме)) Илье понравится)
https://habrahabr.ru/post/333936/

Автор:  Artyemov [ Понедельник, 24 Июль, 2017 11:48 ]
Заголовок сообщения:  Re: Критика С++

"IOCCC, International Obfuscated C Code Contest" и такое существует? Ж8-/

Автор:  Comdiv [ Понедельник, 24 Июль, 2017 14:45 ]
Заголовок сообщения:  Re: Критика С++

В этом одна из проблем. Недостатки языка являются точками отсчёта для всевозможной деятельности, как коммерческой, так и развлекательной, что в конечном итоге приводит к продвижению этих языков. И наоборот, простота и предсказуемость являются скучными и нерентабельными, а потому не способствуют продвижению.

Для Си есть конкурс поинтересней http://underhanded-c.org/, где предлагают нормально выглядящий код, но делающий не совсем то, что от него ожидают.

В принципе, конкурс 2-го типа мог бы быть полезен и для Oberon. Там есть, что копать

Автор:  prospero78 [ Среда, 26 Июль, 2017 11:30 ]
Заголовок сообщения:  Re: Критика С++

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

Автор:  Comdiv [ Среда, 26 Июль, 2017 11:41 ]
Заголовок сообщения:  Re: Критика С++

Отнюдь, поведение при многих нештатных ситуациях не определены, а потому позволяют мутить воду. Посмотрите последний проведённый конкурс Unhandled C, там многие участники просто использовали значение неопределённости в double. Чем в этом плане Oberon отличается от C?
Конкурс для того и нужен, чтобы привлечь внимание и принять меры, а не ходить в розовых очках.

Автор:  prospero78 [ Понедельник, 31 Июль, 2017 14:06 ]
Заголовок сообщения:  Re: Критика С++

Оберон отличается от Си тем, что не будет такого, что в стандарте описано принудительное обнуление и заNULLение, а Оберон этого не делает. Или буйное приведение типов? Или упреждающее объявление процедур? А файлы дефиниций, это вообще изврат!!

Я не стану утверждать, что Оберон -- это предел мечтаний. Но, имхо и не только моё -- объективно Си хуже Оберона. И подавляющее число всяких ваших Луа, ЯваСкриптов, питонов и голангов))

Автор:  Kubanych [ Воскресенье, 20 Август, 2017 14:44 ]
Заголовок сообщения:  Re: Критика С++

Недавно сделал на C++11 с иcпользованием STL довольно большую программу.
До этого предыдущую версию реализовывал на питоне.
А исходную - на BlackBox.

На BlackBox самому приходилось делать сериализатор-десериализатор и много чего.
Некоторое время ушло на привыкание к недостаткам С++11.
А если к ним привыкнуть, STL позволяет сильно ускорить разработку.

Автор:  Comdiv [ Воскресенье, 20 Август, 2017 15:25 ]
Заголовок сообщения:  Re: Критика С++

Попробуйте, пожалуйста, оценить во сколько раз это позволяет ускорить разработку? Желательно учесть, что это уже 3-е воплощение программы.

Автор:  Kubanych [ Воскресенье, 20 Август, 2017 15:56 ]
Заголовок сообщения:  Re: Критика С++

Comdiv писал(а):
Попробуйте, пожалуйста, оценить во сколько раз это позволяет ускорить разработку? Желательно учесть, что это уже 3-е воплощение программы.


B BlackBox я сделал что-то вроде шаблона для работы со списком. Для каждого нового типа данных все делалось через копи-паст.

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

В STL столкнулся с работающими set-ами (для больших коллекций, с маленькими их удобство я и в BlackBox оценил),
а также deque, map.

Со списками, конечно, время разработки в BlackBox меньше, чем в C++11 (даже с ручным собиранием шаблонов).
Ускорение, в основном, за счет применение контейнеров для меня новых типов (set, deque, map),
а также готовыми алгоритмами поиска,
так как, видимо, лень собраться самому написать их аналоги.

Применение этих новых (для меня) типов контейнеров позволило упростить в целом логику обработки данных.

А самописный сериализатор заменил на nlohmann::json.

Автор:  Comdiv [ Воскресенье, 20 Август, 2017 19:07 ]
Заголовок сообщения:  Re: Критика С++

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

К примеру, мой небольшой эксперимент http://comdivbyzero.blogspot.com/2013/07/blog-post_20.html показал, что я на использование "готовых" шаблонных решений на C++ для ассоциативных массивов потратил в 3-4 раза больше времени, чем на самодельную расстановку на C. Конечно, это частный случай, и для более сложных алгоритмов я бы не стал без необходимости самодельничать, но я часто вижу в коде коллег попытки использовать сложные алгоритмы из библиотек, так где можно обойтись очень простым кодом без библиотек, потому что они не видят лёгких решений. Также я часто вижу как коллеги на С++ наворачивают абстракции ради абстракций, производя много кода, не делающего ничего полезного. Поэтому для меня большой вопрос, во сколько раз использование C++ ускоряет разработку по сравнению с менее навороченными языками, и поэтому я его постоянно задаю.

Ещё одна вещь, которая мне не понятна, почему на КП Вы использование копирование кода для работы со списком, вместо того, чтобы использовать расширение от базового типа. Боролись за эффективность и за статические проверки?

Автор:  Иван Денисов [ Понедельник, 21 Август, 2017 10:48 ]
Заголовок сообщения:  Re: Критика С++

Comdiv писал(а):
Ещё одна вещь, которая мне не понятна, почему на КП Вы использование копирование кода для работы со списком, вместо того, чтобы использовать расширение от базового типа. Боролись за эффективность и за статические проверки?

Пример из текущего проекта. У меня вот в одном объекте три независимых списка. Получается, что метод наследования не работает. Но работает метод включения. А для этого типа List уже есть 2 стандартных процедуры Add, Remove. Но эти процедуры у меня сделаны особым образом под мою задачу, с учетом специфики использования (быстрое добавление, удаление по содержимому). Поэтому применить некий сторонний абстрактный List было бы не очень эффективно.

Автор:  Kubanych [ Понедельник, 21 Август, 2017 12:27 ]
Заголовок сообщения:  Re: Критика С++

Comdiv писал(а):
Я, честно говоря, так и не понял, во сколько раз была ускорена разработка, или, вообще, замедлена.


нет линейной зависимости с постоянным коэффициентом типа y=k*x+b.
Есть много факторов, самый важный из которых -
наличие готового к использованию механизма сейчас
или делать его аналог и потратить неопределенное время.

Автор:  Comdiv [ Понедельник, 21 Август, 2017 13:31 ]
Заголовок сообщения:  Re: Критика С++

Иван Денисов писал(а):
эти процедуры у меня сделаны особым образом под мою задачу, с учетом специфики использования (быстрое добавление, удаление по содержимому). Поэтому применить некий сторонний абстрактный List было бы не очень эффективно.
Такой вариант понятен, в таком случае, как я понимаю, и шаблоны не очень подходят, но ведь в сообщении Кубанычбека речь шла именно о copy-paste.

Автор:  Kubanych [ Понедельник, 21 Август, 2017 13:35 ]
Заголовок сообщения:  Re: Критика С++

Ускорение разработки за счет применения готового set (и других контейнеров),
за счет чего удалось упростить алгоритм (не имея своей реализации set мне приходилось использовать
динамические массивы и списки + дописывать алгоритмы)

Автор:  Kemet [ Понедельник, 21 Август, 2017 17:59 ]
Заголовок сообщения:  Re: Критика С++

Comdiv писал(а):
и шаблоны не очень подходят, но ведь в сообщении Кубанычбека речь шла именно о copy-paste.
по причине отсутствия дженериков. дженерики рулят

Автор:  Rifat [ Среда, 06 Сентябрь, 2017 14:42 ]
Заголовок сообщения:  Re: Критика С++

Kubanych писал(а):
В STL столкнулся с работающими set-ами (для больших коллекций, с маленькими их удобство я и в BlackBox оценил),
а также deque, map.

STL, конечно, хорош. Но есть и недостатки. Например, фирма Electronic Arts для своих целей создала свой аналог STL, который называется EASTL. Есть интересная статья, где описываются недостатки STL:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

Автор:  Kubanych [ Воскресенье, 10 Сентябрь, 2017 11:43 ]
Заголовок сообщения:  Re: Критика С++

Rifat писал(а):
Kubanych писал(а):
В STL столкнулся с работающими set-ами (для больших коллекций, с маленькими их удобство я и в BlackBox оценил),
а также deque, map.

STL, конечно, хорош. Но есть и недостатки. Например, фирма Electronic Arts для своих целей создала свой аналог STL, который называется EASTL. Есть интересная статья, где описываются недостатки STL:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html


Ну, вот, жизнь продолжается.
Если бы Оберон-инструментарий позволял также быстро делать свои сложные структуры данных, не вдаваясь в подробности реализации, ...

Страница 1 из 8 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/