Le but est de centraliser le code source en évitant quelques boucles
(ou plus généralement des tests) mal placées. Il est clair que je
n'utiliserai un truc tordu comme ça uniquement si les performances le
justifient. En revanche, je ne veux pas dupliquer le code source.
En regardant ce que VC8 générait, il m'a semblé constater que sur des
fonctions de cette forme (mais plus complexes):
void func(int* tab, int commutateur)
{
printf("%d\n", tab[0]);
if(commutateur)printf("%d\n", tab[1]);
/* etc. */
}
avec les bonnes options d'optimisation, il pouvait générer deux
fonctions, ou au moins deux blocs avec duplication de certaines parties
du code.
En news:, Jean-Marc Bourguet écrivit: [Re: developpez.com]
Ca c'est ameliore
Oui, c'est ce qui m'a semblé aussi
mais la qualite des reponses est tres variables. Il y a trop de messages et pas assez de personnes qualifiees. Et personne du calibre d'Antoine...
Pourtant il m'a bien semblé avoir glissé quelques messages... :-) il faudrait que je vérifie, je confonds peut-être avec un concurrent... et puis, il est probable que j'aurais plutôt participé sur un sujet que je connais bien, c'est-à-dire le langage Pascal :->
Bon, si on revenait au sujet réel ?
Antoine
En news:pxbtztbsv8y.fsf@news.bourguet.org, Jean-Marc Bourguet écrivit:
[Re: developpez.com]
Ca c'est ameliore
Oui, c'est ce qui m'a semblé aussi
mais la qualite des reponses est tres variables.
Il y a trop de messages et pas assez de personnes qualifiees. Et
personne du calibre d'Antoine...
Pourtant il m'a bien semblé avoir glissé quelques messages... :-) il
faudrait que je vérifie, je confonds peut-être avec un concurrent... et
puis, il est probable que j'aurais plutôt participé sur un sujet que je
connais bien, c'est-à-dire le langage Pascal :->
En news:, Jean-Marc Bourguet écrivit: [Re: developpez.com]
Ca c'est ameliore
Oui, c'est ce qui m'a semblé aussi
mais la qualite des reponses est tres variables. Il y a trop de messages et pas assez de personnes qualifiees. Et personne du calibre d'Antoine...
Pourtant il m'a bien semblé avoir glissé quelques messages... :-) il faudrait que je vérifie, je confonds peut-être avec un concurrent... et puis, il est probable que j'aurais plutôt participé sur un sujet que je connais bien, c'est-à-dire le langage Pascal :->
Bon, si on revenait au sujet réel ?
Antoine
Charlie Gordon
"Pascal Bourguignon" a écrit dans le message de news:
Xavier Roche writes:
et dans la série test d'acuité visuelle : "??/??/??"[3] == '/'/'/'/'*'*'*'
A propos, quelqun sait pourquoi ces machins ont été introduits dans ISO C ? Le clavier du mec qui a fait la spec était baisé et les touches [,],etc. n'étaient plus fonctionnelles ?
??/ =
C'est une question d'encodage.
On peut avoir à travailler avec un terminal ISO-646-FR (une version française d'ASCII), où il n'y a pas de caractère , le code ASCII de étant utilisé pour encoder ç en ISO-646-FR. Dans ce cas, on est content de pouvoir entrer un en saisissant ??/.
On peut aussi avoir à programmer en C sur un ordinateur qui ne travaille pas avec le code ASCII du tout. Par exemple, si on veut programmer en C sur un CDC-3000, on n'a que:
pas d'accolade et pas de minuscules. Alors on est content de pouvoir taper son programme C ainsi:
INT MAIN(INT ARGC,CHAR* ARGV)??< IF((ARGC==1)??!??!(ARGC==2))??< PRINTF("GOOD??/n"); ??>ELSE??< PRINTF("BAD??/n"); ??> ??>
Super content !
Il manque juste l'option magique du compilo qui permet de redefinir les mots-clés en majuscules, et il faudra bien se passer du préprocesseur :-(
Trève de plaisanterie, les pauvres Frenchies qui étaient obligés de programmer en C dans ces conditions 7-bit avaient depuis longtemps pris l'habitude de lire et écrire le C avec des é et des è en place des accolades etc. qna dles trigraphes sont apparus. Ces derniers n'ont jamais eu aucun succès, parce que encore moins lisibles. Et heureusement, ce combat des jeux de caractères a rapidement été repoussé au delà des 7 bits de base grâce à l'IBM PC.
Les trigraphes étaient un mauvaise solution à un problème archaïque... mais les défendeurs acharnés du non-ASCII ont continué le combat et introduit dans C99 une bizarrerie encore moins connue : les digraphes et l'infâme <iso646.h>
Chqrlie.
"Pascal Bourguignon" <pjb@informatimago.com> a écrit dans le message de
news: 877iq6iec8.fsf@thalassa.lan.informatimago.com...
et dans la série test d'acuité visuelle : "??/??/??"[3] ==
'/'/'/'/'*'*'*'
A propos, quelqun sait pourquoi ces machins ont été introduits dans
ISO C ? Le clavier du mec qui a fait la spec était baisé et les
touches [,],etc. n'étaient plus fonctionnelles ?
??/ =
C'est une question d'encodage.
On peut avoir à travailler avec un terminal ISO-646-FR (une version
française d'ASCII), où il n'y a pas de caractère , le code ASCII de
étant utilisé pour encoder ç en ISO-646-FR. Dans ce cas, on est
content de pouvoir entrer un en saisissant ??/.
On peut aussi avoir à programmer en C sur un ordinateur qui ne
travaille pas avec le code ASCII du tout. Par exemple, si on veut
programmer en C sur un CDC-3000, on n'a que:
pas d'accolade et pas de minuscules. Alors on est content de pouvoir
taper son programme C ainsi:
INT MAIN(INT ARGC,CHAR* ARGV)??<
IF((ARGC==1)??!??!(ARGC==2))??<
PRINTF("GOOD??/n");
??>ELSE??<
PRINTF("BAD??/n");
??>
??>
Super content !
Il manque juste l'option magique du compilo qui permet de redefinir les
mots-clés en majuscules, et il faudra bien se passer du préprocesseur :-(
Trève de plaisanterie, les pauvres Frenchies qui étaient obligés de
programmer en C dans ces conditions 7-bit avaient depuis longtemps pris
l'habitude de lire et écrire le C avec des é et des è en place des accolades
etc. qna dles trigraphes sont apparus. Ces derniers n'ont jamais eu aucun
succès, parce que encore moins lisibles. Et heureusement, ce combat des
jeux de caractères a rapidement été repoussé au delà des 7 bits de base
grâce à l'IBM PC.
Les trigraphes étaient un mauvaise solution à un problème archaïque... mais
les défendeurs acharnés du non-ASCII ont continué le combat et introduit
dans C99 une bizarrerie encore moins connue : les digraphes et l'infâme
<iso646.h>
"Pascal Bourguignon" a écrit dans le message de news:
Xavier Roche writes:
et dans la série test d'acuité visuelle : "??/??/??"[3] == '/'/'/'/'*'*'*'
A propos, quelqun sait pourquoi ces machins ont été introduits dans ISO C ? Le clavier du mec qui a fait la spec était baisé et les touches [,],etc. n'étaient plus fonctionnelles ?
??/ =
C'est une question d'encodage.
On peut avoir à travailler avec un terminal ISO-646-FR (une version française d'ASCII), où il n'y a pas de caractère , le code ASCII de étant utilisé pour encoder ç en ISO-646-FR. Dans ce cas, on est content de pouvoir entrer un en saisissant ??/.
On peut aussi avoir à programmer en C sur un ordinateur qui ne travaille pas avec le code ASCII du tout. Par exemple, si on veut programmer en C sur un CDC-3000, on n'a que:
pas d'accolade et pas de minuscules. Alors on est content de pouvoir taper son programme C ainsi:
INT MAIN(INT ARGC,CHAR* ARGV)??< IF((ARGC==1)??!??!(ARGC==2))??< PRINTF("GOOD??/n"); ??>ELSE??< PRINTF("BAD??/n"); ??> ??>
Super content !
Il manque juste l'option magique du compilo qui permet de redefinir les mots-clés en majuscules, et il faudra bien se passer du préprocesseur :-(
Trève de plaisanterie, les pauvres Frenchies qui étaient obligés de programmer en C dans ces conditions 7-bit avaient depuis longtemps pris l'habitude de lire et écrire le C avec des é et des è en place des accolades etc. qna dles trigraphes sont apparus. Ces derniers n'ont jamais eu aucun succès, parce que encore moins lisibles. Et heureusement, ce combat des jeux de caractères a rapidement été repoussé au delà des 7 bits de base grâce à l'IBM PC.
Les trigraphes étaient un mauvaise solution à un problème archaïque... mais les défendeurs acharnés du non-ASCII ont continué le combat et introduit dans C99 une bizarrerie encore moins connue : les digraphes et l'infâme <iso646.h>
Chqrlie.
Marc Boyer
Le 15-06-2007, Pierre Maurette a écrit :
[...]
Quitte à dérouler des boucles à la main, je le ferais plutot avec le préprocesseur.
On peut aussi générer les identifiant, avec # et ##.
J'ai un peu regardé de ce coté.
Je suis tombé sur ce lien: <URL:http://www.thescripts.com/forum/thread213073.html> et il m'a semblé reconnaitre du code très pratique que j'avais récupéré de Emmanuel Delahaye, pour au départ printer une série de sizeof(type). Quand j'ai regardé les signatures, j'ai compris ;-)
Voui.
J'ai aussi essayé en Python. Je pensais que ce serait très simple. Ce n'est pas compliqué, mais ça demande quand même un minimum d'analyse si on ne veut pas trop de contraintes sur l'écriture du code. Ou alors il faut être Regex langue maternelle.
Python, awk, m4... Je pense que ce sera de toute façon plus simple qu'avec le préprocesseur.
Je considère que même si un compilateur donné ne génère pas plusieurs fois le code quand on lui passe une valeur en paramètre, il est au moins capable de faire au mieux (dérouler la boucle si c'est bien) quand il traite un for(;;) à bornes constantes.
J'ai renoncé à automatiser la boucle sur la valeur de PETRUS. C'est je pense faisable mais très galère.
Pour les études sur le préprocesseur, le lien de Jean-Marc me semble une bonne idée. Mais, si c'est possible, je préfère pour ma part utiliser des moulinettes autres que cpp.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 15-06-2007, Pierre Maurette <maurettepierre@wanadoo.fr> a écrit :
[...]
Quitte à dérouler des boucles à la main, je le ferais plutot avec
le préprocesseur.
On peut aussi générer les identifiant, avec # et ##.
J'ai un peu regardé de ce coté.
Je suis tombé sur ce lien:
<URL:http://www.thescripts.com/forum/thread213073.html>
et il m'a semblé reconnaitre du code très pratique que j'avais récupéré
de Emmanuel Delahaye, pour au départ printer une série de sizeof(type).
Quand j'ai regardé les signatures, j'ai compris ;-)
Voui.
J'ai aussi essayé en Python. Je pensais que ce serait très simple. Ce
n'est pas compliqué, mais ça demande quand même un minimum d'analyse si
on ne veut pas trop de contraintes sur l'écriture du code. Ou alors il
faut être Regex langue maternelle.
Python, awk, m4...
Je pense que ce sera de toute façon plus simple qu'avec le
préprocesseur.
Je considère que même si un compilateur donné ne génère pas plusieurs
fois le code quand on lui passe une valeur en paramètre, il est au
moins capable de faire au mieux (dérouler la boucle si c'est bien)
quand il traite un for(;;) à bornes constantes.
J'ai renoncé à automatiser la boucle sur la valeur de PETRUS. C'est je
pense faisable mais très galère.
Pour les études sur le préprocesseur, le lien de Jean-Marc me semble
une bonne idée.
Mais, si c'est possible, je préfère pour ma part utiliser des
moulinettes autres que cpp.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Quitte à dérouler des boucles à la main, je le ferais plutot avec le préprocesseur.
On peut aussi générer les identifiant, avec # et ##.
J'ai un peu regardé de ce coté.
Je suis tombé sur ce lien: <URL:http://www.thescripts.com/forum/thread213073.html> et il m'a semblé reconnaitre du code très pratique que j'avais récupéré de Emmanuel Delahaye, pour au départ printer une série de sizeof(type). Quand j'ai regardé les signatures, j'ai compris ;-)
Voui.
J'ai aussi essayé en Python. Je pensais que ce serait très simple. Ce n'est pas compliqué, mais ça demande quand même un minimum d'analyse si on ne veut pas trop de contraintes sur l'écriture du code. Ou alors il faut être Regex langue maternelle.
Python, awk, m4... Je pense que ce sera de toute façon plus simple qu'avec le préprocesseur.
Je considère que même si un compilateur donné ne génère pas plusieurs fois le code quand on lui passe une valeur en paramètre, il est au moins capable de faire au mieux (dérouler la boucle si c'est bien) quand il traite un for(;;) à bornes constantes.
J'ai renoncé à automatiser la boucle sur la valeur de PETRUS. C'est je pense faisable mais très galère.
Pour les études sur le préprocesseur, le lien de Jean-Marc me semble une bonne idée. Mais, si c'est possible, je préfère pour ma part utiliser des moulinettes autres que cpp.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Gabriel Dos Reis
Harpo writes:
| On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote: | | > Mais, si c'est possible, je préfère pour ma part utiliser des | > moulinettes autres que cpp. | | Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur | puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
-- Gaby
Harpo <invalid@invalid.invalid> writes:
| On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
|
| > Mais, si c'est possible, je préfère pour ma part utiliser des
| > moulinettes autres que cpp.
|
| Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur
| puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
| On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote: | | > Mais, si c'est possible, je préfère pour ma part utiliser des | > moulinettes autres que cpp. | | Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur | puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
-- Gaby
Gabriel Dos Reis
Pascal Bourguignon writes:
| Harpo writes: | | > On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote: | > | >> Mais, si c'est possible, je préfère pour ma part utiliser des | >> moulinettes autres que cpp. | > | > Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur | > puissant pour le C ? | | En tout cas, ça donne des résultats: C++, Objective-C sont écrit (au | moins à l'origine) comme un pré-processeur puissant pour le C.
Je presume que cela depend de la definition qu'on donne a "pre-processeur".
| Harpo <invalid@invalid.invalid> writes:
|
| > On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
| >
| >> Mais, si c'est possible, je préfère pour ma part utiliser des
| >> moulinettes autres que cpp.
| >
| > Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur
| > puissant pour le C ?
|
| En tout cas, ça donne des résultats: C++, Objective-C sont écrit (au
| moins à l'origine) comme un pré-processeur puissant pour le C.
Je presume que cela depend de la definition qu'on donne a "pre-processeur".
| Harpo writes: | | > On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote: | > | >> Mais, si c'est possible, je préfère pour ma part utiliser des | >> moulinettes autres que cpp. | > | > Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur | > puissant pour le C ? | | En tout cas, ça donne des résultats: C++, Objective-C sont écrit (au | moins à l'origine) comme un pré-processeur puissant pour le C.
Je presume que cela depend de la definition qu'on donne a "pre-processeur".
-- Gaby
Pierre Maurette
Harpo writes:
On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
Mais, si c'est possible, je préfère pour ma part utiliser des moulinettes autres que cpp.
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
Et le B ?
Louis I Louis II Louis III Louis IV Louis V Louis VI Louis VII Louis VIII Louis IX Louis X (dit le Hutin) (1) Louis XI Louis XII Louis XIII Louis XIV Louis XV Louis XVI Louis XVII Louis XVIII et plus personne plus rien... qu'est-ce que c'est que ces gens-là qui ne sont pas foutus de compter jusqu'à vingt ?
(Prévert, bien sûr...)
-- Pierre Maurette
Harpo <invalid@invalid.invalid> writes:
On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
Mais, si c'est possible, je préfère pour ma part utiliser des
moulinettes autres que cpp.
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur
puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
Et le B ?
Louis I
Louis II
Louis III
Louis IV
Louis V
Louis VI
Louis VII
Louis VIII
Louis IX
Louis X (dit le Hutin) (1)
Louis XI
Louis XII
Louis XIII
Louis XIV
Louis XV
Louis XVI
Louis XVII
Louis XVIII
et plus personne plus rien...
qu'est-ce que c'est que ces gens-là
qui ne sont pas foutus
de compter jusqu'à vingt ?
On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
Mais, si c'est possible, je préfère pour ma part utiliser des moulinettes autres que cpp.
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
Et le B ?
Louis I Louis II Louis III Louis IV Louis V Louis VI Louis VII Louis VIII Louis IX Louis X (dit le Hutin) (1) Louis XI Louis XII Louis XIII Louis XIV Louis XV Louis XVI Louis XVII Louis XVIII et plus personne plus rien... qu'est-ce que c'est que ces gens-là qui ne sont pas foutus de compter jusqu'à vingt ?
C'est AMHA la meilleure solution. Moi je génère du code C à partir d'un script Perl. Et vu que j'étais partir de ce côté-là, le script s'occupe également de lancer gcc une fois avec -fprofile-generate, d'exécuter le code sur des données partielles et de recompiler avec -fprofile-use. Résultat: sur Opteron, un gain allant de quelques % à 22% environ.
C'est AMHA la meilleure solution. Moi je génère du code C à partir
d'un script Perl. Et vu que j'étais partir de ce côté-là, le script
s'occupe également de lancer gcc une fois avec -fprofile-generate,
d'exécuter le code sur des données partielles et de recompiler avec
-fprofile-use. Résultat: sur Opteron, un gain allant de quelques %
à 22% environ.
C'est AMHA la meilleure solution. Moi je génère du code C à partir d'un script Perl. Et vu que j'étais partir de ce côté-là, le script s'occupe également de lancer gcc une fois avec -fprofile-generate, d'exécuter le code sur des données partielles et de recompiler avec -fprofile-use. Résultat: sur Opteron, un gain allant de quelques % à 22% environ.
On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
Mais, si c'est possible, je préfère pour ma part utiliser des moulinettes autres que cpp.
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur puissant pour le C ?
En tout cas, ça donne des résultats: C++, Objective-C sont écrit (au moins à l'origine) comme un pré-processeur puissant pour le C.
Personnellement, plutôt que de générer le C à partir d'un script perl, je préfère le générer à partir de code Common Lisp, comme le fait gcl, ecl ou clicc.
Donc, pour répondre à ta question: non. C est un langage pourri (pour la plupart de ses applications), et dès qu'on le peut on préfère écrire dans un autre langage de programmation, donc ça n'est probablement pas intéressant d'écrire un pré-processeur, mieux vaut écrire un compilateur pour un vrai langage de haut niveau. ;-)
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Harpo <invalid@invalid.invalid> writes:
On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
Mais, si c'est possible, je préfère pour ma part utiliser des
moulinettes autres que cpp.
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur
puissant pour le C ?
En tout cas, ça donne des résultats: C++, Objective-C sont écrit (au
moins à l'origine) comme un pré-processeur puissant pour le C.
Personnellement, plutôt que de générer le C à partir d'un script perl,
je préfère le générer à partir de code Common Lisp, comme le fait gcl,
ecl ou clicc.
Donc, pour répondre à ta question: non. C est un langage pourri
(pour la plupart de ses applications), et dès qu'on le peut on préfère
écrire dans un autre langage de programmation, donc ça n'est
probablement pas intéressant d'écrire un pré-processeur, mieux vaut
écrire un compilateur pour un vrai langage de haut niveau. ;-)
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Tue, 19 Jun 2007 11:44:44 +0000, Marc Boyer wrote:
Mais, si c'est possible, je préfère pour ma part utiliser des moulinettes autres que cpp.
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur puissant pour le C ?
En tout cas, ça donne des résultats: C++, Objective-C sont écrit (au moins à l'origine) comme un pré-processeur puissant pour le C.
Personnellement, plutôt que de générer le C à partir d'un script perl, je préfère le générer à partir de code Common Lisp, comme le fait gcl, ecl ou clicc.
Donc, pour répondre à ta question: non. C est un langage pourri (pour la plupart de ses applications), et dès qu'on le peut on préfère écrire dans un autre langage de programmation, donc ça n'est probablement pas intéressant d'écrire un pré-processeur, mieux vaut écrire un compilateur pour un vrai langage de haut niveau. ;-)
NOTE: The most fundamental particles in this product are held together by a "gluing" force about which little is currently known and whose adhesive power can therefore not be permanently guaranteed.
Pierre Maurette
On Tue, 19 Jun 2007 16:22:38 +0200, Gabriel Dos Reis wrote:
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
Utiliser m4 est une solution, mais c'est un macro-langage généraliste peut-être assez compliqué à utiliser et les sources pourrait etre moins lisibles que lorsque l'on emploie cpp. Je pensais à quelque chose comme cpp mais avec des variables du macro-processeur globales ou locales à une macro et la possibiliter d'itérer et/ou de récurser dans une macro.
Un truc comme le préprocesseur de MASM ?
-- Pierre Maurette
On Tue, 19 Jun 2007 16:22:38 +0200, Gabriel Dos Reis wrote:
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur
puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
Utiliser m4 est une solution, mais c'est un macro-langage généraliste
peut-être assez compliqué à utiliser et les sources pourrait etre moins
lisibles que lorsque l'on emploie cpp.
Je pensais à quelque chose comme cpp mais avec des variables du
macro-processeur globales ou locales à une macro et la possibiliter
d'itérer et/ou de récurser dans une macro.
On Tue, 19 Jun 2007 16:22:38 +0200, Gabriel Dos Reis wrote:
Pensez-vous que ce puisse être intéressant d'écrire un pré-processeur puissant pour le C ?
Je ne sais pas. Mais les inventeurs du C ont invente m4.
Utiliser m4 est une solution, mais c'est un macro-langage généraliste peut-être assez compliqué à utiliser et les sources pourrait etre moins lisibles que lorsque l'on emploie cpp. Je pensais à quelque chose comme cpp mais avec des variables du macro-processeur globales ou locales à une macro et la possibiliter d'itérer et/ou de récurser dans une macro.
Un truc comme le préprocesseur de MASM ?
-- Pierre Maurette
Gabriel Dos Reis
"Antoine Leca" writes:
[...]
| Mais ce ne fut pas un succès, car : | - le problème avait essentiellement disparu avec l'abandon des terminaux | causant 7 bits seulement | - certains problèmes comme celui du ! EBCDIC ou du <5B> nippon restaient | entiers | - le système imposait (et impose toujours) un supplément de complexité dans | TOUS les analyseurs syntaxiques de langage C/C++ (surtout avec % qui demande | potentiellement un lookahead de 4 caractères pour ## devenu %:%:), et encore | aujourd'hui ce n'est pas le plus courant (taper donc %: au début d'une | ligne, et regarder si votre coloriseur syntaxique passe automatiquement en | mode « directive du préprocesseur...)
Et maintenant, on a le probleme de "<:" qui veut dire "[", en C++:
#include <vector>
struct S { int x; };
int main() { std::list<::S> ls; // hahaha - good try }
-- Gaby
"Antoine Leca" <root@localhost.invalid> writes:
[...]
| Mais ce ne fut pas un succès, car :
| - le problème avait essentiellement disparu avec l'abandon des terminaux
| causant 7 bits seulement
| - certains problèmes comme celui du ! EBCDIC ou du <5B> nippon restaient
| entiers
| - le système imposait (et impose toujours) un supplément de complexité dans
| TOUS les analyseurs syntaxiques de langage C/C++ (surtout avec % qui demande
| potentiellement un lookahead de 4 caractères pour ## devenu %:%:), et encore
| aujourd'hui ce n'est pas le plus courant (taper donc %: au début d'une
| ligne, et regarder si votre coloriseur syntaxique passe automatiquement en
| mode « directive du préprocesseur...)
Et maintenant, on a le probleme de "<:" qui veut dire "[", en C++:
#include <vector>
struct S {
int x;
};
int main() {
std::list<::S> ls; // hahaha - good try
}
| Mais ce ne fut pas un succès, car : | - le problème avait essentiellement disparu avec l'abandon des terminaux | causant 7 bits seulement | - certains problèmes comme celui du ! EBCDIC ou du <5B> nippon restaient | entiers | - le système imposait (et impose toujours) un supplément de complexité dans | TOUS les analyseurs syntaxiques de langage C/C++ (surtout avec % qui demande | potentiellement un lookahead de 4 caractères pour ## devenu %:%:), et encore | aujourd'hui ce n'est pas le plus courant (taper donc %: au début d'une | ligne, et regarder si votre coloriseur syntaxique passe automatiquement en | mode « directive du préprocesseur...)
Et maintenant, on a le probleme de "<:" qui veut dire "[", en C++:
#include <vector>
struct S { int x; };
int main() { std::list<::S> ls; // hahaha - good try }
