Convention d'appel .lib - Page 1

Bonsoir,
J'utilise Visual Studio 2005 et j'essaie désespérément de créer une librairie qui soit propre et qui ne fonctionne pas qu'en C++.
Pourtant même si je spécifie la convention d'appel dans les propriétés du projet, celle-ci ne change pas, et dans le .lib j'ai toujours un truc très obscur du stlye: ?oslSetTexture@@YAXPAUOSL_IMAGE@@@Z.
J'aimerais vraiment générer (si possible) une librairie avec une convention __cdecl par exemple, ou __stdcall, mais je sais même pas si c'est possible :/
Si quelqu'un pouvait m'éclairer un peu, ce serait très sympa

Edited_793

Tu peux aussi mettre

extern "C" {
  void bidule(int x);
}

pour déclarer des fonctions C dans du code C++

Mes fichiers sont en .cpp. Y'a pas moyen de forcer une convention compatible entre tous les langages?
Parce que si je dois affubler toutes les déclarations de ma lib d'un __cdecl, OSLAPI, extern "C" ou je ne sais quoi bah c'est super chiant :/

Tu veux pouvoir l'utiliser sur plusieurs plateforme ?
Si tu veux l'utiliser uniquement sous windows la stdcall peut suffir. Autrement le extern "c" et les c convention sont de rigueur.
Tu pourras eventuellement definir une macro qui choisi les modificateurs adequat en fonction d'un parametre lequel specifierai le systeme destinataire.

++

Brunni :
Mes fichiers sont en .cpp. Y'a pas moyen de forcer une convention compatible entre tous les langages?
Parce que si je dois affubler toutes les déclarations de ma lib d'un __cdecl, OSLAPI, extern "C" ou je ne sais quoi bah c'est super chiant :/

Ben si tu veux que ta lib soit linkable et C ET C++, y a pas 40 000 solutions, faut utiliser
extern "C" { ... }
C'est la méthode propre, qui permet de prévenir le linker qu'il va linker du code C quand il linke du C++.

Meme si on code en C, avoir un fichier .cpp force le compilateur de Visual Studio a compiler en C++, qu'on utilise de l'objet ou non. Pour utiliser le compilo en mode C "only" il faut que le/s fichier/s aient l'extention .c

J'ai rajouté dans le #include:
extern "C" {
void maFonction(int, int);
}
et j'ai recompilé la lib (dans le fichier .c j'ai pas mis de extern "C"), ensuite j'essaie de l'utiliser (j'#inclus le fichier qui contient extern "C") et j'ai toujours:
[nosmile]main.cpp.text+0x30): undefined reference to 'maFonction(int, int)'
Ma fonction est bien là mais elle s'appelle 'maFonction', du C quoi :/
Ca c'est pour GCC, pareil sur VC++ où je compile la lib en C++ et j'aimerais utiliser dans un prog C (l'inverse j'ai pas essayé vu que VC++ supporte pas le C99).
Si quelqu'un pouvait m'aider svp, ce serait très sympa

Heu VC support pas le C99 ? quel version de visual C/Studio tu as ?

Parce qu'il existe une version qui le supporte ?

VC 2003/2005 oui

Euh non justement (la question était pas innocente)
Il ne supporte qu'une petite partie du C99, que ce soit VC7 comme VC8.

Tu es un pro gcc, ca se sent a 1000 km a la ronde.

ça n'empêche pas qu'il a raison ^^

Edited_794

GCC ne supporte pas le C99 aussi. Seulement une grosse partie.

Mais plus que Visual (saleté de CRT 2005 à la con, pas capable de supporter le snprintf() pourtant enfin standard!!! )

Enfin, pour ton problème, il faut que tes fonctions soit déclarées en extern "C" et définies en extern "C" :

Pour le header (peut être inclus depuis du C ou du C++) :

#ifdef __cplusplus
extern "C" {
#endif

void maFonction(int, int);
int monAutreFonction(char const *);

#ifdef __cplusplus
}
#endif

Pour le fichier source C++, extern "C" { } suffit, sans les #ifdef.
Tu peux aussi précéder chaque fonction de extern "C", sans mettre les accolades.

_snprintf, _snwprintf
Write formatted data to a string.

int _snprintf( char *buffer, size_t count, const char *format [, argument] ... );

int _snwprintf( wchar_t *buffer, size_t count, const wchar_t *format [, argument] ... );

Issu de la doc de visual.

Ca marche enfin, comme un con j'ai fait #ifdef _cplusplus (un seul _) donc c'est pour ça que ça foirait
Merci à vous

snprintf() standard C99: termine TOUJOURS la chaîne par un caractère nul, retourne TOUJOURS la longueur de la chaîne complète (comme si le buffer était infini), accepte les buffers nuls (Permet d'allouer la taille nécessaire).

_snprintf() : ne termine pas la chaîne par un caractère nul, retourne une valeur négative si la chaîne a du être tronquée.
sprintf_s(), c'est pire.
_snprintf_s(), c'est comme _snprintf(), sauf que ça termine la chaîne par un carac. nul. Toujours le même problème de valeur de retourn, et n'accepte pas non plus les buffers nuls.

(je n'ai même pas eu de recherche à faire: tu vois, je m'étais documenté avant de poster).
J'avais posté la question sur un forum micro$oft, pour savoir s'il y avait un équivalent au snprintf() standard. Dans leur efficacité légendaire, ils m'ont redirigé vers sprintf_s() : Ils en sont fiers en plus...

oui, dans le code que j'ai pondu pour mon job d'été c'est plein de code avec des #ifdef WIN32 pour ce genre de fonctions qui ressemblent mais pas trop

Ok. Je l'ai pas ta fonction snprintf_s, j'ai surement un vieux compilateur. De toute maniere, vous savez quoi faire si visual en trop mediocre...

en effet ^^