Question about a library C API

Discussion in 'C Programming' started by Francis Moreau, Jul 20, 2009.

  1. 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
     
    Francis Moreau, Jul 20, 2009
    #1
    1. Advertising

  2. Francis Moreau

    Chris Dollin Guest

    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
     
    Chris Dollin, Jul 20, 2009
    #2
    1. Advertising

  3. On Jul 20, 10:34 am, Chris Dollin <> 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
     
    Francis Moreau, Jul 20, 2009
    #3
  4. Francis Moreau

    Chris Dollin Guest

    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
     
    Chris Dollin, Jul 20, 2009
    #4
  5. On Jul 20, 11:07 am, Chris Dollin <> 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.
     
    Francis Moreau, Jul 20, 2009
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shlomo Anglister
    Replies:
    1
    Views:
    433
    Default User
    Aug 2, 2004
  2. Praveen, Tayal (IE10)
    Replies:
    0
    Views:
    396
    Praveen, Tayal (IE10)
    Mar 17, 2005
  3. John123

    Profiling API or Membership API

    John123, Oct 20, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    399
    John123
    Oct 20, 2006
  4. George2

    platform specific API or C standard API

    George2, Nov 12, 2007, in forum: C Programming
    Replies:
    13
    Views:
    774
    Tor Rustad
    Nov 13, 2007
  5. Timothy Grant
    Replies:
    5
    Views:
    440
    Timothy Grant
    Aug 6, 2008
Loading...

Share This Page