Errores, fallos, preguntas - página 2532

 
Igor Makanu:

todo funciona, pero las matrices que serán búferes indicadores deben describirse con el modificador public

Sí, por supuesto.

Por supuesto, el acceso público a los miembros de la clase no es bueno, pero el problema principal - el acceso a los datos de la matriz sin copiar se resuelve.

Gracias, la cuestión está aclarada.

 
Si la pregunta está resuelta, ¿puede ayudarme? Para vosotros, mamuts de la programación, es como una caña...
 
Georgiy Merts:

Por supuesto, el acceso público a los miembros de la clase no es bueno, pero el problema principal - el acceso a los datos de la matriz sin copiar se resuelve.

Veo muchos vídeos en YouTube, me encontré con un canal de un programador inteligente, y recuerdo la frase: "¡el código debe, ante todo, realizar su tarea!

Usted no trabaja en un proyecto grande, ¿verdad? - Sabes por qué se define este miembro de la clase y puedes controlar el acceso a él sin la ayuda del compilador, ¿verdad? ;)

 

@Ilyas, actualizado construir de mt4


código que funcionaba bien después de compilar y ejecutar los errores


 
Igor Makanu:

Veo muchos vídeos en YouTube, me encontré con un canal de un buen programador, y recuerdo la frase: "¡el código debe, ante todo, cumplir su cometido! ....

No trabajas en un proyecto grande, ¿verdad? - Sabes por qué se define este miembro de la clase y puedes controlar el acceso a él sin la ayuda del compilador, ¿verdad? ;)

En realidad el acceso a los miembros de la clase es mejor implementarlo a través de métodos y para tener menos desreferencias en tiempo de ejecución, utilizar inline con métodos get.
 
Igor Makanu:

Veo muchos vídeos en YouTube, me encontré con un canal de un buen programador, y recuerdo la frase: "¡el código debe, ante todo, cumplir su cometido!

No trabajas en un proyecto grande, ¿verdad? - Sabes por qué se define este miembro de la clase y puedes controlar el acceso a él sin la ayuda del compilador, ¿verdad? ;)

NO.

En primer lugar, el código debe ser transparente y comprensible, fácil de mantener. Y si no cumple su cometido, lo verás inmediatamente.

Pero cuando el código está lleno de muchos lugares con construcciones potencialmente inseguras que causan errores muy sutiles y no evidentes, nunca se puede estar seguro de que "el código cumple su cometido".

Y cuando se trabaja en un proyecto grande no se puede prescindir de él en absoluto, en muchas empresas hay directrices oficiales en cuanto a la notación, las declaraciones, lo que se puede y no se puede declarar como acciones, etc. Por supuesto, cuando trabajas solo, declaras un miembro de la clase, sabes para qué sirve y sabes cómo lo vas a utilizar. Salvo que cualquier código, por complejo que sea, aunque lo haga un solo programador, tiende a cambiar la arquitectura. Y yo personalmente no puedo recordar qué, dónde, cómo y para qué. Al mismo tiempo, sobrecargo generosamente el código con comentarios detallados. Y aún así, volviendo a otros fragmentos después de medio año, paso bastante tiempo para entender por qué se hizo así y no de otra manera. Sin los comentarios no sería capaz de entender mi propio código en absoluto.

Por supuesto, si tienes la memoria de Peter Konov no tienes que preocuparte por compartir el acceso, haz que todas las variables sean globales - y usa todo lo que necesites, cuando quieras. Sin embargo, mi memoria es mucho peor, y ya puedo olvidar sutilezas de un procedimiento en una semana. Por lo tanto, hace tiempo que desarrollé el principio de que en cualquier lugar del código debe haber disponible exactamente lo que necesito aquí y ni una sola variable más. La mejor manera es convertir todo en interfaces virtuales y dividir las áreas de responsabilidad de cada clase tanto como sea posible (pero por supuesto debe haber una medida, para no lidiar con estas envolturas más que con el código útil).

Recordemos que la falta de punteros a arrays los desarrolladores justifican "cuidando a los programadores", para que no se utilice accidentalmente un puntero a un array que ya no es relevante. Sin embargo, no hay problema para las clases. Bueno, nos explicaron que "si escribes con clases, ya eres lo suficientemente hábil para usar punteros, mientras que los arrays están disponibles para los principiantes, y no queremos que tengan problemas cuando quieran usar punteros a arrays... sin punteros, eso es"...

 
Vladimir Simakov:
Generalmente, es mejor implementar el acceso a los miembros de la clase a través de métodos, y para evitar la desreferenciación en tiempo de ejecución, utilizar métodos inline con get.

Así es. Y normalmente me inclino a hacerlo. Rara vez utilizo miembros públicos de la clase, sólo accedo a ellos con métodos inline. Sólo en casos especiales, como con estas matrices de indicadores, tengo que utilizar públicos...

 
Влад:
Si se resuelve el problema, ¿podríais ayudarme? Para vosotros, mamuts de la programación, es como una polilla...

En su caso, organice un bucle while() en lugar de un bucle for().

Comprueba si hay alguna señal de fin de parpadeo.

Pero sobre el "parpadeo con frecuencia variable" - algo extraño... No veo ningún error sobre la marcha, debería parpadear con bastante frecuencia.

Aunque, dudo que tenga sentido crear y eliminar objetos gráficos en lugar de hacerlos invisibles. Pero, supongo que no se puede hacer invisible un objeto... Así que lo único que queda es borrar.

 
Georgiy Merts:

Por supuesto, si tienes una memoria como la de Peter Konov, no tienes que preocuparte por la separación de accesos, haz que todas las variables sean globales, y utiliza todo lo que necesites, cuando quieras.

Nunca entreno la memoria, uso las variables globales sólo como último recurso, el código a veces incluso me parece redundante, pero los fragmentos de código son portables a otro proyecto,

Suelo utilizar nombres largos de funciones y variables, para poder leer lo que he escrito antes:

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }
Otra cuestión es que no me adhiero al estilo POO - no lo envuelvo todo en clases, utilizo los estilos procedimental y POO en un programa simultáneamente, es más conveniente y rápido formar un programa a partir de bloques ya hechos, lo que falte lo añado o lo modifico ya hecho a la tarea
 
Vladimir Simakov:
y para reducir la desreferenciación en tiempo de ejecución, utilice los métodos inline con get.
Inline es una reliquia, en mi opinión. El compilador inline todo perfectamente, por lo que no hay necesidad de sobrecargar el código. Y en MQL este especificador no es nada, se añade sólo por motivos de compatibilidad (no sé para qué, si se podría declarar una macro así por uno mismo).
Razón de la queja: