C/C++ abstraction layer

Discussion in 'C++' started by jis, Jan 28, 2013.

  1. jis

    jis Guest

    Hello guys,

    please help me with following problem.

    I have a.c which includes a.h
    i have b.c which includes b.h
    i have b.h which includes c.h (c.lib included)

    a.c uses some functions which are defined in c.lib.
    so i included b.h in a.h therby including c lib functions.

    but iam writing something like hardware abstraction layer.
    I dont want a.c access c.lib functions directly.
    One way is to include c.h in b.c instead of b.h

    What would be the standard pro way to do this.

    Please help me. (using visual studio 2010 express on windows 7)

    thanks,
    jis
     
    jis, Jan 28, 2013
    #1
    1. Advertising

  2. jis

    Ian Collins Guest

    jis wrote:
    > Hello guys,
    >
    > please help me with following problem.
    >
    > I have a.c which includes a.h
    > i have b.c which includes b.h
    > i have b.h which includes c.h (c.lib included)
    >
    > a.c uses some functions which are defined in c.lib.
    > so i included b.h in a.h therby including c lib functions.
    >
    > but iam writing something like hardware abstraction layer.
    > I dont want a.c access c.lib functions directly.
    > One way is to include c.h in b.c instead of b.h
    >
    > What would be the standard pro way to do this.


    Either link time substitution or interposition. Both allow you to use
    the normal headers (provided the functions you want to replace aren't
    written inline or as macros) and substitute your own definitions.

    Neither of these are really C++ language features, so you would be
    better off asking on a platform specific group.

    --
    Ian Collins
     
    Ian Collins, Jan 28, 2013
    #2
    1. Advertising

  3. On 1/28/2013 2:21 PM, jis wrote:
    > please help me with following problem.
    >
    > I have a.c which includes a.h
    > i have b.c which includes b.h
    > i have b.h which includes c.h (c.lib included)
    >
    > a.c uses some functions which are defined in c.lib.
    > so i included b.h in a.h therby including c lib functions.


    BAD IDEA(tm). If 'a.c' uses functions that are declared in c.h, then
    a.c should include c.h. *Never* rely on pulling some needed header via
    some other header.

    > but iam writing something like hardware abstraction layer.
    > I dont want a.c access c.lib functions directly.


    Huh? Didn't you just write that "a.c uses some functions that are ..."?

    Are you saying you want to rewrite a.c so it does NOT any longer use any
    functions from c.h (c.lib)?

    > One way is to include c.h in b.c instead of b.h


    You said nothing about b.c actually needing c.lib. I presume it, but I
    am not necessarily convinced it's necessary. Yet.

    > What would be the standard pro way to do this.


    To do what, exactly?

    Are you going to introduce wrappers for those c.lib functions? Where
    are you going to declare/define those wrappers? b.h/b.c?

    The rule should be simple: if blah.c (and actually I recommend you to
    rename your modules to have .cpp filename extension to avoid confusion
    with C language modules) needs functions declared in blehbleh.h, then
    blah.c MUST include blehbleh.h. If the translation unit does not need
    those declarations, don't include that header.

    Perhaps I failed to see the problem you're referring to in your first
    sentence.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 28, 2013
    #3
  4. jis

    jis Guest

    On Monday, January 28, 2013 1:46:00 PM UTC-8, Victor Bazarov wrote:
    > On 1/28/2013 2:21 PM, jis wrote:
    >
    > > please help me with following problem.

    >
    > >

    >
    > > I have a.c which includes a.h

    >
    > > i have b.c which includes b.h

    >
    > > i have b.h which includes c.h (c.lib included)

    >
    > >

    >
    > > a.c uses some functions which are defined in c.lib.

    >
    > > so i included b.h in a.h therby including c lib functions.

    >
    >
    >
    > BAD IDEA(tm). If 'a.c' uses functions that are declared in c.h, then
    >
    > a.c should include c.h. *Never* rely on pulling some needed header via
    >
    > some other header.
    >
    >
    >
    > > but iam writing something like hardware abstraction layer.

    >
    > > I dont want a.c access c.lib functions directly.

    >
    >
    >
    > Huh? Didn't you just write that "a.c uses some functions that are ..."?
    >
    >
    >
    > Are you saying you want to rewrite a.c so it does NOT any longer use any
    >
    > functions from c.h (c.lib)?
    >
    >
    >
    > > One way is to include c.h in b.c instead of b.h

    >
    >
    >
    > You said nothing about b.c actually needing c.lib. I presume it, but I
    >
    > am not necessarily convinced it's necessary. Yet.
    >
    >
    >
    > > What would be the standard pro way to do this.

    >
    >
    >
    > To do what, exactly?
    >
    >
    >
    > Are you going to introduce wrappers for those c.lib functions? Where
    >
    > are you going to declare/define those wrappers? b.h/b.c?
    >
    >
    >
    > The rule should be simple: if blah.c (and actually I recommend you to
    >
    > rename your modules to have .cpp filename extension to avoid confusion
    >
    > with C language modules) needs functions declared in blehbleh.h, then
    >
    > blah.c MUST include blehbleh.h. If the translation unit does not need
    >
    > those declarations, don't include that header.
    >
    >
    >
    > Perhaps I failed to see the problem you're referring to in your first
    >
    > sentence.
    >
    >
    >
    > V
    >
    > --
    >
    > I do not respond to top-posted replies, please don't ask


    Sorry for the confusion.
    Let me rephrase it again.

    1. I have one.cpp and its header one.h
    2. I have two.cpp and its header two.h
    3. two.cpp uses a lib (three.lib). so i include three.h in two.h
    4. one.cpp calls functions in two.cpp. so i need to include two.h in one.h
    but that will expose three.lib also to one.cpp.
    I dont want this. I want top layer to access only one layer down only. not
    all the layers below.

    i hope this is clear.

    thanks,
    jis
     
    jis, Jan 29, 2013
    #4
  5. jis

    red floyd Guest

    On 1/28/2013 5:11 PM, jis wrote:
    [thread redacted
    > Sorry for the confusion.
    > Let me rephrase it again.
    >
    > 1. I have one.cpp and its header one.h
    > 2. I have two.cpp and its header two.h
    > 3. two.cpp uses a lib (three.lib). so i include three.h in two.h
    > 4. one.cpp calls functions in two.cpp. so i need to include two.h in one.h
    > but that will expose three.lib also to one.cpp.
    > I dont want this. I want top layer to access only one layer down only. not
    > all the layers below.
    >


    Does two's interface depend on three? That is, is there anything in
    two.h that depends on three.h? If not, then move the #include of
    three.h into two.cpp

    Minimum visibility and all that jazz.
     
    red floyd, Jan 29, 2013
    #5
  6. jis

    jis Guest

    On Monday, January 28, 2013 6:02:06 PM UTC-8, red floyd wrote:
    > On 1/28/2013 5:11 PM, jis wrote:
    >
    > [thread redacted
    >
    > > Sorry for the confusion.

    >
    > > Let me rephrase it again.

    >
    > >

    >
    > > 1. I have one.cpp and its header one.h

    >
    > > 2. I have two.cpp and its header two.h

    >
    > > 3. two.cpp uses a lib (three.lib). so i include three.h in two.h

    >
    > > 4. one.cpp calls functions in two.cpp. so i need to include two.h in one.h

    >
    > > but that will expose three.lib also to one.cpp.

    >
    > > I dont want this. I want top layer to access only one layer down only. not

    >
    > > all the layers below.

    >
    > >

    >
    >
    >
    > Does two's interface depend on three? That is, is there anything in
    >
    > two.h that depends on three.h? If not, then move the #include of
    >
    > three.h into two.cpp
    >
    >
    >
    > Minimum visibility and all that jazz.


    thanks for the replies.
    yes include of three.h can be moved to two.cpp

    but i wanted to include only two.h in the two.cpp ( as a standard way)
    is there any design i can implement for this?

    thanks,
    jis
     
    jis, Jan 29, 2013
    #6
  7. jis

    red floyd Guest

    On 1/28/2013 7:08 PM, jis wrote:
    > On Monday, January 28, 2013 6:02:06 PM UTC-8, red floyd wrote:
    >> On 1/28/2013 5:11 PM, jis wrote:
    >>
    >> [thread redacted
    >>
    >>> Sorry for the confusion.

    >>
    >>> Let me rephrase it again.

    >>
    >>>

    >>
    >>> 1. I have one.cpp and its header one.h

    >>
    >>> 2. I have two.cpp and its header two.h

    >>
    >>> 3. two.cpp uses a lib (three.lib). so i include three.h in two.h

    >>
    >>> 4. one.cpp calls functions in two.cpp. so i need to include two.h in one.h

    >>
    >>> but that will expose three.lib also to one.cpp.

    >>
    >>> I dont want this. I want top layer to access only one layer down only. not

    >>
    >>> all the layers below.

    >>
    >>>

    >>
    >>
    >>
    >> Does two's interface depend on three? That is, is there anything in
    >>
    >> two.h that depends on three.h? If not, then move the #include of
    >>
    >> three.h into two.cpp
    >>
    >>
    >>
    >> Minimum visibility and all that jazz.

    >
    > thanks for the replies.
    > yes include of three.h can be moved to two.cpp
    >
    > but i wanted to include only two.h in the two.cpp ( as a standard way)
    > is there any design i can implement for this?
    >


    Why do you want to do this? You include what ever the hell that you
    need in the cpp file.
     
    red floyd, Jan 29, 2013
    #7
  8. jis <> wrote:
    > yes include of three.h can be moved to two.cpp


    If you can, do it.

    > but i wanted to include only two.h in the two.cpp ( as a standard way)


    I've never heard of such a standard or convention.

    > is there any design i can implement for this?


    Generally try to avoid including headers into other headers.

    I use the following strategy:
    1. Include in the cpp file
    2. If that's not enough, try forward declarations in the header file.
    3. Only if that does not work, include in the header file.

    Tobi
     
    Tobias Müller, Jan 29, 2013
    #8
  9. jis

    Guest

    On Tuesday, January 29, 2013 4:08:02 AM UTC+1, jis wrote:
    > On Monday, January 28, 2013 6:02:06 PM UTC-8, red floyd wrote:
    >
    > > On 1/28/2013 5:11 PM, jis wrote:

    >
    > >

    >
    > > [thread redacted

    >
    > >

    >
    > > > Sorry for the confusion.

    >
    > >

    >
    > > > Let me rephrase it again.

    >
    > >

    >
    > > >

    >
    > >

    >
    > > > 1. I have one.cpp and its header one.h

    >
    > >

    >
    > > > 2. I have two.cpp and its header two.h

    >
    > >

    >
    > > > 3. two.cpp uses a lib (three.lib). so i include three.h in two.h

    >
    > >

    >
    > > > 4. one.cpp calls functions in two.cpp. so i need to include two.h in one.h

    >
    > >

    >
    > > > but that will expose three.lib also to one.cpp.

    >
    > >

    >
    > > > I dont want this. I want top layer to access only one layer down only. not

    >
    > >

    >
    > > > all the layers below.

    >
    > >

    >
    > > >

    >
    > >

    >
    > >

    >
    > >

    >
    > > Does two's interface depend on three? That is, is there anything in

    >
    > >

    >
    > > two.h that depends on three.h? If not, then move the #include of

    >
    > >

    >
    > > three.h into two.cpp

    >
    > >

    >
    > >

    >
    > >

    >
    > > Minimum visibility and all that jazz.

    >
    >
    >
    > thanks for the replies.
    >
    > yes include of three.h can be moved to two.cpp
    >
    >
    >
    > but i wanted to include only two.h in the two.cpp ( as a standard way)
    >
    > is there any design i can implement for this?


    I don't know who told you this was "standard", but they were EXTREMELY wrong.

    Implementation (*.c) can use all sorts of things that are irrelevant for the public interface. To use them, it needs to #include public interface of these things.

    Interface, OTOH, should expose only... Well, the interface. Anything else is a distraction and a pointless attack on encapsulation.

    Goran.
     
    , Jan 29, 2013
    #9
  10. jis

    Jorgen Grahn Guest

    On Tue, 2013-01-29, jis wrote:
    > On Monday, January 28, 2013 6:02:06 PM UTC-8, red floyd wrote:
    >> On 1/28/2013 5:11 PM, jis wrote:
    >>
    >> [thread redacted
    >>
    >> > Sorry for the confusion.

    >>
    >> > Let me rephrase it again.
    >> >
    >> > 1. I have one.cpp and its header one.h
    >> > 2. I have two.cpp and its header two.h
    >> > 3. two.cpp uses a lib (three.lib). so i include three.h in two.h
    >> > 4. one.cpp calls functions in two.cpp. so i need to include two.h in one.h
    >> > but that will expose three.lib also to one.cpp.
    >> > I dont want this. I want top layer to access only one layer down only. not
    >> > all the layers below.
    >> >

    >>
    >> Does two's interface depend on three? That is, is there anything in
    >> two.h that depends on three.h? If not, then move the #include of
    >> three.h into two.cpp
    >>
    >> Minimum visibility and all that jazz.

    >
    > thanks for the replies.
    > yes include of three.h can be moved to two.cpp
    >
    > but i wanted to include only two.h in the two.cpp ( as a standard way)
    > is there any design i can implement for this?


    Others have replied already, but here's another one:

    There is no such standard way -- a header file is not supposed to be
    the link between the source file and /everything/ outside it.

    C and C++ source code (two.cpp in this
    case) almost always includes

    - two.h (where its client interface is described, and perhaps some of
    its implementation too (types, inline functions, ...))

    You try to expose as little as possible via two.h. Forward
    declarations help.

    - a number of needed standard and system headers (e.g. <string>,
    <unistd.h>)

    - other headers in your source code which are needed for two.cpp
    but which aren't certain to be included already by two.h

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jan 29, 2013
    #10
  11. jis

    W Karas Guest

    On Monday, January 28, 2013 2:21:07 PM UTC-5, jis wrote:
    > Hello guys,
    >
    >
    >
    > please help me with following problem.
    >
    >
    >
    > I have a.c which includes a.h
    >
    > i have b.c which includes b.h
    >
    > i have b.h which includes c.h (c.lib included)
    >
    >
    >
    > a.c uses some functions which are defined in c.lib.
    >
    > so i included b.h in a.h therby including c lib functions.
    >
    >
    >
    > but iam writing something like hardware abstraction layer.
    >
    > I dont want a.c access c.lib functions directly.
    >
    > One way is to include c.h in b.c instead of b.h
    >
    >
    >
    > What would be the standard pro way to do this.
    >
    >
    >
    > Please help me. (using visual studio 2010 express on windows 7)


    An obvious answer is to add "wrapper" function to b.c that call the needed functions in the c library. But I always find it annoying when there is a performance penalty for limiting the visibility of declarations.

    I wonder if there are any compilers that detect cases a wrapper function can be correctly implemented by a simple jump to the function being "wrapped".. I'm guessing only the very best compilers do this, if any.

    I'd be in favor of an explicit language construct that would allow defininga function (non-inline) as an alias of another declared function. Doesn'tseem like this would impose a big burden on the linker. The linker would have to error check that the two functions had matching argument lists (theusual way, based on name decoration). The address backpatching by the linker required to implement this seems comparable in complexity to currently necessary address backpatching.
     
    W Karas, Jan 30, 2013
    #11
  12. W Karas <> wrote:
    > I wonder if there are any compilers that detect cases a wrapper function
    > can be correctly implemented by a simple jump to the function being
    > "wrapped". I'm guessing only the very best compilers do this, if any.


    That's a special case of tail call optimization:
    If the last operation in a function is calling another function (and
    returning its value), the existing stack frame can be reused and the call
    can be replaced by a jump.
    In this case it is especially easy. Since the parameters are just
    forwarded, the stack frame does not have to be modified at all. But in
    general this is not necessary for tail call optimization.

    However, TCO is not so often seen in the C/C++ world. In C++ the last
    operation in a function tends to be a destructor call, which limits the
    applicability.

    In functional programming however, TCO is often even required by the
    language standard. It's important for recursive functions, otherwise the
    stack will overflow rather quickly.

    Tobi
     
    Tobias Müller, Jan 30, 2013
    #12
    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. Dhananjay
    Replies:
    1
    Views:
    1,162
    sloan
    Dec 18, 2006
  2. Luke Wu

    Abstraction layer between C and CPU

    Luke Wu, Jan 21, 2005, in forum: C Programming
    Replies:
    30
    Views:
    851
    Chris Torek
    Feb 5, 2005
  3. Kobu
    Replies:
    18
    Views:
    622
    Keith Thompson
    Jul 23, 2006
  4. BJ Dierkes

    Database Abstraction Layer And/Or ORM

    BJ Dierkes, Sep 24, 2007, in forum: Python
    Replies:
    1
    Views:
    323
    Bruno Desthuilliers
    Sep 24, 2007
  5. Ole
    Replies:
    4
    Views:
    193
Loading...

Share This Page