J'aimerai savoir si il exite une directive qui permet au
pr=E9processeur de pr=E9traiter un fichier deux fois plut=F4t qu'une avant
compilation. Et ce pour que le code suivant est un sens (qui ne
fonctionnerai, selon ma compr=E9hension, qu'au deuxi=E8me pr=E9traitement)
#define D define
#define foo(x,y) foo_2arg(x,y+NULL)
# D MACONST 0xfff
# D foo_2arg(x,y) foo_2arg_prime( x ## * MACONST, y)
int fct(int * a)
{
return foo(22, a)
}
Dans le cas ou une telle directive n'existe pas, est-ce que il existe
une mani=E8re standard ou =E0 d=E9faut, disponible sur tous les
compilateurs, de r=E9clamer une telle op=E9ration dans ses fichiers de
configuration?
Une question:
En C++, il existe deux fonctionnalit=E9s tr=E8s int=E9ressantes, soit la
surcharge d'op=E9rateurs et de fonctions. Est-ce que ces
fonctionnalit=E9s pourraient =EAtre mim=E9s en C?
Et ce pour que le code suivant est un sens (qui ne fonctionnerai, selon ma compréhension, qu'au deuxième prétraitement) Pas d'accord.
Si on peut prétraiter récursivement, on peut faire a peu près
n'importe quoi en autant que l'exécution du programme contrôlant le préprocesseur se termine complêtement, écrit au fichier, puis redémarre. Tel que vu, dans les concours de l'IOCCC, ça fonctionne bien.
L'IOCCC est tout sauf une référence. De plus, dans les concours de l'IOCCC, il est explicitement interdit de faire passer deux fois le préprocesseur.
Après, effectivement avec une machine de Turing on peut faire tourner n'importe quel algorithme. Cela ne veut pas dire que tous les algorithmes doivent être utilisés.
Ah, et comme je l'écrivais le semaine dernière, plutôt qu'utiliser cpp qui est somme toute limité et étrange à l'utilisation, on peut aussi "prétraiter" le source par (liste non limitative): m4, sed/awk, Perl/Python, voire make (j'ai donné) ou MASM (j'ai donné aussi). Etc.
As-tu des arguments concrets contre l'utilisation de cpp (c99) comme preprocesseur pour generer du code? Je pose cette question parce que j'utilise intensivement cpp pour generer du code dans COS et je n'ai pas vu de probleme majeur, mais je ne pousse pas cpp dans ces limites. De son cote, Paul Mensonides va tres loin avec cpp et son probleme est plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou un papier sur ces travaux).
Le gros avantage de cpp, c'est qu'il est inclus dans la chaine de compilation, il est donc plus facile de l'utiliser pour transformer le code puisqu'il est consistant avec l'environement. Avec un autre preprocesseur, la question se pose de l'appliquer avant ou apres cpp. Avant ou apres, les deux ont des avantages et des inconvenients, mais dans les deux cas cela reste complique et demande d'injecter une connaissance partielle de la semantique du C: syntaxe+grammaire (sauf utilisation triviale).
Les limites de cpp sont liees a sa lenteur dans certain cas et donc il faut voir le temps que l'on accepte de passer dans la phase preprocessing: perso j'essaye de rester inferieur a 1/3 du temps total de la compilation de la TU. D'autre part, la necessite de conditionner les cpp-tokens (different des c-tokens) peut poser des problemes de decoupage pour manipuler une sequence de cpp-token, des strings literales ou faire des calculs (contrairement a m4, awk ou perl). Et lorsque ce decoupage ne convient pas (cpp-tokens non separable apriori) on a un probleme de syntaxe inappropriee. En fait, ce qui manque le plus a cpp, c'est la capacite de dire si le prochain cpp-token est un c-token ou non (e.g. __IS_TOKEN__(*int) -> 0 ; __IS_TOKEN__(int*) -> 1) et eventuellement la possibilite de convertir un cpp-token en une sequence de c-token separes par des virgules (e.g. __TO_TOKEN__(cpp-token) -> c,p,p,-,t,o,k,e,n).
a+, ld.
Antoine Leca wrote:
ludovicd@techemail.com écrivit dans
news:1169655199.886126.80730@q2g2000cwa.googlegroups.com:
On 24 jan, 09:53, "Antoine Leca" <r...@localhost.invalid> wrote:
Et ce pour que le code suivant est un sens (qui ne
fonctionnerai, selon ma compréhension, qu'au deuxième
prétraitement)
Pas d'accord.
Si on peut prétraiter récursivement, on peut faire a peu près
n'importe quoi en autant que l'exécution du programme contrôlant le
préprocesseur se termine complêtement, écrit au fichier, puis
redémarre. Tel que vu, dans les concours de l'IOCCC, ça fonctionne
bien.
L'IOCCC est tout sauf une référence. De plus, dans les concours de l'IOCCC,
il est explicitement interdit de faire passer deux fois le préprocesseur.
Après, effectivement avec une machine de Turing on peut faire tourner
n'importe quel algorithme. Cela ne veut pas dire que tous les algorithmes
doivent être utilisés.
Ah, et comme je l'écrivais le semaine dernière, plutôt qu'utiliser cpp qui
est somme toute limité et étrange à l'utilisation, on peut aussi
"prétraiter" le source par (liste non limitative): m4, sed/awk, Perl/Python,
voire make (j'ai donné) ou MASM (j'ai donné aussi). Etc.
As-tu des arguments concrets contre l'utilisation de cpp (c99) comme
preprocesseur pour generer du code? Je pose cette question parce que
j'utilise intensivement cpp pour generer du code dans COS et je n'ai pas
vu de probleme majeur, mais je ne pousse pas cpp dans ces limites. De
son cote, Paul Mensonides va tres loin avec cpp et son probleme est
plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore
grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou un
papier sur ces travaux).
Le gros avantage de cpp, c'est qu'il est inclus dans la chaine de
compilation, il est donc plus facile de l'utiliser pour transformer le
code puisqu'il est consistant avec l'environement. Avec un autre
preprocesseur, la question se pose de l'appliquer avant ou apres cpp.
Avant ou apres, les deux ont des avantages et des inconvenients, mais
dans les deux cas cela reste complique et demande d'injecter une
connaissance partielle de la semantique du C: syntaxe+grammaire (sauf
utilisation triviale).
Les limites de cpp sont liees a sa lenteur dans certain cas et donc il
faut voir le temps que l'on accepte de passer dans la phase
preprocessing: perso j'essaye de rester inferieur a 1/3 du temps total
de la compilation de la TU. D'autre part, la necessite de conditionner
les cpp-tokens (different des c-tokens) peut poser des problemes de
decoupage pour manipuler une sequence de cpp-token, des strings
literales ou faire des calculs (contrairement a m4, awk ou perl). Et
lorsque ce decoupage ne convient pas (cpp-tokens non separable apriori)
on a un probleme de syntaxe inappropriee. En fait, ce qui manque le plus
a cpp, c'est la capacite de dire si le prochain cpp-token est un c-token
ou non (e.g. __IS_TOKEN__(*int) -> 0 ; __IS_TOKEN__(int*) -> 1) et
eventuellement la possibilite de convertir un cpp-token en une sequence
de c-token separes par des virgules (e.g. __TO_TOKEN__(cpp-token) ->
c,p,p,-,t,o,k,e,n).
Et ce pour que le code suivant est un sens (qui ne fonctionnerai, selon ma compréhension, qu'au deuxième prétraitement) Pas d'accord.
Si on peut prétraiter récursivement, on peut faire a peu près
n'importe quoi en autant que l'exécution du programme contrôlant le préprocesseur se termine complêtement, écrit au fichier, puis redémarre. Tel que vu, dans les concours de l'IOCCC, ça fonctionne bien.
L'IOCCC est tout sauf une référence. De plus, dans les concours de l'IOCCC, il est explicitement interdit de faire passer deux fois le préprocesseur.
Après, effectivement avec une machine de Turing on peut faire tourner n'importe quel algorithme. Cela ne veut pas dire que tous les algorithmes doivent être utilisés.
Ah, et comme je l'écrivais le semaine dernière, plutôt qu'utiliser cpp qui est somme toute limité et étrange à l'utilisation, on peut aussi "prétraiter" le source par (liste non limitative): m4, sed/awk, Perl/Python, voire make (j'ai donné) ou MASM (j'ai donné aussi). Etc.
As-tu des arguments concrets contre l'utilisation de cpp (c99) comme preprocesseur pour generer du code? Je pose cette question parce que j'utilise intensivement cpp pour generer du code dans COS et je n'ai pas vu de probleme majeur, mais je ne pousse pas cpp dans ces limites. De son cote, Paul Mensonides va tres loin avec cpp et son probleme est plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou un papier sur ces travaux).
Le gros avantage de cpp, c'est qu'il est inclus dans la chaine de compilation, il est donc plus facile de l'utiliser pour transformer le code puisqu'il est consistant avec l'environement. Avec un autre preprocesseur, la question se pose de l'appliquer avant ou apres cpp. Avant ou apres, les deux ont des avantages et des inconvenients, mais dans les deux cas cela reste complique et demande d'injecter une connaissance partielle de la semantique du C: syntaxe+grammaire (sauf utilisation triviale).
Les limites de cpp sont liees a sa lenteur dans certain cas et donc il faut voir le temps que l'on accepte de passer dans la phase preprocessing: perso j'essaye de rester inferieur a 1/3 du temps total de la compilation de la TU. D'autre part, la necessite de conditionner les cpp-tokens (different des c-tokens) peut poser des problemes de decoupage pour manipuler une sequence de cpp-token, des strings literales ou faire des calculs (contrairement a m4, awk ou perl). Et lorsque ce decoupage ne convient pas (cpp-tokens non separable apriori) on a un probleme de syntaxe inappropriee. En fait, ce qui manque le plus a cpp, c'est la capacite de dire si le prochain cpp-token est un c-token ou non (e.g. __IS_TOKEN__(*int) -> 0 ; __IS_TOKEN__(int*) -> 1) et eventuellement la possibilite de convertir un cpp-token en une sequence de c-token separes par des virgules (e.g. __TO_TOKEN__(cpp-token) -> c,p,p,-,t,o,k,e,n).
a+, ld.
Antoine Leca
Laurent Deniau écrivit dans news:ep9v04$1gr$:
Antoine Leca wrote:
Ah, et comme je l'écrivais le semaine dernière, plutôt qu'utiliser cpp qui est somme toute limité et étrange à l'utilisation, on peut aussi "prétraiter" le source par (liste non limitative): m4, sed/awk, Perl/Python, voire make (j'ai donné) ou MASM (j'ai donné aussi). Etc.
As-tu des arguments concrets contre l'utilisation de cpp (c99) comme preprocesseur pour generer du code?
Non. J'ai seulement répondu à quelqu'un qui, LUI, semble avoir des « problèmes » avec cpp. Et mon expérience, dans ce cas-là, est de chercher à sortir du carcan cpp, plutôt que de se compliquer la vie (qui est l'impression que me donne ses messages).
De plus, et là c'est quand même un argument concret, il y a des chaînes de compilation C pour lesquels cpp n'est pas un programme séparé, ni ne peut être séparé du compilateur C par une option bien choisie (une variation de -E); et là il devient difficile de « jouer » avec cpp pour des utilisations hors contexte de compilation C... (Certes, il est alors possible de prendre un autre préprocesseur, genre celui de GCC ou celui, _nettement_ plus léger, de D. Ritchie si on est gêné par la license GPL).
Je pose cette question parce que j'utilise intensivement cpp pour generer du code dans COS et je n'ai pas vu de probleme majeur, mais je ne pousse pas cpp dans ces limites.
Nous sommes complètement d'accord. Raison pour laquelle j'insiste dans ce fil pour comprendre quel est réellement le _problème_ de "Ludovic", plutôt que de l'aider à faire fonctionner ce qu'il a trouvé comme _solution_.
De son cote, Paul Mensonides va tres loin avec cpp et son probleme est plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou un papier sur ces travaux).
Oui. Mais la logique de P. Mensonides est forcément limitée par le cadre fournie par la norme C ; la quelle ne prévoit pas, par exemple, de passer le préprocesseur deux fois.
Antoine
Laurent Deniau écrivit dans news:ep9v04$1gr$1@cernne03.cern.ch:
Antoine Leca wrote:
Ah, et comme je l'écrivais le semaine dernière, plutôt qu'utiliser
cpp qui est somme toute limité et étrange à l'utilisation, on peut
aussi "prétraiter" le source par (liste non limitative): m4,
sed/awk, Perl/Python, voire make (j'ai donné) ou MASM (j'ai donné
aussi). Etc.
As-tu des arguments concrets contre l'utilisation de cpp (c99) comme
preprocesseur pour generer du code?
Non. J'ai seulement répondu à quelqu'un qui, LUI, semble avoir des
« problèmes » avec cpp. Et mon expérience, dans ce cas-là, est de chercher à
sortir du carcan cpp, plutôt que de se compliquer la vie (qui est
l'impression que me donne ses messages).
De plus, et là c'est quand même un argument concret, il y a des chaînes de
compilation C pour lesquels cpp n'est pas un programme séparé, ni ne peut
être séparé du compilateur C par une option bien choisie (une variation
de -E); et là il devient difficile de « jouer » avec cpp pour des
utilisations hors contexte de compilation C... (Certes, il est alors
possible de prendre un autre préprocesseur, genre celui de GCC ou celui,
_nettement_ plus léger, de D. Ritchie si on est gêné par la license GPL).
Je pose cette question parce que j'utilise intensivement cpp pour
generer du code dans COS et je n'ai pas vu de probleme majeur,
mais je ne pousse pas cpp dans ces limites.
Nous sommes complètement d'accord. Raison pour laquelle j'insiste dans ce
fil pour comprendre quel est réellement le _problème_ de "Ludovic", plutôt
que de l'aider à faire fonctionner ce qu'il a trouvé comme _solution_.
De son cote, Paul Mensonides va tres loin avec cpp et son probleme est
plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore
grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou
un papier sur ces travaux).
Oui. Mais la logique de P. Mensonides est forcément limitée par le cadre
fournie par la norme C ; la quelle ne prévoit pas, par exemple, de passer le
préprocesseur deux fois.
Ah, et comme je l'écrivais le semaine dernière, plutôt qu'utiliser cpp qui est somme toute limité et étrange à l'utilisation, on peut aussi "prétraiter" le source par (liste non limitative): m4, sed/awk, Perl/Python, voire make (j'ai donné) ou MASM (j'ai donné aussi). Etc.
As-tu des arguments concrets contre l'utilisation de cpp (c99) comme preprocesseur pour generer du code?
Non. J'ai seulement répondu à quelqu'un qui, LUI, semble avoir des « problèmes » avec cpp. Et mon expérience, dans ce cas-là, est de chercher à sortir du carcan cpp, plutôt que de se compliquer la vie (qui est l'impression que me donne ses messages).
De plus, et là c'est quand même un argument concret, il y a des chaînes de compilation C pour lesquels cpp n'est pas un programme séparé, ni ne peut être séparé du compilateur C par une option bien choisie (une variation de -E); et là il devient difficile de « jouer » avec cpp pour des utilisations hors contexte de compilation C... (Certes, il est alors possible de prendre un autre préprocesseur, genre celui de GCC ou celui, _nettement_ plus léger, de D. Ritchie si on est gêné par la license GPL).
Je pose cette question parce que j'utilise intensivement cpp pour generer du code dans COS et je n'ai pas vu de probleme majeur, mais je ne pousse pas cpp dans ces limites.
Nous sommes complètement d'accord. Raison pour laquelle j'insiste dans ce fil pour comprendre quel est réellement le _problème_ de "Ludovic", plutôt que de l'aider à faire fonctionner ce qu'il a trouvé comme _solution_.
De son cote, Paul Mensonides va tres loin avec cpp et son probleme est plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou un papier sur ces travaux).
Oui. Mais la logique de P. Mensonides est forcément limitée par le cadre fournie par la norme C ; la quelle ne prévoit pas, par exemple, de passer le préprocesseur deux fois.
Antoine
Laurent Deniau
Antoine Leca wrote:
Laurent Deniau écrivit dans news:ep9v04$1gr$:
Antoine Leca wrote: De son cote, Paul Mensonides va tres loin avec cpp et son probleme est plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou un papier sur ces travaux).
Oui. Mais la logique de P. Mensonides est forcément limitée par le cadre fournie par la norme C ; la quelle ne prévoit pas, par exemple, de passer le préprocesseur deux fois.
Il ne cherche pas a passer deux fois cpp et le cadre de la norme donne deja beaucoup de liberte (c'est d'ailleurs lui qui a formaliser le fonctionnement de cpp a partir de la norme, ce qui permet de mieux guider les implementations). Je suis d'accord avec toi que le probleme de Ludovic est probablement mal formule ou releve d'un autre preprocesseur parceque je n'ai jamais vu de cas necessitant un double passage.
a+, ld.
Antoine Leca wrote:
Laurent Deniau écrivit dans news:ep9v04$1gr$1@cernne03.cern.ch:
Antoine Leca wrote:
De son cote, Paul Mensonides va tres loin avec cpp et son probleme est
plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore
grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou
un papier sur ces travaux).
Oui. Mais la logique de P. Mensonides est forcément limitée par le cadre
fournie par la norme C ; la quelle ne prévoit pas, par exemple, de passer le
préprocesseur deux fois.
Il ne cherche pas a passer deux fois cpp et le cadre de la norme donne
deja beaucoup de liberte (c'est d'ailleurs lui qui a formaliser le
fonctionnement de cpp a partir de la norme, ce qui permet de mieux
guider les implementations). Je suis d'accord avec toi que le probleme
de Ludovic est probablement mal formule ou releve d'un autre
preprocesseur parceque je n'ai jamais vu de cas necessitant un double
passage.
Antoine Leca wrote: De son cote, Paul Mensonides va tres loin avec cpp et son probleme est plutot sur la conformite des cpp existant, qui d'ailleurs s'ameliore grace a ses exemples (j'espere qu'il ecrira prochainement une doc ou un papier sur ces travaux).
Oui. Mais la logique de P. Mensonides est forcément limitée par le cadre fournie par la norme C ; la quelle ne prévoit pas, par exemple, de passer le préprocesseur deux fois.
Il ne cherche pas a passer deux fois cpp et le cadre de la norme donne deja beaucoup de liberte (c'est d'ailleurs lui qui a formaliser le fonctionnement de cpp a partir de la norme, ce qui permet de mieux guider les implementations). Je suis d'accord avec toi que le probleme de Ludovic est probablement mal formule ou releve d'un autre preprocesseur parceque je n'ai jamais vu de cas necessitant un double passage.
