Pergunta datilografada - página 7

 
Dmitry Fedoseev:

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:

MYCRTMFLT(i+1, chart[MYSEG(MYSCNT-i).start].time,
               chart[MYSEG(MYSCNT-i).start].price,
               chart[MYSEG(MYSCNT-i).top].time,
               chart[MYSEG(MYSCNT-i).top].price, 
               chart[MYSEG(MYSCNT-i).top].price>chart[MYSEG(MYSCNT-i).start].price?
                 MYCLRUP : MYCLRDOWN, STYLE_SOLID, true);

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.

 
Dmitry Fedoseev:

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...

 
Ilya Malev:

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 adequado
 
pavlick_:

Por 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.

 
fxsaber:

Se você realmente quiser, você pode fazer isso

etc.

 _W(Color)[2] = (uchar)230;              // Записали по смещению 2 значение (uchar)230.
  PRINT(Color)                           // Убедились, что Color теперь C'241,248,230'
Não é o mesmo quePrint(ColorToString(Color&(uint(-1)&65535)|(230<<<16)); ?

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:

 
Maxim Kuznetsov:

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()

 
Dmitry Fedoseev:

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:

double d;
d = chart[i];  // call operator double

void f(datetime t);
f(chart[i]);  // call operator datetime

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

 
Ilya Malev:

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.

 
pavlick_:

Eu não vejo nenhum problema:

...

Nem eu.
 
Dmitry Fedoseev:

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".