Errores, fallos, preguntas - página 2358

[Alexey Navoykov]

Ilya Malev:

Aunque aunque el objeto no tuviera métodos virtuales, deberías comprobar la validez del puntero al acceder a él.

En realidad, esta es una pregunta ambigua. Por ejemplo, esta comprobación está siempre presente en C# y sólo si es necesaria en C++, lo que supone una ventaja en cuanto a velocidad.

Al fin y al cabo, si se llama a un método que no accede a los campos de un objeto, realmente no tiene sentido comprobar el puntero. En esencia, un método de este tipo es equivalente a uno estático.

[Ilya Malev]

Alexey Navoykov:

En general, se trata de una cuestión ambigua. Por ejemplo, C# siempre tiene esa comprobación, mientras que C++ sólo la tiene cuando es necesaria, lo que supone una ventaja de velocidad.

Porque si estás llamando a un método sin referencia a los campos del objeto, realmente no tiene sentido comprobar el puntero. De hecho, un método así es equivalente a uno estático.

Un objeto puede no tener ningún dato, pero puede implementar un comportamiento absolutamente diferente y de importancia crítica, por ejemplo, referirse a algún dato externo de una manera especial dependiente del tipo, o realizar una acción especial en absoluto. No estoy seguro de cómo justificar este enfoque como "método equivalente al método estático (es decir, 100% no virtual) en ausencia de datos".

Es decir, al menos un objeto puntero siempre tiene un campo: es su tipo. Mediante el cual se pueden determinar las direcciones de los métodos que se llaman. De lo contrario, ¿para qué se necesita la POO?

P.D. Aunque para los objetos automáticos personalmente no tengo nada en contra de al menos cierta lógica de comportamiento (ya que casi no los uso), pero entonces no deberías dejar que se asignen a punteros

[Ilyas]

Desgraciadamente, he engañado a todo el mundo, ya que las construcciones

B *b=a;
B b=a;

se llama al operador de copia en lugar del constructor de copia.
En el segundo caso, después de llamar al constructor B()

En cualquier caso, primero analizaremos y luego corregiremos.

[pavlick_]

Ah, resulta que µl tiene un constructor de copia autogenerada (yo pensaba que no existía, ya que no se puede clasificar obj(otro_obj), sólo con =). Pero por qué no se genera si:

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

[Ilyas]

pavlick_:

Ah, resulta que µl tiene un constructor de copia autogenerada (yo pensaba que no existía, ya que no se puede clasificar obj(otro_obj), sólo con =). Pero por qué no se genera si:

por defecto y eliminar no son compatibles.

Resulta que el constructor de copias por defecto, se ha hecho hasta ahora.

Sólo operador de copia, es decir, para las construcciones:

CFoo foo=another_foo;

Primero se llama al constructor CFoo por defecto y luego al operador de copia

[Alexey Navoykov]

Ilyas:

se llama al operador de copia, no al constructor de copia.

Pero esto sigue siendo un error, porque el operador de copia implícita sólo debería crearse para la clase B, no para todas las clases padre.

[pavlick_]

Ilyas:

por defecto y eliminar no son compatibles

Así es, pero sólo hay que anular la generación del constructor de copia cuando hay un constructor de copia personalizado, ¿no? No cualquier costumbre.

[A100]

Alexey Navoykov:
Es decir, no se debe permitir que el objeto sustituya parcialmente su interior.

Esto es una especie de autolimitación artificial... Incluso diría que la estrechez de miras.

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

¿Cuál es el problema?

He encontrado un diseño así en mí mismo... y funciona... bien. Así que sugiero que los desarrolladores lo dejen como está... al menos si los operadores/constructores correspondientes están definidos explícitamente

[Alexey Navoykov]

A100:

Esto es una especie de autolimitación artificial... Incluso diría que la estrechez de miras.

¿Cuál es el problema?

Encontré una construcción así en mi casa... y todo funciona... bien. Así que sugiero que los desarrolladores lo dejen como está... al menos si se definen explícitamente los operadores correspondientes

Comprueba para empezar cómo funcionan las cosas en C++. Al parecer, sus normas fueron inventadas por personas "de mente estrecha".

Y convertirse en un tapón cada vez para protegerse de la arquitectura errónea del lenguaje... No, hay que hacerlo bien desde el principio. Es decir, el lenguaje

[A100]

Alexey Navoykov:

Comprueba primero cómo funcionan las cosas en C++. Al parecer, sus normas fueron inventadas por personas "de mente estrecha".

Pero hacer tapones en cada momento para protegerse de una arquitectura de lenguaje equivocada... No, hay que hacerlo bien desde el principio. Me refiero al lenguaje.

Lo he revisado especialmente para ti, teniendo en cuenta 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á bien DJ