Контейнер из подручных средств

[Old]

Можно специализировать getter_helper под различные пользоваткльские типы и дёргать его из функции:

Знаете что не нравиться: для каждого типа может быть только один хелпер. Например, для QPoint нельзя в одном случае считать по x, а в другом по y.

[kambala]

такое вообще бывает в нединамических языках? (ну кроме switch-enum подхода)

Не понял, что "бывает"? В смысле десятки ф-ций работающих с одним контейнером? Да, конечно

нет, чтобы

сосредоточить весь новый код в том что "подается на вход GetMaxNegative"

в objc с его «магией рантайма» я еще могу представить как это сделать, но в ++... вариант с лямбдами/функторами кажется вполне естественным.

[Igors]

... вариант с лямбдами/функторами кажется вполне естественным.

Пока одна содержательная/рабочая ф-ция - все хорошо.

Код

C++ (Qt)
getMaxNegative<double>( p.begin(), p.end(), []( const Point &v ){ return v.x; } )

Но беда в том что так придется писать для КАЖДОЙ рабочей ф-ции, напр

Код

C++ (Qt)
getMinPositive<double>( p.begin(), p.end(), []( const Point &v ){ return v.x; } )

А как только объявится еще "виртуальный контейнер" (хотя бы "y" вместо "x") - опять все для КАЖДОЙ

в objc с его «магией рантайма» я еще могу представить как это сделать, но в ++...

Шо за пессимизм? 

Стремиться, имхо, надо к следующему:

Код

C++ (Qt)
template <class T>
int GetVectorValue(const T & vec, int index) const
{
    return vec[index];
}
 
...
 

Таким образом через параметры можно передать и вектор, и функтор для доступа к нему (если базовый не подходит).

Не вкурил, можно подробнее? Как (или куда) пристраивать написанное?

[kambala]

ну так идентичные лямбды делаются обычными функциями.

а если передавать в качестве параметра GetMaxNegative() еще и указатель на метод элемента контейнера?

[m_ax]

Так мне кажется логичнее, но зачем нам засорять код рабочих ф-ций каким-то getter_helper'ом ? Почему не так

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

Знаете что не нравиться: для каждого типа может быть только один хелпер. Например, для QPoint нельзя в одном случае считать по x, а в другом по y.

Согласен) Можно ещё один шаблон добавить, который уже ракзличные стратегии определяет для данного типа..

Хотя я бы с лямбдами сделал и не запаривался)

[Igors]

ну так идентичные лямбды делаются обычными функциями.

а если передавать в качестве параметра GetMaxNegative() еще и указатель на метод элемента контейнера?

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

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

В исходном примере возвращаемое значение int (конкретный тип), т.е. меня не интересует что-то другое, нет планов адаптировать под double или еще что.

Вопрос был в том что исходные (хранимые) значения сами могут и не находиться в классе-контейнере, но для них существует ф-ционал:

- счетчик (число эл-тов)
- доступ к значению по индексу

Ну как бы "виртуальный контейнер" прямого доступа

[Racheengel]

Не вкурил, можно подробнее? Как (или куда) пристраивать написанное?

Вторым параметром при необходимости (F* fvec):

template <class T, class F = GetVectorValue>
int GetMaxNegative( const T & vec, F* fvec  )

Примерно как:

GetMaxNegative(myVector, myFVector);

myFVector должен быть, соответвенно, заточен на обработку myVector.
Каждый раз для получения index элемента вектора будет вызвано myFVector ->GetVectorValue(myVector, index);

[Igors]

Вторым параметром при необходимости (F* fvec):

template <class T, class F = GetVectorValue>
int GetMaxNegative( const T & vec, F* fvec  )

Понял, спасибо. Это близко к предложенным вариантам, но кажется мне поудобнее. Все же "вживление" специального геттера... Ведь следом за ним неизбежно последует сеттер. Зачем мы таким образом достигаем ф-ционала оператора [], не лучше ли перекрывать его если требуется ?

[Racheengel]

Ну а как без геттера? Ведь вектор уже имеет собственный оператор [], речь о том, чтобы специализировать "результат" оператора [].
Например, vec.x(), или vec.y() и т.д. - тут надо ж как-то явно указывать, что именно вам нужно.

[m_ax]

Вопрос был в том что исходные (хранимые) значения сами могут и не находиться в классе-контейнере, но для них существует ф-ционал:

- счетчик (число эл-тов)
- доступ к значению по индексу

Ну как бы "виртуальный контейнер" прямого доступа

Т.е. предлагаете свой враппер писать под контейнер? Не совсем понимаю, чем это лучше специализации для геттера? В подходе с геттером гибкости больше: появилась потребность обращаться, например к point.y() - написали отдельную специализацию и т.д.. И от типа контейнера можно абстрогироваться (не обязательно по индексу обращаться к элементу)..