OberonCore https://forum.oberoncore.ru/ |
|
Критика С++ https://forum.oberoncore.ru/viewtopic.php?f=61&t=5959 |
Страница 4 из 8 |
Автор: | PSV100 [ Четверг, 08 Ноябрь, 2018 20:33 ] |
Заголовок сообщения: | Re: Критика С++ |
Ещё не помешает и по сторонам взглянуть. Насчёт того же переполнения, более-менее адекватный подход реализовали в Swift от Apple, где на уровне языка введены дополнительные арифметические операторы (вида "&+"), явно указывающие на отсутствие контроля переполнения (обычные операторы по умолчанию имеют контроль): https://docs.swift.org/swift-book/LanguageGuide/AdvancedOperators.html |
Автор: | prospero78 [ Четверг, 08 Ноябрь, 2018 21:41 ] |
Заголовок сообщения: | Re: Критика С++ |
Да ладно? Похоже, в Эппл продуманы сидят?)) Правда, опять же есть риск -- все будут лепить небезопасное сложение вдоль и поперёк. |
Автор: | budden [ Четверг, 22 Ноябрь, 2018 23:40 ] |
Заголовок сообщения: | Re: Критика С++ |
C++ местами очень неплох. К сожалению, к ним добавлены и другие места, которые перечёркивают плюсы. Препроцессор нужен. В С++ он ещё недостаточно мощный. Был бы он нормальный - шаблоны стали бы его частным случаем. Проблема в другом. Если есть 10 #define-ов, которые только лишь проверяются #ifdef-ами (т.е. они по сути являются булевыми константами, параметризующими исходный код), то данная программа - это 1024 разные программы. #ifdef ДРУГАЯ_ОПЕРАЦИОННАЯ_СИСТЕМА для анализа такой программы требует наличия заголовочных файлов от другой операционной системы, а таковых файлов нет. То же происходит и в случае, когда используются макросы, определённые в заголовочных файлах отсутствующей системы. Кроме того, нет формального описания того, какие #define или их комбинации вообще имеют смысл. Далее, makefile недостаточно декларативен, а бывает ещё ./configure. По сумме всех этих факторов получается, что невозможно проанализировать программу на С статически. Как только эта проблема в таком формате осознана, можно пытаться её решить и у меня есть намётки, но я ими с вами делиться пока что не буду (а может быть, и никогда не буду). Но решение содержится в самой постановке, вы умные, сами догадаетесь. Что может этому противопоставить Оберон? По сути, он может либо собирать всё, что относится к допустимой комбинации дефайнов в какой-то модуль Конфигурация_этой_ос (и их получится 1024 штуки), а включение этого модуля производится уже в сборочный скрипт. Такой подход порождает массу дополнительных ограничений на модульную структуру программы. Можете сделать по ряду модулей для каждого #define - их понадобится 10 штук, но тогда сложность переносится на сборочный скрипт. Либо выносить соответствующие настройки в динамику со снижением надёжности. Т.е. делать #define MAX(X,Y) функцией и т.п. Да и вообще, у вас море методических ошибок. Где-то была статья про разные подходы к разработке программ. Правильный подход - это что нужно делать максимально просто, но если простота конфликтует с правильностью, то нужно делать правильно. В Оберонах же простота возведена в абсолют, а правильностью повсеместно пренебрегают. Любая программа - вещь, составленная из многих частей. Несовершенства каждого отдельного решения складываются, а то и перемножаются. В итоге получается слабый результат. Плюс к тому, некоторые деятели маскируют консерватизм (ничего менять не надо, потому что у нас есть приложение, которое уже хорошо работает) под воззрения о том, что надо и что не надо развивать (ничего менять не надо, потому что уже и так хорошая среда). Это уже просто ложь. И я должен сказать, что КП оптимизирован не под простоту. У него две цели оптимизации - это простота и компактность. Например, для чтения файла строковых ресурсов используется VAL, хотя без него прекрасно можно было бы обойтись. Давайте говорить правду и не скрывать этот факт. Далее, инструмент не должен быть простым. Инструмент должен автоматизировать труд человека. В исходниках КП я уже несколько раз видел код сортировки, вставленный прямо в тело какой-то функции. Т.е. выразительность языка настолько плохая, что даже сортировку не смогли абстрагировать и сделать универсальной подпрограммой. Ещё и пытаетесь под это подвести какие-то обоснования. Например, что это повышает эффективность. Но вы извините, простота и эффективность - это противоречащие друг другу критерии оптимизации. Равно как эффективность и надёжность противоречат друг другу. С точки зрения простоты и особенно надёжности инлайнить руками функцию сорт - это неправильно. И сама по себе постановка задачи "критика С++" - это неправильная постановка задачи. Она закрывает вам путь к совершенствованию. Назвали бы "сильные и слабые места С++". "В чём брать пример с С++, а от чего бежать" - и была бы правильная. |
Автор: | Илья Ермаков [ Пятница, 23 Ноябрь, 2018 00:29 ] |
Заголовок сообщения: | Re: Критика С++ |
А Вы попробуйте написать "сортировку вообще". Саму-то Вы её напишете. А вот горло-интерфейс, выражающее понятие "сортировабельная последовательность" - упаритесь выражать. И взгромоздите башню средств для этого. Как с шаблонами С++. Хотя некоторые средства над языком, типа типизированных макросов (была такая статья "Умные макросы" для Оберона) могли бы иметь место. В той степени, в какой они просты и не нарушают Парето (чтобы из-за погони за 20% остаточных случаев не возводить 80% сложности). |
Автор: | Валерий Лаптев [ Пятница, 23 Ноябрь, 2018 06:52 ] |
Заголовок сообщения: | Re: Критика С++ |
Насчет универсальной сортировки. В общем-то проблемы всего две: 1. тип сортируемых элементов 2. операция сравнения элементов данного типа. Вариант а) через универсальные указатели - как это было в С. Пишем операцию сравнения для конкретного типа - с указателями! Вариант б) иметь в языке некий универсальный базовый тип, определить сортировку в терминах базового типа Пишем опять операцию сравнения для конкретного наследника - и принцип подстановки работает на нас. Вариант в) шаблоны. В простом варианте - замена параметра на конкретный тип и проверка синтаксиса получившейся конструкции - это просто песня! Последний вариант я думаю допилить в нашем Semantic Language и посмотреть, что получится. |
Автор: | Trurl [ Пятница, 23 Ноябрь, 2018 08:13 ] |
Заголовок сообщения: | Re: Критика С++ |
Валерий Лаптев писал(а): В общем-то проблемы всего две Я вижу ещё одну, как минимум. Для разных типов элементов эффективными будут разные алгоритмы. |
Автор: | Валерий Лаптев [ Пятница, 23 Ноябрь, 2018 08:25 ] |
Заголовок сообщения: | Re: Критика С++ |
budden писал(а): C++ местами очень неплох. К сожалению, к ним добавлены и другие места, которые перечёркивают плюсы. Препроцессор нужен. В С++ он ещё недостаточно мощный. Был бы он нормальный - шаблоны стали бы его частным случаем. Проблема в другом. Если есть 10 #define-ов, которые только лишь проверяются #ifdef-ами (т.е. они по сути являются булевыми константами, параметризующими исходный код), то данная программа - это 1024 разные программы. #ifdef ДРУГАЯ_ОПЕРАЦИОННАЯ_СИСТЕМА для анализа такой программы требует наличия заголовочных файлов от другой операционной системы, а таковых файлов нет. То же происходит и в случае, когда используются макросы, определённые в заголовочных файлах отсутствующей системы. Кроме того, нет формального описания того, какие #define или их комбинации вообще имеют смысл. Препроцессор к языку никакого отношения не имеет. Препроцессор понадобился практически только для того, чтобы сделать модульность - посредством объединения исходных текстов. Дефайны - это иепархия препроцессора, а не Си. Вместо стандартного препроцессора можно поставить любой другой - и ничего практически не изменится. Использование препроцессора - это в 69-70 году была неплохое практическое решение. Ибо модули более-менее в приличном виде появились только в 70-х годах. Причем - в Европе. Американцы, озабоченные на всю голову идеей обратной совместимости (все ради экономии бабла!) даже не думали модифицировать С. budden писал(а): Далее, makefile недостаточно декларативен, а бывает ещё ./configure. По сумме всех этих факторов получается, что невозможно проанализировать программу на С статически. Как только эта проблема в таком формате осознана, можно пытаться её решить и у меня есть намётки, но я ими с вами делиться пока что не буду (а может быть, и никогда не буду). Но решение содержится в самой постановке, вы умные, сами догадаетесь. А maker - вообще к языку отношения не имеет. Опять же - неплохое практическое решение для начала 70-х. Про сортировку я уже написал... budden писал(а): И сама по себе постановка задачи "критика С++" - это неправильная постановка задачи. Она закрывает вам путь к совершенствованию. Назвали бы "сильные и слабые места С++". "В чём брать пример с С++, а от чего бежать" - и была бы правильная. Ну, тут каждый - в меру своей "испорченности"... |
Автор: | budden [ Пятница, 23 Ноябрь, 2018 09:34 ] |
Заголовок сообщения: | Re: Критика С++ |
> Препроцессор к языку никакого отношения не имеет. Может быть, я плохой, но я никогда не понимаю, когда говорят "это не язык, а библиотека", "это не язык, а инструменты". Работать приходится с комплексом из языка, библиотеки и инструментов. Свойства языка задают ограничения на создаваемые библиотеки и инструменты и тем самым язык влияет на инструменты. С другой стороны, без библиотек и инструментов язык безполезен. Если мы говорим о преимуществах и недостатках, то и сравнивать надо комплексы, а не отдельные части комплекса. Мыслить фразами типа "можно создать такой-то инструмент" или "нельзя создать такой-то инструмент". Также мне непонятно, когда говорят "это не язык, а реализация". Допустим, язык хороший, а реализация плохая. Но давайте сначала обсудим вопрос, возможна ли хорошая реализация вообще? Сколько она стоит? Могу ли я как ремесленник с конкретными заказами и ограниченными доходами себе позволить хорошую реализацию? Но даже и так, я не соглашусь, что препроцессор отделен от языка. У них согласованные лексеры. Внутри строки и комментария MAX не будет расширен, а # в Си свободна от иных смыслов. И вы без препроцессора Си просто не соберёте ни одну программу на Си, т.к. #include. Т.е. можно теоретически обсуждать Си без препроцессора, но это будет сферический конь в вакууме. > Препроцессор понадобился практически только для того Понадобился-то он изначально может быть и для того (я не в курсе), а использоваться он стал и для многих других вещей, например, для того, чтобы переименовывать идентификаторы и для создания псевдо-функций, таких, как MAX. Для создания шаблонного кода (кажется, в MFC полно макросов такого рода). И кстати, SORT теоретически тоже сюда бы полез, если бы в КП можно было создавать переменные в теле оператора, как это можно в С++ (про Си не помню). Получился бы тот же самый код, без зависимостей между модулями (зависимость времени компиляции, а не времени связывания), но без необходимости дублирования. Препроцессором можно сделать даже эрзац-ООП в Си, хотя он будет более многословным, чем встроенный в С++. Вот я, например, хочу хороший препроцессор для КП, потому что иначе рано или поздно придётся его писать. Можете просветить, каков мой выбор из уже написанного? Чтобы я мог с его помощью избежать дублирования сортировки? > Вариант а) через универсальные указатели - как это было в С. Пишем операцию сравнения для конкретного типа - с указателями! Ага, только ANYPTR не универсален. Я бы использовал Meta.Item. Но давайте учтём, что это деоптимизация и новая зависимость между модулями. И тут внезапно оказывается, что кого-то может возмутить, если в загрузке строковых ресурсов такая деоптимизация вводится, и вдруг может возникнуть циклическая зависимость и ББ может перестать собираться. И кроме того, снижается типобезопаность, и проверка переходит в рантайм. Подход с шаблонами лишён этого недостатка, но шаблоны хорошо пересекаются с препроцессором и эта задача может делаться препроцессором (например, сишный препроцессор её вряд ли потянет, а вот m4 вполне должен её осилить). Что есть ваш Semantic Language? |
Автор: | budden [ Пятница, 23 Ноябрь, 2018 09:57 ] |
Заголовок сообщения: | Re: Критика С++ |
Илья Ермаков писал(а): А Вы попробуйте написать "сортировку вообще". Саму-то Вы её напишете. А вот горло-интерфейс, выражающее понятие "сортировабельная последовательность" - упаритесь выражать. Я бы сказал на словах: сортировабельная последовательность - это та, в которой элемент можно переместить без его разрушения (например, она хранит числа или указатели) и у которой есть доступ по индексу. Я бы передал в макрос или функцию сортировки следующее: тип указателя на элемент, операцию взятия элемента по индексу, операцию записи элемента по индексу, размер последовательности и операцию сравнения. В функций или в виде кусочков текста, в зависимости от того, функция у нас сортировка или шаблон/макрос. При этом да, может быть проблема сделать такие функции. Для этого придумали замыкания. Хотя и с ними свои ограничения (возникают проблемы с выделением на стеке, может падать эффективность). Т.е. решение в виде макроса здесь будет самым простым, хотя и приведёт к дублированию машинного кода. В случае КП придётся генерировать и внедрять переменную в раздел переменных текущей области, это потребует подобия GENSYM, и это коряво, но в целом решение жизнеспособное. Т.е. да, башню построить придётся. Здесь я соглашусь с тем, что в С++ плохо. У них три разных механизма с пересекающимися областями действия - ООП, шаблоны и препроцессор. Выкинуть из них нельзя ни один. Но извините, в других языках (включая даже лисп) и этого нет. Единственное, я не знаю за Scala и Rust. Самое простое в рамках существующего - это ограничиться массивами, передавать только ANYPTR и соответственно использовать записи для хранения сущностей, если их когда-то придётся сортировать. Тогда единственная остающаяся проблема - это порядок загрузки модулей, хотя не факт, что она разрешима. Тогда придётся дублировать функцию сортировки, как это и сделано. Но сдаётся мне, что сделано оно в большем числе мест, чем это действительно нужно. Цитата: Хотя некоторые средства над языком, типа типизированных макросов (была такая статья "Умные макросы" для Оберона) Можно поподробнее? Статья есть, а реализация есть? Правда, нужна поддержка среды для макросов и я пока такой поддержки не видел ни в одной IDE. Лучшая - опять же, как ни странно, в С с его #file #line. Но некоторые вещи будут потеряны, например, макрос не создаёт кадра стека и когда их пять вложенных друг в друга вперемежку с функциями, то это ад. Я такой ад проходил. Впрочем, в лиспе это отчасти решается, но то лисп. |
Автор: | Info21 [ Пятница, 23 Ноябрь, 2018 11:26 ] |
Заголовок сообщения: | Re: Критика С++ |
prospero78 писал(а): Сняли страничку-то )))
|
Автор: | Info21 [ Пятница, 23 Ноябрь, 2018 11:32 ] |
Заголовок сообщения: | Re: Критика С++ |
Мозг сапиенсов за тыщу лет измениться не мог. С++ -- это то самое агрессивное мракобесие, какое было всегда. Просто произошло некоторое смягчение нравов на почве пищевого изобилия, и редакторов вынуждают снять еретическую страницу вместо выдачи аутодафе её автору. |
Автор: | Валерий Лаптев [ Пятница, 23 Ноябрь, 2018 12:44 ] |
Заголовок сообщения: | Re: Критика С++ |
На хабре как-то был крик души о безобразиях С++... Но мне там найти проблематично - я не зарегистрирован там. |
Автор: | Валерий Лаптев [ Пятница, 23 Ноябрь, 2018 12:54 ] |
Заголовок сообщения: | Re: Критика С++ |
Info21 писал(а): Мозг сапиенсов за тыщу лет измениться не мог. С++ -- это то самое агрессивное мракобесие, какое было всегда. Просто произошло некоторое смягчение нравов на почве пищевого изобилия, и редакторов вынуждают снять еретическую страницу вместо выдачи аутодафе её автору. Помнится, Галилея тоже церковники судили... А Джордано Бруно вообще сожгли... Вы, судя по вашим высказываниям о С++, готовы сжечь Страуструпа... Еретик, несет абсолютную ересь! Улыбнуло... |
Автор: | Info21 [ Пятница, 23 Ноябрь, 2018 19:19 ] |
Заголовок сообщения: | Re: Критика С++ |
Валерий Лаптев писал(а): Вы, судя по вашим высказываниям о С++, готовы сжечь Страуструпа... Это как же Вы вычитали.
|
Автор: | Валерий Лаптев [ Суббота, 24 Ноябрь, 2018 07:13 ] |
Заголовок сообщения: | Re: Критика С++ |
Цитата: С++ -- это то самое агрессивное мракобесие Складывается ВПЕЧАТЛЕНИЕ. Но я с вами согласен, что С++ - опасный язык. Вообще вся ветка С - это "развлечение программистов в своей песочнице". Они делали когда-то это (С, unix) для себя, а народ решил, что простой программист на "этом" сможет решать какие-то задачи. Они там продолжают "играться", часто показывая, как не надо делать. Отсюда родился Rust, Go... Проблема не в С++, а в капитализме - прибыль можно получить на любом дерьме... |
Автор: | Info21 [ Суббота, 24 Ноябрь, 2018 18:29 ] |
Заголовок сообщения: | Re: Критика С++ |
Валерий Лаптев писал(а): Проблема не в С++, а в капитализме Давайте не будем заниматься словоблудием.
|
Автор: | Валерий Лаптев [ Воскресенье, 25 Ноябрь, 2018 08:17 ] |
Заголовок сообщения: | Re: Критика С++ |
Info21 писал(а): Валерий Лаптев писал(а): Проблема не в С++, а в капитализме Давайте не будем заниматься словоблудием.Это не словоблудие, а асимметричность информации на рынке! |
Автор: | Alexey_Donskoy [ Воскресенье, 25 Ноябрь, 2018 10:23 ] |
Заголовок сообщения: | Re: Критика С++ |
Info21 писал(а): Валерий Лаптев писал(а): Проблема не в С++, а в капитализме Давайте не будем заниматься словоблудием.Вся полезная деятельность, которую Вы ведёте, есть борьба со следствиями, и именно потому задача не просто трудна, а принципиально неразрешима в данных социально-экономических условиях... |
Автор: | Info21 [ Понедельник, 26 Ноябрь, 2018 00:12 ] |
Заголовок сообщения: | Re: Критика С++ |
"Глубоко копнуто!" (с) info21 |
Автор: | Пётр Кушнир [ Понедельник, 26 Ноябрь, 2018 00:42 ] |
Заголовок сообщения: | Re: Критика С++ |
Alexey_Donskoy писал(а): в данных социально-экономических условиях... философские воззрения учёных (постпозитивизм) отрицают возможность рассмотрения мiра "в целом".
|
Страница 4 из 8 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |