¿Qué pasa con const?

Question

¿Cuáles son las deficiencias conocidas de const en C++ y C++ 0x?

Answer 1

Las dos cuestiones principales que he visto quejas frecuentes acerca de los grupos de noticias, son

• La necesidad de perder mucho tiempo de compatibilidad con las API no compatibles con const (especialmente las de Microsoft).

• El need to define both const and non-const version of a method.

Creo que este último podría/debería ser compatible con el idioma.

Posiblemente junto con la compatibilidad con las implementaciones de funciones de miembros covariantes, ya que ambas necesitan algún modo de detectar el tipo del puntero this.

Un tercer problema es que

• const does not propagate to owned objects.

Saludos & HTH.,

Answer 2

El único malo de const es que es seriamente subestimado por muchos desarrolladores. Es una de las mejores herramientas en la caja de herramientas de C++, muy nítida y, sin embargo, no es peligroso cortarse con ella.

Answer 3

"issues"?

Si no va a modificar el valor de un puntero pasado (se usa simplemente para la entrada de referencia de una función), marque que es const. Lo mismo si el valor de una variable en particular no cambiará después de su inicialización. Si una función es segura para invocar una instancia de clase const, márquela también en const. Cuantos más elementos estén correctamente anotados const, es menos probable que cometas un error inadvertidamente y cuantas más optimizaciones el compilador teóricamente pueda realizar en ausencia de conocimiento completo (como cuando compilas con solo prototipos de funciones disponibles).

Las versiones modernas de gcc tienen soporte para advertencias cuando intentas convertir una variable const en una no const. Sugiero que dejes esas advertencias habilitadas.

Lo único a lo que hay que tener cuidado es exactamente qué está marcando const; const char * foo() no es lo mismo que char * foo() const.

Answer 4

El problema con const es que los programadores que utilizan de forma incorrecta nuestra manera inconsistente

Answer 5

Un problema es que el idioma también le permite const_cast a la basura, lo que contradice el propósito de usar const en el primer lugar.

Answer 6

Lo que falla con const es que muchos programadores no parecen ser capaces de entenderlo completamente, y un proyecto de "media const-correct" simplemente no funciona.Esto es lo que necesita saber:

1. Foo vs const Foo (o Foo const)
2. Foo& vs const Foo& (o Foo const&)
   • referencias-a-const se unen a todo tipo de cosas, mientras referencias a la no-const no lo hacen
3. Foo* vs const Foo* (o Foo const*)
   • variables de puntero también pueden ser Foo* const y const Foo* const (o Foo const* const)
4. void Foo::mutator() vs int Foo::accessor() const
   • pero los miembros del puntero dentro métodos constantes siguen apuntando a objetos no constante
   • para que podamos accidentalmente devuelve datos no const desde una función const
5. iterator vs const_iterator
   • variables de iterador también pueden ser const iterator y const const_iterator

Migración a C++ de un lenguaje que no tiene un concepto const es bastante difícil, cualquier muchos no ven el punto.

Answer 7

El problema principal es que tiene que escribirlo. Debe ser el valor predeterminado, y todas las variables o parámetros variables deben especificarse explícitamente.

Answer 8

Una cosa que está "mal" es que no se puede convertir T ** a T const * const * que debe permitirse porque no es peligroso. No permitir que T ** se convierta a T const ** es correcto, esa conversión no es válida.

A veces he mencionado que const es en realidad una forma económica de "dividir" su interfaz en métodos de solo lectura y métodos de escritura. Probablemente sería poco práctico en C++. Sin embargo, sería más práctico en Java tener versiones de ReadOnly de colecciones, donde no tienen const y donde sus tipos de colección están más orientados a objetos.

const-ness no se propaga: El problema aquí es que si llevo mi clase, la constness no es "comprobada" por el compilador, es decir, mi clase de interfaz puede tener un método "const" llamar a un método non-const en el pImpl y el compilador no se quejará. Esto se debe a que lo único que mi método const está garantizado de no hacer es cambiar el puntero para apuntar a un objeto diferente, y mi pImpl nunca va a cambiar. Incluso podría ser un puntero const (no puntero a const).

La falta de adecuada covarianza entre shared_ptr<T> y shared_ptr<const T> podría ser un problema también, aunque en general he visto que no sea el problema, sino que los desarrolladores lo general typedef sus shared_ptrs y rara vez typedef la shared_ptr a const. Y a veces pasan const shared_ptr<T> & y piensan que están pasando un puntero compartido a una const T (como con const T *) que no lo son.

Answer 9

Una cosa es que todavía es posible subvertirlo. es decirtodavía es legal para hacer algo como esto:

void foo(const inst& x) 
{ 
    const_cast<int&> x = 3; 
} 

Incluso puede usar cosas como memset subvertir sin una explícita const_cast.

Esto es una desventaja entre hacer que el compilador haga cumplir const y permitir cierta flexibilidad para las interfaces no conscientes de const.

Lo que conduce a otra limitación, ya que no se ha adoptado universalmente, lo cual se debe en parte a otro problema, que es que usar const es una proposición de todo o nada. Si comienza a usarlo, deberá propagarlo a través de su base de códigos.

Answer 10

Otro problema que no se ha mencionado aún es la posibilidad de una interfaz mal diseñada para subvertir const (incluso en ausencia de moldes).

Ejemplo:

class TreeNode { 
public: 
    TreeNode& getParent() const { return *parent_; } 
    TreeNode& getLeft() const { return *left_; } 
    TreeNode& getRight() const { return *right_; } 
private: 
    //TreeNode has a pointer to the Tree to enable navigation of the tree. 
    //Assume that other design constraints mean that this must be a pointer 
    //rather than a reference. 
    TreeNode* parent_; 
    TreeNode* left_; 
    TreeNode* right_; 
}; 
//This function demonstrates the ability for const to be subverted. 
TreeNode& remove_const(TreeNode const& toRemoveConstFrom) { 
    TreeNode& parent(toRemoveConstFrom.getParent()); 
    TreeNode& leftChild(parent.getLeft()); 
    TreeNode& rightChild(parent.getRight()); 
    return &toRemoveConstFrom == &leftChild ? leftChild : rightChild; 
} 

La naturaleza intransitivo de const significa que es posible tener una interfaz donde una referencia no const a un objeto puede obtenerse a partir de una referencia const a un objeto. Esto es algo de lo que hay que tener cuidado al diseñar interfaces.

Answer 11

La mayoría de las respuestas a continuación indican cosas como "lo que está mal con const es que X personas lo hacen Y". Esas no son respuestas sino síntomas. Esas no son cosas malas con const. Hay apenas cualquier cosa incorrecta con const ... Esas cosas están mal con las personas que no pueden RTFM.

Answer 12

const es genial. const es importante. const -corregir es condición necesaria para que una API sea buena.

Sin embargo, hay dos problemas que he tenido con const, repetidamente.

• No hay manera de marcar una variable como const retroactivamente. Debe declarar un código variable, en cuyo caso tiene para inicializarlo inmediatamente. ¿Qué sucede si el código de inicialización contiene un if? Usted tiene la opción de omitir el const (indeseablemente), utilizando el operador ? en lugar de if (daños a la legibilidad). Java es así, las variables BTW - const no tienen que inicializarse de inmediato, solo tienen que inicializarse antes de se leen por primera vez, y deben inicializarse en todas las ramas de un if.

• No hay forma de especificar que un objeto pasado por referencia a una función no cambiará mientras dure la llamada a la función. const T& t hace no significa que el objeto apuntado por t no cambiará, pero solo que la referencia t no se puede usar para cambiarlo. El compilador aún tiene que suponer que cualquier llamada de función que no vea en podría cambiar el objeto. En algunos casos, eso evita bastantes optimizaciones.