Discussion :

[mnaulet]

Bonjour,
J'ai redéfinit la méthode fwrite.
Dans la nouvelle fonction fwrite, je voudrais effectuer un traitement différent selon l'appelant. Est-il possible de savoir qui appelle fwrite sans en changer le prototype. Je voudrais en gros savoir d'où a été appelé ma fonction.
L'appel se fait depuis un code C qui appelle le fwrite d'une dll en c++.
Merci

[loufoque]

Est-il possible de savoir qui appelle fwrite

Non.

[roulious]

On peut, en faisant appel aux fonctions de profiling du compilateur. Avec les outils GNU, voir là : http://www-128.ibm.com/developerwork...ry/l-graphvis/

Ton code va par contre devenir beaucoup plus lent, puisque le compilateur ajoute des instructions au début et à la fin de chaque fonction. Pourquoi exactement veux-tu faire une chose pareille ?

[mnaulet]

Merci,
Je vais lire cette doc.
J'en ai besoin car je dois faire un traitement spécifique (conversion big endian/little endian) ou pas, avant le fwrite selon le programme qui appelle. Le problème est que je ne peut pas modifier le code appelant. Je veut donc faire cette opération dans le code appelé

[icareo]

C'est tout à fait possible :/ .... du moins avec vc++ (jamais essayé avec d'autres) suffit de redéfinir une fonction qui prend pour paramètre une chaine de caractères...et utiliser les macros __FUNCTION__ __LINE__ et __FILE__ (a priori, c'est __FUNCTION__ qui t'interesse il me semble..)
Pour mon gestionaire de mémoire par exemple j'ai :

#define new(sz) c_malloc( sz , __FILE__,__LINE__,__FUNCTION__ )
#define delete(ptr) c_free(ptr)

#define malloc(sz) c_malloc( sz , __FILE__,__LINE__,__FUNCTION__ )
#define free(ptr) c_free(ptr)

[Médinoc]

Attention: pour cela, il faut pouvoir au moins recompiler le code appelant.

[b Oo]

On peut, en faisant appel aux fonctions de profiling du compilateur. Avec les outils GNU, voir là : http://www-128.ibm.com/developerwork...ry/l-graphvis/

Salut roulious,
merci beaucoup pour le lien. Je vais pouvoir regarder les méthodes appelées, et débugger plus rapidement, ...

[loufoque]

Il serait bon de ne pas utiliser des hacks ignobles pour pallier à tes problèmes de conception.

[Luc Hermitte]

L'approche ne me parait pas bonne.
Généralement, on suppose que ce qui transite au niveau des interfaces socket ou fichier sera toujours dans un même alignement. Typiquement le network byte order qui correspond à du big endian si mes souvenirs sont bons.
Du coup, au niveau des interfaces, tu appliques des fonctions de convertion dont le corps est fonction de l'architecture sur laquelle tu tournes -> ntohl & cie.
Et dans ton programme, tu manipuleras les données natives C++.

PS: oublie les hack GCC avec des dll en C++.