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

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

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

Условия задачи:

•  Нет груза наследия прошлого в виде уже имеющихся проектов.
•  Код нужно писать исключительно на С++.
•  Производительность кода имеет значение.

Суть задачи:
  Придумать способ обработки ошибок в коде класса парсера CustomFormatParser и при этом дать возможность пользователю класса влиять на выбор стратегии обработки, одну из следующих двух:

•  По умолчанию при обнаружении ошибки бросается исключение
•  При обнаружении ошибки операция завершается, но информация о типе ошибки сохраняется с возможностью дальнейшего ее получения

Мои мысли привели к тому что :
  Надо реализовывать Event-driven , т.е. вариант обработки ошибки с использованием callback-функции в качестве обработчика ошибки.
Реализовать обработчик ошибки по умолчанию, задаваемый в конструкторе класса парсера как параметр по умолчанию. Затем в коде класса парсера вызывается обработчик ошибки, который задан по умолчанию или реализован и передан пользователем в параметре конструктора. Этот обработчик возвращает статус : "продолжить работу дальше или нет?" имея подобный ответ мы либо бросаем исключение, либо продолжаем работу парсера дальше, но запоминаем информацию об ошибке.

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

EvilsInterrupt, 

диктуется объективными причинами, или это просто желание сделать в более общем виде?

Диктуется причинами. Чаще пишу такие типы приложений когда работа с попорченным файлом не имеет смысла. Но есть и другие типы приложений, которые анализируют и выдают информацию о файле им-то как раз и нужно чтобы приложение работало дальше даже с попорченным файлом

это если простой вариант с возвращением статуса окончания операции не подходит.


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

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

Это сообщение отредактировал(а) mes - 27.12.2012, 21:13