simulating private member functions--static linkage

Discussion in 'C Programming' started by Bill Pursell, Apr 27, 2006.

  1. Bill Pursell

    Bill Pursell Guest

    I've been thinking of doing things like the following:

    [tmp]$ cat foo.h

    struct foo{
    int a;
    void (*init)(struct foo *, int);
    };

    void new_foo(struct foo *self);

    [tmp]$ cat foo.c
    #include "foo.h"

    static void init(struct foo *self, int a)
    {
    self->a = a;
    }


    void new_foo(struct foo *self)
    {
    self->init=init;
    }

    [tmp]$ cat a.c

    #include "foo.h"
    #include <stdio.h>

    int main()
    {
    struct foo f;
    new_foo(&f);
    f.init(&f,10);
    /* can't call init from foo.c directly, because it was declared
    static */
    }

    Basically, I'm providing what in other languages might be called
    (pseudo)-private member function to foo. I don't understand the static
    linkage mechanism well enough to know if this is a bad idea. It seems
    to work well, but I've only used it in very small toy test cases. Are
    there any reasons to avoid this type of construction?
    Bill Pursell, Apr 27, 2006
    #1
    1. Advertising

  2. Bill Pursell

    Guest

    Bill Pursell wrote:
    > I've been thinking of doing things like the following:
    >
    > [tmp]$ cat foo.h
    >
    > struct foo{
    > int a;
    > void (*init)(struct foo *, int);
    > };
    >
    > void new_foo(struct foo *self);
    >

    // I think you should declare the function's type in here.
    void init(struct foo *self, int a)
    > [tmp]$ cat foo.c
    > #include "foo.h"
    >
    > static void init(struct foo *self, int a)
    > {
    > self->a = a;
    > }
    >
    >
    > void new_foo(struct foo *self)
    > {
    > self->init=init;
    > }
    >
    > [tmp]$ cat a.c
    >
    > #include "foo.h"
    > #include <stdio.h>
    >
    > int main()
    > {
    > struct foo f;
    > new_foo(&f);
    > f.init(&f,10);
    > /* can't call init from foo.c directly, because it was declared
    > static */
    > }
    >
    > Basically, I'm providing what in other languages might be called
    > (pseudo)-private member function to foo. I don't understand the static
    > linkage mechanism well enough to know if this is a bad idea. It seems
    > to work well, but I've only used it in very small toy test cases. Are
    > there any reasons to avoid this type of construction?
    , Apr 27, 2006
    #2
    1. Advertising

  3. Bill Pursell

    50h d'essai Guest

    Hello Bill Pursell, All !

    > I've been thinking of doing things like the following:
    >
    > [tmp]$ cat foo.h
    >
    > struct foo{
    > int a;
    > void (*init)(struct foo *, int);
    > };
    >
    > void new_foo(struct foo *self);
    >
    > [tmp]$ cat foo.c
    > #include "foo.h"
    >
    > static void init(struct foo *self, int a)
    > {
    > self->a = a;
    > }
    >


    <snip>

    >
    > [tmp]$ cat a.c
    >
    > #include "foo.h"
    > #include <stdio.h>
    >
    > int main()
    > {
    > struct foo f;
    > new_foo(&f);
    > f.init(&f,10);
    > /* can't call init from foo.c directly, because it was declared
    > static */
    > }


    can't call init from a.c maybe ?


    > Basically, I'm providing what in other languages might be called
    > (pseudo)-private member function to foo. I don't understand the static
    > linkage mechanism well enough to know if this is a bad idea. It seems
    > to work well, but I've only used it in very small toy test cases. Are
    > there any reasons to avoid this type of construction?


    In C AFAIK function is considered as a global object. This avoids to
    place keyword extern every time. static keyword limits the range of
    visibility of that function to source file within it is declared. Hope
    it helps.

    --
    50h d'essai
    06300 Nice
    e-mail: katsuo_harada_evil_does (at) hotmail (.) com
    All said above is IMHO
    50h d'essai, Apr 27, 2006
    #3
  4. Bill Pursell

    Guest

    you are only declare a function type pointer.so it need to be assigned,
    then you can call it.
    , Apr 27, 2006
    #4
  5. In article <>, "Bill Pursell" <> writes:
    > I've been thinking of doing things like the following:
    >
    > [snip code that assigns a static function's address to a function
    > pointer in a structure, then calls the function through that pointer]
    >
    > Basically, I'm providing what in other languages might be called
    > (pseudo)-private member function to foo. I don't understand the static
    > linkage mechanism well enough to know if this is a bad idea. It seems
    > to work well, but I've only used it in very small toy test cases. Are
    > there any reasons to avoid this type of construction?


    It's safe; static linkage limits the visibility of a function, but
    you're allowed to call that function from a scope where it isn't
    visible via a function pointer. This sort of construct is commonly
    used to implement polymorphism in C (that is, it's commonly used in
    programs where the author wants to implement polymorphism).

    I think it's a useful technique. There are many possible variations;
    for example, some people prefer to write factory functions that
    allocate the structure for the caller. But the short answer is that
    what you're doing is fine.

    (Of course, there are always reasons to avoid any construction in
    some circumstances; you wouldn't do this for every single function
    in your program. Used judiciously it's quite useful.)

    --
    Michael Wojcik

    The presence of those seeking the truth is infinitely preferable to
    the presence of those who think they've found it. -- Terry Pratchett
    Michael Wojcik, May 1, 2006
    #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. qazmlp
    Replies:
    0
    Views:
    342
    qazmlp
    Jul 17, 2003
  2. Neno
    Replies:
    2
    Views:
    3,236
  3. Doug Eleveld
    Replies:
    3
    Views:
    746
    Mark McIntyre
    Oct 25, 2003
  4. tropos
    Replies:
    3
    Views:
    449
  5. Replies:
    1
    Views:
    582
    Michael DOUBEZ
    Sep 12, 2008
Loading...

Share This Page