Pb à l'intérieur d'une fonction - Page 14

nitro
:

Kevin Kofler
: Je ne suis pas d'accord! Les standards ISO ne sont pas là pour que M$ fasse ce qu'ils veulent!

Pourtant les développeurs de GCC ne se sont pas gené pour rajouter leurs extensions au standard C...

Certes, mais eux ils s'en fichent toujours du caractère non-standard des MFC, ils le font même exprès pour empêcher à leurs concurrents de les utiliser avec leurs compilateurs.

Bien sûr tu as des preuves concretes pour accuser de la sorte.

C'est quoi l'interet d'un OS comme MenuetOS sur lequel on ne peut utiliser aucun logiciel existant ?

Sur BeOS non plus...
AtheOS est quand-même à peu près compatible avec POSIX, mais BeOS carrément pas.

Pourtant sur les 3000 fichiers de BeBits.com, une grande partie sont des portages de logiciels existant sur d'autres plateformes... me demande bien comment ils font

Reviens quand tu auras mis BeOS sur une disquette et quand elle sera toujours à moitié vide.

Chose vachement utile de nos jours...
Même les consoles et téléphones portables, et les PDA sont suffisamment équippés pour faire du Java et du C++ (cf. SymbianOS). On pourrait penser que pour faire des perfs sur ces plateformes on est obligé de passer par de l'assembleur. Eh bien même pas... les gourous de flipcode eux-mêmes font leur moteur 3D en C++ pour les telephones portables.

Et puis écrire un assembleur ça fait beaucoup plus de lignes de code, et c'est un enfer à maintenir, sans parler du fait que ça ne tourne que sur une seule plateforme.

C'est pour ça que le C (pas le C++) existe.

Ok alors maintenant transpose un niveau plus haut. C'est parce que les gros logiciels en C sont impossibles à maintenir que le C++ existe.

1ere constatation : gcc produit exactement le même code pour les deux.

Pas toujours. Regarde un peu dans Bugzilla, il y a pas mal de problèmes avec les templates.

- dans ce cas, ça produit exactement le même code (j'ai testé) ;
- ce n'est pas parce qu'une implémentation de compilateur est buggée que le langage est mauvais.

2eme constatation : la version template est plus lisible (donc plus facile à maintenir), car c'est une fonction C++ normale, pas besoin d'extension GNU, de variables avec des underscores (qui vont collisionner en plus si on appelle min(_a, x)), et pas de parenthèses superflues autour des paramètres.

C'est subjectif. Pour moi, la macro est au moins aussi claire que le template. Et même pour le compilateur, les macros sont plus "lisibles" (faciles à parser), les templates causent plein de conflits de parsing.

Subjectif ? Clairement j'ai cité les raisons pour lesquelles la macro est moins lisible. De plus la collision elle, n'est pas subjective. Et enfin, côté compilateur ça marche suffisamment bien pour être utilisé dans tout plein de projets, dont la STL.

3eme constatation : la version template bénéficie d'un des avantages du typage, à savoir un message d'erreur clair en cas d'erreur de typage.
- version template : "error: no matching function for call to `min(st&, int)'" où il y a clairement la fonction et les types impliqués ;

Message d'erreur chinois typique du C++.

Tu le fais franchement exprès... ou alors on n'a pas la même définition de chinois. Traduit tout bêtement en français ça dit "aucune fonction correspondant à l'appel de la fonction min avec deux arguments de type st& et int". C'est une description exacte et précise du problème.

- version macro : "error: invalid operands to binary <" alors que sur la ligne concernée il n'y a même pas de '<'.

Très clair comme erreur. Comparaisons entre 2 types incompatibles, donc opérandes invalides pour un opérateur de comparaison. Là, je sais tout de suite ce qui ne va pas.

Sauf qu'il n'y a pas d'opérateur de comparaison "<" sur la ligne. L'erreur décrit ce qu'il y a après expansion de la macro. L'utilisateur lui, utilise la syntaxe d'un appel de fonction, donc il s'attend à retrouver la sémantique de l'appel de fonction, et ce n'est absolument pas le cas. Bien souvent il ne connait même pas le contenu de la macro.
Pire encore, imagine qu'on ai : return min(a, 5) < 4; Pour peu que les éléments soient un peu plus compliqués, voir cachés dans d'autres macros, le message d'erreur parle d'un opérateur '<', et il y en a effectivement un sur la ligne. Mais pas de chance c'est pas de celui-là dont on parle.
Donc non, tu ne me fera pas croire que ce message d'erreur est mieux que le précédent. Désolé.

4eme constatation : la version template bénéficie d'un avantage que la version macro ne peut pas faire, c'est la spécialisation en fonction du type de données. Effectivement, si dans mon programme j'utilise des types de données particuliers dont la fonction min peut être codée de manière beaucoup plus efficace (par exemple les entiers de l'intervale [0,1])

Euh, il n'y en a pas beaucoup là.

J'ai pris un exemple simple pour que tout le monde voit bien de quelle optimisation je parle

#define min(a,b) ({ typeof (a) _a = (a); typeof (b) _b = (b); (__builtin_types_compatible_p(typeof(_a),mastruct) && __builtin_types_compatible_p(typeof(_b),mastruct))? (_a.value && _b.value) : (_a < _b ? _a : _b;) })

Tu trouves ça lisible par rapport à ma spécialisation ? En plus là les deux doivent être définis au même endroit. Ce n'est pas le cas dans mon exemple.

Je posterai un exemple de ld-tigcc quand je serai de retour chez moi. Non seulement, les macros sont utilisées comme des templates et ça marche très bien, mais on fait aussi du Item ## s pour construire un pluriel. Bonne chance pour faire ça avec un template.

Construire le pluriel d'un identifiant c'est ce qu'on appelle du bidouillage
Et le nombre de choses qu'on peut faire avec des templates est bien supérieur à ce qu'on peut faire avec les macros, car le meta-langage des templates est turing complete. cf C++ Templates and Turing Completeness.

Certains peepholes sont mieux exécutés tout à la fin, donc en define_peephole.

Tu ne va pas me faire croire qu'il vaut mieux executer un peephole une seule fois plutôt que plusieurs fois itérativement jusqu'à ce que le code converge...

Je trouve vraiment dommage que la discussion se soit arrêtée là, c'était intéressant !

nitro
:

Kevin Kofler
:Certes, mais eux ils s'en fichent toujours du caractère non-standard des MFC, ils le font même exprès pour empêcher à leurs concurrents de les utiliser avec leurs compilateurs.

Bien sûr tu as des preuves concretes pour accuser de la sorte.

Va voir leurs EULAs récents pour MFC et compagnie si tu veux savoir ce qu'ils pensent des compilateurs concurrents.

C'est quoi l'interet d'un OS comme MenuetOS sur lequel on ne peut utiliser aucun logiciel existant ?

Sur BeOS non plus...
AtheOS est quand-même à peu près compatible avec POSIX, mais BeOS carrément pas.

Pourtant sur les 3000 fichiers de BeBits.com, une grande partie sont des portages de logiciels existant sur d'autres plateformes... me demande bien comment ils font

Bon, je viens de vérifier et en effet il y a une librairie de compatibilité POSIX livrée avec BeOS.
Mais l'existence ou non d'une librairie de compatibilité POSIX n'a pas grand chose à voir avec le langage de programmation utilisé pour coder le système d'exploitation.

Reviens quand tu auras mis BeOS sur une disquette et quand elle sera toujours à moitié vide.

Chose vachement utile de nos jours...

Ben oui, c'est utile si un OS prend moins de place! Les disques durs ne sont pas gratuits!

Même les consoles et téléphones portables, et les PDA sont suffisamment équippés pour faire du Java et du C++ (cf. SymbianOS). On pourrait penser que pour faire des perfs sur ces plateformes on est obligé de passer par de l'assembleur. Eh bien même pas... les gourous de flipcode eux-mêmes font leur moteur 3D en C++ pour les telephones portables.

Bonjour la lenteur...

Et puis écrire un assembleur ça fait beaucoup plus de lignes de code, et c'est un enfer à maintenir, sans parler du fait que ça ne tourne que sur une seule plateforme.

C'est pour ça que le C (pas le C++) existe.

Ok alors maintenant transpose un niveau plus haut. C'est parce que les gros logiciels en C sont impossibles à maintenir que le C++ existe.

Impossibles à maintenir? Linux, GCC etc., tout ça c'est impossible à maintenir??? Je vois le contraire, moi...

- ce n'est pas parce qu'une implémentation de compilateur est buggée que le langage est mauvais.

Un langage difficilement réalisable en un compilateur est un langage excessivement complexe, donc mal conçu.

2eme constatation : la version template est plus lisible (donc plus facile à maintenir), car c'est une fonction C++ normale, pas besoin d'extension GNU, de variables avec des underscores (qui vont collisionner en plus si on appelle min(_a, x)), et pas de parenthèses superflues autour des paramètres.

C'est subjectif. Pour moi, la macro est au moins aussi claire que le template. Et même pour le compilateur, les macros sont plus "lisibles" (faciles à parser), les templates causent plein de conflits de parsing.

Subjectif ? Clairement j'ai cité les raisons pour lesquelles la macro est moins lisible.

Ben, tes raisons ne me convainquent pas:

>c'est une fonction C++ normale
Ça ne veut pas dire que c'est plus lisible.

>pas besoin d'extension GNU
Ça non plus.

>de variables avec des underscores
Ça non plus.

>parenthèses superflues autour des paramètres
Bon, ça, ça peut devenir un peu lourd en effet, mais on s'y habitue.

De plus la collision elle, n'est pas subjective.

Elle n'existe pas. L'utilisation de noms de variables commençant par un underscore est interdite aux programmes utilisateur, en C comme en C++.

Et enfin, côté compilateur ça marche suffisamment bien pour être utilisé dans tout plein de projets, dont la STL.

Ça ne veut pas dire que ça marche mieux que les macros.

3eme constatation : la version template bénéficie d'un des avantages du typage, à savoir un message d'erreur clair en cas d'erreur de typage.
- version template : "error: no matching function for call to `min(st&, int)'" où il y a clairement la fonction et les types impliqués ;

Message d'erreur chinois typique du C++.

Tu le fais franchement exprès... ou alors on n'a pas la même définition de chinois. Traduit tout bêtement en français ça dit "aucune fonction correspondant à l'appel de la fonction min avec deux arguments de type st& et int". C'est une description exacte et précise du problème.

Ce n'est pas exact et précis. Le problème est que les types à gauche et à droite ne sont pas comparables, le message d'erreur n'en dit rien. "error: invalid operands to binary <" dit clairement qu'il y a des opérandes incomparables.

Sauf qu'il n'y a pas d'opérateur de comparaison "<" sur la ligne. L'erreur décrit ce qu'il y a après expansion de la macro. L'utilisateur lui, utilise la syntaxe d'un appel de fonction, donc il s'attend à retrouver la sémantique de l'appel de fonction, et ce n'est absolument pas le cas. Bien souvent il ne connait même pas le contenu de la macro.

Dans cet exemple, c'est clair (évidemment qu'il y a une comparaison dans min!), mais en cas de doûte: gcc -E.

Pire encore, imagine qu'on ai : return min(a, 5) < 4; Pour peu que les éléments soient un peu plus compliqués, voir cachés dans d'autres macros, le message d'erreur parle d'un opérateur '<', et il y en a effectivement un sur la ligne. Mais pas de chance c'est pas de celui-là dont on parle.

Les développeurs de GCC comptent donner les colonnes des erreurs, ce qui résoudra ce problème.

#define min(a,b) ({ typeof (a) _a = (a); typeof (b) _b = (b); (__builtin_types_compatible_p(typeof(_a),mastruct) && __builtin_types_compatible_p(typeof(_b),mastruct))? (_a.value && _b.value) : (_a < _b ? _a : _b;) })

Tu trouves ça lisible par rapport à ma spécialisation ?

Euh... Pas spécialement.
Mais ça montre bien que c'est possible.

En plus là les deux doivent être définis au même endroit. Ce n'est pas le cas dans mon exemple.

Pas nécessairement:
* librairie système:
#define _min(__a,__b) ({ typeof (__a) _a = (__a); typeof (__b) _b = (__b); (_a < _b ? _a : _b;) })
#define min _min
* librairie supplémentaire:
#define libtoto_min(a__,b__) ({ typeof (a__) a_ = (a__); typeof (b__) b_ = (b__); (__builtin_types_compatible_p(typeof(a_),mastruct) && __builtin_types_compatible_p(typeof(b_),mastruct))? (a_.value && b_.value) : (_min(a_,b_)) })
#undef min
#define min libtoto_min
Et le programme utilisateur peut encore étendre min en s'appuyant sur libtoto_min.

Je posterai un exemple de ld-tigcc quand je serai de retour chez moi. Non seulement, les macros sont utilisées comme des templates et ça marche très bien, mais on fait aussi du Item ## s pour construire un pluriel. Bonne chance pour faire ça avec un template.

Construire le pluriel d'un identifiant c'est ce qu'on appelle du bidouillage

Comment veux-tu faire autrement? (cf. ./383)

Et le nombre de choses qu'on peut faire avec des templates est bien supérieur à ce qu'on peut faire avec les macros, car le meta-langage des templates est turing complete. cf C++ Templates and Turing Completeness.

D'un côté oui. De l'autre côté, les macros permettent de travailler sur les tokens (par exemple Item ## s ), les templates ne le permettent pas. Donc chacun permet quelque chose que l'autre ne permet pas.

Certains peepholes sont mieux exécutés tout à la fin, donc en define_peephole.

Tu ne va pas me faire croire qu'il vaut mieux executer un peephole une seule fois plutôt que plusieurs fois itérativement jusqu'à ce que le code converge...

Si l'exécution répétée n'apporte rien (et il y a souvent des peepholes où c'est le cas), les exécuter une fois suffit. Et je reste sur ma position que define_peephole a toujours son sens de par son endroit d'exécution, après scheduler etc. Lis les archives de la mailing list de GCC plus attentivement.

Pas nécessairement:
* librairie système:
#define _min(__a,__b) ({ typeof (__a) _a = (__a); typeof (__b) _b = (__b); (_a < _b ? _a : _b;) })
#define min _min
* librairie supplémentaire:
#define libtoto_min(a___,b___) ({ typeof (a__) a_ = (a__); typeof (b__) b_ = (b__); (__builtin_types_compatible_p(typeof(a_),mastruct) && __builtin_types_compatible_p(typeof(b_),mastruct))? (a_.value && b_.value) : (_min(a_,b_)) })
#undef min
#define min libtoto_min
Et le programme utilisateur peut encore étendre min en s'appuyant sur libtoto_min. 

J'adore les extensions GNU et le preprocesseur.
Dommage qu'on puisse pas redefenir des variables a l'interieur d'une macro.
Sinon qu'est ce qu'on s'amuserait

PS: Kevin, il existe des branches ou le C++ / Java sont decries, ou les mecs sont des dieux en info et en math, et ou ils connaissent pas Windows, mais seulement GNU/Linux et les standards. Mais ils sont pas tres assembleur. Forcement ils compilent pour x86, itanium, alpha, powerpc, arm, dec, sparc, etc. Ils programment en langage tres haut niveau, sauf lorsqu'ils veulent des perfs. Alors ils utilisent le C. Donc tu vois, tu peux trouver un endroit qui te conviennent.

Je croyais que Kevin détestait les langages de haut niveau ??

Ben non. Il aime bien le Ti-Basic. Je rappelle que C++ et Java c'est du moyen de gamme au passage.

Ouep, puis il aime aussi VB ... (c limite une insulte ça )

J'ai pratiquement laissé tomber le VB depuis longtemps (si tu regardes Tokens89, un de mes derniers projets en VB, tu verras que je l'ai commencé en 2000; je n'aurais jamais choisi le VB si je l'avais commencé cette année). Raisons principales:
* !"§$%&/()=? de fichiers runtime qui sont tellement gros qu'ils ne tiennent même pas sur une disquette à l'état compressé
* programmes trop gros (32 KO (+ runtime, évidemment) pour un programme totalement vide)
* programmes trop lents
Dommage parce que le langage n'est pas si mal que ça. (Mais il a des défauts, par exemple le manque de types non signés.)

Bref, vive le C et MinGW pour la programmation Window$.

Personnellement je n'ai plus programmé en basic depuis le CPC 6128 (hum, ce n'est peut-être pas tout à fait vrai, j'ai dû y toucher un tout petit peu sur mon Atari STE aussi, mais pas beaucoup )

Kevin Kofler
:Va voir leurs EULAs récents pour MFC et compagnie si tu veux savoir ce qu'ils pensent des compilateurs concurrents.

Moi tout ce que je vois c'est qu'ils integrent des extensions à leur compilateur, tout comme GCC.
De plus Visual C++ 7 est tout aussi standard que G++. Il est capable de compiler Boost et Blitz++, qui sont des references en terme de programmation C++ avancée.
En passant, Blitz++ (lib de arrays/vectors/matrices) atteint des perfs similaires à Fortran, qui est le langage le plus rapide en calcul scientifique.

Bon, je viens de vérifier et en effet il y a une librairie de compatibilité POSIX livrée avec BeOS.Mais l'existence ou non d'une librairie de compatibilité POSIX n'a pas grand chose à voir avec le langage de programmation utilisé pour coder le système d'exploitation.

Ce que je veux dire c'est que coder un système d'exploitation en assembleur ce n'est pas réaliste. BeOS est très bien conçu, très rapide, et en C++. Donc on peut faire un très bon système d'exploitation en C++, ce n'est pas reservé qu'au C.

Ben oui, c'est utile si un OS prend moins de place! Les disques durs ne sont pas gratuits!

Entre un OS sur une disquette qui supporte 0 application, et un OS sur CD qui supporte des milliers d'applications, le choix est vite fait.
Et en ce qui concerne la place, Symbian OS sur téléphones portables est en C++, avec toutes les apps en C++/Java et ça tourne plutôt bien.

les gourous de flipcode eux-mêmes font leur moteur 3D en C++ pour les telephones portables.

Bonjour la lenteur...

Tu parles de quelque chose que tu ne connais pas. Les jeux tournent très bien, et sont bien rapides.

Impossibles à maintenir? Linux, GCC etc., tout ça c'est impossible à maintenir??? Je vois le contraire, moi...

On a deja dit que justement GCC est le pire exemple. Et Linux n'est pas très gros, la plus grande partie du code source ce sont les drivers.

Un langage difficilement réalisable en un compilateur est un langage excessivement complexe, donc mal conçu.

En l'occurance le compilateur ici est utilisé pour réaliser des applications géantes (KDE, Mozilla), et performantes (Blitz++, Boost), alors il me semble qu'il ne s'en tire pas si mal que ça.

Subjectif ? Clairement j'ai cité les raisons pour lesquelles la macro est moins lisible.

Ben, tes raisons ne me convainquent pas:

Ah, pourtant un peu plus loin, tu me réponds :

Tu trouves ça lisible par rapport à ma spécialisation ?

Euh... Pas spécialement.

Alors il faudrait savoir.

De plus la collision elle, n'est pas subjective.

Elle n'existe pas. L'utilisation de noms de variables commençant par un underscore est interdite aux programmes utilisateur, en C comme en C++.

Ah bon, pourtant tu en as mis dans tes macros.
Et pourquoi est-ce que dans ton exemple de spécialisation tu as :

#define _min(__a,__b) ...
#define libtoto_min(a__,b__) ...

Pourquoi pas __a et __b partout ?

Ce n'est pas exact et précis. Le problème est que les types à gauche et à droite ne sont pas comparables, le message d'erreur n'en dit rien. "error: invalid operands to binary <" dit clairement qu'il y a des opérandes incomparables.

Arrête de faire semblant de ne pas comprendre. Min passe encore, mais dans le cas d'une macro plus compliquée à laquelle le programmeur n'a pas accès, le message d'erreur ne veut absolument rien dire puisqu'il indique une ligne sur laquelle il y a du code différent de ce qu'a vu le compilateur.

Les développeurs de GCC comptent donner les colonnes des erreurs, ce qui résoudra ce problème.

Ca ne résoud rien du tout, car il suffit d'une seule macro sur une ligne pour invalider tous les numeros des colonnes suivantes.

Construire le pluriel d'un identifiant c'est ce qu'on appelle du bidouillage

Comment veux-tu faire autrement? (cf. ./383)

Très franchement je n'ai pas cherché à comprendre ton code car je le trouve complètement illisible.

D'un côté oui. De l'autre côté, les macros permettent de travailler sur les tokens (par exemple Item ## s ), les templates ne le permettent pas. Donc chacun permet quelque chose que l'autre ne permet pas.

Voila, très bien. Le C++ dispose des deux, le C n'en a qu'un seul. L'avantage est donc au C++.

Lis les archives de la mailing list de GCC plus attentivement.

Et moi je te conseille un article de Zachary Weinberg, de CodeSourcery, qui s'intitule "A Maintenance Programmer's View of GCC", paru lors du GCC Summit 2003, dans lequel il expose les problèmes de maintenance dont souffre GCC. Ce n'est pas beau à voir.

nitro :
Et en ce qui concerne la place, Symbian OS sur téléphones portables est en C++, avec toutes les apps en C++/Java et ça tourne plutôt bien
[...] Les jeux tournent très bien, et sont bien rapides.

C'est d'ailleurs assez impressionnant.
C'est plutôt que le hardware est suffisamment puissant pour permettre à des jeux codés en JAVA de tourner correctement, ou bien que le JAVA est un langage qui permet de coder des jeux rapides ?
J'avoue que je n'ai jamais pratiqué le JAVA mais toutes les critiques que j'en ai eues n'étaient pas très positives en ce qui concerne la rapidité du code.
Et j'ai aussi entendu que les langages orientés objet produisaient du code plus gros que les autres (ceux non orientés objet).
Cela signifie que si on codait en ASM voire en C sur les portables on pourrait faire des trucs encore plus puissant que ce qu'il y a actuellement, ou bien que ces échos que j'ai entendu ne se révèlent pas particulièrement vrais ?

Le Java n'est pas du tout prévu pour être rapide. Pendant sa conception tout a été fait pour rendre l'implémentation d'une JVM la plus aisée possible sur n'importe quelle plateforme. C'est pour ça que le Java tourne facilement partout.
Après, pour ceux qui cherchent de la vitesse avec Java, il y a plusieurs solutions, dont la compilation Just-In-Time (très courant), la recompilation dynamique, ou cibler autre chose que la JVM (ex: GCJ). Sur PC, les JVM JIT de Sun et IBM font environ 80% du C en perf.

En ce qui concerne la programmation orientée objet, ce qui fait du code plus gros c'est principalement :
- les programmeurs qui ne savent pas comment sont traduits les fonctionnalités comme le polymorphisme d'inclusion et qui en abusent un peu partout alors que ce n'est pas nécessaire ;
- les compilateurs qui ne sont pas encore assez avancés (par exemple le compilateur Eiffel permet de réduire considérablement l'overhead des appels polymorphes comparé à G++, de même que certains linkers Modula expérimentaux).

Enfin en ce qui concerne les portables, je pense que le hardware est suffisament avancé pour faire tourner tout ça bien comme il fait. La machine s'adapte pour faciliter le boulot du programmeur, et pas l'inverse.
On peut remarquer que la plupart des telephones portables, les consoles portables, et les futures calculatrices HP, sont tous basés sur le même CPU RISC 32-bits (ARM est très populaire en ce moment).

nitro
:De plus Visual C++ 7 est tout aussi standard que G++.

Sûr? Il n'y a que 3 grands défauts (plus les bogues catalogués dans les PRs, mais tous les compilateurs ont des bogues) connus de GCC par rapport au standard ISO C++98:
* erreurs de parsing -> résolu avec le nouveau parser C++ de GCC 3.4
* pas de "2 stage lookup" des templates -> résolu avec le nouveau parser C++ de GCC 3.4
* impossible d'exporter des templates (mot-clé export) -> le seul problème qui reste, et ça m'étonnerait que VC++7 sache faire ceci.

Ben oui, c'est utile si un OS prend moins de place! Les disques durs ne sont pas gratuits!

Entre un OS sur une disquette qui supporte 0 application, et un OS sur CD qui supporte des milliers d'applications, le choix est vite fait.

Et l'OS sur une disquette qui supporte des milliers d'applications?
Linux peut tenir sur une disquette.

Et en ce qui concerne la place, Symbian OS sur téléphones portables est en C++, avec toutes les apps en C++/Java et ça tourne plutôt bien.

Et ils ont combien de mémoire, ces téléphones portables?

Impossibles à maintenir? Linux, GCC etc., tout ça c'est impossible à maintenir??? Je vois le contraire, moi...

On a deja dit que justement GCC est le pire exemple.

Je ne trouve pas si lourd que ça de travailler dessus. Oui, le code est illisible par morceaux, mais je pense que ça serait bien pire s'il y avait ces !"§$%&/()=? de templates dans tous les sens.

Et Linux n'est pas très gros, la plus grande partie du code source ce sont les drivers.

Eux aussi écrits en C.

Subjectif ? Clairement j'ai cité les raisons pour lesquelles la macro est moins lisible.

Ben, tes raisons ne me convainquent pas:

Ah, pourtant un peu plus loin, tu me réponds :

Tu trouves ça lisible par rapport à ma spécialisation ?

Euh... Pas spécialement.

Alors il faudrait savoir.

Pour les spécialisations avec du code différent, les macros s'en tirent moins bien. Mais pour quelque chose de vraiment générique (ce qui est ce pour quoi les templates sont faits normalement!), les macros marchent très bien.

De plus la collision elle, n'est pas subjective.

Elle n'existe pas. L'utilisation de noms de variables commençant par un underscore est interdite aux programmes utilisateur, en C comme en C++.

Ah bon, pourtant tu en as mis dans tes macros.

Parce que ma macro min appartient à la librairie système qui a le droit d'utiliser ces identifiants.

Et pourquoi est-ce que dans ton exemple de spécialisation tu as :

#define _min(__a,__b) ...
#define libtoto_min(a__,b__) ...

Pourquoi pas __a et __b partout ?

Parce que libtoto n'est pas une librairie système et n'a donc pas le droit d'utiliser des identifiants commençant par un underscore.
C'est d'ailleurs spécifié dans les standards C et C++, ce n'est pas juste une convention comme ça.

Ce n'est pas exact et précis. Le problème est que les types à gauche et à droite ne sont pas comparables, le message d'erreur n'en dit rien. "error: invalid operands to binary <" dit clairement qu'il y a des opérandes incomparables.

Arrête de faire semblant de ne pas comprendre. Min passe encore, mais dans le cas d'une macro plus compliquée à laquelle le programmeur n'a pas accès, le message d'erreur ne veut absolument rien dire puisqu'il indique une ligne sur laquelle il y a du code différent de ce qu'a vu le compilateur.

Solution: gcc -E.
Et le programmeur a forcément accès à la macro au moins en lecture parce que sinon, la macro ne fonctionne pas.

Les développeurs de GCC comptent donner les colonnes des erreurs, ce qui résoudra ce problème.

Ca ne résoud rien du tout, car il suffit d'une seule macro sur une ligne pour invalider tous les numeros des colonnes suivantes.

Si c'est bien fait (vu que ce n'est pas encore fait, je ne peux pas le dire à coup sûr), il donnera la colonne avant expansion des macros. Si l'erreur est dans la macro, il indiquera probablement le nom de la macro.

Construire le pluriel d'un identifiant c'est ce qu'on appelle du bidouillage

Comment veux-tu faire autrement? (cf. ./383)

Très franchement je n'ai pas cherché à comprendre ton code car je le trouve complètement illisible.

C'est le code de Sebastian. Et je le trouve très lisible, moi.

Lis les archives de la mailing list de GCC plus attentivement.

Et moi je te conseille un article de Zachary Weinberg, de CodeSourcery, qui s'intitule "A Maintenance Programmer's View of GCC", paru lors du GCC Summit 2003, dans lequel il expose les problèmes de maintenance dont souffre GCC. Ce n'est pas beau à voir.

Bon, je viens de le lire là. (Moi, je lis vraiment ce qu'on me demande de lire. ) J'étais déjà au courant de pas mal des critiques exposées dans cet article. Il faut savoir:
1. que Zack Weinberg traîte souvent une technique de "obsolète" même si elle existe encore parce qu'elle a aussi ses avantages. C'est le cas de define_peephole (cf. mes messages précédents à ce sujet).
2. que l'article est de par sa nature une liste de points négatifs, pas un aperçu complet de la situation.
3. que Zack Weinberg est une personne qui aime beaucoup tout réorganiser même si c'est un travail immense et inutile, et n'hésite pas à supprimer des fonctionnalités. C'est celui qui essaye régulièrement de virer le maximum de targets (chose que je n'apprécie pas vraiment, virer des targets est un pas en arrière), et aussi une des personnes (mais pas la seule) derrière la suppression des chaînes de caractère multilignes (décision totalement idiote qui agace pas mal d'utilisateurs (cf. aussi les commentaires Slashdot; à chaque fois qu'il y a un article sur GCC, il y a au moins une personne pour s'en plaindre) et que j'ai immédiatement réversée dans le patch TIGCC).
4. que le dernier chapître de cet article se concentre exclusivement sur des problèmes de procédures bureaucratiques qui n'ont aucun rapport avec le choix du langage C.

[HS]D'ailleurs, ces proceedings du GCC Summit sont très intéressants. [/HS]

[hs]

Zack Weinberg traîte souvent une technique de "obsolète" même si elle existe encore parce qu'elle a aussi ses avantages.

impression de déjà vu

[/hs]

Kevin Kofler
:

De plus Visual C++ 7 est tout aussi standard que G++.

Sûr?

Je me base sur une interview du Product Manager de Visual C++ .NET, qui date de novembre 2002.

Q: Microsoft people have been hinting about the conformance work in this release for well over a year. What exactly are we getting?
A: In Everett [codename for the next release of Visual Studio .NET] we've achieved 98% conformance to the C++ ISO standard. No compiler reaches 100%, and it turns out that conformance is a difficult thing to measure since there is no singly accepted test suite. We used 3 - Perennial, Plumb Hall, and Dinkumware - and are passing each above the 98% line. But our favorite benchmark is that we're compiling the popular Boost, Blitz, and Loki libraries without the need for special workarounds. We feel that the great number of innovations in C++ are occurring in these community written libraries, and it is important that Visual C++ be able to compile them. Visual C++ developers will now be able to use the same libraries that the rest of the C++ community, making them part of the greater C++ community. That aside, we'll finally be able to write code using some of the advanced template features defined in the standard.

Et ils ont combien de mémoire, ces téléphones portables?

J'en sais rien

Je ne trouve pas si lourd que ça de travailler dessus. Oui, le code est illisible par morceaux, mais je pense que ça serait bien pire s'il y avait ces !"§$%&/()=? de templates dans tous les sens.

Il n'y en a pas besoin dans tous les sens. Tu prends un code source d'une application KDE, c'est très lisible.

Pour les spécialisations avec du code différent, les macros s'en tirent moins bien. Mais pour quelque chose de vraiment générique (ce qui est ce pour quoi les templates sont faits normalement!), les macros marchent très bien.

Non je ne suis pas d'accord. Comment peux-tu dire qu'un code avec :
- des underscores devant toutes les variables ;
- des parentheses autour de toutes les variables passées en arguments ;
- et des '\' à la fin de toutes les lignes
soit plus lisible qu'un code C++ normal ?

Elle n'existe pas. L'utilisation de noms de variables commençant par un underscore est interdite aux programmes utilisateur, en C comme en C++.

Ah bon, pourtant tu en as mis dans tes macros.

Parce que ma macro min appartient à la librairie système qui a le droit d'utiliser ces identifiants.

Je n'ai pas le droit d'avoir une macro my_min dans un code source utilisateur ?

Arrête de faire semblant de ne pas comprendre. Min passe encore, mais dans le cas d'une macro plus compliquée à laquelle le programmeur n'a pas accès, le message d'erreur ne veut absolument rien dire puisqu'il indique une ligne sur laquelle il y a du code différent de ce qu'a vu le compilateur.

Solution: gcc -E.
Et le programmeur a forcément accès à la macro au moins en lecture parce que sinon, la macro ne fonctionne pas.

Ok alors en C++ avec des templates on a un message d'erreur qui indique précisement où est l'erreur.
Et si on utilise des macro on peut être contraint de se taper la sortie du préprocesseur, voire même la lecture des headers systèmes pour savoir ce qui cloche. Ca ne me semble pas très pratique.

Les développeurs de GCC comptent donner les colonnes des erreurs, ce qui résoudra ce problème.

Ca ne résoud rien du tout, car il suffit d'une seule macro sur une ligne pour invalider tous les numeros des colonnes suivantes.

Si c'est bien fait (vu que ce n'est pas encore fait, je ne peux pas le dire à coup sûr), il donnera la colonne avant expansion des macros. Si l'erreur est dans la macro, il indiquera probablement le nom de la macro.

Ben pour l'instant il n'y a rien de tout ça.

Moi, je lis vraiment ce qu'on me demande de lire.

Qu'est-ce que tu insinues ? Je pense que je lis plus de messages que toi étant donné que dans le labo où je travaille (dont une des spécialités est la compilation), il y a un mirroir de la mailing list GCC en newsgroup local.

J'étais déjà au courant de pas mal des critiques exposées dans cet article. Il faut savoir:
\[snip\]

Ca ne change rien aux problèmes de maintenance de GCC

Et pour finir je retiendrais que tu n'a pas répondu à ceci :

Voila, très bien. Le C++ dispose des deux, le C n'en a qu'un seul. L'avantage est donc au C++.

donc j'en déduis que tu es d'accord.. nah

nitro
:

Elle n'existe pas. L'utilisation de noms de variables commençant par un underscore est interdite aux programmes utilisateur, en C comme en C++.

Ah bon, pourtant tu en as mis dans tes macros.

Parce que ma macro min appartient à la librairie système qui a le droit d'utiliser ces identifiants.

Je n'ai pas le droit d'avoir une macro my_min dans un code source utilisateur ?

Si, mais pas d'utiliser des noms de paramètres commençant par des underscores. (C'est explicitement interdit par les standards C et C++.)

Ok alors en C++ avec des templates on a un message d'erreur qui indique précisement où est l'erreur. Et si on utilise des macro on peut être contraint de se taper la sortie du préprocesseur, voire même la lecture des headers systèmes pour savoir ce qui cloche. Ca ne me semble pas très pratique.

Ben, je ne vois pas où se trouve la difficulté en l'utilisation de gcc -E.

Moi, je lis vraiment ce qu'on me demande de lire.

Qu'est-ce que tu insinues ? Je pense que je lis plus de messages que toi étant donné que dans le labo où je travaille (dont une des spécialités est la compilation), il y a un mirroir de la mailing list GCC en newsgroup local.

Plus de messages que moi? C'est difficilement possible, parce que moi, je lis tous les messages de la mailing list GCC (à travers les archives).
Et je n'insinuais rien de particulier contre toi, c'est juste que beaucoup de personnes ont l'attitude fâcheuse de répondre à mes messages sans aller lire les liens que j'indique. Moi, je suis allé lire le texte alors que tu ne m'as même pas donné d'URL.

J'étais déjà au courant de pas mal des critiques exposées dans cet article. Il faut savoir:
\[snip\]

Ca ne change rien aux problèmes de maintenance de GCC

Ben, moi, je trouve que oui, le fait que l'article ne montre (volontairement) que les points négatifs et que tu ne vois pas les points positifs en le lisant change quelque chose. Et le fait que l'auteur est quelqu'un qui se plaint plus que les autres de ces problèmes change aussi quelque chose.

Et pour finir je retiendrais que tu n'a pas répondu à ceci :

Voila, très bien. Le C++ dispose des deux, le C n'en a qu'un seul. L'avantage est donc au C++.

donc j'en déduis que tu es d'accord.. nah

Ben oui, si on a envie de s'amuser à mélanger, voire combiner des macros et des templates. Ça doit donner quelque chose de très puissant et de totalement illisible à mon avis.

Kevin Kofler
: Zack Weinberg traîte souvent une technique de "obsolète" même si elle existe encore parce qu'elle a aussi ses avantages.

Tiens donc... Il me semble qu'on t'a déjà expliqué 1000 fois la même chose à propos des kernels...

l'article est de par sa nature une liste de points négatifs, pas un aperçu complet de la situation.

Tu as le culot de critiquer ça ?
Tu fais exactement la même chose quand tu parles du mode kernel, de GX/X/Gen, de GTC...

Ma conclusion de ces 2 points, c'est que tu n'es pas capable de rester logique avec toi-même !

Ben oui, si on a envie de s'amuser à mélanger, voire combiner des macros et des templates

N'importe quoi. Tu dis n'importe quoi pour essayer d'avoir toujours raison.

Si, mais pas d'utiliser des noms de paramètres commençant par des underscores.

Ok, donc si je fais un my_min dans mon code je risque des collisions, ou alors j'ai oublié un détail ?

Ben, je ne vois pas où se trouve la difficulté en l'utilisation de gcc -E.

Il n'y a pas de difficulté, simplement c'est plus fastidieux que d'avoir la location précise dans le message d'erreur.

Et je n'insinuais rien de particulier contre toi, c'est juste que beaucoup de personnes ont l'attitude fâcheuse de répondre à mes messages sans aller lire les liens que j'indique. Moi, je suis allé lire le texte alors que tu ne m'as même pas donné d'URL.

Ok je comprends... je n'ai pas donné d'URL parce que je ne sais pas où ça se trouve sur le net (j'ai l'ensemble des proceedings en version papier au labo).

Ben, moi, je trouve que oui, le fait que l'article ne montre (volontairement) que les points négatifs et que tu ne vois pas les points positifs en le lisant change quelque chose. Et le fait que l'auteur est quelqu'un qui se plaint plus que les autres de ces problèmes change aussi quelque chose.

L'interet c'est de connaitre les problèmes, et il y en a un certain nombre.

nitro
:

Si, mais pas d'utiliser des noms de paramètres commençant par des underscores.

Ok, donc si je fais un my_min dans mon code je risque des collisions, ou alors j'ai oublié un détail ?

Si tu fais un my_min dans ton code, tu dois quand-même savoir quelles variables ton code utilise, et utiliser une convention par conséquent (par exemple le underscore final; je précise d'ailleurs que le double-underscore est interdit à tout endroit de la variable en C++, il est autorisé partout sauf au début en C).

je n'ai pas donné d'URL parce que je ne sais pas où ça se trouve sur le net

Pas grave, ce n'était pas dur à trouver.
http://gcc.gnu.org -> http://www.gccsummit.org/2003/ -> http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf

Si tu fais un my_min dans ton code, tu dois quand-même savoir quelles variables ton code utilise, et utiliser une convention par conséquent

Ok, donc il y a bien un risque (d'autant plus grand que le nombre de personnes à travailler sur le code source est important), et d'après ce que je viens de tester, si jamais j'ai le malheur d'utiliser la même variable, le compilateur n'est pas capable d'emettre quoi que ce soit comme warning... la compilation se passe très bien, mais le résultat est faux. C'est risqué quand même.

Si, mais pas d'utiliser des noms de paramètres commençant par des underscores. (C'est explicitement interdit par les standards C et C++.)

Pas tout à fait. On a le droit d'utiliser _mavar dans du code perso (i.e. non-système), mais pas _Mavar ou encore __mavar.

Je viens de vérifier, et en effet, pour des usages locaux comme les paramètres d'une macro, _mavar est autorisé, mais pas pour des trucs file-scope (voire globaux).

Alors Kevin, tu nous promets de ne plus parler du mode kernel et de GTC comme Zack Weinberg parle de GCC ?
Ou alors tu retires les arguments 1. et 2. du post #401 ?

Je ne promets rien du tout et je ne retire rien du tout. Tu n'as pas à m'ordonner ce que j'ai à faire.

quel homme ce Kevin !

kessiveu le nain ?

Kevin : tu es comique quand tu ne sais plus quoi répondre... ou plutôt quand tu es trop fier pour répondre "bon ok c'est vrai que je suis pareil"

Peio : il n'apprécie toujours pas tes poêmes d'amour ?

Les templates ont l'air vraiment avantageux. Dommage que le C++ soit impossible sur TI. LWC ne les supporte pas entièrement et il a l'air d'avoir un problème avec les classes

ô ma douce et tendre, que ne ferais-je pour qu'enfin tu ouvres les yeux, tant sur ta profonde connerie dans cette affaire de GTC qu'en ce qui concerne ma flemme que tu sembles si décidée a étouffer ...