Bug de compilador com parâmetro de modelo = vazio* - página 19

Novo comentário
 
pavlick_:

Autodestruição? - isso é novidade :).

Sim, autodestruição. Presumo que você esteja ciente de que esta é a diferença entre objetos "empilhados" e objetos dinâmicos - eles não lhe perguntam quando apagar a si mesmos, eles o fazem quando saem do bloco do programa de origem :)
 
Ilya Malev:
Sim, autodestruição. Presumo que você esteja ciente de que esta é a diferença entre objetos "empilhados" e objetos dinâmicos - eles não lhe perguntam quando apagar a si mesmos, eles o fazem quando saem do bloco do programa de origem :)

Você provavelmente já ouviu falar de construtores/operadores de cópia/movimento, certo?

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

Você provavelmente já ouviu falar de construtores/operadores de cópia/movimento, certo?

Então estaremos atentos a esse momento crucial e o copiaremos dessa forma, se não formos tarde demais? lol:

Só porque nós realmente não gostamos do OOP, ou existem outras razões posteriores?

 
Ilya Malev:

Então estaremos atentos a esse momento crucial e o copiaremos dessa forma, se não formos tarde demais? lol:

Só porque nós realmente não gostamos do OOP, ou existem outras razões posteriores?

Claro, de que outra forma poderia haver? Você, como um proger decente, deve administrar objetos dinâmicos também através de empilhamento (técnica RAII)

{
   unique_ptr<Class> p(new Class);
   ...
   // ой, самоуничтожение :)
}
 
E faremos muitos invólucros para isso, caramba. Porque o nicho de polimorfismo não é tão significativo, mas nossas muletas têm todo um campo de aplicação, se não usarmos OOP: chorar:
 
pavlick_:

Claro, de que outra forma poderia ser? Como um proger decente, você tem que gerenciar objetos dinâmicos também através de objetos empilhados (técnica RAII).

Você se refere ao coletor de lixo? )))) ou sobre a contagem do número de referências. tenho praticado essas coisas ultimamente. mas infelizmente o desempenho de todas essas abordagens é muito pobre em µl

 
Gerenciar din.objects via stack ones significa alocar 24 bytes ADICIONAIS de memória para cada objeto (isto é o quanto tal "stack pointer "+referência ao próprio objeto "pesará"). Além disso, o custo de tempo em termos de velocidade não é nada pequeno. Tudo isso é um pouco triste no geral. Mas também não sentimos uma grande necessidade disso. Como se costuma dizer, o medo tem muitos olhos. Se estivéssemos programando estações espaciais, então você não poderia passar sem um controle rigoroso. Mas como está, com um sistema de classe afinado, tudo funciona bem sem ele.
 

Não, não sobre coletor de lixo, mas sobre apontadores inteligentes - unique_ptr, shared_ptr (com contagem de referência), RAII facilmente pesquisável no Google. Geralmente não há custo extra para o unique_ptr em termos de memória (wrapper == tamanho do ponteiro), e as chamadas são super otimizadas, mas em µl é triste, sim. Mas também não é necessário aqui (apontadores inteligentes).

 
pavlick_:

Ou você poderia pegar os modelos e escrever algo como:

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

O botão também é independente de detalhes, sem todo o polimorfismo e interfaces. O polimorfismo tem seu próprio nicho, mas é muito mais estreito do que dizem.

Neste exemplo simplificado, o modelo certamente fica melhor. Na verdade, você não precisa nem mesmo de um modelo lá, já que você tem apenas uma instância.

 
Alexey Navoykov:

Este exemplo simplificado certamente faz com que o modelo pareça mais conveniente. Na verdade, você não precisa nem mesmo de um modelo lá, já que você tem apenas uma instância.

Lâmpada de botão via g com virtualidade:

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();
}

exemplos hackneyed.

1...121314151617181920
Novo comentário
Razão: