C est-il orienté objet?

Le mot-clé struct est-il l'ancêtre du mot-clé class de la plupart des langages modernes? Du moins, les structures crées par struct sont des classes comme les autres, juste avec des arguments mais quand même une classe. D'autres similtudes existe entre les structures et les classes :
-Les deux sont des types personnalisés.
-Les deux contiennent des attributs
-Les attributs des deux sont accessibles via la notation objet.attribut

Et vous, qu'en pensez vous?
:fleche: Pensez-vous que struct est-il l'ancêtre de l'orienté objet? Pourquoi?
:fleche: Pensez-vous que C est orienté objet? Pourquoi?
:fleche: Pensez-vous que C++ et Objective-C aurait dû n'être que des nouvelles normes pour le C? Pourquoi?

Salut,

C n'est pas orienté objet.
Pour moi, un langage objet permet de standardiser et de simplifier la création d'objet.
C'est très important de "standardiser" car au moins tout le monde travail de la même manière.
L'utilisation des pointeurs en langage C est problématique car tu as directement accès à la mémoire => avec un langage objet, il y a une couche abstraction qui permet de déclarer automatiquement l'espace mémoire des objets et empêche de modifier certaines zone mémoire protégées.

Pour moi le seul avantage du langage C est de pouvoir déclarer des variables globales : ça permet de gagner de l'espace mémoire par rapport à l'utilisation d'allocation dynamique d'espace mémoire (utilisée par les langages objet) mais ça complexifie les programmes et augmente le risque de faire du code buggé.
=> langage C utile pour des systèmes embarqués ou pour travailler proche du hardware (ex : création de drivers).

La démarche de conception d'un programme C n'est pas la même que sur le C++.

Citation:

---

Envoyé par sosolal

-La convention de nommage est la même (on commence par une majuscule).

---

Attention, en C il est déconseillé de nommer quelque chose avec une majuscule : tout ce qui commence par un underscore et une majuscule est un identifant reservé (7.1.3 de la norme C99), et tout ce qui commence par E suivi d'une autre majuscule (ou d'un chiffre) est potentiellement utilisé pour les erreurs (errno.h), de meme pour FE_ suivi d'une majuscule (virgule flottante), LC_ majuscule (locale.h), FP_ majuscule (math.h), SIG majuscule et SIG_ majuscule (signal.h).

Apres, si on considere qu'un objet peut contenir des attributs et des fonctions, alors non le C n'est pas oriente objet, meme s'il est tout a fait possible d'ecrire de telles choses en C.

Citation:

---

Envoyé par boboss123

avec un langage objet, il y a une couche abstraction qui permet de déclarer automatiquement l'espace mémoire des objets et empêche de modifier certaines zone mémoire protégées

---

Documente-toi un peu : cela n'a rien avoir avec l'orienté objet

Citation:

---

Envoyé par sosolal

-Les deux sont des types personnalisés.
-Les deux contiennent des attributs
-Les attributs des deux sont accessibles via la notation objet.attribut

---

- Il y en a un des deux qui implémente la notion de constructeurs et destructeurs.
- Il y en a un des deux qui implémente la notions de méthodes liées à un objet. C'est techniquement faisable en C, mais pas franchement intuitif ni prévu pour, et si t'insistes ça peut être la source de bugs immondes.
- Il y en a un des deux qui implémente les notions d'héritage.
Et on pourrait continuer longtemps comme ça.

Donc non, C n'est pas orienté objet.

Citation:

---

Envoyé par sosolal

Documente-toi un peu : cela n'a rien avoir avec l'orienté objet

---

Membres privés, membres publics ?

J'ai bien dit ancêtre.
PS : Et non, la portée n'a rien à voir avec l'orienté objet : Python est un des langages qui éxagèrent le plus sur l'orienté objet, et pourtant il n'a pas de portée.

Ouaw un topic mort né :aie:
Il n'y a pas de débat la dessus le langage C n'est pas un langage objet.
C'est comme si je disais "Est que une lampe peut s'allumer ?" evidamment que oui et en peut se poser intérêt d'une telle question.

Citation:

---

Pensez-vous que C++ et Objective-C aurait dû n'être que des nouvelles normes pour le C

---

Comment dire C++ est un autre langage que le C , c'est pas quelque petite amélioration.
Après pour Objective-C c'est un autre langage qui n'a rien a voir avec le C.
Parler de possibilité de normes pour des langages différent du C me semple inapproprié.

Citation:

---

Pour moi le seul avantage du langage C est de pouvoir déclarer des variables globales : ça permet de gagner de l'espace mémoire par rapport à l'utilisation d'allocation dynamique d'espace mémoire (utilisée par les langages objet) mais ça complexifie les programmes et augmente le risque de faire du code buggé.
=> langage C utile pour des systèmes embarqués ou pour travailler proche du hardware (ex : création de drivers).

---

Le seul avantage du C c'est les variables globals ? (qui sont déconseillé je le rappel) c'est une blague...
Les variables globals sont disponible sur plusieurs langages , non ça ne rend pas le code buggé , ça peut augmenté la complexité enfin c'est surtout que ça empêche un code modulaire et réutilisable.
Après le C permet de tout faire autre que des drivers ou de embarqué.

Citation:

---

Et non, la portée n'a rien à voir avec l'orienté objet : Python est un des langages qui éxagèrent le plus sur l'orienté objet, et pourtant il n'a pas de portée.

---

Je sentais venir l'argument Python ^^

Python n'est peut-être pas le meilleur exemple (enfin, ça dépend ce que tu souhaites montrer). C'est un langage très permissif, laissant une latitude maximale au programmeur. On pourrait presque dire que Python viole certains principes de base de l'OOP comme l'encapsulation avec une API sans accès à l'implémentation, le rajout de membre à une instance à la volée, etc.

D'autre part, il y a quand même une notion de portée en Python mais elle est beaucoup moins stricte que celle qu'on avoir en C par exemple. J'ai moi-même été surpris du résultat affiché par f() :

$ cat test.py 
a = 2
def f():
	print a
f()

def g():
	a = 42
	print a
g()
print a
$ python test.py 
2
42
2
$ 

Enfin, je ne pense pas que Python soit le langage qui exagère le plus l'orienté-objet : tu peux écrire du code sans faire de classe. En revanche, c'est impossible en Java : il te faut forcer une classe qui va contenir le main().

Citation:

---

Envoyé par ManusDei

- Il y en a un des deux qui implémente la notion de constructeurs et destructeurs.

---

La notion de destructeur n’a rien à voir avec l’OO, c’est un détail d’implémentation.
Les langages à GC (Java, Python, Ruby, …) n’ont pas de destructeurs donc ce ne sont pas des langages OO pour toi ?

Citation:

---

Envoyé par Bktero

Citation:

---

Envoyé par sosolal

Documente-toi un peu : cela n'a rien avoir avec l'orienté objet

---

Membres privés, membres publics ?

---

Python n’a pas de private/public, pourtant il est plus OO que Java (en Java les fonctions ne sont pas de objets, les types primitifs non plus, …)

Citation:

---

Envoyé par Bktero

C'est un langage très permissif, laissant une latitude maximale au programmeur.

---

Python ne te laisse pas faire n’importe quoi non plus (surtout au niveau du typage, c’est pas PHP ou Javascript non plus :P) mais c’est vrai que, comme tout langage de script, il est assez souple (et donc permissif).

Citation:

---

Envoyé par Bktero

On pourrait presque dire que Python viole certains principes de base de l'OOP comme l'encapsulation avec une API sans accès à l'implémentation

---

Je rappelle que « encapsulation is not information hiding » (mais les deux vont souvent de pair, c’est vrai)
Cependant, tu peux restreindre l’accès aux attributs en Python (avec les décorateurs @property et @foo.setter).

Pour les fonctions, Python utilise une convention (si le nom de la fonction commence avec deux underscores (genre __foo) alors elle doit être considéré comme privée).
Attention, ce n’est pas imposée par le langage (tu peux y accéder quand même), juste une convention.
Pourquoi ? Parce que si tu veux vraiment contourner private tu le peux (en C++ par example) et que « We're all consenting adults here » est le motto de Python donc GvR (Guido van Rossum) a décidé de ne pas ajouter ce mécanisme dans Python et de se baser sur la bienséance des développeurs (un choix discutable…).

Citation:

---

Envoyé par Bktero

le rajout de membre à une instance à la volée

---

Ça c’est plus chiant par contre, c’est vrai.
Cependant, je ne vois pas quel principe de l’OOP ça brise.

Citation:

---

Envoyé par Bktero

Enfin, je ne pense pas que Python soit le langage qui exagère le plus l'orienté-objet : tu peux écrire du code sans faire de classe. En revanche, c'est impossible en Java : il te faut forcer une classe qui va contenir le main().

---

Et pourtant, Python est bien plus orienté objet que Java (les types primitifs sont des objets, les modules sont des objets, les fonctions sont des objets, …).
Être orienté objet ce n’est pas tout mettre dans des classes.

D’ailleurs, les classes ne sont pas nécessaires (JavaScript est OO mais prototype-based, pas class-based) et suffisantes pour avoir un langage objet.
Ce qui caractérise vraiment la POO c’est :
- encapsulation
- polymorphisme
- héritage
Cf. ici (c’est wikipédia, mais des ouvrages sont cités).

Cela dit, non, le C n’est pas un langage OO.
Certes, on peut simuler les mécanismes OO, mais comme ça n’est pas intégré dans le langage alors le C n’est pas OO (contrairement au C++ par exemple).

Citation:

---

Envoyé par grim7reaper

La notion de destructeur n’a rien à voir avec l’OO, c’est un détail d’implémentation.
Les langages à GC (Java, Python, Ruby, …) n’ont pas de destructeurs donc ce ne sont pas des langages OO pour toi ?

---

Il faut nuancer un peu les propos.
Mais l'absence de destructeur empêche d'utiliser certains "bons principes" comme le RAII (?).
De plus Java a un "destructeur" mais on est pas sûr qu'il soit appelé à chaque fois :aie:.

Citation:

---

Python n’a pas de private/public, pourtant il est plus OO que Java (en Java les fonctions ne sont pas de objets, les types primitifs non plus, …)

---

Cet argument ne tient pas.
Ce n'est pas parce qu'un langage est plus "OO" qu'un autre (est-ce que cela veut dire quelque chose déjà ?) qu'il fait tout mieux qu'un autre au niveau de l'OO.
Les types primitifs ou les fonctions simples ne vont pas à l'encontre de l'OO au contraire, ils servent de "briques de bases" aux objets.

Citation:

---

Pourquoi ? Parce que si tu veux vraiment contourner private tu le peux (en C++ par example) et que « We're all consenting adults here » est le motto de Python donc GvR (Guido van Rossum) a décidé de ne pas ajouter ce mécanisme dans Python et de se baser sur la bienséance des développeurs (un choix discutable…).

---

En C++ il faut vraiment le vouloir et le faire exprès en python, c'est peut être moins évident (d'après ce que je lis) :

• si la méthode privée ne commence pas pas __, on ne sait pas qu'elle est privée
• la tentation peut être un peu trop grande parfois

Citation:

---

Cependant, je ne vois pas quel principe de l’OOP ça brise.

---

Encapsulation, si tu rajoute un membre, tu rajoute le membre à toutes les classes filles, ton membre peut accéder aux données private etc.

Citation:

---

Et pourtant, Python est bien plus orienté objet que Java (les types primitifs sont des objets, les modules sont des objets, les fonctions sont des objets, …).

---

J'ai vraiment du mal avec cela "plus orienté objet" qu'un autre. Tu le mesures comment "l'orientabilité objet d'un langage" ?

Citation:

---

Envoyé par Neckara

Mais l'absence de destructeur empêche d'utiliser certains "bons principes" comme le RAII (?).

---

Et c’est même très chiant parfois.
Heureusement que Java a introduit le try-with-resources en Java 7, ça améliore un peu le bousin mais bon ça ne vaut pas le RAII.

Citation:

---

Envoyé par Neckara

De plus Java a un "destructeur" mais on est pas sûr qu'il soit appelé à chaque fois :aie:.

---

Tu parles de la méthode finalize?
Ce n’est pas un destructeur (car ça ne peut pas être utilisé en tant que tel) car elle peut ne jamais être appelée durant la vie de l’application comme tu le mentionne.

Citation:

---

Envoyé par Neckara

Cet argument ne tient pas.
Ce n'est pas parce qu'un langage est plus "OO" qu'un autre (est-ce que cela veut dire quelque chose déjà ?) qu'il fait tout mieux qu'un autre au niveau de l'OO.

---

Certes, aucun langage n’est parfait.
Cependant l’encapsulation de Python n’a rien à envier à Java (encapsulation = regrouper les données et les méthodes qui agissent dessus).
Par contre, niveau restriction d’accès là Java s’en sort mieux en effet. Cependant, ce genre de choses n’a rien à voir avec la POO (Ada83 avait déjà ce genre de mécanismes public/private sans être pour autant un langage OO (il a fallu attendre Ada95 ou Ada2005)).

Citation:

---

Envoyé par Neckara

Les types primitifs ou les fonctions simples ne vont pas à l'encontre de l'OO

---

Peut-être, mais ça fait tâche pour un langage comme Java qui est (était?) vendu comme un langage purement objet (alors que C++ se veux clairement multi-paradigme donc ça « choque » moins).

Citation:

---

Envoyé par Neckara

au contraire ils servent de "briques de bases" aux objets.

---

Pas nécessairement.
En Ruby par example, tout est objet (idem pour Smalltalk il me semble) donc les briques de bases sont des objets aussi.

Citation:

---

Envoyé par Neckara

En C++ il faut vraiment le vouloir et le faire exprès en python, c'est peut être moins évident

---

Je suis tout a fait d’accord.
J’ai bien dit que le choix de Python de se reposer sur la bienséances des programmeurs est discutable (et je ne trouve pas ça terrible non plus…).

Citation:

---

Envoyé par Neckara

Citation:

---

Envoyé par grim7reaper

Citation:

---

Envoyé par Bktero

le rajout de membre à une instance à la volée

---

Ça c’est plus chiant par contre, c’est vrai.
Cependant, je ne vois pas quel principe de l’OOP ça brise.

---

Encapsulation, si tu rajoute un membre, tu rajoute le membre à toutes les classes filles, ton membre peut accéder aux données private etc.

---

C’est à dire ? Je ne vois pas le rapport :/. Tu peux donner un exemple ou reformuler ?
Bktero parle du rajout d’un membre à la volée à une instance par une classe.
Mais je trouve ça très moche aussi…

Citation:

---

Envoyé par Neckara

J'ai vraiment du mal avec cela "plus orienté objet" qu'un autre. Tu le mesures comment "l'orientabilité objet d'un langage" ?

---

C’est plus un ressenti qu’un truc vraiment technique (les seules explications qui me viennent à l’esprit sont bancales ou subjectives >_<), donc considérons ça comme un abus de langage de ma part. Désolé.

Citation:

---

Envoyé par grim7reaper

Python n’a pas de private/public, pourtant il est plus OO que Java (en Java les fonctions ne sont pas de objets, les types primitifs non plus, …)

---

Je vois ce que tu veux dire. C'est très juste d'ailleurs ! Je pensais surtout au fait qu'en Java, tu ne peux pas te passer de classe alors qu'en Python, tu peux programmer sans jamais créer de classe. La sensation d'OOP semble plus présente en Java qu'en Python (en tout cas, c'est mon ressenti quand je code).

Citation:

---

Python ne te laisse pas faire n’importe quoi non plus (surtout au niveau du typage, c’est pas PHP ou Javascript non plus :P) mais c’est vrai que, comme tout langage de script, il est assez souple (et donc permissif).

---

Oh la ! Non ! Et je ne dis pas ça : il est très souple, mais aussi très strict sur d'autres points (le type est dynamique mais fort).

Citation:

---

Je rappelle que « encapsulation is not information hiding » (mais les deux vont souvent de pair, c’est vrai)

Cependant, tu peux restreindre l’accès aux attributs en Python (avec les décorateurs @property et @foo.setter).

Pour les fonctions, Python utilise une convention (si le nom de la fonction commence avec deux underscores (genre __foo) alors elle doit être considéré comme privée).
Attention, ce n’est pas imposée par le langage (tu peux y accéder quand même), juste une convention.

« We're all consenting adults here » est le motto de Python donc GvR (Guido van Rossum

---

Il est vrai qu'on peut faire de l'encapsulation sans faire une partie de cache-cache. J'apprécie que moyennement le moto de Python à ce niveau : ma boite fournie des solutions Java embarqué et nos clients viennent souvent du C. Quand je vois à quel point ils ont envie de briser l'encapsulation, je remercie Java de bien cacher la structure interne. Mais j'aime bien Python aussi hein !

Le name mangling est une protection du pauvre si j'ai bonne mémoire, elle est contournable en 2 2. La propriété __all__ (c'est bien elle ?) d'un module est pas trop mal non plus mais ça reste facilement contournable quand même.

Pour moi, cacher la structure interne pour vraiment rester à une API publique permet de respecter des principes de conception tels "programmer contre des interfaces, pas contre des implémentations" (le D de SOLID). Si tu donnes accès à ta structure interne, tu tentes les utilisateurs de programmer contre l'implémentation. Je suis d'accord qu'il faut savoir ce qu'on fait, mais de part ma (pourtant petite) expérience, c'est la porte ouverte aux pires choses :mouarf:

Citation:

---

Citation:

---

le rajout de membre à une instance à la volée

---

Ça c’est plus chiant par contre, c’est vrai.
Cependant, je ne vois pas quel principe de l’OOP ça brise.

---

Ché pas trop... :oops: Je ne sais pas si ça a un nom précis. C'est le concept qu'une classe est définie par son API. Je trouve ça un peu embêtant de pouvoir en rajouter à la volée : tu peux rajouter des méthodes ou des attributs à une instance qui du coup devient différent d'une autre instance de la même classe ou d'une classe fille à laquelle on n'aurait rien rajouté. Tu te retrouves avec 2 objets de même type qui sont différents.

Citation:

---

Envoyé par Bktero

Membres privés, membres publics ?

---

C'est bien de ça que je parlais. Je ne savais pas que certains langages objet n'avaient pas cette notion, désolé.

Citation:

---

Envoyé par Kannagi

Le seul avantage du C c'est les variables globals ? (qui sont déconseillé je le rappel) c'est une blague...

---

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

Citation:

---

Envoyé par Kannagi

Les variables globals sont disponible sur plusieurs langages , non ça ne rend pas le code buggé , ça peut augmenté la complexité enfin c'est surtout que ça empêche un code modulaire et réutilisable.

---

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é)

Citation:

---

Envoyé par Kannagi

Après le C permet de tout faire autre que des drivers ou de embarqué.

---

Je n'ai pas dit qu'on ne pouvait pas faire autre chose que des drivers et de l'embarqué avec : j'ai dit que c'est surtout utile pour ça.
Pour moi, si tu as un nouveau projet à créer en partant de 0 (hors embarqué et driver), je ne vois pas l’intérêt de partir sur du C => dans quel cas tu utiliserais ce langage ?

Citation:

---

Envoyé par Bktero

Citation:

---

Envoyé par grim7reaper

Python ne te laisse pas faire n’importe quoi non plus (surtout au niveau du typage, c’est pas PHP ou Javascript non plus :P) mais c’est vrai que, comme tout langage de script, il est assez souple (et donc permissif).

---

Oh la ! Non ! Et je ne dis pas ça : il est très souple, mais aussi très strict sur d'autres points (le type est dynamique mais fort).

---

Ma phrase doit être ambiguë mais c’est ce que je voulais dire.
Python est souple mais ne te laisse pas faire n’importe quoi au niveau des types (comme PHP et Javascript) :)

Citation:

---

Envoyé par Bktero

Le name mangling est une protection du pauvre si j'ai bonne mémoire, elle est contournable en 2 2. La propriété __all__ (c'est bien elle ?) d'un module est pas trop mal non plus mais ça reste facilement contournable quand même.

---

Bah tu sais, en C++ aussi je te contourne private en 2 2 :

Code:

---

1 2 3

#define private public #include "ma_classe.h" #undef private

---

Et voilà :aie:.
C’est bien crade (on est d’accord) mais ça fonctionne
Java demande à peine plus de boulot (il suffit d’utiliser l’introspection).

Citation:

---

Envoyé par Bktero

Ché pas trop... Je ne sais pas si ça a un nom précis. C'est le concept qu'une classe est définie par son API. Je trouve ça un peu embêtant de pouvoir en rajouter à la volée : tu peux rajouter des méthodes ou des attributs à une instance qui du coup devient différent d'une autre instance de la même classe ou d'une classe fille à laquelle on n'aurait rien rajouté. Tu te retrouves avec 2 objets de même type qui sont différents.

---

C’est peut-être ce que Neckara essaye de m’expliquer.
Moi aussi je n’aime pas vraiment cette fonctionnalité de Python et je ne l’ai jamais utilisé.

Citation:

---

Envoyé par boboss123

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
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é)

---

Je ne dis pas que les variables global ne peut pas être utiles , juste que dans la plupart des cas on peut s'en passé et que c'est souvent mieux de s'en passer , rien que pour le maintenabilité du code notamment.
C'est souvent explication donné le C augmente la complexité et le risque de bug , je n'en sais rien je code en C depuis un moment et j'ai rarement ce soucis la , de même quand je change de langage je ne fais pas moins de bug.

Citation:

---

Envoyé par boboss123

Je n'ai pas dit qu'on ne pouvait pas faire autre chose que des drivers et de l'embarqué avec : j'ai dit que c'est surtout utile pour ça.
Pour moi, si tu as un nouveau projet à créer en partant de 0 (hors embarqué et driver), je ne vois pas l’intérêt de partir sur du C => dans quel cas tu utiliserais ce langage ?

---

Je pars souvent de 0 (mais avec le temps on se construit une petite lib perso tout de même) mais après ça dépend de la compétence de chaqu'un , mais sinon je l'utilise dans le jeux vidéo (2D ou 3D d'ailleurs) ,et quelque fois avec GTK+.

C'est pas question de détail d'implémentation de savoir si C est orienté objet ou pas, on peut très bien faire de l'orienté objet avec du C, il suffit de stocker des pointeurs de fonction dans les struct et de "cacher" les membres internes. On peut émuler quasiment toutes les fonctionnalités OO d'un langage OO traditionnel mais il n'est évidemment pas adapté pour ça.

C'est une question de philosophie, en C les données sont au centre des traitements, on appelle des fonctions sur des données pour modifier ces données, et sous forme de traitement successifs on arrive à un résultat. En POO, on ne pense plus vraiment aux données qu'on manipule mais aux services que peuvent nous rendre ces données. On appelle une méthode sur un objet pour qu'il nous rende un service, les données qu'il manipule ? ça n'a pas d'importance. Grâce à la POO, on obtient des modules avec un plus haut niveau d'abstraction vu qu'on pense en terme de service rendu.

Pour résumer, être OO ou pas, c'est une philosophie lorsqu'on code, des classes en Java qui ne contiennent que des get/set sur tous les attributs ne sont pas plus OO qu'une structure en C. Par contre le langage Java est beaucoup plus adapté si le programmeur veut utiliser la POO car il propose tous les outils de base pour le faire.

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.

Citation:

---

Envoyé par grim7reaper

Ce qui caractérise vraiment la POO c’est :
- encapsulation
- polymorphisme
- héritage

---

Polymorphisme d'inclusion (ou de sous-typage) pour être précis. Les autres formes de polymorphisme ne sont pas franchement liés à la POO.

Généralement, le dispatch simple basé sur le type dynamique de l'objet (qu'il soit nommé single dispatch, dynamic dispatch, late binding ou dynamic binding) est également considéré comme une propriété essentielle à la POO.

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

Citation:

---

Envoyé par sosolal

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.

dispatch? keskecé?

Citation:

---

Envoyé par sosolal

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:

---

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

Citation:

---

Classe A
Classe B

---

et non

Citation:

---

Classe A
Classe A

---

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

Citation:

---

Envoyé par sosolal

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

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

Citation:

---

Envoyé par sosolal

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 :mrgreen:
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: :weird:.
Il est quand même fortement lié à Clang (le compilateur Apple, même s'il y a aussi GCC) et à XCode (l'IDE).

Citation:

---

Envoyé par sosolal

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.

Citation:

---

Envoyé par sosolal

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

Citation:

---

Envoyé par boboss123

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

Citation:

---

Envoyé par boboss123

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

Citation:

---

Envoyé par Mat.M

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

Citation:

---

Envoyé par Mat.M

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

---

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

Citation:

---

Envoyé par foetus

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

Citation:

---

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

---

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

Au pif, bien sûr.