Polymorphism - Can't Articulate Problem

Okay. here's a problem I can't wrap my mind around. I think I basically need all of my opengl transformations to be isolated by glPushMatrix and glPopMatrix. So I have stuff like this:

Code:

---

abstract base object has virtual void draw() = 0

class stuff extends object and implements draw
class sturf extends object and implements draw
class stcrf extends object and implements draw

application has array of objects and draws them

---

I need each drawing routine to be encased in a glPushMatrix and glPopMatrix. I think I understand that this is kind of simplistic in it's approach, and even still I can't figure it out, and if there's a better design, suggestions are welcomed.

You could do something like this:

Code:

---

void DrawObjects(std::list<Object*> ls) {
  std::list<Object*>::iterator it;
  for(it = ls.begin(); it != ls.end(); it++) {
    glPushMatrix();
      (*it)->Draw();
    glPopMatrix();
  }
}

---

If I understood your problem, you can maintain the pure virtual but still implement it on the ABC.

Your deriveds will then be able to implement their own draw() and call base:: Draw() from within, where appropriate.

EDIT: Is there any way to avoid the annoyance of having to put a space to avoid the smiley on base::Draw()?

Quote:

---

Originally Posted by Tonto

Okay. here's a problem I can't wrap my mind around. I think I basically need all of my opengl transformations to be isolated by glPushMatrix and glPopMatrix. So I have stuff like this:

Code:

---

abstract base object has virtual void draw() = 0

class stuff extends object and implements draw
class sturf extends object and implements draw
class stcrf extends object and implements draw

application has array of objects and draws them

---

I need each drawing routine to be encased in a glPushMatrix and glPopMatrix. I think I understand that this is kind of simplistic in it's approach, and even still I can't figure it out, and if there's a better design, suggestions are welcomed.

---

One thing you could do would be:

Code:

---

void Base::Paint(){
    BeginDraw();
    Draw();
    EndDraw();
}

virtual void Base::BeginDraw(){
    glPushMatrix();
}

virtual void Base::Draw() = 0;

virtual void Base::EndDraw(){
    glPopMatrix();
}

---

If your child classes implement BeginDraw/EndDraw (to do their own init/cleanup) then they should call the base class at the beginning of BeginDraw and the end of EndDraw.

>> EDIT: Is there any way to avoid the annoyance of having to put a space to avoid the smiley on base::Draw()?

I can never tell when you're being sarcastic or not, so try this the next time: [noparse]:D[/noparse] I think it's not worth the effort to do. Besides, some people find that syntax aesthetic ...

std :: vector< std :: string :: size_tpye var > d;

Just confusing, in my opinion.

Perfect! Thanks.

I wasn't being sarcastic this time :)

Disable smilies in text. :D

Even better, thanks!

how about something like this

Code:

---

class DrawableObject
{
public:
    virtual void Draw(void) const = 0; // drawing should not affect state of object
};

// lots of classes that derive from DrawableObject and implement Draw()

class GlPainter
public:
    GlPainter(void)
    {
        glPushMatrix();
    }

    ~GlPainter(void)
    {
        glPopMatrix();
    }

    void operator()(const DrawableObject& obj)
    {
        obj->Draw();
    }
};

void DoPainting(const DrawableObject& obj)
{
    GlPainter paint;
    paint();
}

typedef boost::ptr_vector<DrawableObject> DrawingColl;

void Paint(const DrawingColl& coll)
{
    std::for_each(coll.begin(), coll.end(), DoPainting);
}

---

while it could use some fine tuning, it has the advantage of being exception safe

For some reason I didn't really understand that I could just do exactly what Desolation mentioned. Haha. But, there are lots of ways to do it, as you guys have shown. That begindraw/enddraw thing could be useful if specialized initialization would be necessary, and the safety of ce's is good. I may consider looking into boost libraries some time.

On top of that, check also the Bridge Pattern. I'm not quiet sure if it isn't too much for your current needs, but sure makes an interesting reading for more complex needs.

Using this simple class (or some variant of it), is a simple addition to Desolation's code that makes at least the popping of the matrix exception safe:

Code:

---

class GlPainter {
public:
    GlPainter(void)
    {
        glPushMatrix();
    }
    ~GlPainter(void)
    {
        glPopMatrix();
    }
};

void DrawObjects(std::list<Object*> ls) {
  std::list<Object*>::iterator it;
  for(it = ls.begin(); it != ls.end(); it++) {
    GlPainter paint;
    (*it)->Draw();
  }
}

---

I don't get the point of the bridge pattern.

Anyway, here's another thing you can do:

Code:

---

class Drawable
{
public:
  void draw() {
    glPushMatrix();
    do_draw();
    glPopMatrix();
  }
protected:
  virtual void do_draw() = 0;
};

---

Subclasses override not draw() but do_draw(). Because do_draw() is protected, it cannot be called directly from the outside; all calls must go through draw(), which performs the wrapping operation.

I like that option the best. You might actually want to make do_draw private instead of protected. There shouldn't be any do_draw-ing happening outside of the draw() function.

> I don't get the point of the bridge pattern.

Could you elaborate on that CornedBee?

Quote:

---

Originally Posted by Daved

I like that option the best. You might actually want to make do_draw private instead of protected. There shouldn't be any do_draw-ing happening outside of the draw() function.

---

Right. Too much Java on my part. I forgot that it can still be overridden if private.
Although you could perhaps make a case that private functions are an implementation detail of the class itself that subclasses shouldn't know about - how then can they know to override it?

Quote:

---

Originally Posted by Mario F.

Could you elaborate on that CornedBee?

---

Sure. I looked it up at Wikipedia and the article is just confusing me. It starts in the introduction:

Quote:

---

The bridge pattern is useful when not only the class itself varies often but also what the class does.

---

I think what the author meant is "when not only what the class does changes often but also how it does it." Although this should be the other way round: if what the class does changes often, then its interface is incomplete and thus flawed. Whereas changes in how it does it are the whole point of polymorphism.

The article then goes on to first describe interaction of shapes and drawing systems, and then cars and roads. In both cases, the impression I get is that here are two distinctly separate hierarchies (in the first case a hierarchy of shapes and a hierarchy of drawing engines, and in the second case a hierarchy of cars and a hierarchy of roads) that interact through their well-defined interfaces like the very basics of object-oriented design dictate. Yet the article makes the claim that there is a special pattern here because of the road somehow being an implementation detail of the car, or the GFX one of the shape, and that separating these into two hierarchies is a pattern.

That's nonsense IMO. It's just separation of concerns. It may be a pattern, but it's such a fundamental part of OOD that giving it yet another name is pointless, as I see it.

>> That's nonsense IMO.
Most design patterns are actually really simple and fundamental parts of OOD or other types of programming design. Giving it a name makes it easier to discuss and refer to, assuming both sides of the conversation understand what the patterns are.

In this case, I don't see how the Bridge Pattern applies at all, but there's nothing wrong with it having a name.

Right. I was under the impression it could be applied since it transfers the implementation concerns to another hierarchy. But a second look at it shows it is designed to address another issue.