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

J>Например, std::vector<T, A> вполне мог бы предоставлять интерфейс std::fixed_capacity_vector<T>, который не зависит от А и способен менять размеры в рамках своей capacity.
Маленькое уточнение: на аллокаторе не только выделение памяти, но и разрушение объекта.

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

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

J>>Например, std::vector<T, A> вполне мог бы предоставлять интерфейс std::fixed_capacity_vector<T>, который не зависит от А и способен менять размеры в рамках своей capacity.
F>Маленькое уточнение: на аллокаторе не только выделение памяти, но и разрушение объекта.

В смысле? Он, разве, не просто деструктор элемента зовет? (это я не спорю, просто лень в стандарт лезть)

You will always get what you always got
  If you always do  what you always did

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

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

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

T>>>Привет всем,

T>>>Хочу понять, в чём различие и когда стоить выбирать один из следующих подходов для реализации настраиваемых стратегий/политик в классе:
T>>>Допустим, стратегия задаётся для экземпляра класса один раз и не меняется во время исполнения.

S>>ты сам почти ответил на свой вопрос:
S>>runtime — динамический полиморфизм ( в твоем случае интерфейсы, но можно и по другому ), очевидно, имеет некоторый performance impact
S>>compile time — статический полиморфизм ( в твоем случае шаблоны, но можно и по другому )

T>Ну то есть в такой ситуации дефолтное решение — использовать шаблоны? (результат тот же, а выполняется на сколько-то быстрей)
T>Я хочу, чтобы получилась какая-то картинка с плюсами и минусами различных решений.

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

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

J>В смысле? Он, разве, не просто деструктор элемента зовет? (это я не спорю, просто лень в стандарт лезть)
Непонятно, может ли быть здесь дополнительное поведение у своего аллокатора, или всё строго:

template <class U>
void destroy(U* p);

Effects: p->˜U()

http://en.cppreference.com/w/cpp/memory/allocator/destroy

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

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

J>>В смысле? Он, разве, не просто деструктор элемента зовет? (это я не спорю, просто лень в стандарт лезть)
F>Непонятно, может ли быть здесь дополнительное поведение у своего аллокатора

Похоже, может.
Это новости в С++11, при Гейтсе раньше такого не было, а теперь вот так [container.requirements.general]:

For the components affected by this subclause that declare an allocator_type, objects stored in these components shall be constructed using the allocator_traits<allocator_type>::construct function and destroyed using the allocator_traits<allocator_type>::destroy function (20.7.8.2).

Так что получается, что с С++11 невозможно отвязать от аллокатора подынтерфейс, который может создавать/убивать объекты, даже если реаллокации не требуется.
Остается только подынтерфейс для неизменного размера — это итераторы.

(Это верно только для std-контейнеров с аллокатором, ессно. Для своих можно что угодно делать. — Это предвосхищая выступление Егора )

You will always get what you always got
  If you always do  what you always did

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

J>А меня не устраивают виртуальные вызовы, я хочу, чтобы все было заинлайнено по максимуму

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

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

T>Ну то есть в такой ситуации дефолтное решение — использовать шаблоны? (результат тот же, а выполняется на сколько-то быстрей)
T>Я хочу, чтобы получилась какая-то картинка с плюсами и минусами различных решений.

У шаблонов С++ есть такая беда, что формально интерфейс не задан и не проверяется.
Например, можно что-нибудь специализировать, а потом, клиентский код не переживёт правки во фреймворке...

так что если типы совпадают, а скорость не важна, то дефолтное, скорее через динамический полиморфизм...

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

T>Ну наверно можно как-то написать шаблонную f(), которая будет принимать что-то, ведущее себя как vector<int> (а не vector<double>)?
T>Но даже если можно, это здорово всё усложнит наверно.

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

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

T>

T>fac = new Klass<A1, B2, C3>()
T>

T>?

Часто такое сочетание не имеет смысла.
Например "1" может означать "готов к многопотчному окружению", а "2" -- "не готов".
Ну и сочетание A1, B1, C2 не имеет смысла, соответственно...