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

[Ilya Malev]

Igor Makanu:

only through strings, I used to use StringConcatenate() to get pointer address, like this:

I didn't know about StringConcatenate, it's a pity that in MT5 it was redesigned and cannot be used without string s. And StringFormat is much faster on 4.

And in general this operation of "polling" pointer through string is twice slower in five, although generally everything is faster there, sometimes by an order

[Alexey Navoykov]

fxsaber:

Brackets make the expression completely unambiguous.

Why this additional unambiguity, if a smart programmer can do everything unambiguously? And if we continue in the spirit of "caring compiler", then all expressions in if should be enclosed in curly brackets, in case a stupid programmer mixes something up.

If we are talking about greater clarity, it is enough to put spaces:

a<<1 | b<<2 | c<<3

[Alexey Navoykov]

pavlick_:

The usefulness of such an array is questionable, frankly. What can you do with it? You know you won't automatically call delete on array members, right?

Why? Object destructors are always virtual

[pavlick_]

Alexey Navoykov:
Why? Object destructors are always virtual.

Try it. In case of void* there is no chance at all.

[Ilya Malev]

delete is not called automatically at all for anybody.)

It's another thing that it doesn't prevent the array destructor from going through the list and deleting all objects, if necessary

although it is more advantageous to use a common base type and store a reference to it for many reasons

[pavlick_]

If you want to scrap CArayObject, you have to make an override (like this https://www.mql5.com/ru/forum/170952/page110#comment_9894796) over the base class and put them in an array (possibly yours), but then you won't need void* anymore.

I'm not against void*, it's needed, but in a different capacity.

[Alexey Navoykov]

pavlick_:

Try it. In case of void* there is no chance at all.

Everything is working fine, why are you making this up?

class B
{
 public: 
  ~B() { Print(__FUNCSIG__); }
};

class A
{
 public: 
  B b;
  ~A() { Print(__FUNCSIG__); }
};

void OnStart()
  {
   A* a= new A;
   
   void* p= a;
   delete p;
  }

We get it in the log:

void A::~A()
void B::~B()

Why did I fall for it anyway...

[fxsaber]

Alexey Navoykov:

Why this additional unambiguity, if a smart programmer can do everything unambiguously? And if we continue in the spirit of "caring compiler", then all expressions in if should be enclosed in curly brackets, otherwise a stupid programmer can get confused.

If we are talking about more clarity, it is enough to put spaces:

If you want more clarity with spaces, then you should just put spaces.

[fxsaber]

About the extra brackets

class A
{
public:
  int i;
  
  A* GetPtr()
  {
    this.i = 1;
    
    return(&this);
  }
  
  void f()
  {
    Print(this.i);
  }
};

class B : public A
{
public:
  void* GetPtr()
  {
    this.i = 2;
    
    return(&this);
  }
};

void g( A* a)
{
  a.f();
}

void OnStart()
{    
  B* b = new B;
  
//   b.GetPtr().f(); // 'f' - member function not defined
  
  ((A*)b).GetPtr().f();   // 1
  ((A*)b.GetPtr()).f();   // 2
  ((A*)( b.GetPtr())).f(); // Доп. скобки, чтобы подчеркнуть, что именно имелось в виду, не полагаясь на приоритеты.

  delete b;
}

[Alexey Navoykov]

fxsaber:

The visibility on spaces is nothing - welcome to the world of styling tools.

If a styler makes a hard-to-read code unreadable, then don't bother with the styler.

For me, a styler is good only when ALL its rules can be flexibly customized.