Mi enfoque. El núcleo es el motor. - página 50
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
Vitaly, el problema es que Pedro es un titán de la memorización. No olvida dónde y qué índices tiene, qué significan, qué conexiones tienen y dónde.
Con una memoria tan impresionante las mejoras de OOP son sólo gestos innecesarios, y una cierta degradación del rendimiento. ¿Para qué?
OOP es para aquellos que no recordarán en una semana por qué pueden cambiar la variable en un lugar determinado y no en el vecino. Ellos son los que necesitan encapsulación, secciones de clases públicas, protegidas y prevertidas, interfaces virtuales, polimorfismo... Y cuando se tiene todo en memoria, como en un ordenador, es mucho más fácil acceder a cada objeto directamente, sin necesidad de mejoras OOP.
Sugerir a Peter una clase de smartpointers, que tenga en cuenta el número de referencias al pasar los objetos, y luego, cuando nadie se refiera a ellos, ¡borrarlos! Peter se sorprenderá, recuerda bien cuándo se crea cada objeto, cuántos usuarios tiene, cuánto tiempo debe existir y cuándo debe eliminarse. ¿Qué sentido tiene utilizarlos?
No, también se puede hacer eso. La única pregunta que me hago es ¿para quién? Peter dice que "creará una capa de usuarios de este tipo". Bueno, bueno... Ya veremos.
Un buen recuerdo es ciertamente bueno :) Pero la memoria tiene esta propiedad de que con la edad, empeora o se vuelve selectiva. Lo que recuerdas muy bien y lo que crees que es insignificante se te olvida inmediatamente. :)
Tienes un extraño espíritu competitivo :)
Sólo por interés, ¿podría utilizar su gui para crear un análogo de tal programa:
El programa se escribió en dos meses en 2013, con otro proyecto paralelo aún en curso.
El programa se compiló por última vez en 2014, por lo que es posible que haya algún percance :)
Es mejor ejecutar el programa en instrumentos cotizados.
Aclaración para los moderadores: este programa no está en el mercado.
Una interfaz gráfica de usuario buena y potente. Puedo reproducir el 85% de su mecánica con el constructor. También tengo ventanas dinámicas de arrastrar y soltar. El resto es tarea del programa (números parpadeantes en las celdas, llamados funciones).
En cuanto a las ventanas de instrucciones, eso también es reproducible. En resumen, en mi versión, la apariencia será ligeramente diferente, pero la funcionalidad será casi la misma.
Pero, la escala y los números no están implementados en mi versión. Y no hay escalamiento.
Sin embargo, a diferencia de este GUI, mis gráficos serán más bonitos. Gradientes, iconos, bonitos marcos, sombras... Los elementos están todos dibujados.
Pero, para un mercado moderno, su producto es muy potente. Probablemente uno de los más poderosos.
Y el hecho de que no haya mucha gente que lo haya comprado, puede agradecérselo a los probadores. Han hecho que todos los productos carezcan de sentido, excepto para ellos mismos.
¿y por qué este nuevo estilo?
Usted escribió que por cada 30-100 pedidos se encuentra un pedido para el panel de desarrollo, más a menudo no sucede, menos a menudo sucede
si quieres ser autónomo,entra en https://www.mql5.com/ru/search#!keyword=%D0%BF%D0%D0%B0%D0%BD%D0%B5%D0BB%D1%8C&module=mql5_module_jobs
esa es toda la demanda, y fíjese que los paneles son necesarios para comerciar, y a nadie le interesa la analítica y los calendarios en un panel
ZS: ¿Has escuchado el chiste de Joe elusivo? Con todo respeto, pero tu GUI es buena, pero a muy poca gente le interesa, con menos esfuerzo puedes conseguir cualquier resultado con una dll, haz un panel que en tu opinión los usuarios necesitan y en el Market, al mes serán estadísticas...
¡¡¡PS: nunca tuvo ningún deseo de lidiar con C# .Net, pero desde que los desarrolladores han hecho el apoyo, tuve que pasar una hora para encontrar un simple compilador de c con un diseñador de formularios - SharpDevelop (14 Mb) y buscar en Google cómo ejecutar un formulario de .dll, todo funciona y todo "gira", el código en sí, que prescribió las manos literalmente - 3 líneas!!!
Los desarrolladores de MQL han facilitado el trabajo con .dll en C#, sólo tienes que poner una dll ya hecha en la carpeta Librerías y escribir en las primeras líneas del Asesor Experto el nombre .dll - eso es todo ;)
Simplemente no quieres entender. ¿Qué diferencia hay? Su variante no es para las masas.
La gente busca beneficios. En esta búsqueda están pegados en uno y el mismo probador-grandes. Es decir, programas que prometen un enriquecimiento basado en las lecturas de los probadores. Eso es todo. Es un callejón sin salida desde aquí.
¿Durará para siempre? ¿Confiarán siempre en el probador? ¿Nunca se sentirán decepcionados al ver decenas de miles de robots "muertos"?
Propongo una salida al impasse. Programas semiautomatizados en los que el usuario será responsable de sus propias acciones.
¿Crees que nadie quiere esto? Se equivoca.
Peter, esa es la cuestión: no hay nada que usar. Cualquier ventana es un simple adorno o un punto de diálogo. El punto de diálogo implica la necesidad en este diálogo.
Imagina que eres un comerciante y el programa te pregunta algo. Necesita saberlo por ti. ¿Qué puede preguntarle, y usted puede responder a esta pregunta con un botón o un formulario? Me interesa mucho su opinión al respecto, contésteme si no le importa.
Y la segunda situación: usted considera necesario intervenir en el trabajo del programa - ¿qué botón / formulario le permitirá hacerlo de manera eficiente?
Estoy absolutamente de acuerdo contigo en que la automatización de una actividad es tarea de quien la automatiza, pero tú pretendes ser un creador de herramientas para desarrollar una interfaz hombre-máquina en este ámbito. ¿Una interfaz de botones y formularios, o una GUI normal que permita trabajar plenamente con todos los objetos gráficos de MT; una interfaz de objetos, o también interrupciones?
Usted pretende crear un estándar; yo, al automatizar algo, pretendo que cualquier, o casi cualquier, operación gráfica que genere sea aceptada por su interfaz. Si no, no nos necesitamos.
Cualquier ventana puede tener varias funciones posibles:
Cualquier ventana puede tener varias funciones posibles:
¡Esa es la razón y la respuesta!
Un buen recuerdo es sin duda una buena cosa :) Pero la memoria tiende a deteriorarse o volverse selectiva con la edad. Lo que recuerdas muy bien y lo que crees que es insignificante se te olvida inmediatamente. :)
Esa es tu memoria (y la mía también).
Peter tiene una memoria diferente y mejora con la edad, como un buen vino. Peter siempre recuerda todo lo que ha escrito, y cómo y por qué, y en qué estaba pensando. Así que realmente no necesita OOP.
Envidio la memoria de Peter.
Puedo reproducir el 85% de su mecánica con un constructor.
Tengo mis dudas :) Si sólo las ventanas, los botones, los controles... Pero eso es lo menos que hay.
Tu interfaz ni siquiera será capaz de procesar el tráfico de tumblr, y todavía necesitas renderizar algunos indicadores.
Ah, y esta es la primera versión de la librería gui, con un uso mínimo de kanvas, todo está ya implementado en kanvas ahora, excepto la entrada de texto.
La gente busca beneficios. En esta búsqueda, se fijan en los mismos griales de prueba. Es decir, programas que prometen un enriquecimiento basado en las lecturas de los probadores. Eso es todo. Es un callejón sin salida desde aquí.
¿Durará para siempre? ¿Confiarán siempre en el probador? ¿Nunca se sentirán decepcionados al ver decenas de miles de robots "muertos"?
¿Por qué iba a estar "muerto"?
Cualquier robot tiene periodos de ganancia. CUALQUIERA. Incluso los más flojos de mis MU de la Liga tienen poco tiempo de ganancia. Así que no hay manera de llamarlos "muertos".
Es como con la ropa. Por supuesto, pantalones cortos, chanclas y un traje de panamá para la vida en algún lugar de Arkhangelsk. Pero no dirá que son "ropa muerta". Además, algunos días puedes llevarlos incluso en Arkhangelsk.
Y viceversa: en la costa del Mar Negro el tulup y las botas de piel parecen una tontería en verano. Aunque, a veces, son muy necesarios incluso en la orilla del Mar Negro.
Lo mismo ocurre con los robots de trading: cada mercado tiene su propio robot de trading. Y la tarea del trader es seleccionar el robot que se adapte al mercado. Por eso no se puede decir que "la gente se va a decepcionar", igual que nadie se decepciona con unos pantalones cortos o unos pantalones panamá y nadie se decepciona con un chubasquero. Sólo hay que llevar la primera cuando hace calor y la segunda cuando hace frío.
El probador no es un obstáculo ni una panacea. Te dice lo que ha sido el mercado últimamente, y te permite coger un TS que se adapte a tus necesidades. Pero esto no significa que el mercado no vaya a cambiar en los próximos días, y que la ST no vaya a dejar de ajustarse a él. Sin embargo, es preferible un robot que haya obtenido beneficios en la historia que un robot que haya perdido en la historia.
El trading manual sólo puede ser rentable de forma constante si se tiene una gran experiencia. Sólo para entender cuándo y qué técnica utilizar. ¿Cree que mucha gente lo tiene?
Tengo mis dudas :) Si sólo las ventanas, los botones, los controles... Pero eso es lo menos que hay.
Su interfaz ni siquiera será capaz de procesar el tráfico de vidrio, y todavía tiene que renderizar algunos indicadores.
Sí, y esta es la primera versión de la librería gui, con un uso mínimo de kanvas, todo está ya implementado en kanvas ahora, excepto la entrada de texto.
El constructor está diseñado para soluciones genéricas. Su programa se personaliza para tareas específicas.
Puedes hacer y ejecutar una secadora en el constructor y funcionará. Pero el dibujo de todo tipo de indicadores no está incluido en las tareas del constructor hasta ahora.
Esto lo puede hacer el usuario en su programa.
Y qué decir del hecho de que no se tire del tráfico del vidrio:
Haga clic en la imagen para ver el gif. Como puedes ver, la velocidad de renderización de los elementos de la tabla es lo suficientemente rápida como para arrastrar el tráfico de la secadora (hay incluso más celdas).
Y en cuanto a no tirar del tráfico del tumblr:
Haga clic en la imagen para ver el gif. Como puedes ver, la velocidad de renderización de los elementos de la tabla es lo suficientemente rápida como para tirar del tráfico de la secadora (hay incluso más celdas).
No me refería a la velocidad de renderizado, sino al tráfico(intercambio) entre tu gui y el programa del usuario.
Por supuesto, cualquier programa está hecho a medida para una tarea específica, pero usando, por ejemplo, la biblioteca estándar, puedes añadir un objeto animado en la ventana, y en tu gui no, tienes que pedirlo :(