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

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

P>>Штатными средствами этого сделать нельзя. Я недавно сталкивался с подобной задачей и оказалось, что во всех необходимых мне компиляторах (GCC, MSVS) в реализациях STL указатели на внутренние данные std::vector находятся в секции protected, что позволило унаследоваться от std::vector и реализовать недостающий функционал в виде нового метода, тело которого индивидуально для каждого компилятора. Минус такого решения в том, что у вектора не виртуальный деструктор и по этому нужно следить за недопустимостью полиморфного удаления нового контейнера.

I>Если бы это был единственный или хотя бы главный минус! Твое решение привязано к конкретной версии библиотеки, тебе ведь два раза пришлось его писать, для GCC и для VC? И между прочим protected или нет, приципиальной роли не играет, с тем же успехом ты мог бы и private обойти; суть-то ведь одна: ты положился на внутренности реализации.

Обходить private — это слишком грязный хак, вместо которого правильнее было-бы написать свою реализацию. Да и постоянность private-компонентов никто не гарантирует.

Написать 2 раза по 10 строк это конечно существенный минус с точки зрения архитектуры(необходимо подстраиваться под компилятор,STL), но то, что в среднем дописывать код придется раз в ~15 лет полностью компенсирует данный недостаток. У меня основная платформа RedHat 4,5,6(в планах) и во всех перечисленных версиях необходимый protected-API std::vector'а одинаковый. А версия VC у меня одна — 2005 и в ближайшее время миграция на более новые не планируется.

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

P.S. Я всегда считал, что внутренняя реализация — это, то что находится в private, а protected только с очень большой натяжкой можно отнести к внутренней реализации, ведь protected-API напрямую доступно при наследовании. Или я не прав?