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

[Ilya Malev]

Igor Makanu:

только через строки, я раньше через StringConcatenate() получал адрес указателя, примерно так:

Про StringConcatenate не знал, жаль что в МТ5 её переделали и без string s уже не использовать. А на четверке заметно быстрее StringFormat выходит

Да и вообще почему-то в пятерке эта операция "опрощения" указателя через строку почти вдвое медленнее, хотя в основном там все работает быстрее, иногда на порядок

[Alexey Navoykov]

fxsaber:

Скобки вносят полную однозначность в трактовке выражения.

Зачем эта дополнительная однозначность, если толковому программисту всё и так однозначно?  А если продолжать в духе "заботливого компилятора", тогда нужно и все выражения в if требовать заключать в фигурные скобки, а то вдруг глупый программёр чего перепутает.

Если же речь идёт о большей наглядности, то для этого достаточно поставить пробелы:

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

[Alexey Navoykov]

pavlick_:

Сомнительная польза такого массива, честно говоря. Чего вы с ним делать сможете? Вы ведь знаете, что не будет автоматом вызываться delete для членов массива?

С чего это вдруг?  Деструкторы объектов всегда виртуальные

[pavlick_]

Alexey Navoykov:
С чего это вдруг?  Деструкторы объектов всегда виртуальные

А вы попробуйте. В случае с void* никаких шансов вообще нет.

[Ilya Malev]

delete вообще ни для кого не вызывается автоматом. на то оно и delete ) 

другое дело, что это никак не мешает в деструкторе самого массива пройтись по списку и удалить все объекты, если это необходимо

хотя выгоднее по многим причинам использовать общий базовый тип и хранить ссылку на него

[pavlick_]

Если хочется отправить на свалку CArayObject, то нужно сделать обвертку (вроде такой https://www.mql5.com/ru/forum/170952/page110#comment_9894796) над базовым классом и помещать их в массив (возможно ваш), но тогда уже вам void* не понадобится.

Я не против void*, он нужен, но в другом качестве.

[Alexey Navoykov]

pavlick_:

А вы попробуйте. В случае с void* никаких шансов вообще нет.

Да всё нормально работает, чего вы выдумываете:

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;
  }

В логе получаем:

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

И чего я вообще повёлся на это...

[fxsaber]

Alexey Navoykov:

Зачем эта дополнительная однозначность, если толковому программисту всё и так однозначно?  А если продолжать в духе "заботливого компилятора", тогда нужно и все выражения в if требовать заключать в фигурные скобки, а то вдруг глупый программёр чего перепутает.

Если же речь идёт о большей наглядности, то для этого достаточно поставить пробелы:

Наглядность на пробелах ни о чем - добро пожаловать в мир стилизаторов.

[fxsaber]

Про доп. скобки

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:

Наглядность на пробелах ни о чем - добро пожаловать в мир стилизаторов.

Если стилизатор делает из удобочитаемого кода трудночитаемый - может ну его нафиг такой стилизатор?

Как по мне, стилизатор хорош только тогда, когда ВСЕ его правила можно гибко настроить под себя.