6
votes

Comment cacher les fonctions d'assistant d'API publiques en C

Je travaille sur un projet et j'ai besoin de créer une API. J'utilise des sockets pour communiquer entre le serveur (mon application) et les clients (les autres applications à l'aide de mon API).

Ce projet est en C ++ p>

Je viens d'un fond Linux et c'est mon premier projet à l'aide de Windows, Visual Studio 2008 et des bibliothèques DLL. P>

J'ai une communication fonctionnant entre le client et le serveur, mais j'en ai une dupliquée sur les deux projets. Je souhaite créer une bibliothèque (probablement un fichier DLL), que les deux projets peuvent être liés à donc je n'ai pas à maintenir le code supplémentaire. P>

Je dois également créer la bibliothèque qui a l'API que j'ai besoin de mettre à la disposition de mes clients. Dans les fonctions d'API que je veux, les appels sont les appels vers ces fonctions d'assistance qui sont "dupliqué de code", je ne veux pas exposer ces fonctions à mon client, mais je veux que mon serveur puisse utiliser ces fonctions. Comment puis-je faire cela? P>

Je vais essayer de clarifier avec un exemple. C'est ce que j'ai commencé avec. P>

Projet serveur: P>

//Server Project:
int Server_GetPacket(SOCKET sd);

// library with public and private types
//  private API (not exposed to my client)
int ReceiveAll(SOCKET sd, char *buf, int len);
int VerifyLen(char *buf);
//  public API (header file available for client)
int Client_SendCommand(int command);
int Client_GetData(int command, char *buf, int len);


0 commentaires

3 Réponses :


5
votes

Utilisez

static int ReceiveAll(SOCKET sd, char *buf, int len);


2 commentaires

Si je déclare les fonctions privées comme statique et les mettre dans une bibliothèque, serais-je en mesure de l'appeler à partir de mon projet serveur, c'est-à-dire de server_getpacket ()?


Les fonctions dans le même fichier les verront. D'autres ne le feront pas.



1
votes

Si vous mettez les fonctions "privées" dans une DLL et les rendormes de manière externe par des moyens normaux (par exemple, appelé par un processus chargé de la bibliothèque), ils seront également "publics" pour d'autres. Il est possible d'obscurcir les noms et les choses comme ça, mais ce n'est probablement pas une bonne solution.

Il serait peut-être préférable de les mettre dans une bibliothèque liée statiquement liée par opposition à une DLL. Note, cependant, que même dans ce cas, quelqu'un peut démonter le binaire évidemment et arriver au code.


6 commentaires

Je suis plus préoccupé par la fourniture d'une API propre qui ne contient que les fonctions publiques. Je veux juste éviter que toutes les fonctions d'assistant soient faisant partie de l'API. Vous dites que je crée une bibliothèque statique pour les fonctions "privées", puis mettez les fonctions "API publiques" dans une DLL?


@EMGE: C'est une possibilité. Cela dépend un peu de votre architecture de développement si cela a du sens. Une solution "plus simple" serait simplement d'inclure simplement les fichiers source de votre projet et de les construire directement dans le binaire. Ensuite, construisez l'API publique DLL en tant que projet séparé avec les fonctions exportées souhaitées.


Merci, j'aime la solution "plus simple", mais comment puis-je contourner la question du code dupliqué si je n'inclut simplement que le fichier source de mon projet et que l'API DLL doit utiliser certaines de ces mêmes fonctions?


@EMGE: Je ne comprends probablement pas la question. Mais vous ne pouvez pas simplement mettre le code partagé dans quelque chose comme SharedCode.c, puis inclure celui-ci (ou plusieurs fichiers selon les besoins) dans les projets client et serveur? Le code est intégré aux deux projets, mais je ne pense pas que cela viole la règle sèche.


Ok merci, je vais essayer d'avoir un fichier commun.c et voyez si je peux tout faire fonctionner de cette façon. Quelle est la règle sèche?


@Emge: Dry = Ne vous répétez pas. Désolé - je n'aurais pas dû utiliser des acronymes. en.wikipedia.org/wiki/don't_repeat_yourself



0
votes

Si vous souhaitez uniquement exposer certaines fonctions dans votre DLL, vous pouvez créer un fichier exportation (dllname.def) que vous donnez à la liaison lorsque vous construisez le projet. Ce fichier Exports contient une liste des fonctions que vous souhaitez rendre publiquement disponibles pour les applications à l'aide de votre DLL.

Voir l'article MSDN ici Pour plus d'informations à ce sujet.

Je pense que vous pouvez également réaliser des fonctionnalités similaires en utilisant le mot-clé __ DeclSpec (dllexport) sur les fonctions que vous souhaitez exporter.


0 commentaires