Re: Good links for handling with pointers?
On Oct 23, 12:52 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Oct 22, 10:06 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
Markus Pitha wrote:
you are surely right when you say that I'd rather use these librarie=
s.
But my target is it to improve my C++ skills. I think that perfect
handling with pointers is one of the basics if someone wants to cope
with C or C++. And I think that my pointer knowledge is still
insufficient.
Uhm, handling of dynamic allocation is hardly one of the _basics_.
It depends on what you're doing. It's certainly basic to the
applications I work on: a client connects, and creates an
order---where'm I going to put it, if not in dynamic memory? On
the other hand, in such applications, handling dynamic
allocation is usually pretty trivial as well. When the order
has been fully processed, it removes itself from the order table
(actually a hash map) and delete's itself.
The STL offers a good deal of dynamic data structures that
allow you to have data in dynamic memory without new()-ing
them yourself.
In business applications or process control, you'll have a lot
of individual entity objects with very arbitrary lifetimes:
they'll be created on reception of an external event, and
destructed on reception of a different event. That means
dynamic allocation. And there's nothing in the STL which will
help here, at least not directly. (The STL will usually be used
to hold pointers to the objects: at the very least, an std::set
or std::map, in order to find the object given an external
identifier. But the STL doesn't manage the objects, and no STL
container can really be considered "owner" of the objects.)
In teaching C++, I would first discuss the standard containers
before I dive into new() and delete(). (In fact, I would be
inclined to discuss new() and delete() in the context of
implementing containers.)
As I said, I'd almost certainly present std::vector and
std::string before pointers. In my mind, they're really "basic"
types in C++. However, dynamic data structures are a fact of
life, and more important and more fundamental than, say, the
ability to correctly design and write a class template, or even
(IMHO) inheritance.
I'd also expect even a relative neophyte to be able to implement
simple dynamic data structures, like double linked lists.
I don't.
It's about the simplest dynamic data structure I can think of.
I would rather expect the implementation of a
relative neophyte to contain subtle bugs like leaking memory
when copy-constructors throw. The cumbersome issue will be
that the neophyte will not even be able to see those issues.
There are several layers which have to be addressed. I'd
definitly start with lists of basic types.
It is a necessary skill, that much is true. And pointers are
part of the core language. However, I think that acquirering
pointer skills should come somewhat late in the learning
process.
Late, as compared to what? I'd teach pointers before exceptions
or writing (as opposed to usiing) templates.
Here, I strongly disagree. I would definitely discuss
try-throw-catch before diving into dynamic allocation issues.
The reasons are in the part of my previous post that you
snipped.
Given that new may throw, you may have a point there. But any
discussion of exceptions at that point would be very
superficial; at some point, IMHO, it's acceptable that a
student's program crash in the absense of sufficient resources.
The student can't learn everything at once.
I'd probably teach them before inheritance, virtual
functions, and the rest.
You have a valid point here: The whole OO business needs
pointers to actually model the subclass thing (aka
is-a-relationship). If D is derived from B, it is not really
true that values of type D form a subset of values of type B.
The map from
Values(D) --> Values(B)
is a projection called slicing. On the other hand, the map
Values(D*) --> Values(B*)
is an honest inclusion: every D* is a B*.
Now the question is whether that observation implies that
pointers should come early or whether the right conclusion is
that OO should come late.
The problem here is that OO is really a design concept. There's
no point in teaching OO programming (in C++, or in any other
language) unless the programmer has mastered OO design. Of
course, replace OO with any other paradigm, and the same
statement still holds.
To tell the truth, I'm not sure how to approach this problem.
The general rule seems to be that a programming language (some
programming language) is taught right at the start. The result
is that you have to teach simple cases which don't require
design (because the students don't know design), and about all
you can really teach them is the basic mechanics of the
language: int and double, if and loops, and things like that.
And even that is limited---you normally only use a loop because
the design calls for it.
Among the courses I've seen (but I've not seen too many), the
only exception is the one at MIT. And there, the language is
Scheme---a language whose "mechanics" are so trivially simple
that you can spend time presenting design at the same time.
I think you could probably do this with a subset of C++ and a
specially designed library *for* *beginners* (which the STL is
not). I also think that doing this, you'd probably teach
pointers before you even got to classes---simple C-like struct's
are sufficient for a lot of things (provided you've provided the
necessary underlying tool kit).
I strongly sympathize with the later point of view. However,
teaching C++ very likely is not done just to master the
language, but to master specific tasks of programming (i.e.,
there are outside constraints and interests involved). I am
willing to acknowledge that given such constraints, OO might
even be the primary focus of the class, in which case pointers
will have to come very early.
The problem, I think, is that C++ is often used as the "first"
programming language, and that the attempt in that course is to
teach it more or less completely. I don't think that complete
C++, with the complete standard library, is appropriate for
this. (Nor is Java, the other frequent candidate.) I do think
that the power of C++ allows you to *create* a language within
C++ which is appropriate (unlike the case with Java).
If we're talking about a trade school, rather than a university,
where the role is to give them a course in the language, and
then get them employed using it, without any real theoretical
background, then you probably do have to present the OO aspects
early on, because if the student is to be employed working on
business software or industrial process control software, that's
what he'll need to know. Where as he probably won't (or
shouldn't) be called on to implement any basic generic
containers, which IMHO require a good deal of expertise. (But
I'm sceptical about this approach. Somehow, I don't think that
such a course will be able to produce programmers capable of
writing code which is thread safe and exception safe. And both
threads and exceptions are omnipresent in real life code in
these domains.)
On the other hand, I'd probably not teach everything about them
at that point.
[...]
Anyway, the most important knowledge about dynamic allocation
is the many ways of using the STL instead.
Not all of the ways. I'd certainly present std::vector and
std::string before pointers. I'd probably even present
iterators and algorithms, although I'm not sure. But I can't
quite seem teaching someone how to write and STL iterator before
he understands pointer basics.
Teaching how to write an STL conforming iterator is different
from teaching using the STL. I certainly would like the
student to see std::list<T>::iterator before T*.
And probably std::vector<int>::operator[] before either.
I think that pointers (like the STL) need to be handled at
several different levels. Some basic uses should appear fairly
early, where as some of the most subtle parts probably aren't
ever needed by the average programmer.
I am a little worried about the basic uses getting the student
into bad habits that are hard to correct later.
It's something a prof has to watch out for. The bad habits
should result in lower grades, even if the student hasn't been
versed in all of the details as to why they are bad habits. (I
don't generally like this approach, but I don't see any other
real alternative.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34