Pointers and Teaching C++ [was Re: A little disappointed]
From: Anthony Borla (ajborla_at_bigpond.com)
Date: 12/06/04
- Next message: Anthony Borla: "Re: Windows programming"
- Previous message: Anthony Borla: "[OT] Tiered Applications [was Re: Learning]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 06 Dec 2004 13:51:01 GMT
"Alwyn" <alwyn@blueyonder.co.uk> wrote in message
news:pan.2004.11.29.13.41.21.188256@blueyonder.co.uk...
> On Sun, 28 Nov 2004 22:27:39 +0000, Anthony Borla wrote:
>
> > "Alwyn" <alwyn@blueyonder.co.uk> wrote in message
> > news:pan.2004.11.28.12.49.33.431401@blueyonder.co.uk...
> >> On Sun, 28 Nov 2004 07:33:24 +1100, David White wrote:
> >>
> >> Pointers have been called 'the gotos of data' in that they
> >> introduce pitfalls for the unwary and are a source of
> >> programming errors.
> >>
> >
> > True.
> >
> > However, I'd suggest one way of improving matters is to make
> > the unwary more wary via eduaction / training rather than
> > teaching avoidance [or as some languages have done, disallow
> > programmer access to the facility, thus forcing avoidance].
>
> Well, the modern way of teaching C++ seems to be to
> introduce it as a higher-level language, without touching
> on pointers at all, or leaving them till a later stage of the
> learning process.
>
I've nothing against this teaching approach. It is a perfectly valid
approach, especially where the student has little previous programming
experience.
>
> This is the approach taken by Koenig and Moo in *Accelerated
> C++*, and also, I believe, by Glassborow in his beginners'
> book.
>
I'm not familiar with either work, and have no cause to believe they are
other than quality products that effectively fulfil their aims.
My comments were directed at the philosophy behind implementing languages
like Java where *many* facilities such as raw pointer access / manipulation
are removed in order to create a 'safer' language and stop programmers
tripping over their own feet. While I can see certain benefits in doing
this, I'd prefer an approach where the tools are not 'crippled'; instead the
programmer is better educated in tool use so he knows not only how to
effectively use them, but also what *not* to do with them.
A similar type of 'crippling' occurs if important concepts / techniques are
avoided, or postponed too long, as can happen with [not] teaching pointer
usage in a C++ context. It not only prvents solid skills being built, but
may also help instill a certain sense of fear in using such facilities.
I make these points for two reasons:
* My ideal teaching philosphy involves complete disclosure
and trust; teach the student all there is to know about a
knowldege area, and trust that they will use that knowledge
wisely
* Languages like C++ are powerful systems languages; their
users must be quite knowledgable and skilled in many areas
for these tools to be safely and effectively used
If it is deemed desirable [for whatever reason] to avoid teaching certain
concepts or techniques, then it is probably wiser to teach programming using
a less powerful, higher level language such as one of the popular scripting
languages.
>
> Of course, we all know that C++ has pointers,
>
Ah, that's where I disagree to a certain extent. Given that:
* Pointer usage [in a C++ context] tends to be taught at a
later stage [if at all], and
* Pointer usage is actively discouraged
then it is only more advanced students, or more experienced programmers who
have this knowledge, and, quite possibly, some of those may not even have a
solid grasp of this all-important area.
I realise that pointer usage is idiomatic in a language like C, thus is a
topic that is covered early in even an introductory course. However, since
it is not generally considered idiomatic in C++, where the emphasis tends to
be on things like inheritance / polymorphism, and templates, pointer usage
tends to be presented simply as a means of enabling these facilities, and
its wider applicability glossed over or not taught at all.
The point I wish to make is that pointer usage [and the more general concept
of indirection] is also part of the C++ 'substrate', and in order for a
solid understanding of the C++ language to be imparted, pointer usage should
also, I believe, be presented fairly early in a C++ teaching program, and be
dealt with in depth, no less in fact, than would be taught in a C course.
It is in order to ensure that:
* Such low-level topics are adequately covered, and that
* A systematic separation of concepts and programming styles
be made
that I recommend approaching C++ not as a single language but a
multi-faceted language collection, and designing courses that present and
fully explore each of these facets separately.
So, for example, I'd tend to avoid the C++ 'sampler' course approach in
which time is devoted to teaching ['introducing' might be closer to the
truth] each of its facilities without tying these into a coherent whole [a
Google search will reveal a number of such courses].
Instead, adopt an approach which recognises the language's richness, and
intelligently presents it as a collection of logically-related subsets:
[1] Teach a C-like subset of C++; the approach would be
procedurally-oriented, and one exploring the C-derived
Standard Library components, as well as core facilities
like structures, and pointers but specifically avoiding
the use of Iostream, templates, and the STL
[2] Teach OOP, but:
- Avoid Iostream, templates, and the STL
- Introduce inheritance and polymorphism [i.e. virtual function
use], but avoid making this the central OO concern
- Concentrate on an object-interactive approach, that is,
show how objects can interact, and be combined
into elaborate designs to solve problems
- Container could probably be discussed, but do so
using a non template-based library
[3] Teach the 'classic' C++-only facilities which of course
include things like templates, and practical examples
of template usage in via covering Iostream, and STL
usage. With previously-obtained OOP knowledge a
more thorough exploration of these facilities could be
undertaken giving the student a far deeper understanding
than would otherwise be the case
[4] Teach compile-time metaprogramming
While many issues in [2], [3], and [4] could have been further discussed the
point I wish to stress is that the 'mixing' of C++ styles / facilities
should be avoided in introductory level courses since it only leads to
confusion, and helps generate the mistaken notion that C++ is overly complex
[what knowledge area wouldn't be so considered if there is a 'bombardment'
of many new ideas too early on ?].
I also strongly believe that [1] should *not* be glossed over as it is here
that many 'bedrock' programming concepts will be learnt. Furthermore, I
believe the teaching of procedural programming be a first step in teaching
any programming because:
* It most naturally meshes with everday problem solving techniques
i.e. we are taught to solve problems in a top-down, step-by-step
manner, so programming in this way would not require mastering
totally alien ideas
* Provides the most immediately usable programming knowledge,
reflecting the reality that the bulk of programmers *will not* be
working on gargantuan software systems where the OOP and
metaprogramming features of C++ will be of most use, but will
instead be creating or modifiying much smaller systems, very
likely applications written in scripting languages
If such approaches are not taken then vitally important 'bedrock' concepts,
like pointers / pointer usage, may not get taught effectively. Those
claiming to 'know' C++ because they've completed one or more courses may
not, in fact, know the language as well as they have been led to believe.
>
> which are treated almost identically to those of C, and so
> cannot be a real high-level language, but with its references
> and standard library, it makes a passable attempt at imitating
> one.
>
I'm not sure I agree with the notion that a language which allows raw
pointer access / manipulation is not a 'high level language'. To my mind any
language that combines a set of control structures together with a 'toolbox'
[i.e. sufficiently high level set of reusable routines] is entitled to be
viewed as 'high level'.
To me 'high level' means close to the problem space, so by this definition,
even an assembler language coupled with a comprehensive macro library could
be considered 'high level' [though, of course, many would disagree !].
Still, I think I see your point.
>
> Ideally, even an experienced C++ programmer is recommended
> never to handle raw pointers but rather use them wrapped up
> in so-called smart pointers.
>
Certainly since they're paid to be productive, they would reuse existing,
presumably well-tested, components. It almost goes without saying that they
would code at a higher level than raw pointers permit.
Despite this, familiarity with pointer-based techniques would still be
required, if not mandatory. It's difficult to envisage someone without such
knowledge effectively diagnosing an STL container-related problem, or able
to decide whether functors or function pointers would make for a better
solution to a problem.
>
> Since the only thing approaching a 'smart pointer' in the current
> standard is the fragile 'auto_ptr', one must either use a third-party
> library or invent one's own.
>
I think the Boost library offers a number of useful smart pointer
implementations. I'd opt for using such functionailty rather than 'rolling
your own' [except, of course, for learning purposes].
Cheers,
Anthony Borla
- Next message: Anthony Borla: "Re: Windows programming"
- Previous message: Anthony Borla: "[OT] Tiered Applications [was Re: Learning]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
