Norme qui décide ?

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.

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++ ...

Envoyé par dj.motte

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

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.

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 )

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

Bonsoir,

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


Cordialement.

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.

Envoyé par 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.

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

Envoyé par Trap D

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

Envoyé par Trap D

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.

Envoyé par gege2061

Envoyé par dj.motte

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

Envoyé par LeGreg

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

Envoyé par SKZ81

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

Envoyé par LeGreg

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 !

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.

Envoyé par dj.motte

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.

Envoyé par dj.motte

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.

Bonsoir,

Envoyé par JolyLoic

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.

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,

Envoyé par dj.motte

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.

Envoyé par dj.motte

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.

Envoyé par dj.motte

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.

Envoyé par dj.motte

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.

Bonsoir,

Envoyé par JolyLoic

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.

Envoyé par dj.motte

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

pour qu'un header soit accepté par la norme il suffit qu'il soit compilable par un compilateur adapté à la norme du C/C++. Ce qui est très vaste et il n'y en a pas de liste compilée(arf).

À moins que tu veuilles dire: quels sont les header et les fonctions dont l'interface et la fonctionalité sont intégralement définies par une norme ?
Tout dépend de la norme et de l'année.
en C, tu as toutes les stdio, stdlib, math, assert, float, string, complex etc...
Unix (dont la parenté avec le C est évidente) a lui sa propre norme POSIX, qui définit également des fonctions comme execve ou fork.
en C++, tu as la STL qui regroupe des conteneurs template, des objets de traitement sur les flux (basic_istream, basic_string, vector, map et j'en passe) ainsi que des algorithmes.
l'API window a également ses propres headers standard comme windows.h

L'intéret de les définir dans une norme c'est d'avoir un pot commun dans lequel les programmeurs peuvent puiser et ne pas avoir à se réinventer d'un projet à un autre. Bien entendu, la nature du C/C++ fait qu'un programmeur zélé peut ne pas du tout s'appuyer sur ces librairies et tout refaire de A à Z à sa sauce (si ça lui chante).