[Bug] Reverse C++ et déclarations anticipées de classes "nested"

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:

---

1 2 3 4 5 6

namespace N { struct C { struct Pimpl; Pimpl * m_pimpl; }; }

---

Code:

---

1 2 3

struct N::C::Pimpl : noncopyable { ... };

---

Bonsoir,

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

Code:

---

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:

---

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 :marteau:

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

Code:

---

1 2 3 4 5 6 7

namespace N { struct C { class Pimpl {}; Pimpl * m_pimpl; }; }

---

Tordu ? Pas vraiment. C'est même une technique connue :P (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.

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:

---

1 2 3 4 5 6

namespace N { class Pimpl; struct C { Pimpl * m_pimpl; }; }

---

Citation:

---

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 ...

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

Merci.

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