Mi enfoque. El núcleo es el motor. - página 83
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
El motor y el asesor trabajan en un flujo de comunicación. Cada celda de la tabla es un número de simovalores. Además, hay un montón de otros elementos que pasan sus valores, estados, etc. Necesita intercambiar filas rápidamente y no sobrecargar la cola de eventos OnChartEvent().
Toma SQL y no te rompas la cabeza :-)
¿Quieres decir que no tienes ni idea de cómo hacerlo con recursos y unión?
Después de ti, Nikolai.
Has ofrecido la opción con la unión, pero no me has mostrado un ejemplo. Luego se cambió aCharArrayToString yStringToCharArray. Ahora vuelve a hablar de una unión.
Entonces, ¿es la mejor solución pasar de String a Char y luego de vuelta, con la posterior división de las cadenas (las cadenas contienen un conjunto de números de parámetros y sus valores)?
Después de ti, Nikolai.
Dime, Peter, ¿también utilizas cadenas para pasar double, long e int?
El núcleo de los parámetros es un único array. Y es de tipo cadena. Por una razón: es un tipo universal. Es muy conveniente. Puede escribir cualquier valor y luego convertirlo al tipo requerido.
De lo contrario, sería necesario crear muchos núcleos de parámetros. Cada uno para su propio tipo de valor. Como resultado, tendríamos un lío con los atributos de los parámetros, su indexación, la ubicación de la escritura y muchas otras cosas.
No trolleemos. La tutoría no es apropiada. Entiendo más sobre este trabajo.
Nikolai, te dije que probaría tu versión). Así que lo haré.
toma SQL y no te preocupes por ello :-)
Como para seguir con lo de "no te metas en la cabeza" :-)
Hoy estoy amable y nada malvado...
Peter, sobre la "programación visual" (no sólo GUI), para el desarrollo, para no tener que construir un array sobre un array,
echa un vistazo a Oracle, por ejemplo. Uno de los claros líderes
El editor visual gratuito (junto con la máquina virtual) está aquí ; https://apex.oracle.com/en/
Todo lo que necesitas para empezar es un libro de "Los inicios de SQL para Dummies" y un par de días de tiempo libre.
No trolleemos. El tono de tutoría es inapropiado. Entiendo más sobre este trabajo.
No intento disuadirte de ello.
Por qué debería hacer el trabajo ingrato.No tenía ese tono. Es que ya he publicado varias veces código para ti mucho más rápido que el tuyo, con la esperanza de que lo aprendieras y aplicaras métodos más rápidos, pero nunca lo has aprovechado.
El núcleo de los parámetros es un único array. Y es de tipo cadena. Por una razón: es un tipo universal. Es muy conveniente. Puede escribir cualquier valor y luego convertirlo al tipo requerido.
De lo contrario, sería necesario crear muchos núcleos de parámetros. Cada uno para su propio tipo de valor. Como resultado, habría un lío con la propiedad de los parámetros, la indexación, la ubicación de la escritura y muchas otras cosas.
La versatilidad suele ser sinónimo de lentitud, y más aún con las cuerdas.
He aquí un ejemplo.
Una vez analicé una cadena obtenida de una bolsa de criptomonedas usando WebRequest. Y lo analicé usandola biblioteca JSON portado porSergeyev de "high speed C++ library". Y he notado que la velocidad es muy insatisfactoria. Allí todo se hacía a través de cuerdas "universales".
Entendí que la razón de la baja velocidad era el encadenamiento y quise evitar el uso de funciones de encadenamiento y escribí una función que parseaba directamente desde el array uchar. El resultado me sorprendió bastante. Mi velocidad de análisis fue .... (redoble de tambores) 800 veces más rápido. Si el análisis de una cadena completa a través de JSON tomó 0,3 segundos, mi función lo analizó en menos de la mitad de un milisegundo.
Aquí está un ejemplo de mi parsing a través de uchar array.
La versatilidad suele ser sinónimo de lentitud, y con las cuerdas aún más.
He aquí un ejemplo.
Una vez analicé una cadena recibida de un criptointercambio utilizando WebRequest. Y lo estaba analizando conla biblioteca JSON de Sergeev, que portó de la "biblioteca C++ de alta velocidad". Y he notado que la velocidad es muy insatisfactoria. Allí, todo se implementaba a través de cadenas "universales".
Quise alejarme de las cadenas y escribí una función que parsea directamente desde el array uchar. El resultado fue sorprendente. Mi velocidad de análisis es .... (redoble de tambores) 800 veces más rápido.
Aquí está un ejemplo de mi análisis a través de una matriz uchar.
el análisis sintáctico de json (y el análisis sintáctico en general) es una historia diferente ;-)
Tuve problemas en una aplicación de scripting de un solo hilo muy grande que trabajaba con crypto.
Las sospechas caían donde fuera y cómo se optimizaba todo. El problema parecía estar en el parser json de terceros :-)
Es porque las bibliotecas "universales" están diseñadas para la versatilidad y para trabajar con los json más complicados, pero en nuestro campo simplemente no hay ninguna,
y todas las parcelas son muy cortas.
Y sí, el análisis de texto en MQL es un verdadero placer :-). Bueno, no está diseñado para el análisis de texto. Es decir, se puede, pero es un dolor de cabeza.
Arrays, órdenes - ese es el dominio de MQL.