Erros, bugs, perguntas - página 2025

Novo comentário
 

Erro duplo na execução

#define  XY( X, Y )      X##Y
#define  f( X )  XY( g, X )
#define  MACRO1( X )     #X
#define  MACRO2( X )     MACRO1( X )
#define  SIZE    5
void OnStart()
{
    printf( "%s", MACRO2( f( SIZE )));
}

Resultado: f(SIZE)

Deve ser: g5

 
leonerd:

Como remover as setas do gráfico de visualização do teste? Começo a testar e ainda há setas e linhas a partir das entradas do último teste.

Limpar o modelo tester.tpl, os objectos estão provavelmente lá.

 
A100:

Erro duplo na execução

Resultado: f(SIZE).

Deve ser: g5


A mim parece-me um resultado lógico.

 
fxsaber:
A mim parece-me um resultado lógico.

Esperada: Primeiro a substituição da macro SIZE interna, depois a macro intermediária f( X ) e finalmente a macro externa MACRO2( X )

Mas o resultado é diferente, mesmo que se utilize uma lógica incompleta:

#define  MACRO1( X )     #X
void OnStart()
{
    printf( "%s", MACRO1( f( SIZE )));
}
//Результат  :f(SIZE)
//должен быть:f( SIZE )

Pelo menos a diferença está nos espaços

 
A100:

Esperada: Primeiro a substituição da macro SIZE interna, depois a macro intermediária f( X ) e finalmente a macro externa MACRO2( X )

Mas o resultado é diferente, mesmo que se utilize uma lógica incompleta:

Pelo menos a diferença está no espaço branco

A prioridade das funções é, evidentemente, de dentro para fora. Com macros, por outro lado, é o contrário.

#X é um fio sem espaços. É claro que se pode discordar disto.

 
fxsaber:

A prioridade para as funções é, evidentemente, de dentro para fora. As macros, por outro lado, têm-no ao contrário.

#X é um fio sem espaços. Pode discordar com isto, claro.

Mas por que razão havemos de inventar novas regras complicadas com uma notação antiga, quando já existem regras antigas simples com tal notação - conhecidas de um vasto círculo de pessoas e estabelecidas há décadas? Se as regras são novas, então as designações também devem ser novas

 
A100:

Erro duplo na execução

Resultado: f(SIZE)

Deve ser: g5

Enviei um pedido semelhante ao Service-desk há um ano (#1600034), ainda não foi respondido. Parece que eles não se importam com todos estes insectos "totós". E, em geral, a língua não pretende melhorar, a julgar por todos. Apenas os grandes bugs são corrigidos, e não mais.
 
A100:

Porquê inventar regras novas e complicadas com designações antigas quando já existem regras antigas simples com tais designações - conhecidas por um vasto leque de pessoas e estabelecidas ao longo de décadas? Se as regras são novas, as designações também devem ser novas.

De que estamos a falar exactamente? Como deve ser?

 
fxsaber:

De que estamos a falar exactamente? E como deve ser?

#X é a corda tal como está - isto é, com espaços (se houver). E ver exemplo acima de f( TAMANHO ) -> g5. Eu próprio não inventei estas regras - é assim que os compiladores C++ o fazem

 
Alexey Navoykov:
Enviei um pedido semelhante ao Service-desk há um ano (#1600034), ainda sem resposta. Parece que eles não se importam com todos estes insectos "totós". E, em geral, a língua não pretende melhorar, a julgar por todos. Eles apenas corrigem os erros maiores, nada mais.

Ontem deparei-me com isto por acidente e fiquei surpreendido como em conjunto com

template<typename T, int n>

Várias dúzias de linhas de código transformaram-se literalmente em uma ou duas (!). Foi por isso que o escrevi - à primeira vista pode parecer uma bagatela. Mais uma vez, estou convencido de que não há disparates em C++

1...201820192020202120222023202420252026202720282029203020312032...3184
Novo comentário