OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 29 Март, 2024 00:56

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 145 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8  След.
Автор Сообщение
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Четверг, 08 Ноябрь, 2018 20:33 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Ещё не помешает и по сторонам взглянуть. Насчёт того же переполнения, более-менее адекватный подход реализовали в Swift от Apple, где на уровне языка введены дополнительные арифметические операторы (вида "&+"), явно указывающие на отсутствие контроля переполнения (обычные операторы по умолчанию имеют контроль):
https://docs.swift.org/swift-book/LanguageGuide/AdvancedOperators.html


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Четверг, 08 Ноябрь, 2018 21:41 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Да ладно?
Похоже, в Эппл продуманы сидят?))
Правда, опять же есть риск -- все будут лепить небезопасное сложение вдоль и поперёк.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Четверг, 22 Ноябрь, 2018 23:40 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
C++ местами очень неплох. К сожалению, к ним добавлены и другие места, которые перечёркивают плюсы.

Препроцессор нужен. В С++ он ещё недостаточно мощный. Был бы он нормальный - шаблоны стали бы его частным случаем. Проблема в другом. Если есть 10 #define-ов, которые только лишь проверяются #ifdef-ами (т.е. они по сути являются булевыми константами, параметризующими исходный код), то данная программа - это 1024 разные программы. #ifdef ДРУГАЯ_ОПЕРАЦИОННАЯ_СИСТЕМА для анализа такой программы требует наличия заголовочных файлов от другой операционной системы, а таковых файлов нет. То же происходит и в случае, когда используются макросы, определённые в заголовочных файлах отсутствующей системы.

Кроме того, нет формального описания того, какие #define или их комбинации вообще имеют смысл.

Далее, makefile недостаточно декларативен, а бывает ещё ./configure. По сумме всех этих факторов получается, что невозможно проанализировать программу на С статически. Как только эта проблема в таком формате осознана, можно пытаться её решить и у меня есть намётки, но я ими с вами делиться пока что не буду (а может быть, и никогда не буду). Но решение содержится в самой постановке, вы умные, сами догадаетесь.

Что может этому противопоставить Оберон? По сути, он может либо собирать всё, что относится к допустимой комбинации дефайнов в какой-то модуль Конфигурация_этой_ос (и их получится 1024 штуки), а включение этого модуля производится уже в сборочный скрипт. Такой подход порождает массу дополнительных ограничений на модульную структуру программы. Можете сделать по ряду модулей для каждого #define - их понадобится 10 штук, но тогда сложность переносится на сборочный скрипт. Либо выносить соответствующие настройки в динамику со снижением надёжности. Т.е. делать #define MAX(X,Y) функцией и т.п.

Да и вообще, у вас море методических ошибок. Где-то была статья про разные подходы к разработке программ. Правильный подход - это что нужно делать максимально просто, но если простота конфликтует с правильностью, то нужно делать правильно. В Оберонах же простота возведена в абсолют, а правильностью повсеместно пренебрегают. Любая программа - вещь, составленная из многих частей. Несовершенства каждого отдельного решения складываются, а то и перемножаются. В итоге получается слабый результат. Плюс к тому, некоторые деятели маскируют консерватизм (ничего менять не надо, потому что у нас есть приложение, которое уже хорошо работает) под воззрения о том, что надо и что не надо развивать (ничего менять не надо, потому что уже и так хорошая среда). Это уже просто ложь.

И я должен сказать, что КП оптимизирован не под простоту. У него две цели оптимизации - это простота и компактность. Например, для чтения файла строковых ресурсов используется VAL, хотя без него прекрасно можно было бы обойтись.

Давайте говорить правду и не скрывать этот факт.

Далее, инструмент не должен быть простым. Инструмент должен автоматизировать труд человека. В исходниках КП я уже несколько раз видел код сортировки, вставленный прямо в тело какой-то функции. Т.е. выразительность языка настолько плохая, что даже сортировку не смогли абстрагировать и сделать универсальной подпрограммой. Ещё и пытаетесь под это подвести какие-то обоснования. Например, что это повышает эффективность. Но вы извините, простота и эффективность - это противоречащие друг другу критерии оптимизации. Равно как эффективность и надёжность противоречат друг другу. С точки зрения простоты и особенно надёжности инлайнить руками функцию сорт - это неправильно.

И сама по себе постановка задачи "критика С++" - это неправильная постановка задачи. Она закрывает вам путь к совершенствованию. Назвали бы "сильные и слабые места С++". "В чём брать пример с С++, а от чего бежать" - и была бы правильная.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 00:29 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А Вы попробуйте написать "сортировку вообще". Саму-то Вы её напишете. А вот горло-интерфейс, выражающее понятие "сортировабельная последовательность" - упаритесь выражать. И взгромоздите башню средств для этого. Как с шаблонами С++.

Хотя некоторые средства над языком, типа типизированных макросов (была такая статья "Умные макросы" для Оберона) могли бы иметь место. В той степени, в какой они просты и не нарушают Парето (чтобы из-за погони за 20% остаточных случаев не возводить 80% сложности).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 06:52 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Насчет универсальной сортировки.
В общем-то проблемы всего две:
1. тип сортируемых элементов
2. операция сравнения элементов данного типа.

Вариант а) через универсальные указатели - как это было в С.
Пишем операцию сравнения для конкретного типа - с указателями!

Вариант б) иметь в языке некий универсальный базовый тип, определить сортировку в терминах базового типа
Пишем опять операцию сравнения для конкретного наследника - и принцип подстановки работает на нас.

Вариант в) шаблоны.
В простом варианте - замена параметра на конкретный тип и проверка синтаксиса получившейся конструкции - это просто песня!

Последний вариант я думаю допилить в нашем Semantic Language и посмотреть, что получится.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 08:13 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Валерий Лаптев писал(а):
В общем-то проблемы всего две

Я вижу ещё одну, как минимум. Для разных типов элементов эффективными будут разные алгоритмы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 08:25 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
budden писал(а):
C++ местами очень неплох. К сожалению, к ним добавлены и другие места, которые перечёркивают плюсы.

Препроцессор нужен. В С++ он ещё недостаточно мощный. Был бы он нормальный - шаблоны стали бы его частным случаем. Проблема в другом. Если есть 10 #define-ов, которые только лишь проверяются #ifdef-ами (т.е. они по сути являются булевыми константами, параметризующими исходный код), то данная программа - это 1024 разные программы. #ifdef ДРУГАЯ_ОПЕРАЦИОННАЯ_СИСТЕМА для анализа такой программы требует наличия заголовочных файлов от другой операционной системы, а таковых файлов нет. То же происходит и в случае, когда используются макросы, определённые в заголовочных файлах отсутствующей системы.

Кроме того, нет формального описания того, какие #define или их комбинации вообще имеют смысл.

Препроцессор к языку никакого отношения не имеет.
Препроцессор понадобился практически только для того, чтобы сделать модульность - посредством объединения исходных текстов.
Дефайны - это иепархия препроцессора, а не Си.
Вместо стандартного препроцессора можно поставить любой другой - и ничего практически не изменится.
Использование препроцессора - это в 69-70 году была неплохое практическое решение.
Ибо модули более-менее в приличном виде появились только в 70-х годах.
Причем - в Европе.
Американцы, озабоченные на всю голову идеей обратной совместимости (все ради экономии бабла!) даже не думали модифицировать С.
budden писал(а):
Далее, makefile недостаточно декларативен, а бывает ещё ./configure. По сумме всех этих факторов получается, что невозможно проанализировать программу на С статически. Как только эта проблема в таком формате осознана, можно пытаться её решить и у меня есть намётки, но я ими с вами делиться пока что не буду (а может быть, и никогда не буду). Но решение содержится в самой постановке, вы умные, сами догадаетесь.

А maker - вообще к языку отношения не имеет.
Опять же - неплохое практическое решение для начала 70-х.
Про сортировку я уже написал... :)

budden писал(а):
И сама по себе постановка задачи "критика С++" - это неправильная постановка задачи. Она закрывает вам путь к совершенствованию. Назвали бы "сильные и слабые места С++". "В чём брать пример с С++, а от чего бежать" - и была бы правильная.

Ну, тут каждый - в меру своей "испорченности"... :mrgreen:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 09:34 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
> Препроцессор к языку никакого отношения не имеет.
Может быть, я плохой, но я никогда не понимаю, когда говорят "это не язык, а библиотека", "это не язык, а инструменты". Работать приходится с комплексом из языка, библиотеки и инструментов. Свойства языка задают ограничения на создаваемые библиотеки и инструменты и тем самым язык влияет на инструменты. С другой стороны, без библиотек и инструментов язык безполезен. Если мы говорим о преимуществах и недостатках, то и сравнивать надо комплексы, а не отдельные части комплекса. Мыслить фразами типа "можно создать такой-то инструмент" или "нельзя создать такой-то инструмент". Также мне непонятно, когда говорят "это не язык, а реализация". Допустим, язык хороший, а реализация плохая. Но давайте сначала обсудим вопрос, возможна ли хорошая реализация вообще? Сколько она стоит? Могу ли я как ремесленник с конкретными заказами и ограниченными доходами себе позволить хорошую реализацию?

Но даже и так, я не соглашусь, что препроцессор отделен от языка. У них согласованные лексеры. Внутри строки и комментария MAX не будет расширен, а # в Си свободна от иных смыслов. И вы без препроцессора Си просто не соберёте ни одну программу на Си, т.к. #include. Т.е. можно теоретически обсуждать Си без препроцессора, но это будет сферический конь в вакууме.

> Препроцессор понадобился практически только для того
Понадобился-то он изначально может быть и для того (я не в курсе), а использоваться он стал и для многих других вещей, например, для того, чтобы переименовывать идентификаторы и для создания псевдо-функций, таких, как MAX. Для создания шаблонного кода (кажется, в MFC полно макросов такого рода). И кстати, SORT теоретически тоже сюда бы полез, если бы в КП можно было создавать переменные в теле оператора, как это можно в С++ (про Си не помню). Получился бы тот же самый код, без зависимостей между модулями (зависимость времени компиляции, а не времени связывания), но без необходимости дублирования. Препроцессором можно сделать даже эрзац-ООП в Си, хотя он будет более многословным, чем встроенный в С++.

Вот я, например, хочу хороший препроцессор для КП, потому что иначе рано или поздно придётся его писать. Можете просветить, каков мой выбор из уже написанного? Чтобы я мог с его помощью избежать дублирования сортировки?

> Вариант а) через универсальные указатели - как это было в С.
Пишем операцию сравнения для конкретного типа - с указателями!

Ага, только ANYPTR не универсален. Я бы использовал Meta.Item. Но давайте учтём, что это деоптимизация и новая зависимость между модулями. И тут внезапно оказывается, что кого-то может возмутить, если в загрузке строковых ресурсов такая деоптимизация вводится, и вдруг может возникнуть циклическая зависимость и ББ может перестать собираться. И кроме того, снижается типобезопаность, и проверка переходит в рантайм. Подход с шаблонами лишён этого недостатка, но шаблоны хорошо пересекаются с препроцессором и эта задача может делаться препроцессором (например, сишный препроцессор её вряд ли потянет, а вот m4 вполне должен её осилить).

Что есть ваш Semantic Language?


Последний раз редактировалось budden Пятница, 23 Ноябрь, 2018 10:04, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 09:57 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1557
Илья Ермаков писал(а):
А Вы попробуйте написать "сортировку вообще". Саму-то Вы её напишете. А вот горло-интерфейс, выражающее понятие "сортировабельная последовательность" - упаритесь выражать.

Я бы сказал на словах: сортировабельная последовательность - это та, в которой элемент можно переместить без его разрушения (например, она хранит числа или указатели) и у которой есть доступ по индексу. Я бы передал в макрос или функцию сортировки следующее: тип указателя на элемент, операцию взятия элемента по индексу, операцию записи элемента по индексу, размер последовательности и операцию сравнения. В функций или в виде кусочков текста, в зависимости от того, функция у нас сортировка или шаблон/макрос. При этом да, может быть проблема сделать такие функции. Для этого придумали замыкания. Хотя и с ними свои ограничения (возникают проблемы с выделением на стеке, может падать эффективность). Т.е. решение в виде макроса здесь будет самым простым, хотя и приведёт к дублированию машинного кода. В случае КП придётся генерировать и внедрять переменную в раздел переменных текущей области, это потребует подобия GENSYM, и это коряво, но в целом решение жизнеспособное. Т.е. да, башню построить придётся. Здесь я соглашусь с тем, что в С++ плохо. У них три разных механизма с пересекающимися областями действия - ООП, шаблоны и препроцессор. Выкинуть из них нельзя ни один. Но извините, в других языках (включая даже лисп) и этого нет. Единственное, я не знаю за Scala и Rust.

Самое простое в рамках существующего - это ограничиться массивами, передавать только ANYPTR и соответственно использовать записи для хранения сущностей, если их когда-то придётся сортировать. Тогда единственная остающаяся проблема - это порядок загрузки модулей, хотя не факт, что она разрешима. Тогда придётся дублировать функцию сортировки, как это и сделано. Но сдаётся мне, что сделано оно в большем числе мест, чем это действительно нужно.

Цитата:
Хотя некоторые средства над языком, типа типизированных макросов (была такая статья "Умные макросы" для Оберона)

Можно поподробнее? Статья есть, а реализация есть? Правда, нужна поддержка среды для макросов и я пока такой поддержки не видел ни в одной IDE. Лучшая - опять же, как ни странно, в С с его #file #line. Но некоторые вещи будут потеряны, например, макрос не создаёт кадра стека и когда их пять вложенных друг в друга вперемежку с функциями, то это ад. Я такой ад проходил. Впрочем, в лиспе это отчасти решается, но то лисп.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 11:26 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
prospero78 писал(а):
Сняли страничку-то )))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 11:32 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Мозг сапиенсов за тыщу лет измениться не мог.

С++ -- это то самое агрессивное мракобесие, какое было всегда.

Просто произошло некоторое смягчение нравов на почве пищевого изобилия, и редакторов вынуждают снять еретическую страницу вместо выдачи аутодафе её автору.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 12:44 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
На хабре как-то был крик души о безобразиях С++... :)
Но мне там найти проблематично - я не зарегистрирован там.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 12:54 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Info21 писал(а):
Мозг сапиенсов за тыщу лет измениться не мог.
С++ -- это то самое агрессивное мракобесие, какое было всегда.
Просто произошло некоторое смягчение нравов на почве пищевого изобилия, и редакторов вынуждают снять еретическую страницу вместо выдачи аутодафе её автору.

Помнится, Галилея тоже церковники судили...
А Джордано Бруно вообще сожгли... :)
Вы, судя по вашим высказываниям о С++, готовы сжечь Страуструпа... :mrgreen:
Еретик, несет абсолютную ересь!
Улыбнуло...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Пятница, 23 Ноябрь, 2018 19:19 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
Вы, судя по вашим высказываниям о С++, готовы сжечь Страуструпа... :mrgreen:
Это как же Вы вычитали.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Суббота, 24 Ноябрь, 2018 07:13 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Цитата:
С++ -- это то самое агрессивное мракобесие

Складывается ВПЕЧАТЛЕНИЕ.
Но я с вами согласен, что С++ - опасный язык.
Вообще вся ветка С - это "развлечение программистов в своей песочнице".
Они делали когда-то это (С, unix) для себя, а народ решил, что простой программист на "этом" сможет решать какие-то задачи.
Они там продолжают "играться", часто показывая, как не надо делать.
Отсюда родился Rust, Go...
Проблема не в С++, а в капитализме - прибыль можно получить на любом дерьме... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Суббота, 24 Ноябрь, 2018 18:29 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
Проблема не в С++, а в капитализме
Давайте не будем заниматься словоблудием.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Воскресенье, 25 Ноябрь, 2018 08:17 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Info21 писал(а):
Валерий Лаптев писал(а):
Проблема не в С++, а в капитализме
Давайте не будем заниматься словоблудием.

Это не словоблудие, а асимметричность информации на рынке! :mrgreen:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Воскресенье, 25 Ноябрь, 2018 10:23 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Info21 писал(а):
Валерий Лаптев писал(а):
Проблема не в С++, а в капитализме
Давайте не будем заниматься словоблудием.
Отнюдь не словоблудие, а указание первопричины.
Вся полезная деятельность, которую Вы ведёте, есть борьба со следствиями, и именно потому задача не просто трудна, а принципиально неразрешима в данных социально-экономических условиях...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Понедельник, 26 Ноябрь, 2018 00:12 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
"Глубоко копнуто!" (с) info21


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Критика С++
СообщениеДобавлено: Понедельник, 26 Ноябрь, 2018 00:42 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Alexey_Donskoy писал(а):
в данных социально-экономических условиях...
философские воззрения учёных (постпозитивизм) отрицают возможность рассмотрения мiра "в целом".


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 145 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB