delete d'un pointeur null

Le
Stan
bonjour,

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.

Existe-t-il des implémentations
où cela pose un problème ?

Merci

--
-Stan
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
James Kanze
Le #22647661
On Oct 5, 4:26 pm, Stan
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
Le #22647871
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.
Gabriel Dos Reis
Le #22648901
Stan
| 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...

| Existe-t-il des implémentations
| où cela pose un problème ?

Il y a très longtemps le compilateur C de Sun
avait des problèmes avec free(0), mais je ne me
souviens pas du cas pour delete d'un pointeur
nul était un problème.

-- Gaby
espie
Le #22649041
In article 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.



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
Le #22649241
On 6 oct, 06:42, Gabriel Dos Reis
Stan
| 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...

http://cjoint.com/?0kgjWUgGFJ7
http://cjoint.com/?0kgjXUF8KvU

Mauvaise pioche ;-)


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
Le #22649361
On Oct 6, 7:58 am, (Marc Espie) wrote:
In article
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.

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
Gabriel Dos Reis
Le #22649471
Stan
[...]

| Concernant le delete, j'ai fait la remarque
| à 5 dévevoppeurs appartenant à deux équipes distincte s.
| 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.

Au fil des années, j'ai observé qu'un programmeur détermin é
est rarement troublé par la logique et les faits.

| 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 le ur
| montrer qu'ils se trompaient...
|
| http://cjoint.com/?0kgjWUgGFJ7
| http://cjoint.com/?0kgjXUF8KvU
|
| Mauvaise pioche ;-)

J'ose espérer que son utilisation en tant que
combustible de chauffage (pour l'hiver qui s'annonce)
ne se revelera pas toxique.

-- Gaby
Marc
Le #22651441
Marc Espie wrote:

In article 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.



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
Le #22651721
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
Le #22651711
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++.
Publicité
Poster une réponse
Anonyme