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
 

 
Ben voila, ca marche pas (surprenant n'est ce pas ? )
 
En gros pour ce qui ne connaisse pas le glut, glutKeyboardFunc est une fonction prenant en parametre un pointeur de fonction qui va gerer les evenements clavier.
 
J'ai une erreur de type  
error C2664: 'glutKeyboardFunc' : cannot convert parameter 1 from 'void (unsigned char,int,int)' to 'void (__cdecl *)(unsigned char,int,int)'
 
Bon c chiant, et pour corriger l'erreur il faut que je mette la methode en statique mais c grandement chiant car il va falloir que je remodelise tout le programme ce que je ne veux pas
 
Quelqu'un a une solution ?  

(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 !

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  

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 ?

Oui c'est clair.
 
Mais ca marche pas    
Toujours la même erreur    
 
Il m'est alors eu l'idée saugrenue d'essayer de cette manière en recopiant sur la tienne :
 

 
Mais alors là j'ai une belle erreur :
MainObject.obj : error LNK2001: unresolved external symbol "public: static class MainObjectC * MainObjectC::pC" (?pC@MainObjectC@@2PAV1@A)
 
 
Merci en tout cas  

[jfdsdjhfuetppo]--Message édité par ZeMin--[/jfdsdjhfuetppo]

Ca peut pas marcher avec une fonction amie

ZeMin a écrit a écrit : Oui c'est clair.   Mais ca marche pas     Toujours la même erreur       Il m'est alors eu l'idée saugrenue d'essayer de cette manière en recopiant sur la tienne :   Citation : class toto { public: static void keyboard(char,int,int); private: static toto* instance; void keyboard2(char,int,int); };   puis :   void toto::keyboard(char key,int x,int y) { instance->keyboard2(key,x,y); }   Mais alors là j'ai une belle erreur : MainObject.obj : error LNK2001: unresolved external symbol "public: static class MainObjectC * MainObjectC::pC" (?pC@MainObjectC@@2PAV1@A)     Merci en tout cas

 
Nan elle etait pas saugrenue ton idée, c t meme la bonne
Désolé j'avais oublié le static
 
 
Sinon quand tu declares une variable membre static il faut la redefinir dans le .cpp
 
exemple :
 
class toto
{
static int truc;
};
 
et dans le cpp, au dessus apres les includes :
 
int toto::truc;

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 ?

J'y crois pas ça marche !!!
 
Je vais peut etre dormir moins bete !
 
Merci beaucoup en tout cas  

Quel est l'interet de l'approche objet dans ce cas je me le demande

off, moulte, tu peux imaginer deriver des classes de "toto" pour changer le comportement en fonction des entrées clavier et tout et tout

sombresonge a écrit a écrit : Quel est l'interet de l'approche objet dans ce cas je me le demande

 
Ben en fait, l'intéret c d'éviter de garder le code homogene en C++ sans ajouter des morceaux de C ici et là
 
Et puis le C++ objet c beau.
Chrisbk n'a pas tort, c pas mal lors d'une hypothétique extension du programme.
Mais pour le moment, je ne fais que de l'aggrégation du style :
classe GestionnaireMouvement
classe GestionnaireDiscussion
 
Et puis tu as une classe Gestionnaire qui va filtrer les infos et les envoyer aux deux classes instanciées qui vont les traiter différement.
 
Et puis c pour un projet.
Et puis il faut que je fasse le machin en objet.
Et puis je dois respecter la modélisation MVC pour que cela soit propre.
Et puis oui ca me fait chier mais j'avais le choix entre ça et le CamL (je ne dis pas que CamL soit un mauvais langage mais bon....)

chrisbk a écrit a écrit : off, moulte, tu peux imaginer deriver des classes de "toto" pour changer le comportement en fonction des entrées clavier et tout et tout

 
Ce que j'aime pas c:  
 
class toto {  
public:  
static void keyboard(char,int,int);  
private:  
static toto* instance;  
void keyboard2(char,int,int);  
};  
 
puis :  
void toto::keyboard(char key,int x,int y) {  
instance->keyboard2(key,x,y);  
}
 
le problème c que keyboard est une fonction Callback donc si au cour du programe il n'y a plus d'instance de la classe toto, la fonction keyboard2 n'existe plus => si après le sytème fait apelle à keybord => ouïe

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

ZeMin a écrit a écrit : 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

 
Oui si on oublie pas que la classe doit toujours avoir une instance au cours du programe au bout de la troisième personne qui dérive la classe  

tu aurais resolu ca comment ? (en gardant la modélisation choisie)

 
S'il fallait tout faire en C++ j'aurais fait comme l'a dit ZeMin. Par contre si ça ne tennait qu'à moi j'aurais fait toute les parties du programe qui sont en contacte avec le système en C et toute les parties "Intéligentes" du programme en C++

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.

ZeMin a écrit a écrit : 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.

 
Certe n'empeche que je pense qd même que l'approche objet n'est pas forcément meilleur que l'approche structuré pour tout les problème. De plus Qd il s'git de module de programe suffisement éloigné en terme de fonctionalité et d'interaction il est souvent judicieux de choisir la meilleur méthode de programation pour chaque module même si on passe plus de temps à écrire les interfaces entre ces modules.

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

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 (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   )
 
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]

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
 
Mon dieu, 3h42...

[jfdsdjhfuetppo]--Message édité par ZeMin--[/jfdsdjhfuetppo]

Bonne chance à toi alors que le code soit avec toi