Cuestión de mecanografía - página 7

[pavlick_]

Dmitry Fedoseev:

Qué problema tiene la gente))) ¡Voy a vivir una larga vida!

Por cierto, escribird=array[5].to_double() es mucho más fácil qued=(double)array[5] Sólo un punto para presionar. Pero no buscamos caminos fáciles.

¿Por qué escribir d=(double)array[5]? Esa es la idea: no molestarse con estas trivialidades. Aquí hay un trozo 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);

chart[index] returns struct {price; time} ¿Y por qué le sigo añadiendo .time/.price, cuando en la mayoría de los casos se puede entender por el contexto? Sí, a veces tendrás que dar indicaciones (como en la penúltima línea), pero en la mayoría de los casos la vida será más fácil y habrá que escribir menos.

[Ilya Malev]

Dmitry Fedoseev:

Qué problema tiene la gente))) ¡Voy a vivir una larga vida!

Por cierto, escribird=array[5].to_double() es mucho más fácil qued=(double)array[5] Sólo un punto para presionar. Pero no buscamos caminos fáciles.

Sí, claro, hay que escribir necesariamente d=(double)array[5] cuando ya se sabe en el momento de la compilación que d no puede ser otra cosa que doble. Los ratones lloraban y suplicaban pero seguían mordiendo el cactus...

[Maxim Kuznetsov]

Ilya Malev:

Sí, claro, es obligatorio escribir d=(double)array[5], cuando ya se sabe durante la compilación que d no puede ser otra cosa que doble... los ratones lloraban y suplicaban, pero seguían royendo el cactus...

En C++ sobrecargan Oregatog<=> para d, roer y no llorar ;-)

PS/ y en vista de la asociatividad y las prioridades utilizar el operador << como más adecuado

[Dmitry Fedoseev]

pavlick_:

¿Por qué escribir d=(double)array[5]? Esa es la idea: no molestarse con estas trivialidades. Aquí hay un fragmento de código real:

chart[index] devuelve la estructura {precio; tiempo}. ¿Y por qué sigo añadiendo .tiempo/.precio cuando en la mayoría de los casos podemos entenderlo por el contexto? Sí, a veces tendrás que dar indicaciones (como en la penúltima línea), pero en la mayoría de los casos la vida será más fácil y habrá que escribir menos.

El programador pretende sobrecargar (double) para quearray[5] devuelva el número double en lugar de algún objeto. ¿No es así?

¿Dónde está este contexto en el ejemplo dado donde podemos entenderlo? ¿Es el tipo de parámetro MYCRTMFLT? Se trata de una sobrecarga en el tipo del valor de retorno.

[Ilya Malev]

fxsaber:

Si realmente quieres, puedes hacer esto

etc.

 _W(Color)[2] = (uchar)230;              // Записали по смещению 2 значение (uchar)230.
  PRINT(Color)                           // Убедились, что Color теперь C'241,248,230'

¿No eslo mismo quePrint(ColorToString(Color&(uint(-1)&65535)|(230<<16)); ?

Tengo miedo de romperme el cerebro si sigo estudiando sus códigos.

Quiero decir que todo en tus métodos es admirable (no es broma) excepto la abundancia de mayúsculas con guiones bajos y las operaciones de resolución de contexto:)

Creo, que si se permite que (la operación de una resolución de contexto) se sobrecargue, usted junto con sus bibliotecas irán al astral :lol:

[Ilya Malev]

Maxim Kuznetsov:

PS/ y, debido a la asociatividad y las prioridades, utilizar el operador << como más adecuado

A mí también se me ocurrió, francamente. Sobrecarga << con >> y no sufras. Pero no elimina la conveniencia de permitir la sobrecarga de T()

[pavlick_]

Dmitry Fedoseev:

Según entiendo, aquí lo van a sobrecargar, de manera quearray[5] no devolvería algún objeto, sino el número double. ¿No es así?

¿En qué parte del ejemplo se encuentra este contexto que se puede entender? ¿Es el tipo de parámetro MYCRTMFLT? Se trata de una sobrecarga en el tipo de valor devuelto.

No veo ningún problema:

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

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

La macro terminará con algún identificador o llamada a una función y el compilador entenderá lo que se espera de ella. Y si no lo hace (error de compilación con juramento sobre la ambigüedad), entonces siempre se puede ayudar: chart[i].price

[Dmitry Fedoseev]

Ilya Malev:

Sí, claro, hay que escribir necesariamente d=(double)array[5], cuando ya se sabe durante la compilación que d no puede ser otra cosa que doble... los ratones lloraban y lloraban, pero seguían royendo el cactus...

Además d también hay algo más con el nombre array.

No está nada mal que el compilador advierta sobre la asignación de tipos inapropiados. Debemos mostrar al compilador que los que escribieron este código asumen toda la responsabilidad del resultado para que no se quejen después de la ausencia de advertencias generadas por el compilador.

[Dmitry Fedoseev]

pavlick_:

No veo ningún problema:

...

Yo tampoco.

[Ilya Malev]

Dmitry Fedoseev:

No está nada mal que el compilador advierta sobre la asignación de tipos inapropiados. Tenemos que mostrar al compilador que los que han escrito esto se responsabilizan plenamente del resultado, para que no se quejen después de la ausencia de advertencias del compilador.

Sólo que no en ese caso cuando él mismo ha definido el método operador double(){...} para esta asignación, obviamente no para poder escribir después (double) después de una variable de tipo double o recibir advertencias del compilador.

En general, la conversación va obviamente en círculo, esperemos que se permita finalmente la sobrecarga de tipos, a mí personalmente no me importaría que para habilitarla se pusiera un tick en algún lugar de las opciones y se confirmara que "acepto ser totalmente responsable del resultado".