«

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

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

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

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.

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

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.

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

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.

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 .