Discussion :

[gl]

Pour moi, c'est plutôt
-classes :
-peuvent hériter d'autres
-permettent de créer des objets qui :
-ont attributs et méthodes
-ont encapsulation (que ça soit propriétés ou public/private)
-sont polymorphes

Il n'y a pas de définition universellement admise pour l'objet (si on prends par exemple celle de B. Meyer, aucun langage n'est objet si ce n'est Eiffel).

Par contre, il y a un sous-ensemble commun aux différentes définitions :

• Une certaine forme de définition de type personnalisé plus ou moins encapsulé et modulaire.
• Le sous-typage (ce que tu appelles héritage au-dessus, mais d'une part l'héritage connote un sous-typage nominal et laisse de côté le sous-typage structurel et d'autre part certains langages proposent de l'héritage qui ne créé pas de sous-type, par exemple l'héritage privé de C++).
• Le polymorphisme de sous-typage aka d'inclusion (et si je précise de sous-typage, c'est bien parce qu'il existe d'autres polymorphismes qui n'ont rien à voir avec l'objet : coercition, surcharge ou paramétrique).
• Du dispatch dynamique sur le type dynamique de l'objet.

Les deux derniers sont souvent regroupés en grosse partie car ils ont un intérêt essentiellement lorsqu'ils sont tout deux présents mais ça reste des mécanismes différents.

[sosolal]

dispatch? keskecé?

[gl]

dispatch? keskecé?

C'est le mécanisme qui fait que lors de l'appel d'une fonction membre, on appelle celle correspond au type dynamique de l'instance et non celle du type statique.

Pour prendre un exemple C++, c'est ce qui fait que le code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <iostream>
 
class A
{
public:
	virtual void foo() const { std::cout << "Classe A\n";}
};
 
class B : public A
{
public:
	virtual void foo() const { std::cout << "Classe B\n";}
};
 
void bar(const A& a)
{
	a.foo();
}
 
int main()
{
	A a;
	B b;
 
	bar(a);
	bar(b);
	return 0;
}

affiche

Classe A
Classe B

et non

Classe A
Classe A

[sosolal]

on appele ça "méthodes virtuelles", je crois.

[gl]

on appele ça "méthodes virtuelles", je crois.

Ça c'est plus le comment s'est implémenté. Et c'est très connoté C++ (et encore en C++ on parlera plus de fonction membre que de méthode).

Certains langages n'ont pas de notion de virtualité (ce dispatch s'applique systématiquement pour toutes les fonctions membres sans notion de virtuel) et d'autres font du dispatch sur tous les paramètres d'une fonctions et pas uniquement sur le paramètre particulier et (souvent) implicite qu'est l'objet auquel est rattaché la fonction membre (on parle alors de dispatch multiple).

[sosolal]

mettre automatiquement les méthodes en virtuelles? C'est cool comme concept! Pourquoi c'est pas dans le standard C++?

[foetus]

mettre automatiquement les méthodes en virtuelles? C'est cool comme concept! Pourquoi c'est pas dans le standard C++?

Cela alourdit l'objet d'au moins d'un pointeur: la fameuse vtable
Et cela ralentit les déférencements.

Il y a l'exemple de la librairie GTK+, qui est [était] codée en C mais utilise [utilisait] le paradigme de la programmation orientée objet.
La librairie GTK+ c'est la fondation de Gnome Linux avec notamment des types de bases, collections et gestion de la mémoire.


Sinon pour l'Objective-C une norme j'ai une énorme doute: .
Il est quand même fortement lié à Clang (le compilateur Apple, même s'il y a aussi GCC) et à XCode (l'IDE).

[grim7reaper]

mettre automatiquement les méthodes en virtuelles? C'est cool comme concept! Pourquoi c'est pas dans le standard C++?

Parce que cela a un coût à l’exécution et que le principe du C++ est de ne pas payer pour ce que tu n’utilises pas.
De plus, rendre une fonction virtuelle c’est ajouter un point de variabilité. C’est quelque chose qui doit être réfléchi, pas automatique.

[Mat.M]

Tiens, je sais pas pourquoi mais ça me donne une idée : créer une framework pour C qui simule la POO. D'ailleur je crois que c'est déja fait.

ça doit être faisable mais c'est sacrément se casser la tête pour rien...
si tu veux faire de "l'objet" en C,il faudra effectivement utiliser des structs avec des pointeurs de fonctions l'équivalent des méthodes C++..
mais un paquet de méchanismes du C++ seront manquants comme l'Opérateur de résolution de portée,les constructeurs et destructeurs,la RTTI,le fait de pouvoir déclarer un membre privé ou public,les exceptions.
Et puis faire de l'héritage en C je ne sais pas trop comment on peut faire ou alors il faut s'arracher les cheveux de la tête à gérer des pointeurs...
bref tout ce que les méchanismes qu'un compilateur C++ est capable de gérer.

A noter que Microsoft a produit une sorte "d'esatz" objet en pur C, c'est la technologie Active Template Library/Component Model Object , ATL-COM.
Si tu veux adresser un objet , il faut avoir un GUID d'interface et appeler l'API QueryInterface...
C'est cette technologie qui est l'épine dorsale en quelque sorte de Word,Excel,Access..

[Mat.M]

Je persiste et signe à dire que les variables globales ça peut être très utile : réduction de la conso de RAM et augmentation la rapidité du code... mais après faut faire gaffe aux risques d'erreurs

Pour ce qui est de la rapidité du code je crois que tu te trompes...
lorsqu'un programme est exécuté en code natif, le bus d'adresse au niveau du CPU doit effectuer une lecture en RAM, au besoin faire des sauts d'adresse...
avec une variable globale le CPU lira un MOV taille adressage,adresse en x86 ou un LEA...
pour une variable locale c'est pas pareil elle peut être mise dans le segment de pile du CPU d'où une lecture immédiate et plus rapide...
tout cela tu peux t'en rendre compte en faisant un petit programme et voir le code assembleur généré...
pour ce qui est de la consommation de RAM, variable globale ou pas, pas certain que cela change quelque chose...

Ce que j'ai voulu dire, c'est que vu que le langage C augmente la compelxité du programme alors le risque de bug est augmenté par rapport à un langage objet (bien entendu, on peut faire un programme en C non buggé et un programme en langage objet buggé)

ok je suis d'accord

[foetus]

ça doit être faisable mais c'est sacrément se casser la tête pour rien...
si tu veux faire de "l'objet" en C,il faudra effectivement utiliser des structs avec des pointeurs de fonctions l'équivalent des méthodes C++..
mais un paquet de méchanismes du C++ seront manquants comme l'Opérateur de résolution de portée,les constructeurs et destructeurs,la RTTI,le fait de pouvoir déclarer un membre privé ou public,les exceptions.
Et puis faire de l'héritage en C je ne sais pas trop comment on peut faire ou alors il faut s'arracher les cheveux de la tête à gérer des pointeurs...
bref tout ce que les méchanismes qu'un compilateur C++ est capable de gérer.

Cela existe depuis longtemps: (4 posts au dessus).
Mais cela n'est pas aussi complet que tu le penses.

A noter que Microsoft a produit une sorte "d'esatz" objet en pur C, c'est la technologie Active Template Library/Component Model Object , ATL-COM.
Si tu veux adresser un objet , il faut avoir un GUID d'interface et appeler l'API QueryInterface...
C'est cette technologie qui est l'épine dorsale en quelque sorte de Word,Excel,Access..

ATL, COM sont écrites en C++.
Je ne vois que la librairie Win32 et Winsock qui sont écrites en C

[Médinoc]

ATL, COM sont écrites en C++.

En effet. Mais il est possible d'utiliser et d'écrire des composants COM en C. Mais écrire un tel composant en C se fera généralement salement (probables casts de pointeurs de fonction, etc.) ou avec énormément de duplication et de code "boilerplate". Le rapport signal/bruit du code sera très bas.

[mith06]

Le rapport signal/bruit du code sera très bas

Comment ça se calcul le rapport signal sur bruit d'un code?

[Médinoc]

Au pif, bien sûr.