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

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

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

Интересно было бы иметь аналогов классов из Haskell. А ещё лучше, встроенный в компилятор детектор быдлокода: увидел быдлокод — выдал ошибку

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

ТКС>>Тут еще вопрос, что при промышленной разработке дешевле Компилируется-то оно тоже по сто раз на дню...

C>для этого придумали precompiled header и частичную компиляцию

В промышленной разработке precompiled header могут замедлять время сборки. У нас после отключения precompiled headers в проекте время сборки упало почти в 1.5 раза.

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

BZ>новое — это хорошо разрекламированное старое синтаксические макросы хорошо известны с 60-х, как и их недостатки

Если не изменяет память, макросы в Лиспе появились значительно позже. По крайней мере в том виде в котором их понимают сейчас. В 60-ых появился сам Лисп. Подом был долгий путь к квази-цитированию и выделенному коду трансформации.

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

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

ТКС>>>Тут еще вопрос, что при промышленной разработке дешевле Компилируется-то оно тоже по сто раз на дню...

C>>для этого придумали precompiled header и частичную компиляцию

К>В промышленной разработке precompiled header могут замедлять время сборки. У нас после отключения precompiled headers в проекте время сборки упало почти в 1.5 раза.

Забыл добавить. Время распределённой сборки.

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

BZ>для того, чтобы у тебя в шаблонах/макросах не появлялось многоэтажных сообщений об ошибках, нужна типизация. те самые концепты. без них что угодно можно подставить куда попало

BZ>для отладки нужно дать отладчику инофрмацию о том какая строка сейчас выполняется и какие у нас есть переменные. а откуда она возьмётся, если текст подвергся обработке препроцессором? и получаешь ты то же самое, как при отладке в высокоуровневой программы на уровне ассемблера

Обожаю теоретиков.

Звучит все складно, как в пвсевдо-научных статьях, но с практиков не коррелирует.

На практике все же совсем иначе. Макрос — это программа. И этим все сказано. Эта программа не тупой трансформатор АСТ. Она может и типы проверить. Результат правда будет доступен не во время компиляции макроса, а во время компиляции программы которая использует этот макрос. Но для конечного пользователя-программиста именно это и нужно.

Собственно написать и отладить макрос конечно сложнее нежели просто код, но сложность тут в основном определяется не периодом типизации, а тем что это мета-код, т.е. код высшего порядка (скажем так).

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

BZ>>compile-time dynamic typing

K>Мне одному кажется, что это оксюморон?

Согласен, но если подходить к вопросу несколько мягче, то в его словах действительно можно углядеть нечто рациональное.

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

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

A>А типами (видами) макросов можно назвать следующие две разновидности.
A>1. Макросы, вводящие новые синтаксические конструкции и трансформирующие их во встроенные конструкции языка. Эти макросы служат только одной цели — позволяют создавать и использовать синтаксический сахар.
A>2. Макросы, которые используются для трансформации втроенных языковых конструкций в другие конструкции. Например, добавление сериализации, трансформация кода в ленивые или реактивные вычисления и тд, а также возможно анализа кода для каких либо оптимизаций.

Вообще-то есть и строготипизированные макросы. Так есть MacroML

Автор(ы): Kamil Skalski, Michal Moskal и Pawel Olszta
Дата: 23.05.2006
Пример C++ показывает, что индустрии нужны системы метапрограммирования – даже достаточно причудливая система шаблонов широко используется для вычислений во время компиляции. Эта статья является исследованием возможного внедрения техники метапрограммирования в индустриальную среду в более чистой форме. Мы, таким образом, фокусируемся на том, чтобы сделать нашу систему легкой в использовании для программистов, как пишущих, так и использующих макросы.

в котором макросы типизируются. Вот только результат не прижился. Гибкость не та.

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

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

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

Я даже больше скажу. Можно весь язык сделать одной (большой) библиотекой макросов. Это, кстати, будет проделано в Nemerle 2

Автор: VladD2
Дата: 17.06.10

(так же см. Вопрос по синтаксису макросов для v2

Автор: VladD2
Дата: 21.06.10

).

M>В C++ сообществе уже есть успешный опыт по кастомизации синтаксиса с помощью перегрузки операторов, шаблонов. Взгляните на BOOST_FOREACH, SCOPE_EXIT, boost::lambda.

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

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

+1. Особенно те что продумываются для версии 2.

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

__>Мега макросы это хорошо, но лучше улучшать понемногу и пользоваться, чем ждать супер улучшений 12 лет ))

Можно просто взять что-то по продвинутее С++ и пользоваться всеми вкусностями уже сейчас.

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

D>>3. Продолжения

K>А как совмещать продолжения и RAII?

GC

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

Хорошо было бы иметь большую свободу в описании конструкторов объектов.
Сейчас, в первую очередь инициализация в списке инициализации — конструкторы базовых классов, поля,
а потом исполняется тело конструктора.

Зачастую, хочется перед инициализацией из списка инициализации, посчитать что-нить предварительно.

Было бы круто написать что-нибудь вроде

DerivedClass::DerivedClass(mytype arg)
{
  // проверка аргументов
  // предварительный расчет общих значений для конструкторов, полей и проч.
  mytype1 v1 = Calculate1(arg);
  mytype2 v2 = Calculate2(arg);
  
 // инициализация базовых классов и полей (синтаксис условен)
 :BaseClass(arg, v1);
 :MyField1(arg, v1);
 :MyField2(arg, v1, v2);

 // дальнейшая инициализация
}

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

BZ>>для того, чтобы у тебя в шаблонах/макросах не появлялось многоэтажных сообщений об ошибках, нужна типизация. те самые концепты. без них что угодно можно подставить куда попало

BZ>>для отладки нужно дать отладчику инофрмацию о том какая строка сейчас выполняется и какие у нас есть переменные. а откуда она возьмётся, если текст подвергся обработке препроцессором? и получаешь ты то же самое, как при отладке в высокоуровневой программы на уровне ассемблера

VD>Обожаю теоретиков.

VD>Звучит все складно, как в пвсевдо-научных статьях, но с практиков не коррелирует.

ты внимательно прочёл? я сказал, что 1) нужна проверка типов. которой нет в шаблонах, а не Немерле. 2) что помимо проверки типов нужно много других вещей, которые опять же нужно программировать. к примеру поддержка номеров строк для отладчика

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

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

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

VD>Не не уйдет. Проблема в синтаксисе. Он неоднозначен и однозначность достигается уже смантическими средствами (анализом является ли идентификатор типом или нет). Учитывая что шаблоны разбираются только на уровне синтаксиса — эта проблема в С++ практически не устранима.

Ну вот в Clang (компилятор С++ под виртульную машину LLVM) вроде бы в отношении сообщений об ошибках много что сделано.
M>>Стандарт на объектные файлы.

VD>Их вообще надо убрать и заменить их на модули (компонентного типа как в Яве, Обероне или дотнете).

Кто как думает, плохо (хорошо, пофигу) ли , когда синтаксис неоднозначный.

Минус неоднозначностей в том, что сложнее писать компилятор.

Плюс в том, что пользователю не приходится думать за компилятор, чтобы определить, требуется ли ему подсказка или обойдется.
Код будет более аккуратным и не замусоренным ненужными конструкциями Пример

Автор: VladD2
Дата: 14.12.09

PS Я уже несколько дней думаю над тем, что же всё таки лучше — однозначный синтаксис или нет.

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

BZ>>новое — это хорошо разрекламированное старое синтаксические макросы хорошо известны с 60-х, как и их недостатки

VD>Если не изменяет память, макросы в Лиспе

http://en.wikipedia.org/wiki/General_purpose_macro_processor
http://ru.wikipedia.org/wiki/%D0%9F%D0%9B/1

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

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

ну да. ничего, что во время копиляции данных воемени выполнения ещё нет, так что тебе остаётся разве что сгенерить бесконечное число вариантов диспатченного кода

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

K>>А как совмещать продолжения и RAII?

VD>GC

gc не заменяет raii, поскольку не гарантирует вызов деструктора в детерминированный момент времени

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

Еще круто было бы иметь возможность отключить обязательность инициализированности полей.
Т.е. скажем, есть некий тип FieldType. У него есть конструктор с аргументами, которые обязательно
передавать для инициализации объекта. Ну или пусть даже для инициализации объекта ничего не нужно,
но инициализация присутствует.
Хочется, чтобы можно было бы объявить класс

class MyClass {
public:
 MyClass() {}
 ~MyClass();

 void f() {
  field.do_something();
 }

 void control(int control_code);
private:
 optional_initialization FieldType field;
 int state_code;
};

Здесь, благодаря ключевому слову optional_initialization, не требуется обязательно в конструкторе,
в списке инициализации, инициализировать field. Оно, может остаться неинициализированным.
И при уничтожении объекта, оно автоматически не уничтожится.
Но можно будет field ручками инициализировать через его конструктор, и ручками же уничтожить
(это может делать функция control()).
И в функциях различных, использовать его, разумеется обеспечив, что он существует.

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

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

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

Из него выкидывать надо, а не добавлять

C>Мне не так уж и много надо.

C>1. break [what]; continue [what];
C>возможность делать break(и continue) из любого скоупа, а не только цикла. Плюс параметризировать.
C>число говорит сколько скоупов оборвать, а назавание цыкла говорит какой первый встречающийся цикл оборвать. Через запятую перечисление последовательных обрывов.

Ну тогда уж лучше так:

l1: while( 1 )
    {
        if( something )
           break l1;
        do_something_else();
    }

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

BZ>ну да. ничего, что во время копиляции данных воемени выполнения ещё нет, так что тебе остаётся разве что сгенерить бесконечное число вариантов диспатченного кода

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

В общем, не стоит обсуждать то что не пробовал на практике.

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

BZ>>>новое — это хорошо разрекламированное старое синтаксические макросы хорошо известны с 60-х, как и их недостатки

VD>>Если не изменяет память, макросы в Лиспе

BZ>http://en.wikipedia.org/wiki/General_purpose_macro_processor

Ну, и причем тут текстовые макросы?

BZ>http://ru.wikipedia.org/wiki/%D0%9F%D0%9B/1

А это тут вообще причем?