Ошибки, баги, вопросы - страница 2358

[Alexey Navoykov]

Ilya Malev:

Хотя даже если бы у объекта не было виртуальных методов, проверить валидность указателя при доступе по нему следовало бы все равно. 

Вообще это неоднозначный вопрос. Например в C# такая проверка всегда есть, а в C++ только по необходимости, что даёт преимущество в скорости.

Ведь если вызывается метод, в котором нет обращения к полям объекта, то действительно нет смысла проверять указатель.  В сущности такой метод равносилен статическому.

[Ilya Malev]

Alexey Navoykov:

Вообще это неоднозначный вопрос. Например в C# такая проверка всегда есть, а в C++ только по необходимости, что даёт преимущество в скорости.

Ведь если вызывается метод, в котором нет обращения к полям объекта, то действительно нет смысла проверять указатель.  В сущности такой метод равносилен статическому.

В объекте может не быть данных вообще, но при этом он может реализовать абсолютно разное и критически важное поведение, например обращаться к каким-либо внешним данным особым зависящим от типа образом, или вообще выполнять особое действие. Не знаю как обосновать такой подход как "равносильность метода статическому (читай 100% не виртуальному) при отсутствии данных"

То есть как минимум у объекта-указателя всегда есть одно поле - это его тип. По которому можно определить адреса вызываемых методов. Иначе зачем вообще нужно ООП

П.С. Хотя для автоматических объектов я лично ничего не имею против хоть какой логики поведения (т.к. почти ими не пользуюсь), но тогда не нужно давать их присваивать указателям

[Ilyas]

К сожалению, я ввёл всех в заблуждение, для конструкций

B *b=a;
B b=a;

вызывается оператор копирования, а не конструктор копирования.
Во втором случае, после вызова конструктора B()

В любом случае, будем сначала анализировать, потом править.

[pavlick_]

О, оказывается в мкл имеется автогенерация конструктора копирования (я думал, что его вообще нет, т.к. нельзя Class obj(other_obj), только через =). Но почему он не генерится если:

class Q
{
public:
   Q(Q&)=default;  // нельзя
   Q(int) {}       // из-за него копирующий конструктор исчез
};

[Ilyas]

pavlick_:

О, оказывается в мкл имеется автогенерация конструктора копирования (я думал, что его вообще нет, т.к. нельзя Class obj(other_obj), только через =). Но почему он не генерится если:

default и delete не поддерживаются

Конструктор копирования по умолчанию, оказывается пока сделали.

Только оператор копирования, т.е. для конструкций:

CFoo foo=another_foo;

Сначала вызывается конструктор CFoo по умолчанию, а затем оператор копирования

[Alexey Navoykov]

Ilyas:

вызывается оператор копирования, а не конструктор копирования.

Но это всё равно ошибка, т.к. неявный оператор копирования должен создаваться только класса B, а не для всех родительских классов.  Т.е. объект не должен позволять частично заменять свои внутренности.

[pavlick_]

Ilyas:

default и delete не поддерживаются

Это да, но отменять генерацию копирующего конструктора нужно лишь в случае, когда есть пользовательский копирующий конструктор, разве нет? А не любой пользовательский.

[A100]

Alexey Navoykov:
Т.е. объект не должен позволять частично заменять свои внутренности.

Это какое-то искусственное самоограничение... я бы даже сказал - узость мышления

class A {};
class B : public A {
public:
        void operator =( const A& ) {}
};

В чем проблема?

Нашёл у себя такую конструкцию... и все работает... нормально. По сему предлагаю Разработчикам оставить все как есть... по крайней мере если соответствующие операторы\конструкторы определены явно

[Alexey Navoykov]

A100:

Это какое-то искусственное самоограничение... я бы даже сказал - узость мышления

В чем проблема?

Нашёл у себя такую конструкцию... и все работает... нормально. По сему предлагаю Разработчикам оставить все как есть... по крайней мере если соответствующие операторы определены явно

Проверьте для начала, как в C++ всё работает. Видимо его правила придумывали "узкомыслящие".

А городить каждый раз затычки, чтобы защититься от неправильной архитектуры языка... Нет уж, надо изначально делать по уму.  Имею ввиду язык

[A100]

Alexey Navoykov:

Проверьте для начала, как в C++ всё работает. Видимо его правила придумывали "узкомыслящие".

А городить каждый раз затычки, чтобы защититься от неправильной архитектуры языка... Нет уж, надо изначально делать по уму.  Имею ввиду язык

Специально для Вас перепроверил с учетом https://www.mql5.com/ru/forum/1111/page2358#comment_10003995

#ifdef __cplusplus
#include "https://www.mql5.com/ru/forum/1111/page2358#comment_10003995"
void OnStart()
{
        A a;
        B b;
        b = a;
}
#endif

Все нормально DJ