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

Новый комментарий
 
Alexey Navoykov:

А сделал бы так:

Такой стиль считаю неудобным. Т.е. сводим все к "фломастерам".

 
fxsaber:

Так все таки и Вам нужны предупреждения? Что за двойные стандарты: в обоих местах поведение однозначное, но со скобками Вы против предупреждений, а здесь - ЗА?

Вам же предупреждение нужно, чтобы не совершать трудно-уловимые ошибки. Так вот трудность - это субъективная оценка. Вот со скобками Вы не совершаете ошибок, а здесь - могете. А у меня - наоборот.

Так под кого из нас подстраивать правила выноса предупреждений?

Вы похоже реально не понимаете сути.  Динамический кастинг - это всегда должна быть только ЯВНАЯ операция. В любом нормальном языке, хоть С++, хоть C#, хоть Java, хоть другой ООП язык, такой код у вас не скомпилируется. Это основа основ надёжного ООП. А здесь по какой-то причине забыли об этом.  Вот уж не думал, что здесь вообще уместно сравнение со скобочками.

 
Alexey Navoykov:

основа основ надёжного ООП.

Основа в однозначности.

 
Ilya Malev:

Не вижу смысла от кода по ссылке (хотя и стандартными библиотеками не пользуюсь). Если помещение объекта в массив предполагает создание его копии, то метод присваивания или конструктор копирования нужно объявлять и описывать явно в этом классе, иначе никакие обертки не помогут все равно. Если нужно помещать в массив только ссылку на объект то никакие обертки и не нужны (с чего вдруг?)

Для чего нужен такой массив? Ведь это почти аналог плюсового 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) там тоже нужна обвёртка.
 
pavlick_:

ЗЫ: да чего там говорить, vector<class_name*> не будет работать ожидаемо даже в плюсах (вызов деструкторов в конце жизни vector'a) там тоже нужна обвёртка.

Так пойдет? )

template<typename T>
void del(T par){printf("%s не удаляем",typename(T));}

template<typename T>
void del(T *par){printf("%s удаляем",typename(T));delete par;}

class A{public:void~A(void){printf("удаляем %i",&this);}};

void OnStart()
 {
  int var1;
  A *var2=new A;
  del(var1);
  del(var2);
 }

П.С. По аналогии вместо void функция может возвращать все что угодно, и не нужно никаких SFINAE.

 
Да, пойдёт. Но обвёртка всё равно нужна: нам ведь нужен универсальный массив, значит иногда в нём указатели которым нужно делать delete,  а иногда нет (ну тупо набор указателей - результат поиска чего-то в другом массиве).
 
pavlick_:

В плюсах удаление void* это UB.

Кстати я раньше даже и не задумывался об этом, спасибо за наводку.  Получается, в этом случае delete аналогичен free().  По хорошему такое следовало бы запрещать.  Ведь delete позиционируется именно для объектов, а тут просто освобождается память в обход правил.

Теперь буду учитывать это и в MQL тоже.  Хоть тут деструкторы и вызываются, но в случае портирования кода на C++ можно огрести проблем.

 
pavlick_:
Да, пойдёт. Но обвёртка всё равно нужна: нам ведь нужен универсальный массив, значит иногда в нём указатели которым нужно делать delete,  а иногда нет (ну тупо набор указателей - результат поиска чего-то в другом массиве).

Ну так никто же не запрещает передавать доп опцию при создании массива - нужно удалять элементы при его удалении или нет, и сделать её по умолчанию включенной или выключенной (на свой вкус). А то ведь так не угадаешь, нужно удалять или нет.))

П.С. Кстати от того, что Вы обернете указатель в "обертку" перед помещением в массив, вопрос о том, нужно удалять его базовый объект или нет при удалении массива никак не прояснится))
 
fxsaber:

Доп. скобки полностью исключили влияние приоритетов языка. Все становится абсолютно однозначно. Благодаря этому появляется 100% надежность, что в этом месте ничего не поломается после очередного билда.

С учётом этого обобщу:


A100
Разработчики
fxsaber
скобки
нужны только там, где без них не обойтись
возможно нужны ещё и там, где раньше в MQL4 было по другому
нужны везде
лишние предупреждения
не нужны
нужны только там, где раньше в MQL4 было по другому
нужны везде
приоритеты
нужны
нужны
не нужны в принципе (потому что их заменяют скобки)

Если я неправильно изложил - пожалуйста поправьте меня - изложил коротко и однозначно свою концепцию где нужны предупреждения относительно скобок

 
Ilya Malev:

Ну так никто же не запрещает передавать доп опцию при создании массива - нужно удалять элементы при его удалении или нет, и сделать её по умолчанию включенной или выключенной (на свой вкус). А то ведь так не угадаешь, нужно удалять или нет.))

В общем да, можно и так.

П.С. Кстати от того, что Вы обернете указатель в "обертку" перед помещением в массив, вопрос о том, нужно удалять его базовый объект или нет при удалении массива никак не прояснится))


Если без обвёртки - то не удаляется,  с обвёрткой - удаляется, всё кристально ясно.

ЗЫ: но если бы я делал, то делал максимально схоже со стандартной плюсовой библиотекой (имена, поведение и т.д.), поэтому для меня выбора нет. Зачем плодить ещё одну спецификацию, когда всё уже написано?

1234567891011121314...20
Новый комментарий
Причина обращения: