Discussion :

[oodini]

Hello,

J'aimerais faire un diagramme pour décortiquer une bibliothèque Boost.
Mais avec Boost, on se retrouve très vite limité par UML. Représenter des templates de templates, des traits, du CRTP, etc. relève de la gageure.

J'aurais quelques idées pour compléter l'UML histoire d'être à la hauteur de l'expressivité du langage C++.

Connaitriez-vous un framework permettant de créer des semblants de diagrammes UML, pour qu'éventuellement (je doute que j'en ai le temps) je rajoute ma patte, par l'ajout de type de boîte, flèche, etc. ?

[Klaim]

Personellement, des qu'on va dans la meta prog, je laisse tomber totallement UML et je passe direct a des bouts de code. C'est beaucoup plus explicite, surtout si t'es en train d'expliquer une idee a un collegue.

Par contre dans de la documentation, du coup je vais pas trop dans les details et je me contente d'un UML tres haut niveau, juste des types important pour le sujet du diagrame, quelques relations, quelques groupes, rien de plus.

[ternel]

Pour ce genre de diagramme "exploratoire", je recommande yEd, un petit éditeur de graphe for agréable à l'usage.

Son avantage majeur est le coté "un clic un nœud" et surtout, l'agencement automatique.

Il est gratuit, mais cependant conçu comme outil de démonstration de yFiles, la bibliothèque vendues par la société.

D'ailleurs, j'utilise ce graphe entre autre à des fins de documentations de code.

Une grosse astuce, utiliser des flèches "inversées" (pointe coté source) et une présentation hierarchique (left to right, topmost) donne des graphes de classes assez sympa.

[oodini]

Saperlipopette. Dommage que tu fus assez sain d'esprit pour être dans ton lit cette nuit.

J'ai galéré avec UMLet jusqu'à 2h du mat.

Je vous soumettrai d'ici peu un diagramme à ma sauce pour que vous me donniez votre avis.

[oodini]

Très sympa, ce yEd, mais pour faire ce que je veux, il faudrait que je crée mes propres composants, et donc avoir la version payante.

[oodini]

Bon, je vous fais une proposition de diagramme.

J'étais limité par l'outil de dessin, donc je vous demande d'être indulgent.

J'aurais notamment voulu :

- personnaliser le style de certaines flèches
- placer correctement sur les connexions leur nom et stéréotype
- rendre graphiquement plus "solidaire" les classes et la liste de leurs templates

Je vous propose d'essayer de deviner ce que j'ai voulu représenter, et de vérifier par la suite dans Boost::Interprocess (1.52.0).

Et de me faire un retour, pour ceux qui en auront le courage.

[ternel]

Des composants uml existent, qui permettent de lister méthodes et attributs.

J'aime bien ton graphe, mais comme je ne connais pas du tout boost::interprocess, je n'y comprends pas grand chose

[oodini]

J'aime bien ton graphe, mais comme je ne connais pas du tout boost::interprocess, je n'y comprends pas grand chose

Ben si tu as boost installé sur ta machine, il suffit de rechercher dans les sources class basic_managed_shard_memory pour atteindre sa définition, et de remonter, sans forcément chercher à comprendre la logique de programmation, mais s'occuper purement des aspects syntaxiques langages concernant les templates.

[Flob90]

Je comprends globalement ce que tu as voulu faire, cependant certains détails m'échappent :

• Pourquoi le Alignement en plein milieu est en carré pointillé ? C'est parce que c'est un template qui vient spécialisé le TTP MemAligment ?
• Que signifie la flèche pointillé entre IndexType et IndexConfig ? Ça veut dire que IndexType est un TTP et IndexConfig le paramètre de ce TTP ?

[oodini]

Je comprends globalement ce que tu as voulu faire, cependant certains détails m'échappent

Je te remercie d'abord d'avoir passé quelques minutes sur ce diagramme, car ce n'est pas forcément un exercice passionnant.

Pourquoi le Alignement en plein milieu est en carré pointillé ? C'est parce que c'est un template qui vient spécialisé le TTP MemAligment ?

Oui, mais comme ce type de spécialisation est en fait encore un type inconnu, il est encadré en traits interrompu. C'est un typedef du paramètre template AllocationAlgorithm de shmem_open_or_create.
Je reconnais que ce n'est pas très clair, mais le code template est lui-même assez alambiqué.

Que signifie la flèche pointillé entre IndexType et IndexConfig ? Ça veut dire que IndexType est un TTP et IndexConfig le paramètre de ce TTP ?

Exact.
En fait, pour être cohérent, il faudrait que tous les paramètres templates apparaissent de cette façon, comme des boîtes en pointillés, référencés par des traits en pointillés. Sauf que cela encombrerait très vite le schéma. D'où cette représentation bâtarde, où je m'inspire à moitié de que fait UML en mettant les paramètres templates en haut à droite de la classe,, mais en les individualisant dans des boîtes individuelles.

[Flob90]

Je te l'avais dit sur ton autre sujet, mais un template se moque complètement que les types utilisés soient incomplets. Donc j'ai un peu de mal à voir la justification de changer de diagramme ici. C'est un type incomplet, mais quand même un type, la case normal serait tout aussi clair, AMA.

Pour les TTP, le second carré est en fait assez superflus dans le sens où le nom donné au paramètres templates d'un TTP n'ont aucune importance pour le code. Il apporte une indication sémantique (si c'est bien fait) au développeur qui lis la déclaration, mais en l’occurrence sur ton diagramme, je le trouve plus encombrant qu'autre chose.

[JolyLoic]

J'avoue que j'ai un peu du mal à tout comprendre...

Est-ce que tu pourrais le faire avec un exemple plus simple et élémentaire, genre une classe templatisée sur T, qui possède un vector<T> et un vector<bool>, et qui demande que les T soient triables ?

[oodini]

Je te l'avais dit sur ton autre sujet, mais un template se moque complètement que les types utilisés soient incomplets.

Pas forcément la personne qui cherche à comprendre comment est foutu une archi.

Donc j'ai un peu de mal à voir la justification de changer de diagramme ici. C'est un type incomplet, mais quand même un type, la case normal serait tout aussi clair, AMA.

C'est quand même un type, d'où la boîte, mais incomplet, d'où le tracé incomplet.
De toute façon, tout ce qui est boîte est un type. Je peux varier le style des boîtes pour faire varier la sémantique, pourquoi n'en profiterais-je pas ?

Pour les TTP, le second carré est en fait assez superflus dans le sens où le nom donné au paramètres templates d'un TTP n'ont aucune importance pour le code. Il apporte une indication sémantique (si c'est bien fait) au développeur qui lis la déclaration, mais en l’occurrence sur ton diagramme, je le trouve plus encombrant qu'autre chose.

Ce diagramme est avant tout destiné aux développeurs.

Il existe des manières de coder concises : opérateurs ternaires, virgule, etc.
Mais la clarté est toujours encouragée.
Même l'UML, format normalisé, peut très vite être touffu. Mais les éditeurs permettent de "cacher" les éléments non souhaités (membres, navigabilité, etc.).

Dans le cas de mon diagramme, j'imagine que ça serait une solution envisageable.

[oodini]

J'avoue que j'ai un peu du mal à tout comprendre...

C'est normal : c'est du Boost.
Et après tout, le langage UML s'apprend également.

Est-ce que tu pourrais le faire avec un exemple plus simple et élémentaire, genre une classe templatisée sur T, qui possède un vector<T> et un vector<bool>, et qui demande que les T soient triables ?

Tu trouveras ça ici.

edit : diagramme incorrect; voir mon prochain messsage

Concernant le dernier critère, j'avoue que je ne comptais pas aller jusque là. Car ce genre de considération demande à s'intéresser aux détails de l'implémentation, ce que je voulais éviter. Je te propose une solution, mais ne suis guère convaincu.

[JolyLoic]

C'est amusant ton "jusque là". Pour moi, c'est beaucoup moins de l'ordre du détail que le fait que vector<bool> soit une spécialisation et non une instanciation de base (si c'est bien ça que représente ton grisé et ton lien "implements").

C'est à la base de la notion des concepts/contraintes, et ça me semble fondamental dans ce genre de diagramme d'indiquer ce que la classe accepte/requiert des types selon laquelle on va l’instancier.

J'irais même plus loin : Si je définis une classe semblable à vector<T>, j'aimerais dire de manière synthétique que T doit être régulier, et que la fonction membre sort n'existe que si en plus T est comparable.

[oodini]

C'est amusant ton "jusque là". Pour moi, c'est beaucoup moins de l'ordre du détail que le fait que vector<bool> soit une spécialisation et non une instanciation de base (si c'est bien ça que représente ton grisé et ton lien "implements").

En fait, je me suis complètement planté avec le bool.

Il ne devrait pas être grisé, car il n'y a pas d'instanciation (sinon, c'est true ou false, comme au milieu du premier schéma). Il n'y a donc pas du tout de spécialisation, et toute la partie du bas est à enlever. Ça donne donc ça.

Mais ça permet de soulever un point intéressant, auquel je n'avais pas pensé : la "typologie" des templates (classe, enum, pointeur...) doit-elle être précisée ?

C'est à la base de la notion des concepts/contraintes, et ça me semble fondamental dans ce genre de diagramme d'indiquer ce que la classe accepte/requiert des types selon laquelle on va l’instancier.

Tu as raison. D'ailleurs, à la base, j'ai ressenti le besoin de faire ce diagramme pour représenter les typedef dépendant des paramètres templates.
Et je me suis beaucoup tâté à ce sujet. Est-ce que je faisais une surcouche à l'UML, où est-ce que je m'appropriais des représentations de l'UML pour en modifier la sémantique ?

La première solution m'a laissé penser que je serai vite limité par le type de représentations possibles (flèches, pointillés, etc.)
J'ai alors penché vers la seconde solution, en me plaçant dans le paradigme de la métaprogrammation : les typedef sont alors des membres. Mais avec tes requêtes, ça devient un peu compromis...

Mon premier diagramme manque d'ailleurs de cohérence : j'ai une relation de composition allant vers ManagedOpenOrCreateUserOffset, alors que c'est un typedef. En l'occurrence, il s'agit d'un entier. J'ai souvent changé d'avis lors de la création de ce diagramme...

Pour info, voici le code correspondant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class basic_managed_shared_memory
   : public ipcdetail::basic_managed_memory_impl
      <CharType, AllocationAlgorithm, IndexType
      ,ipcdetail::shmem_open_or_create<AllocationAlgorithm>::type::ManagedOpenOrCreateUserOffset>
   , private ipcdetail::shmem_open_or_create<AllocationAlgorithm>::type
{
   /// @cond
   typedef ipcdetail::basic_managed_memory_impl
      <CharType, AllocationAlgorithm, IndexType,
      ipcdetail::shmem_open_or_create<AllocationAlgorithm>::type::ManagedOpenOrCreateUserOffset>   base_t;
   typedef typename ipcdetail::shmem_open_or_create<AllocationAlgorithm>::type                     base2_t;
   ...
};

Et une ribambelle de typedef à la place des pointillés...

J'irais même plus loin : Si je définis une classe semblable à vector<T>, j'aimerais dire de manière synthétique que T doit être régulier, et que la fonction membre sort n'existe que si en plus T est comparable.

Cela apporte pas mal de richesse au diagramme, et donc de la confusion. Pour la régularité, une solution serait de sortir encore plus de l'UML, et de faire dériver (flèche avec traits interrompus, tête de flèche comme pour une dérivation) la classe d'une classe stéréotypée <<regular>>, qui ferait office de spécification.
Pour ton dernier souhait, je verrais bien une relation de spécialisation, mais plutôt que de griser la case, je rajouterais la fonction sort(), comme j'ai rajouté l'opérateur dans mon second diagramme.

De toute façon, je modifierais demain mon second diagramme en fonction de ce que j'ai dit plus haut, et j'essaierai d'en rajouter un autre avec ce que tu as demandé.

Ce qu'il faut maintenant, je crois, c'est que j'écrive les règles, car je m'aperçois que les représentations varient pas mal sur un même schéma...

Il me faudrait aussi un outil correct pour faire le dessin.

[oodini]

J'irais même plus loin : Si je définis une classe semblable à vector<T>, j'aimerais dire de manière synthétique que T doit être régulier, et que la fonction membre sort n'existe que si en plus T est comparable.

Voici ce que tu m'as demandé.

J'ai créé un composant <<fonction>>, qui permet d'extraire d'une classe la représentation d'une fonction, comme on le fait en UML pour les attributs.

Cela apporte en outre trois autres choses :

- la possibilité de définir des fonctions libres
- la possibilité de templatiser des fonctions
- la possibilité de définir l'amitié

[JolyLoic]

Je pense à peu près comprendre ta notation (même si "sort" ne figure pas dans l'image). Mais je ne suis pas encore vraiment convaincu. Même sur un cas assez simple (bien qu'assez complet), on arrive assez vite à quelque chose de très verbeux, et je ne suis pas certain que ça permette d'avoir une vue synthétique du sujet, ce qui est pour moi l'intérêt principal.

Il y a pour moi clairement un besoin de dessiner des architectures C++, mais je n'ai encore rien trouvé qui m'attire vraiment...

[oodini]

J'ai modifié mon schéma :
- la fonction sort a été rajouté
- le lien vers la fonction est maintenant celui utilisé pour les classes imbriquées (même si UMLet ne fournit pas la notation idoine... j'ai à la place ajouté un rond vide)

Concernant la verbosité, on peut dire la même chose de l'UML. Mais tous les éditeurs UML permettent de filtrer des infos. On pourrait par exemple cacher les templates qui ont un type par défaut, ou du moins celui de l'allocateur (on n'utilise que très rarement autre chose que l'allocateur standard).

Ce qui donne ceci.