C++ limit on the number of methods per class?

Started by
20 comments, last by Hnefi 15 years, 11 months ago
Hi there, Is it true that the C++ compiler has a limit on the maximum number of methods per class? http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf It is stated in the above link, that ebay architecture did encountered this problem with C++, that is why I decided to ask. Thanks, Jr
Advertisement
I skimmed through the PDF, and indeed, they claim that they reached a limit in the number of methods per class.
I'm just glad that I don't work in that programming team for so many reasons...
while (tired) DrinkCoffee();
The language itself does not dictate these sorts of implementation quantities -- although it does provide an (informative; that is, it does not dictate compliance) appendix listing a number of recommended minimums.

But any finite limitations that exist in practice are purely determined by the implementation.

Also, reaching any of those limitations is a strong indication that you're doing something wrong from a fundamental design perspective. The original ISAPI DLL that they're referring to that broke those limits was, I imagine, a stunningly poor example of good software design (this seems to be confirmed by the various pros they list that came about in their rewrites).
Good grief! Obviously a compiler has some limits, but I've never before heard anyone ever having too many methods in a class. They probably though that since globals are bad, let's put everything in one class. And hundreds of programmers working on that spaghetti? They probably had a high turnover rate due to frustration.
Uh, I did a quick check and it seems that I'm safe so far (although it kept the compiler busy for a while) :)

struct X {  void foo0(){}  void foo1(){}  void foo2(){}...  void foo9998(){}  void foo9999(){}};int main(){    X x;    x.foo0();}
Quote:Original post by gp343
Is it true that the C++ compiler has a limit on the maximum number of methods per class?

1. What is "the C++ compiler"?
2. I'd be surprised if any C++ compiler supported more than 4 billion member functions per class without running out of memory.
I'd be surprised if you didn't hit a visual-studio-can't-open-the-entire-file limit first. VS handles massive files badly it seems to me.
If you put things into context - it happened before 2002.

This would imply VC6 (or perhaps, though unlikely, gcc 2.x).

It also produced 150Mb executable, with 3.3 MLOC source! That approaches the size of things like Windows.

-----

Of course, there's also that harsh reality check - code quality didn't matter. eBay kept running, they kept growing, they did what had to be done.

Writing good code is incredibly expensive, and in majority of today's business isn't even necessary. Keep this in mind when you have hard time explaining to your boss or manager why your 20% performance improvement is so crucial.

I'm not advocating poor code. Just the usual disconnect between perfect code and earning money or growing a business. Knowing what really matters in the big picture is the really difficult part these days.
Quote:Original post by Antheus
Of course, there's also that harsh reality check - code quality didn't matter. eBay kept running, they kept growing, they did what had to be done.

Writing good code is incredibly expensive, and in majority of today's business isn't even necessary. Keep this in mind when you have hard time explaining to your boss or manager why your 20% performance improvement is so crucial.

I'm not advocating poor code. Just the usual disconnect between perfect code and earning money or growing a business. Knowing what really matters in the big picture is the really difficult part these days.

But code quality did matter and they had to rewrite the whole system. That, and the additional maintenance cost of a rotten code base, likely cost them a lot more money than what they would've paid had they done things right in the first place. Of course the decision to invest less money today only to be forced to burn through a lot more in the future may sometimes be a viable business decision, particularly if you don't expect to be around when the shit hits the fan.
Quote:Original post by SnotBob
But code quality did matter and they had to rewrite the whole system. That, and the additional maintenance cost of a rotten code base, likely cost them a lot more money than what they would've paid had they done things right in the first place. Of course the decision to invest less money today only to be forced to burn through a lot more in the future may sometimes be a viable business decision, particularly if you don't expect to be around when the shit hits the fan.


Sometimes, getting the crappy solution up and running and using whichever ugly methods you need to get it working is the only way to guarantee the business will be around long enough to write the decent version.

This topic is closed to new replies.

Advertisement