Affecter un pointeur à NULL en C++03

Hello,

Voici un code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <stdlib.h>   class Page { };   Page page; Page* nextPage = &page;   int test() { if (nextPage != NULL) { nextPage = NULL; }   return 0; }

---

Je teste sous Windows avec un MinGW récent, ça compile nickel.

Je cross-compile avec une toolchain GCC pour MCU Renesas, basée sur une version GCC 4.8 je crois, et j'obtiens l'erreur suivante sur l'affectation de nextPage à NULL :

invalid conversion from 'void*' to '_Page*' [-fpermissive]

Pouvez-vous me confirmer que le problème viendrait de la toolchain (et/ou de sa configuration) et non de mon code ?

Normalement, tout le monde compile en C++98 ou 03.

Merci d'avance !
Bktero


PS : j'ai réussi à faire compiler le code avec un reinterpret_cast<Page*>(NULL) au fait.

Bonjour,

NULL doit valoir 0 en C++, surtout pas la valeur utilisé en C qui est (void*)0.
Le #include <stdlib.h> est un include du langage C, c'est lui qui doit mettre la mauvaise valeur dans NULL.
Il faut utiliser #include <cstblib> en C++, qui lui devrait avoir la bonne valeur pour NULL.

Bonjour,

Pour compléter ce que dit dalfab :

• En C, NULL est une constante qui vaut 0 et qui est castée ou pas en (void*).
• En C++03, NULL est une constante entière qui vaut 0.
• En C++11, NULL est soit une constante entière qui vaut 0, soit nullptr.

Sources :
• http://en.cppreference.com/w/c/types/NULL
• http://en.cppreference.com/w/cpp/types/NULL

J'ai reproduit le problème avec MinGW en commentant l'inclusion stdlib et en définissant moi-même NULL à 0, avec sous sans cast. Le problème doit bien venir de là. Je vais enquêter sur la configuration de la toolchain de cross-compilation.

Les en-têtes <cstd***> ne sont-elles pas apparues avec C++11 ?

Les entêtes du C <****.h> qui sont compatibles C++ s'utilisent sous le nom <c****>, avec quelques adaptations de compatibilité et les fonctions ****() deviennent std::****().
C'était là avant C++11, je pense dès C++98.

J'ai l'impression que ton compilateur est un peu étrange. Je n'ai jamais eu de problème de ce genre.
Si c'est un souci de compilateur comme je le pense, perso j'opterais pour simplement ignorer ce warning sur ce compilateur (voire cette version du compilateur) avec ifdef et pragma adéquats.

Citation:

---

j'ai réussi à faire compiler le code avec un reinterpret_cast<Page*>(NULL) au fait.

---

Oui mais tu ne veux pas vraiment utiliser cette écriture bien lourde à chaque fois, non ? :aie:
A défaut, une fonction template ou macro qui le fait pour toi sinon.

Citation:

---

Envoyé par dalfab

Les entêtes du C <****.h> qui sont compatibles C++ s'utilisent sous le nom <c****>, avec quelques adaptations de compatibilité et les fonctions ****() deviennent std::****().
C'était là avant C++11, je pense dès C++98.

---

En cherchant sur internet, notamment grâce cette discussion stackoverflow, j'ai compris que :

• à l'exception de cstdint, les autres en-têtes existent depuis C++98
• dans les en-têtes <c***>, les éléments sont définis dans le namespace std, alors que dans <std***.h>, ils sont dans le namespace global.
• il est possible que les en-têtes <c****> définissent aussi les mêmes éléments dans le namespace global (optionnel, en plus du namespace std qui est obligatoire)

Citation:

---

Envoyé par Bousk

J'ai l'impression que ton compilateur est un peu étrange. Je n'ai jamais eu de problème de ce genre.
Si c'est un souci de compilateur comme je le pense, perso j'opterais pour simplement ignorer ce warning sur ce compilateur (voire cette version du compilateur) avec ifdef et pragma adéquats.

---

Le seul moyen de contourner -fpermissive est d'utiliser des #pragmas, il ne semble pas y avoir de -fno-permissive. Vu que le code incriminé est dans une bibliothèque, utilisées sur plusieurs compilateurs, ça m'arrange pas de le polluer.

Citation:

---

Envoyé par Bousk

Oui mais tu ne veux pas vraiment utiliser cette écriture bien lourde à chaque fois, non ? :aie:
A défaut, une fonction template ou macro qui le fait pour toi sinon.

---

Tu m'as pris pour qui ?! :mouarf: Bien sûr que je ne veux pas faire ça !!! :ptdr:
Pour la raison "bibliothèque" évoquée plus haut, je n'ai pas non plus envie de rajouter des templates ou des macros (j'avais d'ailleurs fait une macro avec ce reinterpret_cast ;))



Au final, mon collègue a trouvé une solution : il a changé la lib C utilisée. Il est passé de "optimized" à "newlib" dans les options de l'IDE.

Merci pour votre aide :ccool:

Point plus intéressant, depuis au moins C++03, les entêtes <bidule.h> sont dépréciés, et ne doivent pas être utilisés.
Il me semble même que gcc (dans certaines de ses versions au moins) émêt un warning dédié (de même qu'avec <strstream>)

Code:

---

Point plus intéressant, depuis au moins C++03, les entêtes <bidule.h> sont dépréciés, et ne doivent pas être utilisés.

---

Je vois des choses un peu contradictoires à ce sujet... D'après cette page, http://en.cppreference.com/w/cpp/header, il semble que oui. Pourtant, je vois aussi que <cmath> est apparu en C++17 : http://en.cppreference.com/w/cpp/numeric/math/abs

Ca n'est pas contradictoire, tu n'as pas bien lu :mrgreen:
ce qui est dit, c'est que depuis C++17, les fonctions *abs sont définies dans cmath, en plus de cstdlib.
cmath en lui même existait déjà, mais ne contenait pas ces fonctions-ci.

historiquement, abs était si utilisée qu'on a jugé bon de ne pas obliger les développeurs à inclure math.h pour l'obtenir.

Ah c'est subtil ! Merci pour cette explication de texte !

PS : message n°3333 !