This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


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

Re: b20: c++ bug or feature?


> To: Andres Heinloo <lka@physic.ut.ee>
> Cc: gnu-win32@cygnus.com, egcs@cygnus.com
> Date: Wed, 18 Nov 1998 13:53:29 -0600
> From: Mumit Khan <khan@xraylith.wisc.edu>

> > 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@cygnus.com" with one line of text: "help".


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