Preguntas de un "tonto" - página 14

Nuevo comentario
 

Aquí hay otra cosa en la que pensar. ¡Hazlo!// Informar de los resultados. ;)

struct s_char8
  {
   char c[8];
  };
struct s_long
  {
   long l;
  };
void OnStart()
  {
    Print("//------ ");
    
    s_long L;
    L.l = 2387159478511726799;

    s_char8 Ch = L;

    string S = CharArrayToString(Ch.c, 0);
    
    Print(S);
   }
 
MetaDriver:

Sinceramente, estoy desconcertado, chicos, estáis jugando en igualdad de condiciones. Totalmente plana.

Sólo quería disculparme e interponerme en esta conversación "seria". Pero mientras salía a buscar cigarrillos, me ganaron.

Y no es que seamos "tontos", ¿verdad? Y este "boo-boo-boo" se hizo de la nada.

En la clase CExpert, lo corregiré a ulong.

 
Renat:

Te equivocas.

Sí, me olvidé de la conversión del tipo.

 
uncleVic:

Y no se trata de "tontos", ¿verdad?

Soy un tonto en muchos aspectos. Así que no entiendo cómo las funciones destinadas a devolver long van a devolver ULONG_MAX-1. Las trampas del manejo superficial de los tipos enteros están escritas casi en el propio Manual. sergeev ha captado correctamente el motivo de la pregunta: el control del orden. Si especifico request.magic como ulong, entonces espero que las funciones HistoryDealGetInteger(), PositionGetInteger() y OrderGetInteger() también devuelvan el tipo ulong. Sin conversiones de tipo explícitas-implícitas.

Sin embargo, sisus ejemplos explican que las conversiones de tipo long<->ulong no causan la pérdida de valores (a diferencia de double -> int, por ejemplo), entonces el proceso de pensamiento posterior se vuelve claro.

tíoVic:

Y tal "boo-boo-boo" se creó en un espacio vacío.

En realidad, el hilo de "Preguntas para tontos" fue elegido para obtener explicaciones, no amonestaciones.

 
Yedelkin:

Soy un tonto para muchas cosas. Así que no entiendo cómo las funciones destinadas a devolver long van a devolver ULONG_MAX-1. Las trampas del manejo superficial de los tipos enteros están escritas casi en el propio Manual. sergeev ha captado correctamente el motivo de la pregunta: el control del orden. Si especifico request.magic como ulong, entonces espero que las funciones HistoryDealGetInteger(), PositionGetInteger() y OrderGetInteger() también devuelvan el tipo ulong. Sin conversiones de tipo explícitas-implícitas.

Sin embargo, sisus ejemplos explican que las conversiones de tipo long<->ulong no causan la pérdida de valores (a diferencia de, por ejemplo, double -> int), entonces el proceso de pensamiento posterior se vuelve claro.

En realidad, el hilo "Preguntas de Dummie" fue elegido con el propósito de dilucidar, no de reprender.

¿Ofendido? Lo siento, no pude evitarlo.
 
uncleVic:
¿Se siente ofendido? Lo siento, no pude evitarlo.
No, no lo estoy. He tenido mi cuota de batallas en Internet. Sólo intento siempre dirigir la discusión en una dirección constructiva, por así decirlo.
 
sergeev:

En realidad no son 64, sino sólo 63 bits (es decir, 8 bytes incompletos). 8 bytes sería si se utilizara todo el rango largo.

Pero desgraciadamente...

Por un lado, la magia ulong se pasa a la estructura MqlTradeRequest. Significa que sólo se pueden establecer valores positivos.

Porotro lado, las funciones PositionGetInteger/OrderGetInteger devuelven el tipo long. Significa que la mitad del rango ulong se corta.

Lo que tenemos en realidad son 63 bits en lugar de los 64 descritos anteriormente. En realidad, no es tan malo como un gran inconveniente para los principios de comprobación del orden.

Sería mucho más conveniente utilizar el mismo sistema que en MT4 - permitir a los magos con una señal. Ya que muchos sistemas de trading se basan en un simple principio que utiliza el mismo símbolo de un mago. Ya que es mucho más fácil dividir un sistema en dos y filtrar sus órdenes utilizando la función habitual MathAbs( OrderMagicNumber() ).

los 64. De hecho. No se aferre a los tipos con o sin firma. Esto es para que el compilador se asegure de que las operaciones aritméticas son correctas (y hay un desplazamiento a la derecha, ya sea lógico o aritmético, dependiendo del tipo con signo).

No se pierde información durante la transferencia (asignación) y las fundiciones sin signo de datos del mismo tamaño. Prueba a hacer rebotar ULONG_MAX de un lado a otro. Intenta la asignación de largo-largo y de vuelta. Prueba a copiar la estructura.

Lo mejor es asegurarse por sí mismo. Entonces la cuestión quedará resuelta de una vez por todas.

 
MetaDriver:

Aquí hay otra cosa en la que pensar. ¡Hazlo!// Informar de los resultados. ;)

¡Hecho! Sustituya la línea 14 del código por L.l = 4548887299649496524.

De la descripción de la estructura MqlTradeRequest se deduce que magic es de tipo ulong, es decir, que se le pueden asignar valores superiores a la constante LONG_MAX. Sin embargo, las funciones del ... Las funcionesGetInteger() están diseñadas para trabajar con tipos largos, por lo que los valores mágicos serán implícitamente convertidos a tipos largos por estas funciones. Pero como existe una correspondencia uno a uno entre las variables de tipo long y ulong, al comparar el valor mágico con el resultado devuelto por las funciones de ...GetInteger() ,podemos utilizar con seguridad una conversión de tipo explícita (por ejemplo: magic == (ulong)OrderGetInteger(ORDER_MAGIC) ).

Gracias por mostrar repetidamente los ejemplos.

 

stringo:

No se pierde información en ningún lugar durante la transferencia de datos (asignación) y las fundiciones de datos del mismo tamaño sin firma. Prueba a hacer rebotar ULONG_MAX de un lado a otro. Intenta la asignación de larga duración y de vuelta. Prueba a copiar la estructura. Convénzase usted mismo y no difunda mitos.

Ya lo he probado y devuelve el resultado necesario al forzar el tipo (bueno, quizá haya que hacer un "baile de diamantes" adicional). Pero no es tan importante).

tíoVic:

Voy a cambiar la clase CExpert por ulong.

Me parece una buena idea, los que usen valores negativos en la magia tendrán que especificar forzosamente lo que deben devolver/establecer.

También estaría muy bien que la documentación indicara no sólo long o ulong, sino ambos tipos (por ejemplo, así "long / ulong").

 
stringo:

No se pierde información en ningún lugar durante la transferencia de datos (asignación), o durante los lanzamientosde datos del mismo tamaño sin signo.

Una pregunta adicional: ¿hay alguna forma elegante de preservar la información al transferir doble -> largo?
1...789101112131415161718192021...277
Nuevo comentario