Erros, bugs, perguntas - página 2521
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
fxsaber:
Подскажите, как в C++ с этим? Задумался, использовать эту фишку в своем коде или нет. Если в C++ работает, буду использовать. Нет - вряд ли, т.к. могут отменить в следующих билдах.
b = a; a = b; // OKA primeira tarefa só funciona em MQL. E é uma pena que funcione. Gostaria que finalmente abolissem este mal-entendido. Não há problemas com o segundo.
A primeira tarefa funciona apenas em MQL. Quem me dera que finalmente cancelassem este mal-entendido. Não tenho problemas com o segundo.
Isso é estranho. Pensei que o primeiro deve funcionar e o segundo não.
Isso é estranho. Pensei que o primeiro deve funcionar e o segundo não.
Bem, aparentemente, os desenvolvedores da MQL também não compreendem bem a essência da tarefa. Pois há muito tempo que lhes falo sobre este problema, mas ele atinge uma parede.
A essência da atribuição é que ao objecto é atribuído um objecto equivalente. Isto significa que o objecto direito é primeiro fundido ao tipo do objecto esquerdo implicitamente e só depois é que a atribuição (cópia) ocorre. E no primeiro caso tal fundição (A->B) é certamente impossível.Em C++ haverá um erro, mas em MQL em vez disso o objecto esquerdo é fundido para a direita e A::operator=(A&) é executado, substituindo apenas parte do objecto b. Isto é uma atribuição?
Imagine que está a atribuir int a longo prazo, mas apenas os primeiros quatro bytes estão a ser substituídos e o resto é deixado intocado. O mesmo se passa aqui.
Imagine que atribui uma int a um longo, mas apenas os primeiros quatro bytes são substituídos, e o resto é deixado intocado. Aqui é o mesmo.
Por isso é conveniente, acho eu. No contexto das estruturas, é claro.
Por isso, parece conveniente. No contexto das estruturas, é claro.
Pode salvar caracteres numa cadeia, mas é uma fonte de erros aleatórios e complica/distorce a compreensão do código. Como foi dito acima, o sinal de igualdade tem um significado claro e inequívoco de quetodo o objecto é alterado. É por isso que o operador não é utilizado como pretendido neste caso. Se pretende tal comportamento não normalizado, deve sobrecarregar o operador para tais fins.
p.s. A única excepção é se a classe B não tem campos próprios, ou seja, é exactamente igual à classe A (totalmente equivalente a ela), então não há razão para impedir esta atribuição, embora não funcione em C++ de qualquer forma, mas em MQL pode permitir.
No ficheiro opt-file, no pedaço onde todos os parâmetros de entrada são prescritos, o valor para parâmetros optimizados (definidos através de campos de tamanho e offset) não contém Valor (como sem optimização), mas Start.
Seria lógico ter aí Valor.
Bem, parece que os criadores de MQL também não compreendem bem a essência da atribuição. Pois há muito tempo que lhes falo sobre este problema, mas ele atinge uma parede.
A essência da atribuição é que ao objecto é atribuído um objecto equivalente. Por outras palavras, do mesmo tipo.
A essência das operações para tipos de utilizadores não está definida de antemão. E apenas é definida a sua ordem, que neste caso consiste em chamar o operador apropriado=.
Em MQL, ao contrário de C++ operator= é herdado, portanto b = a; é equivalente a chamar A::operator=(const A&);
Em geral, não há aqui qualquer contradição. No caso especial da atribuição de um objecto equivalente, existe alguma inconsistência de entidades, mas não mais do que isso
Em MQL ao contrário de C++ operator= é herdado, portanto b = a; é equivalente a chamar b.operator=(const A&);
Bem, sim, esse é o problema. Mas a diferença de escrita não desempenha aqui um papel. Em C++ não se compila em ambos os casos.
Em geral, não há aqui qualquer contradição. No caso especial da atribuição de um objecto equivalente, existe alguma inconsistência de entidades
Haverá uma contradição pelo menos com C++. Se compilar, significa que o operando da direita é implicitamente lançado para a esquerda e depois ocorre uma substituição completa do objecto, como deveria logicamente funcionar. Dei um exemplo com in>long. E a substituição de parte do interior de um objecto não é uma atribuição. Portanto, há tanto contradição como inconsistência.
p.s. Embora o operador B::operator=(A&) também possa estar sobrecarregado, mas suponho que um programador sensato substituiria aí o objecto B completamente em vez de parcialmente, pois esta é a essência da atribuição.
Se se quiser uma ortografia concisa, pode-se fazer outro operador para isso: &= ou |= por exemplo. Pelo menos não são comummente usados, por isso não há confusão.
..........
Uma contradição seria, pelo menos, com C++. ......
..........
O que o faz pensar que o MQL deve ser totalmente equivalente a C++ ???
Tipo C não significa equivalente!
A MQL é desenvolvida para tarefas definidas e não é obrigada a copiar completamente a língua com base na qual foi criada.
Vai deixar de ficar indignado?
Mas em Pascal pode .........
Em Assembler pode ir a .....
E em Java ....
E em BASIC ....
Pratica aqui a comparação de línguas?
=======
P.S. Não é só você...
O que o leva a pensar que a MQL deve ser totalmente compatível com C++ ???
...
Pratica aqui a comparação de línguas?
Eu estava a responder a uma frase específica. Acalme-se. Tome um pouco de valeriana e vá para a cama. Não é bom para si preocupar-se. ...Algumas pessoas ficam excitadas com a palavra "C++".