j'ai du mal avec un code C++, et je soupsonne un bug de GCC 3.3.x.
Je n'arrive néanmoins pas à le trouver dans la base de donnée
des bugs (mais j'utilise peut-être pas les bons mots clef).
Voilà, est-ce que le nombre de caractères significatifs pour
une classe pourrait-être tout petit en GCC 3.3 ?
J'ai deux classes template: StateSpace et StateSpaceNode,
et je me demande s'il ne les confond pas parfois.
Si vous en avez connaissance, merci de me le dire avant que je
tente le passage à GCC 3.4 (je suis pas partant, ma tentative
de passage 3.2 à 3.3 a conduit à une réinstallation complète
de la machine: oui, je suis nul en administration Linux).
Merci d'avance,
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
#includeonce qui gère tout seule l'inclusion multiple, etc...
Comme le #import d'Objective-C, qui est déclaré deprecated par gcc?
Je ne connais pas Objective-C, mais d'après le nom, oui, ce serait quelque chose du genre.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Laurent Deniau
Marc Boyer wrote:
In article <cnv6vg$i1i$, Laurent Deniau wrote:
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas utile. Genre #definelocal pour définir une macro de portée locale, ou un #includeonce qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local signifie quoi ici? Les scopes du C?
Il manque cependant un point essentiel dans cpp du C99, la possibilite soit de connaitre le nombre de parametres variables d'une macro variadic (un truc du genre __VA_NUM_ARGS__ qui dit combien __VA_ARGS__ contient de parametres), soit d'eliminer la derniere ',' lorsque le premier parametre variadic est manquant (a-la-gcc). Les deux sont compatibles, on pourrait avoir les deux. Le premier suffit pour resoudre les problemes que j'ai rencontre mais necessite d'utiliser beaucoup de macros derriere (une par valeur valide de __VA_NUM_ARGS__ par ex.). La deuxieme n'est pas suffisante mais resoud le probleme precedant avec une seule macro.
#define my_va_mac_0(a) // ... #define my_va_mac_1(a, b) // ... #define my_va_mac_2(a, b, c) // ... //...
Note que si on pouvait avoir un #if #else #endif *dans une macro*, le ## unaire utilise ci-dessus (gnuish) deviendrait presque inutile: on decompose le meme probleme en deux macros: une pour __VA_NUM_ARGS__ == 0 et une pour __VA_NUM_ARGS__ > 0 ;-)
Ca permettrait aussi de faire du code de portabilite plus encapsule: les #if #else #endif etant dans la macro au lieu de a l'exterieur, les cascades de codes conditionnels pour la portabilite pourraient etre mieux structures.
Sinon, je citais perl mais on peut imaginer sed, awk ou autre manipulateur de texte.
Autant mettre tout ca dans des passes gerees par un makefile.
Tout à fait. C'est bien ça que je reprocherais à cpp: il est soit trop puissant pour le C (puisqu'il permet bien plus que les définitions de constantes et de macros), soit pas assez puissant en tant que générateur de code C.
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament flexible tout en restant dans la philosophie du C/C++.
a+, ld.
Marc Boyer wrote:
In article <cnv6vg$i1i$1@sunnews.cern.ch>, Laurent Deniau wrote:
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de
simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas
utile.
Genre
#definelocal
pour définir une macro de portée locale, ou un
#includeonce
qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local
signifie quoi ici? Les scopes du C?
Il manque cependant un point essentiel dans cpp du C99, la possibilite
soit de connaitre le nombre de parametres variables d'une macro variadic
(un truc du genre __VA_NUM_ARGS__ qui dit combien __VA_ARGS__ contient
de parametres), soit d'eliminer la derniere ',' lorsque le premier
parametre variadic est manquant (a-la-gcc). Les deux sont compatibles,
on pourrait avoir les deux. Le premier suffit pour resoudre les
problemes que j'ai rencontre mais necessite d'utiliser beaucoup de
macros derriere (une par valeur valide de __VA_NUM_ARGS__ par ex.). La
deuxieme n'est pas suffisante mais resoud le probleme precedant avec une
seule macro.
#define my_va_mac_0(a) // ...
#define my_va_mac_1(a, b) // ...
#define my_va_mac_2(a, b, c) // ...
//...
Note que si on pouvait avoir un #if #else #endif *dans une macro*, le ##
unaire utilise ci-dessus (gnuish) deviendrait presque inutile: on
decompose le meme probleme en deux macros: une pour __VA_NUM_ARGS__ == 0
et une pour __VA_NUM_ARGS__ > 0 ;-)
Ca permettrait aussi de faire du code de portabilite plus encapsule: les
#if #else #endif etant dans la macro au lieu de a l'exterieur, les
cascades de codes conditionnels pour la portabilite pourraient etre
mieux structures.
Sinon, je citais perl mais on peut imaginer sed, awk ou autre
manipulateur de texte.
Autant mettre tout ca dans des passes gerees par un makefile.
Tout à fait. C'est bien ça que je reprocherais à cpp: il
est soit trop puissant pour le C (puisqu'il permet bien plus
que les définitions de constantes et de macros), soit pas
assez puissant en tant que générateur de code C.
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament
flexible tout en restant dans la philosophie du C/C++.
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas utile. Genre #definelocal pour définir une macro de portée locale, ou un #includeonce qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local signifie quoi ici? Les scopes du C?
Il manque cependant un point essentiel dans cpp du C99, la possibilite soit de connaitre le nombre de parametres variables d'une macro variadic (un truc du genre __VA_NUM_ARGS__ qui dit combien __VA_ARGS__ contient de parametres), soit d'eliminer la derniere ',' lorsque le premier parametre variadic est manquant (a-la-gcc). Les deux sont compatibles, on pourrait avoir les deux. Le premier suffit pour resoudre les problemes que j'ai rencontre mais necessite d'utiliser beaucoup de macros derriere (une par valeur valide de __VA_NUM_ARGS__ par ex.). La deuxieme n'est pas suffisante mais resoud le probleme precedant avec une seule macro.
#define my_va_mac_0(a) // ... #define my_va_mac_1(a, b) // ... #define my_va_mac_2(a, b, c) // ... //...
Note que si on pouvait avoir un #if #else #endif *dans une macro*, le ## unaire utilise ci-dessus (gnuish) deviendrait presque inutile: on decompose le meme probleme en deux macros: une pour __VA_NUM_ARGS__ == 0 et une pour __VA_NUM_ARGS__ > 0 ;-)
Ca permettrait aussi de faire du code de portabilite plus encapsule: les #if #else #endif etant dans la macro au lieu de a l'exterieur, les cascades de codes conditionnels pour la portabilite pourraient etre mieux structures.
Sinon, je citais perl mais on peut imaginer sed, awk ou autre manipulateur de texte.
Autant mettre tout ca dans des passes gerees par un makefile.
Tout à fait. C'est bien ça que je reprocherais à cpp: il est soit trop puissant pour le C (puisqu'il permet bien plus que les définitions de constantes et de macros), soit pas assez puissant en tant que générateur de code C.
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament flexible tout en restant dans la philosophie du C/C++.
a+, ld.
Marc Boyer
In article <cnvf5h$74f$, Laurent Deniau wrote:
Marc Boyer wrote:
In article <cnv6vg$i1i$, Laurent Deniau wrote:
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas utile. Genre #definelocal pour définir une macro de portée locale, ou un #includeonce qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local signifie quoi ici? Les scopes du C?
Local au fichier par exemple. Ou introduire des portées en cpp.
#define my_va_mac_0(a) // ... #define my_va_mac_1(a, b) // ... #define my_va_mac_2(a, b, c) // ... //...
Note que si on pouvait avoir un #if #else #endif *dans une macro*, le ## unaire utilise ci-dessus (gnuish) deviendrait presque inutile: on decompose le meme probleme en deux macros: une pour __VA_NUM_ARGS__ == 0 et une pour __VA_NUM_ARGS__ > 0 ;-)
Ca permettrait aussi de faire du code de portabilite plus encapsule: les #if #else #endif etant dans la macro au lieu de a l'exterieur, les cascades de codes conditionnels pour la portabilite pourraient etre mieux structures.
OK
Tout à fait. C'est bien ça que je reprocherais à cpp: il est soit trop puissant pour le C (puisqu'il permet bien plus que les définitions de constantes et de macros), soit pas assez puissant en tant que générateur de code C.
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament flexible tout en restant dans la philosophie du C/C++.
Questions de gouts. Mais quand même, avec l'expérience accumulée sur OOC, j'imagine que tu tombes moins dans les pièges que les autres.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <cnvf5h$74f$1@sunnews.cern.ch>, Laurent Deniau wrote:
Marc Boyer wrote:
In article <cnv6vg$i1i$1@sunnews.cern.ch>, Laurent Deniau wrote:
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de
simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas
utile.
Genre
#definelocal
pour définir une macro de portée locale, ou un
#includeonce
qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local
signifie quoi ici? Les scopes du C?
Local au fichier par exemple. Ou introduire des portées en cpp.
#define my_va_mac_0(a) // ...
#define my_va_mac_1(a, b) // ...
#define my_va_mac_2(a, b, c) // ...
//...
Note que si on pouvait avoir un #if #else #endif *dans une macro*, le ##
unaire utilise ci-dessus (gnuish) deviendrait presque inutile: on
decompose le meme probleme en deux macros: une pour __VA_NUM_ARGS__ == 0
et une pour __VA_NUM_ARGS__ > 0 ;-)
Ca permettrait aussi de faire du code de portabilite plus encapsule: les
#if #else #endif etant dans la macro au lieu de a l'exterieur, les
cascades de codes conditionnels pour la portabilite pourraient etre
mieux structures.
OK
Tout à fait. C'est bien ça que je reprocherais à cpp: il
est soit trop puissant pour le C (puisqu'il permet bien plus
que les définitions de constantes et de macros), soit pas
assez puissant en tant que générateur de code C.
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament
flexible tout en restant dans la philosophie du C/C++.
Questions de gouts. Mais quand même, avec l'expérience
accumulée sur OOC, j'imagine que tu tombes moins dans les
pièges que les autres.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas utile. Genre #definelocal pour définir une macro de portée locale, ou un #includeonce qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local signifie quoi ici? Les scopes du C?
Local au fichier par exemple. Ou introduire des portées en cpp.
#define my_va_mac_0(a) // ... #define my_va_mac_1(a, b) // ... #define my_va_mac_2(a, b, c) // ... //...
Note que si on pouvait avoir un #if #else #endif *dans une macro*, le ## unaire utilise ci-dessus (gnuish) deviendrait presque inutile: on decompose le meme probleme en deux macros: une pour __VA_NUM_ARGS__ == 0 et une pour __VA_NUM_ARGS__ > 0 ;-)
Ca permettrait aussi de faire du code de portabilite plus encapsule: les #if #else #endif etant dans la macro au lieu de a l'exterieur, les cascades de codes conditionnels pour la portabilite pourraient etre mieux structures.
OK
Tout à fait. C'est bien ça que je reprocherais à cpp: il est soit trop puissant pour le C (puisqu'il permet bien plus que les définitions de constantes et de macros), soit pas assez puissant en tant que générateur de code C.
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament flexible tout en restant dans la philosophie du C/C++.
Questions de gouts. Mais quand même, avec l'expérience accumulée sur OOC, j'imagine que tu tombes moins dans les pièges que les autres.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Laurent Deniau
Marc Boyer wrote:
In article <cnvf5h$74f$, Laurent Deniau wrote:
Marc Boyer wrote:
In article <cnv6vg$i1i$, Laurent Deniau wrote:
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas utile. Genre #definelocal pour définir une macro de portée locale, ou un #includeonce qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local signifie quoi ici? Les scopes du C?
Local au fichier par exemple. Ou introduire des portées en cpp.
TU = translation unit, ce que tu appelles le fichier. Des portees en cpp? Definies par quoi?
[...]
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament flexible tout en restant dans la philosophie du C/C++.
Questions de gouts. Mais quand même, avec l'expérience accumulée sur OOC, j'imagine que tu tombes moins dans les pièges que les autres.
Je sais pas. OOC n'est pas tres complique, meme dans ces macros. Il y en a beaucoup et sur plusieurs niveaux (pour les organiser/structurer), c'est tout. J'essaye de laisser le namespace des macros aussi propre que possible en dehors des scopes de OOC.
Les macros les plus complexes sont celles qui definissent la reflection (qui est entierement prise en charge par OOC, #include <ooc/rft/Reflection.h> dans l'implementation d'une classe suffit pour que celle-ci supporte la reflection/introspection).
Rien de bien complique en fait, et c'est le but, rester simple (et clair). Le moindre livre sur le C contient des exemples bien plus compliques.
a+, ld.
Marc Boyer wrote:
In article <cnvf5h$74f$1@sunnews.cern.ch>, Laurent Deniau wrote:
Marc Boyer wrote:
In article <cnv6vg$i1i$1@sunnews.cern.ch>, Laurent Deniau wrote:
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de
simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas
utile.
Genre
#definelocal
pour définir une macro de portée locale, ou un
#includeonce
qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local
signifie quoi ici? Les scopes du C?
Local au fichier par exemple. Ou introduire des portées en cpp.
TU = translation unit, ce que tu appelles le fichier.
Des portees en cpp? Definies par quoi?
[...]
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament
flexible tout en restant dans la philosophie du C/C++.
Questions de gouts. Mais quand même, avec l'expérience
accumulée sur OOC, j'imagine que tu tombes moins dans les
pièges que les autres.
Je sais pas. OOC n'est pas tres complique, meme dans ces macros. Il y en
a beaucoup et sur plusieurs niveaux (pour les organiser/structurer),
c'est tout. J'essaye de laisser le namespace des macros aussi propre que
possible en dehors des scopes de OOC.
Les macros les plus complexes sont celles qui definissent la reflection
(qui est entierement prise en charge par OOC, #include
<ooc/rft/Reflection.h> dans l'implementation d'une classe suffit pour
que celle-ci supporte la reflection/introspection).
Rien de bien complique en fait, et c'est le but, rester simple (et
clair). Le moindre livre sur le C contient des exemples bien plus
compliques.
Pour un outil standard au C, il vaut mieux s'en tenir a quelque chose de simple...
Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas utile. Genre #definelocal pour définir une macro de portée locale, ou un #includeonce qui gère tout seule l'inclusion multiple, etc...
Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors local signifie quoi ici? Les scopes du C?
Local au fichier par exemple. Ou introduire des portées en cpp.
TU = translation unit, ce que tu appelles le fichier. Des portees en cpp? Definies par quoi?
[...]
Je trouve qu'il ne lui manque pas grand chose pour etre suffisament flexible tout en restant dans la philosophie du C/C++.
Questions de gouts. Mais quand même, avec l'expérience accumulée sur OOC, j'imagine que tu tombes moins dans les pièges que les autres.
Je sais pas. OOC n'est pas tres complique, meme dans ces macros. Il y en a beaucoup et sur plusieurs niveaux (pour les organiser/structurer), c'est tout. J'essaye de laisser le namespace des macros aussi propre que possible en dehors des scopes de OOC.
Les macros les plus complexes sont celles qui definissent la reflection (qui est entierement prise en charge par OOC, #include <ooc/rft/Reflection.h> dans l'implementation d'une classe suffit pour que celle-ci supporte la reflection/introspection).
Rien de bien complique en fait, et c'est le but, rester simple (et clair). Le moindre livre sur le C contient des exemples bien plus compliques.
a+, ld.
Gabriel Dos Reis
Arnaud Meurgues writes:
| Laurent Deniau wrote: | | > futhermore, I'm of the opinion that Cpp should only be used by | > programmers which know Cpp ;-) | > OOC contient pres de 200 macros (+150 pour enlever le namespace ooc_ | > sur demande). Pas de probleme pourtant. J'ai juste parfois des | > messages aussi abscons que les templates mais on peut pas tout avoir | > :-) | | J'avoue que dans le produit dont je m'occupe, on veut que le moteur | ait une connaissance des classes qu'il manipule. En l'absence | d'introspection, les macros permettent d'enregistrer la description | des classes durant l'initalisation statique et je ne sais pas comment | on pourrait s'en passer sans rendre cauchemardesque pour le | développeur la description d'une nouvelle classe.
Tout dépend de ce que tu places sous « introspection » : il y a des outils ou des compilateurs qui permettent d'avoir des informations sur un programme. Le front-end EDG par exemple est très flexible å cet égard. Il y a aussi des projets comme GCC-XML -- attention je ne l'ai jamais utilisé moi-même.
| Laurent Deniau wrote:
|
| > futhermore, I'm of the opinion that Cpp should only be used by
| > programmers which know Cpp ;-)
| > OOC contient pres de 200 macros (+150 pour enlever le namespace ooc_
| > sur demande). Pas de probleme pourtant. J'ai juste parfois des
| > messages aussi abscons que les templates mais on peut pas tout avoir
| > :-)
|
| J'avoue que dans le produit dont je m'occupe, on veut que le moteur
| ait une connaissance des classes qu'il manipule. En l'absence
| d'introspection, les macros permettent d'enregistrer la description
| des classes durant l'initalisation statique et je ne sais pas comment
| on pourrait s'en passer sans rendre cauchemardesque pour le
| développeur la description d'une nouvelle classe.
Tout dépend de ce que tu places sous « introspection » : il y a des
outils ou des compilateurs qui permettent d'avoir des informations sur
un programme. Le front-end EDG par exemple est très flexible å cet
égard. Il y a aussi des projets comme GCC-XML -- attention je ne l'ai
jamais utilisé moi-même.
| Laurent Deniau wrote: | | > futhermore, I'm of the opinion that Cpp should only be used by | > programmers which know Cpp ;-) | > OOC contient pres de 200 macros (+150 pour enlever le namespace ooc_ | > sur demande). Pas de probleme pourtant. J'ai juste parfois des | > messages aussi abscons que les templates mais on peut pas tout avoir | > :-) | | J'avoue que dans le produit dont je m'occupe, on veut que le moteur | ait une connaissance des classes qu'il manipule. En l'absence | d'introspection, les macros permettent d'enregistrer la description | des classes durant l'initalisation statique et je ne sais pas comment | on pourrait s'en passer sans rendre cauchemardesque pour le | développeur la description d'une nouvelle classe.
Tout dépend de ce que tu places sous « introspection » : il y a des outils ou des compilateurs qui permettent d'avoir des informations sur un programme. Le front-end EDG par exemple est très flexible å cet égard. Il y a aussi des projets comme GCC-XML -- attention je ne l'ai jamais utilisé moi-même.
-- Gaby
Gabriel Dos Reis
Arnaud Meurgues writes:
| Marc Boyer wrote: | | > On utilise cpp parce qu'il vient avec le langage, mais est-ce | > qu'on ne se taperait pas moins sur les doigts avec m4 ou perl ? | | m4, je ne connais pas. Mais il faudrait me payer cher pour me faire | faire du perl.
| Marc Boyer wrote:
|
| > On utilise cpp parce qu'il vient avec le langage, mais est-ce
| > qu'on ne se taperait pas moins sur les doigts avec m4 ou perl ?
|
| m4, je ne connais pas. Mais il faudrait me payer cher pour me faire
| faire du perl.
| Marc Boyer wrote: | | > On utilise cpp parce qu'il vient avec le langage, mais est-ce | > qu'on ne se taperait pas moins sur les doigts avec m4 ou perl ? | | m4, je ne connais pas. Mais il faudrait me payer cher pour me faire | faire du perl.
Tu travailles pour ILOG gartuitement ? ;-)
-- Gaby
Laurent Deniau
Gabriel Dos Reis wrote:
Arnaud Meurgues writes:
| Laurent Deniau wrote: | | > futhermore, I'm of the opinion that Cpp should only be used by | > programmers which know Cpp ;-) | > OOC contient pres de 200 macros (+150 pour enlever le namespace ooc_ | > sur demande). Pas de probleme pourtant. J'ai juste parfois des | > messages aussi abscons que les templates mais on peut pas tout avoir | > :-) | | J'avoue que dans le produit dont je m'occupe, on veut que le moteur | ait une connaissance des classes qu'il manipule. En l'absence | d'introspection, les macros permettent d'enregistrer la description | des classes durant l'initalisation statique et je ne sais pas comment | on pourrait s'en passer sans rendre cauchemardesque pour le | développeur la description d'une nouvelle classe.
Tout dépend de ce que tu places sous « introspection » : il y a des outils ou des compilateurs qui permettent d'avoir des informations sur un programme. Le front-end EDG par exemple est très flexible å cet égard. Il y a aussi des projets comme GCC-XML -- attention je ne l'ai jamais utilisé moi-même.
GCC-XML est utilise dans le projet SEAL qui inclut un module sur la reflection en C++ en attendant les XTI standard.
| Laurent Deniau wrote:
|
| > futhermore, I'm of the opinion that Cpp should only be used by
| > programmers which know Cpp ;-)
| > OOC contient pres de 200 macros (+150 pour enlever le namespace ooc_
| > sur demande). Pas de probleme pourtant. J'ai juste parfois des
| > messages aussi abscons que les templates mais on peut pas tout avoir
| > :-)
|
| J'avoue que dans le produit dont je m'occupe, on veut que le moteur
| ait une connaissance des classes qu'il manipule. En l'absence
| d'introspection, les macros permettent d'enregistrer la description
| des classes durant l'initalisation statique et je ne sais pas comment
| on pourrait s'en passer sans rendre cauchemardesque pour le
| développeur la description d'une nouvelle classe.
Tout dépend de ce que tu places sous « introspection » : il y a des
outils ou des compilateurs qui permettent d'avoir des informations sur
un programme. Le front-end EDG par exemple est très flexible å cet
égard. Il y a aussi des projets comme GCC-XML -- attention je ne l'ai
jamais utilisé moi-même.
GCC-XML est utilise dans le projet SEAL qui inclut un module sur la
reflection en C++ en attendant les XTI standard.
| Laurent Deniau wrote: | | > futhermore, I'm of the opinion that Cpp should only be used by | > programmers which know Cpp ;-) | > OOC contient pres de 200 macros (+150 pour enlever le namespace ooc_ | > sur demande). Pas de probleme pourtant. J'ai juste parfois des | > messages aussi abscons que les templates mais on peut pas tout avoir | > :-) | | J'avoue que dans le produit dont je m'occupe, on veut que le moteur | ait une connaissance des classes qu'il manipule. En l'absence | d'introspection, les macros permettent d'enregistrer la description | des classes durant l'initalisation statique et je ne sais pas comment | on pourrait s'en passer sans rendre cauchemardesque pour le | développeur la description d'une nouvelle classe.
Tout dépend de ce que tu places sous « introspection » : il y a des outils ou des compilateurs qui permettent d'avoir des informations sur un programme. Le front-end EDG par exemple est très flexible å cet égard. Il y a aussi des projets comme GCC-XML -- attention je ne l'ai jamais utilisé moi-même.
GCC-XML est utilise dans le projet SEAL qui inclut un module sur la reflection en C++ en attendant les XTI standard.
On y trouve quelques papiers. Je ne sais pas grand chose de plus.
a+, ld.
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote in message | news:... | | > « furthermore, I'm of the opinion that Cpp must be abolished » | | Si cpp n'existait pas, il faudrait l'inventer:-). | | Sérieusement, dans le C et le C++ actuel, cpp est nécessaire -- on ne
Bof.
| peut pas faire sans. Pour l'abolir, il faut d'abord qu'il y a des | alternatifs.
C'est évident, non ?
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote in message
| news:<m38y8t986k.fsf@merlin.cs.tamu.edu>...
|
| > « furthermore, I'm of the opinion that Cpp must be abolished »
|
| Si cpp n'existait pas, il faudrait l'inventer:-).
|
| Sérieusement, dans le C et le C++ actuel, cpp est nécessaire -- on ne
Bof.
| peut pas faire sans. Pour l'abolir, il faut d'abord qu'il y a des
| alternatifs.
| Gabriel Dos Reis wrote in message | news:... | | > « furthermore, I'm of the opinion that Cpp must be abolished » | | Si cpp n'existait pas, il faudrait l'inventer:-). | | Sérieusement, dans le C et le C++ actuel, cpp est nécessaire -- on ne
Bof.
| peut pas faire sans. Pour l'abolir, il faut d'abord qu'il y a des | alternatifs.
C'est évident, non ?
-- Gaby
Arnaud Meurgues
Gabriel Dos Reis wrote:
| m4, je ne connais pas. Mais il faudrait me payer cher pour me faire | faire du perl.
Tu travailles pour ILOG gartuitement ? ;-)
Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je demanderais une sérieuse augmentation... :)
-- Arnaud (Supprimez les geneurs pour me répondre)
Gabriel Dos Reis wrote:
| m4, je ne connais pas. Mais il faudrait me payer cher pour me faire
| faire du perl.
Tu travailles pour ILOG gartuitement ? ;-)
Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je
demanderais une sérieuse augmentation... :)
--
Arnaud
(Supprimez les geneurs pour me répondre)
| m4, je ne connais pas. Mais il faudrait me payer cher pour me faire | faire du perl.
Tu travailles pour ILOG gartuitement ? ;-)
Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je demanderais une sérieuse augmentation... :)
-- Arnaud (Supprimez les geneurs pour me répondre)
Gabriel Dos Reis
Laurent Deniau writes:
| Marc Boyer wrote: | > In article <cnvf5h$74f$, Laurent Deniau wrote: | > | >>Marc Boyer wrote: | >> | >>>In article <cnv6vg$i1i$, Laurent Deniau wrote: | >>> | >>>> Pour un outil standard au C, il vaut mieux s'en tenir a quelque | >>>> chose de simple... | >>> | >>> | >>> Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas | >>>utile. | >>> Genre | >>> #definelocal pour définir une macro de portée locale, ou un | >>> #includeonce | >>> qui gère tout seule l'inclusion multiple, etc... | >> | >> Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors | >> local signifie quoi ici? Les scopes du C? | > Local au fichier par exemple. Ou introduire des portées en cpp. | | TU = translation unit, ce que tu appelles le fichier. | Des portees en cpp? Definies par quoi?
Par forcément des portées mais des régions de texte. Voir la proposition « #nospam » de BS.
-- Gaby
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| Marc Boyer wrote:
| > In article <cnvf5h$74f$1@sunnews.cern.ch>, Laurent Deniau wrote:
| >
| >>Marc Boyer wrote:
| >>
| >>>In article <cnv6vg$i1i$1@sunnews.cern.ch>, Laurent Deniau wrote:
| >>>
| >>>> Pour un outil standard au C, il vaut mieux s'en tenir a quelque
| >>>> chose de simple...
| >>>
| >>>
| >>> Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas
| >>>utile.
| >>> Genre
| >>> #definelocal pour définir une macro de portée locale, ou un
| >>> #includeonce
| >>> qui gère tout seule l'inclusion multiple, etc...
| >>
| >> Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors
| >> local signifie quoi ici? Les scopes du C?
| > Local au fichier par exemple. Ou introduire des portées en cpp.
|
| TU = translation unit, ce que tu appelles le fichier.
| Des portees en cpp? Definies par quoi?
Par forcément des portées mais des régions de texte. Voir la
proposition « #nospam » de BS.
| Marc Boyer wrote: | > In article <cnvf5h$74f$, Laurent Deniau wrote: | > | >>Marc Boyer wrote: | >> | >>>In article <cnv6vg$i1i$, Laurent Deniau wrote: | >>> | >>>> Pour un outil standard au C, il vaut mieux s'en tenir a quelque | >>>> chose de simple... | >>> | >>> | >>> Simple oui, mais est-ce qu'un rien de sécurité en plus ne serait pas | >>>utile. | >>> Genre | >>> #definelocal pour définir une macro de portée locale, ou un | >>> #includeonce | >>> qui gère tout seule l'inclusion multiple, etc... | >> | >> Le probleme c'est que le (seul) scope de cpp, c'est la TU. Alors | >> local signifie quoi ici? Les scopes du C? | > Local au fichier par exemple. Ou introduire des portées en cpp. | | TU = translation unit, ce que tu appelles le fichier. | Des portees en cpp? Definies par quoi?
Par forcément des portées mais des régions de texte. Voir la proposition « #nospam » de BS.
