Vender-me na const correção

Então, por que exatamente é sempre recomendável usar const o mais rápido possível? Parece-me que usar const pode ser mais uma dor do que uma ajuda em C ++. Mas, novamente, estou abordando isso da perspectiva do python: se você não quiser que algo seja alterado, não mude. Então, com isso dito, aqui estão algumas perguntas:

1. Parece que toda vez que eu marcar algo como const, recebo um erro e tenho que alterar alguma outra função em algum lugar para ser const também. Então isso me faz ter que mudar outra função em outro lugar. Isso é algo que fica mais fácil com a experiência?

2. Os benefícios do uso de const realmente suficientes para compensar o problema? Se você não pretende alterar um objeto, por que não simplesmente não escrever um código que não o mude?

Devo observar que, neste momento, estou mais focado nos benefícios do uso de const para fins de correção e manutenção, embora também seja bom ter uma idéia das implicações de desempenho.

Este é o artigo definitivo sobre "const correctness": https://isocpp.org/wiki/faq/const-correctness .

Em poucas palavras, usar const é uma boa prática porque ...

1. Ele protege você de alterar acidentalmente variáveis ​​que não se destinam a serem alteradas,
2. Ele protege você de fazer atribuições acidentais de variáveis ​​e

3. O compilador pode otimizá-lo. Por exemplo, você está protegido contra

   if( x = y ) // whoops, meant if( x == y )

Ao mesmo tempo, o compilador pode gerar código mais eficiente porque sabe exatamente qual será o estado da variável / função em todos os momentos. Se você estiver escrevendo um código C ++ rígido, isso é bom.

Você está certo, pois pode ser difícil usar a correção constante de forma consistente, mas o código final é mais conciso e seguro para programar. Quando você faz muito desenvolvimento em C ++, os benefícios disso se manifestam rapidamente.

Aqui está um pedaço de código com um erro comum contra o qual a correção constante pode protegê-lo:

void foo(const int DEFCON)
{
   if (DEFCON = 1)     //< FLAGGED AS COMPILER ERROR! WORLD SAVED!
   {
       fire_missiles();
   }
}

Parece que toda vez que eu marcar algo como const, recebo um erro e tenho que alterar alguma outra função em algum lugar para ser const também. Então isso me leva a ter que mudar outra função em outro lugar. Isso é algo que fica mais fácil com a experiência?

Por experiência, este é um mito total. Isso acontece quando non-const-correct se assenta com o código const-correct, com certeza. Se você projeta a correção constante desde o início, isso NUNCA deve ser um problema. Se você criar algo const e depois algo não se compilar, o compilador está dizendo algo extremamente importante e você deve reservar um tempo para corrigi-lo corretamente .

Não é para você quando você está escrevendo o código inicialmente. É para alguém (ou você, alguns meses depois) que está olhando a declaração do método dentro da classe ou interface para ver o que ela faz. Não modificar um objeto é uma informação significativa a ser obtida.

Se você usa const rigorosamente, ficaria surpreso com a quantidade de variáveis ​​reais na maioria das funções. Muitas vezes, não mais do que um contador de loop. Se o seu código está chegando a esse ponto, você tem uma sensação calorosa por dentro ... validação por compilação ... o domínio da programação funcional está próximo ... você quase pode tocá-lo agora ...

const é uma promessa que você está fazendo como desenvolvedor e solicita a ajuda do compilador para fazer cumprir.

Minhas razões para estar constantemente correto:

• Ele comunica aos clientes de sua função que você não alterará a variável ou o objeto
• Aceitar argumentos por referência const fornece a eficiência de passar por referência com a segurança de passar por valor.
• Escrever suas interfaces como const correct permitirá que os clientes as usem. Se você escrever sua interface para receber referências que não sejam const, os clientes que estiverem usando const precisarão expulsar constness para trabalhar com você. Isso é especialmente irritante se sua interface aceita caracteres não-const * e seus clientes estão usando std :: strings, pois você só pode obter um const * deles.
• O uso de const recrutará o compilador para mantê-lo honesto, para que você não altere por engano algo que não deve mudar.

Minha filosofia é que, se você usar uma linguagem exigente com verificações de tempo de compilação, faça o melhor uso possível. consté uma maneira imposta pelo compilador de comunicar o que você quer dizer ... é melhor do que comentários ou doxygen jamais serão. Você está pagando o preço, por que não deduzir o valor?

Programar C ++ sem const é como dirigir sem o cinto de segurança.

É doloroso colocar o cinto de segurança cada vez que você entra no carro e 364 de 365 dias você chega em segurança.

A única diferença é que, quando você tiver problemas com seu carro, sentirá isso imediatamente, enquanto que com a programação sem const, talvez seja necessário procurar por duas semanas o que causou esse acidente, apenas para descobrir que você inadvertidamente confundiu um argumento de função que você passou por referência não const para obter eficiência.

Para programação incorporada, usando const criterioso ao declarar estruturas de dados globais pode economizar muita memória RAM, fazendo com que os dados constantes sejam localizados na ROM ou no flash sem copiar para a RAM no momento da inicialização.

Na programação diária, usar const cuidadoso ajuda a evitar a gravação de programas que travam ou se comportam de maneira imprevisível, porque eles tentam modificar literais de seqüência de caracteres e outros dados globais constantes.

Ao trabalhar com outros programadores em projetos grandes, o uso constadequado ajuda a impedir que outros programadores o estrangulem.

constajuda a isolar o código que "muda as coisas" pelas suas costas. Portanto, em uma classe, você marcaria todos os métodos que não alteram o estado do objeto como const. Isso significa que constinstâncias dessa classe não poderão mais chamar nenhum não constmétodo. Dessa forma, você é impedido de chamar acidentalmente funcionalidades que podem alterar seu objeto.

Além disso, constfaz parte do mecanismo de sobrecarga, portanto, você pode ter dois métodos com assinaturas idênticas, mas um com conste um sem. Aquele com consté chamado para constreferências e o outro é chamado para não- constreferências.

Exemplo:

#include <iostream>

class HelloWorld {
    bool hw_called;

public:
    HelloWorld() : hw_called(false) {}

    void hw() const {
        std::cout << "Hello, world! (const)\n";
        // hw_called = true;  <-- not allowed
    }

    void hw() {
        std::cout << "Hello, world! (non-const)\n";
        hw_called = true;
    }
};

int
main()
{
    HelloWorld hw;
    HelloWorld* phw1(&hw);
    HelloWorld const* phw2(&hw);

    hw.hw();    // calls non-const version
    phw1->hw(); // calls non-const version
    phw2->hw(); // calls const version
    return 0;
}

A correção constante é uma daquelas coisas que realmente precisam estar em vigor desde o início. Como você descobriu, é muito difícil incluí-lo mais tarde, especialmente quando há muita dependência entre as novas funções que você está adicionando e as funções antigas que não estão corretas, que já existem.

Em grande parte do código que escrevo, realmente valeu a pena o esforço, porque costumamos usar muito a composição:

class A { ... }
class B { A m_a; const A& getA() const { return m_a; } };

Se não tivéssemos correção constante, você teria que recorrer a objetos complexos por valor para garantir a si mesmo que ninguém estava manipulando o estado interno da classe B pelas suas costas.

Em resumo, a correção constante é um mecanismo de programação defensivo para se livrar da dor no caminho.

Digamos que você tenha uma variável em Python. Você sabe que não deveria modificá-lo. E se você acidentalmente fizer?

O C ++ oferece uma maneira de se proteger acidentalmente de fazer algo que você não deveria poder fazer em primeiro lugar. Tecnicamente, você pode contorná-lo de qualquer maneira, mas precisa fazer um trabalho extra para se matar.

Há um bom artigo aqui sobre const em c ++. É uma opinião bastante direta, mas espero que ajude alguns.

Quando você usa a palavra-chave "const", está especificando outra interface para suas classes. Existe uma interface que inclui todos os métodos e uma interface que inclui apenas os métodos const. Obviamente, isso permite restringir o acesso a algumas coisas que você não deseja que sejam alteradas.

Sim, fica mais fácil com o tempo.

Eu gosto de const constance ... em teoria. Sempre que tentei aplicá-lo rigorosamente na prática, ele acabou se deteriorando e o const_cast começa a se tornar cada vez mais feio.

Talvez sejam apenas os padrões de design que eu uso, mas o const sempre acaba sendo um pincel muito amplo.

Por exemplo, imagine um mecanismo de banco de dados simples ... ele possui objetos de esquema, tabelas, campos etc. os dados associados à tabela? Se o método Insert () estiver marcado como const, internamente, ele deverá eliminar a constância para realmente manipular o banco de dados. Se não estiver marcado const, não será protegido contra a chamada do método AddField.

Talvez a resposta seja dividir a classe com base nos requisitos de constância, mas isso tende a complicar o design mais do que eu gostaria pelo benefício que ele traz.

Você pode dar dicas ao compilador com const também .... conforme o código a seguir

#include <string>

void f(const std::string& s)
{

}
void x( std::string& x)
{
}
void main()
{
    f("blah");
    x("blah");   // won't compile...
}