C/C++ abstraction layer

[jis]

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

 

[Ian Collins]

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.

 

[Victor Bazarov]

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

 

[jis]

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.







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)?






You said nothing about b.c actually needing c.lib. I presume it, but I

am not necessarily convinced it's necessary. Yet.






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

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

 

[red floyd]

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.

 

[jis]

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

 

[red floyd]

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.

 

[Tobias Müller]

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

 

[goran.pusic]

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.

 

[Jorgen Grahn]

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

 

[W Karas]

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.

 

[Tobias Müller]

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