Retour new sur pointeur alloué à nul

[MicBeastKiller]

Bonjour à tous,

suite à des recherches sur cette question, je ne trouve pas de réponse pertinente. Voici déjà le code d'exemple:

Code :

1
2
3
4
5
 
...
ClasseA * ptA( 0 );
ptA = new ClasseA();
...

dans le cas où il y ait une mauvaise allocation avec l'opérateur "new", problème d'espace mémoire étant je pense le plus courant,"ptA" vaudra-t-il toujours 0 ?

Merci beaucoup pour vos réponses.

[Neckara]

Bonjour,

A ce que je sache, new lancera une exception en cas d'erreur lors de l'allocation mémoire.
Il existe toute fois un moyen pour forcer new à renvoyer NULL en cas d'erreur :

Code :

Type *ptr = new(std::nothrow) Type;

[Aleph69]

Salut,

l'entrée de la faq Peut-on lever des exceptions dans les constructeurs? correspond me semble-t-il à ce que tu cherches.

[MicBeastKiller]

Merci beaucoup pour vos réponses, mais cela n'indique pas si la valeur de ptA sera encore 0 si il y a eu un problème ; ceci dû au fait qu'elle est initialisée à 0.
En parallèle, je vais regarder (m'instruire ) sur le fonctionnement de l'opérateur new.

[cob59]

http://en.cppreference.com/w/cpp/mem...w/operator_new

3-4) Same as 1-2, but returns a null pointer when 1-2 would throw std::bad_alloc

Donc avec std::nothrow, le new renverra un nullptr (C++11) ou un NULL (C++03), c'est à dire 0.

[Aleph69]

Jette un oeil à Que se passe-t-il si aucun bloc catch n'existe pour traiter une exception?
Si new lance une exception et que tu ne la récupères pas, tu vas sortir de ta fonction en détruisant tous les objets locaux, en l'occurence ptA, et ta question n'a donc pas vraiment de sens.
Si tu préfères, la valeur de ptA ne sera pas modifiée mais sera détruite.

[MicBeastKiller]

Merci beaucoup,

j'écris donc

Code :

1
2
3
4
5
 
...
ClasseA * ptA( 0 );
ptA = new( std::nothrow ) ClasseA();
...

et en cas d'erreur d'allocation après le new, ptA vaudra l'adresse 0.

Merci

[Aleph69]

Oui, mais il faut bien noter la subtilité : en cas de problème d'allocation, new renverra le pointeur nul quelle que soit la valeur préalable de ptA. Ce n'est pas le fait d'avoir initialisé ptA à zéro qui provoque ce comportement. Autrement dit, ptA est bien modifié dans ce cas.

[MicBeastKiller]

Envoyé par Aleph69

Oui, mais il faut bien noter la subtilité : en cas de problème d'allocation, new renverra le pointeur nul quelle que soit la valeur préalable de ptA. Ce n'est pas le fait d'avoir initialisé ptA à zéro qui provoque ce comportement. Autrement dit, ptA est bien modifié dans ce cas.

C'est en l'occurrence ce que je veux (pour le moment).
Je reprends du code et il y a à tout bout de champ ce type de chose :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
 
...
ClasseA * ptA( 0 );
ptA = new ClasseA();
if( !ptA )
    printError();
else
{
    /* utilisation de ptA */
    ...
}
...

je souhaite m'assurer que la vérification du "if" est pertinente.
Merci beaucoup

[Aleph69]

Envoyé par MicBeastKiller

je souhaite m'assurer que la vérification du "if" est pertinente.

En l'occurence, elle ne l'est pas du tout.

[MicBeastKiller]

Envoyé par Aleph69

En l'occurence, elle ne l'est pas du tout.

C'est bien ce que je pensais.
Et donc cette vérification est pertinente :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
...
ClasseA * ptA( 0 );
ptA = new( std::nothrow ) ClasseA();
if( !ptA )
    printError();
else
{
    ...
}
...

[Aleph69]

Oui, à ceci près que cela ne sert plus à rien d'initialiser ptA à zéro. Dans l'exemple précédent, cela avait du sens car si new levait une exception, alors ptA pouvait être détruit car préalablement initialisé. Ce qui n'avait pas de sens, c'était le test succédant à new.

[leternel]

une autre verification serait

Code :

1
2
3
4
5
6
7
8
9
...
#include <stdexcept>
...
try {
ClasseA * ptA = new ClasseA();
    ...
} catch (const std::bad_alloc& e){
    printError();
}

à une vache près pour le nom de l'exception

[MicBeastKiller]

Envoyé par Aleph69

Oui, à ceci près que cela ne sert plus à rien d'initialiser ptA à zéro. Dans l'exemple précédent, cela avait du sens car si new levait une exception, alors ptA pouvait être détruit car préalablement initialisé. Ce qui n'avait pas de sens, c'était le test succédant à new.

J'ai un peu du mal à suivre.
Dans le premier cas, le fait d'initialiser ptA à 0 permet de garder cette valeur 0 si il y a échec de new ?

[leternel]

Si j'ai bien compris, avec truc = new (std::nothrow) Truc();, tu as l'équivalent (à la portée de truc près) de

Code :

1
2
3
4
5
try {
    truc = new Truc();
} catch (...) {
    truc = std::nullptr;//ou NULL ou 0 ou ... selon la norme et le compilateur
}

Donc, quel que soit la valeur précédente de truc, elle est remplacée.

En tant que telle, truc = new (std::nothrow) Truc(); est une affectation qui réussit systématiquement.

tu n'imagine pas de faire int i = 0; i = f();… le 0 serait inutile.

[Bousk]

Envoyé par leternel

tu n'imagine pas de faire int i = 0; i = f();… le 0 serait inutile.

Inutile si f() retourne 0 en cas d'exception attrapé en interne

[MicBeastKiller]

Envoyé par leternel

Si j'ai bien compris, avec truc = new (std::nothrow) Truc();, tu as l'équivalent (à la portée de truc près) de

Code :

Donc, quel que soit la valeur précédente de truc, elle est remplacée.

En tant que telle, truc = new (std::nothrow) Truc(); est une affectation qui réussit systématiquement.

tu n'imagine pas de faire int i = 0; i = f();… le 0 serait inutile.

Sauf si la méthode de programmation imposée est :
- toute variable déclarée doit être initialisée avant d'être utilisée.
- tout pointeur déclaré doit être initialisé à 0 avant d'être utilisé.
- l'opérateur new doit être utilisé sur un pointeur préalablement initialisé à 0.
- à la suite de l'opérateur delete sur un pointeur, ce pointeur doit être mis à 0.
- etc.

J'ai par contre toujours cette question en suspend :

Code :

1
2
3
4
5
 
...
ClasseA * ptA( 0 );
ptA = new ClasseA();
...

à la sortie de ce code et si l'allocation a échoué, ptA vaut-il 0 ou autre chose ?

Merci encore à tous .

[Emmanuel Deloget]

Envoyé par MicBeastKiller

Sauf si la méthode de programmation imposée est :
- toute variable déclarée doit être initialisée avant d'être utilisée.
- tout pointeur déclaré doit être initialisé à 0 avant d'être utilisé.
- l'opérateur new doit être utilisé sur un pointeur préalablement initialisé à 0.
- à la suite de l'opérateur delete sur un pointeur, ce pointeur doit être mis à 0.
- etc.

Indépendamment de la méthode de programmation utilisée, le fait de mettre le pointeur à NULL avant l'appel à new() peut être utile dans le cas où tu tu t'attends à des bugs de l'espace. C'est pire si tu compte réinitialiser un pointeur à NULL après le delete.

De manière générale, en C++ le test de la valeur d'un pointeur (enfin, le test == NULL) est souvent signe que le programmeur a fait quelque chose qu'il ne devait pas faire. Dans ce langage, il existe tant de manière de s'assurer qu'un pointeur n'est pas NULL avant de l'utiliser que le test est soit superflu, soit signe d'un manque de compréhension du code ou d'une architecture bancale (comme, par exemple, une mauvaise analyse de la durée de vie d'un objet).

Il faut se rappeler qu'un pointeur appartient à quelqu'un, et ce quelqu'un a une durée de vie. Si l'objet alloué n'a pas la même durée de vie que son propriétaire, alors c'est que ce n'est pas le bon propriétaire.

Envoyé par MicBeastKiller

J'ai par contre toujours cette question en suspend :

Code :

à la sortie de ce code et si l'allocation a échoué, ptA vaut-il 0 ou autre chose ?

Merci encore à tous .

ptA == 0 - logique, puisque si new échoue (et lance une exception) alors l'opérateur = n'est pas évalué, donc ptA garde sa valeur originelle.

[Flob90]

La version classique de new lance une exception si il y a un problème (allocation ou construction), si elle n'est pas du tout attrapé, alors le programme termine.

Si l'ensemble déclaration de la variable, appel à new et affectation à la variable est dans un bloc try avec un catch qui attrape cette exception, alors la question ne se pose pas, en cas d'exception une fois attrapée cette variable n'existe plus.

Code :

1
2
3
4
5
6
7
8
9
 
try{
//...
A* p(0);
//...
p = new A(/*param*/);
//...
} catch(/*exceptions*/)
{ /*...*/ }

Si l'ensemble appel à new et l’affectation à la variable est dans dans le try (qui attrape les exceptions concernées), alors l'ordre entre construction et affectation n'étant pas définie, on ne peut rien dire de la valeur de la variable après le bloc catch.

Code :

1
2
3
4
5
6
7
8
9
10
 
A* p(0);
//...
try{
//...
p = new A(/*param*/);
//...
) catch(/*exceptions*/)
{ /*...*/ }
//ici on ne peut rien dire de p.

NB: Dans ce cas ce sont les exceptions provenant des constructeurs qui posent problèmes, si ils ne peuvent lancer, alors la valeur de p sera non nulle.


On peut tricher un peu en utilisant une variable intermédiaire pour "forcer" l'ordre entre la construction et l'affectation à la variable :

Code :

1
2
3
4
5
6
7
8
9
10
 
A* p(0);
//...
try{
//...
A* q = new A(/*param*/);
p = q;
//...
) catch(/*exceptions*/)
{ /*...*/ }

Sans prendre en compte les éventuels optimisations des compilateurs, à la sortie de ce code on a bien p qui vaut 0 ou est associé à l'objet alloué et construit avant.
Malheureusement, il est fort probable que le compilateur optimise un tel code (ie il considère que la variable q ne sert à rien).

NB: Ces morceaux de code n'ont de sens qu'avec les règles de programmation qui te sont imposées, ils ne servent à rien dans un contexte normal (les exceptions font leur boulot).

[MicBeastKiller]

Envoyé par Emmanuel Deloget

C'est pire si tu compte réinitialiser un pointeur à NULL après le delete.

Pourquoi ?

Envoyé par Emmanuel Deloget

De manière générale, en C++ le test de la valeur d'un pointeur (enfin, le test == NULL) est souvent signe que le programmeur a fait quelque chose qu'il ne devait pas faire. Dans ce langage, il existe tant de manière de s'assurer qu'un pointeur n'est pas NULL avant de l'utiliser que le test est soit superflu, soit signe d'un manque de compréhension du code ou d'une architecture bancale (comme, par exemple, une mauvaise analyse de la durée de vie d'un objet).

Il faut se rappeler qu'un pointeur appartient à quelqu'un, et ce quelqu'un a une durée de vie. Si l'objet alloué n'a pas la même durée de vie que son propriétaire, alors c'est que ce n'est pas le bon propriétaire.

Bien justement et hormis les exceptions, comment vérifier la bonne allocation ?

Envoyé par Emmanuel Deloget

ptA == 0 - logique, puisque si new échoue (et lance une exception) alors l'opérateur = n'est pas évalué, donc ptA garde sa valeur originelle.

Cela répond donc à ma question. Merci beaucoup.

Envoyé par Flob90

La version classique de new lance une exception si il y a un problème (allocation ou construction), si elle n'est pas du tout attrapé, alors le programme termine.

Si l'ensemble déclaration de la variable, appel à new et affectation à la variable est dans un bloc try avec un catch qui attrape cette exception, alors la question ne se pose pas, en cas d'exception une fois attrapée cette variable n'existe plus.

Code :

Si l'ensemble appel à new et l’affectation à la variable est dans dans le try (qui attrape les exceptions concernées), alors l'ordre entre construction et affectation n'étant pas définie, on ne peut rien dire de la valeur de la variable après le bloc catch.

Code :

NB: Dans ce cas ce sont les exceptions provenant des constructeurs qui posent problèmes, si ils ne peuvent lancer, alors la valeur de p sera non nulle.


On peut tricher un peu en utilisant une variable intermédiaire pour "forcer" l'ordre entre la construction et l'affectation à la variable :

Code :

Sans prendre en compte les éventuels optimisations des compilateurs, à la sortie de ce code on a bien p qui vaut 0 ou est associé à l'objet alloué et construit avant.
Malheureusement, il est fort probable que le compilateur optimise un tel code (ie il considère que la variable q ne sert à rien).

NB: Ces morceaux de code n'ont de sens qu'avec les règles de programmation qui te sont imposées, ils ne servent à rien dans un contexte normal (les exceptions font leur boulot).

Je vais donc étudier les exceptions et mettre cela en place.

Merci à tous.