Здравствуйте, R.O. Prokopiev, Вы писали:


ROP>А если придется переходить на другую железку?
Эт совершенно маловероятно ...

C>>Из реального — мне очень понравился такой метод тестирования —
C>>дали проект , компилер и мсдн и попросили убрать при компиляции все ошибки и
C>>варнинги и сказать свое мнение по части пары классов ( после тестирования меня брали но на предыдущей работе перебили цену).
ROP>Если ищешь работу — ориентируйся не на те тесты, которые нравятся, а на те — которые популярны.
ROP>Вряд ли кто-нибудь будет использовать такой тест, не очень это серьёзно как-то.

Тут я думаю так — что это более реальный способ выяснить что человек знает не теоретически ...
и насколько быстро можно решить проблему первый раз с ней сталкиваясь ..
Там пришлось разгребать хитро...пые ошибки связанные с динамической линковкой длл (ну и не только )

Если немного усложнить тест и привнести багу — дать отладчик и исходники и посмотреть как человек найдет и как
решит — я думаю это покажет более реальные знания и умение обращаться с инструментами чем теоретические тесты ...
ИМХО конечно

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

S>Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...
А шаблоны, прям вот, не дополнительный?
Только труднее посмотреть "чего там нагенерилось и почему"

ИМХО это такой спциальный способ улучшить скилы в медитации...

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

А>По скорости пофиг. Зато как потом будет плеваться человек переделывая ваш код под std::list...
Почему так скромно? От чего не на XXX::BTree?

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

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

S>>Я имел ввиду, что кодогенератор — это тоже отдельный проект, который будет требовать написания, отладки, должной инсталляции и поддержки.
WH>А гора мутных меташаблонов которая очень медленно компилируется и выдает огромные и малопонятные сообщения об ошибках типа написания, отладки и поддержки не требует?
Сами шаблоны отлаживать нет смысла — они уже работают . К тому же, при не котором понимании, шаблоны перестают быть малопонятными.

WH>Про инсталяцию вобще не понял ибо кодогенератор работает на этапе сборки проекта.
Ну, дык, он должен стоять на компьютере каждого разработчика. Хотя, ИМХО, эту проблему я выдумал — можно положить в репозиторий.
Именно так работает у нас один кодогенератор (он правда, почему-то не OCaml-e ).
Правда там средствами языка было не обойтись — нужно генерировать параллельные структуры на C++ и C#.
А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.

WH>А гора мутных меташаблонов которая очень медленно компилируется и выдает огромные и малопонятные сообщения об ошибках типа написания, отладки и поддержки не требует?

Есть ли ссылка, где можно посмотреть на реальное использование кодогенератора (желательно для "чайников") или to google?

В RTEMS'e используется кодогенератор, только слишком все наворочено, чтобы с этого начинать.

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

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

S>>Вероятно. Но это дополнительный уровень косвенности. Его тоже надо отлаживать...
E>А шаблоны, прям вот, не дополнительный?
Под дополнительным уровнем косвенности я подразумевал дополнительное средство разработки.
Т.е. в добавок к компилятору появляется еще одно приложение, которое обрабатывает код.

E>Только труднее посмотреть "чего там нагенерилось и почему"
Некоторые вещи лучше не знать

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

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

S>Под дополнительным уровнем косвенности я подразумевал дополнительное средство разработки.
S>Т.е. в добавок к компилятору появляется еще одно приложение, которое обрабатывает код.

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

E>>Только труднее посмотреть "чего там нагенерилось и почему"
S>Некоторые вещи лучше не знать
Даже если надо отлаживать?

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

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

S>А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.
Не, ну если вы там медитацией наслаждаетесь, а от разработки простого довольно сишного проекта мучаетесь, и есть деньги на все эти удовольствия, то от чего бы и нет.

А если серьёзно, то свой кодогенератор имеет такое преимущество, что входной язык можно сделать весьма адекватным задаче, что позволит использовать на программировании "метакода" спецов в предметной области, а не в boost::mpl и продвинутых шаблонах C++. Например метакод можно локализовать, или вообще приделать визуальный редактор...

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

Нашел достаточно простой http://eao197.narod.ru/rucodegen/index.html от eao197

Напрашивается вопрос. Какова выгода от применения таких кодогенераторов, нужно метаязык этого генератора понимать

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

AP>Есть ли ссылка, где можно посмотреть на реальное использование кодогенератора (желательно для "чайников") или to google?

Насколько я понял речь шла о декларативном описании GUI, составленного из разнообразных компонент.
Смотри, например, как под классической MAC OS писался гуй под Powr Plant'ом.

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


S>Скилы в медитации, ИМХО, не так уж плохи . Не все же время молотком гвозди забивать.

Млин докопались до молотка
Чтобы было красивее могу выразить мысль по другому —
В Японии давным давно существовало масса школ кендо(исскуство обращения с мечом)
Все практиковали различные хитро...пые стили ведения боя .
Но одной из самых лучших школ была та (сча точно не скажу какая )- где в начале обучения сенсей говорил —
Не надо искать изощренных методов — когда перед тобой стоит противник , а у тебя в руках меч — убей его ...
Возможно я немного не досконально привел текст ... но мысль я думаю ясна .

Можно еще позаимствовать фразу у WolfHound точнее у Энштейна ...
(она мне нравиться даже больше чем предыдущее сравнение)
где то я ее уже упоминал на рсдн —

Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн

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

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

AP>>Есть ли ссылка, где можно посмотреть на реальное использование кодогенератора (желательно для "чайников") или to google?

E>Насколько я понял речь шла о декларативном описании GUI, составленного из разнообразных компонент.
E>Смотри, например, как под классической MAC OS писался гуй под Powr Plant'ом.
Спасибо.

А что можете сказать про embbeded системы? Про гуй и Power Plant почитаю на выходные.
Как использовать кодогенераторы для системных задач?

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

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

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

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

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

И еще вопрос.
Кто-нибудь использовал прождающее программирование?
Начинал читать книгу про это дело, но идет она тяжеловато.
Или это и есть применеие кодогенераторов?

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

E>А если серьёзно, то свой кодогенератор имеет такое преимущество, что входной язык можно сделать весьма адекватным задаче, что позволит использовать на программировании "метакода" спецов в предметной области, а не в boost::mpl и продвинутых шаблонах C++.
Весь метакод спрятан в макросы, так что непосредственно сложные mpl-ные шаблоны наружу не лезут.
Таким образом, можно человеку, плохо знающему шаблоны, просто сказать, что дык вот так записывается необходимый набор свойств.
Вот сюда писать интерфейсы. И т.п. Т.е. конечные пользователь может (в идеале) и не знать, что происходит внутри компилятора.

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

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

S>Сами шаблоны отлаживать нет смысла — они уже работают .
А это:

По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы

святой дух чтоли делает?

S>К тому же, при не котором понимании, шаблоны перестают быть малопонятными.
Меташоблонные извращения я знаю не хуже тебя.

S>Ну, дык, он должен стоять на компьютере каждого разработчика. Хотя, ИМХО, эту проблему я выдумал — можно положить в репозиторий.
Не можно, а нужно.
И не просто положить, а прописать в системе сборки чтобы она его собирала и если нужно запускала.

S>Именно так работает у нас один кодогенератор (он правда, почему-то не OCaml-e ).
Ну это уже извращения.

S>А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.
Кодогенераторы проще, гибче, быстрее, переносимее...

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

AP>А что можете сказать про embbeded системы? Про гуй и Power Plant почитаю на выходные.
AP>Как использовать кодогенераторы для системных задач?

У нас в конторе есть много кодогенераторов. Верне не так. Используется много входных языков, оптимизированных под какие-топрикладные задачи.
Обычно такое решение состоит из трёх частей.
1) Поддержка сгенерированного кода из C++
2) Собственно кодогенератор
3) Простая среда разработки/отладки (можно ME например использовать или VS закастомайзить)
Ну и справка ко всему этому.

Это позволяет заниматься разработкой текстов, на входном языке кодогенератора, людям, которые хорошо разбираются в вопросе, который прогается, а не в шаблонах там или кодогенераторах...

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

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

S>>Сами шаблоны отлаживать нет смысла — они уже работают .
WH>А это:
WH>

По этим данным строится state-машина (возможно многоуровневая), генериуется таблица переходов, происходит подписка на event-ы

WH>святой дух чтоли делает?
Это все уже внутри библиотеки делается. Конечному пользователю туда лезть незачем.

S>>К тому же, при не котором понимании, шаблоны перестают быть малопонятными.
WH>Меташоблонные извращения я знаю не хуже тебя.
Спорить не буду. Только интересно, откуда дровишки.. тьфу.. сведения?
Скорей всего ты знаешь даже лучше меня, ибо опыт у меня не большой. Но ИМХО, такие заявления бессодержательны.

S>>Ну, дык, он должен стоять на компьютере каждого разработчика. Хотя, ИМХО, эту проблему я выдумал — можно положить в репозиторий.
WH>Не можно, а нужно.
WH>И не просто положить, а прописать в системе сборки чтобы она его собирала и если нужно запускала.
Угу, согласен.

S>>Именно так работает у нас один кодогенератор (он правда, почему-то не OCaml-e ).
WH>Ну это уже извращения.
Почему? Парень набросал этот генератор за вечер. С тех пор и живем — забот не знаем.
Больше времени на разговоры потратили.

S>>А тут все можно решать средствами языка. Зачем мучаться с кодогенератором? ИМХО, это лишнее.
WH>Кодогенераторы проще, гибче, быстрее, переносимее...
В нашем случае о переносимости на другую операционку речи не идет (много COM-а).
К том уже, мы можем себе это позволить, ибо поставляем железо вместе с начинкой.
А под виндой, MSVC шаблоны и так прилично поддерживает.

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

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

AP>>А что можете сказать про embbeded системы? Про гуй и Power Plant почитаю на выходные.
AP>>Как использовать кодогенераторы для системных задач?

E>У нас в конторе есть много кодогенераторов. Верне не так. Используется много входных языков, оптимизированных под какие-топрикладные задачи.
E>Обычно такое решение состоит из трёх частей.
E>1) Поддержка сгенерированного кода из C++
E>2) Собственно кодогенератор
E>3) Простая среда разработки/отладки (можно ME например использовать или VS закастомайзить)
E>Ну и справка ко всему этому.

E>Это позволяет заниматься разработкой текстов, на входном языке кодогенератора, людям, которые хорошо разбираются в вопросе, который прогается, а не в шаблонах там или кодогенераторах...

E>Ну и поддержка сильно удешевляется, так как хорош разграничены зоны ответсвенности и компетенции...
Хорошо вам. Сильно на системы с Лиспом смахивает.