> C'est très différent. Je ne suis pas contre les variables dynamiques, je suis contre les GC censés savoir mieux que le developpeur QUAND il faut libérer la mémoire.
Mais pourtant tu acceptes qu'une librairie décide pour toi de l'endroit en mémoire où seront tes données, et qu'elle prenne plus de place qu'il n'en faut réellement (malloc() alloue toujours plus que ce que tu lui demande).
> Apparement, tu as besoin d'un cours sur l'optimisation:
Surement, tu as l'air d'être bien plus expérimenté que moi, alors je te fais confiance.
> 1er cas: le developpeur (aidé des outils automatiques qu'il veut)
Quels outils ? T'as un nom, une url ?
> trouve QUAND libérer les ressources et place l'appel a la fonction free() au bon endroit dans son code.
Juste pour info, là on est en C++ donc c'est delete ou delete[].
Bon, un exemple simple : j'ai une classe Fenetre comme ça :
class Fenetre {
public:
const char* nom() { return _nom; }
protected:
char* _nom; // nom de la fenetre
}
Supposons un objet instance de cette classe, et d'autres objets qui appellent Fenetre::nom() et gardent le résultat. L'objet Fenetre doit-il liberer la mémoire occupée par _nom lorsqu'il est lui-même effacé ? Qu'arrive-t-il alors aux autres objets qui ont gardé une copie du pointeur vers _nom ?
> 1er cas exécuté une seule fois pour toute.
En es-tu si sur ? Dans la question précédente, une possibilité est que chaque objet qui a besoin de _nom garde une copie du string, qu'il devra bien sur libérer par la suite, ce qui augmente d'autant les appels à new[]/delete[]. Alors qu'avec un GC, tant qu'il reste un pointeur vers _nom, il ne sera pas libéré...
> 2ieme cas exécuté en parallèle du traitement à chaque éxécution.
Ah non, un GC en général c'est executé soit sur demande expresse du programmeur, soit de manière "chronique" par le runtime (quand le programme ne fait rien, ou qu'il a besoin de ressources).
> Quand je fait un malloc(), je sais a quel moment je n'aurai plus besoin de l'espace et je fais le free() qui va bien.
Tu as surement raison. Je me doute que tu as du travailler sur plusieurs gros projets de quelques centaines de milliers, voire millions de lignes de code, et qu'a chaque fois il était évident pour toi de savoir où liberer sa mémoire.
[^] # Re: Comment ça marche ?
Posté par Guillaume Laurent . En réponse à la dépêche Al Stevens n'aime pas QT. Évalué à 5.
Mais pourtant tu acceptes qu'une librairie décide pour toi de l'endroit en mémoire où seront tes données, et qu'elle prenne plus de place qu'il n'en faut réellement (malloc() alloue toujours plus que ce que tu lui demande).
> Apparement, tu as besoin d'un cours sur l'optimisation:
Surement, tu as l'air d'être bien plus expérimenté que moi, alors je te fais confiance.
> 1er cas: le developpeur (aidé des outils automatiques qu'il veut)
Quels outils ? T'as un nom, une url ?
> trouve QUAND libérer les ressources et place l'appel a la fonction free() au bon endroit dans son code.
Juste pour info, là on est en C++ donc c'est delete ou delete[].
Bon, un exemple simple : j'ai une classe Fenetre comme ça :
class Fenetre {
public:
const char* nom() { return _nom; }
protected:
char* _nom; // nom de la fenetre
}
Supposons un objet instance de cette classe, et d'autres objets qui appellent Fenetre::nom() et gardent le résultat. L'objet Fenetre doit-il liberer la mémoire occupée par _nom lorsqu'il est lui-même effacé ? Qu'arrive-t-il alors aux autres objets qui ont gardé une copie du pointeur vers _nom ?
> 1er cas exécuté une seule fois pour toute.
En es-tu si sur ? Dans la question précédente, une possibilité est que chaque objet qui a besoin de _nom garde une copie du string, qu'il devra bien sur libérer par la suite, ce qui augmente d'autant les appels à new[]/delete[]. Alors qu'avec un GC, tant qu'il reste un pointeur vers _nom, il ne sera pas libéré...
> 2ieme cas exécuté en parallèle du traitement à chaque éxécution.
Ah non, un GC en général c'est executé soit sur demande expresse du programmeur, soit de manière "chronique" par le runtime (quand le programme ne fait rien, ou qu'il a besoin de ressources).
> Quand je fait un malloc(), je sais a quel moment je n'aurai plus besoin de l'espace et je fais le free() qui va bien.
Tu as surement raison. Je me doute que tu as du travailler sur plusieurs gros projets de quelques centaines de milliers, voire millions de lignes de code, et qu'a chaque fois il était évident pour toi de savoir où liberer sa mémoire.