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

Вау! Так у вас там ещё и макросы наверчены!!! Круть!!!

S>Таким образом, можно человеку, плохо знающему шаблоны, просто сказать, что дык вот так записывается необходимый набор свойств.
S>Вот сюда писать интерфейсы. И т.п. Т.е. конечные пользователь может (в идеале) и не знать, что происходит внутри компилятора.

Ну и он где-то чего-то не так напишет и дальше все пытаются понять что за фигня случилась.
Был у меня например один проект, где надо было описывать какие-то хитрые лингвистические конструкции, сначала это сделали на макросах, как ты и описал примерно. Только без шаблонов. Ну был там такой лиспоподобный уродский относительно синтаксис описателей, посадили спеца писать эти описания. Ну писал он их, получалочсь через раз. Он даже научился отлаживать большинство ошибок компиляции, но семантические ошибки уже не понимал как находить. Ему же его сложную довольно метапрограмму надо было отлаживать!!!
Так что её отлаживал я
Когда меня это допекло (проект было очень низкоприоритетный), я таки сделал довольно простой кодогенератор, и две версии C++ интерпретатора. Во второй омжно было записывать дебажную информацию.
Соответсвенно, кодогенератор стал выдавать все ошибки связанные с несовместностью заданного описания, а дебажная версия кода (включалось флажком в генераторе) ещё и описывало дебажную инфу о сбое, в отдельном окошке. И всё, после этого я поправил там две ошибки. Специалист всё сделал сам

E>>Например метакод можно локализовать, или вообще приделать визуальный редактор...
S>Визуальный редактор, это хорошо. Мы об этом думали. Эту проблему можно решить и без кодогенератора.
S>Опять же редактор просто расставляет необходимые макросы по "галочкам". И все.
Ну да, но редактор может расставлять и "просто С++ классы" ничуть не хуже

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

E>>Ну компилятор C++ + boost::mpl -- это тоже подобное приложение. Только не очень удобное, как в работе, та ки в отладке.
S>Это так же относится и к кодогенератору.
Не, ну это уже как напишите

E>>>>Только труднее посмотреть "чего там нагенерилось и почему"
S>>>Некоторые вещи лучше не знать
E>>Даже если надо отлаживать?
S>А чего там отлаживать? Клиентский код остается без изменения. Отлаживайте сколько хотите.
S>А сами шаблоны отлаживать не нужно. Компилятся, значит работают. Функциональное программирование, однако.
Ну а там вот ты описывал сложные всякие конструёвины, которые рожаются всей этой хреновиной. Вот если "а включаешь -- не работает", что происходит дальше?

S>Да ладно, эта система позволяет очень быстро реализовать новый тип объектов на основе существующих "кубиков".
А если что-то сразу не складывается, то что происходит?...

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

S>Хорошо вам. Сильно на системы с Лиспом смахивает.
Нет. Чистый C++
Ну вам тоже могло бы быть хорошо, если бы вы не mpl пользовались, а удобный визуальный редакор заботали

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

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

E>Вау! Так у вас там ещё и макросы наверчены!!! Круть!!!
ИМХО, ничего страшного в них нет, если они не заменяют функцию, а позволяют декларировать некоторые свойства.
Вроде THIS_CLASS_IS_POD(SomeStruct).

S>>Таким образом, можно человеку, плохо знающему шаблоны, просто сказать, что дык вот так записывается необходимый набор свойств.
S>>Вот сюда писать интерфейсы. И т.п. Т.е. конечные пользователь может (в идеале) и не знать, что происходит внутри компилятора.
E>Ну и он где-то чего-то не так напишет и дальше все пытаются понять что за фигня случилась.
Возможно. В данном случае помогают осмысленные static-assert-ы.

E>Был у меня например один проект, где надо было описывать какие-то хитрые лингвистические конструкции, сначала это сделали на макросах, как ты и описал примерно. Только без шаблонов. Ну был там такой лиспоподобный уродский относительно синтаксис описателей, посадили спеца писать эти описания. Ну писал он их, получалочсь через раз. Он даже научился отлаживать большинство ошибок компиляции, но семантические ошибки уже не понимал как находить. Ему же его сложную довольно метапрограмму надо было отлаживать!!!
E>Так что её отлаживал я
E>Когда меня это допекло (проект было очень низкоприоритетный), я таки сделал довольно простой кодогенератор, и две версии C++ интерпретатора.
Две версии интерпретатора С++?

E>>>Например метакод можно локализовать, или вообще приделать визуальный редактор...
S>>Визуальный редактор, это хорошо. Мы об этом думали. Эту проблему можно решить и без кодогенератора.
S>>Опять же редактор просто расставляет необходимые макросы по "галочкам". И все.
E>Ну да, но редактор может расставлять и "просто С++ классы" ничуть не хуже
Но тогда придется программировать то, что уже есть в компиляторе C++.

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

S>Это все уже внутри библиотеки делается. Конечному пользователю туда лезть незачем.
Ну и в кодогенератор ему лезть незачем.

S>Почему? Парень набросал этот генератор за вечер. С тех пор и живем — забот не знаем.
S>Больше времени на разговоры потратили.
А нафига сюда еще и OCaml тащить?
Его же отдельно ставить надо.

WH>>Кодогенераторы проще, гибче, быстрее, переносимее...
S>В нашем случае о переносимости на другую операционку речи не идет (много COM-а).
Видишь только то что хочешь? А как насчет остального?

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

E>Вау! Так у вас там ещё и макросы наверчены!!! Круть!!!
Ну квадратные глаза делать не стоит.
Даже плюсовые макросы и шаблоны в определенных рамках работают лучше внешних кодогенераторов. (А если писать на немерле... то про внешние кодогенераторы вобще можно забыть )
Например я кроме конкретного кода генерирую кучу вызовов макросов (таким образом генерируемый код получается сильно читабельнее).
А еще я генерирую 2 макроса которые дергаю из рукописного кода.
Да и в качестве входного языка я использую код на С++... кодогенератор выцепляет вызовы некоторых макросов и на информации полученой из иргументов макросов генерит код.

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

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

E>>>Ну компилятор C++ + boost::mpl -- это тоже подобное приложение. Только не очень удобное, как в работе, та ки в отладке.
S>>Это так же относится и к кодогенератору.
E>Не, ну это уже как напишите
Согласен. Тут уже вопрос сколько на это сил уйдет.

E>>>>>Только труднее посмотреть "чего там нагенерилось и почему"
S>>>>Некоторые вещи лучше не знать
E>>>Даже если надо отлаживать?
S>>А чего там отлаживать? Клиентский код остается без изменения. Отлаживайте сколько хотите.
S>>А сами шаблоны отлаживать не нужно. Компилятся, значит работают. Функциональное программирование, однако.
E>Ну а там вот ты описывал сложные всякие конструёвины, которые рожаются всей этой хреновиной. Вот если "а включаешь -- не работает", что происходит дальше?
А что ты делаешь, если "а включаешь -- не работает". Отладчик в руки и вперед.
А есть другие способы? Кодогенератор это тоже как-то решает? Может в нем искуственный интеллект есть, и он пишет
"Упс. А вот тут вы в некоторых случаях за границу выйдите... А тут меморилик. А если здесь эксепшн отловить, то вообще все хорошо будет.."
Если так, то я преклоняюсь

S>>Да ладно, эта система позволяет очень быстро реализовать новый тип объектов на основе существующих "кубиков".
E>А если что-то сразу не складывается, то что происходит?...
Сообщение об ошибке. Это же, в конце концов, код.
А если кодогенератор сгенерит что-то, что не компилируется. Что происходит?

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

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

S>>Хорошо вам. Сильно на системы с Лиспом смахивает.
E>Нет. Чистый C++
E>Ну вам тоже могло бы быть хорошо, если бы вы не mpl пользовались, а удобный визуальный редакор заботали
А кто сказал, что нам плохо. И редактор прикрутить не проблема. Только вот на это время нужно.

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

S>Две версии интерпретатора С++?
Со стороны C++ была некоторая система калссов, которая использовала это лингвистическое описание. Её я и назвал словом "интерпретатор".
Сначала интерпретатор был устроен так, что макросами генерировалась некоторая статическая таблица, по которой он потом и работал.
Потом я переделал так, что кодогенератор генерил некий код, собираемый из примитивов, который собственно и являлась кодом интерпретатора, но примитивы всё равно опирались на некий фреймворк. Так вот можно было привлечь фреймворк и фреймворкExt, второе случалось, если ты в примитивах указывал отладочную информацию...

E>>Ну да, но редактор может расставлять и "просто С++ классы" ничуть не хуже
S>Но тогда придется программировать то, что уже есть в компиляторе C++.
Это опять же зависит от того, что и как вы напишите.
Я так понимаю, что вы декларируете какой-то набор свойств, по которому строите какой-то конечный автомат, который и используется в дальнейшей работе. Так вот, мне кажется что стрить автомат и проверять его корректность удоьнее не из CT-шаблонов, а простым и ясным C++ кодом. И проверки просто записывать и генерировать всё удобно и представление данных можно какое хочешь выбрать...

Ну а потом, эту готовую структуру, надо отобразить в C++ код, я так понимаю. Соответсвенно тут всё упирается в ваш "интерпретатор" ( (с) см. выше ). ИМХО если написать его прямо, то превратить структуру объектов в С++ код должно быть довольно просто.

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

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

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

S>>Это все уже внутри библиотеки делается. Конечному пользователю туда лезть незачем.
WH>Ну и в кодогенератор ему лезть незачем.
Дык и хорошо. Кто спорит.

WH>А нафига сюда еще и OCaml тащить?
WH>Его же отдельно ставить надо.
Не надо его ставить. Положил exe-шник в репозиторий и ок.

WH>>>Кодогенераторы проще, гибче, быстрее, переносимее...
S>>В нашем случае о переносимости на другую операционку речи не идет (много COM-а).
WH>Видишь только то что хочешь? А как насчет остального?
О простоте: Кодогенератор — это отдельный проект.
Хороший кодогенератор, который умеет делать хотябы половину того, что умеет mpl надо писать и отлаживать.
А mpl — прикрутил и вперед. Собственно сама библиотека — десяток хедеров.
Если о простоте использования, то кодогенератор должен иметь какой-то описательный язык.
Все сложные констуёвины можно обернуть в макросы. И таким образом тоже получаем свой язык.
Удобство одинаково. Единственное, что кодогенератор может в принципе использовать любой извращенный язык,
а в нашем случае — все ограничивается макросами. Да и по барабану.

Про гибкость — в чем она? В любом случае каждая новая фича требует изменения кодогенератора.

Про скорость — возможно, если в смысле компиляции. Но это не первоочередной фактор.

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

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

S>Если так, то я преклоняюсь
Ну в некоторых таки есть
Но вообще-то всё просто. Насколько я понял у вас есть метапрограмма, написанная на входном языке кодогенератора и собственно реализация, которая превращает эту метапрограмму в C++ код, который и работает. То есть это некий фреймворк + собственно нагенерированный код.
В случае кодогенераторов обычно делают так, что ошибки в метапрограмме приводят либо к тому, что она не компилируется, либо к тому, что результат компиляции не работает, но выдаёт диагностику в терминах метапрограммы (ну типа там такое-то свойство противоречит такому-то, или операция провалилась, потому что вот тут у вас логическое противоречие выплыло).
А в случае ошибки во фреймворке, то всё как обычно, assert'ы там, проверки...

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

А у вас как всё происходит?

E>>А если что-то сразу не складывается, то что происходит?...
S>Сообщение об ошибке. Это же, в конце концов, код.
Очень хорошо. Вот я пользователь. Вот у меня не скопилировалось и я получил какой-то бесконечный отчёт о шаблонных подстановках где что-то с чем-то не склеелось.
Заметь, что писал я при этом какие-то макросы, про которые даже не знал это макросы...
Как мне хотя бы понять. Это у меня ошибка или у вас?

S>А если кодогенератор сгенерит что-то, что не компилируется. Что происходит?
А если кодогенератор генерит то, что не компилируется, то авторы кодогенератора ищут у себя ошибку

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

S>+ к этому у нас есть проект на boost::mpl. Там все на шаблонах .

А можешь выдержками поделиться? Хочется почувствовать: каково это — всё на шаблонах, тем более — всё на mpl.

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

К>А можешь выдержками поделиться? Хочется почувствовать: каково это — всё на шаблонах, тем более — всё на mpl.
В одном можно быть уверенным -- компилируется очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень очень долго

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

S>О простоте: Кодогенератор — это отдельный проект.
И?
S>Хороший кодогенератор, который умеет делать хотябы половину того, что умеет mpl надо писать и отлаживать.
Кодогенератор не должен уметь делать весь этот бред что делает boost::mpl.
Оно ему не надо!
Кодогенератор должен генерить код.

S>А mpl — прикрутил и вперед.
Пить чай пока это все скомпилится...

S>Про гибкость — в чем она?
Попробуй на шаблонах реализовать алгоритм поиска кратчайших путей в ориентированном графе от каждой вершины до каждой.
Вершин в графе больше 20...
В кодогенароторе я просто реализовал алгоритм Алгоритм Флойда-Уоршолла.
Работает мнгновенно.

S>В любом случае каждая новая фича требует изменения кодогенератора.
В любом случае каждая новая фича требует изменения шаблонов.

S>Про скорость — возможно, если в смысле компиляции. Но это не первоочередной фактор.
Лично мне очень не нравится когда проект компилируется часами.

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

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

S>>О простоте: Кодогенератор — это отдельный проект.
WH>И?
Отдельный проект => дополнительный геморрой. ИМХО.

S>>Хороший кодогенератор, который умеет делать хотябы половину того, что умеет mpl надо писать и отлаживать.
WH>Кодогенератор не должен уметь делать весь этот бред что делает boost::mpl.
WH>Оно ему не надо!
WH>Кодогенератор должен генерить код.
А что тогда он должен делать? mpl умеет жонглировать шаблонами классов.
А что тогда должен делать генератор? Просто генерировать код? А зависимости, статические проверки и т.п.?

S>>А mpl — прикрутил и вперед.
WH>Пить чай пока это все скомпилится...
Ну, в действительности у страха глаза велики. Не так уж и долго. В проекте ~50 объектов.
Компилится он минут 5. Не так уж и страшно. К тому же мы планируем его разделить => ускорим билд.

S>>Про гибкость — в чем она?
WH>Попробуй на шаблонах реализовать алгоритм поиска кратчайших путей в ориентированном графе от каждой вершины до каждой.
WH>Вершин в графе больше 20...
WH>В кодогенароторе я просто реализовал алгоритм Алгоритм Флойда-Уоршолла.
WH>Работает мнгновенно.
Охренеть. Наверное, в кодогенераторе можно подключиться к удаленному серверу и залить оттуда последний snapshot какой-нибудь библиотеки.
Или просчитать траекторию полета крылатой ракеты в условиях семибального шторма. Только мне все это не нужно.
Ты правильно сказал, генератор должен генерить код. Максимум, что мне нужно — операции над последовательностями.
К примеру, есть набор классов V. От этих классов средствами mpl получаем производный класс C.
Теперь мне нужно выбрать из V те классы, которые имеют функцию F и вызвать её в определенный момент у объекта класса C.
Для этого надо скастить этот объект ко всем базам, имеющим эту функцию и вызвать её.
По хорошему, ничего кроме итераторов, for_each, copy, transform, filter, foldr и т.п. не нужно.

S>>В любом случае каждая новая фича требует изменения кодогенератора.
WH>В любом случае каждая новая фича требует изменения шаблонов.
Согласен. Т.е. шаблоны не хуже.

S>>Про скорость — возможно, если в смысле компиляции. Но это не первоочередной фактор.
WH>Лично мне очень не нравится когда проект компилируется часами.
Выше я уже высказался по этому поводу.

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

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

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

Я хочу еще раз подчеркнуть, что я не имею ничего против кодогенераторов. Просто я считаю что путь с mpl тоже имеет право на существование.

E>Соответсвенно автор метапргораммы (видимо пользователь вашей библиотеки) пишет её, компилит, пока не скомпилит в С++ (уже на этом этапе можно отловить много логических ошибок), потом компилит до исполняемого кода и отлаживает. При этом пока он отлаживает свои ошибки он получает сообщения о них в терминах своей метапрограммы и думает сам. А как только добирается до ваших получает в терминах "внутренняя ошибка" и обращается к вам...

E>А у вас как всё происходит?
Все просто. Если программист набирает класс из уже существующих кубиков, то он может получить ошибки вроде: у этого класса должна быть такая функция или этот класс не может быть вместе с этим. Если он пишет некоторые кубики сам, то ему приходится так же отловить ошибки вроде невозможно сконвертить std::string к char const * и т.п. Я согласен, что все это не идеально. Но тем не менее работает.
Скорей всего дело упрощается тем, что у нас все разработчики — программисты
(нет экспертов, которые непосредственно пишут код (в этом проекте конкретно)).

E>>>А если что-то сразу не складывается, то что происходит?...
S>>Сообщение об ошибке. Это же, в конце концов, код.
E>Очень хорошо. Вот я пользователь. Вот у меня не скопилировалось и я получил какой-то бесконечный отчёт о шаблонных подстановках где что-то с чем-то не склеелось.
E>Заметь, что писал я при этом какие-то макросы, про которые даже не знал это макросы...
E>Как мне хотя бы понять. Это у меня ошибка или у вас?
Если static assert — значет ваша. Если нет — значит наша. По крайней мере, в идеале .

S>>А если кодогенератор сгенерит что-то, что не компилируется. Что происходит?
E>А если кодогенератор генерит то, что не компилируется, то авторы кодогенератора ищут у себя ошибку
Анологично .

А>>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
E>Почему так скромно? От чего не на XXX::BTree?
МОжно нескрномный вопрос? Вы в проектах>10 человек и длительнотью >1 Года принимали участие? Буквально сегодня перелопатил в целях оптимизации std::vector на std::set в одном месте.

sux>з.ы. а еще круто бы сделать подпись внизу ваши постов о величестве спирита, дабы поломники стекались со вего мира поклониться "великому и ужасному"!

К доктору не пробовали обращатся?

C>Опровергать не буду ... но ... есть некоторые замечания -

C>эффективность — почему в примере он использует для проверки последнего элемента функцию end()
Эта функция — inline. И во многих реализациях STL представляет собой указатель за элемент после последнего. И проход по вектору итераторами равносилен написанию след Сшного кода по скорости:

int arr[256];
for(int *p=&arr[0];p!=&arr[255];p++)
{
*p = 10;
}

А с индексами вы делаете так:
for(int i=0;i<255;i++)
{
p[i] = 10;
}

C>почему бы не объявить vector<blblabla>::interator end = vec.end();
Потому что vec.end() и так развернется к обращению к одному элементу структуры.

carpenter wrote:
>
>
> 1.Неужели в реальном программинге так часто используються шаблоны?
Да, часто жуть как удобно.

>
> 2.Кросплатформенность – опять тотже вопрос – неужели так много народу
> пишет на С++ кросплатформенные приложения , которые еще вдобавок должны
> компилиться любыми компиляторами под любые операционки и под любые
> архитектуры процессоров?
По опыту, если приложение писалось кроссплатформенно, то работает оно
обычно с сильно меньшим количеством багов.
> Хотите кросплатформенности — пишите на жабе — в чем проблемы ?
И пишут. Зависит от задачи.

>
> 3.Алгоритмы — ( у меня лично есть небольшие недостатки по мат анализу
> алгоритмов , но да суть не в этом) . В вышеупомянутом посте функция
> подсчета битов — она же подсчитывает (что еще надо?) ...
А вот это нужно уже сильно реже.

>
> 4. По поводу ошибок в написании — я вообще с первого раза не пишу правильно
> чтобы скомпилилось (я не имею в виду что нибудь типа а++; а так — 20-30
> строк)( а Вы ?) . Сначала набрасываю основную идею , а потом под
> отладчиком дошлифовываю.
Это нормально.

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

>
> Из последнего собеседования — думаю большинство знает как выяснить —
> являеться ли переменная степенью двойки (имееться в виду быстрый алгоритм
> if(i & (i-1)) но если нет — реально ли до этого дотумкать в течении пары
> минут ?
Ну а это очередной бессмысленный вопрос. Можно еще открыть
"Занимательные задачи" того же Перельмана и соискателей этим доставать.