0

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.

Fooko R.
  • 129
  • 1
  • 10

2 Answers2

5

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.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • I would really like avoid using a `struct` as I wrote in my question, isn't there another way? – Fooko R. Feb 13 '12 at 23:49
  • No, I don't believe there is an alternative - unless you count a `union` as an alternative to a `struct`. Well, there's the old fallback of `void *`, but that's far worse than an incomplete structure type. If you really want to get gruesome, you can let the users think 'Oh, it is a structure type' while in your code, you do `long double *my_value = (long double *)big_t_pointer_from_interface;`. If you want better abstraction, use C++, but you'll be defining a class in C++ if you do that, so we're back to square one - No, there isn't a real alternative to defining a struct. – Jonathan Leffler Feb 13 '12 at 23:58
  • One of the advantages of the opaque (structure) type is that it gives a better margin of safety than using `void *`; your compiler will complain if the user passes a pointer to `int` or a pointer to a `double` where `big_t *` is expected if `big_t` is an opaque type. If `big_t *` is an alias for `void *`, then you can pass any old pointer into the function. – Jonathan Leffler Feb 14 '12 at 00:00
2

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)?

Ed S.
  • 122,712
  • 22
  • 185
  • 265
  • 2
    I care! If a user sees `long double` perhaps he starts to use `long double` instead of `big` let's say, and after a while I would like to chage `big` to `char *`. Then the user's code wont' work. By saying `typedef struct foo big;` I don't give away the definition of my `struct`, user can't know what are the fields of `struct foo`. – Fooko R. Feb 13 '12 at 23:41
  • 2
    That's not your problem, though. That's the user's problem because they refused to use your API. – David Brown Feb 13 '12 at 23:45
  • 2
    @DavidBrown I don't think that's a valid argument. E.g. you could define all your fields in a Java class to be `public` and just say to the user **don't use the fields**, doesn't seem correct way of creating a API (giving away the **inside** information of it). – Fooko R. Feb 13 '12 at 23:51
  • 2
    @FookoR.: You're right, all those library designers who have been doing this for years are all wrong. Right? Your analogy is not correct as that is simply bad practice in Java and easily avoidable. Look, you *cannot* get around this in a practical way. Writing a library doesn't mean that you coddle your users at each and every step. You do your best to provide a clean API, and typedefs for types that may change are perfectly acceptable. If your users decide to write `long double` everywhere then that is their problem. – Ed S. Feb 13 '12 at 23:59
  • 1
    `all those library designers who have been doing this for years are all wrong.` if they do all their fields `public`, I think they are. – Fooko R. Feb 14 '12 at 00:00
  • @FookoR.: You didn't read very carefully... this is not Java, stop making useless and incorrect analogies. – Ed S. Feb 14 '12 at 00:02
  • @EdS. I appreciate the fact that you tried answering my question. You should give a look at Johnathan answer, a much better one. But if you are tired because of working too much in improving patient care through digital pathology or for other personal reasons, that's not **my** fault. So, please be more kind and stop using irony in your posts. – Fooko R. Feb 14 '12 at 00:09
  • @FookoR.: Hmmm, well, I'm sorry, I didn't intend to be "mean", I'm just saying you're trying to solve a problem that doesn't exist. I have been programming in C and C++ for a long time and typedefs are used all over the place. It's standard practice in a lot of scenarios. – Ed S. Feb 14 '12 at 00:25
  • @EdS. I'm sorry too :). Seems you are correct. +1 and thanks for answering my question :) – Fooko R. Feb 14 '12 at 03:28