Discussion :

[screetch]

c'est pour un projet personnel, qui en est plutot aux couches bas niveaux qu'aux couches haut niveau (sous entendu, c'est le moment de péter des trucs de maniere incompatoble avec la version précédente)

mais parfois j'ai (stupidement) donné du code a mon entreprise que j'avais fait durant le week end.

encore que la je me vois mal dire "eh les gars on va supprimer tous les pointeurs nus du code" :p

[poukill]

Personnellement, je préfère utiliser les outils déjà disponibles pour la gestion de vie des objets (boost::shared_ptr, boost::weak_ptr). Parce que :

1. Ils ont été particulièrement bien étudiés. Donc faire mieux dans un cas précis, certes. Mais dans la globalité, bof...
2. Surtout, quand quelqu'un relit mon code, il sait de quoi ça parle sans aller jeter un coup d'œil au code "maison" du codeur précédent. C'est un peu comme les design pattern, ça permet de créer des références communes à tout développeur.

[nicroman]

Enfin, je suis un peu de l'avis de screetch....
Quand on parle de smart-ptr tout programmeur digne de ce nom sait de quoi on parle....
Bizarrement, j'ai croisé plus de gens ayant des problemes de distinction entre "shared_ptr", "weak_ptr", "intrusive_ptr", ... qu'avec un bon gros "smart_ptr"

En plus le codage d'un intrusive_ptr (renommé pour l'occasion en 'smart_ptr') est pas vraiment ce qu'il y a de plus compliqué (tant qu'on se gourre pas dans les ordres de lock/unlock lors de l'affectation....).

L'avantage que moi j'y ai trouvé (à les réécrire) c'est que:
- Comme screetch, j'ai des "weak_ptr" qui ne servent qu'à repérer les "mauvais" pointeurs leur d'une destruction intempestive (assertions).
- A l'inverse de screetch, je ne suis pas un nazi du pointeur nu Et la plupart des fonctions prenent des pointeurs nus en paramètre "in" plutot que des smart-ptr.
- Il me permet d'utiliser des routines bas-niveau pour l'interlocking et donc le thread-safe sans mutex global (ou pire, mutex par objet), mais cette implémentation est laissée au choix de la classe finalement (si un objet n'a de sens que dans un thread donné, nul besoin de mutex).
- Il me permet aussi d'avoir une phase de "deferred" initialization (à la première référence), et de "deferred" destruction (à la dernière référence).
- Il me permettent d'inclure un system de garbage-collection / pool directement au choix de l'objet.
- Il me permettent d'intégrer de manière complètement transparente du COM (qui est basé sur de l'intrusive ptr, et n'a rien à voir avec Windows). Avec un système de QueryInterface automatique lors des affectations.
- Finalement, en debug, il me permettent à tout moment de sortir un arbre de dépendances.
- Par contre, tout comme screetch, ils ne marchent pas avec les objets sur la pile, mais pour le coup, une assertion est levée en cas de CREATION d'un tel objet dans la pile (le thread est l'unique maitre d'un objet sur la pile, donc conceptuellement, c'est absoluement contre-nature d'avoir un smart-ptr sur un objet de pile).

[camboui]

Question:
Pour qu'un refcounting smart ptr soit threadsafe, suffit-il de protéger le refcount ?
Donc sous Windows, les InterlockedIncrement() et InterlockedDecrement() suffisent-ils ?
Merci.

[Luc Hermitte]

Ceux de boost utilisent des compteurs atomiques quand compilé en MT -- donc les InterlockedMachin en win32, etc.
Quelques part, cela se tient.

[screetch]

oui, lorsque boost peut ils utilisent les intrinsics de GCC ou MSVC (Interlocked, ou bien __sync_atomic_add ou un truc comem ca sous GCC 4)
si le compilo est plus ancien ou inconnu au bataillon ils se rabattent sur les mutex (ce qui etait un de mes problèmes)
il peut y avoir un probleme de synchro si on crée un refptr au moment ou il est detruit sur un autre thread, cependant

[Kalith]

@camboui : Puisque j'ai un exemple que qqn qui mélange pointeurs intelligents et pointeurs nus sous la main, j'en profite :
En règle générale, dans quelles situations utilises-tu les pointeurs intelligents ? Et comment geres-tu leur intégration avec le reste du code (qui se sert donc de pointeurs nus) ?

[nicroman]

La réponse est somme tout assez simple:
Un objet a besoin de conserver la reference sur un autre objet ? => smart-pointer
Une fonction n'a pas besoin de conserver la reference ? => pointeur nu (l'appelant va avoir un smart-pointer qui ne saurait être détruit tant que la fonction ne retourne pas, on est garanti de la durée de vie de l'objet pointé).
Une weak-collection par contre (database des objets instanciés, arbres de tri, ...), doit être garantie par l'objet lui même (et s'assurer que la collection en question ne contient plus de reference *avant* sa destruction)...

[screetch]

en fait avec un pointeur nu on est pas une garantie que l'appelant va conserver la référence assez longtemps. Si tu as besoin de stocker ce pointeur, le smart pointer qui le possède peut quand meme etre détruit. C'est pour cela que je ne veux pas de pointeurs nus et que je souhaite les remplacer par des weakptr, mais ma définition du weakptr est différente du weakptr de boost. "mon" weakptr ne fait qu'etre un pointeur nu, mais en débug, il incrémente un second compteur de référence (le nombre de pointeurs weak) et si ce compteur n'est pas a zero lors de la destruction de l'objet, il y a une assertion (éventuellement on peut meme prolonger la vie de l'objet pour que ca ne plante pas lorsqu'on detecte cette erreur, mais ca reste une erreur)

[JolyLoic]

mais ma définition du weakptr est différente du weakptr de boost.

Et as-tu étudié la possibilité de l'appeler autrement, pour éviter la confusion ? Je demande parce que même avec ce pointeur, il peut y avoir des cas où l'utilisation d'un weak_ptr avec la sémantique de boost::weak_ptr reste utile. Un truc genre checked_ptr me semble plus proche de ce que fait ce pointeur.

[screetch]

bah c'est bien un weak pointer, j'avoue que je me vois mal renommer un truc qui a un nom correct parce qu'il en existe une autre version avec un comportement un peu différent

[camboui]

bah c'est bien un weak pointer, j'avoue que je me vois mal renommer un truc qui a un nom correct parce qu'il en existe une autre version avec un comportement un peu différent

Mon smart ptr s'appelle safe_ptr et lorsque je ferais un weak ptr je l'appelerais naked_ptr . Ou alors subsafe_ptr.

screetch, tu disais ne pas avoir de fonction get() afin de forcer l'usage de operator->() le cas échéant. Perso je laisserais get() (je préfère get_ptr()) avec une condition de compilation qui le désactive afin de vérifier facilement si quelqu'un l'a utilisé ou pas. Vérifier si quelqu'un a utilisé operator->() est moins trivial je pense.

Ceci dit, j'insiste . Je suis curieux de voir tes smart ptr en l'état, même inachevés. Par exemple je ne vois pas comment tu "surveilles" ton weak ptr si tu dis que ce n'est qu'un pointeur nu. Si je comprends bien, il n'existe qu'en mode debug. En mode release tu laisses l'appli se planter le cas échéant. C'est ça ?

[camboui]

@camboui : Puisque j'ai un exemple que qqn qui mélange pointeurs intelligents et pointeurs nus sous la main, j'en profite :
En règle générale, dans quelles situations utilises-tu les pointeurs intelligents ? Et comment geres-tu leur intégration avec le reste du code (qui se sert donc de pointeurs nus) ?

Dangereux de me demander à moi. Ce n'est que très récemment que j'ai découvert l'utilité de weak ptr, ici post #39 .
J'utilise des pointeurs parce que c'est une des bases du langage, et parce que j'utilise ça depuis 15 ans avec habitude et une certaine souplesse. Je trouve d'ailleurs assez risible de devoir se justifier sur ce forum quand on les utilise . C'est tout juste si on ne se fait pas lyncher .

Ah j'y pense, ça fait quand même 10 ans que j'utlise un smart ptr, mais c'était sans le savoir. Il s'appelle... CComPtr.

Depuis un peu plus d'an j'essaie de remettre en question ma programmation en C++. Un peu tout seul dans mon coin. Et je commence tout doucement à me laisser "endoctriner" par le forum . Le smart ptr n'est qu'un détail dans cette remise en cause.

Pour l'instant je n'en utilise qu'un de mon cru, le plus léger qu'il puisse être je pense. Il a une contrainte, il n'est pas assignable: on est obligé de passer par l'équivalent d'un make_shared de boost. Je trouve en toute logique que si on ne s'occupe pas du delete d'un objet on n'a pas à s'occuper non plus du new.
Conceptuellement, il me sert pour l'instant juste à gérer les instances d'objets sur le tas avec la même souplesse que ceux de la pile.

[Kalith]

Dangereux de me demander à moi. Ce n'est que très récemment que j'ai découvert l'utilité de weak ptr, ici post #39 .

... beh, moi aussi ! Faut bien commencer un jour

J'utilise des pointeurs parce que c'est une des bases du langage

... comme les char* et consorts. Ca veut pas dire pour autant que c'est une toujours bonne idée de les utiliser

... et parce que j'utilise ça depuis 15 ans avec habitude et une certaine souplesse.

Ca, je le comprends tout à fait : moi aussi j'y suis bien habitué aux pointeurs nus. Je ne programme que depuis quelques années, et j'ai déjà du mal à m'en passer, alors après 15ans...

Je trouve d'ailleurs assez risible de devoir se justifier sur ce forum quand on les utilise ...

Je pense que ça va finir comme le "combat" char* vs std::string. Dans le fond, c'est un peu pareil : sûreté/simplicité d'emploi vs rapidité/contrôle pointu.
On devrait encourager les débutants à utiliser les smart_ptrs, mais de là a faire un génocide de pointeurs nus... peut être pas

Merci en tout cas pour ton avis !

[screetch]

je me rend compte que j'avais oublié de répondre a camboui pour le smart pointer
mon code se trouve deja en ligne sur http://code.google.com/p/bugengine/s...api/minitl/ptr
libre a toi de regarder dans les fichiers. Je suis en train de changer ces pointeurs justement pour interdire les pointeurs nus, tu devrais sans doute regarder demain ou apres demain a quoi ca ressemble.
ca depend d'autres fichiers dans l'arborescence mais tu dois pouvoir y trouver ton bonheur ou au pire generer un projet visual studio

[camboui]

Merci

[screetch]

(a noter aussi que le code thread-safe interlocked est incorrect et qu'il convient seulement sur un monoprocesseur (meme dual ou quad core) et risque de planter sur un biproc)
j'espere avoir mis assez de disclaimers...

[camboui]

C'est la première fois que j'entends parler que du code thread-safe pourrait ne pas l'être en fonction du hardware.
C'est sans doute hors sujet, mais quelqu'un aurait-il un lien qui discute de cette problématique ?

[screetch]

c'est seulement le code que j'ai ecrit qui n'est pas vraiment thread safe ^^
je n'ai pas eu le temps de mettre les "memory barriers"
je crois que j'ai mis viteuf les memory barriers sur le code PowerPC mais pas sur le code x86

pour la discussion => http://groups.google.fr/group/comp.l...48a0495c521f32 (voir le post numéro 11 principalement)
http://www.safercode.com/blog/2009/0...dispelled.html

merci a Luc Hermitte et promis, j'ai dans l'idée de réparer ca