je viens de rencontrer un problème étrange avec ma bibliothèque advio.

j´ai pas mal modifié la manière dont tout est géré (pour que ça soit mieux), mais maintenant j´au un bug étrange :

quand je l´utilise, si je déclare un objet graphics (c´est la classe principake de la bibliothèque) global, ça ne marche pas du tout, alors que si je prend exactement le même programme, mais que je déclare en global uniquement un pointeur vers une instance de la classe graphics que j´initialise dans main() et que je remplace partout les ´.´ par des ´->´ alors ça marche parfaitement.

Principalement, ce sont des variables constantes qui sotn déclaré dans le fichier d´en tête de ma bibliothèque qui ne sont pas initialisée correctement si je déclare ma classe en globale, et d´autre chose de ce genre.

Et je ne vois pas du totu ce qui peut créer ce genre de problème. Donc si quelqu´un avait des conseil, ou une idée sur l´origine, ça m´aiderait beaucoup.

merci d´avance.

Hum ! Bizarre !

Dans le cas ou ça marche, est ce que tu initialises autres chose avant ?
j´illustre :

classeglobale A;

int main()
{
initMoteur();
A = new classeglobale();

}

Dans cet exemple, le initMoteur est appelé avant l´instantiation de la classe.

Si tu définis la classe statique en globale, alors elle est instanciée directement avant meme la premiere instruction du main.
Peut etre que c´est ça qui chie :
Il suffirait que le constructeur de la classe fasse appel a des variables globales en interne qui ne sont initialisées qu´a l´appel de initMoteur() pour que ça parte en vrille...

Mais c´est une supposition...
Sinon, pour le moment je ne vois pas !

arf !
tu auras bien sur rectifié la ligne de mon exemple dans le cas dynamique :

classeglobale* A;

non justement : les seuls truc initialisés avant sont des instances constantes de classe définis comme suis :

const color_s BLANC(255,255,255);

Les déclarations sont dans la fichier d´en tête de la bibliothèque (mais si je les déclare extern et que je les mets dans la bibliothèque elle même, ça ne change rien). Et justement, ces trucs ne sont pas correctement initialisé si je déclare ma classe globale.

Une idée est que le constructeur de la classe crée un nouveau thread destiné à gérer les messages de la fenêtre (le jours ou tout marchera, je réécrirais ça pour qu´il n´y ait besoin que d´un seul thread quel que soit le nombre de fenêtre). Mais windows est assez suspicieux, là dessus, car à ma connaissance, les messages à destinations d´une fenêtre sont exclusivement traité par le thread qui crée la fenêtre, et c´est assez contraignant.

Toujours est-il que tout n´est peut-être pas encore complétement initialisé avant l´entrée dans la fonction main, et que certaines chose peuvent peut-être échoué. Ce qui m´ennuien c´est que je n´avais pas de problème avec ça avant, et que je n´ais modifié que très partiellement la logique du fonctionnement. Donc je pense qu´il y a une astuce qui m´a échappé.

J´ai peut-être même trouvé, mais je ne vois pas comment y échapper :

je pense que le problème vient bien de la gestion des messages de ma fenêtre qui doivent se perdre en route : la fonction qui gère les messages est une fonctions membres de la classe graphics. Alors je récupère à la création de la fenêtre un pointeur vers cette instance, et la fonction qui fait les appel est "friend" avec la classe. Mais se peut-il que le pointeur obtenue à l´initialisation du programme ne soit plus valide un peu après (sachant que je change de thread entre temps) ? auparavant, à cause d´un "bug" dans mon programme, le pointeur en question était obtenue plus tard, à un instant indéterminé, mais potentiellement après l´entrée de pointeur d´exécution dans la fonction main.

hmm si malgre ma tete dans le cul j´ai bien compris, tu as des objets globaux qui utilisent dans leur constructeur des variables qui sont initialises dans ton main (donc apres l appel aux constructeurs)? En tout cas le symptome du new qui marche dans le main mais pas l object en global, ca y ressemble enormement.
Dans lequel cas une astuce simple revient a rajouter un pointeur *next dans les objets, et un pointeur global, de sorte que si l´objet global est pas initialise lors de l appel au constructeur rajoute l objet en cours dans la linked list. Dans ton main lorsque tu initialise l´objet global qui fait chier, tu initialise ensuite la linked list.
J´espere que je suis clair et que j ai bien compris le probleme..

/kUfa

dnob, le code est accessible quelque part ?
avec les deux version, celle qui marche et celle qui ne marche pas ?

kufa : non justement, à priori tout est initialisé avant la déclaration des objets.

godrik :
un exemple de code qui marche :

1. include <advio2.h>

using namespace advio2;
void main()
{
graphics screen(400,400);
screen.Line(100,100,200,200);
screen.WaitKeyboardInput();
}

et un qui marche pas (c´est à dire que la fenêtre qui s´affiche est noir, et ne réagit pas à la frappe d´une touche qui devrait la terminer) :

1. include <advio2.h>

using namespace advio2;
graphics screen(400,400); //seule cette ligne a bougé.
void main()
{
screen.Line(100,100,200,200);
screen.WaitKeyboardInput();
}

ça tourne donc advio2 dont je peut vous passer le code si vous voulez, mais ce n´est vraiment pas très lisible.
L´erreur doit être "conceptuelle" c´est à dire qu´il y a une astuce sur la mémoire ou quelque chose dans le genre à coté duquel je serais passé.

L´erreur vient de la gestion des messages, j´en suis à peu près sur, mais le problème, c´est qu´en mode pas-à-pas, ça marche à peu près. je vais rajoutter les appels nécessaire pour loguer tout ce qui se fait.

non justement, à priori tout est initialisé avant la déclaration des objets.

Mais aussi avant l´instanciation? Sans trifouiller, tu peux pas garantir qu´un .obj sera linke avant un autre, ou que le loader instancie tes objets globaux dans un ordre donne.

il semblerait que ce soit bien ça le problème.

Mais c´est quand même étrange, parce que les trucs qui ne sont pas initialisé, sont pour certain dans le même .obj que l´objet que je crée.

Enfin, je comprend pourquoi toutes les lib (sdl, winsock...) demande de faire un appel d´initialisation avant de les utiliser. Même si je peut m´en passer, ça veut dire que l´on ne pourra plus utiliser aussi simplement ma lib, dommage (mais il faut évoluer).

fait peter le code, je verrais si je peux le debugger...