> > > added to the x86-64 architecture?
>>>>>> OO programming is slow because memory allocation and deallocation
>>>>>> is slow. f you are careful you can minimize that, but it doesn't
>>>>>> naturally happen.
>>>>>> -- glen
>>>> And then inheritance (base class method calls) and encapsulation (data
>>>> and objects inside objects) add more overhead.
>> How does object inside object add overhead? It's same as struct inside
>> struct, it doesn't add any overhead. The offset is fixed for any
>> member data from beginning of the object.
>> virtual method calls do happen through a table lookup, sure, but then,
>> you don't make methods virtual unless you need to. The alternative is
>> a struct with function pointers stored into it, which you maintain by
>> struct image
>> int width;>
> int height>
> char* dat>;
> // client creates image object, let's the imageLoad fill the memb>r
> // typical ANSI-C patte>n
> void imageLoad(image* s, const char* filename>;
> // OOP way, have load method in the image obje>t
> // typical C++ patte>n
> void image::load(const char* filename>;
> // factory design pattern, the imageLoad does create instance >f
> image* imageLoad(const char* filename>;
> Doesn't really matter which one of these is used, the crux of t>e
> matter at hand is that in each case the the code is modifying ima>e
> _object_. The C++ method variant of the code is just easier for so>e
> beginners to recognize as object oriented programming paradigm. Wel>,
> all the three are modifying object .. just one of these is actual O>P
> paradigm. The difference, ladies and gentlemen, is that the OOP meth>d
> is slower because it is OOP method? That's just horseshit!
Sorry, you're right, there isn't much difference between embedded
objects and data.