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] |
Dear Ian Lance Taylor, you wrote: > > 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 Interesting. I like the term 'vague linkage'. Apparently a vtable isn't by default/always/on different architectures filled with the addresses of virtual functions if these functions are defined inline and not explicitly called from other members. But the repair seems to be simple: as virtual functions need addresses simply avoid using inline definitions for them. Remarkable that the problem only shows up on the armel architecture. But better now than never, isn't it? > > 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. That's a nice subtlety that neatly blends in with the practice of avoiding inline virtual members. Something to add to the Annotations, I guess. Thanks for your quick replies and supportive comments! -- Frank B. Brokken Center for Information Technology, University of Groningen (+31) 50 363 9281 Public PGP key: http://pgp.surfnet.nl Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |