Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
He hecho un indicador de tick en kodobase. Pero no puedo adjuntar las fuentes: pulso "Adjuntar archivos", la inscripción desaparece, pero la interfaz para seleccionar archivos no aparece.
tal vez un adblock está instalado? que bloquea todas las ventanas emergentes
No he cambiado nada. Antes todo funcionaba.
Al pasar por caja, pulso este botón
Nada vuelve, excepto esto.
Sí, entiendo su pregunta. Hay una función con una firma más apropiada, pero no puede ser llamada porque está protegida. Sí, el comportamiento es diferente al de Studio: en MKL, hay un control de tipos más estricto (en este caso). No sé si eso debería considerarse un error. Si se controla el tipo de argumento que se pasa a la función, no hay ningún problema.
El control es más bien selectivo y, por tanto, más incoherente, lo que se deduce de aquí
class A {
}public:
void f( int ) const {} /*(1)*/
void f( int ) {} /*(2)*/
};
class B : public A {
public:
void f( int ) const {} /*(3)*/
};
void OnStart()
{
B b; //не const B
b.f( 0 ); //(*)
Pero C++ siempre no analiza una clase base en busca de un método más adecuado si la derivada sólo tiene uno adecuado.
Y MQL - en el ejemplo anterior, analizó la clase base en busca de un método más adecuado, mientras que en este no lo hace (aquí al igual que C++ llamará a B::f/*(3)*/), lo que significa que no hay un enfoque unificado
Otro ejemplo de control inconsistente: C++ encuentra el siguiente código
void f( int i ) const {}
void f( uint i ) {}
};
void OnStart()
{
A a;
a.f((int)0 );
}
El control es más bien selectivo y, por tanto, más incoherente, lo que se deduce de aquí
class A {
}public:
void f( int ) const {} /*(1)*/
void f( int ) {} /*(2)*/
};
class B : public A {
public:
void f( int ) const {} /*(3)*/
};
void OnStart()
{
B b; //не const B
b.f( 0 ); //(*)
Pero C++ siempre no analiza una clase base en busca de un método más adecuado si la derivada sólo tiene uno adecuado.
Y MQL - en el ejemplo anterior, analizó la clase base en busca de un método más adecuado, mientras que en este no lo hace (aquí al igual que C++ llamará a B::f/*(3)*/), lo que significa que no hay un enfoque unificado
Otro ejemplo de control inconsistente: C++ encuentra el siguiente código
void f( int i ) const {}
void f( uint i ) {}
};
void OnStart()
{
A a;
a.f((int)0 );
}
¿Qué compilador de C++ usas? Yo uso gcc y todo pasa sin errores
void f( int i ) const {} //1
void f( unsigned int i ) {} //2
};
void OnStart()
{
A a;
a.f((int)0 );
}
(1) o (2). Ahora insertaré el mensaje del compilador
Eso es realmente un control estricto: un método es más adecuado en términos de firma, el otro en términos de constancia.
Esto es realmente un control estricto: un método es más adecuado por la firma, el otro por la constancia
Y no está claro por qué escribirías algo así.
Reemplazar f -> operador[], tomar su ejemplo reciente - pensar en cómo hacer [] tanto a la izquierda como a la derecha. Añade la constancia al gusto, luego envuélvelo en una plantilla y tendrás algo parecido.
Si hacer const - considerar sin si
Si no se puede ser inequívoco, por lo menos se debe emitir una advertencia
Reemplazar f -> operador[], tomar su ejemplo reciente - pensar en cómo hacer [] tanto a la izquierda como a la derecha. Añade la constancia al gusto, luego envuélvelo en una plantilla y tendrás algo parecido.
¿De qué ejemplo estamos hablando? ¿Podría dar no la fuente, sino la entrada final que debería funcionar?
Debería terminar con algo así
{
A<int> a;
int b = a[ 0 ];
a[ 0 ] = a[ 1 ];
a[ 1 ] = b;
}
El resultado final debería ser algo así
{
A<int> a;
int b = a[ 0 ];
a[ 0 ] = a[ 1 ];
a[ 1 ] = b;
}