Re: How would Mr. Stroustrup implement his solution to 12.7[2]

From: David White (no_at_email.provided)
Date: 10/22/03 

Date: Wed, 22 Oct 2003 12:56:23 +1000

Oplec <anonymous@anonymous.com> wrote in message
news:w0llb.118400$mf.16285@twister01.bloor.is.net.cable.rogers.com...
> ----- Original Message -----
> From: "David White" <no@email.provided>
> Newsgroups: comp.lang.c++
> Sent: Tuesday, October 21, 2003 8:40 PM
> Subject: Re: How would Mr. Stroustrup implement his solution to 12.7[2]
>
>
> > > What happens is that a Window object, w, has its "draw(Shape*)"
> > > member called. Window::draw(Shape*) then passes its "this" pointer to
> > > "Shape::draw(Window*)".
> >
> > I don't think this is such a good idea. Since the Shape object is doing
> the
> > drawing, there's no need for the Window class to know about Shapes. Just
> > pass a reference to the Window object to the Shape's draw(), and the
> > overridden function in the specific shape will draw itself on the
Window.
>
> The Window class has to have a draw() member because such a member is
> included in the example use of the final implementation of problem
12.7[2].
> He shows that a Window, w, should be used as in the following:
> w.draw(Circle(w.current(),10)); So, clearly, he intends for the solutions'
> Window class to have a draw() member that takes a pointer to a Shape
class.
> I completely understand your idea, and would do it that way as well, but I
> wish to complete this the way he intended it to be.

Fair enough. If that's what the exercise says...

> One of my main
> objections to my design was the addition of Shape::draw(Window*) because
in
> all the examples I have seen surrounding the Shape example, Shape only
ever
> has a pure virtual Shape::draw()

Yes, I've seen these as example OO designs as well, but they are usually
designs, not working implementations. I just don't think a draw() with no
parameters is right for a real graphics system. The Shape objects should be
independent of the device because it is not only possible, but highly
likely, that you will sometimes want to print whatever you've drawn on the
screen.

> , and that is why I felt my solution should
> not be accepted. I often wondered if he mean't for the Window class to use
> iterators supplied by each Shape object in order to get the Shape's shape;
> that is, the character types, and position to be rendered on screen.

Probably. I think the shapes are defined so that the n(), s() etc. members
are sufficient for the window to draw any shape. This is probably a good
enough design, or even the best design, for a system with these limitations.
Remember it is just an exercise and not necessarily a proposal for the best
design for graphics systems in general. For high resolution graphics systems
you will want to have dotted or dashed lines, thick or thin lines, curved
lines, ellipses, pear shapes, closed shapes with various kinds of shading
etc. The possibilities and complexities are endless, and in my opinion the
shape object will usually best know how to draw itself. The type of device
might make a difference too (e.g., raster or non-raster), but the shape
object is where most of the knowledge belongs. So, for this exercise
Stroustrup's design is sufficient, but for more complex drawing I don't
think it is.

> As of
> this writing, I have yet to read anything of his that had Shapes provide
> iterators.
>
> He uses examples like the following when illustrating proper design for
this
> example:
> (src: http://technetcast.ddj.com/str0237/bs-millennium.pdf)

That file is not accessible to me at the moment.

> class Shape {
> public:
> virtual void draw() = 0;
> virtual void rotate(double) = 0;
> };
>
> class Common { Color c; /* ... */ };
>
> class Circle : public Shape, protected Common { /* ... */ };
>
>
> As you can see, his Shape's draw() member does not take anything. This is
> the difficult aspect causing me the concern with my design, as I feel that
> there must be an elegant design that he had intended to be used. My adding
> that Shape::draw() take a Window object was my method of solving 12.7[2],
> while adhering to the requirement their be Window::draw(Shape&);

I assure that, in general, there's nothing wrong with adding a device
parameter to the draw function. But it isn't necessary in this exercise,
since I think it's the Window that's doing the drawing.

> (Note, I mean't Shape& previously when writing Shape*).
>
> I truly wish to understand proper OO design, and do not wish to continue
my
> study until I have understood what should be a very simple problem.
>
>
> > You can make your function parameters const if you want, but it's not
> usual
> > or necessary. Parameters are passed by value, so functions have their
own
> > copies of them. It doesn't help the caller of a function know that a
> > function isn't going to modify its own copy of what's passed to it. The
> > caller doesn't care.
>
> Your comment is interesting. In TC++PL, Mr. Stroustrup uses non-const ints
> for parameters over const ints, but I thought he was doing that for some
> reason that I had not learned about yet and so was using "const int"; that
> is, using const on parameters passed by value.

No, I think he's using non-const parameters because there's no need to make
them const and because it's the convention.

> I did this because I wanted
> to make sure in my function definitions that I would not modify the
original
> values that were passed. I understand that changing the values would not
> affect the callers, but I did it so that my use of the variables would not
> alter them.

Usually, programmers don't accidentally change the passed parameters. And
even if they do it won't affect anything outside the function. So, most
people don't bother making the parameters const.

> If that is not a good idea, please indicate why. I wish to do
> such things correctly.

My problem with it is mainly that the callers see the interface. For
example:

void f(const char * const p);

Here, the first const is important for the caller, but the second const is
only important for the function. I think it's better if function interfaces
are not cluttered with information not relevant to the caller. However,
others might disagree.

DW

Relevant Pages

  • Re: How would Mr. Stroustrup implement his solution to 12.7[2]
    ... > parameters is right for a real graphics system. ... The Shape objects should ... implement a Surface class that Shapes draw to. ... > enough design, or even the best design, for a system with these ...
    (comp.lang.cpp)
  • Re: (OT) Something From An Ignorant Right Winger
    ... or military firearm in use today is specifically designed to kill. ... if that is the line you wish to draw - anything over .50 ... that by design to *not* be as likely to be lethal. ...
    (comp.sys.mac.advocacy)
  • Re: Design help needed (model view controller)
    ... like to find a better approach and start over with a good design. ... with a draw method and then make a "GraphicLIne" that contains a Line ... duplicating my effort or I can see these lists possibly getting out of ... Imagine that you need to transmit a drawing from ...
    (comp.object)
  • Re: How would Mr. Stroustrup implement his solution to 12.7[2]
    ... > If I had were to have free reign over the design, ... > implement a Surface class that Shapes draw to. ... my draw function took a GraphContext object. ... brushes etc.) and was a wrapper for a Windows device context (or CDC ...
    (comp.lang.cpp)
  • Re: Paradigms which way to go?
    ... > Mt knowledge of polymorphism is limited, but I think this has to do ... > method called draw it will know how to draw whatever was assigned in ... When you call the Draw method on a reference to a Shape object, ... It serves as an interface. ...
    (comp.programming)