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

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

VEC>>Здравствуйте, enji, Вы писали:
E>>>int Storage_IReader::SetPosition(size_t pos) { return static_cast<Storage*>(this)->setPosition_read(pos); }

VEC>>Жуть какая
E>Чего ж тут такого жуткого? Обычный передаточный метод, после встраивания накладных расходов не будет.

VEC>>Вариант с инлайном в базовых IReader/IWriter (приведенный выше) мне больше понравился
E>А что за метод такой и чем он тебе может помочь? Насколько я понимаю, в плюсах нельзя указать, метод какого класса ты перекрываешь, так что если у тебя в базовых классах совпадают названия и сигнатуры виртуальных методов, то решения два — или (как тебе сказал Егор выше) NVI или прокси (у меня — статический, у Кодта — динамический)

Тот, который NVI, удобен. Схожий метод я рассматривал с самого начала под п.3
Нарыл его где-то на просторах IBM или MSDN, не вспомню.
От реализации Кодта принципиальных отличий в Вашем решении не вижу, если честно: и там, и там вводится промежуточный класс (прокси), который перенаправляет вызовы к закрытой/защищенной функции, реализация которой отличается. Не углубляясь в подробности нашего решения, несмотря на годность ответа к заданному вопросу, подобный метод не совсем подходит.
Ничем не хуже выглядит определить в заголовке inline-методы IReader::SetPosition/IWriter::SetPosition, перенаправляющие вызов на конкретные закрытые реализации, в самом Storage (п.3).

Уже нарыли сами тут, что стандарт действительно не поддерживает желаемого изначально извращения, т.ч. пришлось-таки "перефигачивать" немножко.
Заметным ограничением выступает Coding Style/Guidelines, принятый командой, — не определять функций в объявлениях интерфейсов (в заголовках, впрочем, тоже).