Membre externe

[Teaniel]

Bonjour,

Trois soucis :
1) Dans une classe paramétrée je déclare un membre externe.
Dans le volet c++ du membre, je veille à ce que 'inline' soit décoché.
Je vide le champs 'Déclaration' (en effet il n'y en a pas).
Dans le champs 'Définition' je place la définition de ce que je veux mettre (en l'occurrence une instanciation explicite de la classe).
A la génération tout apparaît dans l'entête, comme si 'inline' avait été cochée.
Notez que j'ai refait le test sur une classe non paramétrée, le phénomène ne s'est pas reproduit.

2) Pour une classe 'tester' instanciant la classe TPileSymboles<class T>, Le stereotype 'template_typedef' se traduit en 'using tester = TPileSymboles<maClasse>' dans le volet C++, ce qui ne veut rien dire pour ce langage (sauf erreur de ma part). En plus (là ce n'est plus un bug, si vous voulez je mettrai un sujet dans le bon forum), il serait souhaitable de pouvoir le générer dans le source. Comme plus haut, mon objectif était de générer une instanciation explicite dans le source pour une classe paramétrée.

3) Rien a voir avec les précédents :
Lorsqu'on établit une dépendance entre deux classes, et qu'on choisit de mettre le #include dans le source, le générateur le met effectivement dans le source, et ajoute un forward avant la déclaration de la classe dépendante. Jusque là tout va bien.
Le problème vient quand la classe dont on dépend est une classe incluse. On se retrouve avec 'class maClasse::Incluse;' dans l'entête, ce qui est une erreur au niveau C++ (au mieux un warning (g++), sinon une erreur pour le compilateur).

Voila, si vous pouviez prendre ces deux questions en compte
Amicalement,
Marc

[Bruno Pagès]

Bonjour,

1) c'est le pendant de ce qui était fait pour les opérations dans le cas des classes paramétrées, je ne me souvenais pas de cela et avait oublié de ne plus forcer la génération dans le fichier d'en-tête. Par contre cela va modifier le comportement de la génération pour les projets déjà existants, mais ce genre de cas étant à priori rare tant pis.

2) Le stereotype 'template_typedef' est dédié aux "template typedef" de C++11, c.f. historique de la version 5.1 et http://www.bouml.fr/doc/index_class.html

[Teaniel]

Bonjour,

Veuillez m'excuser, pendant que vous me répondiez j'ai édité mon sujet pour ajouter une troisième question... En effet, je ne la trouvais pas suffisamment importante pour justifier un nouveau sujet.

Cordialement,
Marc

[Bruno Pagès]

3) mais comment diantre déclare-t-on une sous classe ?

[Teaniel]

Bonjour,

Pardonnez-moi, je me suis fait mal comprendre : Voici le code généré dans une déclaration de classe qui dépend d'une classe incluse :
entête :

Code: Select all

 /* includes */
// ...
// Générés à partir de bouml
// Lien de dépendance vers une classe normale
class uneClasse; // forward habituel. no comment.
// lien de dépendance vers une classe incluse (attention maClasse != uneClasse)
class maClasse::Incluse; // Ceci constitue une erreur, mais passe chez moi (g++) au prix d'un warning "Ne déclare rien". Ailleurs peut donner une erreur car maClasse est un nom non défini (ça le faisait en tous cas avec BC++).

// Ajouté manuellement pour l'exemple.
class monAutreClasse;
class monAutreClasse::Incluse; // Erreur de compile car monAutreClasse n'est pas définie. Si on en a besoin, il faut inclure l'entête de monAutreClasse.

class maClasseQuiDepend {
    // Ajouté manuellement pour l'illustration
    maClasse *x; // produit une erreur (maClasse est un nom inconnu)
    maClasse::Incluse *y; // Aussi pour la même raison.
...
};

Pour moi, lorsqu'on place une dépendance vers une classe incluse avec #include dans le source, le forward ne doit pas être mis dans l'entête.

En fait, j'ai ajouté cette question parce que dans mon projet j'ai une soixantaine de classes qui dépendent d'une classe incluse.
Cela génère autant de warnings qui en masquent d'autres plus importants (que je n'ai pas vus dans l'empressement de tester mon code ).

Voila, j'espère avoir été plus clair

Cordialement,
Marc

[Bruno Pagès]

lorsqu'on place une dépendance vers une classe incluse avec #include dans le source, le forward ne doit pas être mis dans l'entête.

ce qui est bien dommage

plutôt que d'utiliser des dépendances #include qui ne résistent pas au roundtrip, pourquoi ne placez-vous pas les forward déclarations de classes et #include dans la définition de l'artifact ?

[Teaniel]

Euh...

Excusez moi, mais...
Les liens ne sont-ils pas fait précisément pour cela?

Pour répondre exactement à votre question, si je place ma dépendance (ou que je l'écris) au niveau de l'artifact, une modification du modèle qui me ferait déplacer la classe m'obligerait à penser à déplacer ce lien de dépendance en accord, ce qui pour mon cas personnel a fort peu de chance de se produire (je veux dire qu'à tous les coups j'oublierais).
Pour ma part je pense qu'un lien de dépendance fait partie de l'objet dépendant; le garder dans cet objet permet de créer un modèle plus solide.
Pour précision, je considère personnellement le #include comme l'expression c++ de la dépendance d'un fichier à un autre, ce qui induit son utilisation dans la traduction depuis uml.
Par ailleurs, si je reconnais que les interventions dans les volets de code sont super pratiques, parce qu'elles permettent d'ajouter des tournures syntaxiques impossibles à représenter en uml, je dis tout de même qu'il faut s'en méfier, car cela peut fragiliser le modèle, ou rendre hasardeux les cycles génération/roundtrip.
Pour terminer, je me permets une question : Pour quelle raison, les #include ne sont-ils pas reconnus comme supports de dépendance, au moins entre artifacts, sinon entre classes par le reverse/roundtrip?

Tout a fait cordialement,
Marc

[Bruno Pagès]

La version 6.4.3 est disponible

l'indication 'inline' est désormais suivi sans limitation (1)

le roundtrip ne marque plus les dépendances non stéréotypées <<friend>> comme étant à détruire