Ошибки, баги, вопросы - страница 2358
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Хотя даже если бы у объекта не было виртуальных методов, проверить валидность указателя при доступе по нему следовало бы все равно.
Вообще это неоднозначный вопрос. Например в C# такая проверка всегда есть, а в C++ только по необходимости, что даёт преимущество в скорости.
Ведь если вызывается метод, в котором нет обращения к полям объекта, то действительно нет смысла проверять указатель. В сущности такой метод равносилен статическому.
Вообще это неоднозначный вопрос. Например в C# такая проверка всегда есть, а в C++ только по необходимости, что даёт преимущество в скорости.
Ведь если вызывается метод, в котором нет обращения к полям объекта, то действительно нет смысла проверять указатель. В сущности такой метод равносилен статическому.
В объекте может не быть данных вообще, но при этом он может реализовать абсолютно разное и критически важное поведение, например обращаться к каким-либо внешним данным особым зависящим от типа образом, или вообще выполнять особое действие. Не знаю как обосновать такой подход как "равносильность метода статическому (читай 100% не виртуальному) при отсутствии данных"
То есть как минимум у объекта-указателя всегда есть одно поле - это его тип. По которому можно определить адреса вызываемых методов. Иначе зачем вообще нужно ООП
П.С. Хотя для автоматических объектов я лично ничего не имею против хоть какой логики поведения (т.к. почти ими не пользуюсь), но тогда не нужно давать их присваивать указателямК сожалению, я ввёл всех в заблуждение, для конструкций
вызывается оператор копирования, а не конструктор копирования.
Во втором случае, после вызова конструктора B()
В любом случае, будем сначала анализировать, потом править.
О, оказывается в мкл имеется автогенерация конструктора копирования (я думал, что его вообще нет, т.к. нельзя Class obj(other_obj), только через =). Но почему он не генерится если:
О, оказывается в мкл имеется автогенерация конструктора копирования (я думал, что его вообще нет, т.к. нельзя Class obj(other_obj), только через =). Но почему он не генерится если:
default и delete не поддерживаются
Конструктор копирования по умолчанию, оказывается пока сделали.
Только оператор копирования, т.е. для конструкций:
Сначала вызывается конструктор CFoo по умолчанию, а затем оператор копирования
вызывается оператор копирования, а не конструктор копирования.
default и delete не поддерживаются
Это да, но отменять генерацию копирующего конструктора нужно лишь в случае, когда есть пользовательский копирующий конструктор, разве нет? А не любой пользовательский.
Т.е. объект не должен позволять частично заменять свои внутренности.
Это какое-то искусственное самоограничение... я бы даже сказал - узость мышления
В чем проблема?
Нашёл у себя такую конструкцию... и все работает... нормально. По сему предлагаю Разработчикам оставить все как есть... по крайней мере если соответствующие операторы\конструкторы определены явно
Это какое-то искусственное самоограничение... я бы даже сказал - узость мышления
В чем проблема?
Нашёл у себя такую конструкцию... и все работает... нормально. По сему предлагаю Разработчикам оставить все как есть... по крайней мере если соответствующие операторы определены явно
Проверьте для начала, как в C++ всё работает. Видимо его правила придумывали "узкомыслящие".
А городить каждый раз затычки, чтобы защититься от неправильной архитектуры языка... Нет уж, надо изначально делать по уму. Имею ввиду язык
Проверьте для начала, как в C++ всё работает. Видимо его правила придумывали "узкомыслящие".
А городить каждый раз затычки, чтобы защититься от неправильной архитектуры языка... Нет уж, надо изначально делать по уму. Имею ввиду язык
Специально для Вас перепроверил с учетом https://www.mql5.com/ru/forum/1111/page2358#comment_10003995
Все нормально DJ