Re: [lazarus] how are interfaces / virtual functions handled internally
I'll try to write a complete response to you very soon, I'm just very busy at the moment. If I should happen to forget it, will you please send me a private email? Thanks :) -- Regards, Christian Iversen _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] how are interfaces / virtual functions handled internally
Am Freitag, den 06.10.2006, 15:13 + schrieb Albert Zeyer: Am Donnerstag, den 05.10.2006, 15:08 +0200 schrieb Christian Iversen: On Thursday 05 October 2006 16:48, Albert Zeyer wrote: > Hi > > I am working on a very huge object-system, that means, I will have > thousands objects and more in the memory. > I am now thinking on how to redrucing the needed memory for each object > to a minimum. > > The base of all objects is abstract, that means, I could use an > interface for it or an abstract class with virtual abstract functions. > I will have much helper functions on each object (~ 30 at the moment), > that don't need to be virtual, because they should always behave the > same, they internally simply use the other virtual functions. I don't > want them outside the abstract class or the interface, because I don't > want to have a mixture between a procedural and an object-oriented code. > But the count of virtual functions is also not very small (~ 10 - 20). > > If I have a TObject1 and a TObject2 which both implements the abstract > class TBaseObject, then what exactly is saved internally by an instance > of each class? Does they contain a full table for each virtual function > (that means ~ 40 - 80 bytes only for this table) or does they simply > have a reference to their implementor-class (this means 4 bytes)? They simply have a reference to the TClass. Interfaces are much like this, although not exactly (but they scale as O(1) instead of O(n), with n objects) > I will have perhaps not more than 5 different implementor-classes, so if > a virtual function table is saved for every object, this table would > look mostly the same on all objects. It's only saved for every class. Ah, that is what I wanted to hear. > If I use an interface instead of the abstract class, is it the same > situation or is the virtual function handling different? It's _almost_ the same. You don't need to worry about the difference, it's only important when programming the compiler. OK, the differences are not important for me (at the moment). > But if I use an interface, where should I declare all my helper > functions for the object? If I declare them all in the interface, the > interface would be very huge. You should make an extra interface, which can be accessed by QueryInterface(). Then, on implementations that support the helper functions, you return the helper interface. On other implementations, you return nil. The helper functions should support all objects, not only a few, because the helper functions only use the base interface. So I don't want to make a check if they support them, they all simply do. For example, my base interface is: TFunction = interface function Map(Value: real): real; end; Helper functions (if they are procedural): function Integrate(fct: TFunction; a,b: real): real; function Diff(fct: TFunction; a: real): real; function GetZero(fct: TFunction; a,b: real): real; // calls Exception if no value is found ... I solved this now with a handler-object and I uses interfaces. This would look like the following for the given example: IFunction = interface function Map(Value: real): real; end; TFunctionHandler = class public: constructor Create(aFunction: IFunction); function Integrate(a,b: real): real; function Diff(a: real): real; function GetZero(a,b: real): real; // calls Exception if no value is found ... private: mFunction: IFunction; end; This solves all problems and gives me all wanted features. I don't think there is a better way to do it if I want to avoid abstract classes (because I need multi-inheriting and reference counting). > And if I don't want to define the helper functions again and again for > each implementor (that means to recode always the same), I have to have > an abstract class again because else there is no way to declare them > elsewhere. There are several ways that interfaces can help you there - one of them would be the IMPLEMENTS-keyword. Can you give me an example? I know the implements-keyword and how to use it (everything from here: http://info.borland.com/techpubs/delphi/delphi5/oplg/objintrf.html ), but I cannot imagine, how to use this in my case. In principle I want non-virtual functions in my interface. If I use abstract classes, I can do this. But I want to use interface for a few reasons. I also need reference counting. > I will have situations, where I want to create a huge amount of these > objects, therefore it is important to save memory for each instance. You're not much worse off by using interfaces. A few thousand objects should take only a few KB more mem. I hope you're not THAT pressed for memory? :) Ah, that's OK. That is clear. Only if all objects save the virtual function table seperatly, I would have that problem. As far as I k
Re: [lazarus] how are interfaces / virtual functions handled internally
Am Donnerstag, den 05.10.2006, 15:08 +0200 schrieb Christian Iversen: On Thursday 05 October 2006 16:48, Albert Zeyer wrote: > Hi > > I am working on a very huge object-system, that means, I will have > thousands objects and more in the memory. > I am now thinking on how to redrucing the needed memory for each object > to a minimum. > > The base of all objects is abstract, that means, I could use an > interface for it or an abstract class with virtual abstract functions. > I will have much helper functions on each object (~ 30 at the moment), > that don't need to be virtual, because they should always behave the > same, they internally simply use the other virtual functions. I don't > want them outside the abstract class or the interface, because I don't > want to have a mixture between a procedural and an object-oriented code. > But the count of virtual functions is also not very small (~ 10 - 20). > > If I have a TObject1 and a TObject2 which both implements the abstract > class TBaseObject, then what exactly is saved internally by an instance > of each class? Does they contain a full table for each virtual function > (that means ~ 40 - 80 bytes only for this table) or does they simply > have a reference to their implementor-class (this means 4 bytes)? They simply have a reference to the TClass. Interfaces are much like this, although not exactly (but they scale as O(1) instead of O(n), with n objects) > I will have perhaps not more than 5 different implementor-classes, so if > a virtual function table is saved for every object, this table would > look mostly the same on all objects. It's only saved for every class. Ah, that is what I wanted to hear. > If I use an interface instead of the abstract class, is it the same > situation or is the virtual function handling different? It's _almost_ the same. You don't need to worry about the difference, it's only important when programming the compiler. OK, the differences are not important for me (at the moment). > But if I use an interface, where should I declare all my helper > functions for the object? If I declare them all in the interface, the > interface would be very huge. You should make an extra interface, which can be accessed by QueryInterface(). Then, on implementations that support the helper functions, you return the helper interface. On other implementations, you return nil. The helper functions should support all objects, not only a few, because the helper functions only use the base interface. So I don't want to make a check if they support them, they all simply do. For example, my base interface is: TFunction = interface function Map(Value: real): real; end; Helper functions (if they are procedural): function Integrate(fct: TFunction; a,b: real): real; function Diff(fct: TFunction; a: real): real; function GetZero(fct: TFunction; a,b: real): real; // calls Exception if no value is found ... > And if I don't want to define the helper functions again and again for > each implementor (that means to recode always the same), I have to have > an abstract class again because else there is no way to declare them > elsewhere. There are several ways that interfaces can help you there - one of them would be the IMPLEMENTS-keyword. Can you give me an example? I know the implements-keyword and how to use it (everything from here: http://info.borland.com/techpubs/delphi/delphi5/oplg/objintrf.html ), but I cannot imagine, how to use this in my case. In principle I want non-virtual functions in my interface. If I use abstract classes, I can do this. But I want to use interface for a few reasons. I also need reference counting. > I will have situations, where I want to create a huge amount of these > objects, therefore it is important to save memory for each instance. You're not much worse off by using interfaces. A few thousand objects should take only a few KB more mem. I hope you're not THAT pressed for memory? :) Ah, that's OK. That is clear. Only if all objects save the virtual function table seperatly, I would have that problem. As far as I know, I would have the problem in C++. Regards, Albert
Re: [lazarus] how are interfaces / virtual functions handled internally
On Thursday 05 October 2006 16:48, Albert Zeyer wrote: > Hi > > I am working on a very huge object-system, that means, I will have > thousands objects and more in the memory. > I am now thinking on how to redrucing the needed memory for each object > to a minimum. > > The base of all objects is abstract, that means, I could use an > interface for it or an abstract class with virtual abstract functions. > I will have much helper functions on each object (~ 30 at the moment), > that don't need to be virtual, because they should always behave the > same, they internally simply use the other virtual functions. I don't > want them outside the abstract class or the interface, because I don't > want to have a mixture between a procedural and an object-oriented code. > But the count of virtual functions is also not very small (~ 10 - 20). > > If I have a TObject1 and a TObject2 which both implements the abstract > class TBaseObject, then what exactly is saved internally by an instance > of each class? Does they contain a full table for each virtual function > (that means ~ 40 - 80 bytes only for this table) or does they simply > have a reference to their implementor-class (this means 4 bytes)? They simply have a reference to the TClass. Interfaces are much like this, although not exactly (but they scale as O(1) instead of O(n), with n objects) > I will have perhaps not more than 5 different implementor-classes, so if > a virtual function table is saved for every object, this table would > look mostly the same on all objects. It's only saved for every class. > If I use an interface instead of the abstract class, is it the same > situation or is the virtual function handling different? It's _almost_ the same. You don't need to worry about the difference, it's only important when programming the compiler. > But if I use an interface, where should I declare all my helper > functions for the object? If I declare them all in the interface, the > interface would be very huge. You should make an extra interface, which can be accessed by QueryInterface(). Then, on implementations that support the helper functions, you return the helper interface. On other implementations, you return nil. > And if I don't want to define the helper functions again and again for > each implementor (that means to recode always the same), I have to have > an abstract class again because else there is no way to declare them > elsewhere. There are several ways that interfaces can help you there - one of them would be the IMPLEMENTS-keyword. > I will have situations, where I want to create a huge amount of these > objects, therefore it is important to save memory for each instance. You're not much worse off by using interfaces. A few thousand objects should take only a few KB more mem. I hope you're not THAT pressed for memory? :) -- Regards, Christian Iversen _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] how are interfaces / virtual functions handled internally
Hi I am working on a very huge object-system, that means, I will have thousands objects and more in the memory. I am now thinking on how to redrucing the needed memory for each object to a minimum. The base of all objects is abstract, that means, I could use an interface for it or an abstract class with virtual abstract functions. I will have much helper functions on each object (~ 30 at the moment), that don't need to be virtual, because they should always behave the same, they internally simply use the other virtual functions. I don't want them outside the abstract class or the interface, because I don't want to have a mixture between a procedural and an object-oriented code. But the count of virtual functions is also not very small (~ 10 - 20). If I have a TObject1 and a TObject2 which both implements the abstract class TBaseObject, then what exactly is saved internally by an instance of each class? Does they contain a full table for each virtual function (that means ~ 40 - 80 bytes only for this table) or does they simply have a reference to their implementor-class (this means 4 bytes)? I will have perhaps not more than 5 different implementor-classes, so if a virtual function table is saved for every object, this table would look mostly the same on all objects. If I use an interface instead of the abstract class, is it the same situation or is the virtual function handling different? But if I use an interface, where should I declare all my helper functions for the object? If I declare them all in the interface, the interface would be very huge. And if I don't want to define the helper functions again and again for each implementor (that means to recode always the same), I have to have an abstract class again because else there is no way to declare them elsewhere. I will have situations, where I want to create a huge amount of these objects, therefore it is important to save memory for each instance. Regards, Albert
