Erros, bugs, perguntas - página 2325

Novo comentário
 
Ilyas:
Haviam boas razões para abandonar o operador ->?
 
TheXpert:
Existiam razões sérias para abandonar o operador ->?

Não, não havia razões sérias.

A única justificação para a sua ausência é a preocupação por mentes imaturas de utilizadores não familiarizados com C++.

 
fxsaber:

A dupla negação é optimizada pelo compilador?

Sim, é verdade.

 
Ilyas:

Não, não havia razões sérias.

A única justificação para a sua ausência é a de cuidar das mentes frágeis dos utilizadores não familiarizados com C++.

Penso que nada de mal acontecerá se o adicionarmos.

Pode permitir a utilização de um ponto com apontadores onde não haja ambiguidade durante algum tempo.

E, claro, emitir um aviso.


 
Como posso adicionar um botão aos produtos no mercado: "Download Trial"?
 
Koldun Zloy:

Penso que nada de mal acontecerá se o adicionarmos.

Durantealgum tempo , poderá ser-lhe permitido utilizar um ponto com apontadores onde não haja ambiguidade.

E, claro, emitir um aviso.

Porquê torná-lo tão complicado? Basta fazer registos . e -> equivalentes, intercambiáveis.

Figurativamente falando

#define ->   .
 
fxsaber:

Sim, há ambiguidade no seu caso. De uma boa maneira, deveria haver pelo menos um aviso de compilação para este tipo de coisas.

No meu caso, que é muito mais simples, tudo é claro. Penso que C++ também concorda com isso.

O que eu quero dizer é que no meu caso MQL implica opção (2), enquanto que C++ implica opção (1). Isto é, tem clareza imaginária - uma pequena mudança (de classe A) e o significado muda drasticamente
 
A100:
Tem clareza imaginária - uma pequena mudança (de classe A) e o significado muda drasticamente

Isto é uma mudança na classe e deve resultar numa mensagem de compilação correspondente.

Se não estiver lá, é uma clareza total.

 
Ilyas:

Como solução temporária, utilizar o operador '! (não lógico).
Vamos pensar na solução (podemos mudar o comportamento agora, quando há muito código?)
É possível que para um ponteiro, uma operação de conversão bool seja uma operação sobre o ponteiro e não sobre o objecto para o qual aponta.

Sem alterar os códigos existentes, não vai funcionar... Todo o conceito de apontadores como objectos dinâmicos desaba

Quer dizer, em vez de apenas escrever

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

teremos de escrever uma confusa.

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

E tudo isto para quê? Para que um ponteiro pudesse ser verificado para NULL? - Existe um operador de comparação para isso:

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

Porquê duplicá-lo?

 
A100:

todo o conceito de ponteiros como objectos dinâmicos colapsa

não há conceito agora, um objecto e um ponteiro para ele estão misturados numa só pilha
1...231823192320232123222323232423252326232723282329233023312332...3184
Novo comentário