Erros, bugs, perguntas - página 2419

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
O que acha de acrescentar à língua a capacidade de passar um argumento como um valor r? Isto resolveria imediatamente todos os problemas e permitiria a criação de recipientes universais para qualquer tipo.
como? ) Os recipientes universais precisam de ligações e setas, não deste material.
E o utilizador médio não é aquele que faz r-valor.
O que pensa de acrescentar à língua a capacidade de passar um argumento como um valor r? Isto resolveria imediatamente todas as questões e permitiria criar recipientes universais para qualquer tipo. Em particular, o método acima descrito seria sobrecarregado por valor r:
É exactamente assim que é implementado em todos os contentores STL.
E a segunda vantagem: permitirá definir construtores em movimento. Agora isto também está muito ausente, em particular para a implementação de apontadores inteligentes unique_ptr e outras classes, concebidos para monopolizar algum recurso único no interior, ou seja, os construtores de cópias habituais são inaceitáveis para eles.
Qual é então o objectivo de passar um parâmetro por referência?
Qual é então o objectivo de passar o parâmetro por referência?
Qual é então o interesse de passar o parâmetro por referência?
Também não percebo bem de que tipo de referência está a falar. Originalmente, estávamos a dizer que as referências de valor l (disponíveis em MQL) não cobrem todas as necessidades, o que foi demonstrado pela impossibilidade de passar uma constante ou valor de expressão para tal função. Para este efeito, é necessária uma referência de valor r, que aceitará todos os outros tipos. Assim, a combinação de duas funções sobrecarregadas de valor r e valor l garantirá que todos os tipos de argumentos serão aceites, independentemente da sua origem.
O que disse, que uma constante não é armazenada em qualquer lugar, mas criada na mosca, significa que deve ser passada como valor r, não como valor l (ao contrário de C++). Não faz diferença fundamental a forma como é interpretada, o principal é que pode ser aceite numa função.
O que disse, que a constante não é armazenada em qualquer lugar, mas é criada na mosca, significa que deve ser passada sob a forma de valor r, não de valor l (ao contrário de C++). Em princípio, não faz qualquer diferença na forma como é interpretada, desde que se possa aceitá-la na função.
A referência ao valor r implica na realidade um objecto para o qual o movimento será feito, ou seja, um objecto temporário deve ainda ser criado.
Na realidade, a referência ao valor r implica que existe um objecto para o qual o movimento será feito. ou seja, um objecto temporário tem de ser criado de qualquer forma.
Obviamente, o objecto existe sempre algures. Eu escrevi que este objecto é criado na mosca, ou seja, temporário.
Mas penso ter compreendido o que Slava estava a pedir. Ele queria dizer porque é que precisamos de aceitar um objecto temporário por referência quando o podemos aceitar por valor.
Bem, a questão é que é impossível sobrecarregar uma função simultaneamente para referência e valor numa só cópia:
Isto torna problemática a escrita de soluções universais. E ao substituir o valor por r-valor, obtemos uma variante de trabalho:
template<typename T> void f(T &&) { } template<typename T> void f(T const&) { }
Ele queria dizer porquê tomar um objecto temporário por referência quando se pode tomá-lo por valor.
porque
e porque normalmente é mais conveniente passar algo por referência do que por valor.
E se o método for modelado (que é onde tudo começou), então o comportamento actual simplesmente não lhe permite escrever correctamente.
E se o método for baseado em modelos (que é onde tudo começou), então o comportamento actual simplesmente não lhe permite escrever correctamente.
E ao substituir o valor pelo r-valor, obtemos uma versão funcional:
não realmente )
mover semântica implica dizer ao objecto a mover que não precisa de remover os seus internos. se o objecto for constante, precisaria de um membro de classe mutável, o mql não suporta isso
não realmente )
mover semântica implica dizer ao objecto a mover que não precisa de remover o seu interior. se o objecto é uma constante, precisa de um membro de classe mutável, o mql não suporta isto