Tiens, je viens de percuter un truc.

Si j'ai raté initialement le passage des fichiers *.lib au linker, c'est que j'avais spécifié, dans les "Chemins VC++ 2010", le répertoire des .lib que mon projet devait utiliser, et donc pour moi ça suffisait.
Hors il se trouve que c'est aussi dans cet onglet qu'on spécifie les chemins d'include supplémentaires. Et les *.hpp sont utilisés par le compilateur, pas par le linker.

D'où ma question : est-ce que le compilateur utilise les fichiers .lib ? Et si oui, pourquoi ? D'après ce que j'ai pu comprendre en bossant sur mon assembleur, un fichier de bibliothèque statique peut n'être qu'une archive de fichiers objets, avec éventuellement quelques méta-données. Alors pourquoi spécifier le chemin d'accès de mes .lib au niveau du compilateur ?

Non, le compilateur n'utilise jamais de fichier .lib, pas plus que le linker n'utilise les en-têtes ou les fichiers source ^^

Les chemins d'accès, c'est une option « globale » du projet et ce n'est pas directement en rapport avec le compilateur ou le linker. (En fait j'ai été assez surpris, car dans les versions précédentes c'était dans les options de Visual Studio qu'on réglait tout ça… Mais c'est certainement dû au fait que maintenant le C++ est compilé via MSBuild comme tous les autres types de projet de Visual Studio)
Après, tu as les options spécifiques au compilateur (optimisation, warnings, etc…) et les options spécifiques au linker, où tu indiques par exemple les fichiers .obj/.lib à linker. Mais le linker ne peut trouver les librairies perso que si tu as bien réglé les répertoires du projet auparavant. C'est tout (Pareil pour le compilateur et ses include… ^^)

Erf, je comprends merci. Le linker ne va pas s'amuser à regarder dans tous les .lib pour trouver la fonction que j'utilise. Surtout qu'il pourrait très bien y avoir conflit de nom.

oui, en effet, il faut lui spécifier les fichiers lib.

sous linux c'est des fichiers .a

ça contient juste du code précompilé, et "prêt à utiliser" qui fait éventuellement référence à des DLLs.

Question sans rapport avec les libs graphiques, pourquoi MCVS tient-il tant à s'exécuter en tant qu'administrateur ? J'ai regardé ses propriétés, je ne vois pas quoi changer pour l'exécuter sous mon propre compte, et j'aime pas trop les programmes qui tournent avec des droits sans raison. Est-ce normal ?

Et également, peut-on avoir plusieurs solutions ouvertes ? Plusieurs projets dans une même solution OK, mais plusieurs solutions dans un seul IDE, ça se fait ?

Plusieurs solutions = Plusieurs Visual Studio
(Visual Studio enregistre des paramètres utilisateur pour chaque solution, genre les fichiers ouvert, les régions de code dépliées, ... Ça ne pourrait pas fonctionner avec plusieurs solutions ouvertes en même temps)
Après il me semble que tu peux imbriquer des solutions mais je n'ai jamais fait.

Le mode administrateur ensuite, c'est juste plus simple pour débogguer... Mais à une époque il me semble qu'il s'exécutait en mode utilisateur et passait par un service pour débogguer...

C'est spécifique à VS C++ alors ? Parceque Visual Studio C# n'a pas du tout besoin de s'exécuter en administrateur

spécifique au code natif qui doit faire appel au kernel et aux appels OpenProcess()

sinon en .Net c'est probablement la VM qui s'occupe du debug.

Merci !

Zerosquare : je confirme ce que je t'avais dit : MSVC++ Express 2010 est valable 30 jours, j'ai dû procéder à un enregistrement gratuit du produit, une clé a été attribuée à mon compte WinLive/MSN (en fait, mon compte gmail attribué autrefois à un compte passeport.net ou un truc du genre).

D'après l'aide de MSVC++E, ça permet l'utilisation au-delà de 30 jours, et débloque des fonctionnalités (?).

GoldenCrystal (./34) :
Après il me semble que tu peux imbriquer des solutions mais je n'ai jamais fait.

Pour revenir à ça : Oui, c'est faisable, mais c'est pas commode pour bosser sur, par exemple, un programme et une lib. Ca lie les deux, ce qui n'est pas forcément le but.

Comment appelle-t-on typiquement un object qui sert à envoyer et recevoir des messages ? Celui qui reçoit uniquement, c'est un Listener, celui qui envoie je sais même pas, quant à celui qui fait les deux, j'ai mis CommObject pour le moment, mais c'est nul : trop long et ça signifie trop rien, comme d'habitude avec moi Mais j'imagine qu'un tel objet est courant, et doit donc avoir un nom typique bien reconnaissable, non ?

Ça dépend de l'utilisation, par exemple s'il écoute sur une source et envoie vers plusieurs cibles j'aime bien "Dispatcher". S'il fait office d'intermédiaire entre une source et une cible, ça pourrait être un "Proxy". Il y a beaucoup d'autres possibilités

Bah ça dépend surtout de ce que fait ton objet et de la façon dont il fonctionne. Si il fait un truc pour lequel il existe un mot tout fait, alors tu utilises ce mot. (Ex: transmetteur, distributeur, émetteur, récepteur, transformateur mixeur…)
Mais en général un seul mot c'est trop générique, donc tu va ajouter un autre mot pour dire par exemple si il transmet des paquets, des messages, des pommes, des carottes ou des bananes, … (Ex: BananaTransmitter )

En fait, envoyer et recevoir, c'est super vague, et ça peut vouloir dire tout et n'importe quoi. Est-ce qu'il renvoie les mêmes messages que ceux qu'il reçoit, ou est-ce qu'il transforme les messages ? Est-ce que les messages envoyés ont un rapport avec ceux reçus ? Etc.
Si tu reçois des messages et que tu les transmets directement à un autre, bah, c'es juste un objet qui transmet (perso j’appellerais donc ça MessageTansmitter).
Si tu transmets les messages pour les filtrer, ben c'est un filtre (-> MessageFilter)
Si tu reçois les messages pour les redistribuer de manière intelligente à d'autres objets, c'est plutôt un Dispatcher.
Si tu reçois des messages cryptés et que tu renvoies des messages décrytpés, c'est un décrypteur.

Etc.

Après je sais pas ce qui s'applique plus spécialement à ton cas…

Edit: cross
./40 > (J'aime bien les dispatcher aussi :])

Merci ! Ah tiens, j'ai utilisé Dispatcher déjà (Souvenir : http://tigcc.ticalc.org/doc/events.html#EV_centralDispatcher). J'avais pensé à Central aussi (par analogie à Central Téléphonique, on fait ce qu'on peut hein )

En fait, pour le moment j'ai :
- Un Dispatcher qui tient une liste des "CommObjects" (restons sur ce terme). Il retient pour chaque élément un ID et un pointeur
- des CommObjects, qui possèdent donc un ID, et connaissent l'adresse du Dispatcher.

Quand les CommObjets se créent, ils envoient un message au Dispatcher pour s'enregistrer. Ils se désinscrivent à la destruction.
Les CommObjects sont capables d'envoyer un Message à un autre CommObject, de broadcaster à tous les CommObjects de leur Dispatcher, ou encore de recevoir un message. Les transmissions se font via le Dispatcher qui fait suivre.

Pour le moment, les messages sont des void* parce que je ne sais pas quoi faire d'autre, et au moins on peut tout faire avec ça.



J'ai déjà lu une partie de la doc de Qt sur les signaux/slots, sur le fait qu'ils sont reliés les uns aux autres de manière déterminée. Je ne veux pas en lire plus, je ne veux pas non plus lire la doc de Boost, pour ne pas reproduire ce qui existe et est sûrement 100 fois mieux que ce que je vais faire.
Mon but est de faire un toolkit graphique pour voir comment ça marche, la programmation évènementielle et la communication entre objets, parce que je n'y connais rien, je sais juste que ça existe. Ca n'a donc aucune prétention, c'est pédagogique uniquement, donc on ne parlera pas de cryptage ou autre possibilités

Voilà, donc comme d'hab, tous les commentaires et critiques sont les bienvenus.

Folco (./38) :
Zerosquare : je confirme ce que je t'avais dit : MSVC++ Express 2010 est valable 30 jours, j'ai dû procéder à un enregistrement gratuit du produit, une clé a été attribuée à mon compte WinLive/MSN (en fait, mon compte gmail attribué autrefois à un compte passeport.net ou un truc du genre).

D'après l'aide de MSVC++E, ça permet l'utilisation au-delà de 30 jours, et débloque des fonctionnalités (?).

Ça a changé alors, désolé pour mes infos périmées !

Bof, y a aucun mal. Je me demande juste à quoi ça leur sert ce genre d'inscription. Cibler les pubs ? Compter les utilisateurs ? Pas besoin d'inscription pour ça...

Les voies du marketing sont impénétrables... (désolé pour le blasphème )

Bah, ce mécanisme a toujours été là depuis la première version Express (qui à la base n'était pas sensé rester gratuite à vie, mais qui enfin de compte l'est restée )
Je pense que ça doit servir pour leurs statistiques internes, afin de savoir quel type d'utilisateur utilise quel type de Visual Studio, et pour quoi faire, et ça leur permet éventuellement de développer de nouveaux produits, ou de réorienter leur stratégie. Quand à savoir si c'est vraiment utilisé en pratique… (Ça devait l'être à un moment en tout cas)

En plus je ne suis pas sûr que toutes les versions express soient sujettes à cette inscription, mais je n'ai jamais fait le test. (Y'a des versions installées "de force" avec certains outils de dev genre le toolkit XNA/Windows Phone 7 ou d'autres… Ce qui est rageant, car quand tu as la version Pro/Ultimate, tu t'en branles complètement de la version Express )

GoldenCrystal (./46) :
En plus je ne suis pas sûr que toutes les versions express soient sujettes à cette inscription, mais je n'ai jamais fait le test.

Ça doit être le cas, parce que je ne me souviens pas d'avoir eu à remplir quoi que ce soit pour utiliser les versions Express au boulot (mais c'était pas VC++).

Tiens, puisqu'on parle de C multiplateformes...

pauvres élèves...

Les pauvres ><

Folco (./8) :
1>MSVCRTD.lib(cinitexe.obj) : warning LNK4098: conflit entre la bibliothèque par défaut 'msvcrt.lib' et les autres bibliothèques ; utilisez /NODEFAULTLIB:library

Folco (./8) :
Je prends les erreurs dans l'ordre, d'abord le conflit : comme l'option conseillée est un peu trop bourrine, j'ai ajouté la bibliothèque en cause (msvcrt.lib) aux bibliothèques par défaut spécifiquement ignorées.

GoldenCrystal (./11) :
En fait, le format des librairies ne varie pas vraiment d'une version à l'autre, mais le runtime de Visual C++ (MSVCRT) est mis à jour à chaque nouvelle version (MSVCRT6, MSVCRT7, MSVCRT8, MSVCRT9, MSVCRT10, …)
Le problème de conflit (comme je pensais qu'il risquait de se présenter), c'est que tu lies de manière statique deux versions différentes du runtime (la version 8 et la version 10), ce qui crée donc un conflit. La partie liée de manière dynamique ne pose pas de problème (si ce n'est que tu vas charger en mémoire deux versions différentes de MSVCRT simultanément), mais la partie statique est plus problématique. Mais passons sur ce problème pour l'instant puisque tu l'as résolu au moins temporairement.

Pouet, on peut replancher sur ce problème ? Je serais déjà content de savoir quel MSVCRT j'utilise, et lequel il faudrait idéalement que j'utilise, je ne sais même pas comment savoir ça, et encore moins comment résoudre élégamment le problème ; merci d'avance.

Pourquoi pas utiliser MinGW? Comme ça, tu es sûr que tu utiliseras la MSVCRT.DLL dynamique qui fait partie du système (et tout ce qui manque à la vieille MSVCRT est rajouté dans la libmingwex.a statique).

Et au fait, "Miscrosoft", c'est pour dire que ce sont des escrocs?

^^

En fait, je voulais savoir comment lever ce loup, bien que je n'en ai pas absolument besoin, car en effet j'utiliser MinGW sur ce projet ^^

Par défaut, tu utilises la version de MSVCRT qui correspond à la version du compilateur que tu as installée / que tu utilises. Tu peux éventuellement te démerder pour utiliser une autre version (plus récente / plus ancienne) mais ça implique d'inclure cette version avec ton projet et d'en modifier la configuration (pour ignorer le lib par défaut et utiliser celle que tu spécifies). En faisant ça, tu t'exposes potentiellement à des bugs étranges, même si je doute que ça arrive trop souvent dans la pratique.

Sinon, pour pallier aux problèmes de conflit de version, tu peux soit éviter les dépendances à MSVCRT quand tu compiles les libs statiques (je sais pas si c'est possible d'avoir des références externes dans une lib statique… à voir), soit utiliser la même version partout. (Et donc recompiler ton SDL avec la même version de VC++)

Rien d'extraordinaire, quoi.

GoldenCrystal (./55) :
je sais pas si c'est possible d'avoir des références externes dans une lib statique

Des imports ? On peut, et heureusement (sinon tu ne pourrais pas faire de lib statique qui utilise l'API Windows)

Hmm non je pensais pas à des imports mais à des symboles non résolus… ^^
(C'est vrai que c'était pas clair, j'ai pas trouvé le mot sur le coup )

GoldenCrystal (./54) :
Rien d'extraordinaire, quoi.

J'ai déjà recompilé SDL et SDL_image, je sais pas trop comment, ma build/toolchain est plutôt branlante sous Windows, on va laisser comme ça en fait

Kevin Kofler (./52) :
Et au fait, "Miscrosoft", c'est pour dire que ce sont des escrocs?

J'avais cherché sur la page, et pas vu que c'était dans le titre, beau catch de coquille

GoldenCrystal (./56) :
Hmm non je pensais pas à des imports mais à des symboles non résolus... ^^

Tu peux aussi (ta lib statique peut appeler une fonction du code auquel est linkée en utilisant directement son nom, ça peut servir à faire des callbacks/handlers personnalisés sans devoir utiliser de pointeurs de fonctions)