Erros, bugs, perguntas - página 2358

[Alexey Navoykov]

Ilya Malev:

Embora mesmo que o objecto não tivesse métodos virtuais, deve ainda assim verificar a validade do ponteiro ao aceder ao mesmo.

Na verdade, esta é uma questão ambígua. Por exemplo, esta verificação está sempre presente em C# e apenas se necessário em C++, o que dá uma vantagem em velocidade.

Afinal, se chamar um método que não acede aos campos de um objecto, não vale a pena verificar o ponteiro. Na essência, tal método é equivalente a um método estático.

[Ilya Malev]

Alexey Navoykov:

Em geral, esta é uma questão ambígua. Por exemplo, C# tem sempre um tal controlo, enquanto C++ só o tem quando necessário, o que dá uma vantagem de velocidade.

Porque se está a chamar um método sem referência aos campos do objecto, não vale a pena verificar o ponteiro. De facto, tal método é equivalente a um método estático.

Um objecto pode não ter quaisquer dados, mas pode implementar um comportamento absolutamente diferente e criticamente importante, por exemplo, referir-se a alguns dados externos de uma forma especial dependente do tipo, ou executar uma acção especial. Não sei como justificar tal abordagem como "equivalência do método ao método estático (ou seja, 100% não virtual) na ausência de dados".

Ou seja, pelo menos um objecto ponteiro tem sempre um campo - é o seu tipo. Por este campo podem ser determinados os endereços dos métodos a serem chamados. Caso contrário, porque é que precisa de OOP?

P.S. Embora para objectos automáticos eu pessoalmente não tenha nada contra pelo menos alguma lógica de comportamento (pois quase não os uso), mas então não os deve deixar ser atribuídos a apontadores

[Ilyas]

Infelizmente, enganei toda a gente, para as construções

B *b=a;
B b=a;

chama-se o operador da cópia em vez do construtor da cópia.
No segundo caso, depois de o construtor B() ser chamado

Em qualquer caso, vamos analisar primeiro, depois corrigir.

[pavlick_]

Oh, acontece que o µl tem um construtor de cópias auto-gerado (pensava que não existia de todo, uma vez que não se pode classificar obj(other_obj), apenas com =). Mas porque é que não é gerado se:

class Q
{
public:
   Q(Q&)=default;  // нельзя
   Q(int) {}       // из-за него копирующий конструктор исчез
};

[Ilyas]

pavlick_:

Oh, acontece que o µl tem um construtor de cópias auto-gerado (pensava que não existia de todo, uma vez que não se pode classificar obj(other_obj), apenas com =). Mas porque é que não é gerado se:

não são suportados por defeito e apagar.

O construtor de cópias por defeito, afinal, já foi feito até agora.

Apenas operador de cópia, ou seja, para construções:

CFoo foo=another_foo;

O construtor de CFoo por defeito é chamado primeiro, e depois o operador de cópia

[Alexey Navoykov]

Ilyas:

chama-se o operador da cópia, não o construtor da cópia.

Mas isto ainda é um erro, porque o operador de cópia implícita só deve ser criado para a classe B, e não para todas as classes-mãe. ou seja, o objecto não deve ser autorizado a substituir parcialmente os seus internos.

[pavlick_]

Ilyas:

não são suportados por defeito e apagar

Isso é verdade, mas só precisa de anular a geração do construtor de cópias quando há um construtor de cópias personalizado, não é verdade? Não qualquer personalizado.

[A100]

Alexey Navoykov:
Isto é, o objecto não deve ser autorizado a substituir parcialmente as suas partes internas.

Isto é uma espécie de auto-limitação artificial... Eu diria mesmo estreiteza de visão.

class A {};
class B : public A {
public:
        void operator =( const A& ) {}
};

Qual é o problema?

Encontrei tal desenho em mim mesmo... e funciona... muito bem. Por isso sugiro que os Desenvolvedores deixem as coisas como estão... pelo menos se os operadores/construtores correspondentes forem explicitamente definidos

[Alexey Navoykov]

A100:

Isto é uma espécie de auto-limitação artificial... Eu diria mesmo estreiteza de visão.

Qual é o problema?

Encontrei tal construção no meu lugar... e tudo funciona... muito bem. Por isso sugiro que os Desenvolvedores deixem as coisas como estão... pelo menos se os operadores relevantes forem explicitamente definidos

Verificar como funcionam as coisas em C++. Aparentemente, as suas regras foram inventadas por pessoas "de mente estreita".

E transformar-se sempre numa ficha para se proteger da arquitectura errada da língua... Não, tem de o fazer logo desde o início. Refiro-me à língua

[A100]

Alexey Navoykov:

Verifique primeiro como as coisas funcionam em C++. Aparentemente, as suas regras foram inventadas por pessoas "de mente estreita".

Mas fazer fichas sempre para se proteger de uma arquitectura de linguagem errada... Não, tem de o fazer logo desde o início. Refiro-me à língua.

Voltei a verificá-lo especialmente para si tendo em conta https://www.mql5.com/ru/forum/1111/page2358#comment_10003995

#ifdef __cplusplus
#include "https://www.mql5.com/ru/forum/1111/page2358#comment_10003995"
void OnStart()
{
        A a;
        B b;
        b = a;
}
#endif

Está tudo bem DJ