From: mrs AT wrs DOT com (Mike Stump) Subject: Re: b20: c++ bug or feature? 20 Nov 1998 11:09:42 -0800 Message-ID: <199811200058.QAA27142.cygnus.gnu-win32@kankakee.wrs.com> To: khan AT xraylith DOT wisc DOT edu, lka AT physic DOT ut DOT ee Cc: egcs AT cygnus DOT com, gnu-win32 AT cygnus DOT com > To: Andres Heinloo > Cc: gnu-win32 AT cygnus DOT com, egcs AT cygnus DOT com > Date: Wed, 18 Nov 1998 13:53:29 -0600 > From: Mumit Khan > > OhharaDraw.h:130: sorry, not implemented: object size exceeds normal limit > > for virtual function table implementation, recompile all source and use > > -fhuge-objects > [ I'm copying egcs as well. Hopefully egcs C++ folks will provide some > insight into this ] > The hierarchy looks like this: > > Any target platform that does not use vtable "thunks" is affected by this. > For example, HPUX is as affected by it as ix86-win32. ix86-linux uses > vtable thunks by default, so it works there. > Solutions? > (1) Recompile *everything* with -fvtable-thunks. I don't know if it works > for x86-win32 targets. > (2) Recompile *everything* with -fhuge-objects. Hardly an option for real > life code. Also, I don't know how well debugged -fhuge-objects really > is, so you might be running into other compiler/library bugs there. There are 0 known bugs with it. Last I knew, it worked well. If people really don't like the 32K limitation, this is the `right' solution. 4) Learn to use new/malloc instead of having tons of stuff in an object, learn to make objects smaller. 45K objects seem rather large to me. Show us your code and defend the size, the other other person to ever hit this that I know of had very large data arrays in their objects that I took one look at and thought to myself, boy I wonder just how many static limits on things his code has. But otherwise, your solution list is pretty good. As to wether this is a bug or feature. I'd call it a documented limitation of the compiler. If you don't like it, change the 0 to a 1 on int huge_objects; and recompile and reinstall the compiler. We probably don't want to change the egcs version like this as there is a size win (and speed win as well?) with the limitation, and in practice, no one has good code that exceeds this limitation. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".