Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ [conveption] hierarchies paralleles

[conveption] hierarchies paralleles

6 réponses
Avatar
Luc Hermitte
Bonsoir à tous.

Cela fait quelques jours que je tourne en rond à vouloir faire un truc
propre et simple pour un problème qui me parait somme toute classique.

Rapidement, le contexte est de séparer les servants Corba (si j'ai bien
suivi la terminologie) de classes "corps" qui implémentent ces servants.
Mon but est de rajouter une surcouche d'interface (sorte de bridge) qui
adapte les signatures C++ (const-correctes, et reposant sur la SL) des
fonctions des classes corps en signatures Corba-isées (non const-
correctes, types supportés par mon ORB, ...) côtés servants (plus
interception d'exceptions)

Bref. Tant que j'ai un corps pour un servant tout va bien. Je peux même
reposer sur des aides génériques (templates) qui facilitent la
définitions de paires {corps, servant} indépendantes.

Par contre, dès que je commence à m'occuper de hiérarchies, c'est la
cata. Je me retrouve à jongler entre retours covariants (qui se (en)
mêlent avec des dépendances croisées), functors (que mon vieux Sun-CC
supporte mal) et autres down-castings. Les aides génériques pour
faciliter la définition des servants et des corps est pratiquement
inpensable.

J'ai produit divers codes répondants à ces besoins, mais je ne suis pas
convaincu du résultat: c'est trop compliqué, et je n'en suis resté qu'à
l'indirection de fonctions sans retour (void) et sans paramètres.

Ce genre de problème me parait quelque part assez classique, j'imagine
qu'à un moment ou un autre vous avez dû le rencontrer. J'aimerai savoir
si vous l'avez résolu et comment. J'avoue avoir trouvé assez peu de doc
directement pertinente.


Pour info, mon objectif (en termes de gestion des durées de vie) est
d'avoir un centraliseur de corps (singleton classique); un objet corba
permet de demander et renvoyer (au client corba) des références vers les
servants associés aux divers corps stockés ; les servants appartiennent
aux corps, et ont une référence vers ces derniers ; la référence sert à
déléguer le traitement vers le corps.
Les cycles et tous les problèmes viennent avec ces deux derniers
objectifs.


Je suis preneur de toute lumière sur le sujet. Merci par avance.

--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Jean-Marc Bourguet
Luc Hermitte writes:

Bonsoir à tous.

Cela fait quelques jours que je tourne en rond à vouloir faire un truc
propre et simple pour un problème qui me parait somme toute classique.


Je ne suis pas sur d'avoir compris le contexte (je ne connais pas
corba et sa terminologie et ca complique ma comprehension; peut-etre
en relisant ca passerait mieux mais j'ai pas vraiment le temps, on
verra ce soir chez moi), mais ca me fait penser a un probleme
effectivement classique qui est comment accorder une hierarchie de
classes d'interfaces avec une hierarchie de classes d'implementation.
J'ai en projet depuis un certain temps d'ecrire qqch la dessus, mais
je ne trouve pas le temps de le faire. Rapidement, les possibilites
sont:

* utilisation de template parametre par la classe la plus derivee
(voir la presentation de Gabriel et B.S. sur leur representation
interne du C++; Gaby avait donne un lien et j'avais pose des
questions dessus) Il y a des limitations mais quand elles ne posent
pas de problemes, cette technique est la plus efficace.

* l'utilisation de l'heritage multiple; il y a des couts certains,
en particulier la taille des objets;

* heritage multiple mais gere a la main; comme c'est un cas
particulier d'heritage multiple, on arrive a une structure moins
couteuse en taille des objets, mais avec plus de couts d'ecriture
car il faut beaucoup de classes (du moins dans l'etat ou je suis,
j'etais en train de voir comment simplifier a l'aide de template la
derniere fois que j'ai travaille la-dessus) et si j'ai bonne memoire
une indirection ou deux de plus sur les appels.

Si ca ne suffit pas, je peux etendre, mais ce sera quand j'aurai le
temps.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Luc Hermitte
Luc Hermitte writes:

Cela fait quelques jours que je tourne en rond à vouloir faire
un truc propre et simple pour un problème qui me parait somme
toute classique.


Je ne suis pas sur d'avoir compris le contexte (je ne connais pas
corba et sa terminologie et ca complique ma comprehension; peut-etre
en relisant ca passerait mieux mais j'ai pas vraiment le temps, on
verra ce soir chez moi), mais ca me fait penser a un probleme
effectivement classique qui est comment accorder une hierarchie de
classes d'interfaces avec une hierarchie de classes d'implementation.


C'est bien le même genre de principe. Au détail que je voudrais
plutôt m'orienter vers une séparation par délégation (on retrouve
des points communs entre proxies et bridges).
En fait, en plus de la séparation interface / implémentation, j'ai
une conversion de signatures: un simple getID() côté servant ne peut
pas être const, alors que pour la mise en oeuvre, je cherche à être
le plus const-correct possible ; plus toutes les conversions de
std::string et autres collections en données échangeables via l'ORB.

"servant" fait parti de la terminologie Corba. De ce que j'ai compris,
c'est une classe qui implémente l'interface corba côté serveur.
"body" (/corps) est un terme que j'ai repiqué à des articles que j'ai
pu lire.


J'ai en projet depuis un certain temps d'ecrire qqch la dessus, mais
je ne trouve pas le temps de le faire.


Je sais ce que c'est :(

Rapidement, les possibilites sont:

* utilisation de template parametre par la classe la plus derivee
(voir la presentation de Gabriel et B.S. sur leur representation
interne du C++; Gaby avait donne un lien et j'avais pose des
questions dessus) Il y a des limitations mais quand elles ne
posent pas de problemes, cette technique est la plus efficace.


J'avais envisagé ce genre de trucs, mais c'est dans cette direction
que je me retrouve coincé avec des constructions complexes. À la
base, j'avais un problème plus global qui me bloquait. Dans la classe
de base, il me faut obtenir un pointeur vers la classe d'en face,
pointeur qui est stocké dans la classe dérivée => retours covariants
dans les deux sens, et dépendences croisées.

J'imagine qu'il doit y avoir une autre façon de s'y prendre avec ces
mécanismes.
Tu te souviendrais d'un mot clé (/m-id) qui m'aiderait à retrouver
ton post ou ces liens ?


* l'utilisation de l'heritage multiple; il y a des couts certains,
en particulier la taille des objets;


J'ai déjà de l'héritage multiple côté servants. Seulement, je
cherchais justement à sortir du servant le code d'implémentation.


* heritage multiple mais gere a la main; comme c'est un cas
particulier d'heritage multiple, on arrive a une structure moins
couteuse en taille des objets, mais avec plus de couts d'ecriture
car il faut beaucoup de classes (du moins dans l'etat ou je suis,
j'etais en train de voir comment simplifier a l'aide de template
la derniere fois que j'ai travaille la-dessus) et si j'ai bonne
memoire une indirection ou deux de plus sur les appels.


Je ne suis pas sûr de voir ce que tu veux dire.


Merci pour ton temps. :)

PS: je passe via googlegroups, j'espère que le format du message sera
OK.


Avatar
Jean-Marc Bourguet
"Luc Hermitte" writes:

Luc Hermitte writes:

Cela fait quelques jours que je tourne en rond à vouloir faire
un truc propre et simple pour un problème qui me parait somme
toute classique.


Je ne suis pas sur d'avoir compris le contexte (je ne connais pas
corba et sa terminologie et ca complique ma comprehension; peut-etre
en relisant ca passerait mieux mais j'ai pas vraiment le temps, on
verra ce soir chez moi), mais ca me fait penser a un probleme
effectivement classique qui est comment accorder une hierarchie de
classes d'interfaces avec une hierarchie de classes d'implementation.


C'est bien le même genre de principe. Au détail que je voudrais
plutôt m'orienter vers une séparation par délégation (on retrouve
des points communs entre proxies et bridges).


Pour la différence entre les deux est qu'un proxy a
essentiellement la même interface que la classe qu'il
représente (je dis essentiellement car un jeu de signature
du genre ajouter const et utiliser std::string à la place de
char*, ça reste du proxy pour moi), un bridge a une
interface différente que la classe qu'il adapte.

En fait, en plus de la séparation interface / implémentation, j'ai
une conversion de signatures: un simple getID() côté servant ne peut
pas être const, alors que pour la mise en oeuvre, je cherche à être
le plus const-correct possible ; plus toutes les conversions de
std::string et autres collections en données échangeables via l'ORB.

"servant" fait parti de la terminologie Corba. De ce que
j'ai compris, c'est une classe qui implémente l'interface
corba côté serveur. "body" (/corps) est un terme que j'ai
repiqué à des articles que j'ai pu lire.


J'ai en projet depuis un certain temps d'ecrire qqch la dessus, mais
je ne trouve pas le temps de le faire.


Je sais ce que c'est :(

Rapidement, les possibilites sont:

* utilisation de template parametre par la classe la plus derivee
(voir la presentation de Gabriel et B.S. sur leur representation
interne du C++; Gaby avait donne un lien et j'avais pose des
questions dessus) Il y a des limitations mais quand elles ne
posent pas de problemes, cette technique est la plus efficace.


J'avais envisagé ce genre de trucs, mais c'est dans cette direction
que je me retrouve coincé avec des constructions complexes. À la
base, j'avais un problème plus global qui me bloquait. Dans la classe
de base, il me faut obtenir un pointeur vers la classe d'en face,
pointeur qui est stocké dans la classe dérivée => retours covariants
dans les deux sens, et dépendences croisées.

J'imagine qu'il doit y avoir une autre façon de s'y prendre avec ces
mécanismes.
Tu te souviendrais d'un mot clé (/m-id) qui m'aiderait à retrouver
ton post ou ces liens ?


C'était un article qui pointait vers des documents power
point pour une conférence. L'exposé concernait leur
representation interne du C++. L'idée est aussi présente
dans ce que je montre ci-dessous.

* l'utilisation de l'heritage multiple; il y a des couts certains,
en particulier la taille des objets;


J'ai déjà de l'héritage multiple côté servants. Seulement, je
cherchais justement à sortir du servant le code d'implémentation.


* heritage multiple mais gere a la main; comme c'est un cas
particulier d'heritage multiple, on arrive a une structure moins
couteuse en taille des objets, mais avec plus de couts d'ecriture
car il faut beaucoup de classes (du moins dans l'etat ou je suis,
j'etais en train de voir comment simplifier a l'aide de template
la derniere fois que j'ai travaille la-dessus) et si j'ai bonne
memoire une indirection ou deux de plus sur les appels.


Je ne suis pas sûr de voir ce que tu veux dire.


Rapidement, la structure finale à laquelle je pense.

Les classes AI, BI, CI sont les classes d'interfaces.
Les classes AC, BC, CC sont les classes concrètes à utiliser réellement.
Les classes AP, BP, CP sont des proxy pour faire l'adaptation.

// x.hh
struct AI { virtual void fa() = 0; }
struct BI: AI { virtual void fa() = 0; }
struct CI: BI { virtual void fa() = 0; }

struct factory
{
AI* makeAI();
BI* makeBI();
CI* makeCI();
};

// x.cc

template <typename T1, typename T2>
struct AP: T1 {
AP(): impl(this) {}
void fa() { impl.fa(); }
T2 impl;
};

template <typename T1, typename T2>
struct BP: AP<T1, T2> {
void fb() { this->impl.fb(); }
};

template <typename T1, typename T2>
struct CP: BP<T1, T2> {
void fc() { this->impl.fc(); }
}

struct AC {
AC(AI* self) : mySelf(self) {}
void fa() {...}
AI* mySelf;
};

struct BC: AC {
void fb() {...}
};

struct CC: BC {
void fc() {...}
};

AI* factory::makeAI() { return new AP<AI, AC>(); }
BI* factory::makeBI() { return new BP<BI, BC>(); }
CI* factory::makeCI() { return new CP<CI, BC>(); }

Pour les téméraires, mySelf devrait être à un offset
constant de AC en l'absence d'héritage multiple dans la
hiérarchie d'interace.

Si les classes concrètes n'ont pas besoin de devoir se
présenter comme des classes d'interface, mySelf n'est pas
nécessaire.

Dans BC, static_cast<BI*>(mySelf) est bien défini.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org



Avatar
Jean-Marc Bourguet
"Luc Hermitte" writes:

Tu te souviendrais d'un mot clé (/m-id) qui m'aiderait à retrouver
ton post ou ces liens ?


http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
Message-ID:

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Jean-Marc Bourguet
Jean-Marc Bourguet writes:

"Luc Hermitte" writes:

Tu te souviendrais d'un mot clé (/m-id) qui m'aiderait à retrouver
ton post ou ces liens ?


http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
Message-ID:


Tiens Gabriel, dans cet exposé vous indiquez que la solution
avec héritage multiple était trop lente. Vous avez une idée
de la raison?

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org


Avatar
Gabriel Dos Reis
Jean-Marc Bourguet writes:

| Jean-Marc Bourguet writes:
|
| > "Luc Hermitte" writes:
| >
| > > Tu te souviendrais d'un mot clé (/m-id) qui m'aiderait à retrouver
| > > ton post ou ces liens ?
| >
| > http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
| > Message-ID:
|
| Tiens Gabriel, dans cet exposé vous indiquez que la solution
| avec héritage multiple était trop lente. Vous avez une idée
| de la raison?

(1) double indirection pour les fonctions virtuelles dans les classes
de base virtuelles (i.e. toutes les classes interfaces) -- grosso modo,
une première indirection pour adjuster "this", et une deuxième
indirection pour appeler la fonction proprement dite. Si de plus
tu utilises le Visitor Design Pattern par dessus, tu commences à
voir la différence entre ça et des switch sur des enums.

(2) les objets "simples" tendaient à devenir gros

La solution avec les classes d'interface paramétrées par les classes
d'implémentation, on a une linéarisation de la hierarchie, des
indirections et une réduction de la taille des objets. Et j'ai
remarqué qu'ajouter des classes plus tard ne semblaient pas si
difficile que je ne l'aurais imaginé. Mais cela demande aussi une
bonne vue de l'ensemble de la hiérarchie.

-- Gaby