Discussion :

[Mac LAK]

je n'appelle pas delete a la paluche, jamais; c'est le refptr qui l'appelle. il n'y a pas d'appel au destructeur explicite, ni d'appel a delete; c'est le but meme du refptr, il va "implicitement" appeler le destructeur

Oui, mais "quand", c'est là toute la question quand tu as des objets dont la durée de vie est variable... A un moment ou à un autre, tu vas demander la destruction de l'objet, soit via son container, soit directement.
Or, ça ou un delete, c'est kif-kif...

je ne voulais pas dire "plus de plate formes que tu en aies vu de ta vie" mais juste "plus de plate forme que tu croyais que je connaissais". tu as eu un ton assez condescendant plus haut.

95% des gens ici confondent "portabilité" et "faire un truc qui compile sous Windows et Linux avec trois tonnes de compilation conditionnelle"...
Ceci étant dit, tu ne m'as pas dit si tu utilisais une couche d'abstraction éprouvée (genre ACE) ou pas.

pour le reste, je n'ai pas compris pourquoi tu disais que c'etait inutile d'avoir une DLL. c'est, en quelque sorte, jamais utile; on pourrait tout faire en statique ?

Non, au contraire. Mais le but initial d'une DLL, c'est d'être partagée entre plusieurs processus (y compris et surtout en même temps).
Si ton code n'est jamais utilisé par plus d'un exécutable, ni plus d'un processus, sa présence en DLL n'est pas justifiée. De plus, dans le cas de routines relativement complexes et/ou qu'il ne faut pas recompiler n'importe comment (validation complexe, par exemple), il est alors au contraire primordial de mettre le code dans une DLL.

Mais étant donné que le simple fait d'exposer des classes C++, ou pire, des variables globales va à l'encontre du principe même d'une DLL (qui est de n'exporter QUE des fonctions, et exclusivement des fonctions), la réutilisabilité de la librairie (binaire) et sa portabilité sur d'autres applications / langages en est fortement réduite.

C'est simplement sur ce point que je conteste fortement l'export de classes dans une DLL. Si Microsoft fait le maximum possible pour n'exporter QUE des fonctions en prototype C dans ses librairies, c'est pour une bonne raison, et ce n'est pas "se casser la tête pour rien"...

[screetch]

non non je ne le demande pas; le dernier refptr qui va "out-of-scope" emporte l'objet avec lui dans la mort.

quand ? et bien, quand il n'y a plus de proprietaires... je ne controle pas complétement cela.

je n'utilise pas ACE, ca ne correspond pas a ce que je fais. j'ai une couche d'abstraction maison.

[screetch]

Non, au contraire. Mais le but initial d'une DLL, c'est d'être partagée entre plusieurs processus (y compris et surtout en même temps)

qui ici développe des DLL systemes windows ? honnêtement ?
presque personne n'ecrit des DLL chargées en memoire qui sont partagées par les processus. 99% des gens ont une DLL qui sert uniquement a factoriser du code, mais au chargement d'un processus meme si le code est partagé entre les processus, les données sont toute neuves et differentes pour chaque processus.

Par exemple, si tu charges deux processus qui utilisent Qt, la DLL est chargée deux fois; modifier un objet Qt dans un processus n'est pas propagé jusque l'autre processus.

[Médinoc]

On ne développe pas forcément des DLLs système Windows, mais mêmes les DLLs .Net peuvent être utilisées depuis le C ou le VB6 si elles sont déclarées COM-Visible...

[screetch]

tout a fait, chacun fait ce qu'il lui plait.

[Mac LAK]

non non je ne le demande pas; le dernier refptr qui va "out-of-scope" emporte l'objet avec lui dans la mort.

Mouais, c'est comme ça que j'ai vu des applis grossir indécemment en RAM jusqu'à leur fermeture, parce que la référence n'était en fait jamais détruite réellement...

C'est pour ça que je n'utilise plus ce principe pour ma part dans les "petites" allocations : c'est la porte ouverte non pas au memory leak (car rien n'est "perdu" réellement), mais à la surconsommation de mémoire qui dure jusqu'à la fin de vie de l'application elle-même. Je réserve en général ce principe à des encapsulations d'objets système fonctionnant déjà sur ce principe (ex : handles de mémoire partagée, par exemple).

je n'utilise pas ACE, ca ne correspond pas a ce que je fais. j'ai une couche d'abstraction maison.

Disons que ACE possède une partie de portabilité OS bien pratique (même si mal foutue), qui a l'avantage énorme de supporter un nombre de plate-formes colossal. Cf. le namespace ACE_OS notamment.

qui ici développe des DLL systemes windows ? honnêtement ?

Ben moi, entre autres... Enfin, des DLL qui ont une interface système pour être plus précis. Après, ce sont des DLL spécifiques à mes besoins, bien entendu, mais partagées entre quasiment tous les programmes composant le produit sur lequel je travaille.

presque personne n'ecrit des DLL chargées en memoire qui sont partagées par les processus. 99% des gens ont une DLL qui sert uniquement a factoriser du code, mais au chargement d'un processus meme si le code est partagé entre les processus, les données sont toute neuves et differentes pour chaque processus.

C'est exactement le contraire pour moi : je fais des DLL utilisées par plusieurs processus (entre deux et une dizaine), et qui sert justement à faire le "pont" entre les processus (ou à assurer un vrai singleton au niveau SYSTÈME, et non pas au niveau PROCESSUS).

Par exemple, si tu charges deux processus qui utilisent Qt, la DLL est chargée deux fois; modifier un objet Qt dans un processus n'est pas propagé jusque l'autre processus.

La DLL n'existe qu'une seule fois en RAM : elle est mappée deux fois, c'est très différent. Par contre, les deux "instances" ne communiquent pas entre elles sans volonté explicite du développeur, en effet.

En gros, le segment de code est "unique" en mémoire, mais mappé dans tous les processus qui utilisent la DLL, tandis que le segment de données de la DLL existe en autant d'exemplaires que tu as de processus utilisateurs.

[screetch]

Mouais, c'est comme ça que j'ai vu des applis grossir indécemment en RAM jusqu'à leur fermeture, parce que la référence n'était en fait jamais détruite réellement...

j'ai une appli sans leak mémoire, et un memory tracker de compétition pour tous les autres cas.

[Mac LAK]

j'ai une appli sans leak mémoire, et un memory tracker de compétition pour tous les autres cas.

Attention : un leak, c'est quand il n'est plus POSSIBLE de libérer la mémoire allouée.
Dans le cas d'une mémoire soumise à un compteur de références, la libération reste possible, mais comme tu le dis toi-même, "je ne contrôle pas le moment de la libération"... Et ça, c'est un problème je trouve.

Ce n'est donc pas un leak, mais plutôt une non-libération de mémoire en temps et en heure.

[Médinoc]

Pour moi, avec un compteur de références, tu contrôles le moment de la libération, puisque tu contrôles les références.

C'est avec un GC que tu ne contrôle pas le moment de la libération; c'est avec un GC qu'un objet peut rester en mémoire avec aucune référence jusqu'au prochain ramassage.