Errores, fallos, preguntas - página 706
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
1.
Para crear matrices de punteros a estructuras (arrays) y luego inicializarlas for(i){ S[i] = GetPointer(StaticStruct[i]); }
2. mantener matrices sólidas (empaquetadas) de datos significativos.
Importante cuando se trata de la salida de datos a los búferes sin procesar de OpenCL (o el envío a DLL, la escritura a archivos, etc.)
Al mismo tiempo, es posible reordenar los accesos a los datos (por ejemplo, al ordenar los punteros) sin reescribir los datos.
Un lenguaje con ejecución segura no debería exponer/conceder acceso directo.
Las clases tienen más protecciones y por eso tienen un mango.
No habrá asas para otros objetos, ya que la seguridad es más importante.
En OpenCL, se puede utilizar cualquier tipo de datos para pasarlos, incluidas las estructuras. Allí se utiliza el void*. Sólo hay que preparar los datos uniformes en el formato requerido y ponerse a trabajar. Anticipándome a la pregunta "no quiero hacerlo así, quiero hacerlo a mi manera", respondería que no se puede hacer eso: la seguridad es más importante.
1. Cualquier tipo de datos puede ser utilizado para la transferencia de datos en OpenCL, incluyendo las estructuras. Allí se utiliza el void*. Sólo hay que preparar los datos uniformes en el formato requerido y ponerse a trabajar. Anticipándome a la pregunta "no quiero hacerlo así, quiero hacerlo a mi manera", responderé que no puedes hacerlo: la seguridad es más importante.
2. un lenguaje con ejecución segura no debe exponer/conceder acceso directo.
La cuestión es que para todas las clases, incluidas las más primitivas, el compilador de mql5 crea un VMT, con su correspondiente campo oculto en los objetos (puntero al VMT). Y este puntero en el buffer (archivo) en bruto es demasiado para mí. No sólo es una basura que ocupa espacio, sino que además rompe la alineación de los paquetes de forma inapropiada (los buffers de OpenCL tienen una alineación de 128 bits). Esa es la cuestión. Las clases son tentadoras de usar: son convenientes para trabajar en mql. Pero... ver arriba.
En Delphi hay un buen ejemplo alternativo de implementación. VMT y, en consecuencia, el puntero a VMT aparece en las clases sólo después de que aparezca el primer método virtual en la jerarquía de clases. Si fuera igual en mql5, la situación sería mucho más manejable. Se podrían usar clases sin métodos virtuales en lugar de estructuras y no habría "añadidos" que dañen la estructura.
Ahora me he encontrado con una situación en la que la implementación de una clase abstracta (destinada a la herencia) que encapsula un array de estructuras no se presta a servicios heredados (como la ordenación). La sustitución de una matriz de estructuras por una matriz de clases resuelve este problema, pero crea otro.... (ver arriba).
Y no pido ningún "acceso directo" ni me interesa ninguna aritmética de direcciones. ¿Por qué asustas a los niños para nada? :) la manija mql5 no es ni siquiera cerca de un puntero "crudo". Y si lo es (subrepticiamente) - por lo que el verdadero agujero de seguridad está aquí, no en la implementación de los handles (pseudo-pointers) a cualquier dato del usuario.
---
Ahora mismo tus estructuras son en realidad clases sin funciones virtuales (y VMT, respectivamente). Así que bien, sólo tienes que añadirles algunas funciones de clase (handles). Entonces tampoco necesitarás tanto los punteros a arrays (puedes envolverlos en estructuras si es necesario).
La cuestión no es que quiera hacerlo a mi manera; la cuestión es que para todas las clases, incluidas las más primitivas, el compilador de mql5 crea VMT con el correspondiente campo oculto en los objetos (puntero a VMT). Y este puntero en el buffer bruto (archivo) es demasiado para mí. No sólo es una basura que ocupa espacio, sino que además rompe la alineación de los paquetes de forma inapropiada (los buffers de OpenCL tienen una alineación de 128 bits). Esa es la cuestión. Las clases son tentadoras de usar: son convenientes para trabajar en mql. Pero... ver arriba.
En Delphi hay un buen ejemplo alternativo de implementación. VMT y, en consecuencia, el puntero a VMT aparece en las clases sólo después de que aparezca el primer método virtual en la jerarquía de clases. Si fuera igual en mql5, la situación sería mucho más manejable. Se podrían usar clases sin métodos virtuales en lugar de estructuras y no habría "añadidos" que dañen la estructura.
Ahora me he encontrado con una situación en la que la implementación de una clase abstracta (destinada a la herencia) que encapsula un array de estructuras no se presta a servicios heredados (como la ordenación). La sustitución de una matriz de estructuras por una matriz de clases resuelve este problema, pero crea otro.... (ver arriba).
Y no pido ningún "acceso directo" ni me interesa ninguna aritmética de direcciones. ¿Por qué asustas a los niños para nada? :) la manija mql5 no es ni siquiera cerca de un puntero "crudo". Y si lo es (subrepticiamente) - por lo que el verdadero agujero de seguridad está aquí, pero no en la implementación de los handles (pseudo-pointers) a cualquier dato del usuario.
Se quiere construir un sistema complejo con datos abstractos (lo que ya supone un montón de metadatos y relaciones internas) y luego entregarlo a un entorno OpenCL no controlado en el que se puede cambiar de forma complicada. Por eso sólo permitimos que los objetos simples y las matrices operen libremente sin la posibilidad de sobrescribir las tablas virtuales.
En realidad estás pidiendo indirectamente el acceso directo a través de la "libertad de construcciones abstractas". Este es un tema que hemos explorado bien y cubierto arquitectónicamente en aras de la seguridad. Las clases en MQL5 se rigen por sus propias reglas con énfasis en la seguridad. Otros tipos no tendrán asas. En lugar de manejadores para tipos y estructuras simples, puede utilizar índices en arrays.
Las propias asas en MQL5 son correctas (crecen a partir de una), puedes comprobarlo.
1. quieres construir un sistema complejo con datos abstractos (lo que ya supone un montón de metadatos y relaciones internas), y luego entregarlo a un entorno OpenCL no controlado en el que se puede cambiar de forma inteligente. por eso sólo permitimos que los objetos simples y las matrices operen libremente sin la posibilidad de sobrescribir las tablas virtuales.
2. en realidad estás pidiendo indirectamente el acceso directo a través de la "libertad de construcciones abstractas". Este tema está bien investigado por nosotros y cubierto arquitectónicamente en aras de la seguridad. Las clases en MQL5 se rigen por sus propias reglas con énfasis en la seguridad.
Las asas en MQL5 son correctas (crecen a partir de una), puedes comprobarlo tú mismo.
Quiero pasar los datos estrictamente limpios al buffer sin ningún tipo de metadatos (handles). No necesito estos metadatos en el buffer, ya que estorban allí. Y tampoco podré ponerlos allí: CLBufferWrite() no los dejará entrar. Y esto es correcto.
2. En realidad no estoy pidiendo ningún acceso directo, puedo usar DLL para el acceso directo (si lo necesito).
aPointer = memcpy(a,a);
resolverá el problema de obtener un puntero sin procesar. Renat, intenta entrar en el verdadero problema. No te inventes nada que no " exista realmente". Todo lo que existe en realidad - lo he descrito directamente y sin sutilezas en la solicitud. De la forma más constructiva posible y con pleno conocimiento de los problemas de seguridad.
3. Eso es genial.
--
No debe hacer la creación y eliminación dinámica de estructuras (nuevo, eliminar) en absoluto. Entonces los problemas de seguridad tampoco se plantean. Entiendo cuál es el problema "en realidad" (por decirlo en su lenguaje). Hay un problema de definición del tipo real para los objetos dinámicos. Para las clases lo más probable es que se resuelva analizando un puntero a VMT. Sin embargo: sin estructuras dinámicas, no hay problema.
Piénsalo, ¿qué es un "asa" en relación con una entidad de cualquier escala?
Puede proporcionar asas a objetos cuyo número sea razonable (clases, archivos, etc.). Pero si entras en un área de array de cualquier tamaño, cualquier asa sólo tiene la posibilidad de ser una referencia directa a un trozo de memoria. De lo contrario, la tabla de asignación "asa -> memoria" consumirá aún más memoria que la entidad a la que se hace referencia.
Y en base a la disposición de seguridad, no puedes tener handles que sean punteros directos a la memoria. Por eso no hay asas para "cualquier entidad no limitada".
Renat:
1. puede proporcionar asas a objetos cuyo número es razonable (clases, archivos, etc.). Pero si entras en un área de array de cualquier tamaño, cualquier asa sólo tiene la posibilidad de ser una referencia directa a un trozo de memoria. De lo contrario, la tabla de mapeo asa -> memoria consumirá aún más memoria que la entidad a la que se hace referencia.
2. Y en base a la cláusula de seguridad, no puedes tener handles que sean punteros directos a memoria. Por eso no hay asas para "cualquier entidad no limitada".
1. Lo constructivo es algo bueno. He estado pensando. El problema se planteó exactamente en relación con las estructuras masivas. Para las estructuras pequeñas el tiempo de copia es corto de todos modos. Creo que los problemas pueden surgir aquí sólo por la falta de racionalidad del usuario, pero se puede llenar "tontamente" la memoria de todos modos (con búferes indicadores, por ejemplo). No supongo que nadie prefiera trabajar con asas en estructuras estáticas sin ninguna necesidad particular. Y si se desborda la memoria, es su propia culpa. No te preocupes tanto por las tonterías folclóricas, de todos modos no hay manera de prevenir (ni siquiera de predecir) todo. :)
2. No, no. No es necesario tener punteros directos, pero no estaría de más tener asas, incluso "para cualquier entidad no restringida". Lo principal es que no hay obligación de usarlos. Así habrá suficiente memoria para todos. :)
No entiendo qué es lo que está ladrando aquí. Si quieres manijas, declara tus estructuras como clases, eso es todo.
Si quieres acceso directo a la memoria, escribe una dll.
No entiendo por qué te rompes la cabeza aquí.
1. si quieres manillas, declara tus estructuras como clases, eso es todo.
2. si quieres tener acceso directo a la memoria, escribe una dll.
1. Esa es la cuestión: es problemática. No necesito escribir un array de clases en el buffer (y es imposible). Necesito escribir estructuras allí. Y lo quiero rápidamente (sin reescribir realmente de las clases a las estructuras). Y las asas son necesarias para el acceso reordenado (para ordenar, además, con diferentes claves).
Un reemplazo podría ser mi propia tabla de índices - pero entonces no puedo hacer una clase que encapsule el trabajo con una matriz de estructuras con la capacidad de heredarla, junto con los servicios una vez prescritos (ordenación y búsqueda binaria).
2. ¡No lo quiero! ¡¡!! ¡¡¡Deja de hacer un caso para mí en el acto!!! :))
No, no haremos tales hendiduras. Se trata de una maldad absoluta, de la que tendremos que rendir cuentas hasta el final.
La solución ideal serían las clases parametrizables
class MyClass<T> { T MyArray[]; .... };Pero ya no hablo de eso, ¿tal vez debería?