Ben, il faut adapter le langage, pour fournir ce qui manque. Voir l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de pointeur "managé" (avec une syntaxe différente du pointeur classique)
Certes, mais au finale, les pointeurs "normaux" continuent à exister en C++, donc on ne peut pas avoir les garanties dont Matthieu parle dans <news:.
Ou alors j'ai raté un épisode ?
On Sat, 09 Jul 2005 15:04:47 +0200, Cyrille <cyrille@frsf.invalid>:
Ben, il faut adapter le langage, pour fournir ce qui manque. Voir
l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de
pointeur "managé" (avec une syntaxe différente du pointeur classique)
Certes, mais au finale, les pointeurs "normaux" continuent à exister
en C++, donc on ne peut pas avoir les garanties dont Matthieu parle
dans <news:vpqll4hox3q.fsf@ecrins.imag.fr>.
Ben, il faut adapter le langage, pour fournir ce qui manque. Voir l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de pointeur "managé" (avec une syntaxe différente du pointeur classique)
Certes, mais au finale, les pointeurs "normaux" continuent à exister en C++, donc on ne peut pas avoir les garanties dont Matthieu parle dans <news:.
Ou alors j'ai raté un épisode ?
Cyrille
On Sat, 09 Jul 2005 15:04:47 +0200, Cyrille :
Ben, il faut adapter le langage, pour fournir ce qui manque. Voir l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de pointeur "managé" (avec une syntaxe différente du pointeur classique)
Certes, mais au finale, les pointeurs "normaux" continuent à exister en C++, donc on ne peut pas avoir les garanties dont Matthieu parle dans <news:.
Ou alors j'ai raté un épisode ?
Ah oui, en effet. Sauf peut-être à ajouter un mode de compilation où en plus les pointeurs classiques seraient interdits... et c'est je crois ce que fait Microsoft (je viens de vérifier la doc), qui a un mode "mixed", un mode "pure" et un mode "verifiable", ce dernier donnant des garanties du même genre.
Dans le mode "verifiable" il y a donc pas mal de restrictions sur le langage, qu'on peut trouver là: http://msdn2.microsoft.com/library/ykbbt679(en-us,vs.80).aspx
C'est sans doute ce genre de restrictions qu'il faudrait ajouter au C++ pour offrir les mêmes garanties. A ce niveau-là, ce n'est presque plus le même langage...
-- "I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
On Sat, 09 Jul 2005 15:04:47 +0200, Cyrille <cyrille@frsf.invalid>:
Ben, il faut adapter le langage, pour fournir ce qui manque. Voir
l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de
pointeur "managé" (avec une syntaxe différente du pointeur classique)
Certes, mais au finale, les pointeurs "normaux" continuent à exister
en C++, donc on ne peut pas avoir les garanties dont Matthieu parle
dans <news:vpqll4hox3q.fsf@ecrins.imag.fr>.
Ou alors j'ai raté un épisode ?
Ah oui, en effet. Sauf peut-être à ajouter un mode de compilation où en
plus les pointeurs classiques seraient interdits... et c'est je crois ce
que fait Microsoft (je viens de vérifier la doc), qui a un mode "mixed",
un mode "pure" et un mode "verifiable", ce dernier donnant des garanties
du même genre.
Dans le mode "verifiable" il y a donc pas mal de restrictions sur le
langage, qu'on peut trouver là:
http://msdn2.microsoft.com/library/ykbbt679(en-us,vs.80).aspx
C'est sans doute ce genre de restrictions qu'il faudrait ajouter au C++
pour offrir les mêmes garanties. A ce niveau-là, ce n'est presque plus
le même langage...
--
"I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
Ben, il faut adapter le langage, pour fournir ce qui manque. Voir l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de pointeur "managé" (avec une syntaxe différente du pointeur classique)
Certes, mais au finale, les pointeurs "normaux" continuent à exister en C++, donc on ne peut pas avoir les garanties dont Matthieu parle dans <news:.
Ou alors j'ai raté un épisode ?
Ah oui, en effet. Sauf peut-être à ajouter un mode de compilation où en plus les pointeurs classiques seraient interdits... et c'est je crois ce que fait Microsoft (je viens de vérifier la doc), qui a un mode "mixed", un mode "pure" et un mode "verifiable", ce dernier donnant des garanties du même genre.
Dans le mode "verifiable" il y a donc pas mal de restrictions sur le langage, qu'on peut trouver là: http://msdn2.microsoft.com/library/ykbbt679(en-us,vs.80).aspx
C'est sans doute ce genre de restrictions qu'il faudrait ajouter au C++ pour offrir les mêmes garanties. A ce niveau-là, ce n'est presque plus le même langage...
-- "I have nothing to declare except war on Austria." ~ Oscar Wilde, 1936
Gabriel Dos Reis
Cyrille writes:
[...]
| Dans le mode "verifiable" il y a donc pas mal de restrictions sur le | langage, qu'on peut trouver là: | http://msdn2.microsoft.com/library/ykbbt679(en-us,vs.80).aspx | | C'est sans doute ce genre de restrictions qu'il faudrait ajouter au | C++ pour offrir les mêmes garanties.
Ah bon ?
| A ce niveau-là, ce n'est presque plus le même langage...
Ceux qui veulent faire du Pascal ou Java ou Haskell savent où les trouver.
-- Gaby
Cyrille <cyrille@frsf.invalid> writes:
[...]
| Dans le mode "verifiable" il y a donc pas mal de restrictions sur le
| langage, qu'on peut trouver là:
| http://msdn2.microsoft.com/library/ykbbt679(en-us,vs.80).aspx
|
| C'est sans doute ce genre de restrictions qu'il faudrait ajouter au
| C++ pour offrir les mêmes garanties.
Ah bon ?
| A ce niveau-là, ce n'est presque plus le même langage...
Ceux qui veulent faire du Pascal ou Java ou Haskell savent où les trouver.
| Dans le mode "verifiable" il y a donc pas mal de restrictions sur le | langage, qu'on peut trouver là: | http://msdn2.microsoft.com/library/ykbbt679(en-us,vs.80).aspx | | C'est sans doute ce genre de restrictions qu'il faudrait ajouter au | C++ pour offrir les mêmes garanties.
Ah bon ?
| A ce niveau-là, ce n'est presque plus le même langage...
Ceux qui veulent faire du Pascal ou Java ou Haskell savent où les trouver.
-- Gaby
James Kanze
Cyrille wrote:
On Fri, 08 Jul 2005 22:34:49 +0200, Matthieu Moy :
Pas seulement. Avec un language qui implémente les tests de débordements de tableaux, pas d'algèbre de pointeur et un garbage collector (et sans doute d'autres conditions que j'oublie)
Mais a priori, même si on lui greffe un GC, tout ça n'est pas envisageable en C++, il me semble ?
Pourquoi pas lire la proposition d'abord, à la place de parler dans la vide ?
Il ne faut pas oublier qu'il existe actuellement des implémentations des GC qui fonctionnent avec C++. Et dont certains se servent.
Ben, il faut adapter le langage, pour fournir ce qui manque. Voir l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de pointeur "managé" (avec une syntaxe différente du pointeur classique) qui permet de référer les objets gérés par le GC et interdit au moins l'algèbre de pointeur (pour le débordement de tableaux, je ne sais pas).
Je n'ai pas encore étudié la proposition actuelle en détail, mais c'est clair qu'il n'est pas question de simplement adopter l'extension de Microsoft (qui s'adresse aussi à d'autres concernes, comme l'interopératabilité avec C#). A priori, je crois que les changements dans le langage doivent être vraiment minime : à la limite, une interdiction de « cacher » des pointeurs. Ensuite, c'est une question de la qualité de l'implémentation. Une implémentation qui ne glane qu'une fois, à exit, serait strictement conforme (de la même façon qu'une implémentation où free() est un no-op est strictement conforme aujourd'hui) ; l'expectation, cependant, serait que l'implémentation puisse utiliser des cellules auxquelles le programme ne peut plus accéder dans des allocations ultérieurs.
(Ce que je viens de présenter, évidemment, représente une solution « minimale ». Il est tout à fait possible qu'on y ajoute des fonctionnalités supplémentaires, comme la finalisation. Mais je crois qu'il y a bien un consensus que rien ne change pour un programme conforme qui marche aujourd'hui. À part peut-être s'il cache des pointeurs.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Cyrille wrote:
On Fri, 08 Jul 2005 22:34:49 +0200, Matthieu Moy
<MatthieuNOSPAM.Moy@imag.fr.invalid>:
Pas seulement. Avec un language qui implémente les tests de
débordements de tableaux, pas d'algèbre de pointeur et un
garbage collector (et sans doute d'autres conditions que
j'oublie)
Mais a priori, même si on lui greffe un GC, tout ça n'est pas
envisageable en C++, il me semble ?
Pourquoi pas lire la proposition d'abord, à la place de parler
dans la vide ?
Il ne faut pas oublier qu'il existe actuellement des
implémentations des GC qui fonctionnent avec C++. Et dont
certains se servent.
Ben, il faut adapter le langage, pour fournir ce qui manque.
Voir l'extension "managed C++" de Microsoft. Ils inventent un
nouveau type de pointeur "managé" (avec une syntaxe différente
du pointeur classique) qui permet de référer les objets gérés
par le GC et interdit au moins l'algèbre de pointeur (pour le
débordement de tableaux, je ne sais pas).
Je n'ai pas encore étudié la proposition actuelle en détail,
mais c'est clair qu'il n'est pas question de simplement adopter
l'extension de Microsoft (qui s'adresse aussi à d'autres
concernes, comme l'interopératabilité avec C#). A priori, je
crois que les changements dans le langage doivent être vraiment
minime : à la limite, une interdiction de « cacher » des
pointeurs. Ensuite, c'est une question de la qualité de
l'implémentation. Une implémentation qui ne glane qu'une fois, à
exit, serait strictement conforme (de la même façon qu'une
implémentation où free() est un no-op est strictement conforme
aujourd'hui) ; l'expectation, cependant, serait que
l'implémentation puisse utiliser des cellules auxquelles le
programme ne peut plus accéder dans des allocations ultérieurs.
(Ce que je viens de présenter, évidemment, représente une
solution « minimale ». Il est tout à fait possible qu'on y
ajoute des fonctionnalités supplémentaires, comme la
finalisation. Mais je crois qu'il y a bien un consensus que rien
ne change pour un programme conforme qui marche aujourd'hui. À
part peut-être s'il cache des pointeurs.)
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
On Fri, 08 Jul 2005 22:34:49 +0200, Matthieu Moy :
Pas seulement. Avec un language qui implémente les tests de débordements de tableaux, pas d'algèbre de pointeur et un garbage collector (et sans doute d'autres conditions que j'oublie)
Mais a priori, même si on lui greffe un GC, tout ça n'est pas envisageable en C++, il me semble ?
Pourquoi pas lire la proposition d'abord, à la place de parler dans la vide ?
Il ne faut pas oublier qu'il existe actuellement des implémentations des GC qui fonctionnent avec C++. Et dont certains se servent.
Ben, il faut adapter le langage, pour fournir ce qui manque. Voir l'extension "managed C++" de Microsoft. Ils inventent un nouveau type de pointeur "managé" (avec une syntaxe différente du pointeur classique) qui permet de référer les objets gérés par le GC et interdit au moins l'algèbre de pointeur (pour le débordement de tableaux, je ne sais pas).
Je n'ai pas encore étudié la proposition actuelle en détail, mais c'est clair qu'il n'est pas question de simplement adopter l'extension de Microsoft (qui s'adresse aussi à d'autres concernes, comme l'interopératabilité avec C#). A priori, je crois que les changements dans le langage doivent être vraiment minime : à la limite, une interdiction de « cacher » des pointeurs. Ensuite, c'est une question de la qualité de l'implémentation. Une implémentation qui ne glane qu'une fois, à exit, serait strictement conforme (de la même façon qu'une implémentation où free() est un no-op est strictement conforme aujourd'hui) ; l'expectation, cependant, serait que l'implémentation puisse utiliser des cellules auxquelles le programme ne peut plus accéder dans des allocations ultérieurs.
(Ce que je viens de présenter, évidemment, représente une solution « minimale ». Il est tout à fait possible qu'on y ajoute des fonctionnalités supplémentaires, comme la finalisation. Mais je crois qu'il y a bien un consensus que rien ne change pour un programme conforme qui marche aujourd'hui. À part peut-être s'il cache des pointeurs.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ
On Sun, 10 Jul 2005 12:56:24 +0200, James Kanze :
Une implémentation qui ne glane qu'une fois, à exit, serait strictement conforme
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
On Sun, 10 Jul 2005 12:56:24 +0200, James Kanze <kanze@none>:
Une implémentation qui ne glane qu'une fois, à
exit, serait strictement conforme
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC,
puisque quand le programme se termine, l'OS désalloue toute la
mémoire.
Une implémentation qui ne glane qu'une fois, à exit, serait strictement conforme
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
Jean-Baptiste Nivoit
JBB wrote:
Si on utilise des shared_ptr systematiquent chaque fois qu'on fait des new, c'est un peu comme si on avait un GC non? ca fait des smart pointers implementes au dessus d'un objet a comptage
de references, ca y ressemble mais ca cesse de marcher bien des que tu as des cycles de references...
jb
JBB wrote:
Si on utilise des shared_ptr systematiquent chaque fois qu'on fait des
new, c'est un peu comme si on avait un GC non?
ca fait des smart pointers implementes au dessus d'un objet a comptage
de references, ca y ressemble mais ca cesse de marcher bien des que tu
as des cycles de references...
Si on utilise des shared_ptr systematiquent chaque fois qu'on fait des new, c'est un peu comme si on avait un GC non? ca fait des smart pointers implementes au dessus d'un objet a comptage
de references, ca y ressemble mais ca cesse de marcher bien des que tu as des cycles de references...
jb
Jean-Baptiste Nivoit
Anthony Fleury wrote:
Et alors ? parce que c'est disponible dans d'autres langages on devrait l'ajouter dans C++ ? Je ne sais pas si c'est l'avis des autres programmeurs C++ ou si la majorité est contre moi, mais pour ma part je ne veux pas d'un GC dans C++. Quand j'ai une variable en C++, je sais qu'elle sera détruite à la fin du bloc si c'est une variable automatique, à la fin du programme si c'est une static, et quand je vais faire un delete pour une variable allouée dynamiquement. le probleme n'est a mon avis pas tellement pour les objets dont la
portee est connue limitee par un bloc, mais pour les objets qui ont un cycle de vie complexe. Ceci dit le GC ne garantit que ces objets sont gardes en vie au cas ou en aurait besoin (donc pas de dangling pointer), mais ca introduit une nouvelle classe de problemes (des fuites cachees comme en java des qu'on oublie de relacher une reference).
jb.
Anthony Fleury wrote:
Et alors ? parce que c'est disponible dans d'autres langages on devrait
l'ajouter dans C++ ? Je ne sais pas si c'est l'avis des autres
programmeurs C++ ou si la majorité est contre moi, mais pour ma part je
ne veux pas d'un GC dans C++. Quand j'ai une variable en C++, je sais
qu'elle sera détruite à la fin du bloc si c'est une variable
automatique, à la fin du programme si c'est une static, et quand je vais
faire un delete pour une variable allouée dynamiquement.
le probleme n'est a mon avis pas tellement pour les objets dont la
portee est connue limitee par un bloc, mais pour les objets qui ont un
cycle de vie complexe. Ceci dit le GC ne garantit que ces objets sont
gardes en vie au cas ou en aurait besoin (donc pas de dangling pointer),
mais ca introduit une nouvelle classe de problemes (des fuites cachees
comme en java des qu'on oublie de relacher une reference).
Et alors ? parce que c'est disponible dans d'autres langages on devrait l'ajouter dans C++ ? Je ne sais pas si c'est l'avis des autres programmeurs C++ ou si la majorité est contre moi, mais pour ma part je ne veux pas d'un GC dans C++. Quand j'ai une variable en C++, je sais qu'elle sera détruite à la fin du bloc si c'est une variable automatique, à la fin du programme si c'est une static, et quand je vais faire un delete pour une variable allouée dynamiquement. le probleme n'est a mon avis pas tellement pour les objets dont la
portee est connue limitee par un bloc, mais pour les objets qui ont un cycle de vie complexe. Ceci dit le GC ne garantit que ces objets sont gardes en vie au cas ou en aurait besoin (donc pas de dangling pointer), mais ca introduit une nouvelle classe de problemes (des fuites cachees comme en java des qu'on oublie de relacher une reference).
jb.
James Kanze
Fabien LE LEZ wrote:
On Sun, 10 Jul 2005 12:56:24 +0200, James Kanze :
Une implémentation qui ne glane qu'une fois, à exit, serait strictement conforme
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
C'est vrai. De la même façon qu'un compilateur où free() est un no-op (et où operator delete() se sert de free()) est conforme aujourd'hui. Je ne crois pas qu'il soit prévu de donner plus de garanties pour le glaneur de cellules qu'il y a pour malloc()/free().
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Sun, 10 Jul 2005 12:56:24 +0200, James Kanze <kanze@none>:
Une implémentation qui ne glane qu'une fois, à exit, serait
strictement conforme
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un
GC, puisque quand le programme se termine, l'OS désalloue
toute la mémoire.
C'est vrai. De la même façon qu'un compilateur où free() est un
no-op (et où operator delete() se sert de free()) est conforme
aujourd'hui. Je ne crois pas qu'il soit prévu de donner plus de
garanties pour le glaneur de cellules qu'il y a pour
malloc()/free().
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Une implémentation qui ne glane qu'une fois, à exit, serait strictement conforme
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
C'est vrai. De la même façon qu'un compilateur où free() est un no-op (et où operator delete() se sert de free()) est conforme aujourd'hui. Je ne crois pas qu'il soit prévu de donner plus de garanties pour le glaneur de cellules qu'il y a pour malloc()/free().
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Matthieu Moy
Fabien LE LEZ writes:
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
Mais il n'appelle pas les destructeurs des objets dans le tas.
-- Matthieu
Fabien LE LEZ <gramster@gramster.com> writes:
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC,
puisque quand le programme se termine, l'OS désalloue toute la
mémoire.
Mais il n'appelle pas les destructeurs des objets dans le tas.
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
Mais il n'appelle pas les destructeurs des objets dans le tas.
-- Matthieu
kanze
Matthieu Moy wrote:
Fabien LE LEZ writes:
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
Mais il n'appelle pas les destructeurs des objets dans le tas.
Et alors. C'est probable qu'un glaneur de cellules n'appelle pas les destructeurs sur les objets qu'il glane. (Il est forte possible qu'on y ajouter les possibilités de faire appeler des fonctions de finalisation, mais ce ne sont pas les destructeurs.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Matthieu Moy wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Dans ce cas, mon compilo est déjà (indirectement) équipé
d'un GC, puisque quand le programme se termine, l'OS
désalloue toute la mémoire.
Mais il n'appelle pas les destructeurs des objets dans le tas.
Et alors. C'est probable qu'un glaneur de cellules n'appelle pas
les destructeurs sur les objets qu'il glane. (Il est forte
possible qu'on y ajouter les possibilités de faire appeler des
fonctions de finalisation, mais ce ne sont pas les
destructeurs.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dans ce cas, mon compilo est déjà (indirectement) équipé d'un GC, puisque quand le programme se termine, l'OS désalloue toute la mémoire.
Mais il n'appelle pas les destructeurs des objets dans le tas.
Et alors. C'est probable qu'un glaneur de cellules n'appelle pas les destructeurs sur les objets qu'il glane. (Il est forte possible qu'on y ajouter les possibilités de faire appeler des fonctions de finalisation, mais ce ne sont pas les destructeurs.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
