¿Por qué una declaración de función con un argumento const permite llamar a una función con un argumento no const?

Question

Tomar nota del siguiente código C++:

#include <iostream> 
using std::cout; 

int foo (const int); 

int main() 
{ 
    cout << foo(3); 
} 

int foo (int a) 
{ 
    a++; 
    return a; 
} 

en cuenta que el prototipo de foo() toma una const int y que la definición tiene un int. Esta compilación sin ningún error ...

¿Por qué no hay errores de compilación?

Answer 1

Porque a la persona que llama de la función foo no le importa si foo modifica su copia de la variable o no.

Específicamente en el estándar de C++ 03, los siguientes 2 fragmentos explicar exactamente por qué:

C++ 03 Sección: 13.2-1

Dos declaraciones de función del mismo nombre se refieren a la misma función si están en el mismo ámbito y tienen declaraciones de parámetros equivalentes (13.1).

C++ 03 Sección: 13.1-3

declaraciones de parámetros que difieren sólo en la presencia o ausencia de const y/o volátil son equivalentes. Solo los especificadores de tipos const y volátiles en el nivel más externo de la especificación de tipo de parámetro se ignoran de esta manera; Los especificadores de tipos const y volátiles enterrados dentro de una especificación de tipo de parámetro son significativos y se pueden usar para distinguir declaraciones de funciones sobrecargadas.

Answer 2

int foo (const int a) 
{ 
    a++; 
    return a; 
} 

Eso va a lanzar un error durante la compilación.

Answer 3

El nivel superior const (es decir, que se aplica al valor que se pasa, no es algo a lo que apunta o refiere) afecta solo a la implementación, no a la interfaz, de una función. El compilador lo ignora desde el punto de vista de la interfaz (es decir, el lado de la llamada) y lo impone solo en la implementación (es decir, código en el cuerpo de la función).

Answer 4

Como otros han explicado, la norma dice que está bien, y que el compilador puede permitirse ser indulgentes con la aplicación de esta, ya que no afecta a la persona que llama, pero nadie respondió por qué el compilador debe elegir ser indulgente. No es particularmente indulgente en general, y un programador que acaba de mirar la interfaz y luego se zambulle en la implementación puede tener en mente que un parámetro es const cuando no lo es o viceversa, no es algo bueno.

Esta indulgencia permite cambios de implementación sin modificar los encabezados, que al usar herramientas de creación tradicionales desencadena la recompilación del código de cliente. Esto puede ser un problema serio en el desarrollo de escala empresarial, donde un cambio no sustancial en un encabezado de bajo nivel (por ejemplo, el registro) puede forzar la reconstrucción de prácticamente todos los objetos entre él y las aplicaciones ... desperdiciando miles de horas de tiempo de CPU y retrasando a todos y todo lo que espera en las compilaciones.

Por lo tanto, es feo, pero una concesión práctica.

También he respondido otra pregunta similar que analiza por qué la sobrecarga de f (const T) y no está permitido f (T) - pueda ser de interés para cualquiera que lea esto - Top-level const doesn't influence a function signature