From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29690 invoked by alias); 8 Nov 2005 10:40:18 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 29659 invoked by uid 22791); 8 Nov 2005 10:40:15 -0000 Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.203) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 08 Nov 2005 10:40:15 +0000 Received: by xproxy.gmail.com with SMTP id h27so656217wxd for ; Tue, 08 Nov 2005 02:40:14 -0800 (PST) Received: by 10.70.46.5 with SMTP id t5mr2077959wxt; Tue, 08 Nov 2005 02:40:14 -0800 (PST) Received: by 10.70.38.8 with HTTP; Tue, 8 Nov 2005 02:40:14 -0800 (PST) Message-ID: <8d192cb80511080240y3e3055e7jf07a65360b6ca18@mail.gmail.com> Date: Tue, 08 Nov 2005 10:40:00 -0000 From: Djekic Dusan To: Aseem Rastogi Subject: Re: Compiling and Linking help Cc: gcc-help@gcc.gnu.org In-Reply-To: <4370808B.8070607@india.tejasnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8d192cb80511080031r10a1ba6br214c6431bfe23e91@mail.gmail.com> <8d192cb80511080153gcd1d12dm312f3434492b6f06@mail.gmail.com> <437078F6.9050805@india.tejasnetworks.com> <8d192cb80511080210u7f890742jedad4b0f5f88a770@mail.gmail.com> <43707D14.5020506@india.tejasnetworks.com> <8d192cb80511080220o20aa9b90rf7b63e5127f6ab0e@mail.gmail.com> <4370808B.8070607@india.tejasnetworks.com> X-SW-Source: 2005-11/txt/msg00097.txt.bz2 a.h is still being used by other developers, so unfortunately I am not entitled to change it. Could you suggest who might be able to give the right answer? On 11/8/05, Aseem Rastogi wrote: > 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 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 fir= st 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 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 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. > > > >