Баг компилятора при параметре шаблона = void* - страница 18

 
Igor Makanu:

для меня сейчас приземленная задача это хочу форму с VS в .dll  прикрутить к МТ5 изящным способом ))) - хочу обработчики кликов кнопок обернуть в класс и вызывать путем обхода массива указателей на функции обработчиков, причем хочу получить в основном коде советника возможность писать имена ф-ций один в один как в VS , т.е. button2_Click() ....button2_Click() 

ЗЫ :задача из области ЕОП  )))

Без обид, но очень напомнило :


1
 
Ilya Malev:

- Создавать автоматические структуры в рамках динамического ООП - это нонсенс

Т.е. стековые объекты: myclass obj; - нонсенс? Значит я рукожоп :)

 
pavlick_:

Т.е. стековые объекты: myclass obj; - нонсенс? Значит я рукожоп :)

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

Да, "стековые" (автоматические Вы имеете в виду?) объекты в основном это нонсенс. По моему скромному мнению, которое отнюдь не является истиной и уж тем более не в последней инстанции...
 
На шута нужен объект, который не выполняет главной функции ООП - свойство полиморфизма? Вы не присвоите такой переменной любой объект, обладающий разными свойствами в зависимости от содержания. Вы не сможете вообще этой "переменной" в списке сопоставить другой объект. Зачем Вам вообще объекты тогда нужны, может лучше структурами ограничиться? Разве что потому, что структуры в мкл не умеют возвращать ссылки на самих себя... И с ними начинается темная муть с постоянным созданием-уничтожением-самокопированием и т.п.
 
Ilya Malev:
На шута нужен объект, который не выполняет главной функции ООП - свойство полиморфизма? Вы не присвоите такой переменной любой объект, обладающий разными свойствами в зависимости от содержания. Вы не сможете вообще этой "переменной" в списке сопоставить другой объект. Зачем Вам вообще объекты тогда нужны, может лучше структурами ограничиться? Разве что потому, что структуры в мкл не умеют возвращать ссылки на самих себя... И с ними начинается темная муть с постоянным созданием-уничтожением-самокопированием и т.п.

Как же жить без полиморфизма ... А если я скажу, что без полиморфизма можно обойтись в > 90% случаев? Вот взять "принцип инверсии зависимостей SOLID", мол если мы приличные прогеры, то мы должны везде создавать абстракции, виртуальные методы (что влечёт высокие накладные расходы, естественно). C# адепты написали бы что-то вроде такого https://pro-prof.com/forums/topic/dependency-inversion-principle. А можно взять шаблоны и написать что-то вроде:

class Lamp {
public:
    void activate();
    void deactivate();
};
template <typename T>
class Button {
    Button(T& switchable)
        : _switchable(&switchable) {
    }
    void toggle() {
        if (_buttonIsInOnPosition) {
            _switchable->deactivate();
            _buttonIsInOnPosition = false;
        } else {
            _switchable->activate();
            _buttonIsInOnPosition = true;
        }     
    }
private:
   bool _buttonIsInOnPosition{false};
   T* _switchable; 
}
int main() {
   Lamp l;
   Button<Lamp> b(l)

   b.toggle();
}


Button также не зависет от деталей, без всякого полиморфизма и интерфейсов. У полиморфизма есть своя ниша, но она знчительно уже, чем об этом говорят.

ЗЫ: ну и никто не запрещает:

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
Конечно можно обойтись без полиморфизма, только для этого случая гораздо честнее и логичнее использовать простые структуры, а не объекты, иначе мы забиваем гвозди микроскопом. Точнее говоря в случае мкл5 скорее обходим "особенности реализации", не позволяющие полноценно пользоваться не объектными структурами (невозможность передачи указателей на них, в отличие от объектов). Это уже другая задача совершенно, это уже не ООП, а просто ОП
 
pavlick_:

ЗЫ: ну и никто не запрещает:

Никто не запрещает всякие костыли и схематоз придумывать, только зачем? Например: весело будет, когда Ваш автообъект вдруг внезапно возьмет да самоуничтожится, когда Вы этого меньше всего ожидаете правда? 

 
Смысл ООП не в том, чтобы использовать выбранный Вами метод нажатия кнопки, который Вы можете с тем же успехом реализовать через шаблоны или указатели функций, а как раз в том, чтобы к любому объекту системы применить методы например списка, позволяющие самоорганизовываться в списочные структуры и создавать произвольные выборки в нужное время без всяких костылей типа CArrayObj и т.п. и связанного с этим геморроя, перегружая методы типа Select, Query, Compare, Sort  и т.п. (да хоть бы и тот же Clone/Copy, когда каждый объект без Вашего участия может решать, копироваться ему для помещения в список/массив или не нужно, а если копироваться, то как)
 
Ilya Malev:

Никто не запрещает всякие костыли и схематоз придумывать, только зачем? Например: весело будет, когда Ваш автообъект вдруг внезапно возьмет да самоуничтожится, когда Вы этого меньше всего ожидаете правда? 

Затем, что стековый объект на порядок шустрее объекта в куче (выделение памяти). Самоуничтожится? - это что-то новенькое :). Но иногда необходим, конечно - количество объектов известно только в run time, например.

ЗЫ: вам, возможно, комфортнее иначе, дело личное.

 
Ilya Malev:
Смысл ООП не в том, чтобы использовать выбранный Вами метод нажатия кнопки, который Вы можете с тем же успехом реализовать через шаблоны или указатели функций, а как раз в том, чтобы к любому объекту системы применить методы например списка, позволяющие самоорганизовываться в списочные структуры и создавать произвольные выборки в нужное время без всяких костылей типа CArrayObj и т.п. и связанного с этим геморроя, перегружая методы типа Select, Query, Compare, Sort  и т.п. (да хоть бы и тот же Clone/Copy, когда каждый объект без Вашего участия может решать, копироваться ему для помещения в список/массив или не нужно, а если копироваться, то как)

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