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

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

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

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

ЕМ>>>>ALGOL-68 и Modula.

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

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

S>Вы сказали конкретно вот это:
S>[q]Цель была прежде всего в том, чтобы раздвинуть возможности C в сторону ЯВУ, не теряя при этом его низкоуровневых качеств.[/q]
S>Т.е. если возможности Си нужно было раздвигать в сторону ЯВУ, значит ЯВУ он не являлся. Если следовать написанному вами.

ЕМ>>Принципиальная разница в том, что

S>Простите очередное бла-бла-бла поскипал, т.к. там нет никакой конкретики.

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

S>Э... А что этому препятствует в Pascal, Modula-2 и Ada?
S>Либо вы в очередной раз не смогли внятно сформулировать какую-то мысль, либо я не понимаю, чем Си или C++ в этом вопросе лучше условного Modula-2.

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

ЕМ>>Я не понимаю, отчего Вы так уцепились за GC,

S>Оно заметно.

EM>>который тут вообще не при делах.

S>Очень даже.
S>Вот в C++ мы можем иметь дело с шаблоном:
S>[ccode]
S>template<class T>
S>class value_holder {
S>  T _value;
S>public:
S>  ...
S>};
S>[/ccode]
S>и в C++ мы вынуждены считаться с тем, является ли T ссылкой или указателем, насколько сохраняется семантика value_holder для этого случая, нужно ли нам что-то предпринимать с классом value_holder, если T -- это ссылка.

S>Тогда как в языках с GC этих вопросов нет.

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

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

S>Я бы еще понял претензии по поводу эффективности и экономичности (хотя я уже как-то давал в профильных форумах [url=https://eao197.blogspot.com/2024/09/progc.html]ссылку[/url] на использование возможностей современного C++ как раз для экономичности). Но прозрачность и ортогональность-то здесь каким боком?

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

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

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

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

S>Полагаю, это опять вопрос к Страуструпу. Но, думаю, своей работой он уже на него ответил.

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

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

S>А где макросы не примитивные и не тупые? Рискну предположить, что в Lisp-е или каком-нибудь Nemerle.

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

S>Это возможно в динамически типизируемом языке, типа Lisp-а.
S>В статически типизируемом вы для этого должны оперировать понятиями языка (вроде анотаций в Java или шаблонов C++), либо работать на уровне лексем. Но на уровне лексем возникают проблемы с тем, чтобы понять что конкретная лексема будет означать.

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

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

S>Каких таких эффектов, выражайтесь яснее, плз.

ЕМ>>Как у Вас реально поворачивается язык называть все эти костыли иначе, чем уродством? :)

S>Я вообще не даю оценок, а прошу показать где обобщенное программирование реализовано лучше и гибче.

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

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

S>Где такое чудо можно увидеть?

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

S>В современном C++ практически все это под вашим контролем. За исключением унаследованного из Си неявного преобразования целочисленных типов.

Теги:

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

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