Erros, bugs, perguntas - página 2271

Novo comentário
 
A100:
Um erro de compilação:

Qual é a diferença fundamental entre (1)(2) e (3)(4)?

Se declarar classes (3)(4) fora das funções - não ocorre qualquer erro. Se declarar dentro de uma função, ocorrem erros.

 
Vladimir Pastushak:

A que pode estar relacionado o seguinte comportamento

compilar o indicador funciona correctamente, compilar novamente o indicador não funciona correctamente. Funciona correctamente no testador?

Que indicador?

 
fxsaber:

O que é que o C++ produz aqui?

Para que funcione em MQL5, é necessário ter duas cordas diferentes na saída, não a mesma. Mas então o mecanismo de formação da assinatura deve ser absolutamente diferente. Se C++ der o mesmo resultado na impressão, o custo __FUNCSIG__ baixará drasticamente.

Resultado: C+++

void f<g1::A>( g1::A& )
void f<g2::A>( g2::A& )

Como pode ver, as cordas são diferentes. a assinatura da função é utilizada

 
A100:

Resultado: C+++

void f<g1::A>( g1::A& )
void f<g2::A>( g2::A& )

Como pode ver, as cordas são diferentes. a assinatura da função é utilizada

A MQL5 dá

void f<A>(A&)

Ou seja, não há nenhuma assinatura de classe dentro da função. Um dia, será apoiado.


E se a classe for global, que linha é que o C++ gera?

vazio f<::A>( ::A& )

vazio f<A>( A& )

 
fxsaber:

A MQL5 dá

Ou seja, não há nenhuma assinatura de classe dentro da função. Um dia, será apoiado.

Se os compiladores C++ obsoletos não o suportarem, eles já dão um erro na primeira linha (1) do código fonte. É por isso que a questão foi colocada desta forma em primeiro lugar: porque é que existe um erro num caso e um erro normal num outro?

Esperávamos o mesmo comportamento em ambos os casos: ou um erro ou nenhum erro. E o erro não está na falta de apoio em si, mas no comportamento desigual em condições de igualdade (como neste exemplo)

 
fxsaber:
E se a classe for global, que linha produz C++?

vazio f<::A>( ::A& )

vazio f<A>( A& )

A segunda variante

 
A100:

Se os compiladores C++ obsoletos não suportarem isto, eles já dão um erro na primeira linha (1) no código fonte. É por isso que a questão foi colocada desta forma em primeiro lugar: porque é que existe um erro num caso e um erro normal num outro?

Esperávamos o mesmo comportamento em ambos os casos: ou um erro ou nenhum erro. E o erro não está na falta de apoio em si mesmo, mas no comportamento desigual, sendo tudo o resto igual (como neste exemplo)

Bem, é fácil de explicar. O compilador vai de cima para baixo através do código formando as assinaturas correspondentes à medida que vai avançando. A primeira assinatura é criada sem qualquer problema. Chega-se à segunda e já existe uma tal assinatura. Aqui temos um erro na segunda linha.

 
Georgiy Merts:

Se declarar classes (3)(4) fora das funções, não ocorrem erros. Se declarar dentro de uma função, ocorrem erros.

Se no exemplo inicial
        class  A2 { int i; }; //(3)

substituir por

        interface  A2 {};      //(5)

Se declarar dentro de uma função, também não ocorrem erros... qual é a diferença fundamental?

 
fxsaber:

Portanto, é compreensível. O compilador vai de cima para baixo do código, formando as assinaturas apropriadas à medida que vai avançando. Cria a primeira assinatura sem qualquer problema. Chega ao segundo e já tem um. Assim, há um erro na segunda linha.

Então porque é que se compila em MQL sem erros?

template<typename T>
void f() { Print(__FUNCSIG__); }
void g1() { class A { int    x; } a; f<A>(); }
void g2() { class A { double x; } a; f<A>(); }
void OnStart()
{
        g1();
        g2();
}

Resultado: MQL C++

vazio f<A>() vazio f<g1::A>()
vazio f<A>() vazio f<g2::A>()

Porque é que as assinaturas são criadas aqui sem qualquer interferência?

 
A100:

Então porque é que se compila em MQL sem erros?

Resultado: MQL C++

vazio f<A>() vazio f<g1::A>()
vazio f<A>() vazio f<g2::A>()

Porque é que as assinaturas são criadas aqui sem qualquer interferência?

Uma só é criada. Além disso, em f não se pode usar T. De qualquer modo, a situação é óbvia para mim.

1...226422652266226722682269227022712272227322742275227622772278...3184
Novo comentário