¿Debería const un método que espera un cambio de estado?

Question

En un escenario de multiproceso, tengo un método como este:

bool WaitForChange(time_duration WaitTime) const; 

Este método espera o bien hasta que el estado del objeto ha cambiado y devuelve verdadero, o hasta que los tiempos de tiempo de espera a cabo (¿cómo se dice eso?) y devuelve falso.

Mi intuición es que const es para proteger contra los efectos secundarios no deseados del método en sí, así que esto está bien. Pero, de nuevo, algunos usuarios pueden pensar que el estado de la podría no haber cambiado, ya que el método está declarado const. ¿Es ese usuario estúpido, o debo hacer el método no const para evitar confusiones?

Answer 1

Al declarar el método como const, se dice "llamada a este método no cambia el estado del objeto." Esto es (con suerte) cierto. Entonces hazlo const.

Si alguien piensa, const -ness significa "Mientras se llama este método, nadie más puede cambiar el estado del objeto" que esa persona está equivocada.

Answer 2

Voto por constness.

El método en sí no cambia nada, sólo espera ...

Answer 3

Si está esperando ver si los miembros del objeto han cambiado ... ¿qué pasa con la volatilidad?

bool WaitForChange(time_duration WaitTime) volatile 

const implica el estado del objeto es el mismo en toda la llamada a la función, así que no lo usaría. volatile, por otro lado, indica al compilador que los miembros deben volver a buscarse cada vez que se accede a ellos, que es probablemente lo que desea si está buscando cambios.