Новое сообщение в форум Компьютерные священные войны

Форум	Компьютерные священные войны
Тема	Как правильно задавать вопросы

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, so5team, Вы писали:

ЕМ>>>ALGOL-68 и Modula.

S>>И чем же они ЯВУ, а Си -- нет?

ЕМ>Я не говорил, что C - "не ЯВУ". Я имел в виду, что он Я менее высокого У, чем любой из языков, которые принято относить к ЯВУ.

ЕМ>Принципиальная разница в том, что [почти] все возможности подавляющего большинства ЯВУ содержатся в их ядрах. То есть, исключение хотя бы одной из возможностей языка (которых в ЯВУ обычно достаточно много) из реализации на очередной платформе делает невозможной успешную компиляцию программы, которая эту возможность использует. Поэтому почти любой ЯВУ нужно делать под новую платформу либо целиком, либо не делать вообще, ибо допиливать [i]по отдельности каждый проект[/i], завязанный на отдельные возможности, вряд ли целесообразно.

ЕМ>Подход, принятый в C (и частично сохраненный в C++), позволяет малой кровью реализовать простое ядро языка на любой новой платформе, после чего туда [i]автоматически[/i] переносится вся стандартная библиотека, написанная на нем самом.

S>>Включение же в список кучи языков с GC для сравнения их с чистым Си -- это от большого ума?

ЕМ>Я не понимаю, отчего Вы так уцепились за GC, который тут вообще не при делах. "Кто такой Студебеккер? Это ваш родственник Студебеккер? Папа ваш Студебеккер? Чего вы прилипли к человеку?". :)

S>>Как и попытка сопоставить Си и Prolog (популярность которого, даже в конце 1980-х и начале 1990-х сильно преувеличена).

ЕМ>Я ж не сопоставляю [i]напрямую[/i]. Я лишь показываю, что задачи, которые традиционно решались с помощью ЯВУ, еще с 60-х были вполне покрыты имевшимися тогда языками, и вряд ли кому-то приходило в голову использовать C вместо любого из этих языков для мало-мальски серьезного проекта. Основной причиной появления C было стремление избавиться от написания низкоуровневого кода на ассемблере, а отнюдь не заменить какой-нибудь PL/1 или Fortran-IV. И у C++ поначалу тоже не было шансов полноценно заменить популярные в то время ЯВУ, для этого потребовалось лет десять устаканивания и развития.

ЕМ>>>Вам, насколько я знаю из того, что Вы пишете про C++, неинтересны низкоуровневые и архитектурно-зависимые возможности C++, унаследованные от C.

S>>Значит вы ничего не знаете.

ЕМ>Я сужу по тому, что Вы пишете о C++. Вы всегда выступали прежде всего за совместимость, универсальность, обобщенность, богатство функционала и т.п., а чтоб за эффективность, экономичность, прозрачность, ортогональность функционала - почти не помню.

S>>[q]Однако реализация самого языка Simula не масштабировалась в той же степени, что и моя программа.[/q]

ЕМ>Вас не насторожило ни слово "реализация", ни это?

S>>[q]вероятнее всего, это была проблема используемого компоновщика, а не самого языка Simula[/q]

ЕМ>А если все дело было прежде всего в том, что

S>>[q]Проблема накладных расходов является в Simula фундаментальной и неустранимой. Она коренится в некоторых особенностях языка и их взаимодействиях: проверке типов во время исполнения, гарантированной инициализации переменных, поддержке параллельности, сборке мусора для объектов, созданных пользователем, и записей активации процедур.[/q]

ЕМ>то не проще ли было допилить и сам язык, и его реализацию, чтобы устранить самые критичные проблемы?

S>>Макросы же обрабатываются до начала работы компилятора

ЕМ>Так обрабатываются только самые примитивные, тупые макросы. Их реализация в C - отличный пример мертворожденной концепции.

ЕМ>Полноценный макрос - это как функция, только выполняется на этапе компиляции в тот момент, когда до него доходит очередь (по тексту или по более сложным правилам), а результатом является порожденный код, который затем компилируется опять-таки в заданном порядке.

S>>именно то, что вы описываете, как раз C++ными шаблонами и делается: разбор параметров, сопоставление и т.д.

ЕМ>И сколько лет прошло от появления в C++ шаблонов, которые [i]внезапно[/i] оказались Тьюринг-полными, до появления первых робких средств делать этот разбор иначе, как посредством побочных эффектов? :) Как у Вас реально поворачивается язык называть все эти костыли иначе, чем уродством? :)

S>>как в этом вашем идеальном макрогенераторе решать ту проблему, для которой в C++ добавили специализацию шаблонов (хоть полную, хоть частичную)?

ЕМ>Элементарно. "Макрос" при обработке своего "вызова" анализирует список параметров (напомню, в этой концепции ему доступны все известные на данный момент компилятору типы и значения)  и либо порождает соответствующий код, либо выдает сообщение об ошибке. Для вящего удобства и красоты можно добавить третий вариант - "макрос" завершается с результатом "это определение не подходит" (что будет аналогично SFINAE), и компилятор ищет другой макрос с тем же именем и подходящим набором параметров. Чисто технически это не обязательно, можно обойтись первыми двумя путями, а нужные варианты кода порождать вызовом других "макросов", как это принято делать с функциями.

ЕМ>Этот же механизм можно было бы применить и в перегрузках функций, и вместо обширного перечня неявных преобразований с их приоритетами, указывать только допустимые типы и возможные преобразования в явном виде.

S>>А это уже завозят в рамках C++26. Не без помощи шаблонов.

ЕМ>>>при необходимости сопровождая свою работу сообщениями в общий поток вывода компилятора.
S>>Этого пока нет.

ЕМ>Ничего, еще каких-нибудь десять-пятнадцать лет... :) Только вот механизм будет, как принято, вырвиглазный, ибо человеческого при устоявшемся подходе туда не прикрутить.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail