tag:blogger.com,1999:blog-24148139.post660879729243495931..comments2009-10-25T06:47:27.831-07:00Chuck LeDuc Díaznoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-24148139.post-18080409226704076322009-10-25T06:47:27.831-07:002009-10-25T06:47:27.831-07:00OO failed in the embedded world. The reason was that to embrace OO, you had to embrace an abstraction of your programming. Everything was neat and tidy with objects, constructors, destructors, etc. The problem was that most developers either forgot, or more probably, never learned what was going on underneath the hood. <br /><br />They didn&#39;t realize what was happing to the stack as you instantiated an object that had multiple layers of inheritance. The stack went nuts! All these layers of constructors creating new dynamic memory: Pop everything onto the stack... pop it all back off again. Over and over <i>ad infinitum</i>.<br /><br />All of that Big-O notation stuff in college, which was really hard to understand, was conveniently ignored. And so, when they tried rewriting embedded code, it failed with glory. <br /><br />At BNR, back in the 90&#39;s, they rewrote much of the digital switch call processing code in C++ as a test exercise. One of the key metrics in digital switching at the time was &quot;dial tone delay&quot;--how long from picking up the telephone handset before you hear the dial tone. The rigorous specs said it had to be 100 ms or less. <br /><br />With well written procedural code, that was no problem. But when they tried an elegant OO solution, the dial tone delay was OVER A MINUTE! Ha! I can think of no finer example!Scotthttp://www.blogger.com/profile/10750915013348769846noreply@blogger.comtag:blogger.com,1999:blog-24148139.post-39453971454670644312009-10-24T07:16:36.539-07:002009-10-24T07:16:36.539-07:00Off topic: You&#39;re cute, sir :)Mister G.A.G.http://www.blogger.com/profile/05521844359441132973noreply@blogger.com