Здравствуйте, Сергей Губанов, Вы писали:

СГ>Наверное стоит изобрести совершенно новый язык принципиально основанный на шаблонах но не имеющий к С++ ни какого отношения. Вот тогда программисты наконец-то бросят С++...

А зачем тогда шаблоны то? Человек же ясно сказал "шаблонное метапрограммирование".

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

CX>Вряд ли. Сила C++ не в отдельных парадигмах, а в тесной их взаимосвязи в рамках одного языка.

Ну, ты лично только что так смешал его с дерьмом, что теперь слова про силу звучат крайне не убедительно.

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

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

Эта проблема решаема.

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

Т>Наверное, лет через 10 рекомендации будут звучать примерно так:
Т>

Не используй шаблоны — есть много им альтернатив, начиная с мегафичи X...

Да чё уж через 10 лет? Лет 30 назад был Лисп с его макросами. Так вот он и тогда всех рвал в области метапрограммирования и обобщенных алгоритмов и сейчас рвет. Думаю через 10 лет может уже не будет. Но будет еще более качественная альтернатива.

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

CX>Не буду спорить, механизм не самый удобный.

Тогда не рекламируй эту убогость больше.

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

CX>Стоп-стоп-стоп. Изначально речь шла о безопасных и небезопасных традиционных языках. Зашла речь о метапрограммировании, которое доступно в C++ и недоступно в других языках, которые приводились как его главные противники.
CX>Причем здесь лисп?

Вряд ли. Просто потому, что шаблоны к тому времени изменятся, но сохранят то лучшее, что в них есть сейчас. Да, современные C++ шаблоны можно во многом улучшить, но в них есть то, чего нет ни в каком другом языке — механизм вычислений на этапе компиляции.

Это не твои случаем слова?

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

ГВ>>>Это наследие C и, кроме того, остаётся открытым вопрос: как конкретно должен быть реализован массив? std::vector<> — то частное решение, хоть и стандартизированное.
AVC>>Пока не изобретен лучший вариант, меня вполне устраивает виртовское решение.

ГВ>Именно поэтому оно должно быть внесено в C++ на уровне языка?

Бесполезно.
Как сказал Вирт:

некоторые вещи следует продумывать до, а не после.

AVC>>>>Кроме индекса массива, в Обероне проверяются на NIL указатели и процедурные переменные. (Если они имеют значение, отличное от NIL, то их валидность гарантируется. В том числе — сборщиком мусора.)
ГВ>>>Опять таки, проверки на NULL (NIL) по месту вызова нужны не всегда. Точно так же, как и с массивами. Зачастую гораздо проще проверить валидность структур перед началом выполнения алгоритма, чем проверять их при каждом использовании.

AVC>>Существует понятие программирования по контракту. (Мейер)
AVC>>Главный принцип: не доверяй клиенту (вызывающему коду).

ГВ>Всё хорошо в своём месте и в своё время. ООП само по себе тоже не всегда адекватно задачам. Так что, принцип программирования по контракту тоже не стоит распространять на все случаи программирования.

Разве принцип программирования по контракту применим только к ООП?
Это универсальный принцип, развитие идеи защитного программирования.

AVC>>В самом первом виртовском Обероне не было присоединенных процедур (=виртуальных функций).
AVC>>Полиморфизм работал исключительно благодаря динамическому приведению типа.
AVC>>Наверное, поэтому динамическое приведение типа реализовано так эффективно.
AVC>>Например (опустив все лишнее):
ГВ>[...]

ГВ>Ну, я так понимаю, здесь влияет ещё и модель объектов паскаля, конкретно — строго одиночное наследование.

В Обероне (и других модульных языках) единица инкапсуляции не класс, а модуль.
Это существенно влияет на проектные решения.
Множественное наследование в Обероне просто не нужно (и рассматривается как вредное).
Модули позволяют естественно реализовывать целые паттерны проектирования.
Множественное наследование в Си++ — заплата на отсутствии нормальных модулей.
Вот и пишут на Си++ программы, обращаясь сразу к "человеку и пароходу". (c) Маяковский

AVC>>>>Вот, пожалуй, и все необходимые проверки в Обероне. Можете видеть сами — все они связаны с безопасностью типов и требуют не более одного-двух (для индекса массива) сравнений.
ГВ>>>Угу, но каждый раз...
AVC>>Опять-таки оптимизатор может устранить некоторые лишние проверки.
ГВ>Здесь согласен. Хотя я бы не стал полагаться на оптимизатор...

В руководстве по компилятору XDS (в разделе об оптимизации) говорится:

It is possible not to turn run-time checks off in the product versions of your programs,
because the code generator usually removes redundant checks. A typical
program runs only 10-15% faster with all run-time checks turned off (but the code
size is usually significantly smaller).

Здесь указана цена проверок: программа на 10-15% медленнее.
Разница в размере кода больше.

ГВ>>>Средствами C++ можно обойти type safety. Разумность такого решения — отдельный вопрос. Если голова на плечах есть — всмё будет в порядке, если с этим проблема, то runtime проверками дела не поправишь. Приведённый пример с NASA свидетельствует, скорее, не о бенефитах типобезопасности, а о том, что всем в NASA было настолько страшно взять ответственность на себя, что спихнули всё на "неправильную" фичу языка. Т.е., проблема не в языке, а в головах.

AVC>>Согласен, что проблема — в головах.
AVC>>Потому что именно из голов она попадает в языки.

ГВ>В огороде бузина, а в трюме акулы...

Которые съели дядьку в Киеве?
А что, я сказал глупость?
Может, я чего не знаю, и Си++ создавался не посредством головы?

AVC>>Забавно читать, что "средствами C++ можно обойти type safety".
AVC>>Где бы найти в Си++ эту самую type safety...
ГВ>Да есть она там, что тут можно сказать...

Ну разве что правду — что ее там нет.

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

AVC>ИМХО, рассуждения о принципе подстановки Барбары Лисков в данном случае выглядят наивными.
AVC>Здесь мы имеем дело с задачей двойной диспетчеризации, и это — ее самое простое (и универсальное) решение.

Стопудов, что это оно.
Насчёт того, самое ли это простое и безопасное — у меня остаются сомнения. Пару лет назад меня очень занимали мультиметоды и, в частности, случай мультиметода с двумя полиморфными аргументами... результат скорее пессимистический...

Диспетчеризация — т.е. вызов окончательной ветки — выполняет некий pattern matching.
В случае единственного полиморфного аргумента есть две стратегии:
— выбор наиболее производного класса (далее MDC, most derived class); так устроены обычные виртуальные функции — и это наиболее удовлетворяет LSP
— выбор первого из списка (далее IO, in-order) — серия проверок "obj IS type".

В случае двух и более полиморфных аргументов — стратегий гораздо больше.
Практически применяются:
— 1 — IO пар аргументов (на какой паре произошло сопоставление, так тому и быть)
— 2 — двойная диспетчеризация в стиле обработки сообщений: MDC первого аргумента (вызов callback-функции) и оттуда IO второго аргумента (серия проверок)
— 3' — двойная диспетчеризация на наследовании: MDС первого аргумента находит статический тип из некоего известного подмножества базовых, тем самым сведя задачу к семейству методов с единственным полиморфным параметром; оттуда выполняем MDC-выбор
— 3" — то же самое, но сперва фиксируется база второго аргумента
Изощрения:
— 4 — тройная диспетчеризация: IO-выбор, по какому пути (3' или 3") выполнять двойную диспетчеризацию; такая необходимость возникает при создании мультиметода над двумя расширяемыми иерархиями (выбираем "наиболее осведомлённый о напарнике" класс).
И ещё можно напридумывать.

IO — это не нечто искусственное. Хорошо известный пример IO: когда оконная функция не смогла обработать сообщение, она вызывает дефолтную (предыдущую) функцию, отдавая сообщение дальше. Очевидно, что даже если в ней самой проверки идут в MDC-порядке, то суммарный порядок оказывается произвольным.

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

Например, некий диалог получает нотификации от контролов; каждый контрол идентифицирован своим ID'ом. Всё хорошо до тех пор, пока диалог не был субклассирован, а субкласс обрабатывает нотификации от "контролов вообще". Очевидно, контрол-вообще — это более широкий класс, чем контрол-по-номеру; но благодаря IO-выбору второго аргумента в паре (диалог, контрол) функциональность нарушилась.
Это было MDC диалога, затем IO контрола.

Другой пример с тем же диалогом. Некоторые контролы (субклассированные), вместо того чтобы посылать нотификацию (вызвать оконную функцию), вызывают другие callback-функции диалога (зарегистрированные, например, как свойства окна). Субкласс диалога о таких изысках не знает и по-прежнему ловит нотификации от "контролов вообще". Ото всех, кроме некоторых.
Это было MDC контрола, MDC диалога, далее IO контрола.

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

C>3) Гонки в MT
C>4) Deadlock'и в MT

Решены в ФЯ сто лет назад.

C>5) Неосвобождение ресурсов

Решены в управляемых средах.

C>6) Неправильная обработка исключений

Ну, так можно дойти до неправильного задания условий в if-ах.

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

AVC>>ИМХО, рассуждения о принципе подстановки Барбары Лисков в данном случае выглядят наивными.
AVC>>Здесь мы имеем дело с задачей двойной диспетчеризации, и это — ее самое простое (и универсальное) решение.

К>Стопудов, что это оно.
К>Насчёт того, самое ли это простое и безопасное — у меня остаются сомнения. Пару лет назад меня очень занимали мультиметоды и, в частности, случай мультиметода с двумя полиморфными аргументами... результат скорее пессимистический...

Я впечатлен Вашим постом.
Хотелось бы его еще обдумать.
Интересен разбор двух базовых стратегий (MDC и IO) и их вариаций.
Но какие могут быть сомнения в том, что, применительно к ситуации из книги Вирта, стратегия IO является самой простой?
Ведь, в случае использования MDC, каждый из взаимодействующих объектов обязан иметь виртуальные функции, и я не знаю, сколько их потребуется.
(BTW, вряд ли можно уйти от стратегии IO полностью. Пример: порядок перебора типа исключений в последовательности блоков catch.)
А здесь достаточно одной виртуальной функции в объектах только одного типа.
Поэтому я думаю, что это — самое простое решение.
Конечно, могут оставаться сомнения в универсальности такого подхода.
Но применительно к той задаче, которую решал Вирт в упомянутом Сергеем примере, я не вижу другого разумного решения.
Вирт пишет:

The particular flexibility of this technique using handlers and messages – sometimes identified as
polymorphism – as well as its extensibility stems from the fact that “unknown” messages are simply
ignored. They “fall through” the cascade of if – elsif statements in the handlers of objects to which the
message does not apply.

Конечно, это решение уже старое, оно не изобретено Виртом. (Хотя, ИМХО, именно в сочетании с обероновской type safety оно приобретает завершенную форму.)
И разве не такое решение используют практически все объектно-ориентированные операционные системы?
Именно благодаря такому способу двойной диспетчеризации, например, старые "виндовые" программы работают под новой версией Windows, хотя они и понятия не имеют о новых типах сообщений. Они их просто игнорируют.
Кроме того, Вирт при проектировании и написании Оберона стремился избегать чрезмерного роста числа классов (типов записей). Это было одной из причин того, что в первом Обероне не было присоединенных процедур (виртуальных функций). Ведь зачастую можно было просто переустановить процедурную переменную, не заводя нового типа.

Трурль,

> ПК> Отсюда какой должен следовать вывод у человека, которому надежность работы его программ небезразлична? На мой взгляд простой: не передавать массивы в C++ через указатели.

> Или не использовать C++. Тоже вариант.

Да, естественно, вариант. Нюанс в том, что кроме передачи массивов через указатели надежности и корректности программ угрожает огромное количество других ошибок, и с некоторыми из них C++ позволяет бороться заметно удачнее, чем другие языки. Соответственно, при выборе языка разумно учитывать и эти аспекты тоже. Если же не использовать эти возможности C++, безусловно, есть намного более подходящие альтернативы.

raskin,

>> К сожалению, в отличие от C++, поддержки сколько-нибудь сложных
>> вычислений при таком подходе не выйдет, т.к. в процессе вычислений и L^4
>> (квадрат площади), и L^5 (площать * объем), и L / T (скорость), и L^2 /
>> T^2 (квадрат скорости), и M * L / T (импульс), и M * L^2 / T^2
>> (энергия), и M^2 * L^4 / T^4 (квадрат энергии), и т.п. легко получаются...

> Это детали реализации. Можно сгенерировать модуль с типами, названными в
> духе t3l_2m1e1 (размерность Кл*кг*с*с*с/(м*м)).

Проблема в том, что этих модулей нужно сгенерировать на все мыслимые комбинации всех используемых степеней основных и дополнительных единиц системы счисления. Т.е., скажем в Си, это 7 + 2 = 9 единиц. Степени от -3 до 3 используются даже в именованных единицах. Если учесть наличие промежуточных вычислений, то нужен хоть какой-то запас. Скажем, хотя бы двукратный (т.е. промежуточные вычисления, включающие квадрат именованных единиц). Т.е. больше десятка степеней. Пусть хотя бы десяток. Итого получаем порядка 10^9 производных единиц (модулей?). Еще хуже, что можно перемножать любую из производных единиц на любую другую. Т.е. нужно еще и определить все используемые операции (хотя бы * / + -, я уж молчу о большем...) для всех попарных сочетаний всех производных единиц... В общем, по-моему, многовато генерировать получится. Нет?

P.S.

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

Предупреждая вопросы, вот один из возможных примеров

Автор: Павел Кузнецов
Дата: 07.07.05

того, о чем идет речь.

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

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

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

VD>Эта проблема решаема.

Как?

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

C>>6) Неправильная обработка исключений

VD>Ну, так можно дойти до неправильного задания условий в if-ах.

Влад, здесь, имхо, все не так просто, как кажется. Вот в Java, например, методы специфицируют порождаемые ими исключения. Поэтому в Java хотя бы компилятор позволяет понять, с какими исключениями ты можешь столкнуться. Но даже в Java я видел кучу багов, когда по наивности в finally подряд выполнялись несколько операций, каждая из которых могла порождать исключения.

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

А в C# с этим как дела обстоят?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>P.S.

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

ПК>Предупреждая вопросы, вот один из возможных примеров

Автор: Павел Кузнецов
Дата: 07.07.05

того, о чем идет речь.

Заметно удачнее? Я может что-то недопонял, но есть и более удачные решения упомянутой проблемы. Код на OCaml (не ООП, но идея, думаю, понятна):

type communicatorAnswer =
    Cancel
  | Overwrite
  | Skip

type path = Path of string

let fileExists p = (* Некая имплементация... *)
        match p with
            Path "cancel_path" -> Cancel
          | Path "overwrite_path" -> Overwrite
          | Path _ -> Skip

let answerToString a = 
    match a with
            Cancel -> "Cancel"
          | Overwrite -> "Overwrite"
          | Skip -> "Skip" (* Ну-ка, попробуй тут пропустить хоть одно из значений или сравнить с другим типом! *)

let main () =
        print_string (answerToString (fileExists Communicator (Path "cancel_path")));;

main()

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Семантика инструкции SHORT:

СГ>1) укоротить число на одно как бы поколение:
СГ>LONGINT -> INTEGER -> SHORTINT -> BYTE
СГ>REAL -> SHORTREAL
СГ>Все числа знаковые (беззнаковых чисел не существует вообще).

СГ>аналогично с символами
СГ>CHAR -> SHORTCHAR

СГ>3) С массивами: например переделать строку типа ARRAY OF CHAR в строку типа ARRAY OF SHORTCHAR

куда еще шортее чара! )
или это желание выпендриться? типа это у вас вайды всякие, а у нас просто чары, а выши чары у нас шорт?

и еще, я так понял char->byte преобразование невозможно? а как же битовые операции? а как же совместимость на уровне АПИ!?

Павел Кузнецов wrote:
> raskin,
>
>> > К сожалению, в отличие от C++, поддержки сколько-нибудь сложных
>> > вычислений при таком подходе не выйдет, т.к. в процессе вычислений и L^4
>> > (квадрат площади), и L^5 (площать * объем), и L / T (скорость), и L^2 /
>> > T^2 (квадрат скорости), и M * L / T (импульс), и M * L^2 / T^2
>> > (энергия), и M^2 * L^4 / T^4 (квадрат энергии), и т.п. легко
> получаются...
>
>> Это детали реализации. Можно сгенерировать модуль с типами, названными в
>> духе t3l_2m1e1 (размерность Кл*кг*с*с*с/(м*м)).
>
> Проблема в том, что этих модулей нужно сгенерировать на все мыслимые
> комбинации всех используемых степеней основных и дополнительных единиц
> системы счисления. Т.е., скажем в Си, это 7 + 2 = 9 единиц. Степени от
> -3 до 3 используются даже в именованных единицах. Если учесть наличие
> промежуточных вычислений, то нужен хоть какой-то запас. Скажем, хотя бы
> двукратный (т.е. промежуточные вычисления, включающие квадрат
> именованных единиц). Т.е. больше десятка степеней. Пусть хотя бы
> десяток. Итого получаем порядка 10^9 производных единиц (модулей?). Еще
> хуже, что можно перемножать любую из производных единиц на любую другую.
> Т.е. нужно еще и определить все используемые операции (хотя бы * / + -,
> я уж молчу о большем...) для всех попарных сочетаний всех производных
> единиц... В общем, по-моему, многовато генерировать получится. Нет?
Реально будет использовано меньше. Длинные произведения делаются
inline-функциями. Поэтому небольшая автоматизация изврата — и
генерируются только используемые размерности. Хотя, конечно, получится
многовато, но искусство требует жертв. Благо, не человеческих, и даже не
усилий.

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

ГВ>Однако, если сугубо формально, то анализ типа сообщения всё равно остаётся. Тем-то, кстати, и хорош LSP, что его нарушение можно определить по сугубо формальным признакам.
Как раз по сугубо формальным признакам нарушений не видно.

ГВ>А такая техника обработки сообщений в общем-то, противоречит объектному стилю. Здесь причина зарыта достаточно глубоко и, ИМХО, начинается с того, что методы объектов сами по себе являются сообщениями, а внесение дублирующей структуры типа "сообщение" становится э... чем-то вроде тавтологии. Соответственно, нарушение фундаментального принципа тащит за собой нарушения и кучи других: архитектура смешивается, зависимости становятся неявными и т.п.

Я бы не стал отождествлять методы объектов и сообщения. Методы — реакции на сообщения. А в крайнем случае реакция на любое сообщение может быть одной и той же (ignore, например.

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

CX> Сила C++ не в отдельных парадигмах, а в тесной их взаимосвязи в рамках одного языка.

У меня прямо противоположное отношение. Есть в C++ ряд интересных и полезных особенностей, но как раз их сочетание — .