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

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

Самоуничтожится? - это что-то новенькое :). 

Ага, самоуничтожиться. Я предполагаю, что Вы в курсе, что именно в этом отличие "стековых" объектов от динамических - они не спрашивают Вас, когда им удалять себя, а делают это при выходе из породившего программного блока :)
 
Ilya Malev:
Ага, самоуничтожиться. Я предполагаю, что Вы в курсе, что именно в этом отличие "стековых" объектов от динамических - они не спрашивают Вас, когда им удалять себя, а делают это при выходе из породившего программного блока :)

Вы ведь наверняка слышали про copy/move конструкторы/операторы?:

obj o;
{
   obj q;
   o = q;
   o = move(q);  // С++ вариант, более эффективный
}
 
pavlick_:

Вы ведь наверняка слышали про copy/move конструкторы/операторы?:

То есть мы будем на страже этого ответственного момента и таки его скопируем, если не опоздаем только? :lol: 

Просто потому что мы очень не любим ООП, или есть другие скрытые причины?

 
Ilya Malev:

То есть мы будем на страже этого ответственного момента и таки его скопируем, если не опоздаем только? :lol: 

Просто потому что мы очень не любим ООП, или есть другие скрытые причины?

Конечно, а как иначе то? Вы как приличный прогер должны и динамическими объектами управлять через стековые (техника RAII)

{
   unique_ptr<Class> p(new Class);
   ...
   // ой, самоуничтожение :)
}
 
А ещё, блин, кучу оберток наплодим для этого. Потому что у полиморфизма ниша не столь значительная, зато у наших костылей пространство применения целое поле, если ООП не использовать :cry:
 
pavlick_:

Конечно, а как иначе то? Вы как приличный прогер должны и динамическими объектами управлять через стековые (техника RAII)

Это Вы про сборщик мусора что ли? ))) или про учет числа ссылок. я как раз этими фишками занимался в последнее время. но производительность всех этих подходов хромает в мкл к сожалению

 
Управлять дин.объектами через стековые - это значит выделать ДОПОЛНИТЕЛЬНО 24 байт памяти под каждый объект (именно столько будет "весить" такой "стековый указатель"+ссылка на сам объект). Плюс временные издержки по скорости сильно не малые. В совокупности это все печально. Но и нет в этом особенно никакой необходимости. У страха глаза велики, как говорится. Если бы мы тут космические станции программировали, то без строгого контроля было бы не обойтись конечно. А так при отлаженной системе классов все работает прекрасно и без этого.
 

Нет, не про сборщик мусора, а про умные указатели - unique_ptr, shared_ptr (c подсчётом ссылок), RAII легко гуглится.  Вообще никакой доп платы зы unique_ptr в плане памяти нет (обвёртка == размеру указателя), а вызовы заоптимизируются, но в мкл всё печально, да. Но здесь это и не нужно (умные указатели).

 
pavlick_:

А можно взять шаблоны и написать что-то вроде:

https://www.mql5.com/ru/forum/295485/page18#comment_9971363

Button также не зависет от деталей, без всякого полиморфизма и интерфейсов. У полиморфизма есть своя ниша, но она знчительно уже, чем об этом говорят.

На таком упрощённом примере конечно шаблон удобней смотрится. По сути там даже шаблон не нужен, раз у вас всего один экземпляр.

 
Alexey Navoykov:

На таком упрощённом примере конечно шаблон удобней смотрится. По сути там даже шаблон не нужен, раз у вас всего один экземпляр.

Кнопка лампа через ж с виртуальностью:

struct SwitchableDevice {
    virtual void switchOn() = 0;
    virtual void switchOff() = 0;
};
struct Lamp : SwitchableDevice {
    void switchOn(){std::cout << "shine bright" << std::endl;}
    void switchOff(){std::cout << "i am not afraid of the dark" << std::endl;}
};
struct Button {
    SwitchableDevice& dev;
    bool state = false;
    Button(SwitchableDevice& d) : dev(d) {}
    void buttonPress(){
        if (state) { dev.switchOff(); }
        else       { dev.switchOn();  }
        state = !state;
    }
};
int main(){
    Lamp lamp;
    Button button(lamp);
    button.buttonPress();
    button.buttonPress();
}

заезженные примеры.

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