Errores, fallos, preguntas - página 2325

[TheXpert]

Ilyas:

¿Hubo buenas razones para abandonar el operador ->?

[Ilyas]

TheXpert:
¿Hubo razones de peso para abandonar el operador ->?

No, no había razones serias.

La única justificación de su ausencia es la preocupación por las mentes inmaduras de los usuarios no familiarizados con C++.

[Ilyas]

fxsaber:

¿Está optimizada la doble negación por el compilador?

Sí, así es.

[Koldun Zloy]

Ilyas:

No, no había razones serias.

La única justificación de su ausencia es cuidar las frágiles mentes de los usuarios no familiarizados con C++.

No creo que ocurra nada malo si lo añades.

Se puede permitir el uso de un punto con punteros donde no hay ambigüedad durante algún tiempo.

Y por supuesto emitir una advertencia.

[[Eliminado]]

¿Cómo puedo añadir un botón a los productos en el mercado: "Descargar prueba"?

[A100]

Koldun Zloy:

No creo que ocurra nada malo si lo añades.

Duranteun tiempo, es posible que se permita utilizar un punto con punteros donde no haya ambigüedad.

Y por supuesto emitir una advertencia.

¿Por qué hacerlo tan complicado? Es suficiente para que . y -> sean registros equivalentes e intercambiables.

En sentido figurado

#define ->   .

[A100]

fxsaber:

Sí, hay ambigüedad en su caso. En el buen sentido, debería haber al menos una advertencia del compilador para este tipo de cosas.

En mi caso, que es mucho más sencillo, todo está claro. Creo que C++ también está de acuerdo con eso.

Lo que quiero decir es que en mi caso MQL implica la opción (2), mientras que C++ implica la opción (1). Es decir, tienes una claridad imaginaria: un pequeño cambio (de clase A) y el significado cambia drásticamente

[fxsaber]

A100:
Tienes claridad imaginaria - un pequeño cambio (de clase A) y el significado cambia dramáticamente

Esto es un cambio en la clase y debería dar lugar a un mensaje del compilador correspondiente.

Si no está ahí, es una claridad total.

[A100]

Ilyas:

¡Como solución temporal, utilice el operador '! (lógico no).
Vamos a pensar en la solución (¿podemos cambiar el comportamiento ahora, cuando hay mucho código?)
Es posible que para un puntero, una operación de conversión bool sea una operación sobre el puntero y no sobre el objeto al que apunta.

Sin cambiar los códigos existentes, no funcionará... Todo el concepto de punteros como objetos dinámicos se derrumba

Es decir, en lugar de escribir simplemente

class A {
public:
        bool operator*( A* a ) { return true; }
};
void OnStart()
{
        A *a, *b;
        if ( a * b );  //(1)
}

tendremos que escribir uno confuso.

        if ( *a * *b );//(2)

¿Y todo esto para qué? ¿Para poder comprobar si un puntero es NULL? - Existe un operador de comparación para ello:

        if ( a != NULL );//(3)

¿Por qué duplicarlo?

[TheXpert]

A100:

todo el concepto de punteros como objetos dinámicos se derrumba

ahora no existe el concepto, un objeto y un puntero a él se mezclan en una pila