Do I need RTTI?

edt · #1 23-Aug-2006, 13:43

I have a hierarchy of C++ classes that need to each have a different-sized array declared in the parent but allocated in the children. I also need the array size to be available through the reference (without a cast), so there has to be a non-static copy.

CPP / C++ / C Code:

class Parent {
   obj_type objs[];
   // OBJ_COUNT needs to be declared in the parent
};

class ChildA : public Parent {
   const_or_something int OBJ_COUNT = 5;   // but shouldn't be redeclared...
   obj_type objs[OBJ_COUNT];   // ditto
};

class ChildB : public Parent {
   const_or_something int OBJ_COUNT = 10;   // ditto
   obj_type objs[OBJ_COUNT];   // ditto
}

ChildB cb;
Parent* p = &cb;
cout << p->OBJ_COUNT << endl;   // note: no cast

Is there a way to make this happen?

edt · #2 23-Aug-2006, 14:03

BTW, I'm trying to skip over the whole mess of dynamic allocation here if I can do without.

I think some virtual functions might help with the "no casting" thing, but I don't want to redefine them for each child, and that still only solves half of the problem.

Also the array type could change to a subtype in some children.

edt · #3 24-Aug-2006, 11:00

I found a pretty good solution. There are two pure virtual methods, an accessor for the size and a lookup for the item, in the base. The children have a static const of the size because they need it in two places (the accessor and the array declaration), and they define methods. That way the interface to the array is through a virtual method and the implementation can be child-specific; I statically allocated the array from the child class.

Hope that helps if anyone was actually following this.

LuciWiz · #4 24-Aug-2006, 16:37

Quote:

Originally Posted by edt

BTW, I'm trying to skip over the whole mess of dynamic allocation here if I can do without.

That's what I wanted to suggest

It would have been pretty easy this way, since you could just make the size of the array a protected member variable in the parent class, then assign it to a different value in the constructor of each child class, and dynamically allocate the array to that size.

Well, I see you found another solution (more complicated IMO).

Best regards,
Lucian

#5 24-Aug-2006, 20:20

Quote:

Originally Posted by edt

BTW, I'm trying to skip over the whole mess of dynamic allocation here if I can do without.

WHY!? This practically SCREAMS for dynamic allocation. Why go through all of the complexities associated with trying to get around it? In fact, in C++, the allocation is TRIVAL if you use a standard container or write an appropriate template class or even a template member function in this case.

The beauty of C++ is that we have a ctor and dtor and we can handle initialization and deallocation in well-known, appropriate places whereas in C, we are left to our own devices and we each may pick a separate way to do it.

:davis:

edt · #6 25-Aug-2006, 08:59

Wow, I seem to have stepped on some toes...
The reason I'm trying to avoid dynamic allocation here is that this entire project is going to be a mess of dynamic allocation (I know because it's a reincarnation of an old project that died because it was a mess of dynamic allocation filled with cyclical dependencies), and I'm clinging to my sanity while I can.

In the proposed dynamic solution, you'd need to make the size not a constant but a variable and then set it to a constant at runtime. That sounds frivolous and makes me uneasy. Combine that with the fact that external accesses to this dynamically allocated array will know the size only through that variable, and you've got a potential (granted, a really small one) for problems.

I'm already using lots of virtual functions, anyway, so it won't be a performance bottleneck or anything. It'll all get dynamically allocated along with the object, anyway... I'm not afraid of dynamic allocation, but I tried it both ways and I think this way works better.

Well, I've been typing long enough that Mr. Banana Guy Thing stopped dancing at me, so I'll leave it at that for now.

#7 25-Aug-2006, 11:44

Quote:

Originally Posted by edt

Wow, I seem to have stepped on some toes...

No, just trying to understand why you're avoiding dynamic allocation.

Quote:

Originally Posted by edt

The reason I'm trying to avoid dynamic allocation here is that this entire project is going to be a mess of dynamic allocation (I know because it's a reincarnation of an old project that died because it was a mess of dynamic allocation filled with cyclical dependencies), and I'm clinging to my sanity while I can.

Why not use a simple container?

CPP / C++ / C Code:

typedef std::vector<obj_type> vObjTypes;

// inside your class definition
vObjTypes m_objs;

...and you're done with "dynamic allocation" as the container will manage it for you and when it goes out of scope, it will be deallocated for you.

Quote:

Originally Posted by edt

In the proposed dynamic solution, you'd need to make the size not a constant but a variable and then set it to a constant at runtime.

Huh?

Quote:

Originally Posted by edt

That sounds frivolous and makes me uneasy. Combine that with the fact that external accesses to this dynamically allocated array will know the size only through that variable, and you've got a potential (granted, a really small one) for problems.

What if you have some variable for the "dynamic" size and use something like:

CPP / C++ / C Code:

obj_type** objs = new obj_type*[ variable ];
...
delete [] objs;

...it seems rather simple to me. You can easily add the allocation to your ctor and the deallocation in your dtor.

Quote:

Originally Posted by edt

I'm already using lots of virtual functions, anyway, so it won't be a performance bottleneck or anything. It'll all get dynamically allocated along with the object, anyway... I'm not afraid of dynamic allocation, but I tried it both ways and I think this way works better.

Well, I've been typing long enough that Mr. Banana Guy Thing stopped dancing at me, so I'll leave it at that for now.

I typed this response and a bunch of code, ran some regression tests and memory leak checks (valgrind) and the banana guy is still jumping around like a fruit cake on speed. I wonder what that means?

:davis:

edt · #8 25-Aug-2006, 14:26

Quote:

Originally Posted by davis

Why not use a simple container?

I'm using STL containers up the wazoo as well. But, again, a linked list for this would be overkill since the same N objects will be there for the life of the array; the order and number will never change.

Quote:

Originally Posted by davis

What if you have some variable for the "dynamic" size and use something like:

That would work, and that's what I was looking at doing to begin with, but I think what I have takes fewer "risks" and also fewer lines of code (maybe). A variable could conceivably have its value change between an allocation and an access, and it just somehow seems silly to me to use a variable for something that will (should) never change that I already know the value of at compile time. I tried keeping it a constant w/ the dynamic allocation and it's a PITA.

Anyway, I'll keep the dynamic allocation in mind, but for right now, it works and I've moved on to other sections.

Quote:

Originally Posted by davis

and the banana guy is still jumping around like a fruit cake on speed.

lol

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Rate This Thread
Rate This Thread:

Do I need RTTI?

Re: Do I need RTTI?

Re: Do I need RTTI?

Re: Do I need RTTI?

Re: Do I need RTTI?

Re: Do I need RTTI?

Re: Do I need RTTI?

Re: Do I need RTTI?