OOP, templates and macros in mql5, subtleties and uses - page 9

New comment
 
Ilya Malev:

I got "stack overflow" )

I guess it is a cockroach after all...

Well, it's not the compiler, but at runtime. The compiler should react.

Here's what I tried in VS 2010:

class A
 {
  public:
   virtual int f2() = 0;
 };

class B : public A
{
 public:
  virtual int f2() { return A::f2(); }
};

B b;

I get a compilation error: Error 1 error LNK2001: unresolved external symbol "public: virtual __thiscall A::f2(void)".

But Metaeditor won't say a word. Not good.

 
It turns out that calling an ancestor function with = 0 turns into calling itself. If you catch this error yourself, you might be able to benefit from it...
 
Alexey Navoykov:

This is how the compiler should react.

I tried this in VS 2010:

I get a compilation error: Error 1 error LNK2001: unresolved external symbol "public: virtual __thiscall A::f2(void)".

Metaeditor won't say a word. Not good.

Alexey, please explain to me, why if mql is a copy of C, it must be absolutely identical and one step to the left, one step to the right - firing squad?

Just because the developers were careless? But any language is built on loops and conditions. Everything else is in the trailer. Why doesn't anybody demand that any other language is similar to C in the OOP part or in any other way?

 
Alexey Viktorov:

Alexey, can you please explain to me on your fingers why if mql is like C, then it must be absolutely identical and one step to the left, one step to the right - firing squad?

Just because the developers were careless? But any language is built on loops and conditions. Everything else is in the trailer. Why doesn't anybody demand that any other language is similar to C in the OOP part or in any other way?

It's not about being completely identical. It is about functionality which is implemented must work correctly and consistently. But first you shout: show me another language that works differently. And then when C++, which works differently (correctly), is given as an example, you start an old rant about how MQL is not C++ and shouldn't be identical. You should make up your mind
 
Alexey Viktorov:

Can you show us an example when this all can make writing code easier, shorten it or at least protect it from errors? And please, not abstract functions, but functions close to the real trading conditions in an Expert Advisor or indicator.

No way. The guys are just trying to put their fantasies into reality.

 
Dmitry Fedoseev:

No way. The guys are just trying to stretch their fantasies into reality.

Seems to me, it's a very useful exercise - stretching fantasy into reality. That's the point of development!
Very enlightening discussion. (chuckles): Thank you.
 
Alexey Navoykov:

Yes, but I've been using an alternative way for a long time: all interfaces are originally designed as an intermediate template class:

In this way you may create an inheritance chain consisting of any number of such interfaces. Yes, of course you cannot do dynamic_cast with them, but it is not so often necessary. The main task is to pass them into functions.

I've read it carefully, it's an interesting move, by the way. I had not thought of it before =) I'll experiment too, at my leisure...

 
Nikolai Semko:
As for me, so very useful exercise - to stretch fantasy on reality. That is the point of development!
A very enlightening discussion. Thank you.

And most importantly - fruitful! The developers did hear us and decided to fix this bug that everyone has been stumbling over for years.

But the destructive attitude of some forum users is certainly surprising - they don't develop themselves and try to hinder others with remarkable persistence.

 

>> Yes, of course you can't do dynamic_cast with them, but it's not such a frequent need.

Why don't you do it, no problem ) But then your main nightmare appears - non-detection of casting errors at the compiling stage :)

 
Ilya Malev:

>> Yes, of course you can't do dynamic_cast with them, but it's not such a frequent need.

Why don't you do it, no problem ) But then your main nightmare appears - non-detection of casting errors at compiling stage :)

And it makes no sense in general case anyway, because the inheritance chain could be any way you wanted: whether it was Interface<CBase> or Interface<C<B<CBase>>>>, we have innumerable variants. We'll have to cast CBase consistently to all possible variants, which is unrealistic.

I remember planning to implement storing information about interfaces in class object itself, and in addition to existing interface pads, make independent interface classes, that would work as a wrapper over our pad. But then I came to the conclusion that all this was unnecessary and unnecessary. In practice, I've never seen a need to cast a base class to any interface, it just doesn't make any sense. The only option is to find out if the class supports this interface for debugging purposes, but we don't need casting for that.

12345678910111213141516...28
New comment