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
Que problema as pessoas têm)))) Terei uma vida longa!
A propósito, escreverd=array[5].to_double() é muito mais fácil do qued=(double)array[5] Apenas um ponto para pressionar. Mas não estamos procurando por caminhos fáceis.
Por que escrever d=(double)array[5]? Essa é a idéia - não se preocupar com essas trivialidades. Aqui está um pedaço de código real:
gráfico[índice] retorna estrutura {preço; tempo} E por que eu continuo adicionando .time/.price a ele, quando na maioria dos casos você pode entendê-lo a partir do contexto? Sim, às vezes você precisará ser rápido (como na penúltima linha), mas na maioria dos casos a vida será mais fácil e haverá menos escrita.
Que problema as pessoas têm)))) Terei uma vida longa!
A propósito, escreverd=array[5].to_double() é muito mais fácil do qued=(double)array[5] Apenas um ponto a ser pressionado. Mas não estamos procurando por caminhos fáceis.
Sim, claro, deve-se necessariamente escrever d=(double)array[5] quando já se sabe na hora da compilação que d não pode ser nada além de duplo. Os ratos choravam e imploravam, mas continuavam mordendo o cacto...
Sim, claro, é obrigatório escrever d=(double)array[5], quando já se sabe durante a compilação que d=(double )array[6], os ratos choravam e imploravam, mas continuavam a roer o cacto...
Em C++ eles sobrecarregam Oregatog<=> para d, roem e não choram ;-)
PS/ e em vista da associatividade e uso prioritário << operador como um operador mais adequadoPor que escrever d=(double)array[5]? Essa é a idéia - não se preocupar com essas trivialidades. Aqui está um verdadeiro fragmento de código:
E por que eu continuo acrescentando .time/.price a ele, quando na maioria dos casos podemos entendê-lo a partir do contexto? Sim, às vezes você precisará ser rápido (como na penúltima linha), mas na maioria dos casos a vida será mais fácil e haverá menos escrita.
O programador pretende sobrecarregar (duplicar) para quea matriz[5] devolva o dobro do número em vez de algum objeto. Não é assim?
Onde está este contexto no exemplo dado, onde podemos entendê-lo? É do tipo de parâmetro MYCRTMFLT? Isto é uma sobrecarga sobre o tipo do valor de retorno.
Se você realmente quiser, você pode fazer isso
etc.
Tenho medo de quebrar meu cérebro se eu continuar estudando seus códigos.
Quero dizer que tudo em seus métodos é admirável (sem brincadeira) exceto a abundância de letras maiúsculas com sublinhados e operações de resolução de contexto:)
Eu acho que se for permitido (operação de uma resolução de contexto) sobrecarregar, você, junto com suas bibliotecas, irá para a astral :lolol:
PS/ e, devido à associatividade e prioridades, usar o operador << como um operador mais apropriado
Ocorreu-me também, francamente. Sobrecarga <<< com >> e não sofrer. Mas isso não elimina a conveniência de permitir a sobrecarga de T()
Pelo que entendi, eles vão sobrecarregá-lo aqui, de modo que amatriz[5] não devolva algum objeto, mas o número duplique. Não é assim?
Onde neste exemplo este contexto pode ser compreendido? É do tipo de parâmetro MYCRTMFLT? Isto é uma sobrecarga sobre o tipo de valor retornado.
Eu não vejo nenhum problema:
A macro terminará com algum identificador ou chamada de função e o compilador entenderá o que se espera dela. E se não o fizer (compilar erro com juramento por ambiguidade), então você pode sempre ajudá-lo: gráfico[i].preço
Sim, claro, deve-se necessariamente escrever d=(double)array[5], quando se sabe já durante a compilação que d não pode ser outra coisa senão o dobro... os ratos choraram e choraram, mas continuaram a roer o cacto...
Além da d, há também algo mais com a matriz de nomes.
Não é nada mal quando o compilador avisa sobre a atribuição de tipos inadequados. Devemos mostrar ao compilador que aqueles que escreveram este código assumem total responsabilidade pelo resultado, para que não reclamem mais tarde da ausência de avisos gerados pelo compilador.
Eu não vejo nenhum problema:
...
Não é nada mal que o compilador avise sobre a atribuição de tipos inadequados. Precisamos mostrar ao compilador que aqueles que escreveram isto assumem total responsabilidade pelo resultado, para que eles não reclamem mais tarde da ausência de avisos do compilador.
Somente não nesse caso quando ele mesmo definiu o método double(){...} do operador para essa tarefa, obviamente não para que ele possa mais tarde escrever (double) após uma variável do tipo double ou receber avisos gerados pelo compilador.
Em geral, a conversa está obviamente indo em círculo, esperemos que a sobrecarga do tipo seja permitida eventualmente, eu pessoalmente não me importaria se, para permitir isso, eu colocasse um tique em algum lugar nas opções e confirmasse que "eu concordo em ser totalmente responsável pelo resultado".