![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А сделал бы так:
Такой стиль считаю неудобным. Т.е. сводим все к "фломастерам".
Так все таки и Вам нужны предупреждения? Что за двойные стандарты: в обоих местах поведение однозначное, но со скобками Вы против предупреждений, а здесь - ЗА?
Вам же предупреждение нужно, чтобы не совершать трудно-уловимые ошибки. Так вот трудность - это субъективная оценка. Вот со скобками Вы не совершаете ошибок, а здесь - могете. А у меня - наоборот.
Так под кого из нас подстраивать правила выноса предупреждений?
Вы похоже реально не понимаете сути. Динамический кастинг - это всегда должна быть только ЯВНАЯ операция. В любом нормальном языке, хоть С++, хоть C#, хоть Java, хоть другой ООП язык, такой код у вас не скомпилируется. Это основа основ надёжного ООП. А здесь по какой-то причине забыли об этом. Вот уж не думал, что здесь вообще уместно сравнение со скобочками.
основа основ надёжного ООП.
Основа в однозначности.
Не вижу смысла от кода по ссылке (хотя и стандартными библиотеками не пользуюсь). Если помещение объекта в массив предполагает создание его копии, то метод присваивания или конструктор копирования нужно объявлять и описывать явно в этом классе, иначе никакие обертки не помогут все равно. Если нужно помещать в массив только ссылку на объект то никакие обертки и не нужны (с чего вдруг?)
Для чего нужен такой массив? Ведь это почти аналог плюсового vector, должен работать как с vector<int>, vector<class_name>, vector<class_name*>. Если сможете реализовать без обвёртки средствами мкл - молодец (не думаю, что сможете). У вас нет ни возможности пробежаться по массиву и вызвать деструкторы ( _data[i].~Destr() ), ни частичной специализации, ни всяких SFINAE фокусов. А такая обвёртка даёт возможность сделать массив годным для указателей на объекты в куче не ломая при этом возможность работы с vector<int> например.
vector<unique_ptr<my_class>> v1;
vector<my_class> v2;
vector<int> v3;
ЗЫ: да чего там говорить, vector<class_name*> не будет работать ожидаемо даже в плюсах (вызов деструкторов в конце жизни vector'a) там тоже нужна обвёртка.
Так пойдет? )
П.С. По аналогии вместо void функция может возвращать все что угодно, и не нужно никаких SFINAE.
В плюсах удаление void* это UB.
Кстати я раньше даже и не задумывался об этом, спасибо за наводку. Получается, в этом случае delete аналогичен free(). По хорошему такое следовало бы запрещать. Ведь delete позиционируется именно для объектов, а тут просто освобождается память в обход правил.
Теперь буду учитывать это и в MQL тоже. Хоть тут деструкторы и вызываются, но в случае портирования кода на C++ можно огрести проблем.
Да, пойдёт. Но обвёртка всё равно нужна: нам ведь нужен универсальный массив, значит иногда в нём указатели которым нужно делать delete, а иногда нет (ну тупо набор указателей - результат поиска чего-то в другом массиве).
Ну так никто же не запрещает передавать доп опцию при создании массива - нужно удалять элементы при его удалении или нет, и сделать её по умолчанию включенной или выключенной (на свой вкус). А то ведь так не угадаешь, нужно удалять или нет.))
П.С. Кстати от того, что Вы обернете указатель в "обертку" перед помещением в массив, вопрос о том, нужно удалять его базовый объект или нет при удалении массива никак не прояснится))Доп. скобки полностью исключили влияние приоритетов языка. Все становится абсолютно однозначно. Благодаря этому появляется 100% надежность, что в этом месте ничего не поломается после очередного билда.
С учётом этого обобщу:
Если я неправильно изложил - пожалуйста поправьте меня - изложил коротко и однозначно свою концепцию где нужны предупреждения относительно скобок
Ну так никто же не запрещает передавать доп опцию при создании массива - нужно удалять элементы при его удалении или нет, и сделать её по умолчанию включенной или выключенной (на свой вкус). А то ведь так не угадаешь, нужно удалять или нет.))
В общем да, можно и так.
Если без обвёртки - то не удаляется, с обвёрткой - удаляется, всё кристально ясно.
ЗЫ: но если бы я делал, то делал максимально схоже со стандартной плюсовой библиотекой (имена, поведение и т.д.), поэтому для меня выбора нет. Зачем плодить ещё одну спецификацию, когда всё уже написано?