Y a-t-il des cas o=F9 le delete sur un
pointeur null peut provoquer une erreur
=E0 l'execution ?
La norme l'autorise, et pourtant, je vois
souvent des programmes o=F9 l'on teste
s'il est null avant le delete.
Existe-t-il des impl=E9mentations
o=F9 cela pose un probl=E8me ?
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ?
S'il y a une erreur dans l'implémentation. Autrement non. (Et je ne connais pas d'implémentation avec de telles erreurs aujourd'hui.)
La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
Je vois souvent des programmes par des gens qui ne connaissent pas bien le langage. Dans ce cas-ci, il y a des chances qu'ils ont copié plus ou moins des plus anciens, qui ont copié des plus anciens aussi, jusqu'à arriver aux premiers jours de C, quand il n'y avait pas de norme, et que chaque implémentation faisait à peu près ce qu'elle voulait.
Existe-t-il des implémentations où cela pose un problème ?
Pas aujourd'hui. Pas depuis vingt ans, au moins.
-- James Kanze
On Oct 5, 4:26 pm, Stan <t...@neuf.fr> wrote:
Y a-t-il des cas où le delete sur un
pointeur null peut provoquer une erreur
à l'execution ?
S'il y a une erreur dans l'implémentation. Autrement non. (Et je
ne connais pas d'implémentation avec de telles erreurs
aujourd'hui.)
La norme l'autorise, et pourtant, je vois
souvent des programmes où l'on teste
s'il est null avant le delete.
Je vois souvent des programmes par des gens qui ne connaissent
pas bien le langage. Dans ce cas-ci, il y a des chances qu'ils
ont copié plus ou moins des plus anciens, qui ont copié des plus
anciens aussi, jusqu'à arriver aux premiers jours de C, quand il
n'y avait pas de norme, et que chaque implémentation faisait
à peu près ce qu'elle voulait.
Existe-t-il des implémentations
où cela pose un problème ?
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ?
S'il y a une erreur dans l'implémentation. Autrement non. (Et je ne connais pas d'implémentation avec de telles erreurs aujourd'hui.)
La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
Je vois souvent des programmes par des gens qui ne connaissent pas bien le langage. Dans ce cas-ci, il y a des chances qu'ils ont copié plus ou moins des plus anciens, qui ont copié des plus anciens aussi, jusqu'à arriver aux premiers jours de C, quand il n'y avait pas de norme, et que chaque implémentation faisait à peu près ce qu'elle voulait.
Existe-t-il des implémentations où cela pose un problème ?
Pas aujourd'hui. Pas depuis vingt ans, au moins.
-- James Kanze
Marc
Stan wrote:
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ? La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Stan wrote:
Y a-t-il des cas où le delete sur un
pointeur null peut provoquer une erreur
à l'execution ?
La norme l'autorise, et pourtant, je vois
souvent des programmes où l'on teste
s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand
l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ? La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Gabriel Dos Reis
Stan writes:
| bonjour, | | Y a-t-il des cas où le delete sur un | pointeur null peut provoquer une erreur | à l'execution ?
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ? La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'appel de fonction ? ont-il seulement verifie le gain "eventuel" en performance ? Sachant que ca ne coute pas si cher sur les machines modernes. Par contre, le fait de rajouter un test et donc d'avoir moins de code en cache a des chances d'avoir un effet negatif tres net...
In article <i8fo35$127$1@news-rocq.inria.fr>,
Marc <marc.glisse@gmail.com> wrote:
Stan wrote:
Y a-t-il des cas où le delete sur un
pointeur null peut provoquer une erreur
à l'execution ?
La norme l'autorise, et pourtant, je vois
souvent des programmes où l'on teste
s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand
l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'appel
de fonction ? ont-il seulement verifie le gain "eventuel" en performance ?
Sachant que ca ne coute pas si cher sur les machines modernes. Par contre,
le fait de rajouter un test et donc d'avoir moins de code en cache a des
chances d'avoir un effet negatif tres net...
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ? La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'appel de fonction ? ont-il seulement verifie le gain "eventuel" en performance ? Sachant que ca ne coute pas si cher sur les machines modernes. Par contre, le fait de rajouter un test et donc d'avoir moins de code en cache a des chances d'avoir un effet negatif tres net...
Stan
On 6 oct, 06:42, Gabriel Dos Reis wrote:
Stan writes:
| bonjour, | | Y a-t-il des cas où le delete sur un | pointeur null peut provoquer une erreur | à l'execution ?
Pas dans un compilateur de cette décennie. (La bibliothèque C de Sun était réputé pour des chose bizarres avec free(0), mais je crois qu'ils ont corrigé depuis.)
| La norme l'autorise, et pourtant, je vois | souvent des programmes où l'on teste | s'il est null avant le delete.
Bah, tu sais les programmeurs écrivent beaucoup de choses, y compris insister qu'une instruction de retour doit s'écrire comme un appel de fonction...
Concernant le delete, j'ai fait la remarque à 5 dévevoppeurs appartenant à deux équipes distinctes. Certains m'ont objecté un éventuel problème de portabilité ( ironiquement, le produit n'est pas fait pour être porté, ni sur un autre OS, ni avec un autre compilo); n'ayant pas la science infuse, je me renseigne.
Mais le plus drôle dans l'histoire, c'est que j'ai vu un livre sur leur étagère, donc j'avais pour idée de leur montrer qu'ils se trompaient...
Ce qui m'agace le plus, c'est de passer pour un pinailleur, mais comme disait Courteline ( je crois ) :
"Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet"
PS: merci également aux autres pour leur réponses
-- -Stan
On 6 oct, 06:42, Gabriel Dos Reis <g...@cse.tamu.edu> wrote:
Stan <t...@neuf.fr> writes:
| bonjour,
|
| Y a-t-il des cas où le delete sur un
| pointeur null peut provoquer une erreur
| à l'execution ?
Pas dans un compilateur de cette décennie.
(La bibliothèque C de Sun était réputé pour
des chose bizarres avec free(0), mais je crois
qu'ils ont corrigé depuis.)
| La norme l'autorise, et pourtant, je vois
| souvent des programmes où l'on teste
| s'il est null avant le delete.
Bah, tu sais les programmeurs écrivent beaucoup
de choses, y compris insister qu'une instruction
de retour doit s'écrire comme un appel de fonction...
Concernant le delete, j'ai fait la remarque
à 5 dévevoppeurs appartenant à deux équipes distinctes.
Certains m'ont objecté un éventuel problème
de portabilité ( ironiquement, le produit n'est pas fait pour être
porté,
ni sur un autre OS, ni avec un autre compilo);
n'ayant pas la science infuse, je me renseigne.
Mais le plus drôle dans l'histoire, c'est que j'ai
vu un livre sur leur étagère, donc j'avais pour idée de leur
montrer qu'ils se trompaient...
| bonjour, | | Y a-t-il des cas où le delete sur un | pointeur null peut provoquer une erreur | à l'execution ?
Pas dans un compilateur de cette décennie. (La bibliothèque C de Sun était réputé pour des chose bizarres avec free(0), mais je crois qu'ils ont corrigé depuis.)
| La norme l'autorise, et pourtant, je vois | souvent des programmes où l'on teste | s'il est null avant le delete.
Bah, tu sais les programmeurs écrivent beaucoup de choses, y compris insister qu'une instruction de retour doit s'écrire comme un appel de fonction...
Concernant le delete, j'ai fait la remarque à 5 dévevoppeurs appartenant à deux équipes distinctes. Certains m'ont objecté un éventuel problème de portabilité ( ironiquement, le produit n'est pas fait pour être porté, ni sur un autre OS, ni avec un autre compilo); n'ayant pas la science infuse, je me renseigne.
Mais le plus drôle dans l'histoire, c'est que j'ai vu un livre sur leur étagère, donc j'avais pour idée de leur montrer qu'ils se trompaient...
Ce qui m'agace le plus, c'est de passer pour un pinailleur, mais comme disait Courteline ( je crois ) :
"Passer pour un idiot aux yeux d'un imbécile est une volupté de fin gourmet"
PS: merci également aux autres pour leur réponses
-- -Stan
James Kanze
On Oct 6, 7:58 am, (Marc Espie) wrote:
In article <i8fo35$,
Marc wrote: >Stan wrote:
>> Y a-t-il des cas où le delete sur un >> pointeur null peut provoquer une erreur >> à l'execution ? >> La norme l'autorise, et pourtant, je vois >> souvent des programmes où l'on teste >> s'il est null avant le delete.
>J'ai à l'occasion vu ça justifié par des raisons de >performance, quand l'argument du delete est souvent 0, mais >c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'app el de fonction ? ont-il seulement verifie le gain "eventuel" en performance ? Sachant que ca ne coute pas si cher sur les machines modernes.
Ça ne coûte pas cher sur les machines modernes, mais beaucoup d'entre nous doivent faire fonctionner nos programmes sur l'architecture Intel, qui est loin de ce qu'on peut appeler « moderne » -- la manque des régistres rend un appel assez coûteux. (Il y a aussi l'architecture PA de HP, où un saut indirect, y compris le retour d'une fonction, purgeait systèmatiquement le pipeline.)
(N'empèche que je suis d'accord avec toi pour le fond. Si la différence en temps est mesurable, c'est qu'on se sert beaucoup trop de la mémoire dynamique, et la solution pour améliorer les performances, c'est de moins s'en servir, non d'optimiser l'appel à delete.)
Par contre, le fait de rajouter un test et donc d'avoir moins de code en cache a des chances d'avoir un effet negatif tres net...
Ça dépend de l'architecture. Sur un Sparc, certainement -- l'appel d'une fonction est extrèmement bon marché. Sur un HP PA, c'est prèsque sûr qu'on gagne en évitant l'appel, malgré l'if. Sur un Intel, il faudrait mesurer, mais je soupçonne un léger gain avec l'if.
Mais comme je dis : si la différence est mesurable sur le programme complet, c'est qu'il y a d'autres problèmes, et d'autres mesures qui apporteront beaucoup plus.
-- James Kanze
On Oct 6, 7:58 am, es...@lain.home (Marc Espie) wrote:
In article <i8fo35$12...@news-rocq.inria.fr>,
Marc <marc.gli...@gmail.com> wrote:
>Stan wrote:
>> Y a-t-il des cas où le delete sur un
>> pointeur null peut provoquer une erreur
>> à l'execution ?
>> La norme l'autorise, et pourtant, je vois
>> souvent des programmes où l'on teste
>> s'il est null avant le delete.
>J'ai à l'occasion vu ça justifié par des raisons de
>performance, quand l'argument du delete est souvent 0, mais
>c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'app el
de fonction ? ont-il seulement verifie le gain "eventuel" en performance ?
Sachant que ca ne coute pas si cher sur les machines modernes.
Ça ne coûte pas cher sur les machines modernes, mais beaucoup
d'entre nous doivent faire fonctionner nos programmes sur
l'architecture Intel, qui est loin de ce qu'on peut appeler
« moderne » -- la manque des régistres rend un appel assez
coûteux. (Il y a aussi l'architecture PA de HP, où un saut
indirect, y compris le retour d'une fonction, purgeait
systèmatiquement le pipeline.)
(N'empèche que je suis d'accord avec toi pour le fond. Si la
différence en temps est mesurable, c'est qu'on se sert beaucoup
trop de la mémoire dynamique, et la solution pour améliorer les
performances, c'est de moins s'en servir, non d'optimiser
l'appel à delete.)
Par contre, le fait de rajouter un test et donc d'avoir moins
de code en cache a des chances d'avoir un effet negatif tres
net...
Ça dépend de l'architecture. Sur un Sparc, certainement --
l'appel d'une fonction est extrèmement bon marché. Sur un HP PA,
c'est prèsque sûr qu'on gagne en évitant l'appel, malgré l'if.
Sur un Intel, il faudrait mesurer, mais je soupçonne un léger
gain avec l'if.
Mais comme je dis : si la différence est mesurable sur le
programme complet, c'est qu'il y a d'autres problèmes, et
d'autres mesures qui apporteront beaucoup plus.
>> Y a-t-il des cas où le delete sur un >> pointeur null peut provoquer une erreur >> à l'execution ? >> La norme l'autorise, et pourtant, je vois >> souvent des programmes où l'on teste >> s'il est null avant le delete.
>J'ai à l'occasion vu ça justifié par des raisons de >performance, quand l'argument du delete est souvent 0, mais >c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'app el de fonction ? ont-il seulement verifie le gain "eventuel" en performance ? Sachant que ca ne coute pas si cher sur les machines modernes.
Ça ne coûte pas cher sur les machines modernes, mais beaucoup d'entre nous doivent faire fonctionner nos programmes sur l'architecture Intel, qui est loin de ce qu'on peut appeler « moderne » -- la manque des régistres rend un appel assez coûteux. (Il y a aussi l'architecture PA de HP, où un saut indirect, y compris le retour d'une fonction, purgeait systèmatiquement le pipeline.)
(N'empèche que je suis d'accord avec toi pour le fond. Si la différence en temps est mesurable, c'est qu'on se sert beaucoup trop de la mémoire dynamique, et la solution pour améliorer les performances, c'est de moins s'en servir, non d'optimiser l'appel à delete.)
Par contre, le fait de rajouter un test et donc d'avoir moins de code en cache a des chances d'avoir un effet negatif tres net...
Ça dépend de l'architecture. Sur un Sparc, certainement -- l'appel d'une fonction est extrèmement bon marché. Sur un HP PA, c'est prèsque sûr qu'on gagne en évitant l'appel, malgré l'if. Sur un Intel, il faudrait mesurer, mais je soupçonne un léger gain avec l'if.
Mais comme je dis : si la différence est mesurable sur le programme complet, c'est qu'il y a d'autres problèmes, et d'autres mesures qui apporteront beaucoup plus.
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ? La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'appel de fonction ? ont-il seulement verifie le gain "eventuel" en performance ?
Oui et oui.
Sachant que ca ne coute pas si cher sur les machines modernes. Par contre, le fait de rajouter un test et donc d'avoir moins de code en cache a des chances d'avoir un effet negatif tres net...
Sans vouloir me répéter : « c'est plutôt exceptionnel ».
Marc Espie wrote:
In article <i8fo35$127$1@news-rocq.inria.fr>,
Marc <marc.glisse@gmail.com> wrote:
Stan wrote:
Y a-t-il des cas où le delete sur un
pointeur null peut provoquer une erreur
à l'execution ?
La norme l'autorise, et pourtant, je vois
souvent des programmes où l'on teste
s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand
l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'appel
de fonction ? ont-il seulement verifie le gain "eventuel" en performance ?
Oui et oui.
Sachant que ca ne coute pas si cher sur les machines modernes. Par contre,
le fait de rajouter un test et donc d'avoir moins de code en cache a des
chances d'avoir un effet negatif tres net...
Sans vouloir me répéter : « c'est plutôt exceptionnel ».
Y a-t-il des cas où le delete sur un pointeur null peut provoquer une erreur à l'execution ? La norme l'autorise, et pourtant, je vois souvent des programmes où l'on teste s'il est null avant le delete.
J'ai à l'occasion vu ça justifié par des raisons de performance, quand l'argument du delete est souvent 0, mais c'est plutôt exceptionnel.
Laisse-moi deviner, par des gens qui disent qu'il vaut mieux eviter l'appel de fonction ? ont-il seulement verifie le gain "eventuel" en performance ?
Oui et oui.
Sachant que ca ne coute pas si cher sur les machines modernes. Par contre, le fait de rajouter un test et donc d'avoir moins de code en cache a des chances d'avoir un effet negatif tres net...
Sans vouloir me répéter : « c'est plutôt exceptionnel ».
Fabien LE LEZ
On Wed, 6 Oct 2010 01:08:19 -0700 (PDT), James Kanze :
doivent faire fonctionner nos programmes sur l'architecture Intel, qui est loin de ce qu'on peut appeler « moderne » -- la manque des régistres rend un appel assez coûteux.
Heureusement qu'elle est peu à peu remplacée par l'architecture AMD.
On Wed, 6 Oct 2010 01:08:19 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:
doivent faire fonctionner nos programmes sur
l'architecture Intel, qui est loin de ce qu'on peut appeler
« moderne » -- la manque des régistres rend un appel assez
coûteux.
Heureusement qu'elle est peu à peu remplacée par l'architecture AMD.
On Wed, 6 Oct 2010 01:08:19 -0700 (PDT), James Kanze :
doivent faire fonctionner nos programmes sur l'architecture Intel, qui est loin de ce qu'on peut appeler « moderne » -- la manque des régistres rend un appel assez coûteux.
Heureusement qu'elle est peu à peu remplacée par l'architecture AMD.
Fabien LE LEZ
On Wed, 6 Oct 2010 01:01:55 -0700 (PDT), Stan :
http://cjoint.com/?0kgjXUF8KvU
Mauvaise pioche ;-)
Le pire, c'est que le bouquin est assez récent (moins de 15 ans sans doute), puisqu'on y parle de la page web de l'éditeur :-/
Mébon, j'ai l'impression que la majorité des gens qui écrivent des bouquins sur le C++, n'ont pas les bases en C++.
On Wed, 6 Oct 2010 01:01:55 -0700 (PDT), Stan <tmp@neuf.fr>:
http://cjoint.com/?0kgjXUF8KvU
Mauvaise pioche ;-)
Le pire, c'est que le bouquin est assez récent (moins de 15 ans sans
doute), puisqu'on y parle de la page web de l'éditeur :-/
Mébon, j'ai l'impression que la majorité des gens qui écrivent des
bouquins sur le C++, n'ont pas les bases en C++.
