Du C tout objet

**Gruik** · 13/02/2007, 14h36

Salux,

Quelqu'un a deja essayé de realiser un projet basé uniquement sur des TAD?

Thanks

**Thierry Chappuis** · 13/02/2007, 14h48

Salut,

Oui, je suis en train d'expérimenter plusieurs modèles objets, et réalise actuellement un EDI (pour m'amuser, initialement basé sur CWorkshop de Frank.H et autres personnes présentes sur developpez.net) en me basant uniquement sur de la programmation objet en C (et un peu de Python aussi... soyons honnêtes)

Sinon, si tu veux de beaux exemple de programmation orientée objet en C, tu peux jeter un coup d'oeil au code source de Java (c'est beau de voir que la portabilité de Java passe par la portabilité du C)...

N.B. la programmation objet ne se limite pas seulement au concept de type abstrait de donnée.

Thierry

**Thierry Chappuis** · 13/02/2007, 14h51

Si tu regarde les archives sur usenet fr.comp.lang.c, tu y trouveras des échanges passionnant avec Laurent Deniau à ce sujet.

Bonne chance

Thierry

**DaZumba** · 13/02/2007, 14h53

Envoyé par Gruik

Quelqu'un a deja essayé de realiser un projet basé uniquement sur des TAD?

Une bibliotheque comme GTK est principalement basee sur ce principe.

**Thierry Chappuis** · 13/02/2007, 15h00

Envoyé par DaZumba

Une bibliotheque comme GTK est principalement basee sur ce principe.

Le modèle objet de GTK s'appuye sur le framework GObject de la glib. D'ailleurs, beaucoup d'autres applications du projet GNOME sont codées selon les mêmes principes.

Thierry

**Emmanuel Delahaye** · 13/02/2007, 15h37

Envoyé par Gruik

Quelqu'un a deja essayé de realiser un projet basé uniquement sur des TAD?

Oui, en principe, je ne fais que ça ou presque. Threads + TAD.

**souviron34** · 13/02/2007, 15h38

moi itou...

**Gruik** · 13/02/2007, 15h47

Une bibliotheque comme GTK est principalement basee sur ce principe.

Oui mais une bibliotheque c'est normal, voire naturel d'avoir ce genre d'approche, je parlais de l'utilisation des TAD pour realiser les fonctionnalités du logiciel, pas specialement pour la creation d'utilitaires independants à notre projet.

Oui, en principe, je ne fais que ça ou presque. Threads + TAD.

Envoyé par mujigka

Oui, je suis en train d'expérimenter plusieurs modèles objets, et réalise actuellement un EDI (pour m'amuser, initialement basé sur CWorkshop de Frank.H et autres personnes présentes sur developpez.net) en me basant uniquement sur de la programmation objet en C

Et, c'est viable? toutes vos fonctions sont assimilables à des methodes ? (a part main)

**souviron34** · 13/02/2007, 16h06

Et, c'est viable? toutes vos fonctions sont assimilables à des methodes ? (a part main)

moi j'ai fait un très gros projet comme ça..

Pas forcément 100% des fonctions, mais pas loin de 98% oui

En fait, je m'étais aligné sur la manière dont XWindow (et maintenant les autres) agissent :

créer des "handlers" d'évenements
enregistrer par application / fonctionalité des méthodes associées

Exemple : recevoir des données sur un socket
avoir une action à enregistrer lors de l'arrivée d'une donnée
cette action équivaut à par exemple la méthode "draw"

mais il y a plein de manières différentes de faire...

**Thierry Chappuis** · 13/02/2007, 16h28

Envoyé par Gruik

Et, c'est viable? toutes vos fonctions sont assimilables à des methodes ? (a part main)

sur le plan de la performance? Oui. On trouve plein de gros projets écrit en C selon ce paradigme. Donc, c'est viable, oui! En termes d'organisation du code source et de maintenance, on y trouve de gros avantages.

Thierry

**Emmanuel Delahaye** · 13/02/2007, 17h00

Envoyé par mujigka

sur le plan de la performance? Oui. On trouve plein de gros projets écrit en C selon ce paradigme. Donc, c'est viable, oui! En termes d'organisation du code source et de maintenance, on y trouve de gros avantages.

De toutes façons, il semblerait que dès qu'on commence à prendre de la bouteille, on programme comme ça et que cette façon de procéder soit consensuelle, reconnue et largement utilisée. Il doit y avoir une raison...

**Gruik** · 13/02/2007, 17h20

Dans ce cas, pourquoi ne pas faire du C++? Ya t il des avantages à rester en C?

**hegros** · 13/02/2007, 17h26

Beh parce que déja il faut connaître un tant soit peu le C++.

Mais la c'est refaire le débat C++ vs C non ?

**Emmanuel Delahaye** · 13/02/2007, 17h28

Envoyé par Gruik

Dans ce cas, pourquoi ne pas faire du C++?

Le quoi ? Je me suis trompé de forum ou quoi ?

Ya t il des avantages à rester en C?

Ben oui, c'est plus simple et puis c'est ce qu'on sait faire...

**souviron34** · 13/02/2007, 17h42

et comme disait mujika c'est beaucoup plus simple en termes d'organisation des sources répertoires etc... Enfin à mon avis

Et en ce qui concerne la vitesse, ben... Tant que c'est pas du langage non-compilé, c'est strictement identique (en gros)(ouais bon d'accord pas "strictement")... C'est juste une grosse série d'instructions machine...

En fait, j'ai toujours soutenu (et me suis d'ailleurs frotté à quelques interviouvers pas nets sur le sujet) que le langage objet est simplement une facilité pour la conception pour des personnes ne pensant pas forcément fonctionnel...

Je me souviens avoir non seulement utilisé mais programmé des programmes de traitement d'images en assembleur et Fortran sur un PDP 11 et un HP1000.. en .. 1982..

J'aimerais qu'on me démontre que faire un programme qui fait :

lit image1
lit image2
add image1 & image2
multiplie resultat par 3
sauve resultat

n'est pas de la conception objet

**hegros** · 13/02/2007, 17h46

Je me souviens avoir non seulement utilisé mais programmé des programmes de traitement d'images en assembleur et Fortran sur un PDP 11 et un HP1000.. en .. 1982..

Sérieusement c'est le moyen âge tes programmes (il en existe encore beaucoup j'en doute pas

)

En 1982 franchement l'atlantique c'était qu'une flac puis le langage C en était encore à ces tout début...

**Thierry Chappuis** · 13/02/2007, 17h48

Envoyé par Gruik

Dans ce cas, pourquoi ne pas faire du C++? Ya t il des avantages à rester en C?

La portabilité est un des énormes atouts du C sur C++ dont l'implantation de la norme n'est pas encore 100%. L'idée n'est pas de rentrer dans un débat C vs C++. Chacun a certes des qualités qui lui sont propres. Mais C est un langage très compact et très flexible, et je trouve que ce sont des qualités non négligeables.

Thierry

**Gruik** · 13/02/2007, 17h50

Okay, merci bieng

**Emmanuel Delahaye** · 13/02/2007, 17h55

Envoyé par souviron34

J'aimerais qu'on me démontre que faire un programme qui fait :

lit image1
lit image2
add image1 & image2
multiplie resultat par 3
sauve resultat

n'est pas de la conception objet

On va te sortir un truc dans le genre, "c'est parce qu'on peut pas écrire" :

Code :

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

1
2
3
4
5
6
 
   image1.lit()
   image2.lit()
   resultat = image1 + image2
   resultat =  resultat * 3
   resultat.sauve()

ce qui ramène la différence au codage et non au paradigme (attention, mot savant inside).

Disons que les ADT sont le premier pas vers la conception orienté objet.

**souviron34** · 13/02/2007, 17h58

Du C tout objet

Réseau C

Discussions similaires

Partager

Partager