Ah, il fallait être plus explicite, ce n'est donc pas un en-tête du compilateur mais d'une bibliothèque graphique à part. Le problème n'est donc pas vraiment du ressort de g++ mais plutôt des distributeurs de glut qui devraient, comme le fait le code que j'ai collé, vérifier que l'on n'est pas en C++ avec un #ifndef __cplusplus avant d'utiliser ce typedef.
Je ne connais pas glut, mais ce « glut.h » est il vraiment fait pour être inclut dans du code C++ ? n'y a-t-il pas un autre fichier .h qui correspondrait à une interface C++ ?
En tout cas, le .h donné ici : http://www.cs.uofs.edu/~mpc3/cmps370/glutsetup.html
n'a pas l'air d'avoir le même problème et doit fonctionné, étant donné qu'il utilise ceci :
# ifndef _WCHAR_T_DEFINED typedef unsigned short wchar_t; # define _WCHAR_T_DEFINED
Il faut donc changer cette mauvaise version de l'en-tête glut.h et ca devrait rouler.
-- Anthony Fleury
pascal wrote:
l'entete est "glut.h"
Ah, il fallait être plus explicite, ce n'est donc pas un en-tête du
compilateur mais d'une bibliothèque graphique à part. Le problème n'est
donc pas vraiment du ressort de g++ mais plutôt des distributeurs de glut
qui devraient, comme le fait le code que j'ai collé, vérifier que l'on
n'est pas en C++ avec un #ifndef __cplusplus avant d'utiliser ce typedef.
Je ne connais pas glut, mais ce « glut.h » est il vraiment fait pour être
inclut dans du code C++ ? n'y a-t-il pas un autre fichier .h qui
correspondrait à une interface C++ ?
En tout cas, le .h donné ici :
http://www.cs.uofs.edu/~mpc3/cmps370/glutsetup.html
n'a pas l'air d'avoir le même problème et doit fonctionné, étant donné qu'il
utilise ceci :
# ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
# define _WCHAR_T_DEFINED
Il faut donc changer cette mauvaise version de l'en-tête glut.h et ca
devrait rouler.
Ah, il fallait être plus explicite, ce n'est donc pas un en-tête du compilateur mais d'une bibliothèque graphique à part. Le problème n'est donc pas vraiment du ressort de g++ mais plutôt des distributeurs de glut qui devraient, comme le fait le code que j'ai collé, vérifier que l'on n'est pas en C++ avec un #ifndef __cplusplus avant d'utiliser ce typedef.
Je ne connais pas glut, mais ce « glut.h » est il vraiment fait pour être inclut dans du code C++ ? n'y a-t-il pas un autre fichier .h qui correspondrait à une interface C++ ?
En tout cas, le .h donné ici : http://www.cs.uofs.edu/~mpc3/cmps370/glutsetup.html
n'a pas l'air d'avoir le même problème et doit fonctionné, étant donné qu'il utilise ceci :
# ifndef _WCHAR_T_DEFINED typedef unsigned short wchar_t; # define _WCHAR_T_DEFINED
Il faut donc changer cette mauvaise version de l'en-tête glut.h et ca devrait rouler.
-- Anthony Fleury
Gabriel Dos Reis
Loïc Joly writes:
| > Loïc Joly writes: | > | > Bonjour, | > | > voila un p'tit problème... | > | > j'ai un un entête de fichier avec : | > | > #ifndef _WCHAR_H_ | > | > typedef unsigned short wchar_t | > | > #define _WCHAR_H_ | > | > et le compilateur (GCC pour ne pas le citer) me sort le message | > | > d'erreur : | > | > redeclaration of C++ built-in type 'wchar_t' | > | > typedef n'est pas comme son nom l'indique,une définition et non une | > | > déclaration? | > | | Je pense que ce code a pour but de contourner une limitation de | > vieux | > | compilateurs qui ne définieraient pas le type standard wchar_t. En | > et tu crois qu'un tel compilateur pourrait faure quelque chose d'un | > code C++ écrit ces dix-quinze dernières année ? | | Au vu de l'extrait de code affiché, qu'est-ce qui te fait croire qu'il | date des 10-15 dernières années ?
Rhaaah ! Je ne dis pas qu'il date de 10-15, mais je pose la question si un tel compilateur pourrait faire quelque chose avec un code écrit ces 10-15 ans.
| De plus, même des compilateurs relativement récents peuvent avoir ce | problème.
Mais l'un n'exclut pas l'autre.
-- Gaby
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| > Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| > | > Bonjour,
| > | > voila un p'tit problème...
| > | > j'ai un un entête de fichier avec :
| > | > #ifndef _WCHAR_H_
| > | > typedef unsigned short wchar_t
| > | > #define _WCHAR_H_
| > | > et le compilateur (GCC pour ne pas le citer) me sort le message
| > | > d'erreur :
| > | > redeclaration of C++ built-in type 'wchar_t'
| > | > typedef n'est pas comme son nom l'indique,une définition et non une
| > | > déclaration?
| > | | Je pense que ce code a pour but de contourner une limitation de
| > vieux
| > | compilateurs qui ne définieraient pas le type standard wchar_t. En
| > et tu crois qu'un tel compilateur pourrait faure quelque chose d'un
| > code C++ écrit ces dix-quinze dernières année ?
|
| Au vu de l'extrait de code affiché, qu'est-ce qui te fait croire qu'il
| date des 10-15 dernières années ?
Rhaaah ! Je ne dis pas qu'il date de 10-15, mais je pose la question
si un tel compilateur pourrait faire quelque chose avec un code écrit
ces 10-15 ans.
| De plus, même des compilateurs relativement récents peuvent avoir ce
| problème.
| > Loïc Joly writes: | > | > Bonjour, | > | > voila un p'tit problème... | > | > j'ai un un entête de fichier avec : | > | > #ifndef _WCHAR_H_ | > | > typedef unsigned short wchar_t | > | > #define _WCHAR_H_ | > | > et le compilateur (GCC pour ne pas le citer) me sort le message | > | > d'erreur : | > | > redeclaration of C++ built-in type 'wchar_t' | > | > typedef n'est pas comme son nom l'indique,une définition et non une | > | > déclaration? | > | | Je pense que ce code a pour but de contourner une limitation de | > vieux | > | compilateurs qui ne définieraient pas le type standard wchar_t. En | > et tu crois qu'un tel compilateur pourrait faure quelque chose d'un | > code C++ écrit ces dix-quinze dernières année ? | | Au vu de l'extrait de code affiché, qu'est-ce qui te fait croire qu'il | date des 10-15 dernières années ?
Rhaaah ! Je ne dis pas qu'il date de 10-15, mais je pose la question si un tel compilateur pourrait faire quelque chose avec un code écrit ces 10-15 ans.
| De plus, même des compilateurs relativement récents peuvent avoir ce | problème.
Mais l'un n'exclut pas l'autre.
-- Gaby
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote: | > Loïc Joly writes: | | | > | > voila un p'tit problème... | > | > j'ai un un entête de fichier avec : | > | > #ifndef _WCHAR_H_ | > | > typedef unsigned short wchar_t | > | > #define _WCHAR_H_ | > | > et le compilateur (GCC pour ne pas le citer) me sort le | > | > message d'erreur : | > | > redeclaration of C++ built-in type 'wchar_t' | > | > typedef n'est pas comme son nom l'indique,une définition et non | une | > | > déclaration? | | > | Je pense que ce code a pour but de contourner une limitation | > | de vieux compilateurs qui ne définieraient pas le type | > | standard wchar_t. En | | > et tu crois qu'un tel compilateur pourrait faure quelque chose | > d'un code C++ écrit ces dix-quinze dernières année ? | | Ça dépend de comment on l'écrit. Si une des exigeances du projet | est de supporter des anciens compilateurs, on peut écrire du | code qui le fait. (S'il faut, on peut même encore écrire du | C:-).) Certains projets essaient de le faire, considère | http://www.mozilla.org/hacking/mozilla-style-guide.html.
oh oui, je connais je machin -- on se demande pourquoi il ne sont pas resté à C K&R.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis wrote:
| > Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
|
|
| > | > voila un p'tit problème...
| > | > j'ai un un entête de fichier avec :
| > | > #ifndef _WCHAR_H_
| > | > typedef unsigned short wchar_t
| > | > #define _WCHAR_H_
| > | > et le compilateur (GCC pour ne pas le citer) me sort le
| > | > message d'erreur :
| > | > redeclaration of C++ built-in type 'wchar_t'
| > | > typedef n'est pas comme son nom l'indique,une définition et non
| une
| > | > déclaration?
|
| > | Je pense que ce code a pour but de contourner une limitation
| > | de vieux compilateurs qui ne définieraient pas le type
| > | standard wchar_t. En
|
| > et tu crois qu'un tel compilateur pourrait faure quelque chose
| > d'un code C++ écrit ces dix-quinze dernières année ?
|
| Ça dépend de comment on l'écrit. Si une des exigeances du projet
| est de supporter des anciens compilateurs, on peut écrire du
| code qui le fait. (S'il faut, on peut même encore écrire du
| C:-).) Certains projets essaient de le faire, considère
| http://www.mozilla.org/hacking/mozilla-style-guide.html.
oh oui, je connais je machin -- on se demande pourquoi il ne sont pas
resté à C K&R.
| Gabriel Dos Reis wrote: | > Loïc Joly writes: | | | > | > voila un p'tit problème... | > | > j'ai un un entête de fichier avec : | > | > #ifndef _WCHAR_H_ | > | > typedef unsigned short wchar_t | > | > #define _WCHAR_H_ | > | > et le compilateur (GCC pour ne pas le citer) me sort le | > | > message d'erreur : | > | > redeclaration of C++ built-in type 'wchar_t' | > | > typedef n'est pas comme son nom l'indique,une définition et non | une | > | > déclaration? | | > | Je pense que ce code a pour but de contourner une limitation | > | de vieux compilateurs qui ne définieraient pas le type | > | standard wchar_t. En | | > et tu crois qu'un tel compilateur pourrait faure quelque chose | > d'un code C++ écrit ces dix-quinze dernières année ? | | Ça dépend de comment on l'écrit. Si une des exigeances du projet | est de supporter des anciens compilateurs, on peut écrire du | code qui le fait. (S'il faut, on peut même encore écrire du | C:-).) Certains projets essaient de le faire, considère | http://www.mozilla.org/hacking/mozilla-style-guide.html.
oh oui, je connais je machin -- on se demande pourquoi il ne sont pas resté à C K&R.
-- Gaby
pascal
pascal wrote:
l'entete est "glut.h"
Ah, il fallait être plus explicite, ce n'est donc pas un en-tête du compilateur mais d'une bibliothèque graphique à part. Le problème n'est donc pas vraiment du ressort de g++ mais plutôt des distributeurs de g lut qui devraient, comme le fait le code que j'ai collé, vérifier que l' on n'est pas en C++ avec un #ifndef __cplusplus avant d'utiliser ce typedef .
Je ne connais pas glut, mais ce « glut.h » est il vraiment fait pour être inclut dans du code C++ ? n'y a-t-il pas un autre fichier .h qui correspondrait à une interface C++ ?
je ne sais pas trop,c'est le package fournit avec devcpp.
je ne savais pas qu'il y avait des versions des bibliothèques en c OU e n c++,je pensais que c'était prévu pour les deux langages.. L'utilité d'un package fournit par l'ide et d'être utilisable de suit e non? Hors ce n'est pas le cas,pas trés bien de la part de devcpp,ce n'est pa s parce que c'est un IDE libre qu'il faut bacler le travail.
En tout cas, le .h donné ici : http://www.cs.uofs.edu/~mpc3/cmps370/glutsetup.html
je vais tester cette version,merçi du lien.
n'a pas l'air d'avoir le même problème et doit fonctionné, étant donné qu'il utilise ceci :
# ifndef _WCHAR_T_DEFINED typedef unsigned short wchar_t; # define _WCHAR_T_DEFINED
en remplacant par ces lignes dont mon entête,cela ne fonctionne non plu s
pas.
Il faut donc changer cette mauvaise version de l'en-tête glut.h et ca devrait rouler.
j'ai opté pour ta première proposition: rajouter #ifndef __cplusplus, est
cela fonctionne. je ne comprends pas trop ce qui ce passe,car je compile bien en *CPP* et non en c. est ce que mon ide ce configure mal?
pascal wrote:
l'entete est "glut.h"
Ah, il fallait être plus explicite, ce n'est donc pas un en-tête du
compilateur mais d'une bibliothèque graphique à part. Le problème n'est
donc pas vraiment du ressort de g++ mais plutôt des distributeurs de g lut
qui devraient, comme le fait le code que j'ai collé, vérifier que l' on
n'est pas en C++ avec un #ifndef __cplusplus avant d'utiliser ce typedef .
Je ne connais pas glut, mais ce « glut.h » est il vraiment fait pour être
inclut dans du code C++ ? n'y a-t-il pas un autre fichier .h qui
correspondrait à une interface C++ ?
je ne sais pas trop,c'est le package fournit avec devcpp.
je ne savais pas qu'il y avait des versions des bibliothèques en c OU e n
c++,je pensais que c'était prévu pour les deux langages..
L'utilité d'un package fournit par l'ide et d'être utilisable de suit e non?
Hors ce n'est pas le cas,pas trés bien de la part de devcpp,ce n'est pa s
parce que c'est un IDE libre qu'il faut bacler le travail.
En tout cas, le .h donné ici :
http://www.cs.uofs.edu/~mpc3/cmps370/glutsetup.html
je vais tester cette version,merçi du lien.
n'a pas l'air d'avoir le même problème et doit fonctionné, étant donné qu'il
utilise ceci :
# ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
# define _WCHAR_T_DEFINED
en remplacant par ces lignes dont mon entête,cela ne fonctionne non plu s
pas.
Il faut donc changer cette mauvaise version de l'en-tête glut.h et ca
devrait rouler.
j'ai opté pour ta première proposition: rajouter #ifndef __cplusplus, est
cela fonctionne.
je ne comprends pas trop ce qui ce passe,car je compile bien en *CPP* et
non en c.
est ce que mon ide ce configure mal?
Ah, il fallait être plus explicite, ce n'est donc pas un en-tête du compilateur mais d'une bibliothèque graphique à part. Le problème n'est donc pas vraiment du ressort de g++ mais plutôt des distributeurs de g lut qui devraient, comme le fait le code que j'ai collé, vérifier que l' on n'est pas en C++ avec un #ifndef __cplusplus avant d'utiliser ce typedef .
Je ne connais pas glut, mais ce « glut.h » est il vraiment fait pour être inclut dans du code C++ ? n'y a-t-il pas un autre fichier .h qui correspondrait à une interface C++ ?
je ne sais pas trop,c'est le package fournit avec devcpp.
je ne savais pas qu'il y avait des versions des bibliothèques en c OU e n c++,je pensais que c'était prévu pour les deux langages.. L'utilité d'un package fournit par l'ide et d'être utilisable de suit e non? Hors ce n'est pas le cas,pas trés bien de la part de devcpp,ce n'est pa s parce que c'est un IDE libre qu'il faut bacler le travail.
En tout cas, le .h donné ici : http://www.cs.uofs.edu/~mpc3/cmps370/glutsetup.html
je vais tester cette version,merçi du lien.
n'a pas l'air d'avoir le même problème et doit fonctionné, étant donné qu'il utilise ceci :
# ifndef _WCHAR_T_DEFINED typedef unsigned short wchar_t; # define _WCHAR_T_DEFINED
en remplacant par ces lignes dont mon entête,cela ne fonctionne non plu s
pas.
Il faut donc changer cette mauvaise version de l'en-tête glut.h et ca devrait rouler.
j'ai opté pour ta première proposition: rajouter #ifndef __cplusplus, est
cela fonctionne. je ne comprends pas trop ce qui ce passe,car je compile bien en *CPP* et non en c. est ce que mon ide ce configure mal?
kanze
Gabriel Dos Reis wrote:
writes:
| Gabriel Dos Reis wrote: | > Loïc Joly writes:
| > | > voila un p'tit problème... | > | > j'ai un un entête de fichier avec : | > | > #ifndef _WCHAR_H_ | > | > typedef unsigned short wchar_t | > | > #define _WCHAR_H_ | > | > et le compilateur (GCC pour ne pas le citer) me sort le | > | > message d'erreur : | > | > redeclaration of C++ built-in type 'wchar_t' typedef | > | > n'est pas comme son nom l'indique,une définition et | > | > non une déclaration?
| > | Je pense que ce code a pour but de contourner une | > | limitation de vieux compilateurs qui ne définieraient | > | pas le type standard wchar_t. En
| > et tu crois qu'un tel compilateur pourrait faure quelque | > chose d'un code C++ écrit ces dix-quinze dernières année ?
| Ça dépend de comment on l'écrit. Si une des exigeances du | projet est de supporter des anciens compilateurs, on peut | écrire du code qui le fait. (S'il faut, on peut même encore | écrire du C:-).) Certains projets essaient de le faire, | considère | http://www.mozilla.org/hacking/mozilla-style-guide.html.
oh oui, je connais je machin -- on se demande pourquoi il ne sont pas resté à C K&R.
Peut-être parce qu'ils avaient l'habitude en C de declarer une struct, et un ensemble de fonctions qui la manipulent, et puis de se croiser les doigts que personne ne la manipule autrement qu'avec ces fonctions, et que donc, la simple possibilité de déclarer des parties privées représente pour eux une amélioration importante par rapport à C.
On peut avoir beaucoup de raisons pour vouloir faire du C++ plutôt que du C; à mon avis, les parties privées en est une des plus importantes. L'amélioration des vérifications statiques de type, aussi. D'une certaine côté, la reste, c'est du surplus ; c'est bien de l'avoir, mais je me servirais du C++ plutôt que du C même s'il n'était pas là.
Quant aux restrictions qu'on impose pour des raisons de portabilité, chaque projet a besoin d'établir ses propres règles, en fonction des ses besoins de portabilité. Si Mozilla cible des plateformes où les templates ou les exceptions posent un problème, ils ont raison de les exclure ; ce qui en reste, c'est toujours mieux que rien.
-- 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
Gabriel Dos Reis wrote:
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis wrote:
| > Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| > | > voila un p'tit problème...
| > | > j'ai un un entête de fichier avec :
| > | > #ifndef _WCHAR_H_
| > | > typedef unsigned short wchar_t
| > | > #define _WCHAR_H_
| > | > et le compilateur (GCC pour ne pas le citer) me sort le
| > | > message d'erreur :
| > | > redeclaration of C++ built-in type 'wchar_t' typedef
| > | > n'est pas comme son nom l'indique,une définition et
| > | > non une déclaration?
| > | Je pense que ce code a pour but de contourner une
| > | limitation de vieux compilateurs qui ne définieraient
| > | pas le type standard wchar_t. En
| > et tu crois qu'un tel compilateur pourrait faure quelque
| > chose d'un code C++ écrit ces dix-quinze dernières année ?
| Ça dépend de comment on l'écrit. Si une des exigeances du
| projet est de supporter des anciens compilateurs, on peut
| écrire du code qui le fait. (S'il faut, on peut même encore
| écrire du C:-).) Certains projets essaient de le faire,
| considère
| http://www.mozilla.org/hacking/mozilla-style-guide.html.
oh oui, je connais je machin -- on se demande pourquoi il ne
sont pas resté à C K&R.
Peut-être parce qu'ils avaient l'habitude en C de declarer une
struct, et un ensemble de fonctions qui la manipulent, et puis
de se croiser les doigts que personne ne la manipule autrement
qu'avec ces fonctions, et que donc, la simple possibilité de
déclarer des parties privées représente pour eux une
amélioration importante par rapport à C.
On peut avoir beaucoup de raisons pour vouloir faire du C++
plutôt que du C; à mon avis, les parties privées en est une des
plus importantes. L'amélioration des vérifications statiques de
type, aussi. D'une certaine côté, la reste, c'est du surplus ;
c'est bien de l'avoir, mais je me servirais du C++ plutôt que du
C même s'il n'était pas là.
Quant aux restrictions qu'on impose pour des raisons de
portabilité, chaque projet a besoin d'établir ses propres
règles, en fonction des ses besoins de portabilité. Si Mozilla
cible des plateformes où les templates ou les exceptions posent
un problème, ils ont raison de les exclure ; ce qui en reste,
c'est toujours mieux que rien.
--
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
| > | > voila un p'tit problème... | > | > j'ai un un entête de fichier avec : | > | > #ifndef _WCHAR_H_ | > | > typedef unsigned short wchar_t | > | > #define _WCHAR_H_ | > | > et le compilateur (GCC pour ne pas le citer) me sort le | > | > message d'erreur : | > | > redeclaration of C++ built-in type 'wchar_t' typedef | > | > n'est pas comme son nom l'indique,une définition et | > | > non une déclaration?
| > | Je pense que ce code a pour but de contourner une | > | limitation de vieux compilateurs qui ne définieraient | > | pas le type standard wchar_t. En
| > et tu crois qu'un tel compilateur pourrait faure quelque | > chose d'un code C++ écrit ces dix-quinze dernières année ?
| Ça dépend de comment on l'écrit. Si une des exigeances du | projet est de supporter des anciens compilateurs, on peut | écrire du code qui le fait. (S'il faut, on peut même encore | écrire du C:-).) Certains projets essaient de le faire, | considère | http://www.mozilla.org/hacking/mozilla-style-guide.html.
oh oui, je connais je machin -- on se demande pourquoi il ne sont pas resté à C K&R.
Peut-être parce qu'ils avaient l'habitude en C de declarer une struct, et un ensemble de fonctions qui la manipulent, et puis de se croiser les doigts que personne ne la manipule autrement qu'avec ces fonctions, et que donc, la simple possibilité de déclarer des parties privées représente pour eux une amélioration importante par rapport à C.
On peut avoir beaucoup de raisons pour vouloir faire du C++ plutôt que du C; à mon avis, les parties privées en est une des plus importantes. L'amélioration des vérifications statiques de type, aussi. D'une certaine côté, la reste, c'est du surplus ; c'est bien de l'avoir, mais je me servirais du C++ plutôt que du C même s'il n'était pas là.
Quant aux restrictions qu'on impose pour des raisons de portabilité, chaque projet a besoin d'établir ses propres règles, en fonction des ses besoins de portabilité. Si Mozilla cible des plateformes où les templates ou les exceptions posent un problème, ils ont raison de les exclure ; ce qui en reste, c'est toujours mieux que rien.
-- 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
Samuel Krempp
le Friday 01 April 2005 17:46, écrivit :
pascal wrote:
Je remarque que le compilateur ne correspond pas totalement au bouquin de Bjarne Stroustrup. Je m'explique: <code> struct X{ int a; int * a; struct X; };
Euh, je n'ai pas testé, mais ca m'étonnerait fort que *CE* code compile hein. Déjà il y a deux `a' de déclaré.
et une classe membre ne doit pas avoir le même nom que la classe, il faut donc rennommer X dans struct X;
Ensuite, le dernier membre n'a même pas de nom... quel code compile alors ? faudrait mieux copier/coller le code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre. Version compilable de ce truc :
struct X{ int * a; struct Toto; };
(X::Toto est déclaré, et a un type incomplet à ce stade).
Enfin, ça ne change rien au fait que le posteur original utilise selon toute vraissemblance un compilateur très mauvais (ou ne connait pas le copier-coller), et se fourvoit complètement : "struct Toto;" déclare un type X::Toto, non pas une variable membre de type Toto.
-- Sam
le Friday 01 April 2005 17:46, fleury_anthony@_hotmail.com_ écrivit :
pascal wrote:
Je remarque que le compilateur ne correspond pas totalement au bouquin
de Bjarne Stroustrup.
Je m'explique:
<code>
struct X{
int a;
int * a;
struct X;
};
Euh, je n'ai pas testé, mais ca m'étonnerait fort que *CE* code compile
hein. Déjà il y a deux `a' de déclaré.
et une classe membre ne doit pas avoir le même nom que la classe, il faut
donc rennommer X dans
struct X;
Ensuite, le dernier membre n'a même
pas de nom... quel code compile alors ? faudrait mieux copier/coller le
code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre.
Version compilable de ce truc :
struct X{
int * a;
struct Toto;
};
(X::Toto est déclaré, et a un type incomplet à ce stade).
Enfin, ça ne change rien au fait que le posteur original utilise selon toute
vraissemblance un compilateur très mauvais (ou ne connait pas le
copier-coller), et se fourvoit complètement : "struct Toto;" déclare un
type X::Toto, non pas une variable membre de type Toto.
Je remarque que le compilateur ne correspond pas totalement au bouquin de Bjarne Stroustrup. Je m'explique: <code> struct X{ int a; int * a; struct X; };
Euh, je n'ai pas testé, mais ca m'étonnerait fort que *CE* code compile hein. Déjà il y a deux `a' de déclaré.
et une classe membre ne doit pas avoir le même nom que la classe, il faut donc rennommer X dans struct X;
Ensuite, le dernier membre n'a même pas de nom... quel code compile alors ? faudrait mieux copier/coller le code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre. Version compilable de ce truc :
struct X{ int * a; struct Toto; };
(X::Toto est déclaré, et a un type incomplet à ce stade).
Enfin, ça ne change rien au fait que le posteur original utilise selon toute vraissemblance un compilateur très mauvais (ou ne connait pas le copier-coller), et se fourvoit complètement : "struct Toto;" déclare un type X::Toto, non pas une variable membre de type Toto.
-- Sam
pascal
le Friday 01 April 2005 17:46, écrivit :
pascal wrote:
Je remarque que le compilateur ne correspond pas totalement au bouquin de Bjarne Stroustrup. Je m'explique: <code> struct X{ int a; int * a; struct X; };
Euh, je n'ai pas testé, mais ca m'étonnerait fort que *CE* code com pile
hein. Déjà il y a deux `a' de déclaré.
et une classe membre ne doit pas avoir le même nom que la classe, il f aut donc rennommer X dans struct X;
Ensuite, le dernier membre n'a même pas de nom... quel code compile alors ? faudrait mieux copier/coller le code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre. Version compilable de ce truc :
struct X{ int * a; struct Toto; };
(X::Toto est déclaré, et a un type incomplet à ce stade).
Enfin, ça ne change rien au fait que le posteur original utilise selon toute vraissemblance un compilateur très mauvais (ou ne connait pas le copier-coller), et se fourvoit complètement : "struct Toto;" déclare un type X::Toto, non pas une variable membre de type Toto.
pour le **bon** code j'ai mis dans le post "struct déclaration" ce jour .
le Friday 01 April 2005 17:46, fleury_anthony@_hotmail.com_ écrivit :
pascal wrote:
Je remarque que le compilateur ne correspond pas totalement au bouquin
de Bjarne Stroustrup.
Je m'explique:
<code>
struct X{
int a;
int * a;
struct X;
};
Euh, je n'ai pas testé, mais ca m'étonnerait fort que *CE* code com pile
hein. Déjà il y a deux `a' de déclaré.
et une classe membre ne doit pas avoir le même nom que la classe, il f aut
donc rennommer X dans
struct X;
Ensuite, le dernier membre n'a même
pas de nom... quel code compile alors ? faudrait mieux copier/coller le
code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre.
Version compilable de ce truc :
struct X{
int * a;
struct Toto;
};
(X::Toto est déclaré, et a un type incomplet à ce stade).
Enfin, ça ne change rien au fait que le posteur original utilise selon toute
vraissemblance un compilateur très mauvais (ou ne connait pas le
copier-coller), et se fourvoit complètement : "struct Toto;" déclare un
type X::Toto, non pas une variable membre de type Toto.
pour le **bon** code j'ai mis dans le post "struct déclaration" ce jour .
Je remarque que le compilateur ne correspond pas totalement au bouquin de Bjarne Stroustrup. Je m'explique: <code> struct X{ int a; int * a; struct X; };
Euh, je n'ai pas testé, mais ca m'étonnerait fort que *CE* code com pile
hein. Déjà il y a deux `a' de déclaré.
et une classe membre ne doit pas avoir le même nom que la classe, il f aut donc rennommer X dans struct X;
Ensuite, le dernier membre n'a même pas de nom... quel code compile alors ? faudrait mieux copier/coller le code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre. Version compilable de ce truc :
struct X{ int * a; struct Toto; };
(X::Toto est déclaré, et a un type incomplet à ce stade).
Enfin, ça ne change rien au fait que le posteur original utilise selon toute vraissemblance un compilateur très mauvais (ou ne connait pas le copier-coller), et se fourvoit complètement : "struct Toto;" déclare un type X::Toto, non pas une variable membre de type Toto.
pour le **bon** code j'ai mis dans le post "struct déclaration" ce jour .
Anthony Fleury
Samuel Krempp wrote:
le Friday 01 April 2005 17:46, écrivit :
Ensuite, le dernier membre n'a même pas de nom... quel code compile alors ? faudrait mieux copier/coller le code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre. Version compilable de ce truc : struct X{ int * a; struct Toto; };
Oula, merci pour la correction, on va dire que c'était une blague que j'ai faite le premier avril :-) Décidément je fais trop de C en ce moment (où même si ce code est valide, il ne sert strictement à rien puisque l'on ne peut pas définir de `X::Toto' ensuite. [ et en voyant son code on a vite dans l'idée qu'il veut utiliser la facon « idiomatique » pour les arbres en C , donc avec un struct X* fils; par exemple ]
-- Anthony Fleury
Samuel Krempp wrote:
le Friday 01 April 2005 17:46, fleury_anthony@_hotmail.com_ écrivit :
Ensuite, le dernier membre n'a même
pas de nom... quel code compile alors ? faudrait mieux copier/coller le
code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre.
Version compilable de ce truc :
struct X{
int * a;
struct Toto;
};
Oula, merci pour la correction, on va dire que c'était une blague que j'ai
faite le premier avril :-) Décidément je fais trop de C en ce moment (où
même si ce code est valide, il ne sert strictement à rien puisque l'on ne
peut pas définir de `X::Toto' ensuite. [ et en voyant son code on a vite
dans l'idée qu'il veut utiliser la facon « idiomatique » pour les arbres en
C , donc avec un struct X* fils; par exemple ]
Ensuite, le dernier membre n'a même pas de nom... quel code compile alors ? faudrait mieux copier/coller le code qui compile pour éviter ce type d'erreurs.
si, le nom est X. c'est une déclaration de struct membre. Version compilable de ce truc : struct X{ int * a; struct Toto; };
Oula, merci pour la correction, on va dire que c'était une blague que j'ai faite le premier avril :-) Décidément je fais trop de C en ce moment (où même si ce code est valide, il ne sert strictement à rien puisque l'on ne peut pas définir de `X::Toto' ensuite. [ et en voyant son code on a vite dans l'idée qu'il veut utiliser la facon « idiomatique » pour les arbres en C , donc avec un struct X* fils; par exemple ]
