Cacher des membres dans une structure C

Question

J'ai lu des articles sur la POO en C mais je n'ai jamais aimé le fait qu'on ne puisse pas avoir de membres de données privés comme en C++. Mais il m'est venu à l'esprit que l'on pouvait créer deux structures. L'une est définie dans le fichier d'en-tête et l'autre est définie dans le fichier source.

// =========================================
// in somestruct.h
typedef struct {
  int _public_member;
} SomeStruct;

// =========================================
// in somestruct.c

#include "somestruct.h"

typedef struct {
  int _public_member;
  int _private_member;
} SomeStructSource;

SomeStruct *SomeStruct_Create()
{
  SomeStructSource *p = (SomeStructSource *)malloc(sizeof(SomeStructSource));
  p->_private_member = 42;
  return (SomeStruct *)p;
}

A partir de là, vous pouvez simplement jeter une structure sur l'autre. Est-ce considéré comme une mauvaise pratique ? Ou est-ce que cela se fait souvent ?

Answer 1

sizeof(SomeStruct) != sizeof(SomeStructSource) . Ce site se faire en sorte que quelqu'un vous trouve et vous assassine un jour.

Answer 2

Personnellement, je serais plutôt comme ça :

typedef struct {
  int _public_member;
  /*I know you wont listen, but don't ever touch this member.*/
  int _private_member;
} SomeStructSource;

C'est C après tout, si les gens veulent faire des conneries, ils devraient être autorisés à le faire - pas besoin de cacher des choses, sauf :

Si ce dont vous avez besoin est de garder l'ABI/API compatible, il y a deux approches qui sont plus communes d'après ce que j'ai vu.

• Ne donnez pas à vos clients l'accès à la structure, donnez-leur un handle opaque (un void* avec un joli nom), fournissez des fonctions init/destroy et accessor pour tout. Cela permet de s'assurer que vous pouvez modifier la structure sans même recompiler les clients si vous écrivez une bibliothèque.

• fournir un handle opaque comme partie de votre structure, que vous pouvez allouer comme vous le souhaitez. Cette approche est même utilisée en C++ pour assurer la compatibilité ABI.

Par exemple

 struct SomeStruct {
  int member;
  void* internals; //allocate this to your private struct
 };

Answer 3

Vous l'avez presque, mais vous n'êtes pas allé assez loin.

Dans l'en-tête :

struct SomeStruct;
typedef struct SomeStruct *SomeThing;

SomeThing create_some_thing();
destroy_some_thing(SomeThing thing);
int get_public_member_some_thing(SomeThing thing);
void set_public_member_some_thing(SomeThing thing, int value);

Dans le fichier .c :

struct SomeStruct {
  int public_member;
  int private_member;
};

SomeThing create_some_thing()
{
    SomeThing thing = malloc(sizeof(*thing));
    thing->public_member = 0;
    thing->private_member = 0;
    return thing;
}

... etc ...

Le fait est que, ici maintenant, les consommateurs ont pas de connaissance des éléments internes de SomeStruct, et vous pouvez le modifier en toute impunité, en ajoutant et en supprimant des membres à volonté, même sans que les consommateurs aient besoin de recompiler. Ils ne peuvent pas non plus "accidentellement" munger des membres directement, ou allouer SomeStruct sur la pile. Bien sûr, cela peut aussi être considéré comme un inconvénient.

Answer 4

Je ne recommande pas l'utilisation du modèle public struct. Le modèle de conception correct, pour la POO en C, est de fournir des fonctions pour accéder à toutes les données, sans jamais permettre un accès public aux données. Les données de la classe doivent être déclarées à la source, afin d'être privées, et être référencées de manière directe, où Create y Destroy fait l'allocation et la libération des données. De cette manière, le dilemme public/privé n'existera plus.

/*********** header.h ***********/
typedef struct sModuleData module_t' 
module_t *Module_Create();
void Module_Destroy(module_t *);
/* Only getters and Setters to access data */
void Module_SetSomething(module_t *);
void Module_GetSomething(module_t *);

/*********** source.c ***********/
struct sModuleData {
    /* private data */
};
module_t *Module_Create()
{
    module_t *inst = (module_t *)malloc(sizeof(struct sModuleData));
    /* ... */
    return inst;
}
void Module_Destroy(module_t *inst)
{
    /* ... */
    free(inst);
}

/* Other functions implementation */

D'un autre côté, si vous ne voulez pas utiliser Malloc/Free (qui peut être une surcharge inutile dans certaines situations), je vous suggère de cacher la structure dans un fichier privé. Les membres privés seront accessibles, mais c'est à la charge de l'utilisateur.

/*********** privateTypes.h ***********/
/* All private, non forward, datatypes goes here */
struct sModuleData {
    /* private data */
};

/*********** header.h ***********/
#include "privateTypes.h"
typedef struct sModuleData module_t; 
void Module_Init(module_t *);
void Module_Deinit(module_t *);
/* Only getters and Setters to access data */
void Module_SetSomething(module_t *);
void Module_GetSomething(module_t *);

/*********** source.c ***********/
void Module_Init(module_t *inst)
{       
    /* perform initialization on the instance */        
}
void Module_Deinit(module_t *inst)
{
    /* perform deinitialization on the instance */  
}

/*********** main.c ***********/
int main()
{
    module_t mod_instance;
    module_Init(&mod_instance);
    /* and so on */
}

Answer 5

Ne fais jamais ça. Si votre API supporte tout ce qui prend SomeStruct comme paramètre (ce qui devrait être le cas), ils pourraient en allouer un sur une pile et le passer. Vous obtiendrez des erreurs majeures en essayant d'accéder au membre privé puisque celui que le compilateur alloue pour la classe client ne contient pas d'espace pour lui.

La façon classique de cacher les membres d'une structure est d'en faire un void*. Il s'agit en fait d'un handle/cookie que seuls les fichiers d'implémentation connaissent. Presque toutes les bibliothèques C font cela pour les données privées.