C++ function/member templates

[kikeenrique]

Hello again,

Would it be possible, or is it possible at the moment, to write function or members templates?

I’m currently using a templated class with just one member function to represent this, but I think it’s a workaround.

Regards

[Bruno Pagès]

Hello,

You cannot model a function/member out of a class, so yes you have to place them into a class, having a very reduced definition like ${members}

It is not mandatory to use a templated class even this can be more practical, the template<...> header can be insert directly into the function/member definition

You can also define the function/member directly into an artifact definition, but in that case this is just a text, not a modelization

Kind regards

[kikeenrique]

I’m going to elaborate a bit more my proposal, as I didn’t fully understand your answer.

Your indication with the template<...> would be only for the c++ tab definition, not for modeling, did I understand properly?
I would be interested in modeling templated member functions, individually, in a class.

Currently to model a class template you can do it using the “parameterized” tab. There you can set as many template parameters as you want. That’s perfect.

But, when defining a class method/operation, you can’t set templated parameters specific for that method.
Maybe it would possible to add a new parameterized/template tab into the method/operator dialog.
Then, when setting method parameter types, you could use class template parameters, which it’s already available, or the method template parameters, which would be the ones declared in the new proposed tab.

Do you think it’s interesting?

[Bruno Pagès]

Your indication with the template<...> would be only for the c++ tab definition, not for modeling, did I understand properly?

yes

I would be interested in modeling templated member functions, individually, in a class.
...

As you know the operations of a template class have to respect the template parameters list, for instance in

Code: Select all

template<class T, class V>
class C {
  public:
    inline void op();
    inline void op2();
    inline void op3();
};

template<class T, class V>
inline void C<T, V>::op() {
}

template<class T>
inline void C<T>::op2() {
}

template<class T, class V, class W>
inline void C<T, V, W>::op3() {
}

the definition of op2 and op3 are illegal because I removed/added a template parameter.

So frankly I am not ready to add a template parameter tab in the operation to help to produce an illegal code

If by chance you have several definitions sharing the same template parameters I agree you can put them in a pseudo templated class (whose do not generate a class but only its members).
Else to define several pseudo templated classes each for one definition is heavy for nothing, again it is better to have only one pseudo class containing the members independently of their template parameters list and to add by hand the expected template<...> in their C++ declarations/definitions

[Teaniel]

Bonjour Bruno,

Désolé de rappeler cet ancien sujet, mais il m'intéresse aussi.
Je pense que le souhait de kikeenrique est de pouvoir modéliser des fonctions membres template

Code: Select all

class A {
    template <class T> typeRet fonction( /* mes arguments */ );
};

template <class T> typeRet A::fonction( /* mes argulents */ ) { ... }

template <class T>
class B {
    template <typename Y> typeRet maFontion(/*mes parametres*/);
};

template <class T>
template <typename Y>
typeRet B<T>::maFonction(/* mes parametres */) { ... }


C'est en effet une construction très utilisée en C++ (de plus en plus en fait par la STL en particulier, et surtout dans les dernières versions du langage (c++11/17/20)). Je ne sais pas si les autres langages l'utilisent ou pas.
Actuellement, je la construis en modifiant la définition/déclaration dans le volet C++, mais je trouve cela très peu pratique.
Raison pour laquelle je me permets d'insister, vous m'en excuserez j'espère.
Elle permet en particulier de déclarer/définir en une fois un grand nombre de fonctions ayant la même déclaration et le même corps à un paramètre près.
Je peux comprendre que vous ne soyez pas enchanté de réaliser cela car ce me semble un gros chantier. Cependant cela me semble également intéressant de pouvoir modéliser des groupes de fonctions membres dans BOUML (de la même manière qu'on peut modéliser des groupes de classes).

Je voulais également ajouter une petite remarque (concernant précisément les nouvelles versions de C++) : il manque une case à cocher constexpr également dans le volet C++ des fonctions membres (à partir de C++11 ou 17 je ne sais plus, une fonction membre peut prendre le 'statut' constexpr et être utilisée dans les calculs relatifs aux paramètres template). Même remarque que plus haut, actuellement je modifie la déclaration et/ou la définition dans le volet C++ pour ajouter ce modificateur, mais je trouve cela ni très joli ni pratique.

Voila. J'en profite également pour vous complimenter à nouveau pour votre exceptionnel travail ainsi que la longévité et la constance de votre suivi (cela fait près de quinze ans que j'utilise Bouml).
Cordialement,
Marc

[Bruno Pagès]

Bonjour,

Il semble que j'avais mal compris la demande initiale de kikeenrique, je pensais qu'il voulait remplacer la forme template<...> issue de la classe par une autre au niveau de l'opération et non en ajouter une comme c'est le cas dans votre demande pour maFon(c)tion

Concernant constexpr, actuellement il faut en effet explicitement le mettre dans la déclaration et définition d'une opération, ce que font le reverse et roundtrip C++, mais ni plus ni moins qu'une indication const. Il y a bien le mot clef ${const} et le checkbox correspondant pour les opérations mais ils ne concernent pas le type retourné. Dans le cas des attributs/relations c'est différent car le mot clef ${const} et le checkbox correspondant s'appliquent au type supporté et existaient avant la gestion de constexpr, j'avais donc pu étendre la gestion de ${const} pour qu'il produise constexpr en 5.1 avec le nouveau checkbox constexpr dans leurs éditeurs. Pour avoir un checkbox constexpr au niveau d'une opération en C++ il faut aussi ajouter un checkbox const(value) pour C++ et il faut ajouter le nouveau mot clef ${constvalue} pour générer const ou constexpr ou rien en C++ (rendre le comportement de ${const} dépendant de sa position me parait bien compliqué et interdirait son utilisation dans un commentaire car il serait impossible de savoir à quoi il correspond).

A noter qu'il en est exactement de même pour volatile qui actuellement suit les mêmes règles que const au niveau attribut/relation/opération, si je gère const/constexpr pour le type retourné par une opération il faudrait logiquement faire de même pour volatile et donc ajouter un checkbox volatile(value) au niveau d'une opération en C++ et le nouveau mot clef ${volatilevalue} pour générer volatile ou rien en C++, ou plus simple de gérer la production de const/constexpr/volatile via le seul mot clef ${typeprefix}.

P.S. Le checkbox const est au niveau UML pour les attributs/relations, et qu'il devrait indiquer que l'attribut/relation est constant, mais comme la définition des attributs/relations est ...${const}${type} ${name}... et non pas ...${type} ${const}${name}... dans le cas d'un pointeur ce n'est pas l'attribut/relation qui est constant mais la valeur (par exemple cela donne const char * a et non pas char * const a), mais comme personne n'a jamais protesté et que cela à toujours été comme cela je ne l'ai pas changé/corrigé. Il en est de même pour volatile même si j'ai ajouté sa gestion bien après.

[Bruno Pagès]

Hello,

The release 7.9 is available adding for the operations in C++ (c.f. historic) :

- a new management for the function template with the new tab allowing to specify formals on an operation, it is not anymore necessary to enter the template form by hand into the C++ operation declaration/definition

- the new check boxes to specify the return value is const, constexpr or volatile

The C++ code generator / reverse /roundtrip manage these new features, and there are also available to the plug-outs (after an update through plug-out upgrade)

Kind regards

[kikeenrique]

Thank you Bruno, really,

After a quick look it seems to do what I asked.

On the other hand, I don't fully understand what do I have to do after reading this release notes comment:

"Warning the keyword ${typeprefix} is only present by default in the models created from that version of Bouml. If you expect it in your existing projects you have to add it in the default operation C++ declaration/definition in the generation settings and in the existing C++ operation declaration/definitions. "

* Could you explain it for really basic minds, where exactly am I expected to add ${typeprefix} ?

* I also can't find where are located the new check boxes. "the new check boxes to specify the return value"

[Bruno Pagès]

Hello

Could you explain it for really basic minds, where exactly am I expected to add ${typeprefix} ?

If you create a project with the release 7.9 the keyword is present by default in the generation settings and in the C++ declaration/definition of an operation, it is before ${type}, so

declaration :

Code: Select all

${comment}${friend}${static}${inline}${virtual}${typeprefix}${type} ${name}${(}${)}${const}${volatile}${throw}${abstract};


definition :

Code: Select all

${comment}${inline}${typeprefix}${type} ${class}::${name}${(}${)}${const}${volatile}${throw}${staticnl}{
  ${body}}


I also can't find where are located the new check boxes. "the new check boxes to specify the return value"

There are dedicated for C++ so there are on the right top part of the C++ tab when you edit an operation :

nfcpp.png (70.1 KiB) Viewed 144 times

KInd regards,

Bruno

P.S. sorry for the delay to answer, I a in England for few days