¿Por qué hay tan pocos expertos en la base de datos MQL5? - página 9
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
'MyStruct' - no se admite la declaración hacia delante
Ahí lo tienes. ¿Cómo se eliminan las dependencias cíclicas en la arquitectura?
No me digas que no pueden existir en una arquitectura normal. La única forma (muleta) es rediseñar la arquitectura añadiendo un montón de clases base innecesarias, lo que se convierte en un auténtico coñazo por la falta de herencia múltiple, que rechazaste, según tengo entendido, para no molestarte en implementar dependencias tipo rombo.
Pero podría haber implementado la declaración...
Bien, veamos si los "usuarios novatos imparciales" son capaces de escribir "algo realmente fundamental" en MQL5, en contraposición a los "programadores de sistemas profesionales".
¿Dónde he escrito que no puedan, querida? Sí, pueden, pero será algo tosco y pesado.
Ahí lo tienes. ¿Cómo se eliminan las dependencias cíclicas en la arquitectura?
Todavía no permitimos las descripciones hacia adelante debido al sistema de seguridad en casos de uso complejos.
Tenemos un lenguaje con controles muy estrictos tanto en la construcción como en la ejecución. No podemos permitirnos el lujo de tener un código potencialmente permeable debido a la relajación de los controles. La cuestión es que estas descripciones podrían estar en bibliotecas completamente diferentes y todavía no hay una forma estricta de controlar el uso en estos casos. A grandes rasgos, sería posible (no se puede hacer ahora) llevar a cabo un ataque arropando a una clase de zurdos con otros métodos.
Ya existe una solución al problema de las declaraciones de dependencias externas y cíclicas, pero la implementaremos después de lanzar el terminal de 64 bits (compilador, terminal, editor y probador). Ya hemos preparado una versión pública de 32/64 bits, que publicaremos esta semana.
Hasta que no se empiece a escribir un compilador de código gestionado con seguridad directa para el entorno de ejecución/terminal (C#/Java no tiene nada que ver, porque no es seguro para el entorno), es difícil entender las razones de las acciones de algunos desarrolladores.
Bueno, veamos si los "usuarios novatos imparciales" pueden escribir "algo realmente fundamental" en MQL5 a pesar de los "programadores de sistemas profesionales".
TheXpert:
¿Dónde he escrito que no puedan, querida? Sí, pueden, pero será algo tosco y duro.
Ahí lo tienes. ¿Cómo se eliminan las dependencias cíclicas en la arquitectura?
No me digas que no pueden existir en una arquitectura normal. La única forma (de muleta) es rediseñar la arquitectura añadiendo un montón de clases base innecesarias, lo que se convierte en un auténtico coñazo por la falta de herencia múltiple, que rechazaste, según tengo entendido, para no molestarte en implementar dependencias tipo rombo.
Pero podría haber implementado la declaración...
¿Dónde he escrito que no puedan, querida? Sí, pueden, pero va a ser algo sucio y pesado.
Con el debido respeto, permítanme decir que, a juzgar por el foro 5, son los expertos los que más murmuran y refunfuñan. Mientras los aficionados ordinarios aúllan y crean... Eres un experto, así que vive a tu nivel. Lo siento, en todo caso.
Eso es porque todo es relativo,
Los que nunca han estado al volante de un japonés con volante a la derecha no pueden entender cómo es posible cambiar la caja de cambios con la mano izquierda.
Y a un principiante no le importa, no sabe cómo cambiarlo, ni a la derecha ni a la izquierda.
Eso es porque todo es relativo,
Los que nunca han estado al volante de un japonés con volante a la derecha no pueden entender cómo es posible cambiar la caja de cambios con la mano izquierda.
y a un principiante no le importa, no puede cambiarla con la mano derecha o con la izquierda.
Ahí lo tienes, lo has liado todo. :)
Alguien que está acostumbrado a conducir un coche extranjero con un automático no puede moverse en un shakha con una caja de cambios jodida. Pero el que montaba en "clásico" dará ventaja a cualquier profesional en "japonés", si conduce en "japonés". Sólo estoy siendo filosófico, estoy de buen humor... Fíjate que no he dicho "principiantes", sino "aficionados".
Ahí lo tienes, lo has liado todo. :)
Cualquiera que esté acostumbrado a conducir un coche extranjero con un automático no puede moverse en un shakha con una caja de cambios jodida. Pero él, que monta un coche "clásico", dará ventaja a cualquier profesional en un coche "japonés", si monta un coche "japonés". Sólo estoy siendo filosófico, estoy de buen humor... Fíjate que no he dicho "principiantes", sino "aficionados".
Ya existe una solución al problema de las declaraciones de dependencias externas y cíclicas, pero la pondremos en práctica tras el lanzamiento del terminal de 64 bits (compilador, terminal, editor y probador). Ya hemos preparado una versión pública de 32/64 bits, que publicaremos esta semana.
Hasta que no te pongas a escribir tú mismo un compilador de código gestionado, con un énfasis directo en la seguridad para el entorno de ejecución/terminal (C#/Java no tiene nada que ver, porque no es seguro para el entorno), es difícil entender las razones de ciertas acciones de los desarrolladores.
Aquí está la solución a los constructores de objetos - también. Las razones para hacerlos inútiles no están claras.
No aceptan parámetros. ¿Debemos emular los parámetros ahora, utilizando variables globales para ello?
No existe ningún mecanismo para informar de que un objeto no se ha creado porque se ha producido un error irrecuperable al crear (inicializar) uno de los subobjetos. Se puede añadir una función de inicialización a todas las clases utilizadas en los subobjetos, y llamar a las funciones de inicialización de los subobjetos desde la correspondiente función de clase del propio objeto, lo que proporcionará la posibilidad de devolver el código de error. Pero, en primer lugar, uno debería llamar a dicha función explícitamente justo después de la creación del objeto y después de que se ejecute su constructor "bajo" (así como la función de desinicialización antes de destruir el objeto mediante el destructor), y, en segundo lugar, cuando se modifica la clase principal, por ejemplo, cuando se añade algún subobjeto, uno podría olvidarse fácilmente de incluir, y también en el lugar adecuado, para proporcionar la secuencia adecuada, la llamada de la función de inicialización del subobjeto añadido desde la función de inicialización de la clase principal (lo mismo se aplica a la función de desinicialización). Al fin y al cabo, prácticamente nadie escribe una cosa entera de golpe desde cero. Como resultado se obtiene un código semiautomático e inseguro.
Y el comunicado declarado como tal hace más de un mes no incluía una solución tan importante...
Estás provocando mucho asco al mezclar e inventar problemas que ni siquiera son para ti. Si te da tanto miedo escribir, déjalo.
Ya sabes lo que dificulta a un mal bailarín.
Con todo el respeto que me merecen, permítanme señalar: son los expertos los que más refunfuñan y se quejan, a juzgar por el 5º foro.
Así que hay mucho de qué quejarse. Poco después del lanzamiento de la primera beta pública, empecé a escribir un sistema de comercio. Casi inmediatamente eché de menos los constructores normales, y luego me rendí del todo, porque era imposible obtener un puntero sin crearlo explícitamente con el operador new. Ya entonces sugerí la posibilidad de importar clases, como una adición lógica a la luz de la creciente complejidad de los programas y su estructura (archivos de cabecera y de biblioteca o de objetos -- en algunos sólo las declaraciones necesarias, en otros la implementación).
Las clases de importación y las declaraciones de avance resuelven completamente el problema de la colocación del código.
Un constructor de copia simplifica el problema de los constructores.
El problema que me hizo parar está resuelto. Ahora hay una construcción GetPointer(this). Todo lo demás es (hasta ahora) solucionable dentro del lenguaje, pero me está arruinando la vida.
Tú eres el experto, sé adecuado a tu nivel, porque los entendidos buscan oportunidades y los ignorantes buscan razones... Lo siento, en todo caso.
Así que sigo escribiendo. Hablar aquí no interfiere con la escritura de código. No hace falta que te disculpes por ello: me he pasado.