1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
Often it is said that programming in bf(C++) leads to `better' programs. Some
of the claimed advantages of bf(C++) are:
itemization(
it() New programs would be developed in less time because old code can be
reused.
it() Creating and using new data types would be easier than in bf(C).
it() The memory management under bf(C++) would be easier and more
transparent.
it() Programs would be less bug-prone, as bf(C++) uses a stricter syntax
and type checking.
it() hi(data hiding)`Data hiding', the usage of data by one program part
while other program parts cannot access the data, would be easier to implement
with bf(C++).
)
Which of these allegations are true? Originally, our impression was that
the bf(C++) language was somewhat overrated; the same holding true for the
entire object-oriented programming (OOP) approach. The enthusiasm for the
bf(C++) language resembles the once uttered allegations about
Artificial-Intelligence (AI) languages like i(Lisp) and i(Prolog): these
languages were supposed to solve the most difficult AI-problems `almost
without effort'. New languages are often oversold: in the end, each problem
can be coded in any programming language (say i(BASIC) or
i(assembly language)). The advantages and disadvantages of a given
programming language aren't in `what you can do with them', but rather in
`which tools the language offers to implement an efficient and understandable
solution to a programming problem'. Often these tools take the form of
syntactic emi(restrictions), enforcing or promoting certain constructions or
simply suggesting intentions by applying or `embracing' such syntactic
forms. Rather than a long list of plain assembly instructions we now use flow
control statements, functions, objects or even (with bf(C++)) so-called
em(templates) to structure and organize code and to express
oneself `eloquently' in the language of one's choice.
Concerning the above allegations of bf(C++), we support the following, however.
itemization(
it() The development of new programs while existing code is reused can
also be implemented in bf(C) by, e.g., using function libraries. Functions
can be collected in a library and need not be re-invented with each new
program. bf(C++), however, offers specific syntax possibilities for code
reuse, apart from function libraries (see chapters ref(INHERITANCE) and
ref(TEMPLATES)).
it() Creating and using new data types is certainly possible in bf(C);
e.g., by using tt(struct)s, tt(typedef)s etc.. From these types other types
can be derived, thus leading to tt(struct)s containing tt(struct)s and so
on. In bf(C++) these facilities are augmented by defining data types which are
completely `self supporting', taking care of, e.g., their memory management
automatically (without having to resort to an independently operating memory
management system as used in, e.g., bf(Java)).
it() In bf(C++) memory management can in principle be either as easy or as
difficult as it is in C. Especially when dedicated bf(C) functions such as
tt(xmalloc) and tt(xrealloc) are used (allocating the memory or aborting
the program when the memory pool is exhausted). However, with functions like
tt(malloc) it is easy to err. Frequently errors in bf(C) programs can be
traced back to miscalculations when using tt(malloc). Instead, bf(C++)
offers facilities to allocate memory in a somewhat safer way, using its
tt(operator new).
it() Concerning `bug proneness' we can say that bf(C++) indeed uses
stricter type checking than bf(C). However, most modern bf(C) compilers
implement `warning levels'; it is then the programmer's choice to disregard or
get rid of the warnings. In bf(C++) many of such warnings become fatal errors
(the compilation stops).
it() As far as `data hiding' is concerned, bf(C) does offer some tools.
E.g., where possible, local or ti(static) variables can be used and special
data types such as tt(struct)s can be manipulated by dedicated functions.
Using such techniques, data hiding can be implemented even in bf(C); though it
must be admitted that bf(C++) offers special syntactic constructions, making
it far easier to implement `data hiding' (and more in general:
`encapsulation') in bf(C++) than in bf(C).
)
bf(C++) in particular (and OOP in general) is of course not em(the)
solution to all programming problems. However, the language em(does) offer
various new and elegant facilities which are worth investigating. At the
downside, the level of grammatical complexity of bf(C++) has increased
significantly as compared to bf(C). This may be considered a serious drawback
of the language. Although we got used to this increased level of complexity
over time, the transition was neither fast nor painless.
With the annotations() we hope to help the reader when transiting from bf(C)
to bf(C++) by focusing on the additions of bf(C++) as compared to bf(C) and by
leaving out plain bf(C). It is our hope that you like this document and
may benefit from it.
Enjoy and good luck on your journey into bf(C++)!
|
