compiling class-template member function

[Bruce Lee Roy]

Hi, I am using visual studio.net and I am having problems using this bit
of code when I create an instance,

////////////////////////////////////////////
template<class T>
class matrix : public vector<T> {
public:

matrix(size_t h, size_t w) : vector(h*w), width(w) {}

reference operator()(int i, int j) { return (*this)[i*width+j]; }

const_reference operator()(int i, int j) const { return (*this)
[i*width+j]; }
protected:

size_t width;
};

//////////////////////////////////////////////

error C2955: 'std::vector' : use of class template requires template
argument list : see declaration of 'std::vector'
while compiling class-template member function 'matrix<T>::matrix
(size_t,size_t)'
with
[
T=Point
]
: see reference to class template instantiation 'matrix<T>' being
compiled
with
[
T=Point
]
error C2614: 'matrix<T>' : illegal member initialization: 'vector' is not
a base or member
with
[
T=Point
]

[White Wolf]

Bruce Lee Roy wrote:

Hi, I am using visual studio.net and I am having problems using this
bit of code when I create an instance,

////////////////////////////////////////////
template<class T>
class matrix : public vector<T> {
public:

matrix(size_t h, size_t w) : vector(h*w), width(w) {}
You need to use a concrete type here, not a template-name:

matrix(size_t h, size_t w) : vector<T>(h*w), width(w) {}

Note the <T>
reference operator()(int i, int j) { return (*this)[i*width+j]; }

const_reference operator()(int i, int j) const { return (*this)
[i*width+j]; }
protected:

size_t width;

This is a call for disaster since you have made vector<T> a public base
class and std::vector has no virtual destructor.

Having said all that I suggest that in this case you make that vector a
member of your matrix class. There are many-many reasons to do that. One
of which is written above. The other reason is that in your code above you
have wondered to dependent-base-class-land and believe me you do not want to
go there unless you have to.

--
WW aka Attila

[Gianni Mariani]

White Wolf wrote:

Bruce Lee Roy wrote:
.... This is a call for disaster since you have made vector<T> a public base
class and std::vector has no virtual destructor.

(OMG - the virtual destructor police are BAAACK.)

Wether interitance is better than containment for you I'll leave for
when/if we have a better idea of what you're trying to build.

Generally speaking however, it is perfectly fine to inherit from vector
even though it has no virtual destructor. You just need to make sure
that you allways delete from the most derived class which is only a
problem if you dynamically allocate the class and a fairly trivial rule
to keep.

(this is like one of those cases "Doctor doctor, my head hurts when I
bash it against the brick wall", doctor answers "Well stop bashing it
against a brick wall"...Profit)

[Attila Feher]

Gianni Mariani wrote:

White Wolf wrote:

Bruce Lee Roy wrote:
...

This is a call for disaster since you have made vector<T> a public
base class and std::vector has no virtual destructor.

(OMG - the virtual destructor police are BAAACK.)

Wether interitance is better than containment for you I'll leave for
when/if we have a better idea of what you're trying to build.

Well, then you have a long reading ahead of you. Herb Sutter books
dedicated to C++: how inheritance instead of the proper composition (like
here) can make it impossible to create exception safe code.

Then the Design Patterns, where the ground rule #2 is: prefer composition
over inheritance.
Generally speaking however, it is perfectly fine to inherit from
vector even though it has no virtual destructor.
Generally speaking it is not. As soon as you add additional members, it is
not safe. Generally speaking you may feel it is perfectly fine to walk on
the 50th floor windowsill without safety belt, because you know what you are
doing. The trouble is not that. The trouble is that others will be there
too.
You just need to
make sure that you allways delete from the most derived class which
is only a problem if you dynamically allocate the class and a fairly
trivial rule to keep.
There is no way to ensure this in any decent sized project.

In the OPs case inheritance is completely wrong. Matrix is not a vector.
It is implemented in terms of a vector. Tomorrow he might want to change
this vector to something else (deque or whatever makes sense). Still his
design says that matrix is a kind of vector. This is plain not true.
(which is false ;-) )
(this is like one of those cases "Doctor doctor, my head hurts when I
bash it against the brick wall", doctor answers "Well stop bashing it
against a brick wall"...Profit)

I fail to see what this has to do with the OPs question and my answer. I
have given the solution to the OPs immediate problems and suggested taking t
he appropriate action to avoid future problems arising from his inferior
design. So while it might sound funny what you wrote, it has nothing to do
with this thread.

--
Attila aka WW

[Gianni Mariani]

Attila Feher wrote:

Gianni Mariani wrote:

White Wolf wrote:

Bruce Lee Roy wrote:

...

This is a call for disaster since you have made vector<T> a public
base class and std::vector has no virtual destructor.

(OMG - the virtual destructor police are BAAACK.)

Wether interitance is better than containment for you I'll leave for
when/if we have a better idea of what you're trying to build.

Well, then you have a long reading ahead of you. Herb Sutter books
dedicated to C++: how inheritance instead of the proper composition (like
here) can make it impossible to create exception safe code.

Then the Design Patterns, where the ground rule #2 is: prefer composition
over inheritance.

Great. Another guy who makes a decision on incomplete information.

Fire Ready Aim.

I kindly suggest you take your discussion about inheritance to
comp.object, I'm sure the folks there would love to help you.

Generally speaking however, it is perfectly fine to inherit from
vector even though it has no virtual destructor.

Generally speaking it is not. As soon as you add additional members, it is
not safe. Generally speaking you may feel it is perfectly fine to walk on
the 50th floor windowsill without safety belt, because you know what you are
doing. The trouble is not that. The trouble is that others will be there
too.

Come back down to earth.

Give me some FACTS. When I need religion, I go to church.

If you have lazy ass coders, get them to write in perl.

You just need to
make sure that you allways delete from the most derived class which
is only a problem if you dynamically allocate the class and a fairly
trivial rule to keep.

There is no way to ensure this in any decent sized project.

Cool, and you have facts ? Go ahead an demonstrate instances where you
found problems because of this. I wait with baited breath.

....

(this is like one of those cases "Doctor doctor, my head hurts when I
bash it against the brick wall", doctor answers "Well stop bashing it
against a brick wall"...Profit)

I fail to see what this has to do with the OPs question and my answer.

Obviously.

[White Wolf]

Gianni Mariani wrote:

Then the Design Patterns, where the ground rule #2 is: prefer
composition over inheritance.
Great. Another guy who makes a decision on incomplete information.

All the information needed to know was there. of course if you do not have
the experiences you might not see it.
Fire Ready Aim.

I kindly suggest you take your discussion about inheritance to
comp.object, I'm sure the folks there would love to help you.
I kinfly suggest you learn basic C++ design and participate in real life
sized projects to understand how wrong you are.
Come back down to earth.

Give me some FACTS.
I gave you the facts. Take your time to look at them.
When I need religion, I go to church.
Good. Do so. And post about it to alt.religion
If you have lazy ass coders, get them to write in perl.

I can see you have a lot to learn about real life software projects. And
BTW getting personal does not help you to debate a technical topic.

There is no way to ensure this in any decent sized project.

Cool, and you have facts?
Go ahead an demonstrate instances where you
found problems because of this. I wait with baited breath.

Cool. Let's remember that it is much easier to prove something exists than
to prove it isn't. So let's make it all very simple for us. You give a
solution which portably guarantees a compilation error if someone happens to
try to delete the derived object via a pointer to base. Since "make it not
compilable" the *only* way to *ensure* it will never happen. I am awaiting
your magic solution.

(this is like one of those cases "Doctor doctor, my head hurts when
I
bash it against the brick wall", doctor answers "Well stop bashing
it against a brick wall"...Profit)

I fail to see what this has to do with the OPs question and my
answer.

Obviously.

Yes. Obvious, since it has nothing to do with it.

--
WW aka Attila