«

The eighth chapter (chapter 2.1) of my attempted Correct C++ tutorial is now
available, although for now only in Word format -- comments welcome!

Use the free & system-independent Open Office if you don't have Word.

Classes
<url: http://home.no.net/dubjai/win32cpptut/w32cpptut_02_01.zip>

Introduces the C++ language feature used to define new types, namely
classes. The focus in on creating safe and reusable classes. As a main
theme the jugs-puzzle program from chapter 1.4 is revisited, and the
chapter ends with an example program that solves the puzzle.

General URL:

<url: http://home.no.net/dubjai/win32cpptut/html/>

which provides chapters 1.1 and 1.2 as web-pages (HTML) in addition to the
original Word documents of all chapters in zipped format.

Contents, chapter 2.1:

1 [Background:] PODs, aggregates and pure C++ classes.
2 Classify and define general object member routines.
3 Place inline routine definitions in header files.
4 Design i/o-free classes.
5 Adjust a class to support ease of use, I.
6 Refactor user interface code as a class (class as module).
7 Make a class almost foolproof wrt. access to members.
8 Take charge of per-instance initialization with constructors.
9 Prevent implicit conversions by using explicit constructors.
10 Adjust a class to support ease of use, II.
11 Default constructors & the constructor call guarantee.
12 Use constructor initializer lists to initialize members.
13 A complete example of using classes in a program.

As before, the point of inviting comments is to _fix_ anything incorrect, or
the presentation, or whatever; your input is valuable, and you can thereby
help those who stumble across this tutorial and use it to learn C++.

Thanks in advance,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Alf P. Steinbach wrote:
[snip]
> Contents, chapter 2.1:

I think a general "motivation" behind the REASONS to WHY the world
evolved into OOP instead of functional programming is lacking.
A big point in the whole OO motivation the way I see it (some people
will say it's a motivation behind only C++, I'd say OO) is typesafety!
(That's why C++ is THE best OO language even though lacking several big
OO features...)

If you encapsulate the function "wag()" in the class "DogTail" you
don't run the risc of of wagging() the Dog!
Or said in plain English, if you don't have typesafety you can run the
risc of trying to fly() a Submarine...

Another objective behind classes the way I see it is encapsulation and
datahiding.

Might be I've missed out several good points here, but my point is that
you should first MOTIVATE your readers before trying to teach them
something new which will seem unnessecary for them to spend time on at
first...

Also I'd stress the private keyword to a much bigger extend, after all
if the private data wasn't around in classes there would be no point in
having classes since the whole idea is encapsulating the functions
together with the data meaning that every operation possible for X
resides inside X which means you can easily see the X's interface and
easily spot all potential problem areas of X (X's public data and
functions)

I'd like to have a header called "The problem" and another called
"Encapsulation and private as your biggest friend" or something...

After all, classes are not about what you CAN do, they're about what
you CAN NOT do!!

Apart from that as usual off course excellent work Alf!

Btw, I'm still waiting for an answer regarding if I can mirror your
tutorials on the SmartWin website...

Thomas Hansen


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

* Thomas Hansen:
> Alf P. Steinbach wrote:
> [snip]
> > Contents, chapter 2.1:
>
> I think a general "motivation" behind the REASONS to WHY the world
> evolved into OOP instead of functional programming is lacking.

All in good time...

For this chapter I just stressed how C++ has language features that
directly solve the problems encountered and solved less elegantly and less
safely in earlier chapters.

That's sort of personal motivation to start using classes; why the
world at large did so is, summary, (0) Vannevar Bush, I hope he's not
a relation to GW, and his technological insights, (1) simulations, Simula,
Norsk Regnesentral / Oslo University late 1960's, -> (2) Alan Kay, trying
to make sense of an Algol compiler that was actually Simula, and also
having picked up the ideas of Bush, -> (3) the Smalltalk GUI + language + OS +
computer + network + usability + pedagogical ideas project at Xerox Palo Alto
Research Center (Xerox PARC) in the middle 1970's to early 1980's, -> (4)
Bjarne Stroustrup doing simulations and as just about everyone else extending
C with OO ideas, cirka 1980, (5) the Apple Lisa, the fruits of Apple being
invited to evaluate Smalltalk, and not being as silly as HP or was it
Tektronix (who tried to make a GUI based on a vector graphics terminal), (6)
the Apple Macintosh, a kind of Lisa Light, (7) X11 and MS Windows, middle to
late 1980's, and I have to ask, whatever became of Taxi and all the other GUIs
for PC's, and not to forget, Niklaus Wirth's Oberon machine Lilith?


[snip]
>
> Btw, I'm still waiting for an answer regarding if I can mirror your
> tutorials on the SmartWin website...

I wasn't aware you'd asked. But by all means. _If_ you put a date on it
(when copied), a reference to the original, and wording to the effect that
the copy may not be the latest update. It is of course simpler to just
provide links. That way the site may even be listed in Google!

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Thomas Hansen wrote:
> Alf P. Steinbach wrote:
> [snip]
>
>>Contents, chapter 2.1:
>
>
> I think a general "motivation" behind the REASONS to WHY the world
> evolved into OOP instead of functional programming is lacking.
> A big point in the whole OO motivation the way I see it (some people
> will say it's a motivation behind only C++, I'd say OO) is typesafety!
> (That's why C++ is THE best OO language even though lacking several big
> OO features...)

I might be mis-interpreting your comments here, but type safety little
to do with OO - its only relevant in UP Languages that are static typed.
Dynamic typed languages exist and are also OOPLs.

snipped remaining...


Andrew

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

In article <d262kr$s9f$>,
Andrew McDonagh <> wrote:

> Thomas Hansen wrote:
> > Alf P. Steinbach wrote:
> > [snip]
> >
> >>Contents, chapter 2.1:
> >
> >
> > I think a general "motivation" behind the REASONS to WHY the world
> > evolved into OOP instead of functional programming is lacking.
> > A big point in the whole OO motivation the way I see it (some people
> > will say it's a motivation behind only C++, I'd say OO) is typesafety!
> > (That's why C++ is THE best OO language even though lacking several big
> > OO features...)
>
> I might be mis-interpreting your comments here, but type safety little
> to do with OO - its only relevant in UP Languages that are static typed.
> Dynamic typed languages exist and are also OOPLs.

And there are many strongly-typed functional programming languages.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Chris Riesbeck wrote:
> In article <d262kr$s9f$>,
> Andrew McDonagh <> wrote:
>
> > Thomas Hansen wrote:
> > > Alf P. Steinbach wrote:
> > > [snip]
> > >
> > >>Contents, chapter 2.1:
> > >
> > >
> > > I think a general "motivation" behind the REASONS to WHY the
world
> > > evolved into OOP instead of functional programming is lacking.
> > > A big point in the whole OO motivation the way I see it (some
people
> > > will say it's a motivation behind only C++, I'd say OO) is
typesafety!
> > > (That's why C++ is THE best OO language even though lacking
several big
> > > OO features...)
> >
> > I might be mis-interpreting your comments here, but type safety
little
> > to do with OO - its only relevant in UP Languages that are static
typed.
> > Dynamic typed languages exist and are also OOPLs.

You're right off course, but both OO and strongly typing both try to
achieve the same goal.
They both want to make sure you don't try to fly with your submarine
and go under water with your plain...
OO by coupling the functions with the type and typesafety by making
sure you have the right type for the right task.
So to differentiate them in the conceptual idea is for most languages
wrong.
Most (good) languages that supports one also supports the other as long
as it can.
Off course after OO and typesafety came around in practical use lots of
other "features" where added (discovered) like reuse, data hiding,
encapsulation, cohesion and so on.
But in the beginning it was all about denying a submarine to fly!

>
> And there are many strongly-typed functional programming languages.

But their motivation is still the same, OO is just after all an
extremity of typesafety.
Instead of having a method signature with a given type and issuing a
compiler warning/error when trying to call the method with the wrong
type you couple the method within the type making it impossible to make
your sub fly...
In practise you're right, in theory I must declare that I dissagree.

But I guess this is one of those subjects where we all do alot of
armwaving and "you know what I mean" stuff...
At least in the theoretical perspective.
Let the chicken and egg problem pass us unnoticed!



Thomas Hansen


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Thomas Hansen wrote:
> Chris Riesbeck wrote:
>
>>And there are many strongly-typed functional programming languages.

Most (all?) useful high level languages are strongly typed. The last
time I used a weakly typed high level language was programming in TCL,
which was difficult due to its weak typing. The languages I use now (C,
Python, Lisp) are all strongly typed.

> But their motivation is still the same, OO is just after all an
> extremity of typesafety.
> Instead of having a method signature with a given type and issuing a
> compiler warning/error when trying to call the method with the wrong
> type you couple the method within the type making it impossible to make
> your sub fly...
> In practise you're right, in theory I must declare that I dissagree.
>
> But I guess this is one of those subjects where we all do alot of
> armwaving and "you know what I mean" stuff...
> At least in the theoretical perspective.
> Let the chicken and egg problem pass us unnoticed!
>

It seems to me like you're looking at OO backwards. OO to me is about
polymorphism, where you think of things in terms of shared interfaces
and per-call implementations. What is dispatched on doesn't matter as
much to me as that the dispatch exists. The dispatch has the side
effect of type-safety, but that has never seemed to me to be the prime
motivation.

-- MJF

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Thomas Hansen wrote:
> Chris Riesbeck wrote:
>>Andrew McDonagh wrote:
>>
>>>I might be mis-interpreting your comments here, but type safety
>>>little to do with OO - its only relevant in UP Languages that are
>>>static typed.
>>>
>>>Dynamic typed languages exist and are also OOPLs.
>
> You're right off course, but both OO and strongly typing both try to
> achieve the same goal.
> They both want to make sure you don't try to fly with your submarine
> and go under water with your plain...
> OO by coupling the functions with the type and typesafety by making
> sure you have the right type for the right task.
> So to differentiate them in the conceptual idea is for most languages
> wrong.

OOP emphasizes the following concepts:
Objects;
Abstraction;
Encapsulation;
Polymorphism; and
Inheritance.

Whether or not datatyping is done at compilation or runtime is
orthogonal to the above concepts [1].

>>And there are many strongly-typed functional programming languages.
>
> But their motivation is still the same, OO is just after all an
> extremity of typesafety.

Type safety merely mandates that the type of data objects is fixed and
does not vary over the lifetime of the object. This has nothing to do
with the concepts emphasized by OOP.

> Instead of having a method signature with a given type and issuing a
> compiler warning/error when trying to call the method with the wrong
> type you couple the method within the type making it impossible to make
> your sub fly...
> In practise you're right, in theory I must declare that I dissagree.

Don't give your submarine a fly() method (unless you want it too, of
course) .

Or, if you mean a fly() method on a pilot, there are two equally valid
approaches:
1. Give it the ability to fly various classes: planes, blimps,
helicopters, dragons, etc.; or
2. Give it the ability to fly anything with yaw, pitch and roll controls.

Static typing is the first approach, dynamic typing is the second.


[1] With the exception of polymorphism. It can be argued that dynamic
typing automatically implies/enables (parametric) polymorphism without
needing any special language constructs.

TTFN,
--
Ben M.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

* Ben Measures:
>
> Type safety merely mandates that the type of data objects is fixed and
> does not vary over the lifetime of the object. This has nothing to do
> with the concepts emphasized by OOP.

Type safety does not mandate that the type of data objects is fixed.

Smalltalk is a language that provides for type safety mainly via dynamic type
checking (I don't know whether there is static checking in modern Smalltalks).

C++ is a language that provides for type safety in some cases via dynamic type
checking.

I think it can be argued that Smalltalk is effectively more type safe than C++
(I also think the opposite can be argued, and then it boils down to what kinds
of type safety one cares about the most in any particular context).

However, I'm not sure that it's Good to single out type safety as what OO is
all about, and say that that is mainly what this tool is for. Rather, I think
a certain ease of providing type safety is a _requirement_ for any successful
OO mechanism, because it's difficult or meaningless to apply abstraction when
any object can be anything, or invalid wrt. the assumed type. C++ is
interesting in this respect because the C++ mechanisms for ensuring type
safety are very pragmatic ones where the difficulties mount exponentially the
stronger your goal of type safety is, and yet it has, in practice, been good
enough that C++ is a very successful language, used for very complex systems.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

M Jared Finder wrote:
[snip]
> > But their motivation is still the same, OO is just after all an
> > extremity of typesafety.
> > Instead of having a method signature with a given type and issuing
a
> > compiler warning/error when trying to call the method with the
wrong
> > type you couple the method within the type making it impossible to
make
> > your sub fly...
> > In practise you're right, in theory I must declare that I
dissagree.
> >
> > But I guess this is one of those subjects where we all do alot of
> > armwaving and "you know what I mean" stuff...
> > At least in the theoretical perspective.
> > Let the chicken and egg problem pass us unnoticed!
> >
>
> It seems to me like you're looking at OO backwards. OO to me is
about
> polymorphism, where you think of things in terms of shared interfaces

> and per-call implementations. What is dispatched on doesn't matter
as
> much to me as that the dispatch exists. The dispatch has the side
> effect of type-safety, but that has never seemed to me to be the
prime
> motivation.

Might be OO is polymorphism for you, but the single most importent
feature today with OO according to it's "creators" is Data Hiding also
known as Encapsulation!
You've got a "black box" you know if you feed it a direction it will
try to move in that direction, how this is being done is up to the
implementation to decide.
If this is a shared interface, a template policy, a concrete class is
less importent.
The point is that it may rely upon 500 non visible functions and 1000
private data-members which you don't even know exists!
Before OO we had stuff like (C) void * (typesafety), struct's where all
the data was "wide open" to manipulate for everyone (no encapsulation)
etc.
Basically if you had a bug somewhere you had a scope of "all the code".
After OO we could narrow that scope to only public functions and public
data in the class.
OO is about RESTRICTING developers from doing things (data hiding,
encapsulation, typesafety), not ENABLING them to do things
(polymorphism, inheritence etc.)

Ask your self how many times you've used virtual functions and how many
times you've used private data-members/function-members...


[2_cents_of_zen_philosophy_in_the_morning]

The perfect class has no public members, no public data, can not be
copied, can not be assigned to, can not be instantiated and can not be
destroyed...
That's the perfect class!
(ref: If something is available it will cause trouble! )

[/2_cents_of_zen_philosophy_in_the_morning]



Thomas


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]