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

[lilburne]

A lot of people tend to agree with you, but I really don't understand this
view, as it seems inconsistent to me. Of all the crazy things you can (and
can not) do in C++, programmers pick out this simple one to "not get".

If they did it with all built in types that would be fine,
but they don't typically they do somthing like

f(const int age, double weight);

and leave you wondering why 'age' is being treated
specially. When you examine the code you discover that they
had problem writing the method because they were modifying
age. If their problem had involved weight then no doubt that
would be const and age would not. What you have is const
being attached to function arguements haphazardly. They
aren't saying this method won't change 'age' they are
leaving debugging details in the class interface.

 

[jeffc]

If they did it with all built in types that would be fine,
but they don't typically they do somthing like

f(const int age, double weight);

and leave you wondering why 'age' is being treated
specially. When you examine the code you discover that they
had problem writing the method because they were modifying
age. If their problem had involved weight then no doubt that
would be const and age would not. What you have is const
being attached to function arguements haphazardly.

But to me, it is the "haphazard" that is the problem, not making the
parameter const. I'm sure you've seen something like
void f() const;
void f();
together, when in fact both of them are const functions. But no one ever
complains about this being confusing. Even in C++ FAQs, they recommend
making all appropriate functions const, but they recommend against const
value parameters because "it's confusing". It just seems odd and
inconsistent to me.

 

[lilburne]

But to me, it is the "haphazard" that is the problem, not making the
parameter const. I'm sure you've seen something like
void f() const;
void f();
together, when in fact both of them are const functions. But no one ever
complains about this being confusing.

Well there are two issues there. I'll insist that const
member functions are declared const, and will raise a
software defect notice on any that aren't.

Neither do I like methods that are overriden on const alone.
What you have is an example of a 'candy interface' (Maguire
- Writing Solid Code). I know that it is often done, and
mostly it doesn't hurt, but it can cause problems. At one
point we needed to mark certain objects as having been
modified when mutable methods were called on them. Because
which of the two methods are called depends on the object's
constness retrofitting the system was a costly trawl. We now
discourage the practice and insist that the methods be given
different names.

Even in C++ FAQs, they recommend
making all appropriate functions const, but they recommend against const
value parameters because "it's confusing". It just seems odd and
inconsistent to me.

Anyone coming from a C background knows that if something is
passed by value and the function called won't change it
externally. Therefore to see something like 'const int' in a
function definition leads you to expect a pointer or
reference, that there isn't one makes you think 'perhaps
someone has missed it off'. Its the same as when you see

f(someClass a);

an immediate question forms of why isn't this being passed
by reference.

 

[Oplec]

Would any of you mind offering a design for implementing 12.7[2] that
complys with Mr. Stroustrups constraints? I have provided the source code to
my particular solution in hopes that it might be used as a basis for a quick
solution that is more proper than my own.

Thanks, Oplec.

 

[David White]

Would any of you mind offering a design for implementing 12.7[2] that
complys with Mr. Stroustrups constraints? I have provided the source code to
my particular solution in hopes that it might be used as a basis for a quick
solution that is more proper than my own.

I read the exercise again and it made more sense. I was getting hung up on
the purpose of the contact points for something like a line drawn at an
angle. A colleague suggested that the contact points could be the points you
would "grab" in a drawing editor to modify the shape. (The same colleague
then complained that I "always have to understand every detail". Apparently,
I ask too many questions instead of just accepting what's written.)

Although the contact points seem to overly complicate the line class for
this exercise, they are useful for a rectangle, since you will have other
shapes attached to the corners when drawing something like a house.

I've had a look at your code, and it's fine. The reason the exercise had a
Window::draw became clear when I saw your code, i.e., that the window needs
to keep track of its current position by using the se() point of the shape.
Alternatively, the shape could pass its se() to the window instead after
drawing. You could probably have an argument over which class has the
responsibility for doing this, but it's certainly simpler having the window
do it.

The window's then calling the shape's draw by passing a reference to itself
is how I'd envisaged it. Really, there's no other reasonable choice once
you've called w.draw(shape).

I can't find anything to criticize in your design. It's as good as it can be
in my opinion. I can't see anything much wrong with the implementation
either. One thing I'd suggest is making Shape a class rather than a struct.
Although the struct works, it is most unconventional to have an abstract
class such as Shape declared as a struct. Structs are usually used only as
POD ("plain old data") types. 'Shape' being a struct would probably confuse
people.

DW

 

[David White]

The reason the exercise had a

Window::draw became clear when I saw your code, i.e., that the window needs
to keep track of its current position by using the se() point of the shape.
Alternatively, the shape could pass its se() to the window instead after
drawing. You could probably have an argument over which class has the
responsibility for doing this, but it's certainly simpler having the window
do it.

Actually, it seems far more logical to me for the window's current position
to be the most recently drawn pixel. Why should it be a shape's se() point?
Maybe Stroustrup specified it that way as an excuse to demonstrate virtual
function calls through an abstract class's interface.

DW

 

[Oplec]

Actually, it seems far more logical to me for the window's current position
to be the most recently drawn pixel. Why should it be a shape's se() point?
Maybe Stroustrup specified it that way as an excuse to demonstrate virtual
function calls through an abstract class's interface.

Mr. Stroustrup has his readers extended previous exercises throughout his
book. This allows for the reader to learn how to implement code that can be
easily extended and also for him to use more advanced exercises that
wouldn't be possible if users didn't already know about linked-list or have
one that they understood. So, for instance, he has his user implement a
linked list in one exercise using just modules, then in another they are to
implement those modules as a class, then they are to add a sort member. Do
those exercises was very beneficial for my learning the language and they
are a further motivation to continue to anwer and solve all of the
exercises. The calculator exercises were a lot of fun to do, and I'm so
amazed that I actually understood it since I have not programmed before.

Since nobody has so far indicated as to how I could improve my solution
further, besides the use of "const int" and "shape&", which I have altered,
I suppose I will now continue the other exercises.

Thank you all for your time and assistance, Oplec.