Proposition : héritage constant

Version imprimable

Bonjour,

Que pensez-vous de l'idée d'un héritage constant en C++ ?

Code:

class Cercle : public const EllipseAbstraite { /*...*/ };

Caractéristiques :
Cercle& est convertible en const EllipseAbstraite&, mais pas en EllipseAbstraite&.
Si EllipseAbstraite a des fonctions virtuelles pures alors, pour que Cercle soit instanciable, il doit implémenter les fonctions virtuelles pures constantes de EllipseAbstraite.
Si on appelle une fonction non constante de EllipseAbstraite via une instance de Cercle (à cause d'un const_cast), le comportement est indéterminé.
Code:

1 2 3 4 5 Cercle cercle; const EllipseAbstraite& ellipse = cercle;; EllipseAbstraite& danger = const_cast<EllipseAbstraite&>(ellipse); danger.fonctionNonConstante(); // aïe danger.fonctionVirtuellePureNonConstante(); // crash
Le code suivant est autorisé :
Code:

1 2 class Deriv : virtual public const Base { /*...*/ }; class Deriv2 : public Deriv, virtual public Base { /*...*/ }; // pas de const
Pour la cohérence, on aurait aussi l'héritage volatile et l'héritage constant volatile, qui ne serviraient à rien. 8-)
Le principal intérêt serait de réduire la quantité de classes en évitant les doublons Base/ConstBase :
Code:

1 2 class EllipseAbstraite : public ConstEllipseAbstraite { /*...*/ }; class Cercle : public ConstEllipseAbstraite { /*...*/ };

18/12/2016, 23h52
JolyLoic

Avant de détailler le mécanisme plus en détails, tu pourrais détailler la motivation ? Parce que pour l'instant, je ne vois pas trop ce qu'on y gagne...

Par exemple, à la place de ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
class Product { /*...*/ };
class Fruit : public Product { /*...*/ };
class Orange : public Fruit { /*...*/ };
 
class ConstProductTable {
public:
    virtual const Product& getProduct(size_t index) const = 0;
    // ...
};
 
class ProductTable : public ConstProductTable {
public:
    virtual void addProduct(const Product&) = 0;
    // ...
};
 
class ConstFruitTable : public ConstProductTable {
public:
    const Fruit& getProduct(size_t index) const override = 0;
    // ...
};
 
class FruitTable : public ConstFruitTable {
public:
    virtual void addFruit(const Fruit&) = 0;
    // ...
};
 
class ConstOrangeTable : public ConstFruitTable {
public:
    const Orange& getProduct(size_t index) const override = 0;
    // ...
};
 
class OrangeTable : public ConstOrangeTable {
public:
    virtual void addOrange(const Orange&) = 0;
    // ...
};

On aurait cela :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class Product { /*...*/ };
class Fruit : public Product { /*...*/ };
class Orange : public Fruit { /*...*/ };
 
class ProductTable {
public:
    virtual const Product& getProduct(size_t index) const = 0;
    virtual void addProduct(const Product&) = 0;
    // ...
};
 
class FruitTable : public const ProductTable {
public:
    const Fruit& getProduct(size_t index) const override = 0;
    virtual void addFruit(const Fruit&) = 0;
    // ...
};
 
class OrangeTable : public const FruitTable {
public:
    const Orange& getProduct(size_t index) const override = 0;
    virtual void addOrange(const Orange&) = 0;
    // ...
};

Edit 2016-12-19-19h52 (après la réponse de JolyLoic) : J'avais oublié de rendre pures mes fonctions virtuelles.

19/12/2016, 10h01
JolyLoic

Et comment implémentes-tu FruitTable::addFruit ?

Oups. J'ai oublié de rendre pures les fonctions virtuelles de mon précédent message.
Code modifié et factorisé :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class Product {
	// ...
};
 
class Fruit : public Product {
public:
	using base = Product;
	// ...
};
 
class Orange : public Fruit {
public:
	using base = Fruit;
	// ...
};
 
template<class T>
class ProductTable;
 
template<>
class ProductTable<Product> {
public:
    virtual const Product& getProduct(size_t index) const = 0;
    virtual void append(const Product&) = 0;
    // ...
};
 
template<class T>
class ProductTable : public const ProductTable<typename T::base> {
public:
    const T& getProduct(size_t index) const override = 0;
    virtual void append(const T&) = 0;
    // ...
};
 
class ConcreteOrangeTable : public ProductTable<Orange> {
public:
    const Orange& getProduct(size_t index) const override;
    void append(const Orange&) override;
    // ...
};

Dans mon exemple, ConcreteOrangeTable& serait convertible en ProductTable<Orange>, en const ProductTable<Fruit>& et en const ProductTable<Product>&.

21/12/2016, 21h14
Pyramidev

Aucun avis ?

Personnellement, je suis partagé.
D'un côté, cela permettrait de réduire le nombre de classes dans des cas assez rares.
De l'autre, cela complexifierait un peu plus le langage C++ qui est déjà compliqué.
25/12/2016, 20h52
koala01

Salut,

A mon avis, cela ne servirait à rien : Si les classes qui interviennent dans la hiérarchie n'exposent que des fonctions membres déclarées comme étant constantes (n'oublie pas que le principe de conception d'une classe est de s'intéresser aux services qu'elle peut rendre avant de s'intéresser aux données qu'elle contient ;) ), même si l'objet ("final" ou "intermédiaire") est considéré comme non constant, les services exposés ne permettront de toutes manières pas de modifier le dit objet, et le problème sera résolu d'office ;)

Le seul truc, c'est qu'il faut bel et bien penser aux services que doi(ven)t rendre ta (tes) classe(s) avant de réfléchir aux données qui lui (leur) permettront de rendre ces services, au lieu de penser aux données que l'on estime nécessaires au niveau de la classe avant de penser à la manière dont ces données seront manipulées ;)
19/02/2017, 18h58
Pyramidev
Petit up, pas pour relancer le débat, mais juste pour partager une anecdote.

Sur le site open-std.org, je viens de découvrir que, en février 2016, il y a déjà un certain David Wilson qui a proposé un héritage constant : P0277R0 (4 pages) ; P0277R1 (4 pages).

Par contre, au lieu de proposer que la classe de base constante ne soit pas modifiable dans la classe dérivée, il propose qu'elle soit modifiable, mais uniquement dans les constructeurs de la classe dérivée.
Ce n'est pas cohérent avec les variables membres constantes :
Code:

1 2 3 4 5 struct Foo { const int i; Foo() {i=0;} // ne compile pas };
19/02/2017, 21h20
JolyLoic

Ce papier a été discuté à Oulu, en l'absence de l'auteur (ce qui n'est jamais bon pour un papier), et a été rejeté à une très large majorité.
Si j'essaye de résumer les discussions :
- On ne comprend pas trop à quoi ça servirait
- Ça pose des conflits avec le reste du langage (par exemple, actuellement, on peut dériver d'un typedef défini comme constant... J'avoue que je ne le savais pas, et je ne sais pas comment ça se comporte, j'imagine que le const est ignoré)
- L'exemple choisi était particulièrement non motivant
- Il aurait aussi pu y avoir http://www.open-std.org/jtc1/sc22/wg...014/n4225.html dans la même direction, mais qui avait été rejeté

Citation:

Envoyé par JolyLoic

Ce papier a été discuté à Oulu, en l'absence de l'auteur (ce qui n'est jamais bon pour un papier), et a été rejeté à une très large majorité.
Si j'essaye de résumer les discussions :

Merci pour ces infos. Comment les as-tu eues ?

Citation:

Envoyé par JolyLoic

actuellement, on peut dériver d'un typedef défini comme constant... J'avoue que je ne le savais pas, et je ne sais pas comment ça se comporte, j'imagine que le const est ignoré

Test avec GCC 6.3.0, avec -O2 -Wall -Wextra -pedantic :
Le const est ignoré :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 struct Base { int i; int j; void foo() { j=0; } }; typedef const Base ConstBase; struct Deriv : ConstBase { void bar() { i=0; } // pas d'erreur de compilation }; int main() { Deriv obj; Base& ref = obj; // pas d'erreur de compilation ref.foo(); return 0; }
D'ailleurs, dans N4296 (draft de C++14), je n'ai pas réussi à trouver un passage qui évoque les qualificatifs const et volatile pour les classes de base par l'intermédiaire de typedef.

20/02/2017, 01h55
JolyLoic

Citation:

Envoyé par Pyramidev

Merci pour ces infos. Comment les as-tu eues ?

J'étais dans la salle au moment de la discussion :)

Et il y a des prises de notes de ces réunions, mais comme elles sont brut de fonderie, elles sont réservées aux membres du comité. Mais j'ai pu m'en servir pour me rafraichir la mémoire.

Sinon, j'ai retrouvé dans la norme les aspects liés au const venant d'un typedef :

Citation:

Envoyé par Le standard 9.1/5

A typedef-name (7.1.3) that names a class type, or a cv-qualified version thereof, is also a class-name. If a
typedef-name that names a cv-qualified class type is used where a class-name is required, the cv-qualifiers
are ignored. A typedef-name shall not be used as the identifier in a class-head.

Et au début du chapitre 10, on voit que les classes de base doivent être des class-name.