[CLOSED] : Compiler bug with template parameter = void* - page 18

New comment
 
Igor Makanu:

I would like to attach VS form to .dll to MT5 in a simple way )))) - I want to wrap the button click handlers in a class and call them by traversing a pointer array of handler functions, and I want to have in the main EA code the possibility to write the same function names as in VS, i.e. button2_Click() ....button2_Click()

SZY: This is anEOP problem))))

No offense, but it reminds me a lot:


1
 
Ilya Malev:

- Creating automatic structures within a dynamic OOP is nonsense

So stack objects: myclass obj; is nonsense? Then I'm a handicapper :)

 
pavlick_:

So, stack objects: myclass obj; is nonsense? So, I'm a handicraftsman :)

There are all kinds of tasks. You can practice rhetoric for a long time, if you don't describe specific tasks, you can come up with anything...

Yes, "stackable" (automatic you mean?) objects are basically nonsense. In my humble opinion, which is by no means the truth and certainly not in the last instance...
 
A joker needs an object that doesn't perform the main function of OOP - the polymorphism property? You won't assign any object with different properties depending on the content to such a variable. You won't be able to map another object to this "variable" in the list at all. Why do you need objects at all? Isn't it better to use structures instead? Maybe because µl structures can't return references to themselves... And with them starts a dark stuff with constant creation-destruction-self-copying etc.
 
Ilya Malev:
You want an object that doesn't fulfil the main function of OOP - the polymorphism property? You won't assign any object with different properties depending on the content to such a variable. You won't be able to map another object to this "variable" in the list at all. Why do you need objects at all? Isn't it better to use structures instead? Maybe because µl structures can't return references to themselves... And with them starts a dark stuff with constant creation-destruction-self-copying etc.

How to live without polymorphism ... And if I say that we can do without polymorphism in >90% of cases? Take the "SOLID dependency inversion principle", if we are decent progers, we should create abstractions, virtual methods everywhere (which entails high overheads, of course). C# adepts would write something like this https://pro-prof.com/forums/topic/dependency-inversion-principle. Or we could take templates and write something like:

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 is also detail-independent, without all the polymorphism and interfaces. Polymorphism has its own niche, but it's much narrower than they say.

ZS: well, no one forbids it:

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
Of course, we can do without polymorphism, but for this case it is much more honest and logical to use simple structures rather than objects, otherwise we are nailing with a microscope. To be more precise, in case of µl5 we rather bypass "implementation features" that do not allow to fully use non-object structures (impossibility to pass pointers to them, unlike objects). This is a different problem entirely, it's no longer OOP, but just OO
 
pavlick_:

ZS: well, no one forbids it:

No one forbids all sorts of crutches and schematosis, but why? For example: it will be fun when your auto-object suddenly self-destructs when you least expect it, won't it?

 
The point of OOP is not to use your chosen method of pressing the button, which you can just as well implement through templates or function pointers, but just to apply to any object of the system methods such as list, which allow to self-organize into list structures and create arbitrary selections at the right time without any crutches like CArrayObj, etc. and the associated hassle, overloading methods like Select, Query, Compare, Sort, etc. (and even Clone/Copy, when each object can decide without your participation whether it's to be copied into a list/array or not, and if copied, how it's to be copied).
 
Ilya Malev:

No one forbids making up crutches and schematosis, but why? For example: it will be funny when your auto-object suddenly destroys itself when you least expect it, won't it?

Because a stack object is much faster than an object in a heap(memory allocation). Self-destruction? - That's something new :). But sometimes necessary, of course - the number of objects is known only at run time, for example.

ZS: you may be more comfortable otherwise, it's a personal matter.

 
Ilya Malev:
The point of OOP is not to use your chosen method of pressing the button, which you can just as well implement through templates or function pointers, but just to apply to any object of the system methods such as list, which allow to self-organize into list structures and create arbitrary selections at the right time without any crutches like CArrayObj, etc. and the associated hassle, overloading methods like Select, Query, Compare, Sort, etc. (and even Clone/Copy, when each object can decide without your participation whether to copy it into a list/array or not, and if to copy it, how).

I wrote - polymorphism has its own niche, I'm not arguing. But practice shows (mine personally, at least) that it's not that significant. I'm much more likely to solve issues with templates.

1...11121314151617181920
New comment
Reason: