C++Talk.NET

deb@pixar.com · Guest

I've got a design issue that runs afoul of two issues:
(1) I've read many times that when writing a base class you
expect people to derive from, the class should be abstract.

(2) Lots of casting is bad.

Here's the story: I have a concrete base class TriangleMesh, which is
useful by itself. A TriangleMesh, among other things, owns/creates a
bunch of TriangleVertex objects. Because I expect the user might want
to extend the data in TriangleVertex, I make the TriangleMesh class
have a virtual "factory" function.

For example:

class TriangleVertex {
public:
virtual ~TriangleVertex();

// various accessors: e.g. position, etc.
TriangleVertex* GetClosestNeighbor();

...
};

class TriangleMesh {
public:
virtual ~TriangleMesh();

TriangleVertex* GetVertex(size_t index) {
return _vertices[index];
}

// imagine a whole bunch more accessors on TriangleVertex

private:
// default implementation:
virtual TriangleVertex* NewVertex() {
return new TriangleVertex;
}

vector<TriangleVertex*> _vertices;
};

OK, so now someone can derive off of both TriangleVertex, and
TriangleMesh, and in particular redefine NewVertex() to return their
derived TriangleVertex class:

class WeightedTriangleVertex : public TriangleVertex {
public:
double GetWeight();
void SetWeight(double);
private:
double _weight;
};

class WeightedTriangleMesh : public TriangleMesh {
private:
virtual TriangleVertex* NewVertex() {
return new WeightedTriangleVertex;
}

}:

So one thing is that when you're working in the derived classes, you
end up with a lot of casting going on, because you're constantly using
the accessors from the base mesh class, but you want back the derived
class to get to the extra state variables:

WeightedTriangleMesh* mesh = ...;
mesh->GetVertex(index)->SetWeight(...); // XX: needs a cast...

And, like I said, it bothers me slightly that TriangleMesh is useful on
its own, i.e. is concrete, because of the principle of trying to derive
from non-concrete classes.

Thoughts?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Marco Manfredini · Guest

[email]deb (AT) pixar (DOT) com[/email] wrote:

Victor Bazarov · Guest

[email]deb (AT) pixar (DOT) com[/email] wrote:

Frank Chang · Guest

It appears that you are trying to create virtual constructors. The
theory behind your use of virtual constructors. As the thread from
www.parasoft.com below shows you will have to use Visual C++ 7.0 to
achieve what you want:

[20.8] What is a "virtual constructor"?
An idiom that allows you to do something that C++ doesn't directly
support.

You can get the effect of a virtual constructor by a virtual clone()
member function (for copy constructing), or a virtual create() member
function (for the default constructor).

class Shape {
public:
virtual ~Shape() { } // A virtual destructor
virtual void draw() = 0; // A pure virtual function
virtual void move() = 0;
...
virtual Shape* clone() const = 0; // Uses the copy constructor
virtual Shape* create() const = 0; // Uses the default constructor
};

class Circle : public Shape {
public:
Circle* clone() const; // Covariant Return Types; see below
Circle* create() const; // Covariant Return Types; see below
...
};

Circle* Circle::clone() const { return new Circle(*this); }
Circle* Circle::create() const { return new Circle(); }
In the clone() member function, the new Circle(*this) code calls
Circle's copy constructor to copy the state of this into the newly
created Circle object. (Note: unless Circle is known to be final (AKA a
leaf), you can reduce the chance of slicing by making its copy
constructor protected.) In the create() member function, the new
Circle() code calls Circle's default constructor.

Users use these as if they were "virtual constructors":

void userCode(Shape& s)
{
Shape* s2 = s.clone();
Shape* s3 = s.create();
...
delete s2; // You need a virtual destructor here
delete s3;
}
This function will work correctly regardless of whether the Shape is a
Circle, Square, or some other kind-of Shape that doesn't even exist
yet.

Note: The return type of Circle's clone() member function is
intentionally different from the return type of Shape's clone() member
function. This is called Covariant Return Types, a feature that was not
originally part of the language. If your compiler complains at the
declaration of Circle* clone() const within class Circle (e.g., saying
"The return type is different" or "The member function's type differs
from the base class virtual function by return type alone"), you have
an old compiler and you'll have to change the return type to Shape*.

Note: If you are using Microsoft Visual C++ 6.0, you need to change the
return types in the derived classes to Shape*. This is because MS VC++
6.0 does not support this feature of the language. Please do not write
me about this; the above code is correct with respect to the C++
Standard (see 10.3p5); the problem is with MS VC++ 6.0. Fortunately
covariant return types are properly supported by MS VC++ 7.0.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Wu Yongwei · Guest

[email]deb (AT) pixar (DOT) com[/email] wrote:

deb@pixar.com · Guest

Marco writes:
What has the Mesh to know about the Vertex, except knowing how to
create
new ones? Chance that Mesh<_VertexType_> could be a better idea?

Sorry, this is a very very truncated example. Mesh needs to know a
*lot* about vertices, to do also sorts of comparisons. Mesh has to
create vertices, wire them together, form edges, faces (two more
datastructures I left out for brevity). This is not an example where
templating would be appropriate.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

deb@pixar.com · Guest

Victor Bazarov writes:
Where did you read that nonsense?

[Referring to: I 've read many times that when writing a base class
you expect people to derive from, the class should be abstract.]

Item 33: "Make non-leaf classes abstract."
More Effective C++.

Oh, Scott? ....

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Victor Bazarov · Guest

[email]deb (AT) pixar (DOT) com[/email] wrote:

Frank Chang · Guest

Sorry about the typos in the last message. I meant to say that the
theory behind virtual constructors is well established. It is the
implementation of virtual constructors that varies from compiler to
compiler. The C++ standard/VC 7.0 compiler supports covariant return
types which you may want to incorporate in you design. For example ,
you can change the virtual constructor in :

class WeightedTriangleMesh : public TriangleMesh {
private:
virtual TriangleVertex* NewVertex() {
return new WeightedTriangleVertex;
}

to

class WeightedTriangleMesh : public TriangleMesh {
private:
virtual WeightedTriangleVertex* NewVertex() {
return new WeightedTriangleVertex;
}
}:

Finally, base classes do always not need to be abstract. However, in
the ARM , Margaret Ellis and Bjarne Stroustrup (page 214) write " The
abstract class mechanism supports the notion of a general concept, such
as a shape, of which only more concrete variants, such as circle and
square, can actually be used". So, you must ask yourself does your
class TriangleVertex support the notion of a general concept? Thank
you.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

tony_in_da_uk@yahoo.co.uk · Guest

Not sure if you noticed a crucial part of what Marco was trying to tell
you: a virtual function in a derived class can return a pointer to a
type derived from the function's return type in the base class. So,
your code changes as follows:

class WeightedTriangleMesh : public TriangleMesh {
private:
virtual WeightedTriangleVertex* NewVertex() { // <---- note new
return type
return new WeightedTriangleVertex;
}
}:

Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Greg · Guest

[email]deb (AT) pixar (DOT) com[/email] wrote:

Wu Yongwei · Guest

Greg wrote:

Palik Imre · Guest

"Greg" <greghe (AT) pacbell (DOT) net> writes:

j · Guest

"Palik Imre" <clcppm-poster (AT) this (DOT) is.invalid> wrote

Viper Craft · Guest

[email]deb (AT) pixar (DOT) com[/email] писал(а):