Discussion :

[dj.motte]

Bonjour,

Qui d�cide que telles ou autres fonctions sont compatibles avec un standard qui se meut comme un camenbert frais ?

Avec le code de la route c'�tait facile:
-On observait la vitesse moyenne dans un lieu-dit. On puisait l' �cart-type de cette moyenne.

-Puis on �tablissait la vitesse autoris�e au dessous de la moyenne diminu�e de l' ecart-type.
Ainsi les radars fonctionnaient � plein .

Mais concernant ISO et ANSI je ne vois pas par quelle bretelle, il y aurait une explication...

Aidez-moi � faire le clair entre ISO et ANSI dans la programmation C++.

Cordialement.

[Trap D]

Salut

Pour l'ISO regarde ici
Pour l'ANSI regarde l�

En gros ISO norme internationale (146 pays), norme ANSI, purement am�ricaine.
Maintenant, pour le C++ ...

[gege2061]

Avec le code de la route c'�tait facile:
-On observait la vitesse moyenne dans un lieu-dit. On puisait l' �cart-type de cette moyenne.

-Puis on �tablissait la vitesse autoris�e au dessous de la moyenne diminu�e de l' ecart-type.
Ainsi les radars fonctionnaient � plein .

Je pensais qu'il fesait pareil avec les fonctions

[dj.motte]

Bonsoir,

Mer�i � Trap D pour m' informer sur ISO et ANSI.

Apr�s lecture de ces deux bulletins ...plus difficle pour moi � lire en Anglo-Am�ricain, je me pose une question. Certes c'est dans la mentalit� du Gaulois que de vouloir tout contester...

Apparamment les deux textes se valent. Les n�o-marxistes (tiers-mondialistes ) diront que les deux, c'est l'imp�rialisme Am�ricain...

Je ne pense pas de la sorte.

Mais je veux faire remarquer que "L ' enfer est pav� de bonnes intentions".

Supposons une n�c�ssit� de la norme universelle...Ce serait un enfer. Plus personne ne saurait comment d�roger � cette norme.

Et le plus affligeant dans cette issue, ce serait que tout le monde s' impliquerait � la r�gle , SANS EN AVOIR DE RETRIBUTION NI RETOUR.

Cela serait la norme pour la norme !


Cordiamement.

[Trap D]

Il n'y a rien de pire qu'�tre dans la norme, c'est �a que tu veux dire ? (et que je pense un peu aussi )

[Asarnil]

Le standard permet d'avoir des codes portables et compatibles avec tous les compilateurs respectant le sus-cite standard (idealement le plus possible). Pas besoin d'aller plus loin, il FAUT un standard. En Cpp c'est l'ANSI qui mene la danse (tu peux y voir l'imperialisme americain :p).

W3, ANSI, ISO, a way of life

[dj.motte]

Bonsoir,

Les normes ( ISO, ANSI ) sont bonnes � prendre � condition qu' elles ne deviennent pas en elles-m�mes des finalit�s � prendre.


Cordialement.

[LeGreg]

Si tu cherches des langage franco fran�ais,
tu devrais trouver ton bonheur aupr�s de Prolog, Ocaml, et LSE.

Et si la norme t'ennuie, rien ne t'empeche de cr�er ton propre langage. Rien de plus facile.

[Trap D]

Si tu cherches des langage franco fran�ais,
tu devrais trouver ton bonheur aupr�s de Prolog, Ocaml, et LSE.

Et si la norme t'ennuie, rien ne t'empeche de cr�er ton propre langage. Rien de plus facile.

Tu es s�r que Prolog soit franco/fran�ais ?? Par contre, LSE, je ne savais m�me pas qu'il existait encore !

[LeGreg]

Tu es s�r que Prolog soit franco/fran�ais ??

En tout cas son auteur l'est:
http://www.lim.univ-mrs.fr/~colmer/tablematiere.html

Par contre, LSE, je ne savais m�me pas qu'il existait encore !

Un langage ce n'est pas une personne ou une espece en voie d'extinction, si il existe hier, il existe aujourd'hui.

[SKZ81]

Avec le code de la route c'�tait facile:
-On observait la vitesse moyenne dans un lieu-dit. On puisait l' �cart-type de cette moyenne.

-Puis on �tablissait la vitesse autoris�e au dessous de la moyenne diminu�e de l' ecart-type.
Ainsi les radars fonctionnaient � plein .

Je pensais qu'il fesait pareil avec les fonctions

Bien s�r qu'il font pareil !!! D'ailleurs, apr�s ces f�tes de no�l, personne n'a t il re�u la d�mo de P=NP ????

Parceque, si, le "voyageur de commerce", �quivalant au "sac � dos", peut se r�soude en P... Une conjecture affirme qu'une preuve difficile n'a pas de "concr�tisation", d'applications... Les maths elles m�mes prouvent qu'une application simple, ne peut avor de preuve concr�te (ou est-ce l'inverse??)

Genre j'arrive � �tre compliqu� en voulant rester simple...

[gege2061]

Et si la norme t'ennuie, rien ne t'empeche de cr�er ton propre langage. Rien de plus facile.

Bien s�r qu'il font pareil !!! D'ailleurs, apr�s ces f�tes de no�l, personne n'a t il re�u la d�mo de P=NP ????

Parceque, si, le "voyageur de commerce", �quivalant au "sac � dos", peut se r�soude en P... Une conjecture affirme qu'une preuve difficile n'a pas de "concr�tisation", d'applications... Les maths elles m�mes prouvent qu'une application simple, ne peut avor de preuve concr�te (ou est-ce l'inverse??)

Tu m'otes les mots de la bouche

[Trap D]

Un langage ce n'est pas une personne ou une espece en voie d'extinction, si il existe hier, il existe aujourd'hui.

Un langage, tout comme une langue peut devenir un langage mort !

[dj.motte]

Bonsoir,

Mer�i encore � Trap D pour les liens sur ANSI et ISO.

Mais concernant les normes du C++ , je suis un peu d�rout�.

Avec Windows et CBuilder++, on me livre un logiciel "pur ANSI et peut-�tre m�me pur ISO".

Dans ce cas, il y a dans "<string.h>" la fonction "stricmp" et la possibilit� d' inclure "<io.h>".

Avec Linux, dans "<string.h>" plus de "stricmp" mais "strcasecmp". De plus "<io.h>" n'existe plus !
Par contre une invitation � se servir de POSIX.

Alors � quoi sert la normalisation en C++ si en passant d'un syst�me d'exploitation � l'autre, on ne s'y retrouve pas ?

Cordialement.

[JolyLoic]

Avec Windows et CBuilder++, on me livre un logiciel "pur ANSI et peut-�tre m�me pur ISO".

C'est juste de la publicit� mensong�re.

Alors � quoi sert la normalisation en C++ si en passant d'un syst�me d'exploitation � l'autre, on ne s'y retrouve pas ?

Il y a dans chaque compilateur des extension par rapport � la norme. La norme garanti plus un minimum commun que l'on doit trouver partout (et dont ni stricmp, ni strcasecmp ni io.h ne font partie).
Et m�me si �a a mis du temps, je trouve qu'aujourd'hui (depuis VC++7.1 et gcc 3.0) le respect de la norme commence � �tre bon dans beaucoup de compilateurs. Suffisemment en tout cas pour que le d�veloppeur qui n'utilise les extensions qu'en tout connaissance de cause n'ait pas trop de surprises en passant d'un environnement � l'autre.

[dj.motte]

Bonsoir,

l y a dans chaque compilateur des extension par rapport � la norme. La norme garanti plus un minimum commun que l'on doit trouver partout (et dont ni stricmp, ni strcasecmp ni io.h ne font partie).

Par norme j'entends ANSI ou ISO. Pas la norme des psychanalystes.

Je ne comprends pas pourquoi des fonctions et des librairies ont �t� sabr� de la norme( ANSI & ISO ) avec Linux.

Pourquoi ne pas int�grer les proc�dures "anciennes" dans la mesure o� elles sont op�rationelles ?

Il y aurait plusieurs version de la m�me proc�dure.

Et pourquoi pas ?

La norme ( ANSI & ISO ) proc�de selon moi, comme un s�cateur. On d�truit puis on esp�re une reconstruction.

Fatigu�.

Cordialement.

[ciol2.6.12]

� faisait �

[PINGOUIN_GEANT]

il ne faut pas que "cela" soit trop gros. (par exemple dans l'embarqu�)

tu pars du mauvais endroit en voyant la norme comme une restriction � ton imagination.
c'est plut�t le contraire : ta verve cr�atrice doit �tre guid�e par la norme.
Cordialement,

[JolyLoic]

Bonsoir,

JolyLoic dit

l y a dans chaque compilateur des extension par rapport � la norme. La norme garanti plus un minimum commun que l'on doit trouver partout (et dont ni stricmp, ni strcasecmp ni io.h ne font partie).

Par norme j'entends ANSI ou ISO. Pas la norme des psychanalystes.

Moi aussi, je ne sais m�me pas en quoi consiste cette norme psychanalytique.

Je ne comprends pas pourquoi des fonctions et des librairies ont �t� sabr� de la norme( ANSI & ISO ) avec Linux.

Je ne comprends pas ce que tu veux dire. En particulier je ne vois pas ce qui a �t� sabr� (je rappelle que stricmp ou strcasecmp n'ont *jamais* fait partie ni de la norme C ni de celle C++), ni ce que Linux a � voir l� dedans.
Qu'un compilateur d�cide de faire une extension par rapport � la norme : Ok.
Qu'il d�cide ce placer cette extention dans un header standard, c'est d�j� plus malheureux, car des gens peuvent croire � tort que cette fonction est standard. D'ailleurs, ce comportement est, je pense, interdit par la norme.
Maintenant, que parce qu'un compilateur a d�cid� dans son coin d'ajouter une extension, on d�cide automatiquement de demander � tous les autres compilateurs d'en faire de m�me, alors l�, pas d'accord.

Pourquoi ne pas int�grer les proc�dures "anciennes" dans la mesure o� elles sont op�rationelles ?

Pour plusieurs raisons en l'occurence :
- Des proc�dures op�rationelles, il en existe des milliers. double triple(double a) {return 3*a;} est une proc�dure op�rationnelle. Doit-on l'inclure � la norme ? Pour qu'une fonction soit dans la norme, il faut qu'elle soit jug�e d'int�r�t g�n�ral, qu'elle s'int�gre bien avec le reste des fonctions, qu'il ne soit pas trivial de reproduire son r�sultat, qu'une pratique pr�c�dente prouve sa viabilit�...
- Parce que, m�me dans les environnements o� elle est fournie, stricmp. Elle peut dire des b�tises, comme par exemple que mu� et MUSS sont diff�rents, ou que M. et m. sont identiques, alors que l'un est une abr�viation fran�aise, et que l'autre ne veut rien dire.

Il y aurait plusieurs version de la m�me proc�dure.

Et pourquoi pas ?

La norme ( ANSI & ISO ) proc�de selon moi, comme un s�cateur. On d�truit puis on esp�re une reconstruction.

En l'occurence, elle n'a rien coup�. Et sur bien d'autres points, elle a permis d'�tendre.

[dj.motte]

Bonsoir,

Je ne comprends pas ce que tu veux dire. En particulier je ne vois pas ce qui a �t� sabr� (je rappelle que stricmp ou strcasecmp n'ont *jamais* fait partie ni de la norme C ni de celle C++), ni ce que Linux a � voir l� dedans.
Qu'un compilateur d�cide de faire une extension par rapport � la norme : Ok.
Qu'il d�cide ce placer cette extention dans un header standard, c'est d�j� plus malheureux, car des gens peuvent croire � tort que cette fonction est standard. D'ailleurs, ce comportement est, je pense, interdit par la norme.
Maintenant, que parce qu'un compilateur a d�cid� dans son coin d'ajouter une extension, on d�cide automatiquement de demander � tous les autres compilateurs d'en faire de m�me, alors l�, pas d'accord.

Oui, mais si par exemple ni "stricmp" ou "strcasecmp" ne font pas partie la norme ( ISO & son copain ANSI ), je ne vois plus comment faire une comparaison non sign�e entre cha�nes de caract�res. Il faudrait dans ce cas r�inventer la roue.

ANSI & ISO seraient-ils des "camemberts flottants" ?

La seule raison pour laquelle je con�ois une exclusion de "stricmp" ou de "strcasecmp" de la norme, tient au fait de l' internationalisation des langages vivants ( Arabe, Chinois, Indien etc...).

Par contre supprimer "<io.h>" de la norme, me para�t mesqin.
"<io.h>" a toujours fait partie la norme ANSI depuis 1980 et des brouetttes... Mais fallait-il r�server un acc�s exclusif aux "fstream" du C++ pour acc�der � un fichier ?

Mais je dois radoter...

O� trouver le dictionnaire des fonctions et des "<include>" accept�s par la norme ( ANSI & ISO ) ?

Ou plut�t comment trouver le dictionnaire des fonctions et des "<include>" qui ont �t� d�pr�ci�s par la norme ( ANSI & ISO ) ?

Cordialement.