authoriser / interdire l'acces aux methodes d'une classe

J'ai un driver de peripherique stocké dans une classe : Driver

J'ai une classe gestionnaire de periph appelée par les
differentes threads : DM

Un thread demande l'acces au driver et recoit une clef
qui l'identifie comme propriétaire

en cours de route la clef peut etre invalidée pcq un process
prioritaire a pris la main sur le driver

j'ai donc une fonction

Driver * DM(int key);

si la clef est valide le device manager renvoie le pointeur sur le driver
sinon il lance une exception

--- il me semble que ce systeme est correct en tout cas si vous avez meilleure idée !! je suis preneur ---

Mon probleme est le suivant, en cas d'export du code
et d'utilisation par une tierce personne pressée

il suffit d'ecrire :

Code:

---

1 2 3 4

int key = DM::GetKey(); Driver * t = DM::Driver(key) t->Truc() t->Bidule()

---

au lieu de

Code:

---

1 2 3

int key = DM::GetKey(); DM::Driver(key)->Truc() DM::Driver(key)->Bidule()

---

ou la si la fonction a perdu la main entre truc et bidule
DM peut lancer une exception

alors qu'en sauvegardant l'acces dans une variable
ce n'est pas verifié et le peripherique va peter

l'ideal serait que seul le device manager puisse activer la fonction
de maniere indirecte (il suffirait qu'il soit friend de Driver) mais je ne vois pas comment faire :cry:


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

C'est pas clair ta présentation.

Citation:

---

j'ai donc une fonction

Driver * DM(int key);

---

Tu l'utilise ou cette fonction DM dans ton code??
Pas la en tout cas

Code:

---

Driver * t = DM::Driver(key)

---

Je crois que cet article peut t'intéresser:

http://christophej.developpez.com/tu...n/multithread/

Il n'est pas en C++, mais le concept reste identique et permet de comprendre la difficulté de la chose.

ok pour le pattern singleton

mais ca ne me donne pas des droits d'acces "propres" aux methodes d'une classe

Citation:

---

ok pour le pattern singleton

mais ca ne me donne pas des droits d'acces "propres" aux methodes d'une classe

---

Qu'est-ce que tu entends par "accès propre"?

Je n'arrive pas à comprendre le problème : les membres privées d'une classe d'objet c'est le BA - BA du C++ ; ce sont les bases j'ai l'impression qu'il ya confusion ....
Sinon il faudrait donner plus de détails : est-ce que TOUS les composants et classes sont développés par soi-même ou bien est-ce que par exemple le driver en question provient d'une société tierce dont on n'a le code source .???
Dans le cas contraire il suffit de créer des classes d'objets avec des membres private point à la ligne

Citation:

---

Envoyé par moldavi

Je crois que cet article peut t'intéresser:

http://christophej.developpez.com/tu...n/multithread/

Il n'est pas en C++, mais le concept reste identique et permet de comprendre la difficulté de la chose.

---

Je doute qu'on puisse adapter ce qui est développé en Java vers C++ ; ce sont des méchanismes radicalement différents.

Citation:

---

Je doute qu'on puisse adapter ce qui est développé en Java vers C++ ; ce sont des méchanismes radicalement différents.

---

As-tu lu l'article? Je n'ai jamais parlé d'adaptation mais de concept. Cet article permet de voir quels types de problèmes on peut rencontrer dans un environnement multithread.

Moi ce que je ne saisis pas c'est que tu donnes un accès direct au driver (via DM::Driver(key)) alors que ce que tu shouaites c'est justement qu'on ne puisse pas l'utiliser directement (mais via DM::Driver(key)) :?:

tout d'abord merci pour votre participation

ensuite, je n'ai jamais dit que mon probleme etait bien posé


le contexte, je developpe entierement l'ensemble de l'application
neanmoins (un jour) elle sera mise en diffusion afin que d'autre
personnes (par tres informaticiennes) l'utilise pour developper
des applis autours de ce peripherique. Donc disons que je m'occupe
de l'ecriture du coeur de l'appli - gestion MDI - option de base
driver -- quelques fenetres MDI qui utilise le driver en guise d'exemple

voila le probleme : je n'ai qu'une instance de driver, donc singleton (ok)
(disons pour simplifier un peripherique qui fait de l'acquisition de mesure).

Chaque fenetre mdi propose differents scenario et quand j'appuie sur le boutton go => la fenetre declenche les operations sur le peripheriques a partir d'un thread.

Il peut y avoir plusieurs fenetres ouvertes. Mais une fiche ne prend les droits sur le peripherique que lorsque l'experience est lancée, pas lorsque l'on rentre les modalités de l'experience.

MON PROBLEME :)

Pour les futurs developpeurs amateurs j'aurais aimé qu'ils aient acces au driver par un driver manager qui leur masque le probleme de semaphore (qui n'entre pas dans les choses dont ils voudront se preoccuper - si dans leur code il oublie de rendre le semaphore - l'appli est morte).

Ainsi :

Un thread prend la main et se sert du device manager pour faire cela
et il rend la main quand il a fini. Mais l'utilisateur peut oublier de progammer la gestion de la liberation du peripherique (car il faut aussi l'integrer dans les diverses plantages et gestion d'exception ce qu'il ne fera pas). Lorsqu'un autre thread demande la main, l'interet serait d'avoir une messagebox demandant a l'utilisateur s'il authorise le nouveau thread a prendre la main. (donc meme si le programme est mal foutu, le semaphore sera relachée et on aura encore acces au periph - c'est mieux que de fermer/reouvrir l'appli)

Si l'utilisateur dit oui - le dernier demandeur prend la main et l'ancien utilisateur perd la main.

Conclusion j'ai toujours deux threads qui vont acceder a la meme ressource (le driver) dont un qui n'a plus le droit de le faire

Alors j'avais pensé que la classe device manager pourrait donner le droit d'acces au driver (et a ses methodes) et que les appels du thread invalidé genereraient (par l'intermediaire du device manager) une leve d'exception. Pour que le thread s'arrete.

(mon idée n'est peut etre pas la meilleure ... )

comment faire cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class Driver { friend driver Manager private : static driver * GetInstance(); void FaitCa(); public : }   class Driver Manager { private : int key; public : int RequestKey() { key++; return key; } void FaitCa(int KK) { if ( key != KK) throw TU_NES_PLUS_PROPRIETAIRE; sinon Driver::GetInstance->FaitCa(); }

---

Probleme C EST PAS GENERIQUE
cad que pour chaque evolution de mon driver
va falloir que je duplique la modif dans driver manager (beurk)
c'est pas du tout reutilisable sur une autre version de driver directement.

J'aurais voulu une classe driver manager qui me permette l'acces a n'importe qu'elle classe (ainsi qu'aux methodes...)

Citation:

---

Alors j'avais pensé que la classe device manager pourrait donner le droit d'acces au driver (et a ses methodes) et que les appels du thread invalidé genereraient (par l'intermediaire du device manager) une leve d'exception. Pour que le thread s'arrete.

(mon idée n'est peut etre pas la meilleure ... )

---

Je ne vois pas de meilleure idée.

Citation:

---

Probleme C EST PAS GENERIQUE
cad que pour chaque evolution de mon driver
va falloir que je duplique la modif dans driver manager (beurk)
c'est pas du tout reutilisable sur une autre version de driver directement.

---

Là faut que tu m'expliques, je ne vois pas ou est le problème.

Si ton driver est modifié cela doit rester transparent à la classe "driver manager". Au pire si tu dois modifier cette classe, cela devrait aussi rester transparent pour les classes "driver" que d'autres personnes vont programmer.

l'implementation presentée ci-apres garantit tout ce que je demande, cependant je duplique toutes les fonctions de driver dans driver manager et c'est pour cela que je dis que c'est pas reuse.

Citation:

---

class Driver
{
friend driver Manager
private :
static driver * GetInstance();
void FaitCa();
public :
}

class Driver Manager
{
private : int key;
public :
int RequestKey() { key++; return key; }
void FaitCa(int KK) {
if ( key != KK) throw TU_NES_PLUS_PROPRIETAIRE;
sinon Driver::GetInstance->FaitCa();
}

---

Heu........

Tu connais l'héritage et le polymorphisme?

:oops:

euh oui

peux tu remasteriser le code de l'exemple ci dessus ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

template <class T>   class CDriverManager{   public:   static T& GetInstance() { if(!Inst) Inst = new T; return *Inst; }   static void Destroy() { delete Inst; Inst = NULL; }   bool RequestDriver() {   if(!Libre) return false; else{ Libre = false return true; }   virtual FaitCa() = 0;     protected:   CDriverManager(); ~CDriverManager();   int key;   private:   static T* Inst;   bool Libre;   CSingleton(CSingleton&);   void operator =(CSingleton&); };   class Driver : public CDriverManager<Driver>{   friend class CDriverManager<Driver>;   private:   void FaitCa();   void Request() { if(CDriverManager::GetInstance()->RequestDriver()) FaitCa(); } };

---

Ce code est largement inspiré de la classe CSingleton du tutorial de Loulou24. (qu'est-ce qu'on dit : merci loulou24).

Ce code comporte sûrement plein d'erreur, désolé mais j'espère que des gens le corrigeront, merci à eux.

C'est surtout pour te donner un point de départ je l'espère...

L'idée général:

tu déclares virtual la fonction FaitCa(); dans la classe manager. Ainsi chaque classe Driver pourra la redéfinir.
Avant de faire quoique ce soit, les classes Driver demande si la ressource est libre, sinon elles atendent et retentent plus tard.

Je n'ai pas implémenter le fait qu'il puisse y avoir plusieurs ressources. A ce moment là à toi de passer en paramètre la-dite ressource et de gérer ça.

Il n'y a pas non plus les fonctions gestion des ressources (mutex), par exemple si une classe driver demande la ressource je stoppe le thread qui le détient, et je donne la ressource tout de suite. On peut imaginer un mécanisme de message avec temporisateur et un mécanisme de priorité.

Mais je vais pas te faire tout le bouleau et je suis même en train de me demander si j'en suis capable... :lol:

A la limite la classe CDriverManager se comporte comme le ferait un système d'exploitation qui gère ses ressources et le multitâche. (Ben là bonne chance).

Il y a parfois des classes dédiées à la gestion des mutex et des sémaphores.
Pourquoi pas ne pas en faire hériter CDriverManager. Tu auras moins besoin de te casser la tête.

Par contre je ne peux rien te dire de plus, je n'ai jamais implémenté...

je lis et relis ton exemple (merci bien au fait)
il me semble qu'il est assez proche du mien (tout en etant different)

En fait la question sur la reutilisabilité etait :

j'ai un driver A

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class driver A { func1() func2() func3() };   class driver B { func5() func6() };

---

si je passe par un template(ta methode) ou polymorphisme
je suis coincé car les drivers ne sont pas sensés avoir les
memes fonctions (bien au contraire !!!)
Par contre le driver manager n'en a qu'une

une autre maniere de gerer le probleme (cote semaphore ca va je suis a jour j'y ai passé le dimanche dessus !!!)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

template<class T> TManager { T * thedriver; int key;   public : static Accede(int key) { if ( access != key ) throw "t'as perdu les droits kiki" else return thedriver; } int static GetKey() { return key++; } };

---

ainsi dans le programme j'accede
au driver part :

Code:

---

1 2 3 4 5 6 7 8 9

TManager<driverA> TT;   fnt() { int k = TT::GetKey(); TT.Accede(Key)->func1(); TT.Accede(Key)->func2(); TT.Accede(Key)->func3(); }

---

si un autre thread choppe une autre clef entre temps, fnt recevra une exception au prochain acces au driver sur func2 ou func3

cette methode marche tres bien
le probleme est que j'ai peur qu'un user tappe :

Code:

---

1 2 3 4 5 6 7 8

fnt() { int k = TT::GetKey(); driverA * d = TT.Accede(Key); d->func1(); d->func2(); d->func3(); }

---

et la plus aucune verification des droits

(pour preciser mon statut, je suis informaticien de profession, mais etant chercheur d'activité, je ne pratique plus... sauf pour les projets, le probleme par exemple est que la j'effectue un mois de codage serieux et c''est mon premier depuis un an... et je sens que j'ai perdu... l'informatique étant ma passion, cela m'effraie et donc je rebosse a mort pour relever le niveau que j'estime "juste" arrive a maintenir a flot


[Balises CODE rajoutées par Loulou24, merci d'y penser à l'avenir]

arf, on ne voit pas les choses de la même façon...

Ce n'est pas un reproche mais j'ai l'impression que tu ne comprends pas la notion de polymorphisme.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class driverA{   func1(); func2(); func3(); FaitCa(){ func1(); func2(); func3(); } };   class driverB{   func5(); func6(); FaitCa(){ func5(); func6(); } };

---

En gros bien sur!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

bon on reprend :)

si normalement je suis a jour cote polymorphisme :) enfin je crois mais bon tout est possible :)

alors...

pourquoi tout mettre dans FaitCa, a la base mon "premier" driver dispose de 10 fonctions diverses et variées, je ne peux jamais dire dans quel ordre elles sont appelees, donc impossible d'ecrire ce que tu dis dans le message ci dessus

les drivers sont sensés etre completement differents donc pas de polymorphisme

par contre j'aurais aimé ecrire une seule classe, driver manager<Template driver> qui recoit la gestion de la prise de main du peripherique par les threads et ca je n'y arrive pas

Citation:

---

les drivers sont sensés etre completement differents donc pas de polymorphisme

---

C'est ça l'histoire. Avec FaitCa() drivermanager pas besoin de connaître la façon dont les classes driver implémente cette fonction. En améliorant même le code que j'ai mis tu pourrais t'assurer que les classes driver n'accèdent pas en même temps à la même ressource.

Citation:

---

par contre j'aurais aimé ecrire une seule classe, driver manager<Template driver> qui recoit la gestion de la prise de main du peripherique par les threads et ca je n'y arrive pas

---

Je ne vois pas ce qui ne marche pas, précises.

Code:

---

1 2 3 4 5 6 7 8 9

TManager<driverA> TT;   fnt(){   int k = TT::GetKey(); TT.Accede(Key)->func1(); TT.Accede(Key)->func2(); TT.Accede(Key)->func3(); };

---

Tu veux absolument que ce soit manager qui appelle tes fonctions. C'est l'inverse que tu dois faire.

Tes classes exécuteront tes fonctions depuis leur classe si elles en ont l'autorisation. Regardes bien mon code. A ce moment drivermanager ne fait bien qu'uniquement gérer les accès ressources.

Code:

---

1 2 3 4 5 6 7 8

fnt() { int k = TT::GetKey(); driverA * d = TT.Accede(Key); d->func1(); d->func2(); d->func3(); }

---

La classe drivermanager est un singleton, c'est justement pour éviter ce genre de chose.

PS: ce sujet que je pense ne pas bien maîtriser, m'intéresse parce que bientôt je vais devoir implémenter les threads dans mon programme. :D

Bon c'est difficile de bien se comprendre et de bien s'expliquer.

En effet je crois que je me suis égaré avec le polymorphisme. Je n'avais pas bien en tête la conception générale.

L'idée c'est peut-être ça:

Lorsque tu utilises une fonction qui accède à une ressource, on va dire que c'est un cas critique.

Dès que tu entres dans une de tes fonctions func1(); func2();, etc...

Code:

---

1 2 3 4 5 6 7 8

func1(){   CDriverManager::GetInstance()->entercriticalsection();   ... // ton code   CDriverManager::GetInstance()->leavecriticalsection(); }

---

L'idée c'est que de cette manière, ton code ne sera exécuté que lorsque drivermanager te donneras la ressource.

Après à toi de décider comment sont distribuer les ressources.

je nage...

j'ai plusieurs endroits dans mon programme qui appele une meme ressource. Habituellement, on gere cela par un semaphore qui empeche les autres d'acceder a une ressource quand elle est occupée par qqn.

Je ne veux pas de ce modele, car je considere que mes endusers vont se planter en manipulant les semaphores...

je veux donc faire une classe tampon entre mon driver et le code du programme. Cet objet n'a qu'un role, donner l'acces au dernier thread qui demande l'acces et interdire tous les autres. Ce qui est contraire au principe du partage de ressource-semaphore-mutex.

--- les reponses se croisent

disons que le probleme est que j'ai un thread par exemple qui affiche le % d'utilisation du peripherique. C'est un thread qui doit donc acceder au driver directement entre deux requetes et dont l'appel ne gene en rien

J'ai d'autres thread qui ont une action plus violente
arret du peripherique
initialisation des commandes a effectuer
lancement des commandes


jai englobe tous les envoies d'ordre au pheripherique par un // enter critical et end critical (mutex)

par contre
je voudrais que si un thread demande la main sur le perihperique, qu'une exception remonte jusqu'au thread en train de manipuler le periph

Citation:

---

--- les reponses se croisent

---

En effet...:D

Citation:

---

je voudrais que si un thread demande la main sur le perihperique, qu'une exception remonte jusqu'au thread en train de manipuler le periph

---

Ca d'accord je comprends.

Citation:

---

jai englbe tous les envoies d'ordre au pheripherique par un // enter critical et end critical (mutex)

---

De quelle façon? Ne serait-ce pas à cette endroit que tu peux savoir quelle ressource doit recevoir un une exception?N'est-ce pas le role de drivermanager?

Citation:

---

jai englobe tous les envoies d'ordre au pheripherique par un // enter critical et end critical (mutex)

---

OK, tu gères l'accès aux ressources avec "enter critical et end critical (mutex)".

Est-ce que c'est toi qui a codé "enter critical et end critical". Dans ce cas là pourquoi ne pas les "spécialiser" et leur donner la possibilité de se souvenir qui posséde quelle ressource. Ainsi tu pourra lancer une exception au thread qui possède la ressource, lorsque justement un nouveau thread voudra s'accaparer une ressource?

hum yes...

je peux ecrire :

Code:

---

1 2 3 4 5 6 7 8 9

fnt_du_driver 1 enter critical (WaitForSingleObject sous windows) if ( key != key_owner) { end critical (release) throw "tu as perdu les droits" } truc() end critical (release)

---

donc a ce niveau pas de driver manager, gestion des semaphores dans le driver et aussi de la clef

pour chaque fonction je dois copier.coller ce morceau...

le but du driver manager aurait été qu'il agisse comme un filtre
ou je n'ai pas à dupliquer toutes les fonctions du driver

mais j'ai peur de ne pas arriver a coder cela

J'ai bien compris ton problème ouioui.

Pour l'instant je ne vois pas d'autres solutions (mais je cherche...).

Et en renvoyant des proxy qui eux sauront à tout moment qui dispose vraiment des droits ?

1- c'est quoi un proxy ?

2- j'ai ouvert mon bouquin de design pattern sur l'etagere plein de poussiere... j'ai vu le pattern ETAT qui correspond pas mal a ce que je veux. En fait une classe qui peut se mettre dans 2 etats differents suivant ses decisions internes (par exemple la connexion internet : ouvert ou refus).

Pour cela il passe par une classe abstraite qui declare l'interface commune et les sous classes implementent les comportements specifiques

je crois donc que je suis quitte pour dupliquer ma classe... tant pis, c'est le charme de l'objet

1- proxy == intermédiaire qui cache certains détails, typiquement l'accès aux données de l'objet réel.

3- à la va-vite.... et assez bourrin
(penser à séparer délcarations et implémentation)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

// public struct IDriverA { virtual void f() = 0; };   // caché ; penser aux dépendances cycliques -> FAQ struct DriverAimpl : IDriverA { ..... implémentation des fonctions du driver A et ....   auto_lock a_le_droit(const proxyDriverA * p) const { auto_lock al(mutex_); if (p.getId() == last_id_) return al; else return auto_lock(0); }   DriverAimpl() : last_id_(-1) {}   ProxyDriverA requestDriver() { scoped_lock sl(mutex_); return ProxyDriver(this, ++last_id_); }   private: type_mutex mutex_; int last_id_; };   // public struct ProxyDriverA : IDriverA { /*virtual*/ voif f() { scoped_lock l(DAimpl-> a_le_droit(this)); if (l) { implDA_ -> f(); } }   ProxyDriverA( DriverAimpl * impl, int id ) : DAimpl_(impl), id_(id) {} int getId() const { return id_;} // seulement pour DriverAimpl   private: DriverAimpl * implDA_; // def à inclure seulement dans le .cpp // une decl en avant suffit sinon   int id_; };   // Le singleton exposé struct DA_manager : boost::noncopyable { static DA_manager & instance();   ProxyDriverA requestDriver() { return DA_.requestDriver(); }   private: DA_manager() {}; DriverAimpl DA_; }

---

auto_lock et scoped_lock sont des lock RAII (sans ça le code est dessuite plus pénible à écrire et maintenir). Le premier a une sémantique de déplacement (voir std::auto_ptr<>), le second une sémantique de non-copyable et d'auto-détruit en fin de bloc (voir boost::scoped_ptr, boost::scoped_lock, ...)
D'ailleurs les habitués de boost.threads pourront très certainement corriger et améliorer ce brouillon.

Reste aussi en exo la mise la factorisation du code via polymorphisme paramétrique (et non d'héritage/inclusion/...) afin de gérer d'autres types de drivers.

EDIT: le résultat est que

Code:

---

1 2 3 4 5 6

ProxyDriverA da1 = DA_manager::instance().requestDriver(); da1.f(); // marche   ProxyDriverA da2 = DA_manager::instance().requestDriver(); da1.f(); // marche plus da2.f(); // marche

---

da1 et da2 n'étant pas obligés d'être dans le même thread, tout ça.
Et si j'ai bien compris, c'était la question initiale.

la vache, ca fait mal

bon ca fait une heure que je relis et relis... c'est clair je suis pas au niveau (rassure moi tu fais du c++/objet avancé tous les jours ?). Cependant j'ai compris le principe.

Je fais donc une version plus simple et tu me diras si c'est a peu pret cela, l'astuce (enfin l'idee) consiste non pas a renvoyer un pointeur bourrin sur le driver mais un objet contenant la clef courante et le driver. Ainsi j'ai plusieurs instance de mon driver mais un seul detient la bonne clef.

la RAII c'est du stroustrup ?

y a des bouquins qui parlent de ces techniques ? moi je me suis arrete a stroutrup 3ed / stl et intro aux design pattern...

L'idiome Ressource Acquisition is Initialization porte globalement mal son nom. Surtout que c'est un effet de bord de cet idiome qui en fait toute son importance.

Le principe simplifié à retenir est qu'une ressource ne doit jamais se ballader seule dans la nature et doit systématiquement être enveloppée par un objet automatique qui la libèrera à la sortie de son (l'objet) bloc. Un objet automatique étant un objet qui vit dans la pile, ce qui signifie que son destructeur sera appellé (automatiquement) à la sortie du bloc dans lequel l'objet vit. Le destructeur se chargera de réaliser les libérations de ressources (delete, ou delete[], ou unlock, ou XMLReleaseString, ou close, ou ... suivant le type de ressource enveloppée).
C'est un peu le pendant (d'un point de vue besoin: libération déterministe de ressources) du dispose-pattern des langages comme le Java.

Les sous-bibliothèques sus-cités de boost proposent déjà divers types d'enveloppeurs de ressources à la sauce RAII. Les blogs d'Herb Sutter en parlent pas mal -- en profiter sur GOTW pour voir la sémantique de déplacement des std::auto_ptr<>. Le chapitre 4 sur les techniques du C++ de C++ in Action (consultable en ligne) présente lentement cela, mais avec une autre appelation. Un article ("Big Two machin chose") très succint et efficace sur artima en parle. Dans la même famille, Andrei Alexandrescu a écrit un article sur la gestion des exceptions, article dispo dans le forum expert du CUJ et référencé depuis son site (moderncppdesign).

Désolé, je ne connais pas les liens par coeur, mais google tes les donnera rapidement à partir des points d'entrées que j'ai laissés.


Sinon oui. En passant par des proxies ton problème peut avoir une solution.
Côté bouquins, on parle des proxys dans le GoF, mais aussi dans More Exceptional C++ de Scott Meyer -- Addisson-Wesley est globalement ma crèmerie préférée.

thx :) c'est tres clair, merci

je n'ai pas trouve le bouquin dont tu parles j'ai :

effective c++ scott meyer addison
more effective c++ scott meyer addison

et

More Exceptional C++ by Herb Sutter

Bigre les gens, j'ai l'impression que vous tentez de mettre un cataplasme sur une jambe de bois... C'est une bête question de design, et le singleton n'est pas la réponse, je pense !!

Citation:

---

Envoyé par buzzz

J'ai un driver de peripherique stocké dans une classe : Driver

---

Bon, et ce driver est unique, c'est une ressource

Citation:

---

Envoyé par buzzz

[...]

j'ai donc une fonction
Driver * DM(int key);
si la clef est valide le device manager renvoie le pointeur sur le driver
sinon il lance une exception

--- il me semble que ce systeme est correct en tout cas si vous avez meilleure idée !! je suis preneur ---

---

Moi ça me semble tout bon, si tu est sûr qu'on ne peut pas préempter pendant l'excution de Truc() ou Machin()...

Citation:

---

Envoyé par buzzz

il suffit d'ecrire :

Code:

---

1 2 3 4

int key = DM::GetKey(); Driver * t = DM::Driver(key) t->Truc() t->Bidule()

---

alors qu'en sauvegardant l'acces dans une variable
ce n'est pas verifié et le peripherique va peter

---

Et bien il suffit que celà soit impossible.

Code:

---

1 2 3 4 5 6 7

class DM { ... static void Truc(int key); static void Bidule(int key); ... };

---

Les fonction s'occupe de vérifier la validité de la clé, et exécute la fonction voulue si OK.

Citation:

---

Envoyé par buzzz

l'ideal serait que seul le device manager puisse activer la fonction
de maniere indirecte (il suffirait qu'il soit friend de Driver) mais je ne vois pas comment faire

---

Oui, si c'est une classe de confience, un protected friend qui à accès à la méthode qui retourne un Driver*

Fais gaffe aux interblocages !

Citation:

---

Les fonction s'occupe de vérifier la validité de la clé, et exécute la fonction voulue si OK.

---

oui cela marche
mais il n'y pas de reutilisatibilité pour l'ecriture d'un autre driver ou ressource, la version du candidat precedent parait plus lourde mais l'idee est plus avancée.

En effet dans ton cas je dedouble toutes les fonctions (dans driver et DM)
dans son exemple aussi (pas le code juste la declaration).

Dans mon idée actuelle, il suffit de prendre un singleton Driver manager qui contient la clef valide et de repliquer des instances de driver avec des clefs differentes. Ainsi UNE seule classe driver a ecrire et CA ME PLAIT,

C++ In Action (Premier résultat sous google)
GoF -> Gang of Four -> les auteurs du bouquin de référence sur les design patterns.

Sinon, je suis assez d'accord que ces choix de fonctionnement me paraissent assez compliqués.
Après que l'on utilise un singleton ou fonctions membre statiques ne change pas grand chose.

Pour ce qui est des sémaphores-mutex-... ils se doivent d'être gérés de façon transparente dans le code appelé et non délégués aux utilisateurs finaux.

EDIT: en surchargeant operator->() et operator*(), il n'y a rien à écrire en double -- mais on ne dérive plus de IDriverA non plus alors.

Citation:

---

effective c++ scott meyer addison
more effective c++ scott meyer addison
et
More Exceptional C++ by Herb Sutter

---

la question n'etait pas sur GoF, mais la question etait toi tu me parlais de : More Exceptional C++ de scott, de quel bouquin s'agit il parmi les references citees ?

Citation:

---

operator->() et operator*(),

---

hum, ca va un peu vite, mais je vois

bon j'arrive a ma version :) (1 seule classe... DM+Driver fondu)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class Driver { private : static int key; int mykey;   public : Driver() { mutex; mykey = key++; release mutex; } fnt1(...) { mutex; if ( mykey != key ) { release mutex; throw boum; } peripherique->commande(); release mutex; } };

---

bon court / clair / propre (?)
le mutex protege le peripherique et la clef... que du bonheur...
l'objet est automatique

apres 3 jours de reflexion
je crois que je vais prendre cette solution !!!!!!

:oops: J'avais pas vu les pages suivantes...

Effectivement un peu à coté de la plaque je suis.

Enfin pas complètement, la réponse à ta question de départ reste : ne renvoie pas de Driver* aux utilisateurs finaux (qui sont parfois peu finauds, tu as raison de te méfier !)

pour l'instant le end user c'est plutot moi
mais je mefie de moi meme :D
autant que de mes utilisateurs finaux

La gestion du mutex ne va pas (il doit être accessible partout depuis l'objet), et l'incrément sur la clef n'est pas bon -- faire une pré-incrémentation au lieu d'une post (Sinon le statique est toujours décalé d'un).

Note au passage, je n'aurais pas exposé la donnée statique pour à la place la cacher dans l'unité de traduction (.cpp)

Le problème avec ta dernière classe est que tu dupliques les drivers. Genre si le driver toto a un état qui peut être modifié et observé depuis plusieurs threads différents, avec cette approche, les états sont tous disjoints. Côté implémentation tu vas revenir à centraliser ces états dans un unique objet qui est connu (en interne) de tous les objets exposés aux utilisateurs. Bref retour à la solution avec proxy.
D'ailleurs, question peut-on observer (comme dans le DP) sans lever le jeton d'accès ?


Sinon, pour les bouquins, je me suis effectivement emmelé les pincaux. Les MEC++ est le More Effective C++, tandis que le MXC++ est le More Exceptional C++. De toutes façons, ce sont 4 (et plus) bons bouquins.

tiens pas encore couché... ca se voit qu'on a la meme profession :P

Citation:

---

La gestion du mutex ne va pas (il doit être accessible partout depuis l'objet),

---

le mutex est commun a la classe.. variable statique donc
pour proteger aussi la clef :)

Citation:

---

et l'incrément sur la clef n'est pas bon -- faire une pré-incrémentation au lieu d'une post (Sinon le statique est toujours décalé d'un).

---

oui vu

Citation:

---

Note au passage, je n'aurais pas exposé la donnée statique pour à la place la cacher dans l'unité de traduction (.cpp)

---

une fausse statique donc...

Citation:

---

Le problème avec ta dernière classe est que tu dupliques les drivers. Genre si le driver toto a un état qui peut être modifié et observé depuis plusieurs threads différents, avec cette approche, les états sont tous disjoints. Côté implémentation tu vas revenir à centraliser ces états dans un unique objet qui est connu (en interne) de tous les objets exposés aux utilisateurs. Bref retour à la solution avec proxy.

---

jour de chance !! il n'en a aucun :) (pour une fois !!!)
et de toute facon comme dans mon modele le dernier
objet driver créé prend la main :) il reset automatiquement
le periph, donc les variables d'etat sont les siennes car tous
les autres instances derriere ont pris une exception une a une

Citation:

---

D'ailleurs, question peut-on observer (comme dans le DP) sans lever le jeton d'accès ?

---

je dirais que non... le peripherique (branchée sur l'usb et commandé par un controle activeX (beurk)) a de forte humeur. Ainsi meme si on lui donne une commande, il ne l'a fait pas forcement, le seule moyen de connaitre son etat est de lui demander, donc acces au periph=> mutex

Citation:

---

Sinon, pour les bouquins, je me suis effectivement emmelé les pincaux. Les MEC++ est le More Effective C++, tandis que le MXC++ est le More Exceptional C++. De toutes façons, ce sont 4 (et plus) bons bouquins.

---

ok je vais faire rentrer cela