Petición inválida - acaba de empezar y no puede resolverlo... - página 7

 
papaklass:

Mi post es una respuesta a la pregunta de por qué no uso la biblioteca estándar

En realidad, yo también. Pero yo por la razón - que he creado mis clases mucho antes que MK.

y un intento de llamar la atención de los desarrolladores sobre la redundancia de metadatos en una clase.

No creo que sea redundante. así es la POO esencialmente. simplemente tienes una visión diferente de las envolturas, un diseño de clases diferente y una lógica de estructura comercial. probablemente sea una cuestión de gustos.

------------------------

Pero con los errores comerciales - demos ejemplos. ¿Tiene una forma universal de manejar, por ejemplo, 10008 -> 10012 ?
Digamos que, independientemente de las acciones anteriores y posteriores del Asesor Experto.
¿Cuál debería ser el resultado de la tramitación de este pedido que no ha abierto ...

 

Las funciones no utilizadas se excluyen en cierto modo del archivo final.

Otra cosa es que, casi siempre, el código "no universal" es más rápido que el universal (los EA, por ejemplo, se optimizan más rápido, y las claudes se pagan un poco menos).

 
No te olvides de la optimización del compilador + el inlining masivo.

Sólo se toman las funciones que se llaman en el código, y todo lo demás se omite durante la optimización. Es decir, si sólo se utilizan 3 de la clase con 61 métodos, se incluirá el código de tres métodos.

Las funciones en línea, teniendo en cuenta el pequeño tamaño de las propias funciones y la optimización del código en general, hacen que el código sea simple y plano.
 
papaklass:

Por lo tanto, el caso (10008 -> 10012) no me interesa, porque si la posición no se abre en un determinado tick, se abrirá en el siguiente.

Trato de construir mi código de tal manera que, si la lógica del Asesor Experto requiere la apertura de una posición, la posición se abre la mayoría de las veces. Ya sea que se abra en el siguiente tick o 10 ticks después,

ese es exactamente el enfoque correcto.

Y volviendo a la cuestión del tratamiento de errores, ¿qué falta en la biblioteca estándar? ¿Qué mejoras en la dirección del tratamiento/análisis de errores quieren introducir?

 
papaklass:

al abrir una posición con un lote superior a los fondos disponibles, o al colocar una orden pendiente, no se mantiene el paso mínimo permitido desde el precio actual, o se coloca un stop sin tener en cuenta la dirección de la posición.

¿Y qué significa el tratamiento de estas situaciones, la corrección de fallos en la orden del programador por la propia biblioteca?
es decir, ¿la propia biblioteca invierte las paradas o cambia el lote a su discreción?

¿o simplemente enviar el código correspondiente como respuesta y avisar al proger de su pedido erróneo?

 
sergeev:

y ¿qué significa el manejo de estas situaciones, la propia biblioteca que corrige las deficiencias de la orden del programador?
es decir, ¿para que la propia biblioteca invierta las paradas o cambie el lote a su antojo?

Un par de preguntas más inocentes y papaklass empezará a adivinar y sospechar algo...
 

Lo que ocurre es que los programadores tienen diferentes percepciones de la "necesidad y la suficiencia", por lo que se plantean cuestiones sobre la ampliación de la funcionalidad.

es mejor que lo tengan todo claro a que se queden adivinando.

 
papaklass:
Una vez más, no estoy convenciendo a nadie de nada. Si crees que la bibliografía está bien, déjala como está. Incluso después de la discusión, no utilizaré esta biblioteca. Yo solo, ¿puedo?

Alexander, no eres el único. Pero ese no es el objetivo de la pregunta. Ser o no ser.

La cuestión es puramente práctica, con beneficios para el desarrollo (posiblemente el suyo).

¿Qué significa el tratamiento de estas situaciones, la corrección de los defectos de la orden del programador por la propia biblioteca?
Es decir, ¿la propia biblioteca invierte las paradas o cambia el lote según su criterio?

¿O simplemente enviar el código correspondiente como respuesta y avisar al proger de su pedido erróneo?
 
papaklass:
... ¿Por qué no decirle al programador que su pedido no es válido y emitir un código de error antes de enviarlo?
Parece que la solicitud errónea se corta en la etapa del cliente y no llega al servidor.
 
papaklass:
La respuesta está en la superficie: ¿por qué enviar una orden al servidor que es incorrecta y esperar una respuesta? ¿Por qué no decirle al programador de inmediato que su orden es incorrecta y emitir un código de error antes de enviarla?
¿estamos hablando de añadir OrderCheck a CTrade::OrderSend?