Version imprimable
C'était juste pour une petite comparaison (peut-être déplacée) par rapport à l'extension du language, bref...Citation:
Envoyé par Goten
Ceci dit, je suis d'accord le C++/CLI a sa propre norme mais qui reprend la norme C++ avec quelques distinctions comme par exemple un pointeur qui est défini par * en C++ norme ISO alors que la norme C++/CLI utilise ^.
Mais bon, on ne me fera pas changé d'avis, c'est du C++.
C'est une norme qui reprend une norme comme c'est énorme :lol:
Et comme la norme C++ reprend la norme C, le C++ est du C, et par transitivité le C++/CLI est du C ? Tu es vraiment certain d pas vouloir changer d'avis ?
Bonsoir,
Citation:
Envoyé par coyotte507
Il y a un article intéressant sur le sujet dans la faq.
Oui, enfin à l'heure actuel il ne gère même pas le problème de l'ordre d'initialisation, alors de là à gérer celui de libération ...
De plus qu'il à l'air d'avoir besoin que le destructeur soit appelé, dans ce cas l'allocation "statique" est une solution, mais elle impose de s'assurer de ne pas se retrouver fasse au problème mentionné.
Quel est la 3° solution dont parle la faq ? Un truc du genre Phoenix Singleton ?
Bonjour,
Le pointeur libéré a la fin est utile dans le cadre d'un Singleton
La solution que j'ai mise fait des deletes si nécessaire.
Pour le compteur sur les pointeurs c'est un autre design pattern (smartPointer).
Dans ce cadre la on se retrouve avec un pointeur en static donc tu ne peut pas vraiment le compter vu qu'il peut être appelé a tous moment le comptage est utilisé des que le pointeur ce promène dans tes classes.
Si il est static tu peut l'invoque des le moment ou tu instancie ta classe c'est pour cela que j'ai parler de la libération de la mémoire a la fin de sont exécution
Après si tu est sur de sont utilisation et de ces appels tu peut toujours faire une méthode pour libérer ton pointeur.
Chessmaster1966 ne dénigrez pas ce que vous ne connaissez pas.
Cela vous évitera bien des déconvenues, et sur ce forum, bien des quolibets.
Le "^" du C++/CLI, ce n'est pas pour les pointeurs mais pour les références sur les objets managés.
En C++/CLI, il y a une très forte distinction entre les objets managés dans l'environnement .NET et les objets dit natifs.
Et cela n'a rien à voir avec Visual Studio mais avec .NET.
Vous pouvez faire du C++/CLI sans VS et utilisez VS pour faire du C++ (natif).
Le neuneu qui utilise un GC vous salut, "Chessmaster1966" mais pas "C++/CLIMaster". :furieux::frenchy::boulet:
P.S.: pour faire écho à l'utilisation maladive de "static" par Chessmaster1966, les instances "static" dans les classes managées ne sont pas initialisées au démarrage de l'application mais au chargement de la classe dans un AppDomain, et il peut avoir plusieurs AppDomain dans une application .NET. Chessmaster1966 pense que "static" a la même signification dans tous les langages mais le "static" du Java est aussi lié à son ClassLoader et aux distinctions entre Inner Class et Nested Class.
Enfin bref, "Chessmaster1966" vous connaissez l'histoire de la culture et du parachute ?
Un singleton ne libère pas toujours sa ressource, ca dépend des décisions faites, tu peus choisir de ne pas la libérer, de la libérer une seul fois et de ne pas gérer le cas où le singleton est utilisé après sa mort, ou décider de le gérer (solution à base de atexit), et encore d'autre chose, c'est une question de choix.Citation:
Envoyé par jouana
Alexandrescu en propose pas mal dans Loki, mais en imaginer d'autre n'est pas interdit.
Pour ce qui est du C++/CLI j'ai juste voulu dire que c'était simplement du C++ avec les spécificités de .NET. Je n'ai jamais dit que j'utilisais le mote clé "static" dans C++/CLI mais en C++ puisque je ne programme pas avec la plateforme .NET puisque j'utilise Code::Blocks.Citation:
Envoyé par bacelar
Ce que je voulais dire par C++/CLI c'est du C++ c'est que celui qui connaît le C++ n'aura aucun mal à programmer avec C++/CLI alors que celui qui connaît que le C ne pourra pas programmer immédiatement en C++, c'était le fond de ma pensée !
Un dernier point je n'ai jamais pris pour neuneu qui que ce soit sur se forum.
En introduisant ce genre de réflexion je savais que je n'allais pas me faire d'amis c'était juste pour ouvrir un petit débat.
Pour en revenir à l'usage de "static" puisque tout est parti de là je reste sur ma position il n'y aucun problème d'initialisation ou de libération il faut effectivement faire attention et gérer les instances qui l'utilisent.
Je ne suis peut-être pas un spécialiste du C++ mais je le connais et jusqu'à présent tout problème qui c'est présenté à moi je l'ai traiter tout seul sans l'aide de qui que ce soit. Par mon expérience j'essayes d'apporter ma contribution à ceux qui sont en quête de résolution de problème.
C'est vraie que tout les artciles traitant de l'ordre d'initialisation des variables statiques et ceux traitant des problèmes de libération de ce genre de variables ne servent absolument à rien ...Citation:
Envoyé par Chessmaster1966
Faux, archi-faux.Citation:
Ce que je voulais dire par C++/CLI c'est du C++ c'est que celui qui connaît le C++ n'aura aucun mal à programmer avec C++/CLI alors que celui qui connaît que le C ne pourra pas programmer immédiatement en C++, c'était le fond de ma pensée !
C++/CLI utilisent un ensemble de concept complètement étrangés au C++ standardisé, dont quelques commencent à apparaître dans les projets de standards C++1x.
Je sais qu'on ne peut pas avoir la science infuse mais ce n'est pas une raison pour donner des contre-vérités et ne pas écouter les conseilles des autres sur les pièges courant de l'utilisation de static comme implémentation de singleton.
Regardez bien leurs réponses et commencez à remettre en question vos certitudes, comme nous tous. :aie:
Heu, c'est une anti-phrase, ça ? :aie:Citation:
Un dernier point je n'ai jamais pris pour neuneu qui que ce soit sur se forum.
Citation:
Il y a ceux qui programment avec Visual et lorsqu'ils créent des pointeurs dynamiques il s'en remette au garbage collector pour ma part je pense que cette façon de programmer n'est pas bonne. Car le jour ou ils n'utiliseront pas un tel système de développement et bien ils auront du souci à te faire !!!
Euh le garbage collector et le C++ je cherche hum.
C'est pas java, flash et peu être C# qui utilise le garbage collector
Faut pas confondre la libération de mémoire a la fin d'un processus et le garbage collector de ce type de langage haut niveau qui nous donne pas trop la main au niveau gestion de cette dernière.
Bah le truc c'est qu'un singleton a pour utilité de juste rendre une instance unique peut importe ou elle est appelé donc c'est pas très conseillé de libéré le pointeur sa augmente les risque d'appelé a ce dernier et tomber sur un pointeur pourris.Citation:
Un singleton ne libère pas toujours sa ressource, ca dépend des décisions faites, tu peus choisir de ne pas la libérer, de la libérer une seul fois et de ne pas gérer le cas où le singleton est utilisé après sa mort, ou décider de le gérer (solution à base de atexit), et encore d'autre chose, c'est une question de choix.
Et la solution du atexit je ne sais plus ou j'ai vu sa mais ce n'est pas trés conseillé sa foire pas mal et c'est pas très propre surtout en C++ avec des solutions comme les exceptions qui permette une sortie de programme et un gestion d'erreur beaucoup plus propre.
donc c'est pour sa que je disait que l'on pouvait se permettre de ne pas trop la toucher après c'est vrai qu'il est plus propre de tous libérer soit même.
Et pour répondre a chessmaster sur l'histoire de "gros problème" si on libère pas la mémoire, je connais le principe de la fuite mémoire :)
Mais je vois pas l'utilité de gérer la mémoire sur une variable static a part si changement du pointeur ou il et logique de libérer le dernier mais ce n'est pas trop le but chercher avec ce type de variable cela revient au même d'avoir un extern/import dans un programme enfin bon.
Après peu être que je m'exprime mal et si c'est le cas j'en suis désolé bonne journée tout le monde :))
Ca depend à quoi sert ton singleton, si il gère quelque chose qui doit être détruit, tu as plutôt interet à le faire. (genre un fichier, si tu le fermes pas à la fin ...) Et tu peus le détruire mais aussi t'assurer que si l'on tente de le réutiliser alors la varibale soit recréé, cf Phoenix Singleton.Citation:
Envoyé par jouana
Le comportement de atexit est normalement correctement définit maintenant, il y avait apparament des problèmes d'utilisation il y a plusieurs années mais je n'en sais pas plus. atexit permet de rajouter une fonction à la pile des fonctions appelés à la fermeture du programme (dans des conditions normales), ca n'interfère pas avec les excpetions (il n'est pas question d'appeler exit explicitement).
Tout est questions de choix et de contexte, il y a plein de facon de faire un sinlgeton, si je compte juste celles présentés par Alexandrescu dans MC++D (sans les version MT imparfaite), il y en a déjà 12, tous différents, allocation statique/dynamique, destruction/pas de destruction/phoenix, ...
Le gros problème du DP singleton en C++ c'est pas la facon de gérer la création et la destruction, de ces points de vues tout ce que tu peus imaginer est techniquement réalisable. C'est la partie LT qui pose problème, aucunes solutions (popularisée du moins*), ne permet la création du singleton dans une partie threadée de manière général et sans risques.
(*) Des solutions à base de Memory Barrier ou de CAS semble donner des résultats.
Il n'y a pas à chercher bien loin pourtant : A garbage collector for C and C++.Citation:
Envoyé par jouana
Et il y a eu des discussions sur l'intégration d'un GC en C++0X. Il n'est pas exclus que l'on voit arriver un tel GC dans une future version de C++.
Pour ça un RAII suffirait et serait plus approprié je pense.Citation:
Ca depend à quoi sert ton singleton, si il gère quelque chose qui doit être détruit, tu as plutôt interet à le faire. (genre un fichier, si tu le fermes pas à la fin ...)
Les solutions à base de bons vieux mutex et de locking à chaque accès marchent bien, mais les gens n'en veulent pas... Ils lui préfèrent du double checked lazy singleton, qui lui, ne marche pas. Et le plus souvent le choix est pour de mauvaises raisons (rares sont les cas où l'impact de ce lock est important, et encore plus rares sont les cas où l'impact est importante ET on ne peut pas créer l'objet explicitement dans le main).Citation:
Envoyé par Flob90
@white_tentacle: T'aurais un bench ? j'ai toujours entendue dire que locker un mutex était lent. (C'est d'ailleurs ce qui est dit dans MC++D, mais ca ne m'étonnerait pas que ca ai changé).
@Astraya: Non, on parle d'allocation dynamique (pour le singleton ou les variable statique), ca exclu de profiter du RAII. D'autre part, la fermeture d'un fichier fait partie des opérations qui peuvent lancer une excpetion, mieux vaut la traiter avant que de laisser le destructeur s'en charger.
Un auto_ptr -> RAII + pointeurCitation:
Non, on parle d'allocation dynamique (pour le singleton ou les variable statique), ca exclu de profiter du RAII. D'autre part, la fermeture d'un fichier fait partie des opérations qui peuvent lancer une excpetion, mieux vaut la traiter avant que de laisser le destructeur s'en charger.
RAII + fstream -> auto_file. On peut gérer les exceptions avec ce genre de choses.
On parle de singleton et de variable statique, et à ma connaisance ca ne se fait pas avec des sytème "intelligent".Citation:
Envoyé par Astraya
Si tu appels pas close explicitement et que tu laisse ta classe RAII-sante fermer le fichier, alors non tu ne pourras pas triater les excpetions, tu devras laisser le destructeur le faire.
C'est le but d'un RAII. Tout ce qui nécessite une symétrie. Fichier, BDD, DLL... Dans le standard, la fermeture lève une exception interne qui apparait si il n'y a rien d'ouvert, donc dans tout les cas rien ne sera resté vacant.Citation:
Si tu appels pas close explicitement et que tu laisse ta classe RAII-sante fermer le fichier
Il marche ... mais pas partout :). (et il est effectivement plus léger qu'un mutex)Citation:
Envoyé par white_tentacle