This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: missing symbols with bobcat C++ library on armel


"Frank B. Brokken" <f.b.brokken@rug.nl> writes:

> Dear Ian Lance Taylor, you wrote:
>
>> This approach will only work if you guarantee that every piece of code
>> that creates a new MultiStreambuf includes that header file.
>
> I'm not sure if I follow you here. All MultiStreambuf sources include the
> above header, and no other (external to MultiStreambuf) functions need/have
> access to MultiStreambuf's private members. 
>
> So I guess you do not mean by 'creates a new MultiStreambuf' constructions
> like:
>     void fun()
>     {
>         MultiStreambuf ms;
>         MultiStreambuf *msp = new MultiStreambuf;
>     }

That is pretty much exactly what I do mean, actually.  There is some
more information at

http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Vague-Linkage.html

Note specifically: "Make sure that any inline virtuals are declared
inline in the class body, even if they are not defined there."  You
aren't currently doing that.  It's possible that that by itself might
fix this problem; I'm not sure.


> Btw, this approach, which uses an 'internal header' to minimize the
> requirements that need to be specified in class's header files is extensively
> documented in section 7.9 (near the end) of my C++ Annotations
> (cf. http://cppannotations.sourceforge.net/cppannotations/html/cplusplus07.html).
> If you think the approach outlined there is somehow flawed, I would appreciate
> receiving your thoughts.

The notes there don't seem to cover this case: the case in which all
virtual methods are inline.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]