Adoptar apenas (*a) para se referir às funções dos membros não dá quaisquer vantagens claras, mas em vez disso leva à impossibilidade de uma aplicação múltipla simples e clara dos operadores.
Tente reescrevê-lo tendo em conta a sua sugestão
Não se pode usar o objecto em si em vez do ponteiro porque o operador <<(...) só pode devolver um ponteiro ao objecto.
Deve ter-me compreendido mal. Não estava a falar em desactivar a implementação actual. Pedi para tornar adicionalmente possível levar uma referência ou um ponteiro a um objecto para que não dependesse dos caprichos do compilador.E decidirei o que fazer em cada caso. Se precisar de um programa super fiável, posso facilmente fazê-lo da forma que descreveu. Sim, é complicado. Mas se as metaquotas introduzirem subitamente uma acção especial do operador << para indicações, não teremos medo disso.
Não disse para proibir a implementação actual. Pedi para fazer uma possibilidade adicional de levar uma referência ou ponteiro a um objecto, de modo a não depender dos caprichos do compilador.
Se (b) for um objecto, então a característica adicional (&b) para além do GetPointer( b ) existente é clara - aproxima a sintaxe de C++.
Se (a) for um ponteiro, a característica adicional (*a), para além da existente (a), dá provavelmente um compromisso razoável
class A {
booloperator==(A *);
A *operator<<(A *);
A *operator>>(A *);
};
void f()
{
A *a = new A();
if ( a == a ); //сравнение указателейif ( *a == *a ); //вызов operator==(A *)
a << a >> a; //вызов operator<<(A *) и operator>>(A *)
*a << *a; //вызов operator<<(A *)
}
Por um lado, é eliminada uma contradição e, por outro lado, a ordem existente não é quebrada
O compilador permite variáveis com nomes idênticos em parâmetros e corpos de funções dentro do mesmo âmbito
int f( int a )
{
int a = 10;
return ( a );
}
voidOnStart()
{
Print( f( 5 )); //Результат: 10, а должен был - выдать ошибку при компиляции
}
Embora seja gerado um aviso, não é suficiente para um erro tão difícil de encontrar (num código grande). Pelo menos o compilador C++ gera o mesmo erro no mesmo caso
Talvez a consequência do erro anterior seja que esta construção
class A {
public:
A( int a ) {}
};
void g( int a ) { Print( a ); }
int f( int a )
{
A a( 15 );
g( uint( a ));
return ( 8 );
}
voidOnStart()
{
Print( f( 5 ));
}
Encontrei um problema com a função"MarketBookGet". Não é estável, isto é, pode funcionar sem problemas, ou pode não funcionar de todo, isto é, retorna falso. Quem se confrontou com isso? Como é resolvido e qual é o problema? Corretor Otkrytie.
Quando o preço da ordem pendente é movido por drag'n'drop para um novo nível, o SL/TP muda juntamente com ele. Há alguma forma de o desactivar? Nem sempre se deve mover SL/TP em sincronia com o preço.
marketeer: Quando o preço de uma ordem pendente é movido por drag'n'drop para um novo nível, o SL/TP muda juntamente com ele. Isto pode ser desactivado? Nem sempre é necessário mover SL/TP em sincronia com o preço.
Como o vê? Vejo-o desta forma:
Se possuir a chave Ctrl, a ordem pendente será movida juntamente com o SL/TP. Se não pressionar o Ctrl, ele mover-se-á como está agora.
Note também que nas configurações do terminal, só se pode definir a gestão dos níveis de negociação quando se tem Alt. Depois, deve pressionar Ctrl+Alt para a interacção descrita acima.
Se possuir a chave Ctrl, a ordem pendente será movida juntamente com o SL/TP. Se não pressionar o Ctrl, ele mover-se-á como está agora.
Note também que nas configurações do terminal, só se pode definir a gestão dos níveis de negociação quando se tem Alt. Depois, para a interacção acima descrita, prima Ctrl+Alt.
Está na documentação? Li sobre Alt e utilizo-o, mas não sobre Ctrl.
marketeer: Quando o preço da ordem pendente é movido por drag'n'drop para um novo nível, o SL/TP muda juntamente com ele. Há alguma forma de o desactivar? SL/TP nem sempre deve ser movido em sincronia com o preço.
Se pode ser desactivado, não é claro o que faremos se o preço se mover e cruzar SL e/ou TP fixos
Adoptar apenas (*a) para se referir às funções dos membros não dá quaisquer vantagens claras, mas em vez disso leva à impossibilidade de uma aplicação múltipla simples e clara dos operadores.
Tente reescrevê-lo tendo em conta a sua sugestão
Não se pode usar o objecto em si em vez do ponteiro porque o operador <<(...) só pode devolver um ponteiro ao objecto.
Deve ter-me compreendido mal. Não estava a falar em desactivar a implementação actual. Pedi para tornar adicionalmente possível levar uma referência ou um ponteiro a um objecto para que não dependesse dos caprichos do compilador.E decidirei o que fazer em cada caso. Se precisar de um programa super fiável, posso facilmente fazê-lo da forma que descreveu. Sim, é complicado. Mas se as metaquotas introduzirem subitamente uma acção especial do operador << para indicações, não teremos medo disso.
Não disse para proibir a implementação actual. Pedi para fazer uma possibilidade adicional de levar uma referência ou ponteiro a um objecto, de modo a não depender dos caprichos do compilador.
Se (b) for um objecto, então a característica adicional (&b) para além do GetPointer( b ) existente é clara - aproxima a sintaxe de C++.
Se (a) for um ponteiro, a característica adicional (*a), para além da existente (a), dá provavelmente um compromisso razoável
Por um lado, é eliminada uma contradição e, por outro lado, a ordem existente não é quebradaO compilador permite variáveis com nomes idênticos em parâmetros e corpos de funções dentro do mesmo âmbito
Embora seja gerado um aviso, não é suficiente para um erro tão difícil de encontrar (num código grande). Pelo menos o compilador C++ gera o mesmo erro no mesmo casoTalvez a consequência do erro anterior seja que esta construção
Causa erro de execução: ficheiro EX5 inválido (8)Quem se confrontou com isso? Como é resolvido e qual é o problema? Corretor Otkrytie.
Quando o preço de uma ordem pendente é movido por drag'n'drop para um novo nível, o SL/TP muda juntamente com ele. Isto pode ser desactivado? Nem sempre é necessário mover SL/TP em sincronia com o preço.
Como o vê? Vejo-o desta forma:
Se possuir a chave Ctrl, a ordem pendente será movida juntamente com o SL/TP. Se não pressionar o Ctrl, ele mover-se-á como está agora.
Note também que nas configurações do terminal, só se pode definir a gestão dos níveis de negociação quando se tem Alt. Depois, deve pressionar Ctrl+Alt para a interacção descrita acima.
Como o vê? Vejo-o desta forma:
Se possuir a chave Ctrl, a ordem pendente será movida juntamente com o SL/TP. Se não pressionar o Ctrl, ele mover-se-á como está agora.
Note também que nas configurações do terminal, só se pode definir a gestão dos níveis de negociação quando se tem Alt. Depois, para a interacção acima descrita, prima Ctrl+Alt.
Será isto da documentação? Já li sobre Alt e utilizo-o, não sobre Ctrl.
Quando o preço da ordem pendente é movido por drag'n'drop para um novo nível, o SL/TP muda juntamente com ele. Há alguma forma de o desactivar? SL/TP nem sempre deve ser movido em sincronia com o preço.