C++ const-correct et les membres const

Question

Possible en double:
Does const-correctness give the compiler more room for optimization?

Au cours des dernières semaines, je me suis mis au point une chose pour faire tous mes membres non statiques const si possible afin d'éviter les erreurs de programmation involontaires. Cependant, cette pratique présente d'énormes inconvénients, en particulier pour les objets d'entité, par exemple. personne ne pourra plus jamais appeler un opérateur d'assignation, s'il choisit d'agréger un tel objet entité directement plutôt que d'utiliser un pointeur.

Ma question est de savoir si cette philosophie de membre const fournit même des bonus d'optimisation du compilateur.

class User { 
public: 
    User(const std::string &, const std::vector<unsigned char> &); 
    ~User(); 
    const std::string &getName() const; 
    const std::vector<unsigned char> &getPasswordHash() const; 
private: 
    std::string name; 
    std::vector<unsigned char> passwordHash; 
}; 

Ne serait-il fournir mon compilateur avec toutes les possibilités d'optimisation importantes si ce class 'membres étaient const? Étant donné que les autres classes regroupent généralement les objets non-const User, mais presque tous mes algorithmes acceptent un const User &?

faire, les const membres offrent des possibilités d'optimisation importantes sur la mentalité déjà const User &? Et justifierait-il d'utiliser des agrégations const User * et de reconstruire les objets en cas de changement plutôt que d'utiliser l'opérateur d'affectation?

Merci pour quelques remarques rapides!

Answer 1

départ à ce sujet à SO et aussi HERE

Answer 2

D'abord, une note sur le vocabulaire: objets d'entité, par définition, ont l'identité , et ainsi ne prennent pas en charge l'affectation. Je pense que vous voulez dire objets de valeur. Sinon, j'ai généralement trouvé très peu d'avantages à faire des données membres const Comme vous l'avez remarqué, cela rend l'affectation impossible, , ce qui signifie qu'ils ne peuvent pas être const pour les types de valeur. Pour l'entité objets, qui ne peut pas être affecté, il est utile de faire membres immuables (par exemple un identifiant) const, mais comme tous les accès sont en un petit bloc de code que vous contrôlez, la valeur est considérable moins que pour const dans l'interface publique.

Une autre possibilité consiste à définir des types immuables pour de tels membres. Il est beaucoup plus expressif pour définir name comme Identifier que de définir comme un std::string et Identifier, même si elle contenait un seul membre de données de type std::string limiterait ce que vous pourriez faire. (Cela faciliterait également le changement ultérieur de la représentation de l'identificateur.)