IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

Avis - Pointeurs intelligents


Sujet :

Java

  1. #1
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2006
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Février 2006
    Messages : 70
    Points : 218
    Points
    218
    Par défaut Avis - Pointeurs intelligents
    Bonjour à tous,

    Commençons par enfoncer les portes ouvertes : la JVM et le par extention le garbage collector, s'occupant pour nous de la gestion de la mémoire, on ne devrait pas avoir besoin de gréer de "pointeurs".
    Mais faute est de constater que je suis souvent rencontré au même problème, dès lors qu'il s'agit de partager des objets de "ressources" entre d'autres objets, de manière intelligente. C'est à dire qu'il s'agit plus de maîtriser l'ouverture et la fermeture de ressource partagée, que de gérer la mémoire à proprement parler.

    Je vais prendre pour exemple, le typique cas du fichier ouvert. Imaginons que plusieurs objets aient besoin d'accéder au contenu d'un fichier, mais par un unique FileInputStream (merci de passer outre la stupidité de la chose ).

    Nous avons donc un objet A qui va ouvrir un fichier. Puis un objet B va venir récupérer le même flux à son tour. Si A est détruit, on ne souhaite pas fermer le fichier, car B l'utilise toujours. De même, si B n'est plus utilisé, il faut s'assurer qu'aucun autre objet ne l'utilise avant de fermer finalement le fichier.

    La difficulté est donc de maintenir un compteur, pour savoir combien de fois l'objet est utiliser.
    Jusqu'à présent, j'utilisait une classe de "Manager", auprès duquel mes objets venaient récupérer la ressource, et incrémenter le compteur. De même, quand il n'en ont plus besoin, ils appellent la méthode release() du manager, qui décrémente le compteur. Arrivé à 0, celui-ci ferme la ressource.

    Seulement voilà, créer un Manager pour chaque ressource est fastidieux, et amène de la maintenance inutile, et crée des dépendances entre plus de classes que nécessaire.

    Un point aussi sur les objets WeakReference. Ceux ci ne me semblent pas tellement adapté à ce genre de situation. En effetn, le but ici n'est pas de permettre ou non la suppression d'un objet utilisé par un autre, mais de récupérer un événement au moment où l'objet n'est plus utilisé.

    J'ai donc imaginé une classe "SharedReference" gérant cette problématique. Celle-ci étant finalement très simple, je n'ai pas pris la peine de la commenterdans le code qui va suivre. Cette classe simule l'encapsulation d'une référence. En réalité, elle contient une classe interne (qui contiendra la référence de la ressource et le compteur), dont l'instance sera partagée avec tous les SharedReference voulant utiliser la même ressource.

    L'objectif final est de gérer de manière plus simple le cycle de vie des objets, et de limiter les risques de "fuites mémoire" dues à des objets restant indéfiniment dans des collections, car on a oublié d'appeler la méthode pour retirer l'objet. Ce qui arrive plus fréquement qu'on ne le croit.

    Pour son fonctionnement, la classe prend un callback, qui sera appelé lors de la "destruction" de la ressource (au moment où le compteur arrive à 0). Pour être véritablement réactif, il reste important d'appeler directement la méthode release() de SharedReference quand on n'a plus besoin de al ressource. Toutefois, le garbage collector peut s'en charger par la méthode finalize() en cas d'oubli !

    Je vous demanderais également de ne pas considérer les problèmes de tread-safety ici, ni même le fait que le "destructeur" (du code "client") soit appelé par le thread du garbadge collector. Il ne s'agit pas de la véritable implémentation que je souhaite utiliser, mais plus du principe global.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    public class SharedReference<T> {
     
        private static final class HardReference<T> {
     
    	private T ref;
     
    	private int count = 0;
     
    	private final Consumer<T> destructor;
     
    	public HardReference(T ref, final Consumer<T> destructor) {
    	    this.ref = ref;
    	    this.destructor = destructor;
    	}
     
    	public void acquire() {
    	    ++count;
    	}
     
    	public void release() {
    	    count--;
    	    if (count == 0) {		
    		destructor.accept(ref);
    		ref = null;
    	    }
    	}
     
    	public T get() {
    	    if( count > 0) {
    		return ref;
    	    }
    	    return null;
    	}
     
        }
     
        private final HardReference<T> ref;
     
        private boolean alive = true;
     
        public SharedReference(T val, final Consumer<T> destructor) {
    	ref = new HardReference<>(val, destructor);
    	ref.acquire();
        }
     
        public SharedReference(SharedReference<T> sharedRef) {
    	ref = sharedRef.ref;
    	ref.acquire();
        }
     
        protected void finalize() throws Throwable {
    	try {
    	    this.release();
    	} finally {
    	    super.finalize();
    	}
        }
     
        public void release() {
    	if (alive) {
    	    alive = false;
    	    ref.release();
    	}
        }
     
        public int count() {
    	return this.ref.count;
        }
     
        public T get() {
    	if (alive) {
    	    return this.ref.get();
    	}
    	return null;
        }
     
    }
    Exemple d'utilisation :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    63
    public static void main(String args[]) {
    	test1();
    	test2();
        }
     
        public static void test1() {
     
    	System.out.println("--- test1 ---");
     
    	SharedReference<String> ref1 = new SharedReference<>("test", (r) -> {
    	    System.out.println("destroy " + r);
    	});
     
    	System.out.println(ref1.count()); 	// affiche 1
    	System.out.println(ref1.get());   	// affiche "test"
     
    	SharedReference<String> ref2 = new SharedReference<>(ref1);
     
    	System.out.println(ref2.count()); 	// affiche 2
    	System.out.println(ref2.get());   	// affiche "test"
     
    	ref1.release();
     
    	System.out.println(ref2.count()); 	// affiche 1
     
    	ref2.release(); 			// affiche "destroy test"
     
    	System.out.println(ref2.count()); 	// affiche 0
    	System.out.println(ref2.get());   	// affiche "null"
     
        }
     
        public static void test2() {
     
    	System.out.println("--- test2 ---");
     
    	SharedReference<String> ref = test2inner();
     
    	System.out.println(ref.count());	// affiche toujours 2
     
    	System.gc(); 				// le garbage collector finit par passer
     
    	try {
    	    Thread.sleep(100L);
    	} catch (InterruptedException e) {
    	}
     
    	System.out.println(ref.count());	// affiche 1
    	System.out.println(ref.get()); 		// affiche "test"
     
    	ref.release();				// affiche "destroy test" 
     
        }
     
        public static SharedReference<String> test2inner() {
     
    	SharedReference<String> ref = new SharedReference<>("test", (r) -> {
    	    System.out.println("destroy " + r);
    	});
     
    	// Oubli volontaire d'appeler ref.release() !
    	return new SharedReference<>(ref);
        }
    Vos avis ? Qu'en pensez vous ?

    Je posterais la version réelle, thread-safe, quand je l'aurais terminée si cela vous intéresse.
    On peut également imaginer d'autres outils utilisant cette classe; comme par exemple des collections se vidant automatiquement.

  2. #2
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Salut,



    A mon avis c'est un peu une usine à gaz dont je ne comprend pas trop l'intérêt (comme tu dis pourquoi partager un FileInputStream ?)
    Il est préférable de réduire au maximum la durée de vie des ressources, pour s'assurer le moins de risque d'erreur.

    Dans ton cas tu semble privilégier l'inverse (et stocker ces ressources dans des collections !).
    En plus cela nous empêcherait d'utiliser le try-with-ressource pour libérer proprement la ressource...


    A moins que tu n'ai un cas plus concret d'utilisation...


    a++

  3. #3
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 551
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 551
    Points : 21 607
    Points
    21 607
    Par défaut
    Bah qu'une ressource soit partagée (pas un FileInputStream mais autre chose,) ça se tient.

    Mais qu'il faille absolument pouvoir détruire l'objet qui l'a ouverte avant que tout le monde ait fini de s'en servir, ça me paraît déjà bien plus douteux. Je vois pas l'intérêt.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  4. #4
    Modérateur
    Avatar de kolodz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2008
    Messages
    2 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 211
    Points : 8 316
    Points
    8 316
    Billets dans le blog
    52
    Par défaut
    Déjà vue a de nombreuse reprise cette implémentation, mais uniquement pour des programmes en C++.
    Le principe sous-jacente reste principalement le principe du listener. Pour ce qui est de la gestion de la mort d'un objet. Il me semble plus logique d'utiliser un processus plus naturel. le finaly des blocs try ou même en dernier recours la méthode "finalize()".

    Cordialement,
    Patrick Kolodziejczyk.

    Source :
    http://howtodoinjava.com/2012/10/31/...ethod-in-java/
    http://docs.oracle.com/javase/tutori...s/finally.html
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

  5. #5
    Modérateur

    Profil pro
    Inscrit en
    Septembre 2004
    Messages
    12 551
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2004
    Messages : 12 551
    Points : 21 607
    Points
    21 607
    Par défaut
    Euh, non, la méthode finalize() ne peut être qu'un pis-aller. Il faut toujours prévoir un "vrai" système de libération de ressource qui est censé marcher en toute circonstance.
    Et si on veut mettre un finalize() pour le cas où on se soit planté avec le vrai système, pourquoi pas.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #6
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2006
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Février 2006
    Messages : 70
    Points : 218
    Points
    218
    Par défaut
    Merci de vos réponses

    Effectivement, ma problématique de gestion de ressources est "un poil" plus complexe que celle de la gestion d'un fichier.

    Peut être aurais-je du commencer par là. Alors allons-y.

    La problématique s'inscrit dans le cadre d'un développement de serveur "bas niveau" (gestion directe des sockets avec NIO) "temps réel" (en temps relatif).
    Lorsque l'on souhaite modifier des états de variables sur le serveurs, il faut que ces modifications soient répercutées le plus rapidement possible sur le client concerné.

    Ainsi, on crée une "requête", qui va contenir les informations à envoyer, qui sera rattaché à l'instance représentant le client. Ces requêtes sont enregistrées dans une stack.
    Une fois le packet associé à la requête envoyée, il y a plusieurs cas de figure à prendre en compte :
    - le client a renvoyé sa réponse, et indique que les modifications sont bien prises en comptes
    - le client n'a rien renvoyé (coupure réseau, autres...) un timeout doit être déclenché pour indiquer une erreur sur la requète.

    La logique veut qu'on ajoute un listener (avec des méthodes de type onSuccess(), onError() etc...) à la requète, pour gérer les différentes "fin" de requète.

    Ajouté à cela qu'une requête unique peut nécessiter de générer plusieurs packets, et que chacun de ces packet doit être validé par un code de retour spécifique, afin de valider la requête, on obtient des stack dans des stacks...
    Vraiment top... mais c'est ainsi

    Évidement, tout ceci se déroule dans un contexte mutli-thread. Ce qui implique que certains objets soient partagés, et d'autres locaux aux thread. En particulier pour les pool de thread gérant les timeout, les lecture, les écritures. Il arrive donc fréquemment pour ces derniers, qu'une instance de la représentation d'une requête soit détenus par plusieurs threads en même temps.

    Il suffit qu'un seul développeur ai oublié de retirer, dans un seul des listeners, la requête / réponse de requête, à la stack associée, et c'est la fuite mémoire !!


    Effectivement, la réalisation est tirée du C++. L'idée, c'est d'avoir "ceinture et bretelles". On va tout faire pour relire les milliers de lignes de codes à la recherche d'oublis de remove(), mais utiliser le garbadge collector peut nous aider :
    1) A éviter l'instabilité du serveur
    2) A détecter, par des logs, quels types de requêtes, et à quel moment de son cycle de vie, l'oublie a été fait.


    Voici l'implémentation "finale". Car pour être véritablement utile, il faut encore développer les wrapper de collections afin de supprimer leur contenu lors de la destruction d'une ressource. C'est quand même le seul intérêt de "l'usine à gaz" :p

    L'implémentation est évidement thread-safe, et utilise des algorithmes non bloquant.
    De plus, le "destructeur" (qui n'est rien d'autre qu'un listener en fin de compte) n'est jamais appelé directement par le garbadge collector, afin de minimiser les perte de performance.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    221
    222
    223
    224
    225
    226
    227
    228
    229
    230
    231
    232
    233
    234
    235
    236
    237
    238
    239
    240
    241
    242
    243
    244
    245
    246
    247
    248
    249
    250
    251
    252
    253
    254
    255
    256
    257
    258
    259
    260
    261
    262
    263
    264
    265
    266
    267
    268
    269
    270
    271
    272
    273
    274
    275
    276
    277
    278
    279
    280
    281
    282
    283
    284
    285
    286
    287
    288
    289
    290
    291
    292
    293
    294
    295
    296
    297
    298
    299
    300
    301
     
    public final class SharedReference<T> {
     
        @SuppressWarnings("rawtypes")
        private static final Consumer DO_NOTHING = res -> {};
     
        /**
         * Couple destructeur / ressource
         *
         * @param <T>
         */
        private static class DestructorRef<T> {
    	public final T ref;
    	public final Consumer<T> destructor;
     
    	public DestructorRef(T ref, Consumer<T> destructor) {
    	    super();
    	    this.ref = ref;
    	    this.destructor = destructor;
    	}
     
        }
     
        /**
         * Variable locale au thread servant à savoir si on est dans le thread du
         * finalize ou non
         */
        private static final ThreadLocal<Boolean> FINALISER_HANDLER = new ThreadLocal<Boolean>() {
     
    	public Boolean initialValue() {
    	    return false;
    	}
     
        };
     
        /**
         * File de destructeur a appeler
         */
        private static final BlockingQueue<DestructorRef<?>> PENDING = new LinkedBlockingQueue<>();
     
        /**
         * Thread qui appèle les destructeurs. Son but est d'éviter de laisser le
         * garbade collector appeler du code client
         * 
         * @author Sébastien
         *
         */
        private static class ReferenceHandler extends Thread {
     
    	private ReferenceHandler(String name) {
    	    super(name);
    	}
     
    	@Override
    	@SuppressWarnings({ "rawtypes", "unchecked" })
    	public void run() {
    	    do {
     
    		try {
    		    DestructorRef destructorRef = PENDING.take();
    		    destructorRef.destructor.accept(destructorRef.ref);
    		} catch (InterruptedException e) {
    		    Thread.currentThread().interrupt();
    		}
     
    	    } while (!Thread.currentThread().isInterrupted());
    	}
     
        }
     
        /**
         * Initialisation du thread des destructeurs
         */
        static {
     
    	Thread handler = new ReferenceHandler("Reference Handler");
     
    	handler.setPriority(Thread.MAX_PRIORITY);
    	handler.setDaemon(true);
    	handler.start();
        }
     
        /**
         * Wrapper de la référence de l'objet ressource. L'instance gère également
         * le compteur
         * 
         * @param <T>
         */
        private static final class HardReference<T> {
     
    	private final AtomicReference<T> ref;
     
    	private final AtomicInteger count;
     
    	private final Consumer<T> destructor;
     
    	public HardReference(T ref, final Consumer<T> destructor) {
    	    if (ref == null) {
    		throw new NullPointerException();
    	    }
    	    if (destructor == null) {
    		throw new NullPointerException();
    	    }
    	    this.ref = new AtomicReference<>(ref);
    	    this.count = new AtomicInteger(1);
    	    this.destructor = destructor;
    	}
     
    	/**
             * Méthode thread safe non bloquante. Incrémente le compteur de
             * ressource si celle-ci n'est pas déjà détruite.
             */
    	public void acquire() {
    	    do {
    		T localRef = this.ref.get();
    		int localCount = this.count.get();
     
    		if (localRef == null || localCount == 0) {
    		    throw new NullPointerException("Resource is null");
    		}
     
    		if (this.count.compareAndSet(localCount, localCount + 1)) {
    		    return;
    		}
     
    	    } while (true);
     
    	}
     
    	/**
             * Méthode thread safe non bloquante. Décrémente le compteur de
             * ressource si celle-ci n'est pas déjà détruite. Le thread qui atteind
             * 0 demande l'appel du destructeur.
             * 
             * Si le thread courant est celui du garbadge collector, l'appel est
             * réalisé par thread prévu. Autrement, l'appel se fait directement.
             */
    	public void release() {
     
    	    do {
    		T localRef = this.ref.get();
    		int localCount = this.count.get();
    		int newValue = localCount - 1;
     
    		if (localCount == 0 || localRef == null) {
    		    return;
    		}
     
    		if (this.count.compareAndSet(localCount, newValue)) {
    		    if (newValue == 0) {
    			if (this.ref.compareAndSet(localRef, null)) {
    			    if (FINALISER_HANDLER.get()) {
    				PENDING.add(new DestructorRef<T>(localRef, destructor));
    			    } else {
    				destructor.accept(localRef);
    			    }
    			    FINALISER_HANDLER.remove();
    			}
    		    }
    		    return;
    		}
     
    	    } while (true);
     
    	}
     
    	/**
             * Retourne l'instance de la ressource uniquement si le compteur n'est
             * pas à 0
             * 
             * @return
             */
    	public T get() {
    	    if (count.get() > 0) {
    		return ref.get();
    	    }
    	    return null;
    	}
     
        }
     
        private final HardReference<T> ref;
     
        /**
         * Permet de savoir si la référence paratagée a été relachée, ou pas.
         */
        private final AtomicBoolean alive;
     
        @SuppressWarnings("unchecked")
        public SharedReference(T val) {
    	this(val, DO_NOTHING);
        }
     
        public SharedReference(T val, final Consumer<T> destructor) {
    	if (val == null) {
    	    throw new NullPointerException();
    	}
    	if (destructor == null) {
    	    throw new NullPointerException();
    	}
    	this.ref = new HardReference<>(val, destructor);
    	this.alive = new AtomicBoolean(true);
        }
     
        public SharedReference(SharedReference<T> sharedRef) {
    	if (sharedRef == null) {
    	    throw new NullPointerException();
    	}
    	ref = sharedRef.ref;
    	ref.acquire();
    	this.alive = new AtomicBoolean(true);
        }
     
        /**
         * Appelé par le garbadge collector
         */
        protected void finalize() throws Throwable {
    	try {
    	    FINALISER_HANDLER.set(true);
    	    this.release();
    	} finally {
    	    super.finalize();
    	    FINALISER_HANDLER.remove();
    	}
        }
     
        /**
         * Doit être appelé dès que la ressource n'est plus utilisée. Une fois
         * appelé, la ressource n'est plus accessible par cet objet.
         */
        public void release() {
     
    	do {
    	    if (!this.alive.get()) {
    		return;
    	    }
     
    	    if (this.alive.compareAndSet(true, false)) {
    		ref.release();
    		return;
    	    }
     
    	} while (true);
     
        }
     
        /**
         * Retourne le nombre d'utilisation actuelle de la ressource
         * 
         * @return
         */
        public int count() {
    	return this.ref.count.get();
        }
     
        /**
         * Retourne l'instance uniquement si release() n'a pas déjà été appelé avant
         * 
         * @return
         */
        public T get() {
    	if (this.alive.get()) {
    	    return this.ref.get();
    	}
    	return null;
        }
     
        /**
         * Référence faible vers la ressource
         * 
         * @param <T>
         */
        public static class WeakReference<T> {
     
    	private final HardReference<T> ref;
     
    	public WeakReference(final HardReference<T> ref) {
    	    this.ref = ref;
    	}
     
    	public WeakReference(final SharedReference<T> ref) {
    	    this.ref = ref.ref;
    	}
     
    	public int count() {
    	    return this.ref.count.get();
    	}
     
    	/**
             * Retourne la ressource uniquement si cette dernière n'a pas été
             * relaché par l'ensemble des SharedReference
             * 
             * @return
             */
    	public T get() {
    	    return this.ref.get();
    	}
     
        }
     
    }

Discussions similaires

  1. Réponses: 12
    Dernier message: 24/06/2012, 11h20
  2. delete [] et pointeur intelligent
    Par zenux dans le forum C++
    Réponses: 11
    Dernier message: 04/12/2006, 09h18
  3. Les pointeurs intelligents
    Par MatRem dans le forum C++
    Réponses: 8
    Dernier message: 20/06/2006, 19h27
  4. pointeur intelligent??
    Par yashiro dans le forum C++
    Réponses: 3
    Dernier message: 04/04/2006, 08h08
  5. Pointeur intelligent boost : return NULL ->comment faire?
    Par choinul dans le forum Bibliothèques
    Réponses: 7
    Dernier message: 21/12/2005, 16h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo