«

Hello,

I have a quite large library of datastructures implemented in C. All
the datastructures are implemented like this:

/***************************************/

//header file:

typedef struct my_struct my_type;

//implementation

struct my_struct {
// fields in the struct
}

my_type * my_alloc( /* input_args */ ) {
// Create and initialize a my_struct instance.
}

void my_free( my_type * instance ) {
// Free the instance along with all it's fields.
}

// And then various set/get/do_whatever functions

/**************************/

I.e. everything is implemented through opaque pointers, and all
manipulations are based on designated functions which take a pointer
instance as the first argument.

Now - I would like to access this functionality from a C++ program as
well, i.e. I would like to create C++ classes which encapsulate the C
functionality. I have done this manually for some "classes" and that
works OK, but I would strongly like to automate the process. I have
considered writing some Python code to do it, but maybe there is a
better way?

Any tips on how to do this?

Joakim

On Wed, 14 Apr 2010, Joakim Hove wrote:

> I would like to create C++ classes which encapsulate the C functionality

I'd check <http://www.swig.org/>.

Cheers,
lacos

> Just use the library as is. Wrapping it in C++ code doesn't do much but
> change the syntax and that shouldn't matter.– Skjul sitert tekst –

I realize that; myself I am perfectly using the C code, however there
are some people in my organisation with a love/hate relationship with
C/C++ and I am trying to cater to their "needs". So - it is actually
the syntax change (and some maintainance overhead....) I am after.

Regards

Joakim

On 15 avr, 09:17, Joakim Hove <joakim.h...@gmail.com> wrote:
> > Just use the library as is. Wrapping it in C++ code doesn't do much but
> > change the syntax and that shouldn't matter.

It is not totally true, automatic call of alloc/free function is IMO
already an improvement.

>– Skjul sitert tekst –
>
> I realize that; myself I am perfectly using the C code, however there
> are some people in my organisation with a love/hate relationship with
> C/C++ and I am trying to cater to their "needs". So - it is actually
> the syntax change (and some maintainance overhead....) I am after.

A script parsing the headers and generating c++ class could get you a
long way (eventually with meta-informations).

--
Michael

On Thu, 15 Apr 2010, Michael Doubez wrote:

> On 15 avr, 09:17, Joakim Hove <joakim.h...@gmail.com> wrote:
>>> Just use the library as is. Wrapping it in C++ code doesn't do much but
>>> change the syntax and that shouldn't matter.
>
> It is not totally true, automatic call of alloc/free function is IMO
> already an improvement.

Exactly. It's perfectly sensible from C++ programmers already using
exceptions and relying on destructors to expect *all* libraries to conform
to this style. Otherwise they'll have to mix "traditional" error handling
with exceptions, which is worse than any of them alone.

IMO, this hurts most when trying to do UNIX(R) systems programming in
"idiomatic" C++.

("Newsgroups: comp.lang.c++" snipped, because I'm not subscribed to it.)

Cheers,
lacos

On Apr 15, 10:17*am, Joakim Hove <joakim.h...@gmail.com> wrote:
> I realize that; myself I am perfectly using the C code, however there
> are some people in my organisation with a love/hate relationship with
> C/C++ and I am trying to cater to their "needs". So - it is actually
> the syntax change (and some maintainance overhead....) I am after.

All added 'value' is about interface syntax change? Then you are lucky
who is getting paid for doing questionable things. C is fine language
and such interfaces are pretty readable.

Only value that can be added to good C library interface is to enwrap
that my_struct* into proper smart pointer, my_alloc() into factory
function that produces such smart pointer and ... done.

Usually it is C library itself that is refactored into C++ to
introduce polymorphism instead of overly long switch-case chains and
exceptions instead of overly massive return value handling code. These
two things tend to make legacy C hard to maintain.