¿Debo devolver objetos constantes?

En el Effective C++elemento 03, utilice constante siempre que sea posible.

class Bigint
{
  int _data[MAXLEN];
  //...
public:
  int& operator[](const int index) { return _data[index]; }
  const int operator[](const int index) const { return _data[index]; }
  //...
};

const int operator[]hace la diferencia de int& operator[].

Pero que pasa:

int foo() { }

y

const int foo() { }

Parece que son iguales.

Mi pregunta es, ¿por qué usamos en const int operator[](const int index) constlugar de int operator[](const int index) const?

Se ignoran los calificadores de cv de nivel superior en tipos de devolución de tipos que no son de clase. Lo que significa que incluso si escribe:

int const foo();

El tipo de retorno es int. Si el tipo de retorno es una referencia, por supuesto, constya no es el nivel superior y la distinción entre:

int& operator[]( int index );

y

int const& operator[]( int index ) const;

es significante. (Tenga en cuenta también que en las declaraciones de funciones, como las anteriores, también se ignoran los calificadores cv de nivel superior).

La distinción también es relevante para los valores de retorno de tipo de clase: si regresa T const, entonces la persona que llama no puede llamar a funciones no constantes en el valor devuelto, por ejemplo:

class Test
{
public:
    void f();
    void g() const;
};

Test ff();
Test const gg();

ff().f();             //  legal
ff().g();             //  legal
gg().f();             //  **illegal**
gg().g();             //  legal

Debe distinguir claramente entre el uso constante que se aplica a los valores de retorno, los parámetros y la función en sí.

Valores devueltos

• Si la función regresa por valor , la constante no importa, ya que se devuelve la copia del objeto. Sin embargo, será importante en C ++ 11 con la semántica de movimientos involucrada.
• Tampoco importa para los tipos básicos, ya que siempre se copian.

Considere const std::string SomeMethod() const. No permitirá (std::string&&)que se use la función, ya que espera rvalue no constante. En otras palabras, la cadena devuelta siempre se copiará.

• Si la función regresa por referencia , constprotege el objeto devuelto de ser modificado.

Parámetros

• Si pasa un parámetro por valor , la constante evita la modificación de un valor dado por función en función . Los datos originales del parámetro no se pueden modificar de todos modos, ya que solo tiene una copia.
• Tenga en cuenta que dado que la copia siempre se crea, la const solo tiene significado para el cuerpo de la función , por lo tanto, se verifica solo en la definición de la función, no en la declaración (interfaz).
• Si pasa un parámetro por referencia , se aplica la misma regla que en los valores devueltos

Función en sí

• Si la función tiene constal final, solo puede ejecutar otras constfunciones y no puede modificar o permitir la modificación de los datos de la clase. Por lo tanto, si regresa por referencia, la referencia devuelta debe ser constante. Solo las funciones const se pueden llamar en un objeto o una referencia a un objeto que es const en sí mismo. También se pueden cambiar los campos mutables.
• El comportamiento creado por el compilador cambia de thisreferencia T const*. La función siempre puede const_cast this, pero, por supuesto, esto no se debe hacer y se considera inseguro.
• Por supuesto, es sensato usar este especificador solo en métodos de clase; Las funciones globales con const al final generarán un error de compilación.

Conclusión

Si su método no modifica y nunca modificará las variables de clase, márquelo como constante y asegúrese de cumplir con todos los criterios necesarios. Permitirá que se escriba un código más limpio, manteniéndolo const-correcto . Sin embargo, poner en consttodas partes sin pensar en ello ciertamente no es el camino a seguir.

Hay poco valor en agregar constcalificaciones a valores r que no son de referencia / no punteros, y no tiene sentido agregarlos a los valores integrados.

En el caso de los tipos definidos por el usuario , una constcalificación evitará que las personas que llaman invoquen una constfunción no miembro en el objeto devuelto. Por ejemplo, dado

const std::string foo();
      std::string bar();

luego

foo().resize(42);

estaría prohibido, mientras

bar().resize(4711);

estaría permitido.

Para integradas como int, esto no tiene ningún sentido, porque tales valores r no se pueden modificar de todos modos.

(Sin embargo, recuerdo que Effective C ++ discutió cómo hacer el tipo de retorno de operator=()una constreferencia, y esto es algo a considerar).

Editar:

Parece que Scott dio ese consejo . Si es así, debido a las razones dadas anteriormente, lo encuentro cuestionable incluso para C ++ 98 y C ++ 03 . Para C ++ 11, lo considero claramente incorrecto , como parece haber descubierto el propio Scott. En las erratas para C ++ efectivo, 3ª ed. , escribe (o cita a otros que se quejaron):

El texto implica que todos los retornos por valor deben ser constantes, pero los casos en los que los retornos por valor no constantes tienen un buen diseño no son difíciles de encontrar, por ejemplo, tipos de retorno de std :: vector donde los llamadores usarán swap con un vector vacío para "tomar" el contenido del valor de retorno sin copiarlo.

Y después:

Declarar los valores de retorno de la función por valor const evitará que estén vinculados a referencias de rvalue en C ++ 0x. Debido a que las referencias de rvalue están diseñadas para ayudar a mejorar la eficiencia del código C ++, es importante tener en cuenta la interacción de los valores de retorno constantes y la inicialización de las referencias de rvalue al especificar firmas de funciones.

Es posible que pierda el sentido del consejo de Meyers. La diferencia esencial está en el constmodificador del método.

Este es un método no constante (observe no constal final) lo que significa que puede modificar el estado de la clase.

int& operator[](const int index)

Este es un método constante (aviso constal final)

const int operator[](const int index) const

¿Qué pasa con los tipos de parámetro y el valor de retorno? Hay una pequeña diferencia entre inty const int, pero no es relevante para el punto del consejo. A lo que debe prestar atención es que la sobrecarga no constante devuelve, lo int&que significa que puede asignarle, por ejemplo num[i]=0, y la sobrecarga constante devuelve un valor no modificable (sin importar si el tipo de retorno es into const int).

En mi opinión personal, si un objeto se pasa por valor , el constmodificador es superfluo. Esta sintaxis es más corta y logra el mismo

int& operator[](int index);
int operator[](int index) const;

La razón principal para devolver valores como const es que no puede decir algo como foo() = 5;. En realidad, esto no es un problema con los tipos primitivos, ya que no se pueden asignar valores r de tipos primitivos, pero es un problema con los tipos definidos por el usuario (como (a + b) = c;, con una sobrecarga operator+).

Siempre he encontrado la justificación para eso bastante endeble. No se puede detener a alguien que tiene la intención de escribir un código incómodo, y este tipo particular de coerción no tiene ningún beneficio real en mi opinión.

Con C ++ 11, en realidad hay mucho daño que este idioma está haciendo: devolver valores como const evita las optimizaciones de movimiento y, por lo tanto, debe evitarse siempre que sea posible. Básicamente, ahora consideraría esto como un anti-patrón.

Aquí hay un artículo relacionado tangencialmente sobre C ++ 11.

Cuando se escribió ese libro, el consejo fue de poca utilidad, pero sirvió para evitar que el usuario escribiera, por ejemplo, foo() = 42;y esperara que cambiara algo persistente.

En el caso de operator[], esto puede ser un poco confuso si no proporciona también una no constsobrecarga que devuelva una no constreferencia, aunque quizás pueda evitar esa confusión devolviendo una constreferencia o un objeto proxy en lugar de un valor.

En estos días, es un mal consejo, ya que le impide vincular el resultado a una constreferencia (no ) de valor.

(Como se señaló en los comentarios, la pregunta es discutible cuando se devuelve un tipo primitivo como int, ya que el lenguaje le impide asignar a uno rvaluede ese tipo; estoy hablando del caso más general que incluye la devolución de tipos definidos por el usuario. )

Para tipos primitivos (como int), la consistencia del resultado no importa. Para las clases, podría cambiar el comportamiento. Por ejemplo, es posible que no pueda llamar a un método que no sea constante en el resultado de su función:

class Bigint {
    const C foo() const { ... }
     ...
}

Bigint b;
b.foo().bar();

Lo anterior está prohibido si bar()es una función de miembro constante de C. En general, elija lo que tenga sentido.

Mira eso:

const int operator[](const int index) const

el constfinal de la declaración. Describe que este método se puede llamar en constantes.

En la otra mano cuando escribes solo

int& operator[](const int index)

solo se puede llamar en instancias no constantes y también proporciona:

big_int[0] = 10;

sintaxis.

Una de sus sobrecargas es devolver una referencia a un elemento en la matriz, que luego puede cambiar.

int& operator[](const int index) { return _data[index]; }

La otra sobrecarga devuelve un valor para que lo use.

const int operator[](const int index) const { return _data[index]; }

Dado que llama a cada una de estas sobrecargas de la misma manera, una nunca cambiará el valor cuando se use.

int foo = myBigInt[1]; // Doesn't change values inside the object.
myBigInt[1] = 2; // Assigns a new value at index `

En el ejemplo del operador de indexación de matrices ( operator[]), hace una diferencia.

Con

int& operator[](const int index) { /* ... */ }

puede usar la indexación para cambiar directamente la entrada en la matriz, por ejemplo, usándola así:

mybigint[3] = 5;

El segundo, el const int operator[](const int)operador se utiliza para obtener el valor únicamente.

Sin embargo, como valor de retorno de funciones, para tipos simples como, por ejemplo int, no importa. Lo que importa es si está devolviendo tipos más complejos, digamos a std::vector, y no desea que la persona que llama a la función modifique el vector.

El consttipo de devolución no es tan importante aquí. Desde temporales int no son modificables, no hay ninguna diferencia observable en el uso intvs const int. Vería una diferencia si utilizara un objeto más complejo que pudiera modificarse.

Hay algunas buenas respuestas que giran en torno al tecnicismo de las dos versiones. Para un valor primitivo, no hace ninguna diferencia.

Sin embargo , siempre he considerado constestar ahí para el programador más que para el compilador. Cuando escribe const, está diciendo explícitamente "esto no debería cambiar". Seamos sinceros,const generalmente se puede eludir de todos modos, ¿verdad?

Cuando devuelve un const, le está diciendo al programador que usa esa función que el valor no debería cambiar. Y si lo está cambiando, probablemente esté haciendo algo mal, porque no debería tener que hacerlo.

EDITAR: También creo que "usar constsiempre que sea posible" es un mal consejo. Debería usarlo donde tenga sentido.