Re: How would Mr. Stroustrup implement his solution to 12.7[2]
From: Oplec (anonymous_at_anonymous.com)
Date: 10/22/03
- Next message: red floyd: "Is there an inverse of gmtime()?"
- Previous message: jeffc: "Re: Accelerated C++ Sample Solutions"
- In reply to: David White: "Re: How would Mr. Stroustrup implement his solution to 12.7[2]"
- Next in thread: David White: "Re: How would Mr. Stroustrup implement his solution to 12.7[2]"
- Reply: David White: "Re: How would Mr. Stroustrup implement his solution to 12.7[2]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 22 Oct 2003 16:24:10 GMT
"David White" <no@email.provided> wrote in message
news:Nlmlb.6612$d6.290296@nasal.pacific.net.au...
> 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.
If I had were to have free reign over the design, I would most likely
implement a Surface class that Shapes draw to. My only question would then
be whether or not such a Surface should provide the members for drawing to
it, such as put_pixel(), or whether another class should be implemented to
do so. Any ideas?
> 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.
From my understanding of the problem, and how I implemented it, the
Points returned by the n(), e(), ..., members could not be used to draw a
shape unless Window knew of what shape the object being drawn was, such as
Line. That would violate the whole idea of what Mr. Stroustrup wrote in the
chapter; He seems to detest casts.
> No, I think he's using non-const parameters because there's no need to
make
> them const and because it's the convention.
If it is the convention then I will follow it. Thank you for informing
me of this matter since I was not expecting any help on my code, but it is
most welcome.
Thank you for your time, Oplec.
- Next message: red floyd: "Is there an inverse of gmtime()?"
- Previous message: jeffc: "Re: Accelerated C++ Sample Solutions"
- In reply to: David White: "Re: How would Mr. Stroustrup implement his solution to 12.7[2]"
- Next in thread: David White: "Re: How would Mr. Stroustrup implement his solution to 12.7[2]"
- Reply: David White: "Re: How would Mr. Stroustrup implement his solution to 12.7[2]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
