Erros, bugs, perguntas - página 1358
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
Pessoalmente, este é um problema constante para mim, tenho de estar sempre atento, ou especificar A.operator=(B), A.operator!=(B) em todo o lado, ou seja, perde concisão e a sobrecarga do operador não faz realmente sentido.
Já levantei este problema uma vez, mas o assunto ficou parado. Vamos finalmente terminar esta questão.
Para que serve isso? Está de cabeça para baixo.
Faz mais sentido ao contrário: que < e > conduzam a uma comparação de ponteiro.
Isto já era discutido na altura (por favor, releia aquele fio antigo). Nos meus posts presumi que se lembraria se sugerisse: "vamos terminar esta pergunta".
Deixe-me repetir - dois operadores são sacrificados (== e !=) a fim de preservar as capacidades de todos(!) outros (não apenas < e >). A beleza em detrimento da funcionalidade.
para que não tenha de especificar explicitamente A.operator!=(B)
Bem, isso será resolvido em breve, espero, uma vez que os criadores finalmente me ouviram. Então será simples: *A != *B
Isto já foi discutido na altura (por favor releia aquele fio antigo) - repito - dois operadores são sacrificados (== e !=) a fim de preservar as capacidades de todos(!) outros (não apenas < e >)
Concordo que todos estes operadores devem ter o mesmo estatuto. Mas não da forma que sugere. Se ambos os argumentos são ponteiros, são os ponteiros que devem ser comparados um com o outro. Caso contrário, seria ilógico: ambos os argumentos são explicitamente dados pela GetPointer, mas de alguma forma os operadores de classe são executados. Assim, imho, os sinais de desigualdade seriam mais correctamente aplicados aos ponteiros neste caso.
No entanto, ninguém vai mudar o comportamento dos operadores de qualquer maneira, obviamente. Caso contrário, haverá uma confusão geral sobre os programas não laborais.
Mais uma vez, está sempre a esquecer-se do operador da missão. Sugere que a implementemos também através de uma função? Não seria demasiado cansativo?
Olá a todos,
Uma tal questão, inscrita para um sinal que é bastante fiável, então do nada começou o comércio em lotes loucos, tudo teria corrido bem no início, pois houve um lucro que acabou por se revelar uma perda de dinheiro no final. Pode dizer-me onde está enterrado o cão (de quem é a culpa?) e quem pode ajudar a resolvê-lo.
Olá a todos,
Uma tal questão, inscrita por um sinal que é bastante fiável, aqui do nada começou a negociar em lotes loucos, tudo teria corrido bem no início, uma vez que houve um lucro que acabou por se revelar uma perda de dinheiro no final. Pode dizer-me onde está enterrado o cão (de quem é a culpa?) e quem pode ajudar a resolvê-lo.
Um sinal que é bastante fiável, aqui do nada começou a negociar em lotes loucos
+100500
Pode dizer-me onde está enterrado o cão (de quem é a culpa?) e quem pode ajudar a resolvê-lo?
Dir-lhe-emos onde o cão está enterrado: atrás das garagens, mas de quem é a culpa - deve ir ao ramo do telepata, está algures neste fórum, pesquisá-lo no Google.
sim, a questão é que as ordens apresentadas no website na minha secção de sinais e o que a plataforma no meu telefone não corresponde.
não é sobre o sinal, o sinal é fiável, é sobre a transmissão, qual poderia ser a razão?
e o que posso fazer para fornecer o material se não o compreender de todo do ponto de vista técnico
E, mais uma vez, continua a esquecer-se do operador da missão. Oferece-se para a implementar também através de uma função? Não seria demasiado cansativo?
No caso de operator=(...) não há solução mais fácil do que usar a.operator=( b ) directamente
Se eles fizerem *A = *B - óptimo!