Características del lenguaje mql5, sutilezas y técnicas - página 110
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
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Bichos, errores, preguntas
fxsaber, 2018.12.01 11:15
Diseño de superfrenoUn archivo de 40Mb de 1 millón de líneas tarda 18 segundos en leerse.
El mismo resultado de salida, pero hecho de manera diferente
Ya está hecho en 0,5 segundos.
Una contraparte simple de auto_ptr (considerada obsoleta). Nota: no es del todo análogo, con
...
https://habr.com/post/140222/
pavlick_
Hay que añadir una línea al principio a operator=:
Aunque probablemente valga la pena limitarse a algo así (no se puede copiar en absoluto):
¿Por qué hice copias para auto_ptr? Debido a la curvatura de µl - para copiar el objeto pila a CArrayObj hay que crear un montón de objetos llamando al constructor un montón de veces. Pero no creo que valga la pena. En este sentido, voy a retirar el primer post.¿Por qué hice copias para auto_ptr? Debido a la curvatura de µl - para copiar un objeto de pila a CArrayObj tienes que crear un montón de objetos llamando al constructor un montón de veces.
¿Y por qué "la curvatura de μl"?
¿Y por qué la "torcedura de la µl"?
La tarea trivial de añadir una copia de un objeto de pila a un array es añadir un constructor por defecto, que no necesitaba en primer lugar:
No es fatal, sí, puedes hacer init() en Q, lo que suavizará un poco el problema, pero aun así es un asco. Y al copiar auto_ptr a mano, todo pasa en dos líneas, pero el juego no vale la pena. Quizás demasiado exigente, perfeccionista.
La tarea trivial de añadir una copia de un objeto de la pila a un array resulta ser esto + tengo que prescribir un constructor por defecto, que no necesitaba en absoluto:
No es fatal, sí, puedes hacer init() en Q, lo que suavizará un poco el problema, pero sigue siendo desagradable. Y al copiar auto_ptr a mano, todo pasa en dos líneas, pero el juego no vale la pena. Quizás demasiado exigente, perfeccionista.
Pero es exactamente igual en C++ también, así que no está muy claro por qué el mcl torcido.
Y en tu caso es más fácil especificar el constructor de copia, y añadir elementos con una sola línea:
ar.Add(new Q(q));
La tarea trivial de añadir una copia de un objeto de la pila a un array resulta ser esto + tengo que escribir un constructor por defecto, que no necesitaba en absoluto:
No es fatal, sí, puedes hacer init() en Q, lo que suavizará un poco el problema, pero sigue siendo desagradable. Y cuando se ha copiado auto_ptr, todo pasa en dos líneas, pero el juego no merece la pena. Quizás demasiado exigente, perfeccionista.
Así es como todo sucede de todos modos - sólo se oculta detrás de su auto_ptr...
No veo ningún problema especial aquí.
Como veterano empedernido, me desagrada mucho el enfoque de C# en el que la memoria se borra automáticamente. En mi opinión, es la persona que ha solicitado la eliminación de objetos, y no unos "recolectores de basura", quien debería ser responsable de ello.
Pero es exactamente lo mismo en C++, así que no está muy claro por qué el mcl está torcido.
Y en tu caso es más fácil especificar un constructor de copia, y añadir elementos en una sola línea:
¿Cómo es lo mismo? Hay un constructor de copias allí automáticamente y todas las manipulaciones tendrán una mirada:
Y en tu caso es más fácil establecer el constructor de copia y añadir elementos con una sola línea
Por supuesto, es una clase de juguete por ejemplo, en la realidad son algunos datos también, probablemente mucho, no es una opción para escribir un constructor de copia en absoluto. Envuelto en los lugares correctos en envolturas y sin necesidad de un constructor personalizado.
Así que todo sucede de todos modos - sólo se oculta detrás de su auto_ptr...
No veo ningún problema en particular.
Como veterano endurecido, no me gusta el enfoque de C# en el que la memoria se borra automáticamente. En mi opinión, la persona que solicitó la eliminación de objetos debería ser responsable de ello, no un recolector de basura.
En µl, se puede prescindir de los punteros inteligentes. Recolector de basura != punteros inteligentes, no se puede prescindir de ellos al menos por las excepciones. A mí tampoco me gusta el recolector de basura.