
www.Usenet.com
| <-- __Chronological__ --> | <-- __Thread__ --> |
Uli asked: > Is that a realistic limit? Or will some more advanced projects run into > trouble with this approach? Does anybody know what figures other > languages (like Objective C) are working with? To which our esteemed moderator replied: > [Interesting question. I doubt that code written by humans would have > hundreds of superclasses, but what about code written by other programs? > - John] Valid point, John, and the answer is 255 is probably a reasonable limit, but I'm not certain. The Verilog compiler I work on emits C++ code to implement a simulator. In doing, so we generate heavily nested classes specifically to get around some limits in the MS Visual C++ compiler. It turns out some limitations (perhaps a limit of 65k members per class) of the compiler can be worked around by making deep single threaded class hierarchies (e.g. 65k members per class at each level of the chain until all the class members are included). Of course, this is in the same application that allowed us to uncover a MASM bug that only occurs in programs with more than 2MB of source lines (or something similar). I don't think our current class hierarchies have chains longer than 255 deep, but we are probably well into the 100+ depth, and I wouldn't doubt having chains in the 200+ range by the next generation of chip that we will handle. Just like Moore's law, the size of the simulated chips doubles with great regularity, and at roughly the same speed, so any fixed limit (on any attribute of the compiled code) will eventually be exceeded, and automated source code writers will then find another limit to stretch to cover the boundaries in the problem limit. Hope this helps, -Chris ***************************************************************************** Chris Clark Internet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 19 Bronte Way #33M voice : (508) 435-5016 Marlboro, MA 01752 USA fax : (508) 251-2347 (24 hours)
| <-- __Chronological__ --> | <-- __Thread__ --> |