|
Dernière réponse | |
---|---|
Sujet : Probleme C++ OpenGL/Glut | |
ZeMin | :jap: |
Aperçu |
---|
Vue Rapide de la discussion |
---|
ZeMin | :jap: |
sombresonge | Bonne chance à toi alors :) que le code soit avec toi :pt1cable: |
ZeMin | Ben j'essaie de coder de la manière la plus propre qu'il soit et puis c'est noté donc...
On verra ensuite, le temps que mon code se dégrade au fur a mesure :D Mon dieu, 3h42... [jfdsdjhfuetppo]--Message édité par ZeMin--[/jfdsdjhfuetppo] |
sombresonge | Mon expérience me dit que qd on reprend ses anciens objets qu'on les dérive pour obtenir quelque chose qui nous soit util => on réecrit 80% du code :lol: (Bon j'exagère un peu disons 60-70%) Ba quite à tout réécrire mieux vaut repartir sur de bonne base ;)
C++ => lisibilité : OUI si le program est bien conçut à la base. Mais on arrive à un même résultat (nivo lisibilité) qu'en C. Le seul intéret que je vois à l'approche objet c la possibilité de pouvoir (devoir) se placer à un nivo supérieur d'abstraction lors de la résolution d'un problème or quand il s'agit de programation de routines proches du système il vaut mieux ne pas trop "s'asbtraire" (cf les MFC [:vomi] :sarcastic: ) Voilà mon point de vue. N'empeche que d'un point de vue purement théorique l'approche objet est >>>> approche structuré. Mais dans la pratique c rarement le cas (Fénéantisme => BEAUCOUP de bidoullage et de contournement lors de la conception de module objet => perte de lisibilité) [jfdsdjhfuetppo]--Message édité par sombresonge--[/jfdsdjhfuetppo] |
ZeMin | Mon optique est que mon application soit très modulable (c ce que mes enseignants m'ont imposé, ils veulent que mon projet soit réutilisable l'année prochaine).
Donc via l'approche objet, on peut considérer que chaque classe ayant leur propre utilité. Il suffit de modifier leur comportement en les enrichissant par exemple par héritage cela permettant de ne pas géner le reste du comportement du programme. Il faut que la structure du programme soit aussi bien lisible dans le but de faire un zoli diagramme de classes pour que mes successeurs puissent lire et comprendre assez rapidement le fonctionnement du truc. Une héterogéneité C/C++ aurait complexifié le problème. Mais je ne mets pas ton point de vue en doute, je pense que tout le monde a une approche qu'il préfere. ;) D'ailleurs c'est avec une héterogéneité C/C++(voire / ASM) que John Carmack code son doom 3 alors bon.... :) |
sombresonge |
|
ZeMin | Mettre un bout de programme en C et un autre en C++ soit coder a la fois en structuré et en objet rendrait le code un peu moins lisible et "structuré" et c ce que je cherche avant tout. ;) |
sombresonge |
|
chrisbk | tu aurais resolu ca comment ? (en gardant la modélisation choisie) |
sombresonge |
|
ZeMin | C'est la raison pour laquelle Chrisbk m'a demandé si il y aura plusieurs instances. De ce fait leurs existences sont éphémères donc oui cela pourrait poser en effet probleme.
Mais dans ce cas, l'instance toto sera détruit à la terminaison du programme, il n'y a donc pas de probleme ;) |
sombresonge |
|
ZeMin |
|
chrisbk | off, moulte, tu peux imaginer deriver des classes de "toto" pour changer le comportement en fonction des entrées clavier et tout et tout :D |
sombresonge | Quel est l'interet de l'approche objet dans ce cas je me le demande :sarcastic: |
ZeMin | J'y crois pas ça marche !!!
Je vais peut etre dormir moins bete ! :D Merci beaucoup en tout cas :jap: |
ZeMin | Ben euh je crois pas.
Les fonctions amies ne permettent pas plutot d'avoir la possibilité d'accéder aux membres privés et protegés ? |
chrisbk |
|
bilgetz_42 | Ca peut pas marcher avec une fonction amie :??: |
ZeMin | Oui c'est clair.
Mais ca marche pas :cry: Toujours la même erreur :sweat: Il m'est alors eu l'idée saugrenue d'essayer de cette manière en recopiant sur la tienne :
[jfdsdjhfuetppo]--Message édité par ZeMin--[/jfdsdjhfuetppo] |
chrisbk | heuh non, en fait le fin mot de l'affaire c'est que ton glutKeyboardFunc prends en entrée sur une fonction non-membre ou une fonction membre statique .
Le soucis avec la statique c que tu acces qu'a la partie statique de ta classe D'ou la fine idée : stocker en statique un pointeur sur la classe courante (le instance) Et tout ce que tu fais, c une fonction qui "redirige" les appels de glutKeyboard en plus détaillé, ca fait : class toto { public: void keyboard(char,int,int); private: static toto *instance; void keyboard2(char,int,int); }; et dans le constructeur : glutKeyboardFunc(keyboard); et ta fonction keyboard fait juste: instance->keyboard2(....) bref, la fonction statique redirige vers un titi non statique c clair ? |
ZeMin | Merci :)
Effectivement ma classe toto est instanciée qu'une seule fois a l'intérieur du programme. J'essaies de comprendre le principe. En gros, tu rends la classe "statique" en y déclarant un champ statique pointant vers l'objet meme (c fait récursif nan ?) Par contre, ca ne marche pas vraiment :( Je crois pas que cela réponde ma réponse car glutKeyboardFunc est une fonction C définie dans un fichier entete séparée glut.h. Ou alors je n'ai pas vraiment compris ta démarche :sweat: |
chrisbk | (je me demande cbien se font avoir a cause de ca :) )
Le probleme est que tu veux donner a glut une fonction membre d'une classe, et ca, ca passe pas Pourquoi ? Tout simpletement parce qu'un pointeur sur une fonction membre d'une classe fait 8o (a la place des 4requis) 4o pour le ptr de fonction + 4o pour le this Que faire ? passer ta fonction en statique . probleme, tu n'auras acces qu'aux données statique de ta classe . pas glop Si ta classe toto est instancié juste une seule fois dansn tout ton prog, y'a une vieille feinte : class toto { public: void glutKeyboard(); private: static toto *instance; void keyboard(); }; toto::toto() { instance = this; } void toto::glutKeyboard() { instance->keyboard(); } vala ! |
ZeMin | Salut tout le monde,
J'ai un gros soucis et peut etre que quelqu'un pourrait m'aider :) Voila je me sert de la bibliothèque glut pour coder un programme en C++ sous visual c++. Voici mon probleme
|