Как определить тип функции для шаблона?

Question

[yatanai]

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

template<class C>
class property : public C
{
public:
    property& operator= (decltype(C::n) arg)
    {
        this->Setter(arg);
        return *this;
    }
    operator decltype(C::n)()
    {
        return this->Getter();
    }
};
class Test 
{
protected:
    int Getter()
    {
        std::cout << ("GET\n");
        return n;
    }
    void Setter(int arg)
    {
        std::cout << ("SET\n");
        n = arg;
    }
    int n;
};
int main()
{
    property<Test> x;
    x = 10;
    std::cout << "Hello World! << "<< x << "\n";
}

Как убрать "int n"? Исходя из дальнейшей идеи я думал что можно взять тип из функции геттера, но при написании "decltype(С::Getter)" и подобных компилятор ругался что так делать нельзя.
А как мне избавится от грёбаннного "int n"???
(Мимо 3:30 "ночи")

Comments

[Евгений Шатунов]

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

Так и тут. Где конкретно находится этот int n? Я пока только одно место вижу и оно не в шаблоне, поэтому я пока тебя не понимаю.

class property : public C, а если у C этих property 50+ штук? Реальный пример, для одного из типов у меня порядка 60 свойств определено.

Тебе не нравится использование decltype(C::n) в шаблоне?

Answer 1

[Александр Прилепский]

Коль речь идет о шаблонах и желательно избавиться от int, не лучше ли воспользоваться шаблоном?

template <class T, template <typename> class mc>
class property : public mc<T> {
public:
    property& operator= (T arg)  {
        this->Setter(arg);
        return *this;
    }
    operator T() {
        return this->Getter();
    }
};

template<class T>
class Test {
protected:
    T Getter() {
        std::cout << ("GET\n");
        return n;
    }
    void Setter(T arg) {
        std::cout << ("SET\n");
        n = arg;
    }
    T n;
};

int main() {
    property<int, Test> x;
    x = 10;
    std::cout << "Hello World! << "<< x << "\n";
    
    property<float, Test> y;
    y = 5.3f;
    std::cout << "Hello World! << "<< y << "\n";
}

Comments

[Мирон]

Will this code, potentially, need "toString()" override ( for T)?

[Александр Прилепский]

Мирон, А где там toString() ?

[Мирон]

cout <<
requires?

[Александр Прилепский]

Мирон, Здесь приведены лишь какие-то примеры решения того вопроса, который был задан. Не ищите здесь того, чего здесь не может быть. Чтобы рассмотреть варианты, при которых у T нет cout<< , надо применять дополнительные ограничения или еще чего-нибудь, но, в данном вопросе это вряд ли требуется. Параметр T в этом случае не приносит абсолютной универсальности, а демонстрирует лишь один из методов решения заданного вопроса.

[Мирон]

Thanks, I did find your approach the most convincing and, if you will, correct, with spirit and aim of templates. However, the questions I have asked were the same, that stopped me from writing the code itself in the fist place, and instead share some general directions to approach in one of the earlier comments.
Will review what's left to imagination to fill the picture at some later point.
If anyone gets ahead of me, mucha gracias.

Answer 2

[Wataru]

Можно использовать typedef int value_type; в классе с Setter/Getter.

Тогда в вашем шаблоне вы можете использовать C::value_type. Так в STL, например, сделано.

Плюсы: не надо обязательно заводить n. Можно обзывать его как удобнее или оно может вообще иметь другой тип, если свойство хранится неявно.

Минусы: Надо обязательно заводить этот самый value_type и обновлять его вместе с методами Getter/Setter.

Comments

[yatanai]

Направление мысли правильное, но если просто так писать то сыпет ошибками.
Перед определением C::value_type нужно дописывать typename как тут.

template<class C>
class property : public C
{
public:
    property& operator= (typename C::type arg)
    {
        this->Setter(arg);
        return *this;
    }
    operator typename C::type()
    {
        return this->Getter();
    }
};

Тогда и правда всё работает, спасибо.

Книжек по приёмам в шаблонах не подскажешь?
(На вопрос зачем я это вообще делал - Уменьшает количество SetOffsetX\Y\Z\W в коде, теперь у тебя просто переменные)

[Wataru]

yatanai, Нет, книжек не знаю. Советую это отдельным вопросом оформить - уверен вам хороших советов накидают.

[Мирон]

yatanai,
I can understand the motivation
But what I can't understand is type inference logic
In theory template flow is from declaration ( when type resolution is imminent ) -> through parameters ( in diamond brackets <> ) -> hydrate types of the library. In which case it makes sense to add parameter to implementation class, in your example, Test, like this Test<T> and extend template with T type for the property data type.
May be this is "too" obvious and I am getting in a carefully setup trap, but I am curious to find out :)
Correct me if I am wrong, but I have a feeling that you would like to infuse template with something like "inversion - of - control - template - reflection" function, where library would get informed, at the time of implementation of what type it is dealing with to implement some ( potentially conditional ) logic. But this isn't really an template purpose, even if something like this ever featured. Usually template code, if type inference gets involved, encapsulates its "common" application to some very high level abstraction, such as constructor and destructor, which can handle pretty much type independent beings, while passing actual implementation to some "implementation" feature, which is resolved through type, once again, designated at declaration time.
If my understanding is correct, your intent is to reverse the acyclic graph of compiled tree and get/extend a handler, to get an origin point for injection of some functionality, which could ( if it worked ) get into any assignment / variable reading operation, either as a feature, or, as instrumentation.

[Wataru]

Мирон, Adding template parameter to Test limits the options a lot. What if Test already were a template? When you can't just write C, as it may have more parameters. So you would need to implement a special adapter template for that.

Alternative approach might be to add T as a parameter to the property template, but then it's easier to make an error. Now you need to pass in both C and a correct T to the property template.
Current approach just requires some consistency in each separate C class. Only one place to check things out.
Also it adds an unnecessary verbosity. Why would you need to specify T, if it's fully defined by C?

[Мирон]

Wataru,
ну, так ил иначе, options have to be limited to specific type.
Вопрос, когда эти самые options get limited.
И поскольку и C и T заданы в декларации, мы не отступаем от наших, если позволите, принципов :)

[yatanai]

Мирон, Лучше поздно чем никогда.
Моя цель была - написать реализацию свойств из C#. Что бы хотя бы вызовы свойства в коде выглядели идентично. Цели оно достигло, и в целом это стало удобно.

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

int n1 = dev.GetSpeed();
int result = dev.SetSpeed(arg);
int fun = dev.GetSpeed() + arg * dev.GetSome();

Или же можно сделать то что я писал, наколдовать в свойствах и получить в рабочем коде это.

int n1 = dev.speed;
dev.speed = arg;
int fun = dev.speed + arg * dev.some;

Так как работа с устройствами это по сути библиотеки (один раз написал и забыл), то после определения всех свойств, ты к ним больше не вернёшься + код уменьшается раза в 1.5.