¿Cómo puedo pasar por una enumeración de forma coherente? - página 3
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
Los ejemplos mostrados aquí (caso 1: valor de retorno1; caso 2: valor de retorno2; caso 3: valor de retorno3... Una persona adecuada pondría todos los valores en un array y sólo obtendría el valor requerido por su índice. Y para la tarea inversa utilizaría la búsqueda binaria.
Estoy a dos manos a favor de un código bonito con arrays. Pero al escribir un NormalizeDouble más rápido que el normal, me he encontrado con un efecto optimizador - una buena solución vía const-array era mucho más lenta que una engorrosa vía switch-case. He dejado la segunda variante porque NormalizeDouble se utiliza mucho en el probador. Lo pongo en el indicador y no miro a este monstruo. Pero las pruebas retrospectivas son más rápidas.
Recuerdo que una vez hubo un hilo en el que se discutía sobre switch, en el que los desarrolladores sólo hablaban de la implementación como búsqueda binaria, que por supuesto es mucho más lenta que el simple acceso por índice calculado.Pero ahora parece que lo han hecho de forma más inteligente: si un paso es constante, se calcula el índice, de lo contrario se realiza la búsqueda binaria. Por supuesto, la implementación nativa siempre es más rápida que la del wrapper.
Por supuesto, esto depende de tus prioridades. Pero, en mi opinión, si la velocidad es tan crucial que estás dispuesto a inventar muletas, entonces deberías abandonar la POO y el MQL también ;) Aunque estoy seguro de que con una codificación adecuada esta diferencia de velocidad no será tan significativa. En las mediciones de prueba sólo estás rebotando una función en un bucle millones de veces. Y lo usas más racionalmente en el código real, ¿no?
Recuerdo que una vez hubo un hilo en el que se discutía sobre switch, en el que los desarrolladores sólo hablaban de la implementación como búsqueda binaria, que por supuesto es mucho más lenta que el simple acceso por índice calculado.Pero ahora parece que lo han hecho de forma más inteligente: si el paso es constante, entonces se calcula el índice, en caso contrario, búsqueda binaria. Por supuesto, la implementación nativa siempre es más rápida que la del wrapper.
El compilador, si no es tonto, tendría que convertir la matriz const y el único tipo de referencia a ella por el índice en código de conmutación.
Por supuesto, es posible que tenga que hacerlo en función de sus prioridades. Pero en mi opinión, si la velocidad es tan crucial que estás dispuesto a inventar muletas, entonces deberías abandonar la POO y el MQL en general ;) Aunque estoy seguro de que con una codificación correcta la diferencia de velocidad no será tan sustancial. En las mediciones de prueba simplemente estás corriendo una función a través de un bucle millones de veces. Y en el código real lo usas más racionalmente, ¿no?
El compilador, si no es tonto, se habría visto obligado a convertir la matriz const y la única referencia al tipo por índice en código de conmutación.
¿Así que la matriz es sólo una const? ¿Y la estática? Es una operación simple: comparar el valor del índice con el tamaño del array/enum, y si es menor, obtener la dirección del elemento requerido como dirección del array + índice, y luego leer el valor desde allí. Pensaba que semejantes tonterías debían compilar igualmente.
¿Así que la matriz es sólo una const? ¿Y la estática? Es una operación simple: comparar el valor del índice con el tamaño del array/enum, y si es menor, obtener la dirección del elemento requerido como dirección del array + índice, y luego leer el valor desde allí. Pensé que estas tonterías debían compilar de la misma manera.
No recuerdo con certeza si se pueden crear matrices estáticas usando métodos const - ciertamente no. Por principio de cuentas estaba haciendo contras y no estáticas. Contar con la inteligencia del compilador. Después de la compilación, no debería haber ningún indicio de matriz en las tripas. Un statik es una estructura mucho más complicada que el const, por lo que estaba seguro de que el compilador no podría hacer frente al statik. Pero tendría que probarlo.
No recuerdo exactamente si las matrices estáticas pueden hacerse const. métodos - definitivamente no. Por principio, estaba haciendo contras, no estáticas. Contar con la inteligencia del compilador. Después de la compilación, no debería haber ningún indicio de matriz en las tripas. Un statik es una estructura mucho más complicada que el const. Por eso estaba seguro de que el compilador no se enfrentaría al statik. Pero tendría que probarlo.
Oh, bueno, eso lo explica. No deberías confiar en la excesiva inteligencia del compilador, que optimiza aún más una solución mal diseñada para ti. Si tú mismo eres demasiado vago para hacerlo correctamente, diciendo que "la estática es mucho más complicada" (aunque lo que es complicado ahí, no lo entiendo), entonces ¿por qué acusar al compilador?
Oh, bueno, eso lo explica. No hay que confiar en la excesiva inteligencia del compilador, ya que éste optimizará por ti una solución mal diseñada. Si tú mismo eres demasiado vago para hacerlo correctamente, diciendo que "la estática es mucho más complicada" (aunque lo que es complicado ahí, no lo entiendo), entonces ¿por qué acusar al compilador?
De nada. Me servirá de lección para el futuro, que debo pensar 7 veces, antes de andar inventando muletas).
Ahora resulta que alabé el interruptor, o más bien a sus desarrolladores demasiado pronto. Así que todo se implementa allí a través de la búsqueda binaria solamente, incluso cuando la enumeración va con múltiplos. No es bueno.
De nada, será una lección para el futuro, para pensar 7 veces antes de correr a inventar muletas )