Вот есть в DirectShow интерфейс IMediaSeeking, в нем 17 методов. Правила обработки для финального (render) фильтра предусматривают прозрачную передачу всех вызовов предыдущему фильтру. Только одно это требование предполагает тупое выписывание определений всех методов, с проверками и вызовами целевых, а при наличии макропроцессора их можно было бы свести в изящную таблицу, и генерировать и объявления, и определения, и вызовы методов по ней. Для фильтра с единственным входным пином можно было бы вообще использовать стандартные Base Classes, где все это уже когда-то трудолюбиво выписано.
Но самая задница в том, что у моего фильтра переменное и заранее неизвестное количество входных пинов, поэтому список предшествующих фильтров формируется динамически. Для каждого метода нужно пройти по всему списку, вызвать метод для каждого из фильтров, а возвращаемые значения проверять, чтобы вернуть из метода наиболее подходящее.
Так что для реализации требования нужно либо в реализацию каждого из методов вставить отдельный цикл со всей этой логикой, либо складывать параметры в объединение и передавать его переходнику, который уже организует цикл, в каждом проходе определит нужный метод, вызовет его с соответствующими параметрами, и выберет подходящее значение для возврата.
Ну не извращение ли — выписывать всю эту байду, пусть даже при наличии copy/paste, замены с регулярными выражениями и т.п.?
... ЕМ>Ну не извращение ли — выписывать всю эту байду, пусть даже при наличии copy/paste, замены с регулярными выражениями и т.п.?
Дык что мешает использовать сязыки типа lua или php для генерации кода? Там хоть 17 хоть 100500 методов, генерит быстро, единообразно и легко вносить изменения.
Здравствуйте, kov_serg, Вы писали:
_>Дык что мешает использовать сязыки типа lua или php для генерации кода?
Если б изрядная часть программы из такого состояла — пришлось бы. А для одно-двукратной реализации нелогично вводить отдельные сущности, проще руками, там потом и править ничего не нужно.
Я к тому, что в C++ подобные задачи возникают регулярно, а подходящего средства в языке и нет, и не планируется.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если б изрядная часть программы из такого состояла — пришлось бы. А для одно-двукратной реализации нелогично вводить отдельные сущности, проще руками, там потом и править ничего не нужно.
lua занимает 230кб, язык собирается прямо на месте из исходников. изменения вносить проче чем в midl компилятор.
ЕМ>Я к тому, что в C++ подобные задачи возникают регулярно, а подходящего средства в языке и нет, и не планируется.
Зачем себя ограничивать только одним языком?
ЕМ>Я к тому, что в C++ подобные задачи возникают регулярно, а подходящего средства в языке и нет, и не планируется.
Я даже больше скажу, еще 100500 других задач возникает регулярно, которые средствами языка решать неудобно. Предлагаю собрать тяжелый комбайн и засунуть его в язык и компиляторы.
Здравствуйте, Muxa, Вы писали:
M>Я даже больше скажу, еще 100500 других задач возникает регулярно, которые средствами языка решать неудобно. Предлагаю собрать тяжелый комбайн и засунуть его в язык и компиляторы.
Тяжелый комбайн — это излишество, а вот универсальный макропроцессор полезен в любом языке. Таблицы, перечисления, серийные конструкции, в которых меняются только параметры, встречаются почти в любой мало-мальски сложной программе. PL/1, при всей своей мощности, имел и макропроцессор тоже, причем весьма навороченный. А простой макропроцессор в реализации несложен.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да хоть бы и 10 кб. Все равно это дополнительная сущность.
Эта 1 сущность легко заменяет многие часы бестолковой копипасты.
_>>Зачем себя ограничивать только одним языком? ЕМ>Этак можно договориться и до того, что в любой язык нет смысла добавлять конструкции, которые нельзя сгенерить внешним препроцессором.
Так наоборот-же вместо использования "магии" для получения тривиальных вещей. Может имеет смысл использовать простые вещи для достижения поставленой задачи.