Qué significa el modificador const después de una declaración de método - página 3

Nuevo comentario
 
No es raro que también se utilicen intencionadamente este tipo de construcciones:
const TYPE1 Method( const TYPE2 Input ) const;
Y si no sólo cambio los datos internos del objeto, sino que tampoco accedo a ellos, inmediatamente escribo el método como estático. Para mí, el uso de const y static aumenta enormemente la legibilidad/comprensión de mi propio código. Y a menudo me permite detectar errores o fallos en mi propia arquitectura en las primeras etapas de la implementación.

Lo escribo todo sólo para mí. Y parece que no voy a cambiar algunos datos que no debería cambiar de todos modos. Pero el deseo de protegerme de mi propia estupidez me hace remachar la arquitectura OOP de tal manera, que sólo lo que debe ser accesible para cambiar. El resto no lo es. Y aquí los tipos de const + herencia son de gran ayuda. Lo recomiendo.
 
Dmitry Fedoseev:

Tal vez esta es una parte que se da de los creadores a los usuarios comunes. Como la función de inicio en el EA y las variables Bid y Ask. Cuando uno lo hace todo por sí mismo, no tiene sentido molestarse con todo tipo de const.

Por desgracia, tenemos que arrastrar todo este lastre en aras de la compatibilidad. Por otro lado, los pequeños códigos C y C++ se portan muy rápidamente a MQL (esto se ha comprobado muchas veces).
 

He observado una tendencia interesante: en la gran mayoría de los casos, los que no saben nada del tema hablan de lo monstruoso de los pluses. La mayoría de los afiladores, eso es típico.

Sí, por supuesto, Sharpe es mejor y más conveniente cuando se necesita hacer algo tan recto como un palo).

 
zaskok3:
No es un caso raro cuando uso tales construcciones intencionalmente:
Si no cambio los datos del objeto interno y no lo aplico, especifico el método como estático. Para mí, el uso de const y static aumenta enormemente la legibilidad/comprensión de mi propio código. Y a menudo permite detectar errores o fallos en la propia arquitectura en una fase temprana de la implementación.
...

Oh, chicos. Tengan piedad de MetaQuotes. Uno de los principales mandamientos de un programador: no usar nunca estática. Segundo mandamiento: si quieres utilizar la estática, consulta el primer punto:)

Si los datos estáticos son modificados por un hilo mientras otro los lee, aparecen tales maravillas de la programación multihilo, que uno puede recordar esta estática como un mal sueño.

Pero es bueno para los usuarios en MQL: no hay multithreading y, en consecuencia, ningún método cambiará los datos estáticos antes de que un hilo de usuario termine de leerlos.

 
Vasiliy Sokolov:

Uno de los primeros mandamientos de un programador: no usar nunca estática. Segundo mandamiento: si quieres utilizar la estática, consulta el primer punto:)

Si los datos estáticos son cambiados por un hilo mientras otro los lee, aparecen tales maravillas de la programación multihilo, que uno puede recordar esta estática como un mal sueño después.

Una vez más estoy convencido de que la discusión no funcionará )
 
Комбинатор:

He observado una tendencia interesante: en la gran mayoría de los casos, los que no saben nada del tema hablan de lo monstruoso de los pluses. La mayoría son afiladores, lo que es típico.

Sí, por supuesto, Sharp es mejor y más conveniente cuando se necesita hacer algo tan recto como un palo).

La clásica masa b pluses: "¿No te gustan los gatos? Simplemente no sabes cómo cocinarlos".

No, no lo niego, C++ como ningún otro lenguaje se puede ajustar a los estándares de desarrollo. Pero hasta que no llegues a estos estándares puede que te maten con tal rastrillo que o te conviertes en un programador de C++ realmente bueno o te rindes y te vas a 1C a hacer ERP-tickets.

 
Vasiliy Sokolov:

La clásica mascarada de la gente B: "¿No te gustan los gatos? Simplemente no sabes cómo cocinarlos".

Así son las cosas).

No tengo nada en contra de Sharp, ahora escribo bots en él, es cómodo y rápido.

Simplemente no me gusta que la gente eche barro sobre algo que no lo merece y además, algo que nadie está necesariamente obligado a usar.

Esto es válido tanto para los contras como para los pros en general.

 
Комбинатор:

Así son las cosas).

No tengo nada en contra de Sharp, ahora escribo bots en él, es cómodo y rápido.

Simplemente no me gusta que la gente eche barro sobre algo que no lo merece y además algo que nadie está obligado a usar obligatoriamente.

Esto se aplica tanto a los const como a los profesionales en general.

Ok, el mundo. Es que la discusión sobre C++ siempre desciende a una barahúnda.

Z.U. Si alguien me explica cuál es el problema de la const, se lo agradecería. Realmente no lo entiendo.

 
Vasiliy Sokolov:

Alexey escribió el ejemplo. Un método constante no puede modificar los miembros de su clase.

void bar(X& obj) const 
    {
        obj._x = 42; // OK! obj передается по ссылке и не имеет модификатора const
        _x = 42; // ERROR!
    }

Tal vez me estoy perdiendo algo, pero... aquí. Alexey escribió que el método constante bar cambia el objeto de su clase obj. ¿Cuál es el problema?

Sí, obj se pasa por referencia, pero el método aún no se ha convertido en constante...

 
Alexey Kozitsyn:

Tal vez me estoy perdiendo algo, pero... aquí. Alexey escribió que el método constante bar cambia el objeto de su clase obj. ¿Cuál es el problema?

Sí, obj se pasa por referencia, pero el método sigue siendo constante...

No es suya, sino de una totalmente ajena del mismo tipo.
1234567
Nuevo comentario