Salux,
Quelqu'un a deja essayé de realiser un projet basé uniquement sur des TAD?
Thanks
Version imprimable
Salux,
Quelqu'un a deja essayé de realiser un projet basé uniquement sur des TAD?
Thanks
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
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
Une bibliotheque comme GTK est principalement basee sur ce principe.Citation:
Envoyé par Gruik
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.Citation:
Envoyé par DaZumba
Thierry
Oui, en principe, je ne fais que ça ou presque. Threads + TAD.Citation:
Envoyé par Gruik
moi itou...
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.Citation:
Une bibliotheque comme GTK est principalement basee sur ce principe.
Citation:
Oui, en principe, je ne fais que ça ou presque. Threads + TAD.
Et, c'est viable? toutes vos fonctions sont assimilables à des methodes ? (a part main)Citation:
Envoyé par mujigka
moi j'ai fait un très gros projet comme ça..Citation:
Et, c'est viable? toutes vos fonctions sont assimilables à des methodes ? (a part main)
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...
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.Citation:
Envoyé par Gruik
Thierry
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...Citation:
Envoyé par mujigka
Dans ce cas, pourquoi ne pas faire du C++? Ya t il des avantages à rester en C?
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 ? :aie:
Le quoi ? Je me suis trompé de forum ou quoi ?Citation:
Envoyé par Gruik
Ben oui, c'est plus simple et puis c'est ce qu'on sait faire...Citation:
Ya t il des avantages à rester en C?
et comme disait mujika c'est beaucoup plus simple en termes d'organisation des sources répertoires etc... Enfin à mon avis :oops:
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 :aie: 8O
;)
Sérieusement c'est le moyen âge tes programmes (il en existe encore beaucoup j'en doute pas :aie: )Citation:
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..
En 1982 franchement l'atlantique c'était qu'une flac puis le langage C en était encore à ces tout début...
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.Citation:
Envoyé par Gruik
Thierry
Okay, merci bieng
On va te sortir un truc dans le genre, "c'est parce qu'on peut pas écrire" :Citation:
Envoyé par souviron34
ce qui ramène la différence au codage et non au paradigme (attention, mot savant inside).Code:
2
3
4
5
6
Disons que les ADT sont le premier pas vers la conception orienté objet.
;)
Y'avait encore la banquise entre New York et Paris et on allait à Manhattan en char à ski et évitant les ours blancs... Depuis, la planète s'est rechauffée et on a du apprendre à nager...Citation:
Envoyé par hegros
D'ailleurs une version simplifiée de OOC vient d'être plubliée : http://ldeniau.web.cern.ch/ldeniau/oopc.html#OOC-S ;)Citation:
Envoyé par mujigka
Merci Gege, et il y a même une release alpha de COS... Génial! Merci pour l'infoCitation:
Envoyé par gege2061
Thierry