Bug GCC 3.3 ?

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> 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.
|
| http://seal.web.cern.ch/seal/snapshot/workbook/reflection.html
|
| On y trouve quelques papiers. Je ne sais pas grand chose de plus.

Mais, c'est très intéressant. C'est fou ce qu'il veut ressembler à XTI
:-)

-- Gaby

Gabriel Dos Reis wrote:

Tout dépend de ce que tu places sous « introspection » :

Sans doute. Là, en l'occurrence, il s'agit de savoir associer un nom
(string) à un membre d'une classe pendant le runtime (par exemple, en
interprétant un script).

il y a des
outils ou des compilateurs qui permettent d'avoir des informations sur
un programme.

C'est-à-dire ?

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.

Connais pas.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

| Gabriel Dos Reis wrote:
|
| > Tout dépend de ce que tu places sous « introspection » :
|
| Sans doute. Là, en l'occurrence, il s'agit de savoir associer un nom
| (string) à un membre d'une classe pendant le runtime (par exemple, en
| interprétant un script).
|
| > il y a des
| > outils ou des compilateurs qui permettent d'avoir des informations sur
| > un programme.
|
| C'est-à-dire ?

Par exemple, ce que tu viens juste de décrire ci-haut.

|
| > 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.
|
| Connais pas.

Regarde le lien donné par Laurent pour avoir une idée des choses
qu'ils font avec.

-- Gaby

Gabriel Dos Reis wrote:

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.

as-tu un lien? Inutile de dire que Stroustrup+#nospam avec google, ca
explose ;-) Rien trouve non plus sur sa home page.

a+, ld.

Gabriel Dos Reis wrote:

Regarde le lien donné par Laurent pour avoir une idée des choses
qu'ils font avec.

Vi. Effectivement. Si seulement c'était apparu quelques années plus tôt !...

--
Arnaud
(Supprimez les geneurs pour me répondre)

In article <cnvjdi$hdl$1@sunnews.cern.ch>, Laurent Deniau wrote:

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.

Hu ?
Quand un fichier fait un #include d'un autre, ils ne forment
qu'une TU il me semble, non ?

Des portees en cpp? Definies par quoi?

Et bien, des identifiants de porté ;-)
#openbloc
#closebloc

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.

Ce que je reproche à cpp n'est pas tellement sa complexité
que le manque de protection face à l'étourderie, ou, dit autrement,
l'absence de support pour un partitionnement de la complexité
du problème.

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.

Gabriel Dos Reis wrote:

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> 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.
|
| http://seal.web.cern.ch/seal/snapshot/workbook/reflection.html
|
| On y trouve quelques papiers. Je ne sais pas grand chose de plus.

Mais, c'est très intéressant. C'est fou ce qu'il veut ressembler à XTI
:-)

Ils ne s'en cache pas. Dans son papier (pdf en bas de la page), S.
Roiser dit clairement que c'est en attendant les XTI et que la
transition future doit rester facile. Donc je suppose que l'interface
colle le plus possible avec les propositions de BS. D'ailleurs a part
ses slides, est-ce que BS a ecrit un papier sur les XTI? Pas trouve sur
son site web (il devrait penser a y mettre un google:search ;-) )

a+, ld.

Marc Boyer wrote:

In article <cnvjdi$hdl$1@sunnews.cern.ch>, Laurent Deniau wrote:

Local au fichier par exemple. Ou introduire des portées en cpp.

TU = translation unit, ce que tu appelles le fichier.

Hu ?
Quand un fichier fait un #include d'un autre, ils ne forment
qu'une TU il me semble, non ?

Oui. Mais tu veux que tes blocs s'arretent au premier #include ou qu'un
#include dans un bloc ne soit pas considere? C'est pour ca que je
prefere parler de TU, c'est plus simple que de parler de fichier.

Des portees en cpp? Definies par quoi?

Et bien, des identifiants de porté ;-)
#openbloc
#closebloc

Arf. J'ai deja ca en OOC (les scopes). Le scope de l'interface d'une
classe se definit comme:

#include <ooc/Object.h>

#include OpenInterface // peut inclure des defines

#define CLASS MyClass
#define SUPER Object

#include CloseInterface // inclus du nettoyage, CLASS et SUPER inclus

Ca ressemble presque non?

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.

Ce que je reproche à cpp n'est pas tellement sa complexité
que le manque de protection face à l'étourderie, ou, dit autrement,
l'absence de support pour un partitionnement de la complexité
du problème.

Si tu parts dans cette direction, tu vas vouloir lui ajouter plein de
trucs (peut-etre meme une collaboration avec le systeme de type du
langage). Je prefere qu'il reste simple et *rapide*. Il a deja pas mal
de boulot a faire le pauvre...

a+, ld.

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > 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.
|
| as-tu un lien? Inutile de dire que Stroustrup+#nospam avec google, ca
| explose ;-) Rien trouve non plus sur sa home page.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1614.pdf

(La prochaine version de cette proposition n'utilisera probablement
pas « scope », puisque cela crée certaines confusions. Moi, j'aime
bien « #nospam » -- comme on peut le voir dans la liste de EWG -- mais
cela semble politiquement pour certains).

-- Gaby

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| > | Gabriel Dos Reis wrote:
| > | > Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> 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.
| > | | http://seal.web.cern.ch/seal/snapshot/workbook/reflection.html
| > | | On y trouve quelques papiers. Je ne sais pas grand chose de plus.
| > Mais, c'est très intéressant. C'est fou ce qu'il veut ressembler à
| > XTI
| > :-)
|
| Ils ne s'en cache pas.

Oui, j'ai lu leur papier avant de faire le commentaire.

| Dans son papier (pdf en bas de la page),
| S. Roiser dit clairement que c'est en attendant les XTI et que la
| transition future doit rester facile. Donc je suppose que l'interface
| colle le plus possible avec les propositions de BS. D'ailleurs a part
| ses slides, est-ce que BS a ecrit un papier sur les XTI?

Oui. On en a soumis un à une conférence à venir. On a des slides.

(au fait, cela s'appelle IPR maintenant).

-- Gaby