Re: Compiling and Linking help

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

 



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


[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