Erros, bugs, perguntas - página 1749
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Fiz um indicador de tiquetaque em kodobase. Mas não consigo anexar as fontes - pressiono "Anexar ficheiros", a inscrição desaparece, mas a interface de selecção de ficheiros não aparece.
talvez esteja instalado um bloco de anúncios? que bloqueia todos os pop-ups
Eu não mudei nada. Tudo estava a funcionar antes.
Ao fazer o check-out, carrego neste botão
Nada regressa, excepto isto.
Sim, compreendo a sua pergunta. Existe uma função com uma assinatura mais apropriada, mas não pode ser chamada porque está protegida. Sim, o comportamento é diferente de Studio: em MKL, há um controlo de tipo mais apertado (neste caso). Não sei se isso deve ser considerado um insecto. Se se controlar o tipo de argumento passado para a função, não há problema.
O controlo é bastante selectivo e, portanto, mais incoerente, o que se segue
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 ); //(*)
Mas C++ não analisa sempre uma classe base para um método mais adequado se o derivado tiver apenas um método adequado.
E MQL - no exemplo anterior, analisou a classe base para um método mais adequado, enquanto neste não o faz (aqui, bem como C++ chamará B::f/*(3)*/), o que significa que não existe uma abordagem unificada
Outro exemplo de controlo incoerente: C++ encontra o seguinte código
void f( int i ) const {}
void f( uint i ) {}
};
void OnStart()
{
A a;
a.f((int)0 );
}
O controlo é bastante selectivo e, portanto, mais incoerente, o que se segue
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 ); //(*)
Mas C++ não analisa sempre uma classe base para um método mais adequado se o derivado tiver apenas um método adequado.
E MQL - no exemplo anterior, analisou a classe base para um método mais adequado, enquanto neste não o faz (aqui, bem como C++ chamará B::f/*(3)*/), o que significa que não existe uma abordagem unificada
Outro exemplo de controlo incoerente: C++ encontra o seguinte código
void f( int i ) const {}
void f( uint i ) {}
};
void OnStart()
{
A a;
a.f((int)0 );
}
Que compilador C++ utiliza? Eu utilizo gcc e tudo passa sem erros
void f( int i ) const {} //1
void f( unsigned int i ) {} //2
};
void OnStart()
{
A a;
a.f((int)0 );
}
(1) ou (2). Vou agora inserir a mensagem do compilador
É realmente um controlo rigoroso: um método encaixa melhor em termos de assinatura, o outro em termos de coerência
Este é realmente um controlo rigoroso: um método é mais adequado por assinatura, o outro por constância
E não é claro porque escreveria tal coisa.
Substitua f -> operador[], tome o seu exemplo recente - pense em como fazer [] tanto à esquerda como à direita. Adicione constância ao sabor - depois embrulhe-o num modelo e terá algo semelhante.
Se const - considerar sem se
Se não puder haver ambiguidade, deve pelo menos emitir um aviso
Substitua f -> operador[], tome o seu exemplo recente - pense em como fazer [] tanto à esquerda como à direita. Adicione constância ao sabor - depois embrulhe-o num modelo e terá algo semelhante.
De que exemplo estamos a falar? Poderia dar não a fonte, mas a entrada final que deve funcionar?
Deveria acabar com algo como isto
{
A<int> a;
int b = a[ 0 ];
a[ 0 ] = a[ 1 ];
a[ 1 ] = b;
}
Deveria acabar com algo como isto
{
A<int> a;
int b = a[ 0 ];
a[ 0 ] = a[ 1 ];
a[ 1 ] = b;
}