¡¡¡Ideas ambiciosas !!! - página 4
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
Cálmate.
¿Por qué es una tontería? Sólo hay que calcular cuántos punteros se necesitan para llegar a los datos o a la función correcta.
Si ciertamente sabes contar. :)
Cuando se crea una nueva instancia de una clase - es decir, una variable de tipo de clase, se crea un duplicado de la tabla de relación y eso es todo
El acceso a los datos, tanto en la clase como en la variable habitual es el mismo en velocidad, todas las medidas descriptivas sobre la división de los derechos de acceso dentro de las clases (privat, public) - todo esto es a nivel del compilador, el código compilado trabaja sólo con celdas de memoria física
Bien, supongamos que habrá una "clase dinámica compleja" que se engendra astutamente sobre la marcha a partir de otras clases astutamente engendradas. ¿Y qué? Al fin y al cabo, todo será computado por una función específica. Entonces, ¿realmente valía la pena construir un jardín para tales trucos de circo?
¿Está avanzando la enfermedad? Te lo han dicho varias veces, la POO libera al programador de las acciones rutinarias de preparación de datos, del control sobre el contenido de los datos y depende del programador cómo implementas los métodos dentro de la clase o llamas a funciones de terceros
La OOP también es cosa del pasado. La tendencia actual es la programación orientada al hardware, que se realiza principalmente en C, por ejemplo, CUDA. Con el lanzamiento de los procesadores con GPU esto se potenciará aún más. Las empresas de procesadores están planeando dejar de lanzar sólo núcleos de procesadores universales.
Aquí no soy competente, y en su boca esta información no parece creíble
SZZY: por qué te escribo, no escribas tonterías en los foros técnicos, comparte tus conocimientos y si no sabes algo, pregúntame.
cuando se crea una nueva instancia de una clase - es decir, una variable de tipo de clase, se crea un duplicado de la tabla de relación y eso es todo
el acceso a los datos, ya sea en una clase o en una variable ordinaria, es el mismo en términos de velocidad, todas las medidas descriptivas para separar los derechos de acceso dentro de las clases (privat, public) son todas a nivel del compilador, el código compilado trabaja sólo con celdas de memoria física
Entonces aquí hay una pregunta para un experto. Hay una clase que consta de tres matrices dinámicas (el tamaño en tiempo de compilación es desconocido).
Ahora, por favor, calcule y compare el número de operaciones para acceder a un array estático arbitrario y a un array dinámico dentro de la clase.
No soy competente aquí, y en su boca esta información no parece creíble
¿Qué tiene que ver la lógica del programa con la presentación de los datos? Estas cosas no están conectadas en absoluto.
La lógica del programa son las operaciones aritméticas sobre cualquier dato de entrada, mientras que la representación de los datos son simplemente datos en un formato u otro.
Y por definición es imposible reducir el código del programa con la POO ya que aparecen punteros externos a los objetos para acceder a los datos internos (funciones y variables) en lugar de un acceso directo. Pero como el cálculo de los punteros y las referencias de memoria es una operación muy lenta, el rendimiento disminuye en consecuencia.
Desarrollar aplicaciones de POO no es lo mismo que desarrollar bibliotecas de clases. Estrictamente hablando, un desarrollador de bibliotecas no debería preocuparse _en absoluto_ por el uso que le darán a su biblioteca los que escriben los programas de aplicación. Por ejemplo: a un fabricante de martillos no le importa en absoluto el uso que se le dé a su producto: para clavar clavos o para partir nueces. Su trabajo es crear una herramienta. También en la programación orientada a objetos las clases son herramientas para resolver una determinada gama de tareas, normalmente muy amplia y no siempre claramente definida (¿quién sabe, tal vez se usa un martillo para matar cucarachas?)
Una vez más, para resolver las tareas más sencillas no se necesita OOP. Pero, por otro lado, no crees que todo el que quiera clavar un clavo tenga que fabricarse un martillo, ¿verdad?
Por supuesto, se puede argumentar que ya tenemos bibliotecas de funciones, ¿por qué necesitamos más clases? Pero en este caso te privas de las comodidades que proporcionan los mecanismos de herencia, las extensiones de tipo, la sobrecarga, etc. A grandes rasgos, puedes atornillar un motor casero a un martillo y hacer que funcione a tu manera, pero no tienes que entender el mecanismo del martillo; todo lo que necesitas saber es que puede utilizarse para clavar clavos.
Así que, créame, la POO realmente facilita la vida a los programadores que escriben aplicaciones. Otra cosa es que las capacidades de las librerías MQL5 son todavía muy limitadas, pero es cuestión de tiempo, y los desarrolladores de las librerías se encargarán de ello (aunque, por supuesto, pueden ser -pero no están obligados a ser- las mismas personas). Con un sistema bien desarrollado de bibliotecas de clases, es suficiente para un usuario-programador escribir una o dos líneas como "1. programa, aquí están los datos" "2. programa, cuenta", casi sin preguntarse cómo funciona en detalle. Esto no se puede lograr en la programación orientada a la estructura.
Me parece que tu prejuicio contra la POO es el resultado de que, o bien no te has encontrado con tareas suficientemente complejas, o simplemente no quieres hacerlo por pereza o alguna otra razón. Yo diría que para nada. Sin embargo, el maestro es el maestro.
Esta es la pregunta de un experto. Hay una clase que consta de tres matrices dinámicas (el tamaño en tiempo de compilación es desconocido).
Ahora, por favor, calcula y compara el número de operaciones para acceder a un array estático arbitrario y a un array dinámico dentro de la clase.
¿Qué tienen que ver las clases? Se trabaja con matrices dinámicas o estáticas, y no importa dónde se usen las matrices dinámicas: en una clase o sólo en una variable.
El hecho de que trabajar con arrays dinámicos lleve un poco más de tiempo es "difícil de entender" - hay un control para los desbordamientos de arrays y el gestor de asignación de memoria dinámica será llamado a menudo
alsu:
1. Pero en ese caso, te privas de la comodidad que ofrecen los mecanismos de herencia, extensiones de tipo, sobrecarga, etc. A grandes rasgos, puedes atornillar un motor hecho a mano a un martillo y hacerlo funcionar a tu manera, pero no tienes que entender la mecánica del martillo; todo lo que necesitas saber es que puedes clavar clavos con él.
2. Con un sistema bien desarrollado de bibliotecas de clases, basta con que un usuario-programador escriba una o dos líneas como "1. programa, aquí están los datos" "2. programa, cuenta" en un programa, casi sin preguntarse cómo funciona en detalle. Esto no se puede lograr en la programación orientada a la estructura.
1. En el RPP, también hay que ocuparse de las clases, de lo que hacen exactamente. Como si fuera una función de algún tipo. Pero con las clases es más difícil trazar toda la cadena, por lo que generalmente se dedica más tiempo a estudiar su estructura, al mismo nivel de funcionalidad.
2. En la programación orientada a la estructura, también se pueden organizar estas acciones sin problemas, sin tener que entrar en detalles en los que alguien ya ha entrado antes.
¿Qué tienen que ver las clases? Se trata de trabajar con arrays dinámicos o estáticos, y no importa dónde se usen los arrays dinámicos: en una clase o sólo en una variable
Bien, haré una pregunta más sencilla. Compara el número de operaciones al acceder a una variable de un array unidimensional y otro bidimensional.
¿Y ahora vas a argumentar que casi no hay diferencia?
Bien, entonces haré una pregunta más sencilla. Compara el número de operaciones al acceder a una variable en una matriz unidimensional y en una bidimensional.
¿Vas a afirmar que casi no hay diferencia?
¿Es esta también una pregunta de OOP?
Si no, entonces: si el array es estático - entonces no habrá diferencia en el rendimiento al acceder a los arrays unidimensionales y bidimensionales, porque los datos de los arrays multidimensionales se almacenan en la memoria por cadenas, como si tienes el array x[20] y el array y[2][10], entonces los datos de y se grabarán en la memoria: primero y[0] y luego y[1], que se ubicará físicamente como x[20]
si hay algún retraso en el rendimiento, es insignificante y sólo se produce por el control de rebasamiento de la matriz
Si el array es dinámico, depende del fabricante del compilador específico - cuánto del código del gestor de memoria está optimizado (en Delphi, la mayor parte del módulo System está escrito en ASM), porque la asignación de memoria para un array dinámico multidimensional es un poco más complicada, pero entonces, normalmente el problema no está en los arrays dinámicos, sino en el programador - cuán justificado y frecuente llama a la asignación de memoria para un array dinámico
SZS: gracias por la charla - pero no puedo por tu falta de comprensión de las cosas elementales pasar tanto tiempo - empieza a leer tú mismo
¿Es esta también una pregunta de OOP?
si no, entonces: si el array es estático - entonces no habrá ninguna diferencia en el rendimiento al acceder tanto al array unidimensional como al bidimensional, porque los datos del array multidimensional se almacenan en la memoria en cadenas, como si tienes el array x[20] y el array y[2][10], entonces los datos de y se grabarán en la memoria: primero y[0] y luego y[1], que se ubicará físicamente como x[20]
Te equivocas ya que no conoces las cosas más simples.
Los datos de cualquier matriz se almacenan en la memoria de forma lineal. Del primero al último, para acceder a un elemento x[15], hay que calcular la dirección del principio del array más el offset 15, que será la dirección de la variable para calcular esta variable. Si tenemos un array de dos dimensiones, por ejemplo, x[2][5], primero calculamos el desplazamiento de la segunda fila y luego le añadimos el desplazamiento del 5º elemento, es decir, el doble de operaciones.