Discussion :

[Niark13]

Nous sommes d'accord..

Non, elle n'est pas plus "omniprésente" que en Fortran, en Pascal, etc..

Je ne parlerai pas de Fortran parce que je ne le connais pas. Ce que je voulais dire, c'est que la moindre fonctionnalité comme par exemple convertir une chaîne en majuscules impose de manipuler directement des pointeurs en C. De mémoire, en Pascal, on passe par une abstraction supplémentaire. Il en est de même en C++, en Java, en D, etc.

Maintenant, en ce qui concerne la taille des types, c'est vrai de Fortran, de Pascal, de Java, de C++, et de au moins la moitié des langages de l'arbre cité (en fait de 99% voire 100% des langages compilés)

Java possède justement des types de tailles fixes. Un int fera toujours 32 bits, un long fera toujours 64 bits. Et il n'y a aucun type Java qui puisse représenter le type flottant 80 bits des x86 (Java s'arrête aux doubles 64bits). Charge à l'implémentation (la JVM) d'émuler ces types si le matériel sous-jacent ne le prend pas directement en charge. En ce sens, les particularités de la machines sont masquées au programmeur
Dans un langage de très haut niveau comme Python, les types entiers manipulés sont de taille infinie.

[Jean-Marc.Bourguet]

au contraire du code canonique en C va caster le résultat de malloc (si l'on suit K&R et non la norme), puisqu'à l'époque le cast était obligatoire..

De memoire, le C K&R n'avait meme pas de cast, Je n'ai pas de K&R premiere edition pour verifier, mais ce manuel qui est de la meme epoque n'a pas le mot cast. Voir le paragraphe 7.14.1 pour ce qui se passe dans les assignations avec des types differents.

Les exemples de K&R 2d edition castent peut-etre le resultat de malloc. Mais ils ont ete compiles avec un compilateur C++.

[souviron34]

Je ne parlerai pas de Fortran parce que je ne le connais pas. Ce que je voulais dire, c'est que la moindre fonctionnalité comme par exemple convertir une chaîne en majuscules impose de manipuler directement des pointeurs en C. De mémoire, en Pascal, on passe par une abstraction supplémentaire. Il en est de même en C++, en Java, en D, etc.

Cela est des particularités des langages, mais n'en fait pas des langages de bas ou haut niveau.

Le type string n'apparait en Fortran qu'en 1990. Auparavant il fallait faire des équivalences, et donc passer par des "pointeurs".

Par contre, je ne vois pas, à part les langages fonctionnels, de langages autre que Fortran pour écrire : A = B + C où A, B, et C sont des matrices (des tableaux à N dimensions).

Comment alors classez-vous un tel langage ??

Ce que je veux dire, c'est que vos arguments en faveur de l'appellation "langage de bas niveau" pour C sont valables pour pratiquement tous les langages compilés...

Donc, soit on les appelle tous "bas niveau", et "haut niveau" n'est que pour les langages "récents", soit votre appellation est fausse..

[souviron34]

De memoire, le C K&R n'avait meme pas de cast, Je n'ai pas de K&R premiere edition pour verifier, mais ce manuel qui est de la meme epoque n'a pas le mot cast. Voir le paragraphe 7.14.1 pour ce qui se passe dans les assignations avec des types differents.

Les exemples de K&R 2d edition castent peut-etre le resultat de malloc. Mais ils ont ete compiles avec un compilateur C++.

Dans la version originale (1978) , alloc ressortait un char* (sur la supposition que char = 1 byte).

Pour C89, malloc et calloc retournaient un void*.

Pour l'utiliser (dans les 2 cas), le cast était donc obligatoire..

Ma version du K&R (1978) a bien le mot-clé "cast", avec comme exemple d'utilisation (p. 157) :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
char *calloc();
int *ip ;
 
ip = (int *) calloc ( n, sizeof(int)) ;

[Niark13]

Le type string n'apparait en Fortran qu'en 1990. Auparavant il fallait faire des équivalences, et donc passer par des "pointeurs".

Par contre, je ne vois pas, à part les langages fonctionnels, de langages autre que Fortran pour écrire : A = B + C où A, B, et C sont des matrices (des tableaux à N dimensions).

Comment alors classez-vous un tel langage ??

Si dans votre exemple, A, B et C sont des matrices, alors oui c'est une fonctionnalité de haut niveau dans le sens où l'opérateur '+' ici ne correspond pas à une instruction simple, mais au contraire, masque au programmeur le détail des opérations effectuées. C'est quelque chose qui est impossible de faire en C (où on passera par des appels de fonctions explicites et des pointeurs). Donc je dirais que Fortran 90 est de plus haut niveau que le C.

Ce que je veux dire, c'est que vos arguments en faveur de l'appellation "langage de bas niveau" pour C sont valables pour pratiquement tous les langages compilés...
Donc, soit on les appelle tous "bas niveau", et "haut niveau" n'est que pour les langages "récents", soit votre appellation est fausse..

Un code similaire pourrait être écrit dans un langage orienté objet autorisant la surcharge d'opérateur, par exemple C++, D, Python ou Ruby. J'en prends volontairement deux compilés et deux interprétés afin de bien vous montrer que ces notions sont complètement orthogonales. Quand au fait de distinguer le niveau d'un langage par sa date d'apparition, relisez mon exemple sur Lisp, s'il vous plait.

Pour préciser mon propos, le coté haut ou bas niveau d'un langage n'est absolument pas péjoratif mais est corrélé à la quantité d'abstractions que le langage met à disposition du programmeur vis à vis du système. Dans mon exemple de chaîne de caractère, Pascal possède un type string. Pascal permet aussi de passer une variable à une fonction par référence. C'est aussi quelque chose qu'il est impossible de faire en C sans passer par un pointeur.
Maintenant, posez-vous la question, combien d'abstractions vous propose le langage C ?

[Jean-Marc.Bourguet]

Pour préciser mon propos, le coté haut ou bas niveau d'un langage n'est absolument pas péjoratif mais est corrélé à la quantité d'abstractions que le langage met à disposition du programmeur vis à vis du système.

C'est la ou nous differons. Pour moi ce qui fait qu'un langage est de haut niveau ou pas, ce n'est pas les abstractions fournies, mais la possibilite de batir ses propres abstractions et de le faire efficacement sans que des details d'implementation de cette abstraciton fuitent.

L'aspect dynamiquement, statiquement ou pas typé du tout est completement independant.

La presence d'un GC ou non est relativement secondaire.

[Ca commence serieusement a sortir du cadre de la publication de la norme, un moderateur pourrait-il extraire cet aspect de la discussion dans une nouvelle?]

[souviron34]

Maintenant, posez-vous la question, combien d'abstractions vous propose le langage C ?

Pour moi beaucoup, mais je suis physicien à la base, pas informaticien.

Donc, primo je ne connais rien ni aux nombres héxadécimaux, ni aux bits, ni aux théories informatiques, et d'autre part je n'ai eu aucun mal à programmer ni en Fortran ni en C, donc pour moi ce sont des langages de haut niveau, puisque avec entre 2 et 3 jours et le manuel j'ai pu faire des programmes scientifiques sans connaître les machines.. avec seulement la connaissance de la limite des types par machine (et pas par langage).

Maintenant, vous avez une définition différente. Soit.

Mais à part le fait que cela provoque chez moi un profond étonnement, cette discussion est sans intérêt réel.

A part sur le fait qu'une norme doive inclure les longueurs des types ou non, et l'exemple que vous avez donné me donne à penser que baccali citait cet exemple en pensant à Java.

Je ne peux que répéter que je n'en voie pas l'intérêt du tout.. Si demain une machine sort avec de base 128 bits, il faudra ré-éditer la norme du langage ??? ça n'a pas de sens..

Au contraire, le fait de ne pas avoir la longueur des types dans la norme permet d'avoir un programme qui s'"auto-scale" en fonction de la machine tout en respectant la norme sans modifications :

si il peut traiter 256 points sur un 8 bits, il pourra en traiter sans modifications 65535 sur un 16 bits, etc etc...

[Niark13]

Mais à part le fait que cela provoque chez moi un profond étonnement, cette discussion est sans intérêt réel.

Sur ce point, je vais dans votre sens...

A part sur le fait qu'une norme doive inclure les longueurs des types ou non, et l'exemple que vous avez donné me donne à penser que baccali citait cet exemple en pensant à Java.

Je ne peux que répéter que je n'en voie pas l'intérêt du tout.. Si demain une machine sort avec de base 128 bits, il faudra ré-éditer la norme du langage ??? ça n'a pas de sens..

Au contraire, le fait de ne pas avoir la longueur des types dans la norme permet d'avoir un programme qui s'"auto-scale" en fonction de la machine tout en respectant la norme sans modifications :

si il peut traiter 256 points sur un 8 bits, il pourra en traiter sans modifications 65535 sur un 16 bits, etc etc...

Je n'ai jamais eu la prétention de dire que la norme du C devait fixer la taille de ses types de base. J'ai dit que le fait qu'elle ne le fasse pas était pour moi une des caractéristiques de son coté bas-niveau. Vous venez justement d'illustrer l'intérêt de cette approche : s'adapter au matériel.

Je préfère m'arrêter là et inviter les autres participants de ce thread à se recentrer sur le sujet, la nouvelle norme C11.

[baccali]

Donc, primo je ne connais rien ni aux nombres héxadécimaux, ni aux bits, ni aux théories informatiques, et d'autre part je n'ai eu aucun mal à programmer ni en Fortran ni en C, donc pour moi ce sont des langages de haut niveau, puisque avec entre 2 et 3 jours et le manuel j'ai pu faire des programmes scientifiques sans connaître les machines.. avec seulement la connaissance de la limite des types par machine (et pas par langage).

C'est une blague??!! En tout cas si c'est sérieux C'est franchement navrant!

Et au fait, j'ai pu faire des programmes en assembleur au bout de 2 ou 3 jours moi aussi, c'est donc un langage haut niveau?

C'est la ou nous differons. Pour moi ce qui fait qu'un langage est de haut niveau ou pas, ce n'est pas les abstractions fournies, mais la possibilite de batir ses propres abstractions et de le faire efficacement sans que des details d'implementation de cette abstraciton fuitent.

On peut mettre des abstractions dans n'importe quel langage(et les langages se caractérisent d'ailleurs par çà). Même en assembleur j'ai ma petite lib de fonction et à moindre mesure les appels systèmes sont de bons exemples. Par contre les possibilité du langage à nu sont ce qui compte pour moi. Et pour çà C est le seul à ma connaissance qui ait ce qu'il faut pour "discuter" avec le hardware sans avoir à réécrire ton code selon l'architecture sur laquelle tu te trouve (je ne connais pas d'autres langages doté d'"inline assembly" ou d'option -fsse, -fsse2, -mtune etc..., pour ne parler que de gcc. Ca montre bien que le but du C est d'être low-level.). Un système comme linux ou Windows est écrit totalement en C. d'ailleurs tu n'as pas le choix. L'assembleur est là seulement pour les parties à perf critiques (scheduler) et le boot. Dans un autre langage, c'est pratiquement impossible. Je ne connais pas beaucoup de langage doté de memset. (à moins que souviron34 pense que "a=..." soit la même chose memset (&a, ..., ...) ou que memcpy et que programmer en real mode sans segmentation ou paging est possible dans tous les langages qu'il cite)

De plus la GC et le Runtime est au contraire déterminant dans le fait qu'un langage soit haut niveau ou non (la GC rend impossible de faire un système en java par exemple). Exemple : C et C++ sont des langages qui ne sont pas "COM aware", donc lorsqu'on fait du COM, on récupère la sortie sur un pointeur dont on a passé l'addresse en paramètre et on sait comment ça s'est passé grace au HRESULT. En java, COM aware, tu n'as pas à te soucier du HRESULT parce que la typelib l'a informé du [out]. Le runtime python ou VB s'occupe de surveiller le HRESULT pour toi et lève une exception ou autre si le HRESULT n'est pas bon. Bref voilà d'autres abstractions qui jouent beaucoup dans le fait que tel ou tel langage soit haut niveau à mon sens.

Fin de la parenthèse pour moi.

Mais gèrer un très gros projet en C, si il a été bien conçu, est aussi facile et adapté...

Par contre là on est d'accord. Le C++ n'apporte que des facilité de codage servant à réduire le TCO d'un projet (AMHA). Il est plus facile d'utiliser une classe que des vtbl, donc la "réutilisabilité" est plus facile selon le cas mais perso je trouve qu'un projet bien maintenu en C est tout aussi, sinon plus facile qu'un projet C++ (mais je suis pas du C++). Les projets comme PostgreSQL, Linux ou vim et pleins d'autres projets open-source en sont le parfait exemple. (même si on trouve aussi de parfaites horreurs)


------------------------------------------------------------------
Concernant la norme, avez-vous remarquer que gets_s (originaire de chez M$ il me semble) a fait la peau à gets? Et de manière générale vous ne trouvez pas qu'on se rapproche de plus en plus de langage plus haut niveau justement (overload de fonction avec _Generic pour revenir à la question de Niark)

Sinon à part le support pour le multithreading et l'officialisation du support pour l'unicode je ne vois pas trop de révolution! Cela m'étonnerait que M$ le supporte encore cette fois-ci! Par contre quelqu'un sait si l'attribut "naked" sera un jour officiel ou non?

[souviron34]

C'est une blague??!! En tout cas si c'est sérieux C'est franchement navrant!

Ah oui ? pour quelle raison

Pour quelqu'un qui n'a jamais suivi de cours d'nfo (3h d'initiation au Fortran), depuis 28 ans j'ai une (bonne) carrière à faire de l'informatique scientifique...

Si j'ai besoin de trucs bas niveau, je fais appel à des mecs comme toi. Mais pour mes programmes, je m'en fous dans 99.99% du temps.

La seule chose à assimiler, et, comme mon exemple de Fortran le montrait, c'est valable de manière générale en informatique, et ça n'est pas particulier au C, c'est les adresses/pointeurs..

Peux-tu m'expliquer comment faire comprendre le concept de liste chaînée ou doublement chaînée pour n'importe quel langage sans faire assimiler la notion d'adresse ou de pointeur ??????

Et pour çà C est le seul à ma connaissance qui ait ce qu'il faut pour "discuter" avec le hardware sans avoir à réécrire ton code selon l'architecture sur laquelle tu te trouve

Et ta connaissance est limitée..

On ne compte plus le nombre d'interfaçage matériel avec des programmes Pascal ou HPIB... voire Postscript pour les imprinantes..

De plus la GC et le Runtime est au contraire déterminant dans le fait qu'un langage soit haut niveau ou non

J'arrête de discuter avec toi : ta connaissance du monde est si limitée que tes arguments tombent pour toute personne ayant un tantinet d'expérience...


Ciao..

[Bktero]

Est-ce qu'on fait beaucoup de bas niveau avec un ordinateur où on utilise un système d'exploitation ?

La programmation des micro-contrôleurs (par exemple) l'est déjà beaucoup plus et se fait presque uniquement en C. Vous allez lire des registres, mettre des pattes d'E/S à des niveaux logiques, gérer des interruptions, endormir le processeur, etc.

[baccali]

Pour quelqu'un qui n'a jamais suivi de cours d'nfo (3h d'initiation au Fortran), depuis 28 ans j'ai une (bonne) carrière à faire de l'informatique scientifique...

Mon patron tiens la boîte dans laquelle je bosse depuis 87 et c'est un ingénieur en bâtiment à la base. J'ai beaucoup trop de respect pour lui pour en parler en mal ici (surtout parce qu'il sait quelles sont ses "limites" et le dit clairement! Quelqu'un qui te répond "Je sais pas!" est beaucoup plus sage que quelqu'un qui s'avance sur tout et n'importe quoi n'importe comment.) mais saches que l'expérience ne veut ABSOLUMENT RIEN dire! On s'occupe de laboratoires d'analyses médicales (réseau et logiciel), mais j'ai quand même dû expliquer à mon premier client que si il a 12 000 euros en plus sur sa facture c'est en gros parce que mon bosse ne sait pas ce que c'est qu'un VPN! Et pourtant l'entreprise tourne, et pas qu'un peu! Donc pour l'argument de l'"expérience" qui donne la parole divine tu repasseras

Mais pour mes programmes, je m'en fous dans 99.99% du temps.

Et c'est bien pour toi mais évites d'en faire une généralité. Que tu te fiches de la libc c'est ton problème. Que tu dises que la libc ça sert à rien sur un forum (pour changer de discour 5 min plus tard en plus) c'est déjà un peu moins ton problème.

La seule chose à assimiler, et, comme mon exemple de Fortran le montrait, c'est valable de manière générale en informatique, et ça n'est pas particulier au C, c'est les adresses/pointeurs..

Peux-tu m'expliquer comment faire comprendre le concept de liste chaînée ou doublement chaînée pour n'importe quel langage sans faire assimiler la notion d'adresse ou de pointeur ??????

Un conseil, avant de leur faire comprendre le concept de liste chaînées, commence par leur faire comprendre (ça te servira par la même occasion) la différence entre pointeur et référence. Une piste parmi tant d'autre : Essayes de faire pointer un pointeur en PASCAL vers l'adresse 0x12345678!

On ne compte plus le nombre d'interfaçage matériel avec des programmes Pascal ou HPIB... voire Postscript pour les imprinantes..

Voilà qu'on passe sur un langage interprété (tu serais capable de me dire que c'est du bas niveau c'est çà le pire!). Je ne parlerais même pas du GPIB, on parle plus de la même chose. (et heureusement, on parles plus du tout!)

J'arrête de discuter avec toi : ta connaissance du monde est si limitée que tes arguments tombent pour toute personne ayant un tantinet d'expérience...

Enfin...

[Jean-Marc.Bourguet]

Dans la version originale (1978) , alloc ressortait un char* (sur la supposition que char = 1 byte).

Pour C89, malloc et calloc retournaient un void*.

Pour l'utiliser (dans les 2 cas), le cast était donc obligatoire..

En C89, le cast est pour sûr pas obligatoire.

Ma version du K&R (1978) a bien le mot-clé "cast", avec comme exemple d'utilisation (p. 157) :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
char *calloc();
int *ip ;
 
ip = (int *) calloc ( n, sizeof(int)) ;

Intéressant. Les casts ont donc été ajouté entre 75 et 78.

A ma connaissance, K&R est le seul livre sur le C qui utilise un cast sur le résultat de malloc (les bouquins de Stevens ou celui de Plauger ne le font pas par exemple).

[souviron34]

Intéressant. Les casts ont donc été ajouté entre 75 et 78.

A ma connaissance, K&R est le seul livre sur le C qui utilise un cast sur le résultat de malloc (les bouquins de Stevens ou celui de Plauger ne le font pas par exemple).

je ne peux savoir, n'ayant eu comme référence que ce bouquin.. Mais visiblement dans les mileux dans lesquels j''étais, y comprris les services informatiques, tout le monde l'avait et a casté au moins jusqu'en 2000 (y compris pour le Y2k bug, en Amérique du Nord) (ce pourquoi je m'étais étonné il y a 2 ou 3 ans qu'on me blaste à ce sujet ici) :je ne me suis jamais posé la question et j'ai toujours casté, vu que K&R était LA réference..

[souviron34]

tiens, pour répondre à Baccali sur la taille des types :

Portable Fixed-Width Integers in C