Re: Compiling and Linking help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



i would suggest rewrite a.h for better future.

its not important what you get from ur predecessors but what you leave behind for ur successors. :)

Djekic Dusan wrote:

unfortunately a.h also have some classes declarations and
implementations within it, and in b.h I declare pointers to some of
those classes.

On 11/8/05, Aseem Rastogi <aseem@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

may be this will works.

include a.h in b.cpp and not in b.h if possible.

Djekic Dusan wrote:

the previous message was a mistake, since I have not correctly the first line.
Yes, you are right about it. But, in reality, a.h includes many
functions, and including all of them is rather tedious job. Is there
any other solution?

On 11/8/05, Aseem Rastogi <aseem@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

do not include a.h in b.h and declate a () as an extern function in b.h

include a.h in main.cpp.

it should work.

Djekic Dusan wrote:

a.h is not the file I could change. I am just using it from third
party. Files in my project are b.h, c.h, and so forth. I forgot that
all my .h files are enclosed within suitable #ifndef, #define, and
#endif. And the question is how to have .o files of all b, c, and so
forth files linked without having multiple definition linking error of
everything from a, since everything from a is defined twice:
1 - in b.o (since b.h includes a.h)
2 - in main.o (since main.cpp includes b.h which includes a.h)

On 11/8/05, Dima Sorkin <dima.sorkin@xxxxxxxxx> wrote:

On 11/8/05, Djekic Dusan  wrote:

a.h
int a( ) { };

Hi.
I have encountered this problem too.
Explicitly writing "inline int a() {}" instead
of your piece of code helped.

Or , if "a" will be a big function (not intended for inlining),
you will have to
move it's definition into a.cpp, and in a.h there will be
only declaration.

Regards,
Dima.


--
The end is always good. If it's not good, it's not the end.





--
The end is always good. If it's not good, it's not the end.







--
The end is always good. If it's not good, it's not the end.




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux