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

E>Я бы подкоректировал твой список:

CX>>Надо разделять два понятия:
CX>>1. Язык помогает писать надежные программы
CX>>2. Язык запрещает писать ненадежные программы.
E>3. Язык позволяет писать надежные программы.

CX>>Так вот, C++ помогает писать надежные, но не запрещает писать ненадежные программы, только и всего.

E>Имхо, C++ позволяет писать надежные программы.

Ок. На мой взгляд, позволяет и помогает писать надежные, но не запрещает писать ненадежные программы.

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

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

E>>Я бы подкоректировал твой список:

CX>>>Надо разделять два понятия:
CX>>>1. Язык помогает писать надежные программы
CX>>>2. Язык запрещает писать ненадежные программы.
E>>3. Язык позволяет писать надежные программы.

CX>>>Так вот, C++ помогает писать надежные, но не запрещает писать ненадежные программы, только и всего.

E>>Имхо, C++ позволяет писать надежные программы.

CX>Ок. На мой взгляд, позволяет и помогает писать надежные, но не запрещает писать ненадежные программы.

Нет. Я бы еще уточнил:

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

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

CX>>Ок. На мой взгляд, позволяет и помогает писать надежные, но не запрещает писать ненадежные программы.

E>Нет. Я бы еще уточнил:

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

Ок, пусть будет по-твоему.

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

AVC>>Наслышан. Правда, все примеры, которые мне попадались, сводились к вычислениям во времени компиляции. Других выгод я пока не видел.

CX>А разве этого недостаточно?

Что-то это мне напоминает...

AVC>>Но я попробую назвать хотя бы несколько преимуществ.
CX>[skipped]
CX>В этом месте Вы рассказали только ожидаемое, а именно — модули и garbage collector. На самом деле это не совсем то, что я хотел услышать.

CX>Согласен. Но я говорил именно о шаблонном метапрограммировании, compile-time программировании, присущем только C++.
"Только C++" — это очень сильно сказано.

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

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

AVC>>>Наслышан. Правда, все примеры, которые мне попадались, сводились к вычислениям во времени компиляции. Других выгод я пока не видел.

CX>>А разве этого недостаточно?

Т>Что-то это мне напоминает...
Т>

AVC>>Но я попробую назвать хотя бы несколько преимуществ.
CX>>[skipped]
CX>>В этом месте Вы рассказали только ожидаемое, а именно — модули и garbage collector. На самом деле это не совсем то, что я хотел услышать.

Не совсем понял, к чему здесь эта цитата. Объясните, если не трудно.
Или Вы о повторяемости ситуации? Так здесь схожесть только внешняя, не более того.

CX>>Согласен. Но я говорил именно о шаблонном метапрограммировании, compile-time программировании, присущем только C++.
Т>"Только C++" — это очень сильно сказано.

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

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

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

Могу только догадываться, что ты имел ввиду под словом "шаблонное". Вот тебе примеры compile-time программирования:

Конечно же, LISP. Правда, тут метапрограммирование не "шаблонное", а основанное на преобразовании AST. Scheme-овские syntax-rules. В принципе, похожи на шаблоны C++.

Ну и куча языков/средств, куда были добавлены макросы на основе сплайсов: Nemerle, Template Haskell, Java Syntactic Extender. Наверное, наиболее похожи на шаблоны C++. С учетом того, что, например, в Template Haskell часть задач шаблонов C++ решается более мощной системой типов (параметрический полиморфизм).

Заметь, в отличии от C++ для метапрограммирования используется тот же host-язык. В C++, например, в компайл-тайм вызвать функцию некую библиотечную функцию (например, sin) нельзя.

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

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

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

WF>Могу только догадываться, что ты имел ввиду под словом "шаблонное". Вот тебе примеры compile-time программирования:

WF>Конечно же, LISP. Правда, тут метапрограммирование не "шаблонное", а основанное на преобразовании AST. Scheme-овские syntax-rules. В принципе, похожи на шаблоны C++.

Эээ... А разве здесь compile-time? Или все же interpret-time?

WF>Ну и куча языков/средств, куда были добавлены макросы на основе сплайсов: Nemerle, Template Haskell, Java Syntactic Extender. Наверное, наиболее похожи на шаблоны C++. С учетом того, что, например, в Template Haskell часть задач шаблонов C++ решается более мощной системой типов (параметрический полиморфизм).

Мне вообще интересен вполне конкретный механизм — рекурсивные вычисления в compile-time с возможностью эту самую рекурсию останавливать. В C++ это делается с помощью специализаций. Как с этим обстоит дело в вышеприведенных языках?

WF>Заметь, в отличии от C++ для метапрограммирования используется тот же host-язык. В C++, например, в компайл-тайм вызвать функцию некую библиотечную функцию (например, sin) нельзя.

Совершенно верно, т.к. в вычислениях должны участвовать только compile-time значения. Иначе какой же это compile-time?

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

CX>Эээ... А разве здесь compile-time? Или все же interpret-time?

Интересный вопрос. Но учитывая существование комипиляторов LISP (например, SBCL), то можно сказать что и compile-time тоже.

CX>Мне вообще интересен вполне конкретный механизм — рекурсивные вычисления в compile-time с возможностью эту самую рекурсию останавливать. В C++ это делается с помощью специализаций. Как с этим обстоит дело в вышеприведенных языках?

Очень просто. Как я уже сказал, эти вычисления пишутся на том же языке, что и основной код. Результат вычислений просто подставляется в код (в случае макросов, основанных на сплайсах).

В случае Scheme-овских syntax-rules так вообще есть почти прямой аналог специализации шаблонов — паттерн матчинг.

CX>Совершенно верно, т.к. в вычислениях должны участвовать только compile-time значения. Иначе какой же это compile-time?

Не вижу противоречий. Почему бы, например, не подсчитать тот же sin в compile-time? Или strlen? Например, хочу такую конструкцию: (print-with-len "Some string") разворачивать в такую: (begin (print "Some string") (print 11)), где 11 — это просто длина строки. Я ведь вполне могу это сделать и в compile-time?

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

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

ГВ>>Следовательно, проверять индекс нужно до его использования, следовательно, проверять индекс на уровне массива никакой необходимости нет — всё равно он ему "приходит" уже заведомо корректным.
СГ>А если приходит всё же не корректным, тогда что, портить память?
Я говорил о том случае, когда индекс заведомо корректен. "Если" злонамеренно не предусматривается, поскольку этих "если" может быть вагон помимо индексов, так что, вопрос отклоняется.

AVC>>>Еще иногда требуется проверка динамического типа переменной. Для этого в Обероне достаточно одного сравнения.
ГВ>>А это вообще часто называется ошибкой проектирования.
СГ>Наоборот. Это такой способ проектирования.
Да, есть такой способ. Правда он слегка не LSP-compliant. Из того, что пользуясь им Вирт иллюстрирует программирование на Обероне следует только то, что Вирт таким образом иллюстрирует программирование на Обероне. Не стоит обобщать.

CrystaX wrote:
> WF>Конечно же, LISP. Правда, тут метапрограммирование не "шаблонное", а
> основанное на преобразовании AST. Scheme-овские syntax-rules. В
> принципе, похожи на шаблоны C++.
>
> Эээ... А разве здесь compile-time? Или все же interpret-time?
>
По выбору

> WF>Заметь, в отличии от C++ для метапрограммирования используется тот же
> host-язык. В C++, например, в компайл-тайм вызвать функцию некую
> библиотечную функцию (например, sin) нельзя.
>
> Совершенно верно, т.к. в вычислениях должны участвовать только
> compile-time значения. Иначе какой же это compile-time?
Легко. Мне нравится Паскаль. Но возможности нормально обратиться по
именам к 25 переменным по очереди не хватает. Ладно, пишу программу,
генерирующую нужный код, а её вывод гордо въезжает (на велосипеде, т.к.
хранить отдельно и не забывать собирать лень) в библиотеку.

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


WF>Не вижу противоречий. Почему бы, например, не подсчитать тот же sin в compile-time? Или strlen? Например, хочу такую конструкцию: (print-with-len "Some string") разворачивать в такую: (begin (print "Some string") (print 11)), где 11 — это просто длина строки. Я ведь вполне могу это сделать и в compile-time?

так вроде с таким компиляторы C++ уже довольно давно справляются:

int main(int argc, char *argv[])
{
printf("%d\n", strlen("Some string"));
return 0;
}

превращается с помощью VC7.1 в:

; 13   : printf("%d\n", strlen("Some string"));

    push    11                    ; 0000000bH
    push    OFFSET FLAT:$SG928
    call    _printf
    add    esp, 8

; 14   : return 0;

    xor    eax, eax

; 15   : }

    ret    0

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

CX>>Мне вообще интересен вполне конкретный механизм — рекурсивные вычисления в compile-time с возможностью эту самую рекурсию останавливать. В C++ это делается с помощью специализаций. Как с этим обстоит дело в вышеприведенных языках?

WF>Очень просто. Как я уже сказал, эти вычисления пишутся на том же языке, что и основной код. Результат вычислений просто подставляется в код (в случае макросов, основанных на сплайсах).

WF>В случае Scheme-овских syntax-rules так вообще есть почти прямой аналог специализации шаблонов — паттерн матчинг.

Интересно. В свободное время обращу на это внимание. А затем, вполне возможно, вернемся к данному обсуждению.

CX>>Совершенно верно, т.к. в вычислениях должны участвовать только compile-time значения. Иначе какой же это compile-time?

WF>Не вижу противоречий. Почему бы, например, не подсчитать тот же sin в compile-time? Или strlen? Например, хочу такую конструкцию: (print-with-len "Some string") разворачивать в такую: (begin (print "Some string") (print 11)), где 11 — это просто длина строки. Я ведь вполне могу это сделать и в compile-time?

Да, это возможно. Но и в C++ возможно выполнить подобное вычисление в compile-time. Вообще, конечно, нынешняя ситуация с шаблонами не очень удобна для создания подобных конструкций, но с введением в язык мета-функций (что, я надеюсь, все-таки случится) ситуация упростится и Ваш аргумент будет применим и к C++.

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

>> Совершенно верно, т.к. в вычислениях должны участвовать только
>> compile-time значения. Иначе какой же это compile-time?
R>Легко. Мне нравится Паскаль. Но возможности нормально обратиться по
R>именам к 25 переменным по очереди не хватает. Ладно, пишу программу,
R>генерирующую нужный код, а её вывод гордо въезжает (на велосипеде, т.к.
R>хранить отдельно и не забывать собирать лень) в библиотеку.

Разве это можно назвать compile-time вычислениями? Это же просто генерация кода, которая может быть выполнена практически на любом языке. Вот, например, в QT прежде чем скомпилировать программу, ее надо через их препроцессор прогнать (moc). Но разве можно это назвать метапрограммированием в compile-time?

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

WF>>Не вижу противоречий. Почему бы, например, не подсчитать тот же sin в compile-time? Или strlen? Например, хочу такую конструкцию: (print-with-len "Some string") разворачивать в такую: (begin (print "Some string") (print 11)), где 11 — это просто длина строки. Я ведь вполне могу это сделать и в compile-time?

FR>так вроде с таким компиляторы C++ уже довольно давно справляются:
FR>

[...]
FR>

FR>превращается с помощью VC7.1 в:
FR>

[...]
FR>

Ну ты же понимаешь, что это не то.

CrystaX wrote:
> Здравствуйте, raskin, Вы писали:
>
>> > Совершенно верно, т.к. в вычислениях должны участвовать только
>> > compile-time значения. Иначе какой же это compile-time?
> R>Легко. Мне нравится Паскаль. Но возможности нормально обратиться по
> R>именам к 25 переменным по очереди не хватает. Ладно, пишу программу,
> R>генерирующую нужный код, а её вывод гордо въезжает (на велосипеде, т.к.
> R>хранить отдельно и не забывать собирать лень) в библиотеку.
>
> Разве это можно назвать compile-time вычислениями? Это же просто
> генерация кода, которая может быть выполнена практически на любом языке.
> Вот, например, в QT прежде чем скомпилировать программу, ее надо через
> их препроцессор прогнать (moc). Но разве можно это назвать
> метапрограммированием в compile-time?

Добавлю в язык — можно будет. Если нет — то что Вы называете
мета-программированием? (я не утверждаю, что у меня есть хорошее
определение; это вопрос с целью узнать) Пока — да, генерация кода. Но
разные мелочи вроде упомянутых в теме позволяет сделать с меньшей моей
работой (а в чём ещё цель? надёжность тоже уменьшает работу). Я это, как
правило, использую вместо шаблонных функций и длинных конструкций (Что,
я что ли буду объявлять очевидную ерунду). Будет время — прикручу AST
модуля. А просто лямбда-функции мне просто не нужны — для этого есть
TMethod. Не говорите, что для этого нужен объект. А так, конечно
LISP/Scheme — но я не нашёл пока себе набор библиотеки+компилятор, чтобы
можно было с комфортом делать не только вычисления (в широком смысле).

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

R>Добавлю в язык — можно будет.

Это как? Свой язык создавать предлагаете?

R>Если нет — то что Вы называете
R>мета-программированием? (я не утверждаю, что у меня есть хорошее
R>определение; это вопрос с целью узнать)

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

R>Пока — да, генерация кода. Но
R>разные мелочи вроде упомянутых в теме позволяет сделать с меньшей моей
R>работой (а в чём ещё цель? надёжность тоже уменьшает работу). Я это, как
R>правило, использую вместо шаблонных функций и длинных конструкций (Что,
R>я что ли буду объявлять очевидную ерунду). Будет время — прикручу AST
R>модуля.

Здесь куда-то в сторону уехали.

R>А просто лямбда-функции мне просто не нужны — для этого есть
R>TMethod. Не говорите, что для этого нужен объект.

Хорошо, не буду.

R>А так, конечно
R>LISP/Scheme — но я не нашёл пока себе набор библиотеки+компилятор, чтобы
R>можно было с комфортом делать не только вычисления (в широком смысле).

Каждой задаче — свой инструмент.

CrystaX wrote:

> Здравствуйте, raskin, Вы писали:
>
> R>Добавлю в язык — можно будет.
>
> Это как? Свой язык создавать предлагаете?
Хотя бы препроцессор. Или диалект Паскаль. Тем, кто не поддержит идею —
отдавать сгенерированный код, если надо.
>
> R>Если нет — то что Вы называете
> R>мета-программированием? (я не утверждаю, что у меня есть хорошее
> R>определение; это вопрос с целью узнать)
>
> Я не готов дать определение термину "метапрограммирование" в его широком
> смысле — это непростая задача. Но у меня есть определение термину
> "compile-time метапрограммирование". Это возможность с помощью
> определенных языковых конструкций изменять поведение компилятора.
> Подчеркиваю — изменять поведение компилятора, а не конечной программы!
> Изменение конечного кода это только эффект от изменения поведения
> компилятора. В C++ этого добиваются операциями над типами.

Если честно, не очень понял. Я могу сделать что-то вроде list of
myobject — это считается? Могу описать алгоритм с
параметром-подпроцедурой. Могу из перегруженных функций собрать
перегруженный алгоритм (без усилий). А что для счастья надо? Новые
ключевые слова?
Если можно, приведите пример, что Вы считаете compile-time metaprogramming

> R>Пока — да, генерация кода. Но
> R>разные мелочи вроде упомянутых в теме позволяет сделать с меньшей моей
> R>работой (а в чём ещё цель? надёжность тоже уменьшает работу). Я это, как
> R>правило, использую вместо шаблонных функций и длинных конструкций (Что,
> R>я что ли буду объявлять очевидную ерунду). Будет время — прикручу AST
> R>модуля.
>
> Здесь куда-то в сторону уехали
Про AST? Ну, иногда создавать обобщённый код в его терминах приятней.

> R>А просто лямбда-функции мне просто не нужны — для этого есть
> R>TMethod. Не говорите, что для этого нужен объект.
>
> Хорошо, не буду.
>
> R>А так, конечно
> R>LISP/Scheme — но я не нашёл пока себе набор библиотеки+компилятор, чтобы
> R>можно было с комфортом делать не только вычисления (в широком смысле).
>
> Каждой задаче — свой инструмент.
Да, конечно.. Просто язык удобен, компилятор есть — а stand-alone ещё
подумай, как собрать, и окошко для ввода-выводы подумай, как нарисовать.
Лень. Пока что.

А ещё Пролог и Форт.

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

AVC>>>>Еще иногда требуется проверка динамического типа переменной. Для этого в Обероне достаточно одного сравнения.
ГВ>>>А это вообще часто называется ошибкой проектирования.
СГ>>Наоборот. Это такой способ проектирования.
ГВ>Да, есть такой способ. Правда он слегка не LSP-compliant.
Это почему-же?
ГВ>Из того, что пользуясь им Вирт иллюстрирует программирование на Обероне следует только то, что Вирт таким образом иллюстрирует программирование на Обероне. Не стоит обобщать.
А из того, что таким образом спроектирована Оберон-система следует только то, что таким образом спроектирована Оберон-система.

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

AVC>>>>>Еще иногда требуется проверка динамического типа переменной. Для этого в Обероне достаточно одного сравнения.
ГВ>>>>А это вообще часто называется ошибкой проектирования.
СГ>>>Наоборот. Это такой способ проектирования.
ГВ>>Да, есть такой способ. Правда он слегка не LSP-compliant.
Т>Это почему-же?
Сейчас ссылки поднимать некогда, закину завтра. Пока что, посмотри в инете по ключевому слову LSP или Liskov's Substitution Principle. Можно даже поиском по RSDN.

ГВ>>Из того, что пользуясь им Вирт иллюстрирует программирование на Обероне следует только то, что Вирт таким образом иллюстрирует программирование на Обероне. Не стоит обобщать.
Т>А из того, что таким образом спроектирована Оберон-система следует только то, что таким образом спроектирована Оберон-система.