Discussion :

[Luc Hermitte]

Bonjour,

Juste pour signaler un problème que j'ai constaté sur plusieurs classes lors d'un import: Si la classe contient une déclaration anticipée de classe embarquée (nested)(typiquement une classe pimpl), BOUML signale des erreurs de syntaxe. On retrouve le même problème lors de la définition de la classe dans le .cpp.
ex.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
namespace N {
struct C {
    struct Pimpl;
    Pimpl * m_pimpl;
};
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
struct N::C::Pimpl : noncopyable {
   ...
};

[bruno_pages]

Bonsoir,

en fait le reverse râle dans le cas d'un struct / union / enum, mais pas d'une classe, il accepte

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
namespace N {
struct C {
    class Pimpl;
    Pimpl * m_pimpl;
};
}

la forme "class Pimpl;" produisant un extra member qui est la seule façon de mémoriser la chose dans le modèle

par contre cela se passe mal pour le reverse de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

class N::C::Pimpl {};

car cela produit la classe N::C:: Pimpl, et m_pimpl n'est pas une relation car la classe Pimpl est vue comme absente.

Il faut quand même dire que procéder ainsi est particulièrement tordu

tout va bien par contre si la définition de Pimpl est faite dans C:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
namespace N {
struct C {
    class Pimpl {};
        
    Pimpl * m_pimpl;
};
}

[Luc Hermitte]

Tordu ? Pas vraiment. C'est même une technique connue (sous trois noms différents -> pimpl idiom, compilation firewall, chesshire cat (celui-là, je ne sais jamais l'épeler)). Cf les GOTW 24 et 28: http://www.gotw.ca/gotw/024.htm et http://www.gotw.ca/gotw/028.htm

Cela permet de tirer moins de dépendances dans les fichiers d'en-tête, d'avoir une encapsulation encore plus forte, et d'améliorer accessoirement les temps de compilation, au détriment de ceux à l'exécution.

Bref, cette digression pour dire que cet idiome n'appartient pas à la catégorie des mauvaises pratiques, et qu'il n'est pas si rare qu'il soit employé: les écrits d'Herb Sutter dont GOTW et les bouquins qui en découlent, sont régulièrement évoqués sur la toile, et de fait cette technique "découverte".

Concernant, le coup du struct qui n'est pas reconnu comme une classe, c'est dommage, mais bon à savoir. Merci.


PS: je ne passe pas le sujet à résolu, je peux migrer le Bug en RfC ou RfE si tu préfères.

[bruno_pages]

ce qui est tordu c'est que Pimpl est à la fois imbriquée et non imbriquée, cela pose un gros problème au niveau modélisation, ce qui n'aurait pas été le cas avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
namespace N {
class Pimpl;
struct C {
    Pimpl * m_pimpl;
};
}

PS: je ne passe pas le sujet à résolu, je peux migrer le Bug en RfC ou RfE si tu préfères.

je ne sais pas ce que tu veux dire par RfC/RfE, mais puisqu'il n'y a toujours rien aujourd'hui sous forge à ce propos j'ai ouvert un ticket ...

[bruno_pages]

avec la version 4.8.4 il n'y a plus d'erreur de syntaxe lors de la lecture d'une déclaration en avance d'un struct, union et enum

[Luc Hermitte]

Merci.

PS: RfC/E==Request for Change/Enhancements