Errores, fallos, preguntas - página 2499

[Igor Makanu]

fxsaber:

Me gustaría llegar al fondo de esto.

la alineación de los datos no es

Print(sizeof(A)); // 2

aparentemente esto se hace considerando el uso interno de sizeof() , es decir,sizeof() no considera la memoria física, simplemente suma cada tipo en bytes

la alineación es una disposición de los datos en la memoria física, como está escrito en la ayuda "para transferir a los importados dll-funciones" - en diferentes compiladores y lenguajes de los tipos de datos pueden diferir en el tamaño o más bien la forma en que se almacenan en la memoria, por lo que debe utilizar struct A pack(4) para que cadamiembro de la estructura "no subió más allá de su caja" - bytes

Así es como se ve en la hubra del artículo:

struct Foo
{
    char ch;
    int value;
};

1 byte: ch

2 bytes: vacío

3 bytes: vacíoESTO eschar ch

4 bytes: vacío

5 bytes: valor[0]

6 byte: valor[1]ESTO esvalor int;

7 byte: valor[2]

8 bytes: valor[3]

[fxsaber]

Igor Makanu:

aparentemente esto se hace para acomodar el uso interno de sizeof() , es decir,sizeof() no tiene en cuenta la memoria física, sólo suma cada tipo en bytes

No es así.

struct A pack(4)
{
  short j;
  char i;
};

void OnStart()
{
  Print(sizeof(A)); // 4
}

[Igor Makanu]

fxsaber:

Este no es el caso.

entonces su ejemplo comprobó que sizeof() contaba correctamente el "peso" de la estructura en bytes,

lo único que queda por comprobar es la memoria física, pero en mi opinión sólo funcionará cuando se llame a la dll, no el hecho de que los desarrolladores no hayan sobreoptimizado el almacenamiento de datos en memoria ;) - es decir, si pack(4) no se utiliza como se pretende en el código, puede ser ignorado en el código ejecutable

[fxsaber]

Igor Makanu:

entonces su ejemplo comprobó que sizeof() cuenta correctamente el "peso" de la estructura en bytes

Por eso surge la pregunta: ¿cómo funciona realmente la alineación? La documentación y Habr no han revelado el algoritmo con sus ejemplos.

Igor Makanu:

Lo único que queda por comprobar es la memoria física, pero en mi opinión sólo funcionará cuando se llame a la dll, no el hecho de que los desarrolladores no hayan sobreoptimizado el almacenamiento de datos en la memoria ;) - es decir, si pack(4) no se utiliza como se pretende en el código, puede ser ignorado en el código ejecutable

La memoria física es similar.

struct A pack(4)
{
  short j;
  char i;
};

void OnStart()
{
  Print(sizeof(A)); // 4
  
  const int handle = FileOpen(__FILE__, FILE_WRITE | FILE_BIN);
  
  if (handle != INVALID_HANDLE)
  {
    A a = {0};
    
    FileWriteStruct(handle, a);
    Print(FileTell(handle)); // 4
    
    FileClose(handle);
  }
}

[Igor Makanu]

fxsaber:

Esto nos lleva a preguntarnos cómo funciona realmente la alineación. La documentación y hubr no han revelado el algoritmo con sus ejemplos.

depende del compilador específico, tal vez en MQL puedes probar la unión para ver cómo se guardaron los datos al usarpack(4)

[fxsaber]

Igor Makanu:

depende del compilador específico, probablemente puede tratar de buscar en la unión en MQL para ver cómo los datos se guardó cuando se utiliza pack(4)

Hay offsetof y otras formas de hacerlo.

HH Resulta que la fijación de una alineación sirve para hacerla inequívoca. Pero no para uso propio. Bueno, y se ve claramente que el orden de los campos afecta al consumo de memoria y, aparentemente, al rendimiento.

[Igor Makanu]

fxsaber:

Resulta que el ajuste de la alineación tiene como objetivo no dar ambigüedad. Pero no para uso propio.

y esto es"todo depende del compilador específico" - los desarrolladores a menudo van a los trucos para mejorar el rendimiento de sus desarrollos en relación con otros, no hay directivas del compilador en MQL - como la desactivación de la optimización del código fuente, etc. - no se puede ver la diferencia en el rendimiento o el uso de RAM del código nativo

SZZ: No estoy seguro de que el ejemplo con la escritura en el archivo siempre funciona correctamente, alguien escribió recientemente que MQL utilizar Win API cuando se escribe en el archivo, puede haber algunas suposiciones hechas por la compatibilidad con las funciones de la API - pero eso es mi conjetura, no soy un desarrollador de compiladores (((

[[Eliminado]]

fxsaber:

Hay otras formas de hacerlo.

Resulta que la fijación de una alineación sirve para hacerla inequívoca. Pero no para uso propio. Y puedes ver que el orden de los campos afecta al consumo de memoria.

Estás cavando en algún lugar equivocado, la alineación no es necesaria para ti en absoluto, es necesaria para que el procesador no obtenga algún int en dos líneas de caché. El lugar en el que se realizará el fetching no está regulado y depende del compilador, por lo que no se puede confiar en pack() a la hora de transferir al exterior, sólo en el fetching manual.

[fxsaber]

Vict:

Estás escarbando en algún lugar equivocado, la alineación no es necesaria para ti en absoluto, es necesario que el procesador no obtenga algún int en dos líneas de caché. El lugar en el que se realiza la adición no está regulado y depende del compilador, por lo que no se puede confiar en pack() cuando se transfiere al exterior, sólo en la adición manual.

Quedó claro, gracias a todos.

[Alexey Viktorov]

fxsaber:

Quiero llegar al fondo del asunto.

¿Qué hay que averiguar si la documentación dice claramente

El nombre de la estructura no puede utilizarse como identificador (un nombre de variable o de función). Tenga en cuenta que en MQL5 los elementos de una estructura se suceden directamente , sin alineación. En C++, esta indicación se hace al compilador mediante la función

#pragma  pack(1)

Y así sucesivamente...

Por lo tanto, no hay ninguna alineación en MQL5.