Bpnjour,

Lors de mon dernier exercice, face aux complaintes du compilateur, j'ai du me résoudre à fournir une implémentation constante de l'une des fonction membre de ma classe, et je ne suis pas sûre d'en comprendre tous les tenants et aboutissants.

Dans quel(s) cas faut-il fournir une implémentation constante d'une fonction membre, et pourquoi ?

Une implémentation constante ?

C'est-à-dire (pas de spécialisation si c'est une fonction générique) ?

Je n'ai jamais entendu parler ni vu sur les forums ce terme d'implémentation constante, ça m'intéresse.

Exemple:

class table
{
public:
    cell& operator()(unsigned, unsigned);
    cell const& operator()(unsigned, unsigned) const;
};

D'accord, c'est juste une histoire de const/pas const.

 Je vois, ça me rappelle déjà l'opérateur[] :

std::array<unsigned short, 4> array {0, 1, 2, 3};
array[0] = 7; // type& operator[](std::size_t index)
const unsigned short { array[2] }; // type operator[](std::size_t index) const

Cppreference confirme pour std::string.

Après je pense que le seul contexte où c'est justifiable, c'est une fonction d'accès à un élément de conteneur (disponible tout le temps, const ou pas), et de modification (non const), enfin la seule situation qui me vienne à l'esprit pour le moment.

-
Edité par Chi_Iroh 9 avril 2021 à 15:23:04

On va faire ça pour les accesseurs. Le C++ ne distingue pas lecture d'écriture, mais appliqué sur un objet modifiable ou non.

Du coup il faut la surcharge pour les objets modifiables (qui gère lecture et écriture), et celle sur les non modifiables qui ne gèrent qu'écriture.

Ceci dit depuis peu, je vois une nouvelle tendance: https://en.cppreference.com/w/cpp/container/span/operator_at Je n'adhère pas encore à cette approche car elle permet de modifier les éléments malgré que l'objet frontal soit non modifiable. C'est juste si le paramètre est const que l'on va interdire l'écriture.

-
Edité par lmghs 9 avril 2021 à 15:31:08

Personnellement ça ne me choque pas plus que ça quand std::span retourne un élément non-const alors que son opérateur est const.

La raison derrière est assez bête, la vue indique elle-même si elle référence des valeurs const ou non. Cela se rapproche plus du comportement du langage vis-à-vis des indirections: pas de propagation du const pour le référé.

using T = int&;
using U = T const&;
ici U == T

Si on veut une vue sur des valeurs constantes, autant partir sur span<const T> qui apporte la même chose qu'un span sur un T non constant qui retourne une référence const avec [].