I have a little conceptual problem. I have different classes representing the geometric data of an edge depending what type of edge it is. For Example the class for a straight line and a circle:
class Line{
private:
double[3] startPoint;
double[3] endPoint;
public:
//getter and setter and some other functions such as equals
}
class Circle{
private:
double[3] center;
double[3] planeNormal;
double radius;
public:
//getter and setter and some other functions such as equals
}
Now I need a class Edge which stores the type of the edge and the fitting geometric data.
In the end the Edge has to be stored in a std::vector<Edge> edges; The Problem is that I do not know the type before runtime, because I am analysing the boundary representation of CAD parts which can have various types of edges.
class Edge{
private:
EdgeType type;
GeometricData data;
public:
//...
}
So how should I design my class Edge and espacially GeometricData which has to store either a Line-object, a Circle-object or another geometric object, so that I can go back from GeometricData to Line, Circle or whatever geometric class it may be.
I tried polymorphism with GeometricData as base class, but the derived
classes are too different, since things like B-Splines are also
included.
I also tried GeometricData as void* and a template-approach
for the set- and get-methode, but with that I have problems
storing the data and not only the pointer, because of the lifetime
of the objects (I have to analyse the BRep recursivly).
I would also appreciate suggestions that may change the whole concept of the geometric representations, as long as I can access the type-fitting data such as startPoint of a straight line or radius of a circle using the edges-vector.
EDIT:
Thanks for the fast responses. I decided to use suszterpatt suggestion including some of my templates and changing my std::vector<Edge> to std::vector<shared_ptr<Edge>> as TAS mentioned. Now it looks like this:
#include "stdafx.h"
#include <string>
#include <sstream>
#include <iostream>
#include <vector>
using namespace std;
enum EdgeType{
LINE = 100,
CIRCLE
};
//Basis
class GeometricData {
private:
public:
virtual string toXMLString() = 0;
};
class Line : public GeometricData{
//less code just for illustration
private:
double d1;
public:
double getD1() { return d1; }
void setD1(double d1) { this->d1 = d1;}
virtual string toXMLString() {
stringstream s;
s << "d1=\"" << d1 <<"\"";
return s.str();
}
};
class Circle : public GeometricData{
private:
double d2;
public:
double getD2() { return d2; }
void setD2(double d2) { this->d2 = d2;}
virtual string toXMLString() {
stringstream s;
s << "d2=\"" << d2<<"\"";
return s.str();
}
};
class Edge{
private:
EdgeType t;
GeometricData* d;
public:
Edge () { d = 0;}
~Edge () {if (d) {delete d; d=0;}}
template <typename T> int setGeomData (T data) {
static_assert(
is_same<T,Line*>::value ||
is_same<T,Circle*>::value,
"EdgeGeometryType is not supported");
GeometricData* buffer = data;
//set type corresponding to thethis->data given= data
if(is_same<T,Line*>::value){
this->t = LINE;
Line* lb = dynamic_cast<Line*>(buffer);
Line* l = new Line(*lb);
this->d = l;
}else if (is_same<T,Circle*>::value){
this->t = CIRCLE;
Circle* cb = dynamic_cast<Circle*>(buffer);
Circle* c = new Circle(*cb);
this->d = c;
}else{// this case should not occure because of the static_assert
return -1;
}
return 0;
};
template <typename T> T getGeomData () {
static_assert(
is_same<T,Line*>::value ||
is_same<T,Circle*>::value,
"EdgeGeometryType is not supported");
if ((this->t == LINE && is_same<T,Line*>::value) ||
(this->t == CIRCLE && is_same<T,Circle*>::value))
{
return dynamic_cast<T>(this->d);
}else{
return NULL;
}
};
EdgeType getType(){ return t; }
//void setType(EdgeType t) { this->t = t; } not needed
GeometricData* getData(){return d;}
};
class Model {
private:
vector <shared_ptr<Edge>> edges;
public:
Model(){}
vector <shared_ptr<Edge>> getEdges(){ return edges; }
void addEdge (Edge* e) {edges.push_back(shared_ptr<Edge>(e));}
shared_ptr<Edge> getEdge(int i ){ return edges.at(i); }
};
// Functions
void foo2 (Edge* e){
Line* l = new Line;
l->setD1(0.1);
e->setGeomData<Line*>(l);
//e->setType(LINE); not needed
delete l;
}
void foo1 (Edge* e){
Circle c;
c.setD2(0.2);
e->setGeomData<Circle*>(&c);
//e->setType(CIRCLE); not needed
}
void foo (Model* mdl){
Edge* e1 = new Edge;
Edge* e2 = new Edge;
foo1(e1);
foo2(e2);
mdl->addEdge(e1);
mdl->addEdge(e2);
}
int _tmain(int argc, _TCHAR* argv[])
{
Model mdl;
int i;
foo(&mdl);
cout << "Edge 1: " << mdl.getEdge(0)->getData()->toXMLString() << endl;
cout << "Edge 2: " << mdl.getEdge(1)->getData()->toXMLString() << endl;
for (i = 0; i<2; i++){
switch (mdl.getEdge(i)->getType()){
case LINE: {
Line* ld = (mdl.getEdge(i)->getGeomData<Line*>());
cout << "Line (templated get): " << ld->getD1() << endl;
}break;
case CIRCLE:{
Circle* cr = (mdl.getEdge(i)->getGeomData<Circle*>());
cout << "Circle (templated get): "<< cr->getD2() << endl;
}break;
}
}
return 0;
}
There's a number of solutions. The one that seems to fit best is Boost.Variant; define your Line and Circle classes as you showed, then make GeometricData a typedef of variant<Line, Circle>, and you'll be able to store an instance of either one in there. When you want to go back from a GeometricData to the actual object stored, you can perform a cast, or you can write a so-called visitor. A visitor is just a class specifying an action for each possible type, and then boost::apply_visitor can be used to select the right action based on what is stored.
Example (using vectors for simpler notation):
struct Line {
Vector3d startPoint, endPoint;
};
struct Circle {
Vector3d center;
float radius;
};
using GeometricData = boost::variant<Line, Circle>;
struct MidpointVisitor : boost::static_visitor<Vector3d> const {
Vector3d operator()(Line const& line) {
return (line.startPoint + line.endPoint)/2;
}
Vector3d operator()(Circle const& circle) const {
return circle.center;
}
};
void foo() {
GeometricData data;
// ...
auto midpoint = boost::apply_visitor(MidpointVisitor{}, data);
// ...
}
A less type-strict solution is Boost.Any, but I don't see any advantages for this case. Even if you did need another option, you'd probably want to specify that explicitly.
I suspect your solution using void* (or using a common base class and RTTI) could be made to work using smart pointers. However, the only advantages I can see are faster compilation and less awful compiler error messages, while you end up having to bother with dynamic allocation and can't have visitors.
You could also roll your own union for this, effectively implementing something along the lines of Variant. That would involve making sure you get construction, destruction and alignment all correct, and don't trigger some obscure case of undefined behaviour. If that's not a problem for you and you really don't want to use a library, it's an option, but it is very much reinventing the wheel.
I would say polymorphism where perhaps the shared interface looks something like this:
class Edge
{
enum EdgeType
{
CIRCLE,
LINE
};
EdgeType GetType();
}
Then in a switch statement somewhere you could do something like:
switch (myEdge.GetType())
{
case Edge::EdgeType::CIRCLE:
auto myCircle = (Circle)myEdge;
// do things specific to circle
break;
case Edge::EdgeType::LINE:
auto myLine = (Line)myEdge;
// do things specific to line
break;
}
That being said, I would try to use polymorphism as much as possible over the switch statement, but the above interface gives you the option of having a function using edges contain the logic for doing different things based on type.
I'm not sure I fully understand the problem you're trying solve but from reading and understanding the question, I'd say look into serialization
You could maybe create a global array type variable, store the objects you need, serialize it an deserialize it when you need to use it.
Related
I have a superclass Element with multiple subclasses, let's call them A and B. I want to overload << and >> so I can save and load my objects.
class Element
{
public:
Element();
int superProperty;
virtual void write(iostream &out)
{
out << superProperty;
}
virtual void read(iostream &in)
{
in >> superProperty;
}
};
iostream operator<<(iostream &out, const Element &elt)
{
elt.write(out);
return(out);
}
iostream operator>>(iostream &in Element &elt)
{
elt.read(in);
return(in);
}
class A : public Element
{
public:
A();
int subProperty;
void write(iostream &out)
{
Element::write(out);
out << subProperty;
}
void read(iostream &in)
{
Element::read(in);
in >> subProperty;
}
};
class B : public Element
{
public:
B();
double subProperty;
void write(iostream &out)
{
Element::write(out);
out << subProperty;
}
void read(iostream &in)
{
Element::read(in);
in >> subProperty;
}
};
With these definitions, I can easily write out a file of my Elements, writing each one as
iostream mystream;
Element e;
...
mystream << e;
Where I'm stuck is reading them back in. I want it to look like this:
iostream mystream;
Element *pe;
...
pe = new Element(); // the problem is right here
mystream >> *pe;
But that won't work because I don't know if the element I'm about to read is an Element or an A or a B. (In my application, I never actually instantiate an Element. All objects are one of the subclasses.)
I resorted to writing out a char to indicate the class...
if (dynamic_cast<A>(e))
{
out << 'A';
out << e;
} else if (dynamic_cast<B>(e))
{
out << 'B';
out << e;
}
and then switch/casing to read like this:
char t;
Element *pe;
...
in >> t;
switch (t)
{
case 'A':
pe = new A;
break;
case 'B':
pe = new B;
break;
}
in >> *pe;
but it seems inelegant.
What is a better way to stream my disparate objects?
In essence, that’s what any serialization solution will boil down to. Elegance may be improved a bit though but using code generation may still be better (serialization frameworks do that).
The dynamic cast can definitely be avoided using a virtual function or a map (type_index to tag 1). The switch can be replaced with a map (tag to factory) as well. It is even possible (with some template magic) to use the same code to initialize both maps, like:
using Factory = void(*)();
struct SerializationInfo {
char key;
type_index type;
Factory factory;
};
template <class T>
SerializationInfo Serializable(char key) // note that SerializationInfo is not a template!
{
return {key, typeid(T), []() { return new T(); }}; // IIRC captureless lambda is convertible to a function pointer
}
Maps buildSerializationMaps(initializer_list<SerializationInfo>);
buildSerializationMaps({
Serializable<A>('A'),
Serializable<B>('B'),
});
where Serializable is a function template that wraps all the serialization information (key, type id, and factory function) in a standard interface.
So I am basically trying to link two different classes and use both in the same vector.
For example, if I have one class called "CPlayer" and another one called "CEnemy" where they have different elements but the same principle, how do I link it possibly into a class named "CEntity"? I want to avoid messy and hard code.
#IgorTandetnik is right, polymorphism is the solution. I have posted a descriptive snippet here to guide your thoughts as you learn this interesting topic.
emum entity_type_enum { PLAYER, ENEMY };
struct CEntity
{
CEntity(void) { /**/ }
virtual ~CEntity(void) { /**/ }
virtual entity_type_enum id(void) = 0;
};
struct CPlayer : public CEntity
{
CPlayer(void) { /**/ }
virtual ~CPlayer(void) { /**/ }
entity_type_enum id(void) { return PLAYER; }
};
struct CEnemy : public CEntity
{
CEnemy(void) { /**/ }
virtual ~CEnemy(void) { /**/ }
entity_type_enum id(void) { return ENEMY; }
};
std::vector<CEntity*> objects;
objects.push_back(new CEnemy());
objects.push_back(new CPlayer());
To get actual player or enemy
auto *ptr = objects[0];
if (ptr->id() == ENEMY)
{
auto *E = dynamic_cast<CEnemy*>(ptr);
// do something with enemy...
}
if (ptr->id() == PLAYER)
{
auto *P = dynamic_cast<CPlayer*>(ptr);
// do something with player...
}
And to clean up
for (auto *ptr : objects) delete ptr;
objects.clear();
Igor Tandetnik has given you basically a good advice. But here's a simple solution that does not involve inheritence and hence, dynamic casting. In case you need to store your Entities without polymorphism, there are a couple solutions:
Use std::variant (requires C++17):
#include <variant>
class CPlayer
{
// impl
};
class CEnemy
{
// impl
};
using RefCPlayer = std::reference_wrapper<CPlayer>;
using RefCEnemy = std::reference_wrapper<CEnemy>;
using EntityWrapper = std::variant<RefCPlayer, RefCEnemy>;
void deduce(EntityWrapper e)
{
switch (e.index())
{
case 0:
std::cout << "This is a CPlayer entity" << std::endl;
break;
case 1:
std::cout << "This is a CEnemy entity" << std::endl;
break;
default:
break;
}
}
int main()
{
CPlayer p1;
CEnemy e1;
std::vector<EntityWrapper> entities;
entities.emplace_back(RefCPlayer(p1));
entities.emplace_back(RefCEnemy(e1));
EntityWrapper w1 = entities[0],
w2 = entities[1];
deduce(w1);
deduce(w2);
}
std::variant::index
Returns the zero-based index of the alternative that is currently held by the variant.
Another way is to use a vector of std::pair<enum Entity, std::any>.
If the variant is valueless_by_exception, returns variant_npos.
I'm trying to create a mechanic that fills a vector with Spell objects, each with its own name, then select the spell with cin input and cast it on a target. What's the best way to do it? This is what I've done, but what if the spell has multiple spell effects?
//Spell.h
class Spell
{
public:
enum e_spellType //enum with all spells
{
FIREBALL = 1,
FROSTBOLT
};
enum e_spellEffect //enum with different effects
{
DAMAGE = 1, //for damaging effect
SLOW
};
Spell(e_spellEffect effect);
void returnSpellEffect(Unit* target);
//getters here
string getSpellName() const { return m_SpellName; }
int getSpellValue() const { return m_SpellValue; }
int getCooldown() const { return m_Cooldown; }
int getManaCost() const { return m_ManaCost; }
protected:
string m_SpellName;
int m_SpellValue;
int m_Cooldown;
int m_ManaCost;
int m_SpellID;
e_spellEffect m_spellEffect;
e_spellType m_spellType;
};
Spell::Spell(e_spellType type)
{
m_spellType = type;
switch (m_spellType)
{
case 1: //Fireball
m_SpellValue = 35;
m_ManaCost = 40;
m_Cooldown = 2;
m_spellEffect = DAMAGE;
case 2: //Frostbolt
m_SpellValue = 30;
m_ManaCost = 40;
m_Cooldown = 2;
m_spellEffect = SLOW;
}
}
void Spell::returnSpellEffect(Unit * target)
{
switch (m_SpellEffect)
{
case DAMAGE:
target->takeDamage(m_SpellValue);
break;
case SLOW:
target->setDamage(0.5); //modifies Unit object's attack dmg to half
break;
default:
break;
}
}
//Game.h
class Game
{
public:
void enemyCombat();
protected:
Player *player;
vector<Enemy*> enemyList;
vector<Spell*> spellList;
};
void Game::enemyCombat()
{
//after you have chosen a target from enemyList (enemyList[target])
spellList.push_back(new Spell(FIREBALL));
spellList.push_back(new Spell(FROSTBOLT));
cout << "Choose a spell to cast:" << endl
<< "1. Fireball" << endl
<< "2. Frostbolt" << endl;
int spellChoice = 0;
cin >> spellChoice;
spellList[spellChoice-1]->returnSpellEffect(enemyList[target]);
}
How do I make this whole thing more abstract to allow a spell to use more than one spell effect?
Consider using polymorphism. If you have a virtual function doSpellEffects, you can implement "usual" logic in the base class, and more specialized logic in other classes for specific spells or spell categories.
class Spell
{
public:
// Copying disabled to avoid slicing.
Spell(const Spell&) = delete;
Spell& operator=(const Spell&) = delete;
virtual ~Spell() = default;
enum e_spellType { /*...*/ };
// TBD whether e_spellEffect belongs in Spell or SimpleSpell.
// Factory function:
static std::unique_ptr<Spell> create(e_spellType spellType);
const std::string& getSpellName() const noexcept { return m_SpellName; }
int getCooldown() const noexcept { return m_Cooldown; }
int getManaCost() const noexcept { return m_ManaCost; }
virtual void doSpellEffects(Unit* target) = 0;
protected:
Spell(e_spellType spellType) :
m_spellType(spellType), m_SpellName(),
m_Cooldown(0), m_ManaCost(0) {}
e_spellType m_spellType;
std::string m_SpellName;
int m_Cooldown;
int m_ManaCost;
};
class SimpleSpell : public Spell
{
public:
SimpleSpell(e_spellType spellType);
void doSpellEffects(Unit* target) override;
int getSpellValue() const { return m_SpellValue; }
protected:
e_spellEffect m_spellEffect;
int m_SpellValue;
};
class WarlocksRay : public Spell
{
public:
WarlocksRay() : Spell(WARLOCKS_RAY, "Warlock's Ray") {}
void doSpellEffects(Unit* target) override;
};
void WarlocksRay::doSpellEffects(Unit* target)
{
// Two effects!
target->takeDamage(5);
target->stun();
}
// The factory function that creates all spells:
std::unique_ptr<Spell> Spell::create(e_spellType spellType) {
switch(spellType) {
case FIREBALL:
case FROSTBOLT:
return std::make_unique<SimpleSpell>(spellType);
case WARLOCKS_RAY:
return std::make_unique<WarlocksRay>();
}
// Invalid spellType: Log an error? Throw an exception? Just return nullptr?
throw std::invalid_argument("Bad spellType in Spell::create");
}
You could use subclassing in other ways, which might or might not be worth it:
Instead of a switch in SimpleSpell::doSpellEffects, create classes for each common effect type, like DamageSpell and SlowSpell.
If the "cooldown" and/or "mana cost" mechanics might not apply to all spells, move these members and related logic out of Spell into a class NormalCastingSpell or something, which would come between Spell and other classes in the heirarchy.
Even go so far as to create a class for each individual spell. In some cases, this could just inherit SimpleSpell or DamageSpell or etc., and the only member it would need to define would be a constructor that correctly sets all data members.
aschepler's answer is probably the most flexible one, in worst case, though, you might end up in implementing every spell on its own. A variation of could be:
a base class Effect
deriving classes DamageEffect, SlowEffect, ...
one single Spell class
The spell class then might look like this:
class Spell
{
std::string name;
std::vector<std::unique_ptr<Effect>> effects;
public:
void cast(Unit& target)
{
for(auto& effect : effects)
effect->applyTo(target);
}
}
When the spell gets casted, you likely would want to show some appropriate visual effect. You could again have polymorphic objects for these and provide one to the spell class as a member (several similar spells could re-use the same animation that way), alternatively you could have an animation for every effect and use the one of the first element in the effects vector.
Side note: You might create every spell just once in some global vector (not getting changed after creation any more, so no re-allocations – best have it const), units being able to cast spells would then just have pointers to those in their own vector.
I put the whole code on github: https://github.com/marianatuma/CG
I have a struct called point, declared in line.h, and a class line that has two points, start and end. EDIT: I didn't add it before, but Line inherits from GraphObj. graphObj.h:
class GraphObj {
private:
type t;
std::string name;
public:
GraphObj(type t, std::string name);
type getType();
std::string getName();
};
line.h:
#ifndef LINE_H
#define LINE_H
struct point {
double x;
double y;
};
class Line {
private:
point start;
point end;
public:
Line(type t, std::string name) : GraphObj(t, name) {};
void setStart(double x, double y);
void setEnd(double x, double y);
point getStart();
point getEnd();
};
#endif
line.cpp:
#include "line.h"
void Line::setStart(double x, double y) {
this->start.x = x;
this->start.y = y;
}
void Line::setEnd(double x, double y) {
this->end.x = x;
this->end.y = y;
}
point Line::getStart() {
return start;
}
point Line::getEnd() {
return end;
}
I always get a segmentation fault when I try accessing any of these points. I tried making them public, didn't work. I also tried using getters and it also didn't work. Here's how I'm initializing them:
The line is in a list of lines, called a display file, which will be used with cairo to draw them.
displayFile.h:
#ifndef DISPLAYFILE_H
#define DISPLAYFILE_H
#include <list>
#include "graphObj.h"
class DisplayFile {
private:
std::list<GraphObj*>* objectList;
std::list<GraphObj*>::iterator it;
int size;
public:
DisplayFile();
void add(GraphObj* g);
GraphObj* getNextObject();
void resetIterator();
int getSize();
};
#endif
displayFile.cpp:
#include "displayFile.h"
DisplayFile::DisplayFile() {
this->objectList = new std::list<GraphObj*>();
this->it = objectList->begin();
this->size = 0;
}
void DisplayFile::add(GraphObj* g) {
std::list<GraphObj*>::iterator tempIt;
tempIt = objectList->begin();
this->objectList->insert(tempIt, g);
this->size++;
}
GraphObj* DisplayFile::getNextObject() {
return *++it;
}
void DisplayFile::resetIterator() {
it = objectList->begin();
}
int DisplayFile::getSize() {
return size;
}
DisplayFile returns a GraphObj instead of the objectList, so it has to iterate through objectList by itself, hence the resetIterator (so when the main code is done traversing the list it will reset the iterator to the start of the list, but I'm not calling this method anywhere so far). The code in main.cpp where an instance of Line is used is below:
static void do_drawing(cairo_t *cr)
{
/* not using these right now
cairo_set_source_rgb(cr, 0, 0, 0);
cairo_set_line_width(cr, 0.5);
*/
int size = df->getSize(); //df is the list
for(int i = 0; i < size; i++) {
Line* g = df->getNextObject();
point start = g->getStart();
}
}
The problem only starts when I try accessing the points, I can access other attributes from that line instance without problems. What am I doing wrong?
edit: I hope I've provided enough information, the main code is long and doesn't really have much to do with the line class, so I don't think it's relevant.
The problem lies with your list class.
class DisplayFile {
private:
std::list<GraphObj*>* objectList; // Why not just a list<GraphObj*>
std::list<GraphObj*>::iterator it; // Why use this?
int size; // WHY manually keep track of a STL container size?
public:
DisplayFile();
void add(GraphObj* g);
void resetIterator();
int getSize();
};
In your implementation file:
GraphObj* DisplayFile::getNextObject() {
return *++it;
}
As I already commented: this is the winner... Think about it, what if it already happens to be the last element on the list, and you ask for getNextObject()? Boom
I don't see why you couldn't just replace the entire DisplayFile class with a nice and plain std::list:
std::list<GraphObj*> objectList;
// I would also advice to change to smart pointers here
// for example: std::list<std::shared_ptr<GraphObj> > objectList;
// or std::list<std::unique_ptr<GraphObj> > objectList;
Then you would just use the STL methods to work with the list:
Add an item to the front: (for the sake of simplicity lets imagine that GraphObj has a default constructor)
GraphObj* g = new GraphObj();
objectList.push_front(g);
// If you change to smart pointers:
// objectList.push_front(std::make_shared<GraphObj>());
// or
// objectList.push_front(std::make_unique<GraphObj>());
Get the list size:
objectList.size();
Traverse the list:
for (std::list<GraphObj*>::const_iterator it = objectList.begin();
it != objectList.end();
++it)
{
point start = (*it)->getStart();
// or whatever you need to do here
}
Or with the much nicer range for:
for (const auto & graphObj : objectList)
{
point start = graphObj->getStart();
// or whatever you need to do here
}
Because you are not initilaizing the structs .
Change your constructor a bit
From this
Line(type t, std::string name) : GraphObj(t, name) {};
to
Line(type t, std::string name) : GraphObj(t, name) , start(),end() {};
This may help.
The problem might be coming from your getStart and getEnd because they return a point, which will create a copy(I think) of your start or end point, ie not using the point from line but copies. This usually isn't a big deal but if you want to change an x or y value and have the new value stick you'll need a reference to the original points x and y values.
Try this, change
point getStart();
point getEnd();
into
point *getStart() { return &start; }
point *getEnd() { return &end; }
and in your do_drawing(cairo_t *cr) change
point start = g->getStart();
to
point *start = g->getStart();
start->x = value; // or
double value = start->x; // or however you want to use start
I am updating an old piece of C++ code and am stuck on a design issue and need advice on the best course of action. The code handles geometric data. Currently, the code defines many global constants to handle element types:
#define TETRAHEDRON 0
#define HEXAHEDRON 1
Each constant has information associated with it that remains constant and which is currently handled by a class, in our case Topology.
int Topology::nodesPerElement(int topType)
{
switch(topType) {
case TETRAHEDRON:
return 4;
break;
case HEXAHEDRON:
return 8;
break;
}
}
The Topology class has many of these functions that simply switch on the global constant to figure out associated information. There are a lot of element types and many bugs are introduced by switch statements that don't consider all element types. If an element type is added all of these methods need to be fixed. I need a better way of doing this that keeps the associated information with the type.
Enumerations are an improvement over this design, but it doesn't solve the problem of associating data with the enumeration.
For simplicity, I would like to avoid needing to instantiate classes for each type, as each will contain only static data that doesn't change.
What I really need is a "static class" that holds this information and performs like the pseudocode below:
class Tetrahedron : public TopType {
static const int nodesPerElement = 4;
static const std::string name = "Tet";
etc...
}
Each method in Topology becomes trivial:
int Topology::nodesPerElement(TopType topType)
{
return topType.nodesPerElement;
}
Is there a way to do this in C++? I've thought about just getting rid of the enumerations and having separate child Topology classes for each TopologyType, but the feedback I get from others is that it's too complicated of a solution. I hope that my question is clear enough.
Create a base class that contains all of the properties that your objects should support, and a private constructor to set those properties. You don't need derived classes, then: you can use static public objects to create the objects that you want with the desired properties.
class TopologyObject
{
private:
int numberVertices;
int numberFaces;
// etc.
public:
int getVertices() { return numberVertices; };
int getFaces() { return numberFaces; };
protected:
TopologyObject(int vertices, int faces) :
numberVertices(vertices),
numberFaces(faces)
{};
public:
static TopologyObject Tetrahedron = new TopologyObject(4, 4);
// etc.
}
You can access the Tetrahedron with all of its properties via TopologyObject::Tetrahedron.
If you decide that you need more complex variable behavior based on the type of object, then you really do need derived classes and virtual methods for the overrideable behavior.
Unless your Topology types have different runtime behaviors (like drawing themselves), then I agree with your peers that sub-classing is overkill. Reporting static properties like nodesPerElement and name is hardly a runtime behavior.
Unless you are not telling us the whole story about Topology, it seems that what you need is a simple property map. Use std::map to associate a topology type code with a structure of topology properties. This refactoring resembles Replace Subclass with Fields.
Here's some code that may serve as inspiration:
#include <cassert>
#include <iostream>
#include <map>
#include <string>
struct Topology
{
enum Code {tetrahedron, hexahedron};
int nodesPerElement;
std::string name;
};
namespace // Anonymous namespace
{
// Lookup table associating topology code with properties
const struct {Topology::Code code; Topology topo;} topoTable_[] =
{
{Topology::tetrahedron, {4, "Tetrahedron"}},
{Topology::hexahedron, {6, "Hexahedron"}}
};
};
class TopologyMap // Singleton
{
public:
static TopologyMap lookup(Topology::Code code)
{
return Topology(instance().doLookup(code));
}
private:
typedef std::map<Topology::Code, Topology> Map;
Map map_;
TopologyMap()
{
// Initialize map with constant property table
size_t tableSize = sizeof(topoTable_) / sizeof(topoTable_[0]);
for (size_t row=0; row<tableSize; ++row)
{
map_[topoTable_[row].code] = topoTable_[row].topo;
}
}
static TopologyMap& instance()
{
static TopologyMap instance;
return instance;
}
const Topology& doLookup(Topology::Code code) const
{
Map::const_iterator match = map_.find(code);
assert(match != map_.end());
return match->second;
}
};
class Shape
{
public:
Shape(Topology::Code topoCode)
: topo_(TopologyMap::lookup(topoCode)) {}
const Topology& topology() const {return topo_;}
// etc...
private:
Topology topo_;
};
int main()
{
Shape shape1(Topology::tetrahedron);
Shape shape2(Topology::hexahedron);
std::cout << "shape1 is a " << shape1.topology().name << " with " <<
shape1.topology().nodesPerElement << " nodes per element.\n";
std::cout << "shape2 is a " << shape2.topology().name << " with " <<
shape2.topology().nodesPerElement << " nodes per element.\n";
};
Output:
shape1 is a Tetrahedron with 4 nodes per element.
shape2 is a Hexahedron with 6 nodes per element.
If the topology code is zero-based and continuous, then you may use simple array indexing instead of a map. However, array indexing will be more error-prone if someone messes around with the topology code enum. Here is the same example that uses array indexing:
#include <cassert>
#include <iostream>
#include <map>
#include <string>
struct Topology
{
enum Code {tetrahedron, hexahedron, CODE_COUNT};
int nodesPerElement;
std::string name;
};
namespace // Anonymous namespace
{
// Lookup table associating topology code with properties
const Topology topoTable_[] =
{
{4, "Tetrahedron"},
{6, "Hexahedron"}
};
};
class TopologyMap // Singleton
{
public:
static Topology lookup(Topology::Code code)
{
assert(code < Topology::CODE_COUNT);
return topoTable_[code];
}
private:
TopologyMap() {} // Non-instantiable
};
class Shape
{
public:
Shape(Topology::Code topoCode)
: topo_(TopologyMap::lookup(topoCode)) {}
const Topology& topology() const {return topo_;}
// etc...
private:
Topology topo_;
};
int main()
{
Shape shape1(Topology::tetrahedron);
Shape shape2(Topology::hexahedron);
std::cout << "shape1 is a " << shape1.topology().name << " with " <<
shape1.topology().nodesPerElement << " nodes per element.\n";
std::cout << "shape2 is a " << shape2.topology().name << " with " <<
shape2.topology().nodesPerElement << " nodes per element.\n";
};
Note that because the details of storing and retrieving Topology was encapsulated in TopologyMap, I didn't have to rewrite any code in Shape and main.
You can have classes with nothing but static member variables. And that's a nice way to encapsulate attribute data.
If you'd rather not do that, traits might get you what you want.
I'm not sure who advised you to avoid derived classes for each Toplogy type. To my eye, this problem is screaming for derived classes.
Unless you would need a very large number of such classes.
Personally I think the best way to store this information would be to create a general Shape class. Then, instead of coding all those static variables put them in a file/database and load your shape information from the data store when you start your program.
Couldn't you use a record to do this if your goal is to avoid class instantiation?
Really though, you should class the poop out of this.
If topType is contiguous and starting a 0, you could just maintain an array of structs and index into that, instead of trying to have classes and subclasses. This way the only code change you would need is to
add the struct: Easy
add an array of structs: Easy
change each method to index into array and return proper field of struct: Tedious, but you have to do this anyway.
It your TopologyType can just be modelled as an instance of a struct (i.e no methods on it etc), Classes + Derived classes is overkill, IMO.
Since (apparently) all the relevant data is available at compile time, one possibility would be to use an enumeration along with templates and specialization to do the job:
enum { tetrahedron, hexahedron };
template <int type>
struct nodes_per_element { int operator()() const {
throw std::invalid_argument("Attempt to use unknown shape");
};
template <>
struct nodes_per_element<tetrahedron> { int operator()() const { return 4; } };
template <>
struct nodes_per_element<hexahedron> { int operator()() const { return 8; } };
You'd use this like: int x = nodes_per_element<hexahedron>()(); If you try to use it for a value for which there's no specialization, that will invoke the un-specialized template, which will throw an exception, halting the program and (normally) displaying a message saying you attempted to use an unknown shape. Of course, you can customize how that's displayed (if at all).
This should quickly show where you have problems due to values that haven't been defined.
The other obvious possibility would be to just define a struct for each shape you're going to use, and create an array of those structs, using the name of the shape as an index into the data, and the name of the specific data you want will be the member of the struct. For just the nodes per element you've given, that would look like:
struct shape_data {
int nodes_per_element;
std::string name;
};
shape_data data[] = {
{4, "Tetrahedron"},
{8, "Hexahedron" }
};
Retrieving data would be something like:
shape_data &s = data[hexahedron];
std::cout << "A " << s.name << " has " << s.nodes_per_element << "nodes per element.\n";
Having look at the previous answers, I've decided to add my own.
To me there are 2 things that I would require of such a design:
the ability to define a new item without recompiling the whole program
the ability to look up an item based on a property (like the number of faces)
This can be quite easy to do, so here is my little bit of code:
class Solid
{
typedef std::vector<Solid> solids_type;
public:
Solid(std::string name, size_t faces, size_t nodes):
mName(name), mFaces(faces), mNodes(nodes)
{
}
///
/// Properties
///
const std::string& getName() const { return mName; }
size_t getFaces() const { return mFaces; }
size_t getNodes() const { return mNodes; }
///
/// Collection Handling
///
static bool Add(Solid solid); // only add if it's not already there.
///
/// struct Predicate: std::unary_function<Solid,bool>
///
template <class Predicate>
static const Solid* Get(Predicate pred)
{
solids_type::const_iterator it =
std::find_if(Solids().begin(), Solids().end(), pred);
return it == Solids().end()) ? 0 : &(*it);
} // Get
///
/// Some Predicates
///
class ByName: std::unary_function<Solid,bool>
{
public:
ByName(std::string name): mName(name) {}
bool operator()(const Solid& s) const { return s.getName() == mName; }
private:
std::string mName;
};
class ByFaces; /// ...
class ByNodes; /// ...
private:
/// Properties
std::string mName;
size_t mFaces;
size_t mNodes;
/// Collection
static solids_type& Solids()
{
static solids_type MSolids;
return MSolids;
}
}; // class Solid
And thus, now we can have:
// in tetrahedron.cpp
namespace
{
bool gTetrahedron = Solid::Add(Solid("Tetrahedron", 4, 4));
}
// in main.cpp
int main(int argc, char* argv[])
{
const Solid* myTetra = Solid::Get(Solid::ByFaces(4));
assert(myTetra->getName() == "Tetrahedron");
assert(myTetra->getFaces() == 4);
assert(myTetra->getNodes() == 4);
return 0;
} // main
And now we have met our goals:
Adding one new solid does not cause any recompilation
We can lookup solid based on their properties
We could also imagine:
being able to iterate through all the registered solids
having them sorted by number of faces, or whatever
defining a little macro for the registration
This is precisely what virtual functions are for. The classical way to do it would be:
class Topology
{
public:
virtual int nodesPerElement() const = 0;
// etc
};
class Tetrahedrom : public Topology
{
public:
virtual nodesPerElement() const { return 4; }
// etc
}
// etc
But if you really have an aversion to re-implementing the accessor methods (as opposed to just defining variables) you could do the following with templates (although it's really no less verbose):
class Topology
{
public:
virtual int nodesPerElement() const = 0;
// etc
};
template<typename T>
class ConcreteTopology : public Topology
{
public:
virtual int nodesPerElement() const { return T::nodesPerElement; }
// etc
};
struct Tetrahedron_Data {
int nodesPerElement = 4;
// etc
};
typedef ConcreteTypology<Tetraheadron_Data> Tetrahedron;
// etc