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

ГВ>> ... этих "если" может быть вагон помимо индексов
СГ>Но почему вагон, ведь всего две (и обе уже решены):
СГ>1) Проверка индексов массивов;
СГ>2) Проверка правильности приведения/преобразования типов;
СГ>что еще-то???

А что, порчей памяти и зависанием ссылок проблемы ограничиваются? Почему тогда им такое предпочтение? По моим наблюдениям, куда как больше неприятностей в конечном итоге вызывают неправильные алгоритмы и их неправильное использование. Те же неприятности в MT могут принести ничуть не меньше секса.

Здравствуйте, Oleg A. Bachin, Вы писали:

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

СГ>>

СГ>>    i16 := SHORT(SHORT(i64));  (* Вот так кастуются от LONGINT к SHORTINT *)
СГ>>

OAB>.............
СГ>>(* В Oberon 2 типы чуток подругому называются, там HUGEINT — 64, LONGINT — 32, INTEGER — 16, SHORTINT — 8 битов *)

OAB>а это что было? если паскаль, то так кастуют только параноики — людям одного каста хватает.

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

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

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

Да, настолько убогого механизма вычислений на этапе компиляции нет ни в одном языке

Вот, например, по LISP-у есть книжка.

Уж как минимум LISP и его мета-возможности должен знать каждый уважающий себя программист! Чтоб потом не говорить, что вычисление на этапе компиляции есть только в C++ (хотя признаюсь, после прочтения Александреску я тоже восторгался шаблонами). Без обид.

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

К>Э! Любая программа, поданная на вход компилятора, "меняет" его поведение, потому что "обычное" поведение компилятора — в основном это лежать на диске и никого не трогать



К>Прагмы как раз влияют на компилятор, в бОльшей степени, чем compile-time программирование.

Это как? Разве можно в прагму запихнуть условие? Я всегда воспринимал прагмы как прямое указание к действие, но не условие.

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

СГ>>>

СГ>>>    i16 := SHORT(SHORT(i64));  (* Вот так кастуются от LONGINT к SHORTINT *)
СГ>>>

OAB>>.............
СГ>>>(* В Oberon 2 типы чуток подругому называются, там HUGEINT — 64, LONGINT — 32, INTEGER — 16, SHORTINT — 8 битов *)

OAB>>а это что было? если паскаль, то так кастуют только параноики — людям одного каста хватает.

К>Я так понял, что SHORT — это перегруженная функция, берущая младшую половинку числа. Поскольку SHORTINT — это четверть от LONGINT, пришлось вызвать дважды.

в случае signed типов просто взять младшую половинку не совсем красивое решение... потеря знака гарантированна. интересненький каст тогда получается...

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

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

WF>Да, настолько убогого механизма вычислений на этапе компиляции нет ни в одном языке

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

WF>Вот, например, по LISP-у есть книжка.

WF>Уж как минимум LISP и его мета-возможности должен знать каждый уважающий себя программист! Чтоб потом не говорить, что вычисление на этапе компиляции есть только в C++ (хотя признаюсь, после прочтения Александреску я тоже восторгался шаблонами). Без обид.

Да ладно, какие обиды.
Вот только мы же не о лиспе говорим. Согласись, это язык совсем другого уровня.

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

К>Это не хак и не кряк, а непонимание того, как устроен CString.
Кодт, спасибо за поправку. На самом деле я имел ввиду именно приведение типа такого:

Header *p = &((Header*)m_Data)[-1];

К>У него нет "минус-первого" элемента массива (хотя бы потому, что элементы массива — это символы — CHAR/WCHAR, а служебная информация там явно не однобайтная).
Да, естественно.

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

CX>Пример приведу на C++ — им владею намного лучше, чем функциональными языками.

Шаблоны имеют много общего с функциональными языками

CX>

CX>template <int A, size_t N>
CX>struct power
CX>{
CX>    static int const result = A * power<A, N - 1>::result;
CX>};

CX>template <int A>
CX>struct power<A, 0> {static int const result = 1;};

CX>int a = power<4, 5>::result;
CX>

CX>Пример очень упрощенный, но основная идея в нем видна — вычисления происходит в compile-time, при этом с помощью частичной специализации введено условие, при совпадении с которым компилятор прекращает рекурсию (т.е. изменяет поведение). Ни один аспект этого поведения не попадает в конечный код, вся работа производится компилятором.

(define (pow x n)
    (define (pow1 n t)
        (if (= n 0)
            t
            (pow1 (- n 1) (* t x))))
    (pow1 n 1))


(define-syntax pow-ct
    (lambda (x)
        (syntax-case x ()
            ((_ a n) (pow (syntax-object->datum (syntax a)) (syntax-object->datum (syntax n)))))))

(define-macro (pow-ct2 a n)
    (pow a n))


(print (pow-ct 2 3))

(print (pow-ct2 3 4))

8 и 81 будут вычислены при компиляции (или при интерпретации ). Первый макрос в стиле Scheme, второй в стиле LISP (код написан на Scheme).

Заметь, функция pow — обычная функция. Вместо нее могла быть функция рейтрейсинга и я так же спокойно мог бы использовать ее в compile-time (ну, например, чтобы встроить в свой код красивый логотип в виде битмапа ). А у тебя "функция" power во время исполнения абсолютно бесполезна. Вот это и есть убожество C++ с точки зрения метапрограммирования.

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

CX>Вот только мы же не о лиспе говорим. Согласись, это язык совсем другого уровня.

Ну да, и что? Как можно говорить о вычислениях на этапе компиляции, не зная макросов LISP? Есть, конечно, уйма других подходов, но LISP — это однозначно один из самых значительных.

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

СГ>1) неправильный индекс массива
СГ>2) неправильное приведение типа
СГ>3) неправильная синхронизация потоков, изменяющих одну и туже переменную

СГ>Две из них решаются с помощью проверок во время исполнения, от третьей, видимо, в принципе нет защиты, кроме аккуратного проектирования.

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

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

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

CX>>Вот только мы же не о лиспе говорим. Согласись, это язык совсем другого уровня.

WF>Ну да, и что? Как можно говорить о вычислениях на этапе компиляции, не зная макросов LISP? Есть, конечно, уйма других подходов, но LISP — это однозначно один из самых значительных.

Стоп-стоп-стоп. Изначально речь шла о безопасных и небезопасных традиционных языках. Зашла речь о метапрограммировании, которое доступно в C++ и недоступно в других языках, которые приводились как его главные противники.
Причем здесь лисп? Да ни причем. Ежу понятно, что C++ с функциональными языками в сфере метапрограммирования конкурировать не может. Ну так и не нужно. Разве ж этого кто добивался?

CrystaX wrote:
>> > Это как? Свой язык создавать предлагаете?
> R>Хотя бы препроцессор. Или диалект Паскаль. Тем, кто не поддержит идею —
> R>отдавать сгенерированный код, если надо.
>
> В экую степь унесло! Речь ведь идет о *существующих* языках.
Я на этом пишу! На том, что уже реализовал. Супер-убого — но лучше,
нежели ничего (для меня). Велосипед на десяток килобайт — уже препроцессор.
>
> R>Если можно, приведите пример, что Вы считаете compile-time metaprogramming
>
> Пример приведу на C++ — им владею намного лучше, чем функциональными
> языками.
>
> template <int A, size_t N>
> struct power
> {
> static int const result = A * power<A, N — 1>::result;
> };
>
> template <int A>
> struct power<A, 0> {static int const result = 1;};
>
> int a = power<4, 5>::result;
>
>
>
> Пример очень упрощенный, но основная идея в нем видна — вычисления
> происходит в compile-time, при этом с помощью частичной специализации
> введено условие, при совпадении с которым компилятор прекращает рекурсию
> (т.е. изменяет поведение). Ни один аспект этого поведения не попадает в
> конечный код, вся работа производится компилятором.
При аккуратной генерации тоже такое используется. Включая (если надо)
использование обычно run-time функций из модулей проекта. Ну, правда,
зависимости ловить надо.
>
>> > Здесь куда-то в сторону уехали
> R>Про AST? Ну, иногда создавать обобщённый код в его терминах приятней.
>
> Да нет, просто это уже вообще не о метапрограммировании.
Формально говоря разные compile-time вычисления можно описать в терминах
замены символов в AST на их значения в compile-time среде.

CrystaX wrote:
> Здравствуйте, Кодт, Вы писали:
>
> К>Э! Любая программа, поданная на вход компилятора, "меняет" его
> поведение, потому что "обычное" поведение компилятора — в основном это
> лежать на диске и никого не трогать
>
>
>
> К>Прагмы как раз влияют на компилятор, в бОльшей степени, чем
> compile-time программирование.
>
> Это как? Разве можно в прагму запихнуть условие? Я всегда воспринимал
> прагмы как прямое указание к действие, но не условие.
Зато можно очень резко поменять его отношение к некоторым конструкциям.

CrystaX wrote:
> WF>Ну да, и что? Как можно говорить о вычислениях на этапе компиляции,
> не зная макросов LISP? Есть, конечно, уйма других подходов, но LISP —
> это однозначно один из самых значительных.
>
> Стоп-стоп-стоп. Изначально речь шла о безопасных и небезопасных
> традиционных языках. Зашла речь о метапрограммировании, которое доступно
> в C++ и недоступно в других языках, которые приводились как его главные
> противники.
> Причем здесь лисп? Да ни причем. Ежу понятно, что C++ с функциональными
> языками в сфере метапрограммирования конкурировать не может. Ну так и не
> нужно. Разве ж этого кто добивался?

Функциональный ли язык LISP зависит от того, как им пользоваться, в
конце концов. Императивные оптимизации у него обычно плохие — но писать
императивно можно.

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

ГВ>Дальше в любом случае нужно анализировать саму задачу и её реализацию. В данный момент я оспариваю обобщение, сформулированное Сергеем Губановым:

ГВ>

AVC>>>Еще иногда требуется проверка динамического типа переменной. Для этого в Обероне достаточно одного сравнения.
ГВ>>А это вообще часто называется ошибкой проектирования.
ГВ>Наоборот. Это такой способ проектирования.
ГВ> http://www.inr.ac.ru/~info21/wirth/programming_in_oberon.pdf

ГВ>Нет ничего удивительного в том, что для иллюстрации использования IS Вирт пользуется таким приёмом, в конце концов, иллюстрация есть иллюстрация. Никто же не заставляет, например, "в лоб" переносить объектные модели из книг Буча/Шлеера/и т.д. в реальные проекты (хотя некоторые горячие головы могут)!

Я — такая "горячая голова".
Я использовал на практике метод Шлеер (мне кажется, это дама) и Меллора практически "в лоб".
И, как мне кажется, весьма успешно.
Дальнейшее развитие этого метода привело к генерации программного кода прямо из UML (это называется xUML).

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

ГВ>

ГВ>struct message {
ГВ>  int type;
ГВ>    // ...
ГВ>};

ГВ>#define DRAW_MESSAGE 12345
ГВ>#define MARK_MESSAGE 67890
ГВ>// ...

ГВ>class Handler {

ГВ>void handle(const message &msg)
ГВ>{
ГВ>  switch(msg.type)
ГВ>    {
ГВ>      case DRAW_MESSAGE: // ...
ГВ>        case MARK_MESSAGE: // ...
ГВ>    }
ГВ>}

ГВ>};

ГВ>

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

ГВ>Так что, хотя такой "способ проектирования" и есть, но я бы не стал заявлять о нём, как о чём-то, имеющем ценность большую, чем сугубо иллюстративную.

В некоторых случаях этому методу нет альтернативы.
Он используется независимо от языка, как на Обероне, так и на Си.
Как например, Вы предложили бы реализовать рассылку сообщений в Windows?
Приведенный Сергеем пример из книги Вирта просто демонстрирует, что в Обероне это делается безопасным путем.
(В этом огромное отличие от того кода, что привели Вы.)
ИМХО, рассуждения о принципе подстановки Барбары Лисков в данном случае выглядят наивными.
Здесь мы имеем дело с задачей двойной диспетчеризации, и это — ее самое простое (и универсальное) решение.

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

CX>Причем здесь лисп? Да ни причем. Ежу понятно, что C++ с функциональными языками в сфере метапрограммирования конкурировать не может. Ну так и не нужно. Разве ж этого кто добивался?

Дмитрий, мне кажется эта ветка флейма началась с твоего утверждения:

Согласен. Сильно. Скажу тогда чуток послабже: "Из всех известных мне языков шаблонное, compile-time программирование присуще только C++". Но если я неправ и есть язык, поддерживающий эту концепцию столь же хорошо, как C++, покажите мне его. Я таких не нашел.

Народ понял тебя буквально.

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

К>Я так понял, что SHORT — это перегруженная функция, берущая младшую половинку числа. Поскольку SHORTINT — это четверть от LONGINT, пришлось вызвать дважды.

В принципе верно, но не совсем функция и не совсем половину. SHORT — это предопределенная инструкция языка, такая же как, например, INC, DEC, ASL, ASR, LEN, BITS, ORD,...

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

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

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

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

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>в случае signed типов просто взять младшую половинку не совсем красивое решение... потеря знака гарантированна. интересненький каст тогда получается...

Она берет по умному. Кстати, все числовые типы в Обероне со знаком. Беззнаковых числовых типов нет вообще.

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

CX>Все примеры, что ты приводил, относятся к той самой части языка, которая не type-safety и досталась в наследие от C. И конечно же, ты можешь неявно привести массив к указателю, обратиться за границы массива и т.д. и т.п. Компилятор тебе этого не запретит. Но кто тебя заставляет это делать? Никто.

О, какя логика замечательная. Дык меня и на ассемблере никто не заставляет память портить. Пиши себе окуратно. Соблюдай паттерны и будет тебе счастье. Подтверждение тоже как у С++ есть программы написанные на асме которые работают.

CX> Это как раз пример той самой "запретительной" конвенции, о которой я говорил чуть раньше. Не используй массивы — есть много им альтернатив, начиная с std::vector.

От жаль, что большая часть их релизации в релизе выход за границы не контролирует. А в VC6 и в дебаге не контролировала.

CX> Не используй голые указатели — смарт-пойнтеров огромное множество.

Логично. Но как? Все АПИ вокруг требуют их. Можно произвести смелый эксперемент. Поищем на этом сайте (тут же одни гурья, значит хоть тут должны писать грамотно!), например, такой код &amp;v[0]. Ой! 36 документов! Откуда?!

CX> Type safety будет почти 100%.

О! Почти. Т.е. ты и сам в это не веришь? Ну, оно и логично. Кто же поверит в такую фигню. Безопасность типов в плюсах целиком лежит на плечах программиста. Он сам должен контролировать себя.

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

CX> И глядишь, все станет радужнее и приятнее.

А что при этом осталось от хваленого С++? Указатели нельзя... массивы тоже... функции с переменным числом параметров тоже нельзя. Даже переменную примитивного типа в классе лучше не объявлять. А то ведь не дай бог забудешь проинициализировать! Что у нас дальше? А, ну, да. Память тоже руками выделять нельзя. Неравен час забудешь delete вызвать, а кругом исключения так и кишат. Вот и видишь в коде вот такие приколы:

if (iid == IID_IUnknown || iid == IID_ICallInterceptor)
    hr = CComPtr<ICallInterceptor>(this).CopyTo(
        (ICallInterceptor**)ppvObject);
else if (iid == IID_ICallUnmarshal)
    hr = CComPtr<ICallUnmarshal>(this).CopyTo((ICallUnmarshal**)ppvObject);
else if (iid == m_iid)
    hr = CComPtr<IUnknown>((IUnknown*)&m_thunk).CopyTo(
        (IUnknown**)ppvObject);

И ведь даже обоснование этом делу разумное — "Вопрос стиля. Избегаю ручного управления ресурсами в том числе и прямых вызовов AddRef, Release и т.п. ".

CX>Все эти низкоуровневые элементы есть смысл использовать только при реализации высокоуровневых примитивов и/или в критичных по производительности местах (хотя и тут надо смотреть внимательно — зачастую высокоуровневые средства типа тех же смарт-пойнтеров никакого run-time оверхеда в себе не несут).

О! Хорошая оговорка. А так как хочется по быстрее, то такими местами становится пол программы.

CX> Конечно, если ты начнешь направо и налево указатели разбрасывать да массивы к указателям приводить, ничего путного не получится. Но не надо, пожалуйста, приводить это в качестве довода — никто не заставляет тебя их использовать где попало.

Резюмируем. Половина С++ надо пометить как "запрещенно к использованию". При этом мы получаем намго более простой язык. Скорость у него уже далеко не С++-ная. Куча рантйм-проверок... лишнего кода... не совсем оптимальных решений. При этом постоянно нужно следить, "чтобы не оступиться". Контролировать кучу никакого отношения к основному алгоритму не имющих вещей... и т.д., т.п.

Так може вместо этого чуда-языка в котором половину нельзя взять язык где есть только то что можно, а то что нельзя прямо помечается как опасное? Зачем над собой то издеваться? Скорости это не дает. Выигрывается только память. Неуже ли она настолько дорога?

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

CX>Ну почему же — отличается. Прежде всего тем, что в моем случае, если понадобится, я смогу использовать и голые указатели, и прочее.

Как я понимаю и в Обероне есть указатели. Ну, не голые, но скорость та же. И в Шарпе тоже есть. В небезопасном режиме, но есть. Так зачем плюсы то? Ради СТЛ? Да напиши ты ее для шарпа и живи спокойно.

CX> Кроме того, отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование.

О. Оно есть без шаблонов. Поставь себе тот же R# и "шаблонное метапрограммирование" покажется тебе детской забавой.

Ну, или если тебе больше нравятся компилируемые в машинный код языки без серьезного рантайма, то возьми Ocaml. Его препроцессор, да и встроенные возможности тоже рвет С++-ные шаблоны как тузик грелку.