Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Question about a library C API

Reply
Thread Tools

Question about a library C API

 
 
Francis Moreau
Guest
Posts: n/a
 
      07-20-2009
Hello,

I have to use a library which has an API that I find a bit weird for
the C language, so I'd like to get some feedbacks to know if it's a
good API design for C or it's just a bad practice.

Basically this API is an object oriented API.

To allocate an object I have to use for example:

o = alloc_object();

Once I have a reference on that object, I have directly access to its
internal data structure. So to call its methods I can do this:

o->m1();

And this is what I find weird. I would do instead:

m1(o);

which is more natural when doing C (probably because all very used
lib, like the libc, pthread... don't do this) and has the advantage to
not expose the internal data of 'o'.

Could anybody tell me if there is one good reason to do so ?

Thanks
 
Reply With Quote
 
 
 
 
Chris Dollin
Guest
Posts: n/a
 
      07-20-2009
Francis Moreau wrote:

> I have to use a library which has an API that I find a bit weird for
> the C language, so I'd like to get some feedbacks to know if it's a
> good API design for C or it's just a bad practice.
>
> Basically this API is an object oriented API.
>
> To allocate an object I have to use for example:
>
> o = alloc_object();
>
> Once I have a reference on that object, I have directly access to its
> internal data structure. So to call its methods I can do this:
>
> o->m1();
>
> And this is what I find weird. I would do instead:
>
> m1(o);
>
> which is more natural when doing C (probably because all very used
> lib, like the libc, pthread... don't do this) and has the advantage to
> not expose the internal data of 'o'.
>
> Could anybody tell me if there is one good reason to do so ?


Different objects of the same (super)type can have different
implementations of m1. [eg: streams, where FILE*-based streams
and from-memory type streams are both streams.]

m1 is not a global name, so different types don't tread on each
others method names. [There are lots of different things one might
mean by `append`, `next`, `parse`, `save`, &co.]

[These advantages should not be taken as an endorsement of the
API as presented.]

--
"This town is run by seven megalomaniac wizards!" /Archer's Goon/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

 
Reply With Quote
 
 
 
 
Francis Moreau
Guest
Posts: n/a
 
      07-20-2009
On Jul 20, 10:34*am, Chris Dollin <(E-Mail Removed)> wrote:
> Francis Moreau wrote:
> > I have to use a library which has an API that I find a bit weird for
> > the C language, so I'd like to get some feedbacks to know if it's a
> > good API design for C or it's just a bad practice.

>
> > Basically this API is an object oriented API.

>
> > To allocate an object I have to use for example:

>
> > o = alloc_object();

>
> > Once I have a reference on that object, I have directly access to its
> > internal data structure. So to call its methods I can do this:

>
> > o->m1();

>
> > And this is what I find weird. I would do instead:

>
> > m1(o);

>
> > which is more natural when doing C (probably because all very used
> > lib, like the libc, pthread... don't do this) and has the advantage to
> > not expose the internal data of 'o'.

>
> > Could anybody tell me if there is one good reason to do so ?

>
> Different objects of the same (super)type can have different
> implementations of m1. [eg: streams, where FILE*-based streams
> and from-memory type streams are both streams.]


sure but you get the same with:

void m1(struct object *o)
{
o->m1(o);
}

depending on what 'o' really is, m1 can be different.

>
> m1 is not a global name, so different types don't tread on each
> others method names. [There are lots of different things one might
> mean by `append`, `next`, `parse`, `save`, &co.]


well, if I have to design a lib API, I would never name a function of
that lib: 'append', that would be silly...

thanks
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-20-2009
Francis Moreau wrote:

> well, if I have to design a lib API, I would never name a function of
> that lib: 'append', that would be silly...


No matter what name you pick [1], some other library will have an
equally good claim on the name [2]. `append`, etc, are just convenient
examples.

[1] Namespace prefixing help, but just pushes the problem up one
layer. Long names help, but push the code toward unreadability.

[2] There are probably too few concepts being librified to spread
out the names.

--
"This town is run by seven megalomaniac wizards!" /Archer's Goon/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

 
Reply With Quote
 
Francis Moreau
Guest
Posts: n/a
 
      07-20-2009
On Jul 20, 11:07*am, Chris Dollin <(E-Mail Removed)> wrote:
> Francis Moreau wrote:
> > well, if I have to design a lib API, I would never name a function of
> > that lib: 'append', that would be silly...

>
> No matter what name you pick [1], some other library will have an
> equally good claim on the name [2]. `append`, etc, are just convenient
> examples.
>


If you really insist on that point, I think the problem is still there
since the object needs to be allocated by a global function...

I agree this issue is less frequent though but as I said, I think it's
not real issue IMHO.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
platform specific API or C standard API George2 C Programming 13 11-13-2007 06:29 PM
.Net Profiler API in 64 bit windows -FunctionMapper callback API =?Utf-8?B?TGVv?= Windows 64bit 0 09-05-2007 06:10 PM
Profiling API or Membership API John123 ASP .Net 0 10-20-2006 03:18 PM
Calling the C API from Python and Python program from same C API -bidirectional Praveen, Tayal (IE10) Python 0 03-17-2005 06:33 AM
What API replaces the unlock API that existed in gcc 2.9.3? Shlomo Anglister C++ 1 08-02-2004 06:50 PM



Advertisments