Hi,
Sorry if my message came across as a "lesson", but I have come across quite a few people who don't quite understand this :+)
primem0ver wrote: |
---|
I am aware that one can implicitly downcast to a base class. In my experience, the opposite though cannot be done implicitly. |
But from what I understand you to be saying I don't need to use a casting mechanism? That doesn't make any sense to me when my BaseClass pointer in the table could refer to a DerivedClass1 or DerivedClass2, or DerivedClass3 etc... |
The key idea for this is the
declaration is a pointer to Base, but the container is
populated with pointer to Derived. Quite simply, a pointer to Derived is a valid pointer to Base.
That's the thing, there is no casting for the polymorphism to work. The compiler uses the vtable to
check that a pointer to Derived really is a descendant of Base class, if it is, then one can use that pointer to call the (pure) virtual functions that exist in the Base class. So all the Derived classes should supply a concrete definition of those virtual Base class functions. But, seen as the pointer
is a pointer to Derived, the Derived class functions are called. That's it, there is no conversion or casting done by compiler, nor is there any need for the code to do any explicitly. Often the need for casting could point to problems with the design.
As I said earlier this is a really powerful thing: One can have one set of interface functions for all the Derived classes, not different functions for each Derived class. Adding a new Derived classes just means providing a concrete definition for the virtual Base class interface functions, keeping the same names.
This is all useful... but to my original question. Is a single generic table better (i.e. more efficient) or multiple more specific tables when there is the potential for thousands of objects to be stored? |
So, keep it all in one table :+) In my mind the number and type of the objects is irrelevant - seen as you are using a Hash container. This type of container is efficient for lookup because of the hash function, perhaps more importantly it will be better when there are lots of insertions after the initial construction of data. Having one table is also better than multiple ones because one doesn't have to have extra logic to decide which of the other tables to go looking in. Just on having thousands of objects: thousands is a drop in the ocean; millions is more normal. Perhaps the limiting factors are: the size of 1 object and how much RAM one has.
Can you provide short descriptions of the real world classes you have for your UI components, plugins, plugin data and other classes? There might still be other ways of doing this. In my mind it is often a danger when someone expresses their problem in generic fashion (Base, Derived, foo, bar etc). By danger I mean we could spend a lot of time discussing the generic solution when there may be a better solution. Often alternative solutions may be envisaged when the real situation is presented :+)
Regards :+)