Que devient la programmation OO ? - Page 4

./87> erf.

Godzil :
pourtant dieu sait que le C est tres bas niveau comme langage

En fait, je crois que le C ne peut être considéré comme un langage de bas niveau. Entre autres parce que c'est un langage impératif qui dispose de toutes les structures nécessaire pour la programmation structurée et procédurale (on ne peut même pas dire ça du COBOL )...

Évidement, si on considère qu'un langage de haut niveau est garbage collecté, orienté objet, qu'il supporte la synchronisation de threads et qu'il restreigne le programmeur à utiliser des références (au lieu de pointeurs), le C n'en est pas un.

Cependant, je ne serais pas prêt à conclure que le C soit un langage de bas niveau, et je dirais même que c'est probablement l'un des langages qui est fait des meilleurs compromis. Par contre, ça n’empêche pas que le C soit inadapté pour certaines tâches, la POO et la programmation d’applications avec GUI entre autres. D’ailleurs, on a inventé Objective C et le C++ pour palier à cette situation.

Le C++ ^^

./92> disons que le C est un langage d'assez haut niveau au niveau de la syntaxe, mais qu'il permet de faire du bas niveau

Quesoft :
En fait, je crois que le C ne peut être considéré comme un langage de bas niveau.

Ben, c'est pas vraiment grand-chose de plus que de l'assembleur portable... Le but était de faire un truc :
- qui permette de faire des progs portables
- qui soit simple à implémenter pour avoir un maximum de plateformes disponibles
- qui soit aussi efficace que de l'ASM modulo les capacités du compilo

Toutes les features du C sont dans cet esprit, les struct et les union, par exemple, sont uniquement là pour permettre une portabilité maximale (pour ne pas hardcoder la taille ou l'alignement des types de bases) ; de même, il n'y a pas de limites sur le nb de variables locales (pour ne pas dépendre du nb de registres sur la machine cible, d'où l'utilisation "obligatoire" d'une pile) ; il y a une traduction immédiate instruction par instruction du C vers un assembleur non optimisé ; etc...

Je ne crois pas que tu puisses faire vraiment plus bas niveau sans sacrifier à la portabilité... Certes, on pourrait supprimer les "while" pour ne laisser que des "goto", mais c'est du sucre syntaxique facile à implémenter et très utile... Ca a une traduction tellement immédiate en termes de goto qu'on ne peut pas dire que ça soit une feature haut niveau ^^

Pollux :
Je ne crois pas que tu puisses faire vraiment plus bas niveau sans sacrifier à la portabilité... Certes, on pourrait supprimer les "while" pour ne laisser que des "goto", mais c'est du sucre syntaxique facile à implémenter et très utile... Ca a une traduction tellement immédiate en termes de goto qu'on ne peut pas dire que ça soit une feature haut niveau ^^

Même si toutes les considération d'implémentations que tu as énoncées sont vrai, et que le C soit efficient, cela n'en fait pas, à mon avis un langage de bas niveau. Il est de plus haut niveau que COBOL et que fortran (bon, j'ai jamais programmé en ça alors je parle au travers de mon chapeau, mais je sais qu'il n'y a qu'une seule structure de donnée : l'array ...) et du même niveau que le Pascal.

De toute façon haut niveau != nécessairement bon et puissant. Le basic est de haut niveau, pourtant, il offre excessivement peu d'avantages.

Le fortran est bcp plus haut niveau que le C !!

Je crois que tu te trompe sur la définition de Haut niveau et Bas niveau..

Un langague bas niveau est proche du materiel, un langage haut niveau s'en eloigne fortement, les langages tel le Basic, le Pascal (et encore c'est limite le pascal) le fortran, le forth, le lisp, ...

Un bon exemple, en C on ne parle que de fonction au point de faire des fonction qui retournent.. Rien ! Alors que je pascal est plus strict, une fonction doit retourner une valeur et une procedure ne peut rien retourner.

Le cobol est tellement pointu comme langage qu'il ne peut etre considéré comme langage de bas niveau

Quesoft
: Il est de plus haut niveau que COBOL et que fortran (bon, j'ai jamais programmé en ça alors je parle au travers de mon chapeau, mais je sais qu'il n'y a qu'une seule structure de donnée : l'array ...)

Je connais pas trop non plus, mais tu as l'air de penser que le fait qu'il y ait plusieurs types de données est une caractéristique de haut niveau... Mais comme je l'ai dit, si tu veux faire un assembleur portable, tu n'as pas trop le choix. Exemple : tu veux porter un OS (disons PedroM) pour le mettre dans ton assembleur portable. Tu tombes sur un tableau où chaque élément est constitué de deux entiers (sur 2 octets) et un pointeur (sur 4 octets). Si tu n'as qu'un seul type de données, soit :
[ul][li]tu imposes que tous les éléments soit de taille maximale (par exemple, ici tu imposes que les entiers soient de taille 4) ; malheureusement, ça veut dire que tes structures de données seront 2x plus grosses, les multiplications plus de 3x plus lentes, etc... C'est incompatible avec le fait d'être aussi efficace que l'assembleur.
[li]au contraire, tu imposes que tous les éléments soient de taille minimale (par exemple, ici tu imposes de découper toutes les données octets par octets) ; mais ça a plein d'inconvénients :
[ul]* soit tu représentes un entier 32 bits par un quadruplet (a,b,c,d), et pour faire une addition, tu dois faire (a3,b3,c3,d3) = add32((a,b,c,d),(a2,b2,c2,d2)), ça oblige le compilateur à détecter des motifs pour pouvoir le transformer en l'instruction add32 native du processeur (tu ne pourrais pas l'utiliser pour faire add32((d,c,b,a),...) par exemple), ce qui est contraire à la contrainte de simplicité de l'implémentation
* soit tu représentes un entier 32 bits juste par l'adresse de son premier octet, et tu auras d'autres problèmes, notamment : ça va être compliqué de mettre le *contenu* de cette adresse dans un registre pour optimiser (problèmes d'aliasing, il faut faire des analyses qui étaient très très coûteuses à l'époque de la conception du C, et qui de toutes façons ne sont pas parfaites), tu vas dupliquer le type à chaque opération, tu vas devoir utiliser sizeof() partout, etc...[/ul]
Bref, tu vas devoir gérer plusieurs types de données, avec des tailles qui varient selon la plateforme, donc après les notions de struct et d'union viennent toutes seules... Tu pourras difficilement faire plus bas niveau. Tu peux peut-être faire plus "primitif" en supprimant certaines contraintes d'efficacité, mais c'est tout...

De toute façon haut niveau != nécessairement bon et puissant. Le basic est de haut niveau, pourtant, il offre excessivement peu d'avantages.

On est bien d'accord, mais ça n'empêche pas que le C n'est pas un langage de haut niveau

Godzil :
Alors que je pascal est plus strict, une fonction doit retourner une valeur et une procedure ne peut rien retourner.

Mouais enfin ça j'appelle ça une distinction inutile (pkoi une fonction pourrait renvoyer 5 éléments, 2 éléments, 1 élément, mais pas 0 ?) pour que ça soit plus "intuitif", ça n'a rien à voir avec le fait d'être de haut ou de bas niveau...

Je crois que tout ça est relatif à ce que l'on définit par langage de haut niveau. Ma définition est qu'il s'agit d'un langage dont la syntaxe permet de manipuler des structures abstraites par rapport à ce que la machine connaît. Selon cette définition, le C est un langage de haut niveau. Cela dit, ce n'est peut-être pas la bonne définition, et j'ai peut-être tout faux.

btw
Je veux pas lancer de débat, mais bien que plus verbeux, pascal est au même niveau que le C. L'histoire de la ségrégation des fonctions et des procédures en pascal n'est rien d'autre qu'une saveur syntaxique. Le COBOL (je déteste ce langage soit dit en passant), c'est de l'assembleur structurée avec une syntaxe plus chiante (désolé d'employer ce mot, mais c'est le seul qui a assez de force pour la décrire) et plus blablablabla que le pascal : Exemple, pour exécuter une sous-routine il faut se taper quelque chose du genre PLEASE KIND COMPILER PERFORM THIS PARAGRAPH, WHICH IS NOT A PROCEDURE SINCE THERE ISNT ANY LOCAL VARIABLE IN THIS LIMITED LANGUAGE UNLESS YOU CALL A SUBPROGRAM, MEANWHILE ILL RESPECT THE 80 COLUMN RESTRICTION AND WILL FINISH THIS STATEMENT WITH A DOT. et j'exagère à peine (parce que l'on ne peut pas mettre une instruction aussi longue sur une seule ligne) ... C'est un langage structuré, au mieux, où le working-storage est traduit directement par des define storage en assembleur. Je ne dis pas ça pour choquer les tenants du langage, j'ose m'exprimer ainsi parce que je présume que peu d'entre vous ont eu la malchance d'avoir à l'utiliser.

non meme si au niveau syntaxique le C et le Pascal se ressemblent, et que le pascal propose (plus ou moins) des pointeurs, la gestion de la mémoire est bcp moins poussé en pascal, ce qui rend le C de bas niveau est lié au rapprochement tres fort avec le matériel. Tu peut fait du pascal sans jamais utiliser un pointeur ni d'allocatioin mémoire (chose qui n'existe pas naturellement en pascal d'ailleurs !)

Mon exemple pour le pascal au dessus n'avait rien a voir avec le fait que le pascal soit de haut ou bas niveau, je sais meme pas pourquoi j'ai parlé de ça

Quesoft
: Je crois que tout ça est relatif à ce que l'on définit par langage de haut niveau. Ma définition est qu'il s'agit d'un langage don't la syntaxe permet de manipuler des structures abstraites par rapport à ce que la machine connaît.

Ca veut dire quoi ?

Pollux
:

Quesoft
: Je crois que tout ça est relatif à ce que l'on définit par langage de haut niveau. Ma définition est qu'il s'agit d'un langage don't la syntaxe permet de manipuler des structures abstraites par rapport à ce que la machine connaît.

Ca veut dire quoi ?

Si j'en comprend la définition, l'assembleur est donc de haut niveau

Godzil :
non meme si au niveau syntaxique le C et le Pascal se ressemblent, et que le pascal propose (plus ou moins) des pointeurs, la gestion de la mémoire est bcp moins poussé en pascal, ce qui rend le C de bas niveau est lié au rapprochement tres fort avec le matériel. Tu peut fait du pascal sans jamais utiliser un pointeur ni d'allocatioin mémoire (chose qui n'existe pas naturellement en pascal d'ailleurs !)

Tu leur reproches quoi aux pointeurs en pascal, et aux fonctions NEW et DISPOSE ?

Attendez là... Si le C n'est pas un language de bas niveau, il y a quoi à part l'ASM qui est de bas niveau ???

./103 D'après mes connaissance limitées et très théorique de l'ASM, il n'y a vraiment rien d'abstrait (par rapport à la machine) en ASM.
Je suis assez d'accord avec la définition qu'a donné Quesoft.

Spectras: ce n'est pas de la gestion de ma mémoire au sens ou le C l'entend sa en est tres loin, faire (par ex) une liste chainé en pascal est une véritable horreur, chose qui pourtant est relativement simple en C


jfg: ba

faire

add.b d0, d1

est aussi abstrait que devoir faire

char d1, d0;
[...]
d1 = d1 + d0; :/

Godzil :
faire

add.b d0, d1

est aussi abstrait que devoir faire

char d1, d0;
[...]
d1 = d1 + d0; :/

Non, pas du tout. Dans le deuxième cas tu as l'abstraction des variables qui peuvent être placées dans n'importe quel registre ou sur la pile ou un mix des deux, au bon grès du compilateur. Tu n'as pas à réfléchir à l'allocation toi même, et c'est un gros avantage.

Certe

Le C est un langage de moyen niveau. Bas niveau = assembleur.

nitro
:

Godzil :
faire

add.b d0, d1

est aussi abstrait que devoir faire

char d1, d0;
[...]
d1 = d1 + d0; :/

Non, pas du tout. Dans le deuxième cas tu as l'abstraction des variables qui peuvent être placées dans n'importe quel registre ou sur la pile ou un mix des deux, au bon grès du compilateur. Tu n'as pas à réfléchir à l'allocation toi même, et c'est un gros avantage.

Evidemment, mais comme je l'ai dit c'est un corollaire de la portabilité. Si pour toi ce type d'abstraction est caractéristique d'un langage de haut niveau, alors je ne vois pas quel langage portable pour être qualifié de bas niveau ?

Je trouve qu'il n'y a rien d'abstrait dans les 2 cas! Je pense que l'addition est un mauvais exemple...
[EDIT] 4x Cross-combo

Ben nan, c'est un bon exemple je trouve... Quel type d'opération serait fondamentalement différent ? (à part les appels de fonctions et les tests/goto)

Pollux
:

nitro :
Non, pas du tout. Dans le deuxième cas tu as l'abstraction des variables qui peuvent être placées dans n'importe quel registre ou sur la pile ou un mix des deux, au bon grès du compilateur. Tu n'as pas à réfléchir à l'allocation toi même, et c'est un gros avantage.

Evidemment, mais comme je l'ai dit c'est un corollaire de la portabilité. Si pour toi ce type d'abstraction est caractéristique d'un langage de haut niveau, alors je ne vois pas quel langage portable pour être qualifié de bas niveau ?

Mon avis est que le C est plus proche du bas niveau que du haut niveau. Mais on peut encore discuter pendant 107 ans, il n'y a pas de définition précise et universelle pour ces choses là.

Pollux :
Evidemment, mais comme je l'ai dit c'est un corollaire de la portabilité. Si pour toi ce type d'abstraction est caractéristique d'un langage de haut niveau, alors je ne vois pas quel langage portable pour être qualifié de bas niveau ?

Il y en a peut-être pas. Ce que je désigne par abstractions, ce sont les strutures dont tu parlais (même si c'est simplement un emplacement mémoire mapé), les variables qui sont typées, les structures de contrôles qui ne sont pas des instructions machines, les fonctions.

Bien sûr tout cela est traduit en instructions machines, mais si on se sert de cela comme critère, Moka est de bas niveau aussi : les objets ce n'est pas de la magie, c'est rien qu'un endroit mémoire mapé où se retrouve des attributs et des pointeurs vers des routines ; quand j'évoque une méthode de l'interface d'un objet (i.e. que le compilateur n'as pas de moyen de savoir l'adresse de la fonction lors de la compilation), Moka est obligé de faire du dynamic binding, mais c'est rien d'autre que de chercher p/r à l'id correspondant à la classe de l'objet la bonne routine à invoquer, etc...

Cela dit, ma définition du niveau est peut-être invalide ... et on peut allouer de la mémoire dynamiquement en pascal en passant (du moins en Tubo Pascal)

Anyway ce n'est pas super important, on se comprend sur le fond, c'est l'essentiel.

Godzil :
Spectras: ce n'est pas de la gestion de ma mémoire au sens ou le C l'entend sa en est tres loin, faire (par ex) une liste chainé en pascal est une véritable horreur, chose qui pourtant est relativement simple en C

(* La déclaration des types *)
TYPE linkptr = ^link;
     link = record
         next: linkptr;
         value: integer;
     end;

(* Pour créer un maillon *)
function insert(head:linkptr ; v:integer):linkptr;
VAR result: linkptr;
begin
     new(result);
     result^.next  := head;
     result^.value := v;
     insert        := result;
end

(* Pour supprimer un maillon *)
function remove(head:linkptr):linkptr;
VAR result: linkptr;
begin
     result := head^.next;
     dispose(head);
     remove := result;
end

Je comprends pas en quoi c'est plus compliqué que ce que tu ferais en C

Voici ma définition personnelle de la différence entre bas et haut niveau :
[ul][li]Bas niveau (LLL) :
1 instruction (mnémonique) <=> 1 opcode proposé par le processeur cible avec maîtrise des registres[/li]
[li]Haut niveau (HLL) :
1 instruction => 1 bloc d'opcodes sans maîtrise des registres[/li][/ul]Ainsi, il n'y a rien d'autre que l'Assembleur qui soit de bas niveau.

Cependant, il est trompeur de dire qu'il n'y a qu'un seul langage de bas niveau, l'Asm, et d'innombrables langages de haut niveau (C, Pascal, etc.) : bien que les mnémoniques soient les mêmes (si tant est que l'on suive bien la notation d'Intel), les différents compilateurs Asm présentent des différences de syntaxe (gestion des variables, directives d'assemblages, ...) qui permettent de dire qu'il existe plusieurs langages de bas niveau (Asm NAsm, Asm MAsm, etc.). Voici ce que j'avais écrit il y a bien longtemps sur ce point :

De même que le concept de programmation de haut niveau, appelé algorithmique textuelle, présente de nombreux avatars qui sont autant de HLLs, le concept de programmation de bas niveau, appelé génériquement langage Assembleur, présente de nombreux avatars qui sont autant de syntaxes spécifiques avec leur compilateur dédié. En fait, le C et le Pascal sont aussi similaires entre eux que le sont les syntaxes de NAsm et de MAsm, et inversement, les syntaxes de NAsm et de MAsm sont aussi différentes entre elles que le sont le C et le Pascal.

@++

void foo( int data __attribute(register asm("d0")) ) ou un truc comme ça...

Ça, ce n'est pas du C, c'est du GNU C, et en plus non-portable entre architectures. Si vous programmez pour une seule machine et avec GCC seulement, par exemple sous TIGCC, utiliser ça a un sens. Partout ailleurs, non.

ok

Je ne voulais pas ouvrir un autre topic pour ça, alors je vais le poster ici :

Le prochain release de Moka sera multi plates-formes, je n'ai pas encore fait beaucoup de tests, mais voici la compilation d'un hello world :

http://quesoft.dyndns.org:8080/dev/moka/Screenshot.png