Object Oriented Programming Using C An

Introduction 1st Edition by Pardoe, King

0333692411 978-0333692417 download

https://ebookball.com/product/object-oriented-programming-using-
c-an-introduction-1st-edition-by-pardoe-
king-0333692411-978-0333692417-15282/

Download more ebook instantly today - Get yours now at ebookball.com

 Get Your Digital Files Instantly: PDF, ePub, MOBI and More
Quick Digital Downloads: PDF, ePub, MOBI and Other Formats

Object Oriented Programming using C 1st Edition by Simon Kendal

9788776818142

https://ebookball.com/product/object-oriented-programming-
using-c-1st-edition-by-simon-kendal-9788776818142-15260/

Beginning C 3 0 an introduction to object oriented programming 1st

edition by Jack Purdum 0470261293 978-0470261293

https://ebookball.com/product/beginning-c-3-0-an-introduction-to-
object-oriented-programming-1st-edition-by-jack-
purdum-0470261293-978-0470261293-15238/

Microsoft Visual C# 2017 An Introduction to Object Oriented

Programming 7th Edition by Joyce Farrell ISBN 1337102100 9781337102100

https://ebookball.com/product/microsoft-visual-c-2017-an-
introduction-to-object-oriented-programming-7th-edition-by-joyce-
farrell-isbn-1337102100-9781337102100-25038/

C Programming An Object Oriented Approach 1st Edition by Behrouz

Forouzan, Richard Gilberg 0073523380 9780073523385

https://ebookball.com/product/c-programming-an-object-oriented-
approach-1st-edition-by-behrouz-forouzan-richard-
gilberg-0073523380-9780073523385-15328/
Object Oriented Programming C Simplified 1st Edition by Hari Mohan
Pandey 978-9381159507

https://ebookball.com/product/object-oriented-programming-c-
simplified-1st-edition-by-hari-mohan-pandey-978-9381159507-15298/

An Introduction to Object Oriented Programming With Java 5th Edition

by Thomas Wu 0073523305 9780073523309

https://ebookball.com/product/an-introduction-to-object-oriented-
programming-with-java-5th-edition-by-thomas-
wu-0073523305-9780073523309-17244/

An Introduction to Object Oriented Programming With Java 5th Edition

by Thomas Wu 0073523305 9780073523309

https://ebookball.com/product/an-introduction-to-object-oriented-
programming-with-java-5th-edition-by-thomas-
wu-0073523305-9780073523309-15256/

An Introduction to Object Oriented Programming With Java 5th Edition

by Thomas Wu 0073523305 9780073523309

https://ebookball.com/product/an-introduction-to-object-oriented-
programming-with-java-5th-edition-by-thomas-
wu-0073523305-9780073523309-15330/

Computer Science An Object Oriented Approach Using C 1st edition by

Behrouz Forouzan, Richard Gilberg 9780077418755 0077418751

https://ebookball.com/product/computer-science-an-object-
oriented-approach-using-c-1st-edition-by-behrouz-forouzan-
richard-gilberg-9780077418755-0077418751-15228/
Macmillan Computer Science Series

A Abdellatif, J. Le Bihan, M. Limame, Oracle - A User's Guide

I. O. Angell, High-resolution Computer Graphics Using C
I. O. Angell and G. Griffith, High-resolution Computer Graphics Using Pascal
C. Bamford and P. Curran, Data Structures, Files and Databases, second edition
P. Beynon-Davies, Database Systems
P. Beynon-Davies, Information Systems Development, second edition
Linda E.M. Brackenbury, Design of VLSI Systems - A Practical Introduction
Alan Bradley, Peripherals for Computer Systems
P.C. Capon and PJ. Jinks, Compiler Engineering Using Pascal
B. S. Chalk, Computer Organisation and Architecture
Eric Davalo and Patrick Nalill, Neural Networks
Joyce Duncan, Lesley Rackley and Alexandria Walker, SSADM in Practice
D. England et al., A Sun User's Guide, second edition
Jean Ettinger, Programming in C++
lS. Florentin, Microprogrammed Systems Design
Michel Gauthier, Ada - A Professional Course
M.G. Hartley, M. Healey and P.G. Depledge, Mini and Microcomputer Systems
MJ. King and lP. Pardoe, Program Design Using JSP - A Practical Introduction,
second edition
Bernard Leguy, Ada - A Programmer's Introduction
M. Leonard, Database Design Theory
David Lightfoot, Formal Specification Using Z
AM. Lister and R.D. Eager, Fundamentals of Operating Systems,fifth edition
Tom Manns and Michael Coleman, Software Quality Assurance, second edition
G.P. McKeown and VJ. Rayward-Smith, Mathematical Foundations for Computing
B.AE. Meekings, T.P. Kudrycki and M.D. Soren, A book.on C, third edition
RJ. Mitchell, C++ Object-oriented Programming
R.J. Mitchell, Microcomputer Systems Using the STE Bus
RJ. Mitchell, Modula-2 Applied
J.P. Pardoe and M.l King, Object Oriented Programming Using C++
- An Introduction
Pham Thu Quang and C. Chartier-Kastler, MERISE in Practice
Ian Pratt, Artificial Intelligence
F.D. Rolland, Programming with VDM
S. Skidmore, Introducing Systems Analysis, second edition
S. Skidmore, Introducting Systems Analysis, second edition
AG. Sutcliffe, Human-Computer Interface Design, second edition
C.l Theaker and G.R. Brookes, Concepts of Operating Systems
M. Thorin, Real-time Transaction Processing
DJ. Tudor and U. Tudor, Systems Analysis and Design - A Compan'son ofStructured
Methods
Al Tyrell, Eiffel Object-Oriented Progru,nming
Other titles
Ian O. Angell and Dimitrios Tsoubelis, Advanced Graphics on VGA and XGA Cards
Using Borland C++
N. Frude, A Guide to SPSSIPC+, second edition
Peter Grossman, Discrete Mathematicsfor Computing
H. Harper and A. Meadows, GNVQ Advanced Information Technology
Percy Mett, Introduction to Computing
P.D. Picton, Neural Networks
Tony Royce, COBOL - An Introduction
Tony Royce, Structured COBOL - An Introduction
Tony Royce, C Programming
Object Oriented Programming
Using C+ +
An Introduction

John Pardoe and Melv King

© J.P. Pardoe and M.J. King 1997

All rights reserved. No reproduction, copy or transmission of

this publication may be made without written permission.

No paragraph of this publication may be reproduced, copied or

transmitted save with written permission or in accordance with
the provision of the Copyright, Designs and Patents Act 1988,
or under the terms of any licence permitting limited copying
issued by the Copyright Licensing Agency, 90 Tottenham Court
Road, London WIP 9HE.

Any person who does any unauthorised act in relation to this

pUblication may be liable to criminal prosecution and civil
claims for damages.

The authors have asserted their rights to be identified as

the authors of this work in accordance with the
Copyright, Designs and Patents Act 1988.

First published 1997 by

MACMILLAN PRESS LTD
Houndmills, Basingstoke, Hampshire RG21 6XS
and London
Companies and representatives
throughout the world

ISBN 978-0-333-69241-7 ISBN 978-1-349-14449-5 (eBook)

DOI 10.1007/978-1-349-14449-5

A catalogue record for this book is available

from the British Library.

This book is printed on paper suitable

for recycling and made from fully
managed and sustained forest sources.

10987654321
06 05 04 03 02 01 00 99 98 97
Contents

Preface ix

1 Programming Concepts 1
1.1 Computer programs 1
1.2 The way a program uses the computer's memory 2
1.3 Input and output of data 4
1.4 Computer program development 6
1.5 The user requirements specification 6
1.6 The design stages 7
1.7 Detailed design using pseudo-code 7
1.8 The programming stage 8
1.9 Compiling, running and testing a program 8
1. 10 Documenting and maintaining pro grams 9
1.11 Writing high-quality computer programs 10
1.12 Exercises 10

2 Object Oriented Programming Concepts 12

2.1 Concept of a model 12
2.2 Object classes and objects 13
2.3 Inheritance 15
2.4 Encapsulation 17
2.5 Polymorphism 17
2.6 Modelling a system using object classes 17
2.7 Exercises 18

3 A First Program 21
3.1 The model for our first program 21
3.2 The C++ code for our first program 22
3.3 Coding style 26
3.4 Pseudo-code for a sequence 27
3.5 Exercises 28

v
vi Contents

4 An Introduction to Inheritance 29
4.1 Using a header file 29
4.2 Inheriting code from our first program into a second
program 31
4.3 Exercises 34

5 Arithmetic 36
5.1 Integers 36
5.2 Assignment statements and integer arithmetic 37
5.3 Real arithmetic 38
5.4 A model for a student's assessment in a subject 38
5.5 Using integer and real numbers, the ini tialise
function 42
5.6 The display functions 44
5.7 Exercises 46

6 An Introduction to Selection 49
6.1 Further development of a model for a student's
assessment in a subject 49
6.2 The i f statement 49
6.3 The if-else statement 52
6.4 Relational operators 53
6.5 Nested selections 54
6.6 Compound statements 56
6.7 Exercises 57

7 Further Concepts for Selection 62

7.1 Further development of a model for a student's
assessment in a subject 62
7.2 Logical operators 62
7.3 Assigning and comparing characters 66
7.4 The swi tch statement 67
7.5 Exercises 71
 Contents vii

8 Repetition 74
8.1 Refining the input processes for the student's marks 74
8.2 The whi le statement 77
8.3 The for statement 80
8.4 The do-while statement 82
8.5 Exercises 85

9 Functions 88
9.1 The function call 88
9.2 The function definition 89
9.3 A revised version of the student marks object class 90
9.4 Call by value parameters 91
9.5 Function results 93
9.6 Call by reference parameters 96
9.7 When to use call by value and call by reference 101
9.8 Exercises 101

10 Constructors and Destructors 106

10. 1 Constructors 106
10.2 Constructors with parameters 109
10.3 Destructors 111
10.4 Exercises 112

11 Introduction to Arrays 114

11.1 The need for arrays 114
11.2 Using an array 114
11.3 Exercises 121

12 Arrays of Objects 124

12.1 Using an array of objects 124
12.2 Aggregation 128
12.3 Exercises 129

13 Two-dimensional Arrays 132

13.1 Using a two-dimensional array 132
13.2 An alternative approach for entering the data 138
13.3 Exercises 140
viii Contents

14 Object Lifetime and Dynamic Objects 143

14.1 Object lifetime 143
14.2 The scope of variables 144
14.3 The scope of objects 145
14.4 Dynamic variables 147
14.5 Dynamic objects 149
14.6 Exercises 155

15 Streams and Files 161

15.1 Disk files 161
15.2 Streams 162
15.3 File streams 164
15.4 Object persistence 172
15.5 Exercises 173

16 Introduction to Polymorphism 177

16.1 What is polymorphism? 177
16.2 Operator overloading 177
16.3 Operator functions 179
16.4 Function overloading 181
16.5 Generic functions 184
16.6 Exercises 187

Appendix A: Object Classes Used in Examples 189

Appendix B : Solutions to Exercises 193

Appendix C : C++ Keywords and Operators 246

Appendix D : The ASCn Character Set 248

Index 249
Preface

Aim of the book

The increasing use of object oriented techniques for software development is now
a fact of life.
• Increasingly large software projects must use object oriented techniques.
• It has been predicted that object oriented programming will provide the
focus for all new software development.
• The concepts of software reuse are becoming increasingly important.
The aim of this book is to provide an introductory course in the use of object
oriented computer programming using the C++ language. It has been especially
designed to teach those with no previous experience of computer programming.
Many student programmers learn more traditional, procedural approaches to
computer programming before tackling the quite different concepts found in
object oriented programming; many students find this switch difficult. Hence the
need for an introductory text that encourages students to understand basic
programming concepts and techniques within an object oriented framework.
Other books in this area have tended to incorporate so much material, much
of it difficult to assimilate, that the novice reader could well be discouraged. The
temptation to include too much has therefore been resisted. Complex terminology
has been eliminated or explained in simple terms.
What we have included are the basic concepts and terminology of object
oriented programming that will enable the reader to 'get started' and build up the
confidence to move on to more advanced texts.

Content of the book

The book develops the techniques of object oriented programming at the same
time as gradually introducing the language features of C++. Procedural aspects
that should be included in any introductory text, such as the use of structured
programming techniques, have been incorporated.
Many straightforward examples are used to introduce and illustrate both new
techniques and language features.

ix
x Preface

Chapter I covers basic concepts in order that the reader can appreciate what
a computer program is. The development of a program is then put in context by
describing briefly, in general terms, the various stages involved. Chapter 2
introduces the basic object oriented terminology and illustrates how object classes
are used to model a very simple system.
Having introduced a C++ program in chapter 3, the important concept of
inheritance and the use of a header file are covered in chapter 4.
Chapters 5 to 8 cover, within an object oriented context, facilities found in
most procedural languages, such as basic data types, arithmetic and control
constructs for selection and repetition. The need for, and the difference between,
the constructs for both selection and repetition are emphasised.
Chapter 9 concentrates on the use of programmer-defined functions; con-
cepts are introduced by referring to functions already used including those found
in standard C++ libraries. The next chapter on the use of constructors and
destructors is a natural development.
The need for arrays and their use is described in chapters 11 to 13. The
concept of an array of objects enables the difference between inheritance and
aggregation to be explained.
Scope rules and object lifetime are emphasised in chapter 14 before introduc-
ing the concept of pointers for dynamic variables and objects. Then chapter 15
covers the use of file streams in general and how they may be used to facilitate
object persistence.
Finally, in chapter 16, we introduce some of the fundamental concepts of
polymorphism and use appropriate C++ language constructs in straightforward
illustrative examples.

Use of the book

Each chapter starts with the learning objectives for the chapter and concludes with
a number of exercises. The chapters have been kept relatively short so that the
reader can use the exercises to ensure that concepts are understood and techniques
mastered in accordance with the objectives.
There are two types of exercise. The first type is a self-assessment question
designed to reinforce major points by referring the reader back to specific
examples in the chapter. The second type of exercise involves either amending
one or more of the example programs or writing a new program. The reader is
strongly advised to attempt all the exercises and for the second type to run the
program and get it working. Sample solutions to all the exercises are given in
appendix B.
An outline design, indicating how each function achieves a specific task, is
provided in most of the examples and all the practical exercises; it is written in a
form of structured English (pseudo-code). This emphasises to the reader the
importance of understanding 'how to solve the problem' before 'coding in C++'.
It also demonstrates how to write pseudo-code and provides appropriate help for
the novice when attempting the practical exercises.
 Preface xi

A model and corresponding object class for a student's performance

(examination and practical mark) in a subject (module) is introduced in a
simplified form in chapter 5. This model is developed and refined in subsequent
chapters as additional features of object oriented programming are introduced.
This case study approach promotes the learning process as well as providing an
awareness of the reality of software systems development using object oriented
programming. A diagram showing all the object classes that are eventually used
and the relationship between them is given in appendix A. This diagram also
indicates where each class is first introduced in the text enabling the reader to
refer back, if necessary, for the full specification.

Acknowledgement
The authors are grateful to Neil Hepworth of South Bank University for his
helpful and constructive comments made while reviewing this book.
1 Programming Concepts

Objectives for this chapter

Familiarity with the programming terms:
• identifier, data type
• integer, float, character and string
• constants and variables
• source code and coding
• compiler, compilation, syntax errors
• program execution, run-time errors, logical errors
• testing, test data, bugs, debugging
• user requirements specification, program design, documentation and
maintenance
• sequence, iteration and selection constructs
• program characteristics: correctness, reliability, modifiability and clarity.
Understanding of:
• how the computer and the programmer identify data items
• how values may be given to data items
• how data are accepted and displayed.

1.1 Computer programs

A computer program is a sequence of instructions, often a very long sequence,
that can be held in a computer's internal storage area (memory) and executed at
speed. The instructions are normally first written down in a human-readable
form, called the source code or program code, and entered into the computer's
memory or a computer file via the keyboard. The source code is written using a
high-level programming language, ~uch as Pascal, C, C++, Ada, COBOL.
Instructions, written in these languages are referred to as program statements.
This source code has to be translated into a form that can be understood by the
electronics of the computer; this is known as the machine code and the
translation process is called compilation.
A computer program will normally take some data values, store the data
in memory and then manipulate the values to produce the required results. For
example, a simple program might take in ten temperature readings in degrees

1
2 Object Oriented Programming Using C++

Fahrenheit and convert them to degrees Celsius. A more complex program for a
company's payroll system would take in a great deal of data, staff names, tax
codes, salary grades and so on, in order to produce results in the form of
payshps and cheques or bank credits. The values that the program takes in are
known generally as the input data and the results are often referred to as the
output. This can be visualised as in figure 1.1.

..
Program

....
held in memory
Data values manipulates data r- Results
stored in memory

Figure 1.1

1.2 The way a program uses the computer's memory

Within the computer itself, each unit of memory (called a byte) is accessed or
addressed by a unique reference number. In some cases a single byte is
addressed, in others two or more bytes are addressed as if they are one complete
unit of memory.
To make programs more readable, however, the programmer refers to
parts of the computer's memory by an identifying name, called an identifier.
Since different types of data are stored differently, we also need the concept of a
data type. The standard data types used in most computer programming
languages are: integer, float (or real), character, and string. An integer item
is restricted so that it will contain only whole numbers within a pre-specified
range, for example in the range -32,768 to +32,767. Data of type float is for
real numbers, that is numbers that may contain a decimal part. While integer
and float data items use more than one byte, an item of type character uses only
one byte and is restricted to contain just one character. The character may be
any that is recognised by the computer, including some special ones as well as
the usual letters of the alphabet and numbers. Finally, a text string is a number
of characters such as a person's name or the name of a product, stored in a
succession of bytes.
We can illustrate the way in which the programmer and the computer
access items of data by considering the diagram in figure 1.2.
If we imagine that the diagram represents a portion of the computer's
memory and that each cell is one byte, we can give a unique numerical
reference to each byte by using the column and row numbers. Hence the cell at
the top left-hand comer containing the letter B is referred to as byte 00, the one
 Programming Concepts 3

to its right as byte 01 and the one directly beneath it as byte 10, and so on.

9 I I
Figure 1.2

Within a program, all we have to do is specify (or declare) the names of

the identifiers (in this case, a_letter, a_number, a_real_number and
a_char_string) and state which data type they are to contain (character,
integer, float, string), the computer references and in most cases the number of
bytes to be used are calculated during the compilation process.
Areas of computer memory reserved to hold data in a computer program
may have initial values (or constant values) pre-loaded into them automatically
when the program is first run, or values may be assigned to the areas during the
running of the program. This is illustrated in figure 1.3.

computer memory
constant value !!

computer memory
program statement
a_letter = 'B' ;

computer memory
Identifier a_letter

Figure 1.3
In this diagram, we have three areas of computer memory. At the top we
have a single byte that is of data type character and it contains the constant
4 Object Oriented Programming Using C++

value B that it will retain for the duration of the program. Not surprisingly, we
call this kind of data constant data. At the bottom of the diagram, we have also
a single byte that has been given the identifying name a_letter and the data
type character. Because a_letter may be given any value during the running
ofa computer program it is referred to as a variable identifier (or just variable
for short). The third area of memory shown is that which is needed to hold a
computer instruction written in the C++ language to change the value of the
identifier so that it contains the letter B; we call this kind of instruction an
assignment statement, it is one way of changing the values held in a computer
program's memory. Another way is depicted in figure 1.4.

computer memory
constant value 12

~
computer memory
Identifier a number 1 32121
before after

Figure 1.4

Here the computer instruction shown, again in the C++ language, is one
that adds a fixed value (the constant number 12) to the existing contents of the
variable identifier a_number giving it a new value. Again, three areas of
memory are shown; the two data areas would be integers.
The above examples use elementary data types containing a single item of
data. Groups of data items may also be declared using a single identifier. The
components of these groups may all be of the same type or of a number of
different types.

1.3 Input and output of data

As mentioned in section 1 .1, a program will normally take in some input values
and produce results known as output.
The input values can be held in computer files on disk or typed at the
keyboard. In either case, the data are first stored in a small area of memory
called a buffer. When a computer program issues an instruction to read or
accept the data, the required value(s) are transferred into memory areas within
 Programming Concepts 5

computer memory
program sraremenr
cin.get (name_oCwrlter, 6) ;

computer memory
Identifier name of writer L........L_.L..~_....L........I

Figure 1.5

mouse
monitor screen

screen buffer

computer memory
program statement
caut« animal« endl ;

Icomputer
L..-L_.L........L_...L.........I
memory
Identifier animal

Figure 1.6

the program. This general process for keyboard input is shown in figure l.5.
The program statement illustrated here is written in the C++ language.
Note that the programmer generally does not need to be concerned with
6 Object Oriented Programming Using C++

the buffer.
The process of producing output is almost the reverse of obtaining input
data. Writing data to a disk file and displaying data on the monitor screen also
involves a memory buffer that we do not need to concern ourselves with unduly.
For such output activities, we need to do two things: identify the memory area
from which the data will be taken and indicate where the output is to be placed;
the name of the computer file and in some cases the position in the file or the
position on the screen where the data are to be displayed. The general process
for displaying just one item on the screen is depicted in figure 1.6. Again, the
program statement is written in the C++ language.

1.4 Computer program development

The stages of computer program development are most often referred to as the
software life-cycle. A number of different models have been produced to
describe this life-cycle with the major differences being the breakdown of the
different stages and the way certain stages may be repeated or occur
concurrently.
In the following sections we describe the stages separately, but it should be
understood that the stages may overlap and that it may be necessary to return to
a previous stage. For example, the testing stage if not completed to the
developer's satisfaction could require adjustments at the programming stage.
A life-cycle model can be applied to a single computer program or a
collection of programs that make up a complete computer system.

1.5 The user requirements specification

The user requirements specification is normally a document that describes in
precise terms what is required of a computer program (or computer system). It
is produced after an analysis process in which systems analysts consult with the
probable eventual users of the system to explore the current and future
requirements in a specific business or technical area. It will be concerned with
what will actually be delivered to the users at the end of the development
process or each development stage.
The user requirements specification is the result of a refining process
whereby general statements of desire or intent to produce a computer system are
formalised; it becomes the foundation for the system's development. An
analysis process (called object oriented analysis or OOA) will define the
components (objects) of the real world that are to be modelled in the proposed
computer system. This will focus on the information that is required to be
processed as well as the functional requirements (specific activities).
The details of how the information needs of the system are to be met or
how the specific requirements are to be provided are not produced at this stage.
 Programming Concepts 7

1.6 The design stages

The design stages translate the user requirements into a representation of the
proposed system that can be assessed for quality and can facilitate the
production of computer program code.
The systems design stage is concerned with all aspects of the system, not
just the production of computer programs. For example, the design of clerical
procedures and management of the system would need detailed consideration as
well as what the computer software is to achieve.
The software design stage is concerned with how the real-world objects
identified in the analysis stage are to be represented in the computer system and
how they may interact.
This will include how and where data are to be stored within computer
files or in computer memory during the running of computer programs. It will
involve the determination of what data are to be grouped together and what
types of data storage are needed for storing different kinds of values.
It will also include a definition of the relationship between the major
components of the system (or program) and design representations of the
detailed processes that the system requires.

1. 7 Detailed design using pseudo-code

As we shall see in the next chapter, a large program is normally broken down
into self-contained parts called functions. Each function consists of the steps
required to achieve a specific task; eventually it will be written in program
statements using the appropriate programming language. First, at this stage, the
tasks are written in an informal notation called pseudo-code.
Pseudo-code contains normal language statements to describe the actions
required and also more formalised control statements to indicate the logic. For
example, the normal language statements for the c++ statements shown in
figures 1.3 to 1.6 are:
Assign 'B' to a_letter
Add 12 to a number
Accept name of writer (from keyboard)
Display animal (on monitor screen)
Control statements are similar to C++ statements and will be described in
detail in the appropriate chapters.
We can describe the logic of most functions using the three constructs:
sequences, iterations and selections.
A sequence is a number of statements that will be executed in the order
written from top to bottom of the paper.
An iteration is the repetition of one or more statements.
A selection is a choice between two or more different actions depending
on the value of a data item or some other condition.
8 Object Oriented Programming Using C++

1.8 The programming stage

Writing computer programs involves far more than just learning a program-
ming language; it is very easy to write poor programs. Problems that we are
trying to solve by computer must be carefully defined. Then when the definition
or specification is clearly understood, we can design a solution to the problem
using pseudo-code. Only after the design process is complete should we
elaborate the design by producing programming language statements (or
program code) from it. This is known as the coding process or implementing
the design.

1.9 Compiling, running and testing a program

As mentioned in section 1. 1, a source program cannot be understood directly by
the computer; it must first be translated into an equivalent program in the
machine language (code) of the computer.
This process of translation (compilation), is performed by a program
stored within the computer called a compiler. This produces a machine-
readable form of the program that is combined with code from the compiler
libraries using a process called linking. This two-stage process produces a
machine language program that is then stored either in a disk file or in
computer memory, but it will only do this if there are no mistakes in the way
you have used the language. If there are syntax errors, that is, mistakes in the
program language grammar, then the compiler will produce error messages.
Once we have produced a program without syntax errors and have a
machine language program in computer storage, we can go to the next stage,
execution. The computer executes the machine code instructions and may
produce the results you require. However, at this stage further errors can occur.
Run-time (or execution) errors occur when the programmer has made a
mistake that was not a syntax error, but still contravenes the computer's rules
(for example, trying to divide a number by zero). In such cases an appropriate
run-time error message is produced.
Logical errors occur even when there are no syntax or run-time errors.
The symptoms for these errors are results that are not as expected. The design
may be wrong or they may arise because the programming language statements
are misused or in the wrong order.
The error messages will help us to find the syntax and run-time errors.
Detecting logical errors can obviously be more difficult. It is vitally important
that we test our program, possibly with a range of data values, known as test
data, to ensure that it works according to its specification. The task of finding
out why a program is not working to specification is called debugging. This is
because logical errors in programs are called bugs. If we discover that the
program is not correct for any reason, then we must change the contents of the
source program.
 Programming Concepts 9

1.10 Documenting and maintaining programs

Documentation is that information concerning a program that is needed by both
users of the program and those with responsibility for maintaining the program.
The former need sufficient detail to enable them to use the program properly.
The latter need sufficient detail to enable them to modify, improve and correct
the program.
Good user documentation is essential if a program is to be a useful tool;
an outstanding piece of software is useless if no one knows how to use it. The
contents and style of a user guide will obviously vary depending on the target
audience. For example, a user guide for a software tool that is to be used by
experienced programmers will need almost no information about how to switch
the computer system on. However, a user guide for the general public, such as a
Windows 95 User Guide will need to contain instructions on how to tum on the
computer and how to use disks.
Good technical documentation is essential for maintaining a program.
We may have to correct errors or we may decide to add features and improve
the program. Programs have actually been thrown away because they are too
difficult to change. A technical manual should enable someone other than the
author, but who is familiar with the design methods and documentation
standards, to understand fully the program's purpose and the way that the
purpose has been achieved.
When do we write this documentation? The rule is, document as you go
along. Much of the user documentation should be written as we start to design a
program, it can serve as a set of specifications. As we proceed with the
development of a program, much of the technical documentation can be written.
This should ensure that the documentation will be of a high quality. If
documentation is left until the end of the project, important details are often
omitted.
When the program is complete and full-scale testing has been done, the
documentation should be reviewed to check that it meets its stated purpose and
that it is accurate and consistent with the finished program.
Maintenance can be defined as "anything that happens to program code
after the initial implementation". It can be classified into four areas: corrective
maintenance, adaptive maintenance, perfective maintenance and preventive
maintenance.
The most obvious form of maintenance is error fixing or corrective
maintenance. Here we concern ourselves with removing a known fault from a
program or system.
Adaptive maintenance is the act of modifying a software unit so that it
interfaces with a changing environment. It commonly occurs when changes in
hardware, the operating system or other system software force alterations to be
made to application programs.
Perlective maintenance is the most common type of maintenance
encompassing enhancements both to the function and the efficiency of the code.
10 Object Oriented Programming Using C++

It usually arises from requests for change to the user requirements specification.
Preventive maintenance is the process of changing software to improve
its future maintainability or to provide a better basis for future enhancements.

1.11 Writing high-quality computer programs

Writing computer programs is both exciting and creative. It also needs discip-
line and a systematic approach if the desired results are to be achieved. This is
because there may be many ways of writing a computer program but not all of
them will lead to the production of a program of the required quality.
To produce high-quality programs, we need to be aware of the four basic
criteria for quality. They are: correctness, reliability, modifiability and clarity.
Correctness is obviously an essential quality in that we would always wish
to ensure that a computer program does what it is supposed to do in the most
appropriate manner. It must satisfy its requirements or specification in all
aspects.
A computer program must also be reliable in that it will always produce
predictable results every time it is run. Most computer programs will operate on
different sets of data each time they are run hence there may be many different
results to be produced.
Of increasing importance as a requirement of high-quality software is
modifiability. Most computer programs will require some modification, or
maintenance, at some time because the requirements of the program may
change or better techniques are discovered or even to correct residual errors.
To be modifiable a computer program must be easy to understand. Hence
clarity is an essential characteristic of high-quality programs. It is easy to
produce over-complex programs. However, it should be noted that bad pro-
grammers produce unnecessarily complicated programs; good programmers
only ever produce simple, clearly understood programs.
Our goal should be to provide high-quality programs using a method of
proceeding from a statement of the program's requirements to high-quality
solution in a reasonable manner. Object oriented design and programming is a
means of achieving this.

1.12 Exercises
1.12.1 State in your own words what is meant by the following terms:
(a) Compilation of a computer program.
(b) Identifier.
(c) Data type.
(d) Variable.
(e) Keyboard buffer.
 Programming Concepts 11

1.12.2 Answer the following questions:

(a) How does a computer programmer identify a particular part of the
memory in a computer program?
(b) What different kinds of data might you wish to use in a computer
program?
(c) What is an assignment statement?
1.12.3 State in your own words what is meant by the following terms:
(a) The user requirements specification.
(b) Pseudo-code.
(c) Testing.
(d) The reliability of a computer program.
1.12.4 Answer the following questions:
(a) Why is the software life-cycle not a strictly sequential set of
development stages?
(b) What type of errors may be discovered when compiling and then
testing a computer program?
(c) What is the process offault diagnosis more commonly called?
(d) What is the difference between user-documentation and technical
documentation?
(e) What are the four types of program or system maintenance?
(f) Why are simplicity and clarity necessary requisites of a good
computer program?
2 Object Oriented Programming Concepts

Objectives for this chapter

Familiarity with the object oriented tenns:
• object and object class
• object class data, object class behaviour and functions
• an instance of an object class
• inheritance, base class, derived class
• encapsulation
• private and public parts of an object class
• polymorphism.
Ability to:
• draw a diagram to represent a simple object class
• draw a diagram to illustrate inheritance of an object class
• model a simple object class in tenns of its data items and behaviour
(functions).

2.1 Concept of a model

Computer programs model or simulate real-world or imaginary-world objects
and their interactions. We can illustrate this by considering a simple computer
game in which the user guides a little figure around a maze. The little figure is
a model of a person who can walk around a maze. As with all models, because
they are models, they do not have all of the facilities of their real-world
counterparts. Our little figure may only be required to "walk" in each of the
four compass directions (because the walls of the maze are at right angles to
each other), and "recognise" when it reaches a wall, and "decide" which
direction to take next. Note that the verbs "walk", "recognise" and "decide"
describe the behaviour or the functions of the model. Other aspects of the
model might be its colour and the size of the figure. These attributes are
infonnation (or data) that describe the structure and nature of the model. They
do not necessarily influence the behaviour of the model, but may do so, for
example, if an aspect of the behaviour was a function to change the colour or
size.
We can describe a real-world object in tenns of its component parts (its

12
 Object Oriented Programming Concepts 13

data) and what it does (its behaviour). When we produce a model of such an
object, we decide which features we are going to use in the model. First we look
at the component parts and choose what we need in our model; we may ask
ourselves "Which of the component parts of the object are important in our
simulation?" Next, we choose those functions of the behaviour of the object that
we wish to simulate.
In what sense do we produce a model or use simulation when developing a
computer program? Clearly, it is not in the same sense as building a model of a
person from clay or wood. Rather, we use pictures, words and numbers. We
manipulate these in the computer to give some desired affect possibly on the
monitor screen. For example, a model of a person in a computer would probably
consist of graphical representations of a person in different poses as well as
descriptive data in words concerning such things as the person's name and
numerical data for such things as size.
So, the model's data can be described in terms of graphics, words and
numbers, but what of the model's behaviour? Each aspect of the behaviour
represents a function to be defined. For example, our little figure in the maze
has a "walk" function. This would be quite a complicated function to imple-
ment; others in different simulations could be more straightforward. For
instance, if we were to produce a computer function to simulate the withdrawal
of money from a bank account, it might be just two simple calculations: subtract
sum of money from account; and add sum of money to contents of wallet.
Object oriented programming emphasises the interconnections between
data items and functional behaviour in a way that puts together information and
processing rather than processing alone. An object is a component imple-
mented in software such that it contains a definition of its data and the
functions (operations) that describe the object's behaviour or how the data is
used or interacts with its environment.

2.2 Object classes and objects

It would be very wasteful to describe uniquely each individual object as we need
them because most objects tend to have some things (data or behaviour) in
common with others. Often it is convenient to group objects together such as in
the field of zoology in grouping animal species with common characteristics.
Such groupings in programming are called object classes.
Object classes can be thought of as descriptions of categories or groups of
objects. For example, the object class car may have a description pertaining to
the relevant features that· apply to all cars. All cars have wheels and an engine;
they consume fuel and so on. The object class employee might have the
general description of all people employed in a certain situation; and would
likely comprise name, date of birth and current salary among other areas of
interest.
We can apply what we have already seen when introducing the notion of
14 Object Oriented Programming Using C++

models to object classes. What we know about the component parts of an object
class is called the member data (or attributes). The member data for an
employee could be name, date of birth and so on. The things we can do
with an object class or its data are called its behaviour. For example, we can
give an employee a pay rise or amend an employee's qualifications. The
definition of the member functions that define an object's behaviour is part of
an object class's description. Each function will normally consist of the actions
required to achieve a specific task.
One way of describing the object class for an employee is by means of an
object schema as given in figure 2.1.

Class: employee t--Identification

name
date of birth
qualifications r---Data
telephone number
etc ..

Amend qualifications
Get telephone number
Calculate age -Functions
Display details
etc ..

Figure 2.1

Notice how we identify the object data and the object behaviour
(functions). In a full description, we would normally have one or more
functions for each item of data. If we asked "What can we do with each item of
data?", the answer would generate a list of functions. For example, if we asked
this question of just one data item, say telephone number, we would likely
generate: insert new number, amend existing number, delete
number, display full number, extract dialling code, and
perhaps many more.
An object is said to be an instance of an object class. This means that an
object is an implementation of an object class definition. We can liken an object
to a more complex version of a variable in a program; a variable has a type that
describes its characteristics (for example, an integer is a whole number within a
certain range); an object has an object class that describes its characteristics.
For example, we might have objects Jim_Brown and Dave_Thomas of the
 Object Oriented Programming Concepts 15

object class employee.

Objects have all the data items and functions of their class. Hence, to
change Jim_Brown' s qualifications, we would use the function amend
qualifications. The object oriented terminology for this is that we "send a
message to the object"; so we send the message amend_qualifications
to Jim Brown.

2.3 Inheritance
If we develop the example of the object class employee, it is easy to see that
there are different kinds of employee all having a common set of characteristics
as described in the definition of the object class employee. Also we can see
that different kinds of employee would have additional, more specific,
characteristics depending on their position or type of work. For example, an
employee who is a manager might be responsible for a number of staff and may
have a secretary (who can be described by name or perhaps employee number).
We therefore need to use the attributes and behaviour from the original class
and extend them to include the particular characteristics of each type of
employee.
The concept of inheritance allows us to produce another class such that it
has all the data and functions of the class upon which it is based (called the
base class). The new class called a derived class can be thought of as a
specialised version of the more general base class.
So, a class that inherits the data and behaviour of another is called a
derived class often referred to as a descendant or a child class. The class that
provides the inherited characteristics is called the base class also referred to as
an ancestor or parent class.
The way in which a derived class is formed by inheritance from a base
class is depicted in the object schema shown in figure 2.2.
An entire inheritance (or classification) hierarchy (like a family tree) may
be constructed from a single class with a number of descendants. This is
illustrated in figure 2.3 where the base class employee has three descendants:
manager, secretary and technician. The manager derived class is
also a base class with one descendant: sales manager.
Note that the inheritance of data and behaviour in a program is usually
achieved by sharing the code and not duplicating it, so the inherited functions
and data do not actually exist in the derived class. To illustrate this, imagine we
wish to use the function get telephone number from the manager
class, the computer would first look for the function in manager, then on
failing to find it there it would look further up the class hierarchy until the
function is found.
16 Object Oriented Programming Using C++

Class: employee Derived class: manager

name
date of birth
qualifications
telephone number
etc ..

Amend qualifications
Get telephone number
Calculate age
Display details
etc ..
~

Decrease number of staff

Change secretary
etc ..

Figure 2.2

employee
(base class)
I
I I I
manager secretary technician
(base class &
derived class) (derived class) (derived class)

I
sales
manager
(derived class)

Figure 2.3
 Object Oriented Programming Concepts 17

2.4 Encapsulation
Putting data and functions together is called encapsulation. A basic principle
of object oriented programming is that member data should only be accessed via
the object's own functions. To achieve this, in all but exceptional cases,
member data items are described as private or protected. Functions may also
be private. If data or functions are to be accessed directly from outside the
object class, they are defined as public.
Encapsulation separates how an object class behaves from how it is
implemented and therefore allows the details of an object class to be modified
without requiring changes to applications that use the object class. The object
class can be treated as a black box, the programmer needs only to know what
functions can be requested and not how they are carried out.

2.5 Polymorphism
Polymorphism means having many forms. In object oriented programming it
refers to the way in which different objects may respond to the same message in
different ways depending on the type of the object. For example, manager and
technician objects should respond differently to the Display details
message. The functions need to be different even though the purpose of the
function is the same, that is, to display the details of the object concerned.
There are a number of ways to implement polymorphism, we will discuss
these later in the text.

2.6 Modelling a system using object classes

Suppose we wish to model the activities of a University; we could define an
object class person with derived classes student and tutor and an object
class course. To keep things simple, let us assume that these are the only
objects of interest and their data items are as follows.

person: name,
reference number,
year of joining the University.
student: as for person,
year of the course.
tutor: as for person,
years of teaching experience.
course: name,
number of students.
Again, to keep it simple, their functions are:
18 Object Oriented Programming Using C++

person: Ini tial.ise detail.s: to allow the entry of the

three data items for a person.
Display details: to display the values of all
three data items of a person.
student: Ini tialise details: to allow the entry of the
three data items for a person, plus the year of the
course.
Displ.ay detail.s: to display the values of all
three data items of a person, plus the year of the
course.
tutor: Ini tial.ise details: to allow the entry of the
three data items for a person, plus the years of
teaching experience.
Display detail.s: to display the values of all
three data items of a person, plus the years of
teaching experience.
course: Ini tial.ise details: to allow the entry of
course name and setting the number of students to
zero.
Add new s tuden t: to use the student initialise
details function and add one to the number of
students.
Display details: to display the course name
followed by the number of students on the course.
We can represent the relationship between the object classes using an
object schema similar to that shown in figure 2.2, as follows in figure 2.4. Note
that, in this case, for the derived classes the functions are over-ridden
(redefined) because they must be different for each class.

2.7 Exercises
2.7.1 State in your own words what is meant by the following object oriented
terms:
(a) An object class.
(b) A function.
(c) An attribute.
(d) Inheritance.
(e) Encapsulation.
2.7.2 Answer the following questions:
(a) In what way is an object similar to a variable?
(b) What are two other names given to derived classes?
(c) What is a software "black box"?
 Object Oriented Programming Concepts 19

Class: person

name
reference no.
Derived class: studen Derived class: tutor
year of joining

Initialise
Display details

year of the course years of experience

Initialise Initialise
Display details Display details
Class : course

name
number of students

Initialise
Display details
Add new student

Figure 2.4

2.7.3 Please examine the object schema in figure 2.2 and answer the
following questions.
(a) What data members are inherited by the derived class manager
from employee?
(b) What other data members might the derived class manager have?
(c) What other derived classes do you think might be derived from the
class employee?
2.7.4 In a warehouse system, the following objects have been identified as
having the data items:
container: name,
location,
weight.
carton: as for container,
destination,
number of components.
20 Object Oriented Programming Using C++

case: as for container,

quality control reference.

The functions are:

container: Initialise details: to allow the entry of
the three data items for a container.
Display details: to display the values of all
three data items of a container.
carton: Ini tialise details: to allow the entry of
the three data items for a container, plus the
destination and number of components.
Display details: to display the values of all
three data items of a container, plus the
destination and number of components.
Amend the number of components.
Amend the destination.
case: Ini tialise details: to allow the entry of
the three data items for a container, plus the
quality control reference.
Display details: to display the values of
all three data items of a container, plus the quality
control reference.
Draw an object schema that shows the relationship between the class
container and the derived classes carton and case.
3 A First Program

Objectives for this chapter

Familiarity with the c++ programming terms and concepts:
• the #include directive
• the keywords class, public and protected
• program comments
• function prototype, definition, heading, result type, arguments
• the resolution operator : :
• the keyword void
• the data type char and a text string
• the object cou t
• the function s trcpy
• the main function
• object class definition
• member data and member functions
• declaring an object as an instance of an object class
• calling member functions.
Ability to:
• understand a simple c++ program that uses a single object class
• understand the pseudo-code for a sequence
• write a simple C++ program based on the example in the chapter.

3.1 The model for our first program

Let us examine a simple program that displays a message on the monitor
screen. We need an object class that defines the contents of the message and at
least two functions. We need a function to give an initial value to the message
and a function to display the contents of the message. With a little thought we
could probably specify other functions such as determining the position on the
screen or defining the colour of the background and foreground for the
message. However, we will keep it simple and produce a model of the problem
in the form of an object class with just two functions, as shown in the object
schema given in figure 3.1.

21
22 Object Oriented Programming Using C++

Class : message f-- Identification

contents (of message) f-- Data

Initialise contents
r - Functions
Display contents

Figure3.!

3.2 The C++ code for our first program

Figure 3.2 contains the complete C++ code to display a message. Please accept
for the moment the necessity for what may appear to be many programming
statements for a straightforward task. The benefits of this approach will only
become apparent when we consider more complicated examples.
We will now explain this program line by line by repeating small parts of
the code with an explanation of the component parts.
The first two lines in our program are comments.
II HELLO.CPP
II A program to display the Hello World message
A comment is introduced by the two consecutive characters I I. Everything that
follows on that line is considered to be explanatory text that does not affect the
running of the program. Comments are ignored by the compiler and are
included to explain the program to a human reader. They can be placed
anywhere in a program, on lines by themselves as above, or towards the end of
a line containing a program statement. It is considered good programming
practice to include comments at the start of a program to explain its purpose. In
our case, we have the purpose preceded by the name of the file containing the
whole program.
Lines 3 and 4 are called include statements.
#include <iostream.h>
#include <string.h>
These lines are instructions to the compiler, known as directives. For the
moment we shall consider such statements as a means by which the compilation
system allows us to use certain of its features. In the first case, the way data is
sent to the monitor screen and read from the keyboard; the "io" is an
abbreviation for input and output and this statement enables us to use the object
cou t later in the program. In the second case, the way we may use groups of
 A First Program 23

II HELLO.CPP
II A program to display the Hello World message
'include <iostream.h>
'include <string.h>
class message
(
public :
void initialise ()
void display ()
protected :
char contents [12]

void message: : initialise ()

strcpy (contents I "Hello World")

}

void message: : display ()

cout « contents « end!

void main ()

message hello ;
hello.initialise ()
hello. display ()
}

Figure 3.2

characters called strings; this statement enables us to use the function s trcpy
later in the program.
The section of code in lines 5 to 12 is a complete object class definition.
class message
{
public :
void initialise ()
void display ()
protected :
char contents [12]
} ;
24 Object Oriented Programming Using C++

The object class definition is introduced by the C++ keyword class followed
by the programmer-chosen class identifier message. The whole of the class
definition is bounded by braces { and }, and finally terminated by a semicolon.
Note that the layout of this section is not a necessary requirement of the C++
language, but indentation has been used to highlight the different component
parts.
Within the braces, we declare the functions and data associated with the
object class. We have two sections labelled by the C++ keywords public and
protected, note the colon that follows these keywords. We label parts of a
class definition in this way to enable or disable the general use of parts of an
object class. In general terms, those parts of an object class that are labelled
public may be used in any part of the program; those labelled protected
may only be used within the definition of the functions of the object class or its
descendants.
In the public part of the class definition, we have two function prototypes
called member function prototypes. These declare the object class functions.
In this case, functions to display and initialise a message. The format consists
of three parts: the result type, the identifier and the arguments. We will not
concern ourselves with the details of these parts other than in the context of
these simple examples. The result type here is void, meaning that the
functions do not produce anything that needs to be classified by type. The
programmer-chosen identifiers are display and initialise. The
arguments of a function are enclosed within parentheses. There are no
arguments for these functions, so we simply have the parentheses.
In the protected part of the class definition, we have the declaration of a
member data item:
char contents [12] ;
In this statement, we are declaring a text string to contain the contents of the
message. The keyword char introduces the declaration and defines the type of
data to be held, in this case characters. contents is the programmer-chosen
identifier for that part of memory where the string will be stored. [12] is the
maximum length of the string in characters. This includes an allowance of one
character to hold a special character to mark the end of the string. This is
necessary because text strings in C++ may vary in length up to the specified
maximum.
In lines 14 to 17 of the program we have the definition for the first of two
member functions.
void message: : initialise ()
{
strcpy (contents I "Hello World")
}
The first line of the function is its heading. This consists of the same three
parts as the associated prototype already described above. However, there are
 A First Program 25

two differences. The programmer-chosen name initialise is preceded by

the object class identifier message followed by the scope resolution operator
: : . The technical details for this need not concern us at the moment; briefly, it
is needed so that the data defined in the class definition can be accessed within
the function. Notice also that there is no semicolon at the end of the function
heading, nor at the end after the closing brace.
The details of the function are enclosed within braces, we have just one
line that instructs the computer to make a copy of the text Hello World and
store that copy in the identifier contents. This line starts with strcpy
which is the name of a C++ function that does this. The words contents and
"Hello World" are called the arguments of the function strcpy and as
such are placed in parentheses after the function name. Note that arguments of
functions are separated by commas.
Lines 19 to 22 of the program contain the definition of the second
function.
void message: : display ()
{
cout « contents « end!

As with the previous function, the first line is the heading. Again, this
corresponds to the associated prototype with the inclusion of message: :.
Within the braces we have just one line that instructs the computer to
direct output to the monitor screen. This line starts with cou t, the name of an
object that has functions to achieve this. The output to be directed to the
monitor screen is specified by following cout with the operator « and a
definition of the output required. In this case we have two output definitions to
be handled by couto The first is the identifier contents; this indicates to
cou t that the string stored in this identifier is to be displayed on the monitor
screen. The second output definition is end! (an abbreviation for end of line);
this simply indicates to cou t that the current line must end and the screen
cursor is to be placed at the start of the next line.
Line 24 of our program is one that all of our programs will include (or one
very similar) to show where program execution begins.
void main ()
The parentheses indicate to the compiler that main is a function with no
arguments. The body of the main function is enclosed by braces (lines 25 and
29).
Line 26 is a declaration of the object hello as an instance of the class
message.
message hello ;
In effect, it makes a copy of all the members of message and gives them the
group identifier hello. This means that hello can be referred to within the
26 Object Oriented Programming Using C++

function main and that all the public parts of its class definition may be used.
We see this in the next two statements of the function (in lines 27 and 28).
hello. initialise () ;
The member function initialise for the object hello is called; this
means that the statement(s) within the function definition for initialise
are executed. Note the format, instance identifier then a full-stop (known as the
dot operator) then the member function identifier then the parentheses then a
semicolon. The result of the function being called will be that hello's copy of
contents will be given the value "Hello World". To see the way that this
is done, please refer again to the description of the function definition for
ini tialise of class message.
Finally, the display member function for the instance hello is called.
hello. display () ;
The result of this will be that the text stored in contents (that is, Hello
World) will be displayed on the monitor screen and the cursor placed at the
start of the next line. Again, to see the way that this is done, please refer to the
description of the function definition for display of class message.
Notice that the functions ini tialise and display were declared as
public because they are being used in the function main, which is outside
the definition of the object class. The string identifier contents was declared
as protected since it is only used within the definition of a member function
of the object class message.

3.3 Coding style

The layout of the program is of little concern to the compiler. Generally, spaces
are not significant. The use of spaces, comments and blank lines is left to the
discretion of the programmer. So, it is possible to produce a program that is
readily understood by the compiler but is not so easily read by the human
reader. You are encouraged to use a layout and style that ensure that your
programs are easy to follow and read.
The identifiers created by the programmer ate a matter of choice, but give
an opportunity to describe the data that is to be contained within them. Again,
you are encouraged to always use meaningful identifiers. Normally, an
identifier will not exceed 30 characters in length. It must start with either a
letter or the underscore character C) and its remaining characters may be
letters, digits or underscore characters.
Notice that the case used to write C++ is significant; for example,
strcpy is not the same as STRCPY. In our first program, we declared an
instance of message as hello, we could not then refer to it in the main
program by Hello.
Certain items of punctuation are mandatory parts of the C++ language. In
 A First Program 27

our first program you will notice that declarations and statements end with a
semicolon. Also note that in lists, such as in the list of arguments of a function,
a comma is used to separate components.
C++ contains several keywords such as void, each of which has a
specific purpose. These keywords must be surrounded by one or more blank
characters and they must not be used as identifiers. The full list of C++
keywords is given in appendix C.

3.4 Pseudo-code for a sequence

As mentioned in section 1.7, a sequence using pseudo-code notation consists of
a number of statements to be executed presented in the order of execution.
Unless the components of a sequence are themselves controlling statements, the
statements will be in plain language with no formal syntax. However, we will
find that certain phrases tend to be used for like operations.
An example of a sequence using pseudo-code is given in figure 3.3. Here,
we show the basic actions of the function main from figure 3.2.

main
Declare object hello of type message
Call hello. initialise
Call hello.display

Figure 3.3

The first line identifies the function name. The next three are a sequence
of the actions to be performed in the order given.
A slightly more complex version of the function display could be described
in pseudo-code as in figure 3.4.

message: : display
Display screen headings
Display contents of message
Display screen footings

Figure 3.4

Here, the first line identifies the class and the function name. This is
followed by a sequence of three actions. Note that they are simply general
descriptions of the activities without relying on a formal syntax. The precise
details of what to display and where to display the data on the computer screen
would obviously need to be specified and implemented in the C++ code.
However, the generalisation 'display ... ' will suffice at the design stage.
28 Object Oriented Programming Using C++

3.5 Exercises
3.5.1 Please refer to the example in figure 3.2, then answer the following
questions:
(a) What is the purpose of lines I and 2? Ifthey were removed, what
effect would this have on the running of the program?
(b) Lines 3 and 4 permit the use of what C++ features?
(c) What do we call the program statements in lines 8 and 9? What do
we call the three component parts of each statement (excluding the
terminating semicolons)?
(d) What three things can you say about the data member declaration
in line 11?
(e) What are the differences between the function prototype in line 8
and the corresponding function heading in line 14.
(f) What does the member function ini tialise do?
(g) What does the member function display do?
(h) What is the point of line 24 (that is, void main ( ) )?
(i) What does the declaration in line 26 do?
(j) The member functions are called in lines 27 and 28. Describe each
of the four components of the statements (excluding the
terminating semicolon).
(k) What happens when a function is called?
(I) Name the five identifiers that are declared and then used in this
example? What are the C++ rules for making up identifiers?
(m) Why are the functions ini tialise and display declared as
public?
3.5.2 Make changes as necessary to the example in figure 3.2 to achieve the
following revised specification.
Allow for two messages to be displayed, the first should be
Hello all computer users
and the second
What a fine day!
You should implement this by making the first two lines more
appropriate, by replacing the member data declaration in the class
definition by two similar statements, and by replacing the single
statement in both of the member functions by two similar statements.
3.5.3 Please refer to section 3.4, then answer the following questions:
(a) What will the first line of the pseudo-code for a function normally
contain?
(b) Give an example of a pseudo-code statement indicating that a
function is to be used.
(c) Rewrite the pseudo-code for the display function so that the
actions are performed in the reverse order.
4 An Introduction to Inheritance

Objectives for this chapter

Familiarity with the C++ programming terms and concepts:
• the member function cin. qet
• the data type char for a single character
• program files and header files
• use of a prompt for keyboard input
• deriving a new object class from an existing (base) class
• using header files and a derived class
• inheriting object class members.
Ability to:
• understand a simple C++ program that uses a header file
• understand a simple C++ program that uses a derived object class
• write pseudo-code for a simple function
• write simple C++ programs based on the examples in the chapter.

4.1 Using a header file

Our first program in chapter 3 would normally be typed into a single computer
file and presented to the compiler for translation and execution to produce the
required results. However, we could separate the object class definition and
member function definitions from the function main. Let us say that we put the
defintions in a file called messaqe. h and the function main in the file called
hello_m.cpp. The file messaqe.h is known as a header file and its
contents are shown in figure 4.1. The contents of the program file,
hello_ m. cpp, are shown in figure 4.2.
In figure 4.2 we have the same main function as in figure 3.2 (in chapter
3), preceded by the #include statement referencing the header file. When we
present the program file to the compiler, as part of the translation process the
code from the header file, in effect, replaces the #include statement, in the
sense that the compiler now regards the program file as being exactly the same
as the first program in figure 3.2.
Note that in chapter 3 and figure 4.1 the previous #include statements

29
30 Object Oriented Programming Using C++

II MESSAGE.H
II The object class message
#include <iostream.h>
#include <string.h>
class message
{
public :
void initialise ()
void display ()
protected :
char contents [12]

void message::initialise ()

strcpy (contents I "Hello World")

}

void message: : display ( )

cout « contents « end!

Figure 4.1

II HELLO M.CPP
II A program to display the Hello World message
#include "message.h"
void main ()
{
message hello
hello.initialise ()
hello. display ()
}

Figure 4.2

reference facilities held in a compiler library and are identified by a name

enclosed in angle brackets <>; we now reference the message. h file and
enclose this name with ", to indicate that it is a file stored in the same directory
as the program file.
 An Introduction to Inheritance 31

4.2 Inheriting code from onr first program into a second program
The statements in message. h can be reused in other programs that require
the object class message or derivatives based on it. For example, if we wished
to have an additional program that accepted any message from the keyboard
and then displayed it on the monitor screen, we have a similar model to that
described in figure 3. I, but need a different initialisation function. Instead of
simply assigning a value of "Hello World" to the contents of the
message, we need code to accept a string of characters into contents.
We could simply make a copy of message. h, call it a different name
and make modifications to the copy. However, there is a better solution to this
type of problem that avoids duplicating the code; rather it involves inheriting
the code from message. h by defining a new object class based on message,
but with a new member function ini tialise. Hence there is no code dupli-
cation, simply a replacement for that part which has different requirements.
The model of the new class any_message (the derived class) and its
derivation from the original class message (the base class) is represented by
the object schema shown in figure 4.3.

Class : message Derived class: any_message

contents (of message) .»-

Initialise contents Initialise contents
Display contents ~ _i.:.p_ll~:lill:"
V _ _ _ _·_ ..
:.·.:~;i(;_
i !:il _
Figure 4.3

As mentioned in chapter 2, notice how the arrows and shading indicate

those members of the derived class that have been inherited from the base class
without being changed; the lack of shading in the derived class indicates those
members that have been added or, in this case, redefined.
We implement this additional program by writing C++ code for a new
header file messagel. h and a new program file anymess. cpp. They are
shown in figures 4.4 and 4.5 respectively. The pseudo-code for the function
ini tialise is also given in figure 4.6.
Let us first describe the contents of the header file line by line.
II MESSAGE1.H
II The object class any_message
We have described comments before; these identify and reflect the purpose of
the new header file.
32 Object Oriented Programming Using C++

II MESSAGE1.H
II The object class any message
'include "message.h"
class any_message : public message
{
public :
void initialise ()

void any_message::initialise ()

char terminator ;
cout « "Enter message: "
cin.get (contents, 12)
cin.get (terminator) ;
}

Figure 4.4

II ANYMESS.CPP
II A program to display any message
'include "message1.h"
void main ()
{
any message do_message ;
do_message. initialise ()
do_message. display () ;
}

Figure 4.5

any_message::initialise
Declare terminator variable
Prompt for message
Accept message contents
Skip newline character

Figure 4.6

Line 3 is also familiar.

'include "message.h"
This statement is a directive to the compiler to take into account (or "include")
all the code found in the file message. h.
In lines 4 to 8, we define a new object class based on message as
 An Introduction to Inheritance 33

previously defined in the file messaqe. h.

class any_messaqe : public messaqe
{
public :
void initialise ()
} ;
The first line in this section, introduced by the keyword class, specifies the
new object class, called any_messaqe, derived from the object class
messaqe with all of its facilities made public in the new class. Note the
colon after the new class identifier and before the derivation type public.
The new object class inherits all of the public and protected components of
the class upon which it is based. So we inherit the member data contents
and two member functions called initialise and display in our new
object class. However, we need to redefine the initialisation function, so we
declare a public member function ini tialise as part of any_messaqe;
as before, this is enclosed in braces.
In lines 10 to 16, we have the definition of the new member function
ini tialise.
void any_messaqe::initialise ()
{
char terminator ;
cout « "Enter messaqe: "
cin.qet (contents, 12)
cin.qet (terminator) ;
}

After the heading, we have four statements enclosed in braces as usual. The
first statement is a data declaration for a single character (indicated by the
keyword char). The function will refer to this area of data by the identifier
terminator. The second statement will display text on the monitor screen
inviting the user to type a message; this text is called a prompt. We have
already described the use of cou t to display data on the screen, in this case we
do not use end! because we want to keep the cursor on the same line. The
third statement will obtain the message from the keyboard. cin. qet is a
mechanism by which we can obtain, in this case, up to 11 characters from the
keyboard and store them in contents (with the end of string character being
automatically appended). Formally, qet is a member function of the object
cin provided by the compiler in iostream. h. The first argument of qet is
the identifier of an area to receive the data (con ten ts), the second is the
maximum length of the data (12) including the automatically appended end of
string character. It is assumed that after the data has been entered the user
presses the enter key. A side-effect of this is that the character generated when
the user presses enter (we will call it the newline character) is not transferred to
Other documents randomly have
different content
 ßrandner — Braun 57 Brandner, Johann. — Mittenwald.
Geb. 1835, t 1916 Ein braver Gelgenmacher, der selbständig wenig
hervorgetreten ist, aber seines unversieglichen Humors halber sehr
beliebt war, und der als Hochzeitlader und Brautführer bei allen
Familienfesten seines Ortes eine gewichtige Rolle spielte. Brandner,
Kaspar. — Mittenwald. Geb. 18. Nov. 1883 in Mittenwald Schüler der
Mittenwalder Geigenbauschule unter Franz Baader. Als Gehilfe
arbeitete er zwei Jahre lang bei G. Kriner in Landshut und drei Jahre
in München bei Gius. Fiorini, Zunterer und zuletzt bei Sim. Rieger,
nachdem er vorher m seinem Heimatsort noch das Lauten- und
Gitarrenmachen erlernt hatte. Im Jahre 1904 machte er sich
selbständig, baut nach Stradivari und Guarnen gute Konzertgeigen
und nach italienischen und Wiener Modellen Lauten und Gitarren. Er
ist auch in der Wiederherstellung aller Saiteninstrumente geschickt
und wurde 1896 auf der Nürnberger Ausstellung für seine Geigen
prämiiert. Geigenzettel : Kaspar Brandner / Instrumentenmacher und
Reparateur / Mittenwald Nr. 125 (Bayern) [Rechts und links Medaille
Prämiiert Nürnberg 1906]. w len. Geb. um 1757. Brandstätter, Ignaz.
t 10. März 1791 Da er nur ein Alter von 34 Jahren erreicht hat,
dürfte es nur wenige Geigen von ihm geben. Er scheint übrigens
hauptsächlich Gitarren gemacht zu haben, die aber nur von
mittelmäßiger Arbeit sind. Boden und Zargen zeigen denselben
schwarzbraunen Lack, der zu seiner Zeit in Wien beliebt war.
Geigenzettel : Abb. 46. Brandstätter, Matthäus Ignaz. — Wien. Geb.
um 1791, t 6. März 1851 Er wohnte Stadt Nr. 994 und legte am 3.
Oktober 1817 als Lautenmacher den Bürgereid ab. Er baute sehr
sauber gearbeitete Violinen nach Stradivari und verwendete einen
gelben Lack mit rötlicher Schattierung. Leider ist der Ton seiner
Geigen nicht so schön wie ihr Aussehen. Er war sehr fleißig, soll aber
in den letzten Lebensjahren nicht zu bewegen gewesen sein, eine
seiner neuen Geigen zu verkaufen. Nach seinem Tode fanden sich in
seiner Werkstatt mehrere Schubladen voll Violinen, die bis zum
Lackieren fertig waren. Anton Hoffmann kaufte den ganzen Nachlaß,
machte die Geigen fertig, versah sie mit Brandstätters Zettel und
brachte sie in den Handel. Diese nachgelassenen Geigen sind leicht
an ihrem minderwertigen Lack zu erkennen und nur halb so viel wert
als diejenigen, die er selbst noch fertig gemacht hat und die jetzt
recht gut bezahlt werden. Er stand als Reparateur in großem
Ansehen. Ein Reparaturzettel von ihm in Brüssel (Mus. d. Cons. Nr.
258), ein ebensolcher in einer theorbierten Laute von Pradter, die
sich in der Sammlung alter Musikinstrumente in Wien, Burgring 5,
befindet. Ein Johann Brandstätter, der von 1840 bis 1855 in Wien
gelebt haben soll, hat nicht existiert. Geigenzettel : Mathäus
Brandstätter in Viennae / reparavit Anno 1817 (gedruckt) und Abb.
47. Branzo, Francesco Barbaro. — Padua. 1 620. 1 660 Das Wort
»Barbaro« dürfte die Heimat dieses Meisters andeuten. Ein
Calascione (beliebtes neap. Volksinstrument) in der staatl.
Sammlung alter Musikinstrumente in Berlin, Nr. 723 (von 1620),
S.Abbildung Bd. I Seite 54. Bei Vidal wird nur der Name mit der
Jahreszahl 1660 erwähnt. Erscheint also nur die aus diesem Jahre
stammende Gamba von ihm in der Sammlung Correr gekannt zu
haben. Valdnghi nennt ihn BronzoBarbaro (3693). Brater s. Pradter
Bratti, Cesare. — Florenz. 1882 Er soll nicht ungeschickt gewesen
sein ; da er aber in seine Geigen gerne fremde Zettel geklebt hat,
findet man seinen Namen sehr selten. Braun, Adam. —
(Mark-)Neukirchen. 1697 Sein Name wird als der eines Stiefsohnes
und Schülers von Komelius Kretzschmar überliefert. Da er keines
Meisters Sohn war und die vorgeschriebene Wanderzeit nicht erledigt
hatte, wurde er erst auf ein an den Landesherrn gerichtetes
Gnadengesuch hin am 17. Okt. 1697 als Meister in die Zunft
aufgenommen. Er ist wahrscheinlich der Ahnherr der noch
bestehenden Familie, seine Söhne und Enkel scheinen jedoch nicht
Geigenmacher gewesen zu sein. Braun, Anton. — Budapest,
Szegedin, Belgrad. Geb. 1847, t 5. Okt. 1901 Schüler von Placht in
Wien und Ferd. Jos. Homolka in Kuttenberg. Er hielt sich nur kurze
Zeit in Budapest auf, ging dann nach Szegedin und ließ sich um 1887
in Belgrad nieder, wo er Königl. Serbischer Hofinstrumentenmacher
wurde. Er war auch ein tüchtiger Musiker und wahrscheinlich der
Vater von Johann und Michael Braun. Geigenzettel : Antonius Braun
/ fecit Beigradi 1890 (gedruckt). — Reparavit / Ant. Braun Beigradi /
1882 (gedruckt). Braun, August Hermann. — Markneukirchen. Geb.
11. Dez. 1868 Schüler von Karl Wilhelm Keßler, bei dem er seit 1882
lernte. Als Gehilfe arbeitete er bei verschiedenen Meistern und
machte sich 1892 selbständig. Im Jahre 1896 trat er bei der Firma
Karl Gottlob Schuster ein und gründete deren Werkstatt für
Kunstgeigenbau, die er durch 22 Jahre leitete. Im Jahre 1918
richtete er seine eigene Werkstatt ein und baut sehr sorgfältig
ausgeführte Violinen und Violoncelli nach italienischen und Tiroler
Meistern, die sich sehr schnell Eingang in Künstlerkreisen
verschafften. Er verwendet einen guten ätherischen Ollack.
Besonders wird auch seine Geschicklichkeit im Wiederherstellen alter
Meistergeigen gelobt. Geigenzettel: Gebaut im Jahre 19 . . / von
Aug. Hermann Braun / Lauten- und Geigenbaumeister /
Markneukirchen i.'S. No. 855.
 58 B raun -B renner Braun, August Robert. — Erlbach. 19.
Jahrh. Er soll nach Spremberg gezogen sein, war aber dort nicht zu
ermitteln. Braun, August Wilhelm. — Markneukirchen. Geb. in
Erlbach 1819, f 30. Okt. 1869, 50 Jahre 23 Tage alt Ließ sich anfangs
der fünfziger Jahre in Markneukirchen als Geigenmacher nieder und
baute billige Geigen für den Ausfuhrhandel. Braun, Ernst Moritz. —
Markneukirchen. Geb. in Erlbach 27. Dez. 1848 Sohn von Aug. Wilh.
Braun. Geigenmacher der Gegenwart. Braun, Gustav. — Düsseldorf,
Dresden, Lübeck. Geb. in Erlbach 7. Febr. 1 846, f Ostern 1896 in
Lübeck Sohn von Aug. Wilh. Braun. Er war ursprünglich Bratschist;
da er jedoch Geigenmacherssohn war, interessierte er sich für den
Geigenbau, und als er in Hannover Gelegenheit gehabt hatte, bei
einem Geigenmacher Unterricht zu nehmen, begann er bald darauf
in Düsseldorf, in seiner freien Zeit Geigen zu reparieren. 1872
siedelte er nach Dresden über und 1895 nach Lübeck. Er besaß
theoretische Kenntnisse und beschäftigte auch zeitweise Gehilfen.
Die von diesen angefertigten Geigen tragen seinen Zettel.
Geigenzettel : Repariert von Gustav Braun / Düsseldorf 1869
(gedruckt). Gustav Braun /Dresden 18 . . (geschr.). Braun, Johann.
— Szegedin. Geb. in Nagy SzentMiklos 1860 Als C.W.Richters
Nachfolger ließ er sich 1883 in Szegedin als Geigenmacher und
Optiker nieder. Er soll bei Ig. Lutz in Wien gearbeitet haben und
unterhält eine Werkstatt. Auf der Szegediner und Torontäler
Gewerbeausstellung sowie auf der Budapester
Millenniumsausstellung erhielt er Medaillen. Geigenzettel: Joannes
Braun fecit / Szegedini 1895 (gedruckt). Braun, Joseph. —
Mittenwald. 1914 Er gilt als guter Violoncellomacher, arbeitet aber
auch als Zimmermann. Braun, Michael. — Szegedin, Klausenburg.
1891. 1896 Geschickter Geigenmacher der Gegenwart. Er arbeitet
nach Guarnen und Stradivari, verwendet einen goldrötlichen Lack
und liebt dicke Einlagen. Geigenzettel: Braun Michael / Szegedin 891
(geschr.). Braun, Wilhelm August. — Markneukirchen. Geb. 18. Juni
1855 in Markneukirchen Sohn von Aug. Wilh. Braun. Gelgenmacher
der Gegenwart. Brauner, Johann Josef. — Wien. 1749. 1761 In den
Wiener Steuerbüchern kommt er von 1750 bis 1758 vor. Im letzten
Jahre mit der Bemerkung: »Wegen seiner Abreisung von hier der
Steuer und des Bürgerrechts entlassen worden«. Er wohnte im
Schotten viertel und legte am 4. Juli 1 749 den Bürgereid ab. Er wird
zuletzt erwähnt mit der Bemerkung : »Vermög Verordnung dd° 29.
May 1758 der Bürgerpflicht entlassen und das Bürger Zettel
zurückgegeben worden.« Doch kommen noch Geigen mit der
Jahreszahl 1761 von ihm vor. Auf seinen Zetteln gebraucht er
abwechselnd bald den Taufnamen Johann, bald Josef, selten beide
zusammen. Geigenzettel : Abb. 40. Brauns, Carl Friedr. Wilh. —
Hamburg. 1798 Er wird als »Instrumentenmacher« am 12. Okt. 1798
Bürger von Hamburg, ist aber sonst nicht bekannt. B reazzano s Bri
riazzano Breckinridge, John. — Glasgow. Geb. 1790 in Parkhead bei
Glasgow, f 1840 in Glasgow Er war von Hause aus Weber und besaß
später einen Krämerladen ; dabei machte er fleißig Geigen, die recht
gut nach Amati gebaut sind. Sein (Splritus-)Lack ist gelb oder
dunkelbraun. Der Ton ist angenehm, aber nicht groß. Geigenzettel:
John Breckinridge Maker Parkhead 1834 (geschrieben). Breiling,
Andreas Ludolph (Ludwig). — Göttingen. 1801. 1829 Er wurde am
21. September 1801 zum Bürger angenommen, aber erst am 29.
April 1829 als solcher vereidigt. Da ihm dabei die Gebühren erlassen
wurden, kann man annehmen, daß er in beschränkten Verhältnissen
lebte. Trotzdem war er ein sehr geschickter Lautenmacher, der
ebenso originell als sauber arbeitete. Eine Laute von ihm aus dem
Jahre 1803 trug die Nr. 132. Geigenzettel: A. L. Breiling in Göttingen
,' fecit 1802 No. 121 (?) (geschrieten). Breitenberger, Ludwig, lebt
als Instrumentenmacher in München Bremitz, Giuseppe. — Tnest.
1895 Unbedeutender Geigenmacher aus den letzten Jahren des 19.
Jahrhunderts, der wohl nur von Fabriken hergestellte Schachteln
verarbeitete. Brenner, C. — Gefle. 1804 Man kennt einige
Reparaturen von ihm, es ist aber wahrscheinlich, daß er ein Musiker
war, der nur gelegentlich Ausbesserungen vornahm. Geigenzettel:
Reparerad 1804 C . . . Brenner, Gefle (gedruckt).
 Brensio — Brinckmann 59 Brensio (Brensius, Brinsius),
Antonio. — Bologna. 1592 Vielleicht der Vater oder Sohn von
Girolamo. Eine Lira da Gamba von ihm besitzt W. Heyers
Musikhistonsches MuseuTi in Köln (Nr. 782). Geigenzettel : Antonino
Brensius Bononi (gedruckt). — Antonius Bononiensis (geschrieben).
Brensio, (Girolsmo) Hieronymus. — Bologna 16. Jahrhundert In einer
nicht datierten Viola da Eraccio im Museum des »Liceo filarmonico«
in Bologna findet sich der Name dieses Meisters. Vidal teilt die Maße
des fünfsaitigen Instruments, das für die Geschichte des Geigenbaus
sehr bemerkenswert ist, mit. Geigenzettel : Abb. 89. Brenzoni,
Pietro. — 1902 Italienischer Geigen macher unserer Zeit. Bresa
(Brosa?), Francesco. — Mailand. 1708 Vidal ergänzt den Namen der
Stadt, die auf einem Originalzettel nicht ganz leserlich war, wohl
richtig, wenn er Milano lesen will, wofür auch »alla scala« zu
sprechen scheint. Das zu dem Zettel gehörige Instrument ist
übrigens verschwunden und Werke von F. Bresa sonst nicht bekannt
geworden. Vgl. auch Brossa. De Piccolellis bezeichnet ihn als einen
mittelmäßigen Mailänder Geigenmacher. Geigenzettel : Francesco
Bresa fece alla Scala in Mil . . 1 708 (gedruckt). Bressano, Baptista.
— ? 16. 17. Jahrhundert Eine Pochette im Museum des Liceo
filarmonico in Bologna trägt diesen Namen. Sie ist wahrscheinlich
Brescisner .Arbeit, in welchem Falle das Wort Bressano wohl als
Heimatsbezeichnung angesehen werden muß. Breton, Fran^ois. —
Mirecourt. Geb. in Mirecourtum 1750, f 1830 Seine Arbeit ist zwar
nicht künstlerisch, aber immerhin recht sauber. Er bevorzugte ein
großes Modell und verwandte meist hellgelben Lack. Da er viele
Arbeiter beschäftigte, sind seine Geigen nicht selten ; man muß sich
jedoch trotzdem vorsehen, denn abgesehen davon, daß seine Firma
auf eine Mirecourter Fabrik überging, die noch immer seinen Zettel
m ganz neue Instrumente klebt, ist er auch norh vielfach
nachgeahmt worden. Es geht ihm beinahe so wie der deutschen
Famihe Hopf. Sie erhob sich nicht über handwerksmäßige
Mittelmäßigkeit und wird doch fortwährend von einer urteilslosen
Menge zum Vorbild senommen. — Er verwendete auch den einen
Brandstempel, dessen letzte Zeile häufig fehlt. — .'Xuch als
Bogenmacher hat er sich betätigt. Geigenzettel: Abb. 71 und 79.
Breton, Joseph Fran^ois. 1740. 1815 (?) Paris, Mirecourt. Ein
Mirecourter Meister, der vielleicht wirklich vorübergehend in Paris
ansässig war, obwohl das Fehlen einer näheren Wohnungsangabe zu
Zweifeln m dieser Hinsicht berechtigt. Seine Arbeiten zeichnen sich
nicht aus und werden häufig mit denen von F. Breton verwechselt,
wozu die '\hnlichkeit der Modelle einigen Anlaß gibt. Es ist auch nicht
ganz sicher, welcher Breton den Brandstempel : Breton Luthier ä
Paris benutzte. Eine Violine von ihm befand sich in der Sammlung
Snoeck (Nr. 522). Geigenzettel: J. F. Breton, citharae fabri- ' cator,
faclt , vendit et recon- cinat instrumenta musica omnis / generls.
Parisiis anno 1780 (gedruckt). Gleichlautende Zettel kommen von
1740 — 1780 häufig vor. doch fand sich ein solcher Zettel auch in
einem Violoncello mit der Jahreszahl 1815 vor. Ob er dieses noch
selbst gemacht hat, oder ob der alte Zettel mit neuer Jahreszahl von
einem Werkstattnachfolger gebraucht worden ist, müßte erst
festgestellt werden. Breton s. auch Le Breton Breuling s. Breiling
Briano, Fran>Korrektionsgitarren«. Sehr geschätzt waren seine
übersponnenen Saiten.
 60 Britsen — Brown Britsen, Georgius. — Antwerpen. 1613
Schüler des Bildhauers Melchior Ykens. Er ist freilich nur als
Clavecinmacher bekannt. Auch sein Sohn und sein Enkel gleichen
Taufnamens kommen 1654 — 1659 und 1675 im gleichen Berufe vor,
doch wurde mir von einem Händler vor längerer Zeit eine schön
geschnitzte Theorbe mit dem eingeschnittenen Namen »Britsen«
angeboten, so daß anzunehmen ist, daß auch m dieser Familie die
Lautenmacherei wenigstens nebenbei betrieben wurde, wenn der
Name nicht etwa nur den einstigen Besitzer andeutete. Brizzano (?),
Vincenzo. — Foggla. 1860 Der Name war nicht sicher leserlich, aber
die Geige, die ihn trug, recht gut, ja besser als viele von seinen
italienischen Zeitgenossen. Broberg, Carl Johan. — Gothenburg. 1
769. 1 793 Er war vermutlich ein Schüler von Jacob Hellman in
Engelholm^) und wurde im Jahre 1 769 als Geigen- und
Musikinstrumentenmacher in Gothenburg zugelassen. Er war fleißig
und baute alle Arten von Streich- und Rupfinstrumenten. Er
verwendete geschriebene und gedruckte Zettel und gelegentlich
auch eine Brandmarke. Arbeiten von ihm haben sich im Privatbesitz
mehrfach erhalten. Geigenzettel : Carl Joh. Broberg / Götheborg
Anno 1 774 (gedruckt). Brechet (Broche) s. M. Snoeck Brock, Alfred
Nilsson. — Stockholm. Geb. 15. April 1876 Sohn und Schüler von N.
Nilsson in Malmö. Am 1. Oktober 1900 eröffnete er in Stockholm
seine eigene Werkstatt und ist jetzt dort Geigenmacher der
Königlichen Hof kapelle und des Musikhistorischen Museums.
Brocsko (Brotsko), Karl. — Budapest, f 1858 Schüler von
Teufelsdorter. Seine nach Amati gebauten Geigen sind in ihrer Arbeit,
im Lack und im Ton recht lobenswert. Geigenzettel : Carolus Brotsko
fecit / Pestini 1 85 1 (gedruckt). Brooley, Charles. — London. 1885
Gitarren- und Banjomacher. Bronzo s. Branzo Brookfleld, Edward. —
Southport. 1890. 1900 Er baut nach Guarneri und Stradivari und
verwendet ÖUack von gelber und orangeroter Farbe. Die Firma heißt
jetzt Brookfield & Co. Geigenzettel: Edward Brookfield (geschrieben).
Broomley, Ch. H. — New Haven Amerrkanischer Geigenmacher der
Gegenv.'art. Broquet, lebte Ende des 19. Jahrhunderts In Dunkerque
(Dep. Nord) Broschi (Brocchi), Carlo. — Parma. 1 730. 1 744 Wenig
bekannter Geigenmacher, über den sich nichts ermitteln ließ. Eine
zweifellos echte, vom Wurm stark angegriffene Violine (kleines an
Nie. Amati erinnerndes Modell, hübsche F-Löcher, kleine Schnecke),
trug den Zettel : Carlo Broschi / in Parma fecit 1 732. Ein
gleichnamiger Geigenmacher lebte noch in den zwanziger Jahren des
19. Jahrhunderts. Der Name wird auch Braschi gelesen. ^) Was
Hedvig Boivie, Amanuensis am Nordischen Museum in Stockholm, in
ihrem hübschen Aufsatz über die schwedischen Geigenmacher in der
Mus. Zeitschr. »Fataburen« 1921, S. 64 mit aller Vorsicht sehr
wahrscheinlich macht. Brosig. — Neiße. 1910 Wurde nur als
Reparateur genannt. Brossa (Brosa, Bresa), Francesco. — Mailand.
1700 Eine Violine mit seinem Namen erinnert an die Brescianer
Schule und hat orangeroten Lack. Ich bin geneigt, diesen Francesco
Brossa mit Francesco Bresa zu identifizieren; es wäre nur
festzustellen, welche Form des Namens die richtige ist. Eine Geige
von ihm befindet sich in Freiburg i. B. Geigenzettel: Francesco Bro'-a
fece / dalla Scala in Mano / 1700 (gedruckO. Brouaux. — Bar-le-Duc.
1860. 1890 Beschäftigte sich hauptsächlich mit
Wiederherstellungsarbeiten. Brown, Alexander. — Glasgow. 1855.
1860 Er baute nicht ungeschickt nach Stradivari und verwendete
Spirituslack. Geigenzettel : Alex. Brown Maker, / Glasgow, 1 857
(geschrieben). Brown, Anthony. — London. 1855 Er soll ein Schüler
von Morrison oder Panormo gewesen sein und war besonders als
Gitarrenmacher geschätzt. Er wohnte um 1855 in der Rosamond st.,
Clerkenwell. Brown, James (sen). — London. Geb. vor 1759, t vor
1834 Er war ursprünglich Seidenweber und erlernte erst im Jahre
1804 bei Thomas Kennedy den Geigenbau, eröffnete dann in der
Wheeler st. ,Spitalfields' seine eigene Werkstatt als Geigenmacher
und Reparateur und betätigte sich als geschickter Meister. Brown,
James (jun.). — London. Geb. im Nov. 1786, t 1860 Sohn und
Schüler von James B. sen. Ursprünglich sollte er nur Bogen macher
werden und erlangte darin eine besondere GeschicklicKkeit. Nach
dem Tode seines Vaters verlegte er sich dann mehr auf den
Geigenbau und leistete auch darin Beachtenswertes. Auch sein Sohn
war zum Geigenmacher bestimmt.
 Brown — Brusere 61 Brown, John. — Melbourne. 1880 Ein
australischer Geigenmacher der Gegenwart, der auf der Melboumer
Ausstellung den dritten Preis erhielt. Brown, W. J. — Melbourne
Erhielt 1880 einen Ausstellungspreis für vorzügliche Reparaturen. Die
Firma heißt jetzt W. J. Brown & Son. Browne (Brown), John. —
London (Cornhill). 1680. 1743 Er führte die Hausmarke *at the Black
lyon«. Das Selhofsche Auktionsverzeichnis weist eine Viola da
Braccio von ihm auf. Seine Violinen gehen auf ein Amatimodell
zurück, erinnern aber auch an Stainer. Brubac, Antoine. — Rouen.
Geb. in Mirecourt 22. Jan. 1847, f in Rouen 1894 Ein tüchtiger
Meister und verdienstvoller Leiter der bekannten A. Kleinschen
Geigenbauwerkstatt. Seine Geigen tragen den Namen der Firma
Klein. Brubac, Charles. — Paris. Geb. in Mirecourt 21. Mai 1853
Bruder von Antoine B. Er arbeitet seit 1877 bei Gand & Bernardel
(jetzt Caressa & Franjais) und erhielt 1897 in Brüssel eine goldene
Mitarbeitermedaille. Brücken-Hammig, Christian August. —
Markneuklrchen. Geb. 14. Okt. 1833, f 19. Dez. 1885 Er selbst war
hauptsächlich Baßmacher, aber er beschäftigte in seiner Werkstatt
viele Geigenmacher, hielt auf saubere Arbeit und besaß viele
Ausstellungspreise. Brücken-Hammig jun., Max. — Markneukirchen
1897 Streichinstrumentenmacher der Gegenwart, von dem ein 1897
ausgestelltes Quartett nach Stradivari Beifall verdiente. Brückner,
Ernst Max. — Geb. 30. Mai 1875 Geigenmacher der Gegenwart.
Markneukirchen. Brückner, Ernst Richard. — Markneukirchen. Geb. 5.
Nov. 1867 Geigenmacher der Gegenwart. Brückner, Ferdinand
(Nändor). — Budapest. 1874. 1900. Geb. 1848 Schüler von Mönnig.
Im Jahre 1874 begründete er in Budapest sein Geschäft, in welchem
er stets eine Reihe von Gehilfen beschäftigt hat. Unter seinen
Streichinstrumenten werden besonders seine Bässe gelobt; auch
fertigt er gute Schlaginstrumente (Cymbal) an' Als Gehilfe arbeitete
er vor 1874 bei J. W. Schunda. Geigenzettel : Brückner Nändor ,'
hangszer keszitö / Budapest , Raktar: Magyar utcza 4. sz.
(gedruckt). Brückner, Franz. — Berlin, New York. 1879. 1892 Er ließ
sich zuerst in Berlin nieder und ging im Anfeing der neunziger Jahre
nach New York. Brückner, Heinrich Albin. — Markneukirchen. Geb. 2.
März 1855 Geschickter Geigenmacher der Gegenwart, der auch als
Lehrmeister erfolgreich gewirkt hat. Mark neuBrückner, Heinrich
August, kirchen. Geb. 6. Sept. 1856 Geigenmacher der Gegenwart.
Brückner, Richard. — London. 1886. 1906 Bruder von Franz Br. ; er
hat eine Zeitlang in Berlin gearbeitet und ist dann nach London
übergesiedelt, wo er namentlich als Reparateur geschätzt wird. Der
Ton seiner Geigen findet Anerkennung. Geigenzettel : repaired at R.
Brückner / London Septbr. 1892 (gedruckt). Brückner, W. — Erfurt.
1900 Wurde mir nur durch seinen Zettel bekannt. Geigenzettel:
W.Brückner, Geigenbauer / Erfurt. / Instrumenten- und
Saitenhandlung / 1 900 (gedruckt). Bruders, Johann August Christof.
— Tangermünde. 1829 Er soll bei A. Zabel gelernt haben. In den
Akten wird er als Instrumentenmacher bezeichnet. Brugere, Charles
-Georges. — Paris. Geb. 10. Nov. 1865 in Mirecourt Sohn von
Charles Joseph Br. und Schüler von Etienne Drouin m Mirecourt. Er
arbeitete als Gehilfe bei Blanchard in Lyon, bei P. Bailly und bei Gand
& Bernardel und übernahm am 22. Sept. 1892 die alte Werkstatt der
Familie Henry in der Rue St. Martin. Er arbeitet ungemein sorgfältig,
so daß er in jedem Monat nur eine Geige fertig bekommt, die er
nach Stradivari baut und mit einem gelben bis goldroten Lack
versieht. Nur in die Geigen, die er vollkommen allein fertigmacht, ■
klebt er seinen Zettel. Er besitzt bereits mehrere silberne Medaillen
und eine goldene (Lüttich 1 905) und war auch 1900 auf der Pariser
.Ausstellung gut vertreten. Eine Verbesserung der Klangfarbe des
Kontrabasses ist ihm durch Änderungen in der Bauart recht wohl
gelungen. Geigenzettel: Abb. 51. 65, 94. Brugere, Charles-Joseph.
1842, t 1876 Mirecourt. Geb. Nur als geschickter Gitarrenmacher
hervorgetreten. Seine Arbeiten tragen seinen Namen als
Brandmarke.
 62 Brugere — Bubenik Brugere, Charles -Malakof f. —
Marseille. Geb. 1857, f 1894 In Mirecourt Ältester Sohn von Fran
 Bucharin — Buchstetter 63 Bucharin, Iwanowitsch. —
Kasan. 1914 Sohn des geschickten Holzschnitzers Iwan
Dimitrowitsch B., der sich schon mit der Ausbesserung alter
Musikinstrumente beschäftigt hatte. So war er frühe auf den
Geigenbau hingewiesen und hat es darin zu einer bei seinen
Landsleuten sehr gerühmten Geschicklichkeit gebracht. Er arbeitet
sehr sauber nach Amati und Stradivarl und verwendet einen guten,
dunkelgelben Ollack. Buchenberg (Buckenberg), Mattheus. 1592.
1619 Rom. Der Name kommt in allerlei entstellten Formen vor:
Bückenburg, Buechtenberg und italienisch sogar Matteo Boccaber. Er
selbst schrieb sich Bucchenberg; in Urkunden heißt er manchmal
auch Bucherberg (1606). Er war deutscher Abkunft und ein
berühmter Lautenmacher. Baron schreibt von ihm: »Man hat die
vortrefflichsten Theorben von ihm, die nur zu finden seyn. e. g. Oval
rund, von einer sehr proportionierlichen Größe, und von einem sehr
delikaten, durchdrmgenden metallenen Ton. Wer das Glück hat, von
diesem besonderen und vortrefflichen Meister etwas zu besitzen, der
kann nur solches als ein wahres Kleinod von Instrumenten aufheben.
Das Dach oder die Decke ist insgemein mit drey Sternen nach
römischer .\rt geziehret, damit sie den Ton gut auswerf fen können.«
— (Vgl. auch V. d. Straeten, B. VI, S. 516. 517.) Im Jahre 1592
heiratete er Virginia, die Tochter des Lautenmachers Pietro de
Albertis. Eine Theorbe von ihm aus dem Jahre 1608 besitzt .Mfr. Keil
in Lissabon, ein Chitarrone von 1614 das Victoria- and Albert-
Museum in London. Bucher, Ignaz Johann (I). — Wien. Geb. in Wien
1828, t ll.Juh 1881 Schüler seines Vaters Johann B., dessen Geschäft
er 1856 übernahm. Er war ein sehr tüchtiger Geigenmacher, der u.
a. für ein nach Stradivari gebautes Quartett, dessen guter und
starker Ton auffiel, im Jahre 1873 die Verdienstmedaille erhielt. Er
baute auch verschiedene andere Saiteninstrumente, von denen
namentlich seine Gitarren sehr beliebt waren. Als in den sechziger
Jahren die Zither populär wurde, verlegte er sich ganz auf den Bau
dieses Instruments und brachte es darin bald zu großem Rufe.
Geigenzettel : Abb. 48. Bucher, Ignaz Joh. (II). — Wien VII. Geb. In
Wien 1859 Schüler seines Vaters Ign. Joh. B. I, dessen Geschäft er
1881 übernahm. Er arbeitete eine Zeitlang als Gehilfe in
Markneukirchen und setzt jetzt die Traditionen des ererbten
Geschäftes, das neun Medaillen besitzt, in würdiger Weise fort. Er
baut seine Geigen meist nach Stradivari, die übrigen Instrumente
(Zithern, Gitarren usw ) n-ich eigenen Modellen und verwendet
Spintusund Öllack. Mit dem Geschäfte ist jetzt auch eine Saitenfabrik
und eine Musikalienhandlung verbunden. Gcigenzettel: Ig. Joh.
Bucher / VII Zollergasse 22 ,' Wien (gedruckt). Bucher, Johann. —
Wien. Geb. 1792 zu Hammerschwang in Württemberg, f in Wien
1856 Er kam als Knabe nach Wien zu J. G. Stauffer in die Lehre,
gründete bereits 1816 sein eigenes, heute noch blühendes Geschäft
und brachte es bald zu Ansehen, sodaß er schon in den dreißiger
Jahren in Schuberths Lexikon unter den hervcrragerden neueren
Geigenmachern aufgeführt wird. Hauptsächlich verlegte ersieh auf
den Bau von Gitarren, die er nach Legnani, Stauffer u. a. baute und
in großer Zahl auch an die Wiener Händler verkaufte. Geigenzettel :
(Schwebender, Gitarre spielender Engel ) Johann Bucher
Guitarremacher in der Stadt. Schultergasse am Judenplatz N° 403 ,
in Wien (Abb. 70). Bucher. Michael. - Halle (Hall?). 1729 Eine Arbeit
von ihm besitzt das Museum in Darmstadt (Nr. 499). Buchner Eine
Geigenmacherfamilie, von der gegenwärtig selbständig tätig sind :
Anton B., Emanuel B. und Wenzel B. in Schönbach und Josef B. in
Steingrub. Der Klaviermacher Carl Conr. B. (geb. 1778) in
Sondershausen gehört einer anderen Familie an. Buchstetter,
Christoff Andre. — Stadtamhof. 1741 Wahrscheinlich der Vater von
Gabriel David B. Er arbeitete nach G. da Salö und nennt sich
»Bürger, Landen und Geigenmacher«. Buchstetter, Gabriel David. —
Stadtamhof bei Regensburg. 1752. 1771 Seinerzeit galt er für einen
der besten deutschen Meister, und selbst Spohr spielte auf seinen
Konzerten nur eine »Buchstetter«, bis ihm der Zufall in Münster bei
Kolmar seine »Lupot« in die Hand fallen ließ. Buchstetter war fleißig
und galt für sehr wohlhabend. Seine besten Geigen sind lang und
schmal, haben flache Wölbung und eigenartige F-Löcher, die etwas
an Amati erinnern. Die Arbeit ist gut, stellenweise sogar sehr
sorgfältig; nur in der Wahl des Holzes war er nicht allzu wählerisch
und verarbeitete gern hartjähriges Tannenholz, was den Ton scharf
machte. Weniger gut war ursprünglich sein Lack, der über einer
braunen Beize aufgetragen erscheint. Später verstand er aber ■
einen schönen, feurigen Lack von guten Eigenschaften und gelber
oder gelbroter Farbe herzustellen. Auch seine Schnecken sind oft
schön gestochen. Er machte Geigen und Lauten aller Art, und
Arbeiten von ihm kommen noch ziemlich häufig vor. Eine Chorlaute
besitzt das Germanische Museum in Nürnberg, zwei Violinen das Stift
St. Florian in Obcrösterrelch. Es gibt auch eine Anzahl hochgewölbter
Geigen (mit tiefer, breiter Hohlkehle, kurzen, geschweiften F-
Löchern mit eiförmigen Endpunkten, gutem Lack, aber schlechter
Schnecke), in denen statt Gabriel David nur Gabriel Buchstetter zu
lesen ist. Man hat daher zwei Geigenmacher unterscheiden wollen.
Wahrscheinlich
 64 Buchstetter — Burekart hat er seine billigen Geigen in
den gangbaren deutschen Formen und bessere nach italienischem
Vorbild gemacht. Eine Violine von ihm mit geschriebenem Zettel
besitzt Carl Stoeber in Würzburg. Geigenzette! : Abb. 35 und 83.
Buchstetter, Josef. — Stadtamhof b. Regensburg. 1776 Sohn von
Gabriel David B. und jedenfalls auch dessen Schüler, da er ganz wie
dieser arbeitete ; doch kommen seine Geigen seltener vor.
Geigenzettel: Josephus Buchstetter, Filius Gabrielis / Davidis,
PedepontI prope Ratis- / bonam — Anno 1776 (gedruckt). Buchta,
Johann. — Brunn. 1776. 1841. Geb. bei Ingrowitz in Mähren um
1755, f 1841 Außer Lauten und Gitarren soll er auch Harfen gemacht
und sich schließlich auf den Klavierbau verlegt haben. Er war seit
1776 Mitglied der Tischlerzunft und wurde 1803 Bürger. Der im Jahre
1838 als Bürger vorkommende Instrumentenmacher Wilhelm B.
dürfte sein Sohn, und der 1888 verstorbene Klaviermacher Rudolf B.
sein Enkel gewesen sem. Buckman, Geo. H. — Dover. 1899. Geb. 23.
Okt. 1845 Ein Beamter und guter Geiger, der, durch Ottos und
Heron-Allens Schriften angeregt, sich dem Geigenbau zuwendete
und am besten nach dem Modell von Stradivaris »Le Messie«
arbeitete. Seine Geigen zeigen gutes, altes Holz, sorgfältige Arbeit
und sind mit »Whitelaws Cremona-Bernstein-Öllack« in
verschiedenen Farben lackiert. Seine Biographie veröffentlichte
Meredith-Morris in »The Strad
 Burckholtzer — Buti 65 Burckholtzer (Burgkholzer) s.
Purkholtzer Burghardt s. Bourgard Burkhardt, Emil. — Elsenach.
Geb. 1871 zu Annaberg im Erzgeb. Er lernte bei Meisel in Klingenthal
und arbeitete 1888 als Gehilfe bei Ernst Gläsel in Markneukirchen ;
von da ging er 1890 nach Dresden zu Hammig, 1892 zu Beyer nach
Erfurt und 1895 nach Kötzschenbroda bei Dresden, wo er sich am 1 .
Juni selbständig machte. Er erfand ein Universalstreich- und
Rupfinstrument, zu dessen fabrikmäßiger Herstellung er sich mit
einem Kaufmann in Schleusingen verband. Seit 1898 widmete er sich
wieder ausschließlich dem Geigenbau und siedelte 1901 nach
Eisenach über, wo er durch gediegene Arbeit bald allgemeine
Anerkennung fand. Er ist gleich tüchtig im Neubau wie in der
künstlerischen Wiederherstellung alter Geigen. Geigenzettel: Emil
Burkhardt, / Instrumentenmacher u. Reparateur, ' Elsenach, anno
190 (gedruckt). Burnley, Arnold. — 1871 Ein englischer
Geigenmacher, dessen OUack gelobt wird. Burzenski, Kasimir. —
Uscie-Solne. 1796 In der Wiener Musik- und Theaterausstellung
waren Arbeiten von ihm ausgestellt. Busan, Domenico. — Vicenza,
Venedig. 1 740. 1780 Die Lesart BusaS ist sein:n Zetteln nach falsch.
Er ist wenig bekannt und soll nach de Plccolellis aus Vicenza
stammen, schloß sich aber der Venezianer Schule an. Hauptsächlich
sind einige gute Bässe von ihm bekannt. Geigenzettel : Dominlcus
Busan / Venetus Fecit / Anno 1746 (gedruckt). — Dominicus Busan /
fecit Venetils 1761 (gedruckt). Busch, Ernst. — Nürnberg. 1612.
1644 Ein fleißiger und geschätzter Lauten- und Violenmacher, der in
den Umrissen eine neue Form anstrebte. Arbeiten von ihm sind in
verschiedenen Sammlungen zu finden. Zwei Gamben von ihm sind in
W. Heyers Musikhistorischem Museum in Köln und ferner eine Violine
von 1644 im Germanischen Museum in Nürnberg. Eine aus der
Sebalduskirche stammende Viola von ihm besitzt der 85 jährige
Nürnberger Musiker Auer seit 65 Jahren. Die Viola ist sehr groß und
hat einen wundervollen Ton. C. Claudius in Kopenhagen hat eine
sehr große Baßgamba mit Bogen von ihm aus dem Jahre 1638 und
eine Diskantviola da Gamba. Gelgenzettel: Ernst Busch, Nürnberg
1617 (gedruckt). — Ernst Busch / in Nürnberg 1 638 (gedruckt). —
Ernst Busch Nürnberg / 1641 (gedruckt). Kontrabaß hier genannt
werden darf. Er hat sich seit langen Jahren mit der Verbesserung des
Kontrabasses beschäftigt, der bekanntlich an dem Mangel leidet, daß
seine Töne nur bis zum Kontra-E hinuntergehen, daß also die
Kontraoktave zu den tiefsten Cellotönen bis C fehlt. Schon 1856
baute er einen C- Kontrabaß, der sich aber nicht praktisch erwies,
well er in Quinten gestimmt war. Um die gewohnte Mensur bestehen
zu lassen und nur die tiefste Saite nach Bedürfnis bis zum Kontra-C
benutzen zu können, ersann Buschmann verschiedene Systeme mit
Anwendung von Wellen, Klappen oder Druckstäben, aber alle wollten
den Ansprüchen an bequeme Spielart nicht genügen. Schließlich
löste er das Problem durch Verwendung eines zweiten Sattels für die
tiefste Saite und von vier Greifern, die durch Druckknöpfe vom Hals
aus in Tätigkeit gesetzt werden. So kann die gewöhnliche Spielart
des Instruments bestehen bleiben und doch nach Belleben die tiefste
Saite nach Dis oder Es, D, Cis oder Des und C zu gestimmt werden.
Damit ist nicht nur die Skala um diese Töne erweitert, sondern der
Klang des Instruments vervollkommnet und die Tonarten, die sonst
ohne Kraft sind, wirken freier. Eine ähnliche Erfindung hat allerdings
Karl Plttrlch in Dresden schon früher gemacht. Bussetto, Giovanni
Maria del. — Cremona, Brescia. 1640. 1681 Er wird stets, u. a. noch
von Valdnghi, in die Zeit von 1540 — 1580 gesetzt und dann der Zeit
nach als einer der ersten Geigenmacher Cremonas erklärt. Auf
echten Zetteln ist jedoch die Zahl 16 bei der Angabe des
Jahrhunderts ganz deutlich; einen solchen Zettel veröffentlicht auch
Grillet. In einer Ahviola der Sammlung Scheurleer mit der
Ortsangabe Brescia wird die Jahreszahl 1 576 gelesen, was offenbar
falsch ist. Seine Geigen sind hochgewölbt, haben großes Patron,
kurze, weite F-Löcher, und dunkelgelben oder braunen Lack. Er
stammt wahrscheinlich aus Busetto und ist vielleicht der Meister der
Violen mit dem Namen: Joannes Marlus (gedruckt). Geigenzettel :
.Abb. 85. Bussolero, Luigi. — Riva-Nazzaro. 1817 Guter Gitarren-
und Mandollnenbauer vom Anfang des 19. Jahrhunderts.
Geigenzettel: Luigi Bussolero Rivanazzaro 1817 (gedruckt). Buthod.
— Mirecourt. 1820. 1845 Nachdem er eine Zeitlang unter Vulllaume
gearbeitet hatte, gründete er in Mirecourt eine große Fabrik und
verband sich später mit Husson; zuletzt hieß die Firma »Husson,
Buthod et Thibouville*. Geigenzettel : Buthod. Luthier / Eleve du
Vulllaume, ä Paris (gedruckt). Buschmann, Gustav Adolf. —
Hamburg. Geb. Buti, Antonio. — Archi. 1756 1835 in Freiburg i. Br.
Mittelmäßiger Geigenmacher aus Albano. Bekannter Piano- und
Harmoniumfabrikant, der als Geigenzettel: Antonio Buti d'Albano
Archi / Fece Erfinder einer schätzenswerten Verbesserung am l'anno
1756 (gedruckt). V. Lütg-endorff, Geig-en- und Lautenmacher. Bd. II
J
 66 Button — Ca'.agari Button. — London. 1806. 1830
Hauptsächlich Händler. Er war zuerst mit Purdey, später mit Whitaker
verbunden und wohnte eine Zeitlang in St. Paul's Churchyard.
Byrom, John. — Liverpool. 1900 Eine sauber gearbeitete Violine, die
ich in Händen hatte, trug semen Namen. C. C.F.R. — Wien. 1800 In
einer sehr schön gearbeiteten, mit Ebenholz, Elfenbein und
Perlmutter eingelegten Gitarre fand sich dieser Brandstempel. Es
gelang mir nicht, den Verfertiger festzustellen. Cabasse, Prosper. —
Mirecourt. Anfang des 19. Jahrhunderts Vielleicht ein Sohn des 1778
genannten Bogenmachers Jean C. Ein ziemlich geschickter Gitarren-
und Geigenmacher, der auf seiner Brandmarke Paris als Ursprungsort
anzugeben pflegte. Sein Modell war schmal und höher gewölbt als
das in Mirecourt übliche. Seine Brandmarke wurde auch nach seinem
Tode noch von Händlern benutzt, wobei der Name manchmal als
Gabasse erscheint. Cabled (Cabley). Claude. — Mirecourt. 1604.
1607 Ein bisher nur aus den Urkunden nachzuweisender
Geigenmacher. Einer seiner Nachkommen, Jean Claude Cabley, lebte
zwischen 1 762 und 1 777 als Bogenmacher. Cabresy. — (?) 1725
Der am 8. Mai 1794 guillotinierte Tavernier de Boulogne besaß nach
Brunis Inventar (Gallay, Un Inventaire sous la terreur par A. Bruni,
Paris 1890, S. 25) »ein Violoncello von Cabresy«. Auch ein Baß aus
dem gleichen Jahr von diesem Meister ist bekannt. Über seinen
Wohnort usw. war nichts zu erfahren. Cabroli, Lorenzo. — Mailand.
1716 Mittelmäßiger Geigenmacher, dessen gelber Lack noch das
Beste an seinen Arbeiten ist. Cabroly. — Toulouse. 1734. 1747 Er
scheint ein in Frankreich eingewanderter Italiener gewesen zu sein
und könnte mit der Mailänder Familie Cabroli zusammenhängen.
Seine Arbeiten sind nicht schlecht und sein Lack ist gewöhnlich
blaßrot oder rötlichgelb. Statt der Einlage zog er oft nur Linien. Eine
Diskantviola von ihm ist in der Crosby BrownSammlung in New York
zu sehen. Geigenzettel: Abb. 124. Cadot, Theobald. — Toulon. Geb.
um 1850 Er ließ sich in den achtziger Jahren des 1 9. Jahrhunderts
in Toulon als Geigenmacher und -händler nieder. Caeste, Gaetano. —
Cremona. 1660. 1680 Da die wenigen, die seinen Namen erwähnen,
ihre Quellen verschweigen, war es nicht möglich, etwas Näheres
über ihn festzustellen. Er gehört vielleicht zur Familie Costa, ist aber
m Cremona unbekannt. Caffarata. — ? 1840 Ein geschickter
Italiener, von dem ich einen sehr guten Baß kennen lernte. Cahusac.
— London (Strand). 1785. 1788 Da er fast nur mit den Söhnen von
Banks gemeinsam arbeitete, kommen Geigen mit seinem Namen
äußerst selten vor. Er hielt sich an den deutschen Stil; sein Modell ist
hochgewölbt. Die Einlage fehlt zwar, dagegen ist sein
bernsteinbrauner Lack schön. Sein Sohn (»Cahusac Son«) ist als
Verfertiger von Oboen bekannt geworden. Cailhe, Henri. —
Charroux. Geb. 8. Aug. 1864 Geschäftsteilhaber seines Vaters J. B.
Cailhe-Decante. Cailhe (Cailhe-Decante), Jean Baptiste. — Charroux.
Geb. in Charroux d'Allier 10. Mai 1832 Schüler und Schwiegersohn
von Jacques Decante, dessen Geschäft er 1858 übernahm und von
Jenzat nach Charroux verlegte, nachdem er vorher von 1855 bis
1857 in Paris und Lyon gearbeitet hatte. Er baute Leiern (Viellen)
nach den Modellen seines Hauses und hat ihnen eine gefälligere
Form und volleren Klang gegeben und auch den Saitenbezug
verdoppelt. Er verwendet einen Spirituslack eigener Mischung. Seine
Fabrik führt das Schild »ä la vielle Bourbonaise«. Auf seinen Zetteln
findet man außer dem Namen seine zahlreichen Auszeichnungen
angeführt. Caille. — Mirecourt. 18. Jahrhundert lacquot nennt zwei
Mitglieder dieser Familie: Louis C. (1779—1787) und Dominique C.
(1769—1789). Caisser s. Kaiser Calabri,PierVittoriodi. — Ferrara.
1549. 1551 Ein Musiker, der auch Lyren gebaut haben soll. Vgl.
Valdrighi 518 und Anmerkung dazu. Calace, Antonio. — Neapel. Um
1850 Nur als Gitarrenmacher bekannt. Er wohnte Strada Mezzo-
cannone Nr. 32. Calace (Calaca), Nicola und Raffaele. - Neapel.
1881. 1903 Söhne des Antonio C. Gehören wie ihr Vater zu den
vielen Mandolinenmachern Neapels. Calagari, Francesco Giuseppe. -
— ? 1685 Eine sehr schöne, hochgewölbte Viola von großem, edlem
Ton, mit braunem feurigen Lack und schöner Schnecke in der
Sammlung Carl Stoeber in Würzburg enthält einen Zettel mit diesem
Namen. Der Wohnort läßt sich nicht einwandfrei lesen. I
 Ca'.ar — Campetti 67 Calar, Giovanni. — Rom. 1624 Ein in
Rom ansässiger Lautenmacher, wahrscheinlich deutscher
Abstammung. Calow, William. — Nottmgham. 1875. Geigenmacher,
Reparateur und Händler. 1890 G enua. Calcagni (Calcanius),
Bernardo. 1710. 1750 Ein geschickter Meister, der von verschiedenen
Kennern der Schule Guarneris zugewiesen wird. Wenn er auch
zeitweise das Guarnen-Modell nachahmte, so nähert er sich mehr
und mehr dem flachen Modelle Stradivaris ; nur um 1 740, da er mit
Pazarini verbunden war, scheint er das hochgewölbte Modell seines
Genossen angenommen zu haben. Sem Holz ist schön und der Lack
von rotgelber oder Goldorangefarbe. Ein Ferdmando Calcanius, den
manche erwähnen, hat in Genua nicht gelebt^). Geigenzettel: Abb.
140. Caldeira. — Lissabon. 1896 Sein Geschäftsteilhaber war Rosa.
Beide sind die Nachfolger von Manoel Pereira gewesen und bauten
hauptsächlich Gitarren und Mandohnen. Callsen, Bruno. — Zittau i.
S. 1898 Die Firma lautete bis 1898 B. Callsen & Schäfer. Er
bezeichnet sein Geschäft als »Streichinstrumentenmacherei".
Caltrassaure (?). — 1787 Eine Geige mit diesem zweifelhaften
Namen, hellbraun lackiert, besitzt G. Withers in London. Calvalono.
— Genf. 1 725 Zweifelhafter Name, der jedoch von Grillet noch
angeführt wird ; s. Cavalono. Calvarola, Bartolommeo. — Torre
Baldone (Bergamo) und Bologna. 1 750. 1 767 Viele seiner Geigen
sind von gewöhnlicher Arbeit, einige aber sorgfältiger gemacht und
erinnern an die Schule der Ruggeri. Sein gelber Lack ist immer
ziemlich gut ; dagegen sind seine Schnecken ohne Schwung und bei
aller Kleinheit plump in der Form. Geigenzettel : Bartolommeo
Calvarola / fecit Bergame 1 76 . . (gedruckt). Calzavara, Santo. —
Padua. 1764 Sein Name ist mir nur in einer klemen Mandoline der
Sammlung Snoeck (Nr. 319) vorgekommen. Geigenzettel : Santo
Calzavara fece ,' in Padova Tanne / 1764 (geschrieben). Calonardi,
Marco. 1 7. Jahrhunderts Sowohl de Piccolellis als Vidal teilen ohne
Quellennachweis nur den Namen mit. »Calonardi« ist jedenfalls mit
»Carlomordi« identisch, doch wage ich nicht zu entscheiden, welche
Form des Namens die richtige ist. Calon-Stremiti, Eugenio. —
Modena. 1840 Nur als Gitarrenmacher bekannt geworden. Calot. —
Bern, Turin. 1820. 1830 Er stammte aus Mirecourt, arbeitete in
verschiedenen Städten als Gehilfe und ließ sich zuerst in Bern und
später in Turin als Geigenmacher nieder. Valdrighi besitzt eine
schöne Gitarre mit dem Zettel : Calot, rue de la rose rouge / porte N.
3. U etage, Turin (gedr.). — Eine von ihm ausgebesserte Viola besaß
Comm. Ca Valien in Ferrara. Geigenzettel : Repare par Calot ,' ä
Herne, 1 . may 1 820 (geschrieben). Calot (Callot). — Paris. Geb.
1810 in Mirecourt In seiner Vaterstadt ausgebildet, kam er als
Gehilfe zu Clement nach Paris und verband sich 1830 mit Augiere,
mit dem zusammen er ein Geschäft in der Rue St. Eustache Nr. 12
eröffnete. Ihre Instrumente zeichnen sich durch saubere Arbeit,
gelbroten Lack und guten Ton aus. ^) Ein Tiberio Calcagni war ein
florentinischer Bildhauer, der um 1560 bei Michel .'Xngelo arbeitete.
Cremona. Mitte des Camberini (?), Giambattista. — Florenz (?). 18.
(?) Jahrhundert Wahrscheinlich ein Mitglied der Familie Giamberini
(s. d.), von dem G. Withers in London einen dreisaitigen Kontrabaß
besitzt. Das Holz daran und die Arbeit sind gut. Camilli, Camillo. —
Mantua. 1714. 1760 Er wird zwar gewöhnlich als Schüler Stradivaris
bezeichnet, doch sind seine Geigen viel häufiger nach Guarnen
gebaut, so daß es wahrscheinlicher ist, daß er bei einem Mitglied der
Guarnerischule gelernt hat. Seine Instrumente kommen, wie nicht
anders zu erwarten, jetzt immer mehr in Aufnahme. Schöner Ton,
gutes Holz, hellroter oder bräunlichroter Lack, der an Landolfi
erinnert, weite, kurze F- Löcher kennzeichnen seine Geigen. Er
verwendet verschiedene Zettel: Eine Violine mit der Inschrift
»Camillo de Camilli Fee. in Mantova 1734« besitzt das Brüsseler
Streichquartett. Geigenzettel : Camillus de Camilli , Fecit in Mantova
1760(gedruckO und Abb. 116, Camilho, Davide. — Cremona. 1 755
Wenig bekannter Meister dritten Ranges, den de Piccolellis übrigens
nicht erwähnt. Er ahmte Nie. Amati nach. Der Wohnort ist vielleicht
fingiert. Campetti, Lorenzo. — Lucca. 1833 Einer der vielen
italienischen Geigenmacher des 19. Jahrhunderts ohne Eigenart,
deren Arbeiten nichts mehr von den Traditionen der klassischen
Meister verraten. 5*
 68 Campi — Cappa Campl, Giuseppe. — Pescina. 1760.
1762 Ein Geigen macher, der vielleicht in Pesaro gelernt hat oder zu
Odoardo in Beziehung stand. Seine Geigen sind nicht schlecht, flach
gewölbt, aber von handwerksmäßiger Arbeit. Geigenzettel :
Josephus de Campis / in Pescina Ao 1 7 . . (geschrieben). —
Giuseppe Campi fece ,' in Pescina Anno 1762 (geschrieben).
Campion. — Paris (?). 1823 Nur nach einer reich mit Perlmutter und
Ebenholz emgelegten Gitarre aus Mahagoniholz bekannt, die m Paris
im Jahre 1823 ausgestellt war. Camploy. J. — Verona. 1854. 1860
Wie so viele andere wollte auch er den alten Cremoneser Lack neu
erfunden haben und stellte Geigen mit diesem Lack in München im
Jahre 1854 aus. Cannon, James. — Dumfnes. Geb. m Plascow
(Kirkcudbrightshire) 1855 Er kam um 1 880 als Bahnbeamter nach
Dumfries und ist ein guter Geiger. Er besaß eine von seinem
Großvater gemachte Violine, die ihn zuerst veranlaßte, sich auch im
Geigenbau zu versuchen. Er studierte Ottos Schriftchen und hat aus
Liebhaberei eine Anzahl Geigen gemacht, die nicht schlecht sind.
Geigenzettel: J. Cannon. / Dumfries,/ 1888 (gedr.). Cans, Dominik.
— Oudenaarde (Belgien). 1 748. t 1806 In der Sammlung Snoeck
befand sich eine von Jooris Willems gebaute Baßviola mit seinem
Reparaturzettel. Er war von Beruf Apotheker und nur aus
Liebhaberei Geigenmacher. Geigenzettel: D. Cans refecit /
Aldenardae, anno 1801 (gedruckt). Capellus, Antonius. — ? 1563
Eine Diskantlaute mit diesem Namen und Datum besitzt C. Claudius
in Kopenhagen. Capiari. 1846 Italienischer Geigenmacher, der um
die Mitte des 19. Jahrhunderts tätig war. Capo (Capa), Antonio. —
Cremona. 1796 Einige wenige Geigen tragen seinen Namen; auch
bei Valdrighi (4093) wird er erwähnt. Capo. — Mailand. 1717. 1718
Ebenso selten vorkommend wie der gleichnamige Cremoneser. Vidal
führt nur den Namen an ; Grillet fügt die Beschreibung eines Zettels
hinzu, ohne auf seine Arbeiten einzugehen. Beide sind vielleicht
Nachkommen G. Cappas. Eine Violine (35,4 mm) von ihm mit einem
Pergamentzettel besitzt Julius von Thury In Budapest. Sie erinnert
eher an das Klotz-Modell als an die Arbeiten gleichzeitiger Malländer,
Ist aber eleganter Im Umriß und hat recht hübsche F-Löcher. Cappa,
Giuseppe Francesco. — Saluzzio. 1 640 Grillet veröffentlicht seinen
Zettel. Wenn die Jahreszahl richtig gelesen und der Zettel echt ist,
dann wäre dieser bisher unbekannte Gius. Franc. C. vermutlich als
ein Oheim des berühmteren Goffredo C. anzusehen. Geigenzettel:
Abb. 139. Cappa, Goffredo. — Saluzzo. Geb. 1644 in Saluzzo, t 6.
Aug. 1717 Sohn des Andrea C. aus Finalborgo. Er war wahrscheinlich
ein Schüler Nicolo Amatis. Von seinen Lebensschicksalen weiß man
bedauerlicherweise sehr wenig, nur daß er im Jahre 1679 die Maria
Scottl geheiratet hat. Er gehört zu den besten Meistern der
Amatlschule und geriet unverdienterweise so in Vergessenheit, daß
allerlei schiefe Urteile über ihn und seine Arbeit lange genug
unwidersprochen verbreitet werden konnten. Auch wurden seine
Zettel gefälscht und mit unsinnigen Jahreszahlen versehen in
minderwertige Gelgen geklebt, während seine echten Arbeiten als
Arbeiten der Amati, deren Namen den Händlern geläufiger waren,
verkauft worden sind. Er nimmt die Wölbung ein klein wenig höher
als sein Lehrer, hat eme andere Schnecke, kurze, weite F-Löcher,
hohe Zargen und kommt im Lack seinen größeren Zeltgenossen
nicht gleich. Seine Geigen haben jedoch einen edlen Ton und können
In dieser Beziehung mindestens den Arbeiten G. B. Rogerls
gleichgestellt werden. Da seine besten Violinen, wie schon bemerkt,
längst mit Amatizetteln versehen wurden, kommt nur selten ein
einwandfreies Exemplar mit seinem Namen zum Vorschein, eher
begegnet man noch Violen und Violoncelli von ihm, so daß es
begreiflich erscheint, wenn min angenommen hat, daß ihm diese
Instrumente besser gelungen seien. Auf den Zetteln, die er In seine
Arbeiten klebte, liest man : lofredus Cappa feclt / Salutlls anno 16 . .
(gedruckt). Diese Zettel wurden schon In alter Zeit gefälscht, und da
sie häufig verwendet wurden, läßt dies doch einen Rückschluß
darauf zu, daß Cappa seinerzeit einen gewissen Ruf bei den Geigern
gehabt haben muß. Dafür spricht auch, daß verschiedene geschickte
Gelgenmacher als Cappa-Schüler bezeichnet wurden, so die Turiner
Meister G. Francesco Celoniato, der etwas ältere Gius. Francesco
Catenarl und Nicola Glorgl, femer Domenico Bombino In VUlafranca
und Spirito Sorsana in Conl und bis zu einem gewissen Grade auch
Carlo Giuseppe Testore In Mailand. Es wird sich schwer feststellen
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookball.com