Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 122 563 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
321
Comme j'ai dit, il y a un petit peu de portage a faire: en gros, faut faire un header de compatibilite, qui import dlfcn.h sous posix et windows.h sous windows, puis remplacer le void* pour le handle library par un typedef qui est remplace comme il faut selon la plateforme. Un truc du genre, typiquement:

Citation :


#ifndef LOCAL_H
#define LOCAL_H

#if _WIN32
#include <windows.h>
inline void* dlopen(const char* name) { return LoadLibrary(name); }
inline void* dlsym(void* hdl, const char* sym)
{
return GetProcAdress((HMODULE)hdl, name);
}
#else
/* POSIX (Mac OS X not included) case */
#include <dlfcn.h>
#endif

#endif



Je voulais tester ce genre de trucs, mais comme VS me chie a la gueule pour du code qui ne devrait pas poser de pbs (les typedef de pointeurs de fonctions pour le callback plug->hote et le callback hote->plug), j'ai eu la flemme de tester.

Ressayerai ce soir sur mon minimac avec Xcode, pour voir si ca vient de VS ou d'un truc tout con que j'ai pas compris
322
Ah pardon, je croyais que tu cherchais à compiler le code que tu as mis dans un post précédent. Euh, là, sans le code sous les yeux ni les messages d'erreur de visual, je ne vois pas bien comment on pourrait t'aider :nawak: Bonne chance donc ;)
323

Citation :
Ah pardon, je croyais que tu cherchais à compiler le code que tu as mis dans un post précédent.



Je connais pas grand chose a la prog windows, mais quand meme, je m'attendais pas a ce que le code pour charger une librairie soit le meme ;)

Sinon, le code qui compilait pas, c'est parce que VS est super mauvais pour ses messages d'erreur... Le __cdecl qui ne sert a je ne sais quoi sous windows doit etre parenthese avec le nom de la variable dans une declaration de pointeur de fonction :nawak:
324
> Wolfen, j'ai mis a jour le code avec un .sln pour visual studio express 2005.

http://www.ar.media.kyoto-u.ac.jp/members/david/pyvst.zip

Donc la, t'as deja de quoi compiler l'executable qui te montre un peu comment utiliser les auto_ptr (concretement, tu as un hote VST hyper basique, la).

Si je suis motive ce soir, je regarde comment installer le combo boost+python, et ca devrait rouler. Le truc chiant, ca doit etre de voir comment compiler une extension python avec VS, parce que visiblement, ca a l'air d'etre bien different a ce niveau la entre windows et UNIX.
325
Perso, j'utilise boost/python avec cygwin et je compile le tout en utilisant les distutils (un bon vieux setup.py).
Je tenterais bien de passer sous VS Express, simplement pour voir si CL est plus rapide que GCC qui prends pas loin d'une heure à compiler et autant à linker :furieux: sur un P4 3GHz avec ses maigres 512 Mo de RAM.
Des retours d'expérience ?
My name is john, '_' john.
326
Perso, j'aime pas cygwin pour compiler, parce que ca prend un temps fou: deja de base, gcc n'est pas super rapide pour compiler, mais surtout, l'emulation au dessus de cygwin est super lourde.

Pour compiler du code "simple" sous windows, pendant un temps, je cross-compilais depuis linux avec mingwin. Maintenant, de temps en temps, pour certains projets, j'utilise scons pour le systeme de build, qui est cense prendre en charge les differences de plateformes automatiquement.
327
A un moment, j'utilisais conjointement mingw et VC (et même cygwin un temps) pour compiler un projet, y a pas photo, VC compilait nettement plus vite. Maintenant faut voir si ton projet est facilement "portable" sur VC, parce que tu risques de perdre pas mal de temps dessus si t'as pas pris les bonnes dispositions dès le départ ;)
328
Non mais attention, la lenteur cygwin ou mingw provient avant tout de l'emulation de tout ce qu'il y a autour. Sur la meme machine, entre gcc sous linux et gcc mingw sous windows (meme version de gcc, compile a la main), il y a un rapport de 2 a 3 facile pour la vitesse.

Par exemple, tout ce qui est makefile + shell, c'est pas top sous windows, car windows a des processus tres lourds, contrairement aux unix en general, et en particulier linux, ou la creation de processus devient de plus en plus legere. Ensuite, bash sous mingw est extrememement lent, je pense que la moitie du temps au moins passe a la compilation d'un projet sous makefile n'est pas prise par gcc (le fait que windows n'ait pas d'office un environnement shell me depasse: cmd.exe ne supporte meme pas le copier coller, les capacites d'edition de ligne sont catastrophiques, c'est vraiment intolerable pour moi de bosser la dessus... C'est quand meme pas complique d'ecrire un remplacant de cmd.exe, merde. Meme powershell utilise encore le meme environnement graphique qui est toujours aussi pourri...).

Si tu utilises mingw sous linux, pour faire du cross compiling, tu verras que niveau rapidite de compilation, ca n'a rien a voir. Et apres, tu peux faire tourner sous wine. Ca parait bourrin, mais c'est assez pratique en fait. Le probleme est lorsque tu commences a dependre de pas mal de librairies externes
329
Bonnjour à tous, j'ai une petite question à vous poser. Je ne suis pas DU TOUT programmeur, mais il m'arrive à l'occasion de bricoler de petits modules très très simples en c++ pour synthEdit (synthétiseur modulaire). J'utilise un IDE se nommant "code::blocks" pour cela. Le connaissez vous et qu'en pensez vous?
En compilant avec ce dernier, certains bugs que j'ai avec dev c++ disparaissent; comment est ce possible puisqu'il s'agit du même "compilateur" si j'ai bien compris?
330

Citation : Si tu utilises mingw sous linux, pour faire du cross compiling, tu verras que niveau rapidite de compilation, ca n'a rien a voir.


J'ai jamais penser à faire ca, c'est compliqué à mettre en eouvre? mais on peut lié quand meme avec des librairies dynamique? ca doit avoir ses limites non? (je suis très très intéréssé par ca, car je suis jamais arrivé à compiler correctement du code avec cygwin, j'ai tjs des erreurs con que je n'ais pas avec gcc).