Proper way to put an abstract base class into a container

[Aguilar, James]

Suppose I have my own template container that represents a matrix. The
template's only parameter is < typename T > for the type that will go into
it. The only problem is that calling this matrix's constructor causes
issues with initiazing an abstract base type. What is the design pattern I
need to use to put this ABC into the container?

 

[Victor Bazarov]

Suppose I have my own template container that represents a matrix. The
template's only parameter is < typename T > for the type that will go into
it. The only problem is that calling this matrix's constructor causes
issues with initiazing an abstract base type. What is the design pattern I
need to use to put this ABC into the container?

You probably want to have a container of pointers to T.

Victor

 

[David Hilsee]

Suppose I have my own template container that represents a matrix. The
template's only parameter is < typename T > for the type that will go into
it. The only problem is that calling this matrix's constructor causes
issues with initiazing an abstract base type. What is the design pattern I
need to use to put this ABC into the container?

When people say that they have a class that represents a matrix, they are
usually writing a class that will perform number-crunching (matrix
multiplications, inverses, transposes, etc). Also, they usually will use it
to hold objects of type double or float (or possibly a light wrapper around
those types), and not instances of an ABC. An ABC might be an interesting
exercise, but for any application that made intensive use of the matrix, the
performance would probably be unacceptable. Why do you want to store an ABC
inside a matrix? As Victor pointed out, pointers are an option. They're
not all that easy to handle, though, if you want to write memory-leak-free
code.

 

[Gianni Mariani]

Suppose I have my own template container that represents a matrix. The
template's only parameter is < typename T > for the type that will go into
it. The only problem is that calling this matrix's constructor causes
issues with initiazing an abstract base type. What is the design pattern I
need to use to put this ABC into the container?

If you're using the STL, you're stuck with placing pointers in the
container. If you have a map or a list there may be alternatives e.g.

See this for one example using lists.
http://austria.sourceforge.net/dox/html/group__FlexibleList.html

You'll need to look at the test case to get an idea on how it works.

or even better -
http://www.elude.ca/aapl/

 

[Aguilar, James]

When people say that they have a class that represents a matrix, they are
usually writing a class that will perform number-crunching (matrix
multiplications, inverses, transposes, etc).

This is not a mathematical matrix, it is a matrix in the sense of a two
dimensional array (i.e. rows and columns, hence, matrix).

Also, they usually will use it
to hold objects of type double or float (or possibly a light wrapper around
those types), and not instances of an ABC. An ABC might be an interesting
exercise, but for any application that made intensive use of the matrix, the
performance would probably be unacceptable.

I wouldn't say that. It's just a one dimensional array of "<typename T>"s.
It is accessed through T operator ()(int, int) which just does array
arithmetic: return store_[rows * x + y]. Everything is inline, so it's
really no overhead at all, besides actually filling the matrix.

Why do you want to store an ABC
inside a matrix?

I'm doing a toy project which makes a 80x20 matrix of containers, then puts
particles in them (based on a text file). After that, it will iterate
through the matrix and randomly move each particle. The point is to
demonstrate that a gas, even if concentrated in one place initially, will
eventually diffuse into a larger area. This will be tried with all kinds of
shapes of containers to see how well the concept works and what kinds of
shapes keep gasses in the longest. Since a text file will dictate the shape
of the container, it should be no problem to reuse the programs on different
kinds of containers. Of course, the base class that I want to put into the
matrix is the bottom type (that is "Floor" or "Wall" at this point) which
will itself have a reference to a list of the particles on top of it.

As Victor pointed out, pointers are an option. They're
not all that easy to handle, though, if you want to write memory-leak-free
code.

That's one option. I'm not worried about memory leaks, since the program is
so small. I know exactly where everything is and in what order it happens.
Pointers . . . meh. I guess I will have to use one sometime, so it might as
well be now. I think I'll do that. Actually, I think I can still abstract
it and make it return references to the typename by making pointers
internally but dereferencing them outside. Well, I'll let y'all know how it
goes.

Yours,

James

 

[David Hilsee]

When people say that they have a class that represents a matrix, they are
usually writing a class that will perform number-crunching (matrix
multiplications, inverses, transposes, etc).

This is not a mathematical matrix, it is a matrix in the sense of a two
dimensional array (i.e. rows and columns, hence, matrix).

Also, they usually will use it
to hold objects of type double or float (or possibly a light wrapper around
those types), and not instances of an ABC. An ABC might be an interesting
exercise, but for any application that made intensive use of the matrix, the
performance would probably be unacceptable.

I wouldn't say that. It's just a one dimensional array of "<typename T>"s.
It is accessed through T operator ()(int, int) which just does array
arithmetic: return store_[rows * x + y]. Everything is inline, so it's
really no overhead at all, besides actually filling the matrix.

In this case, I wouldn't worry about performance. I mentioned performance
because I thought that you might be doing some number crunching with the
"matrix" class, which you clearly aren't.

I'm doing a toy project which makes a 80x20 matrix of containers, then puts
particles in them (based on a text file). After that, it will iterate
through the matrix and randomly move each particle. The point is to
demonstrate that a gas, even if concentrated in one place initially, will
eventually diffuse into a larger area. This will be tried with all kinds of
shapes of containers to see how well the concept works and what kinds of
shapes keep gasses in the longest. Since a text file will dictate the shape
of the container, it should be no problem to reuse the programs on different
kinds of containers. Of course, the base class that I want to put into the
matrix is the bottom type (that is "Floor" or "Wall" at this point) which
will itself have a reference to a list of the particles on top of it.


That's one option. I'm not worried about memory leaks, since the program is
so small. I know exactly where everything is and in what order it happens.
Pointers . . . meh. I guess I will have to use one sometime, so it might as
well be now. I think I'll do that. Actually, I think I can still abstract
it and make it return references to the typename by making pointers
internally but dereferencing them outside. Well, I'll let y'all know how it
goes.

I'm not a big physics or chemistry guy, but I would be interested in seeing
what the end result looks like.

 

[Aguilar, James]

I will post a link to the source code when it is done, if I can find a place
to host the text files.