简体   繁体   中英

Hide type definition in C

I have a .c file (a library of functions) with a function and a definition like this:

typedef long double big;
big foo(int x) { ... }

I want to create an interface of this library, an .h . So I do:

typedef long double big;
big foo(int);

and remove the typedef long double big; from the .c file. But by doing so I give away the type definition of big in my interface, so it's not really a clean interface. Any ideas how to fix that?

I know I could do this in my .c file:

struct foo {
  long double;
};

and then in the .h file do:

typedef struct foo big;
big foo(int);

But it seems waste to create a struct for just one field, plus I should use the . operator whenever I want to read a big .

If the type is never going to get more complex than long double , then it probably isn't worth having conniptions about hiding it more. If it might need to become more complex, then you can consider using an opaque type. In your public header, big.h , you use:

#ifndef BIG_H_INCLUDED
#define BIG_H_INCLUDED
typedef struct big big_t;

extern big_t *foo(int);

...

#endif

All the functions will take and return pointers to the big_t type. This is all you can do with incomplete types like that. Note that your customers cannot allocate any big_t values for themselves; they don't know how big the type is. It means you'll probably end up with functions such as:

extern big_t *big_create(void);
extern void   big_destroy(big_t *value);

to create and destroy big_t values. Then they'll be able to do arithmetic with:

extern big_errno_t big_add(const big_t *lhs, const big_t *rhs, big_t *result);

Etc. But because they only have an opaque, incomplete type, they cannot reliably go messing around inside a big_t structure. But note that you are constrained to using pointers in the interface. Passing or returning values requires complete types, and if the type is complete, users can investigate its inner workings.

In the implementation header, bigimpl.h , you'll have:

#ifndef BIGIMPL_H_INCLUDED
#define BIGIMPL_H_INCLUDED
#include "big.h"

struct big
{
    ...whatever the details actually are...
};

#endif

And your implementation code will only include bigimpl.h , but that includes big.h . The main issue here is making sure you know how the memory allocations are handled.

Sometimes this technique is worthwhile. Often it is not really necessary. You'll need to make the assessment for yourself.

and remove the typedef long double big; from the .c file. But by doing so I give away the type definition of big in my interface, so it's not really a clean interface.

How so? Who cares if users of your code can see the typedef? How does it hurt... anything? They need a way to use your typedef and this is how it is done. Sounds like a theoretical problem to me that has no appreciable ill effects. You're worrying about the wrong thing(s).

But tit seems waste to create a struct for just one field, plus I should use the . operator whenever I want to read a big.

Yup, that is silly. Also, now you've given away the definition of your struct! Oh no! How is that any different than exposing the typedef (or any other type)?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM