//declarations of functions to play pure notes void left_note(audio_data & data,
double frequency, int duration, double volume); void right_note(audio_data & data,
double frequency, int duration, double volume); void stereo_note(audio_data & data,
double left_frequency, double right_frequency,
int duration, double left_volume, double right_volume);
Put simply, I wanted to be able to play a pure sine wave of a given frequency, duration, and volume on one or both of a pair of stereo speakers. Everything else was implementation. We need an object to manage the audio data. Here is the class definition:
class audio_data{ public:
// WARNING: public data
float *out; // definitely easier to keep this public, // as the callbacks have to manage it
bool (*callback)(audio_data & data);
//end of public data audio_data( );
//init from stream:
audio_data(std::istream & in, int size = samples::default_size);
void new_samples(std::istream & in, int size = samples::default_size); float const * get_samples( ){return data_table.asarray( );}
I am not going to bore you with the details because the purpose of this section is simply to outline how we can implement a high-level interface for an existing legacy library.
The user of the sound library wants to write some simple instructions that will allow them to produce some simple music. They do not want to have to bother with a large amount of complicated low-level code. The task of the library designer is to provide a number of layers so that the user can enter at the level with which they are comfortable. All they need at the top level is to know what note, duration, and loudness they want. They also need an object (an output stream for sound) to which they can send that data. The
SOMETHING OLD, SOMETHING NEW
329
audio data class handles that. The high-level user will need to construct an audio data object. However, they initially need to know nothing about the details of that type, because we hide the details within the implementation of the constructors. The default audio data constructor initializes a lookup table of sound samples using pure sine waves. A second constructor uses a suitable file as a source of sample data.
When the user wants to dive deeper into the details, they can do so. Several other classes handle various aspects of the system. Users never have to concern themselves with the low-level C code. On the other hand, those that want to can. Note that if I wanted to build my library on top of a different low-level library, I could do so without touching the high-level interface.
My coding for my draft for a library for music code is currently very rough, and, perhaps, one day I will have the time to return to it and improve it. The important feature is that it is usable now, and because of the layers of encapsulation, I can work on it bit by bit, progressively improving the code while testing that it still outwardly behaves as it did before.
In Conclusion
Books have to stop somewhere. I could easily write another 600 pages and still not cover everything that makes C++ into the vibrant language that it is today. Inevitably, you will come across many things that have not been covered in these pages. You may want to learn how to design and implement template classes, what mutable is for, what use is private inheritance, what protected is all about, how we overload or even replace operator new, and so on.
Some of these things are best covered by selecting good books that specialize in some of the more advanced aspects of C++; some of them are small things that can be learned by making good use of newsgroups such as alt.comp.lang.learn.c-c++and comp.lang.c++.moderated.
If you have diligently studied the material in this book and done the exercises and experimented with the code, you have a solid basic knowledge of C++ and a sound understanding of how it can be used. I have tried to show you how to build bigger programs by focusing on getting the parts right and avoiding trying to do everything at once.
You certainly still have much to learn, but you also have more than enough C++ to write excellent readable and maintainable code. If our paths cross at some time, please do introduce yourself. Tell me what you liked (that will make me feel good), but tell me what you did not like too, because that will help me the next time I sit down to write a book.
A P P E N D I X A
Those Who Went Before
When I started writing this book, I thought it would be interesting to discover what responses contributors to the comp.lang.c++.moderated newsgroup would give to the following request:
I am in the process of writing a book introducing C++ as a second language (i.e. I assume the reader is able to do simple programming in at least one other language). Yes, I do know that there are other books that do this.
In the introductory chapter, I attempt to cover some of the ways that C++ differs from a wide range of other languages that the reader might already know. I would be interested in contributions from people who have learned C++ as a second language. If you have the time and inclination, could you tell us (I think it might be of general interest to the readership here) what significant differences you found in C++, particularly those that caused you difficulty in understanding C++.
Here are the answers I received. I have edited the spelling and I have corrected the English (several contributors are not native English speakers). I have not suppressed anything nor modified them in any other way.
I thank all those who took the time to share their thoughts and experiences with both the newsgroup and the readers of this book. Remember that each of these contributions is just an individual’s response to my request. They might write something different today.
From Victor Bazarov
C++ was my first OO language. When I learned C++, I knew Fortran, C, assembly for a couple of processors, PL/I, BASIC, a bit of Prolog. The main ‘shock’ was to basically undergo that ‘paradigm shift’ known to accompany switching between a procedural approach and an OO approach. I do not remember actually reading something like ‘From now on you will think differently’ but that is what C++ did for me. Essentially, I discovered OO through learning the syntax of C++ and reading the examples given.
I cannot say I remember any difficulties. Perhaps it’s because too much time has passed since my first foray into C++, perhaps because there were very few of them. I was a C programmer. Going to C++ was quite natural then (not that it has to be for every C programmer; do not get me wrong).
332
APPENDIX A
Another reason why there probably were very few difficulties is that I did not attempt to grasp the entire language at once. In fact, if I recall correctly, the first programs I wrote did not have much of OO. C++ was just a ‘better C’ to me then. Well, I might have written a class or two, but that was the extent of it. Overloading operators, and templates, came later and were more like an evolution of my knowledge of C++ (however small it was) rather than a dramatic change. I had the luxury to ‘take it slow’.
Best of luck with your book!
Victor
Matthew Collett adds
Likewise. I knew Fortran, various dialects of BASIC, some Pascal, even a little assembly. Then I read TC++PL (2nd ed.). It was a mind-expanding experience. (In fact, I found it one of the most conceptually difficult texts I have ever read – which, given that I am by profession a theoretical quantum physicist, is I think a fairly strong statement.;-))
Best wishes,
Matthew Collett
From Ali Cehreli
My first language was C, but I think I was at most an intermediate-level programmer in C when I started learning C++.
RAII (resource allocation is initialization, an abbreviation for the idiom of the language where dynamically allocated resources are encapsulated into an object whose destructor releases them) and exception safety:
For me, the single biggest item in switching to thinking in C++ was realizing that RAII is not just a good thing, but also a must in C++. For some reason, years of following the newsgroups were not enough for me to realize the importance of that idiom.
I woke up from my ignorance after reading the exception-safety section in Exceptional C++ by Herb Sutter.
Of course RAII (and probably even following the guidelines for exception safety) is not very difficult to grasp, but is very important for the learner to understand early on.
Reading:
I am not sure how C++ is different from other languages in this, but it’s not a language to master on one’s own. The learner is on a long journey full of reading articles, books, and newsgroups. I do not think the reading has an end.
No assumptions please:
C++ is probably more different from C than one might think. Related to the item above, the learner must not make assumptions but read. For example, one of the fundamental expressions in C++ is not known by far too many programmers because they assume that if malloc may return null, new might too.
(Before anyone objects, I know that the behavior of new was different in the past, but I have seen this mistake in fresh C++ code written by new C++ programmers. Moreover, I am not talking about new alone here, but ‘writing under assumptions’ in general.)
Ali
THOSE WHO WENT BEFORE
333
From Peter Koch Larsen
My background is roughly Algol → Pascal → C → C++ (Algol only ‘academic’), so I doubt I will be very representative here. I have had very good mentors so I have not had any serious difficulty understanding the language per se, but I remember in particular my initial reluctance to place variables where they are used instead of at the beginning of a function. My biggest revelation was RAII (resource allocation is initialization), which (with templates) is the most important feature of C++.
Peter
From Maciej Sobczak
I’ve learned C++ as my nth language (having some previous BASIC, C, and Pascal experience). One of the things that I appreciate most is the ability to (ab)use operator overloading and templates in order to ‘bend’ the language to the extent that it becomes a separate dialect for performing specific tasks – in other words, the ability to create domain-specific sublanguages. It caused me some difficulty in the sense that it was not visible at the beginning, when I was learning the language. Let me explain this issue. The obligatory line
cout << "Hello, World!" << endl;
was taken (at the beginning) as a way of doing I/O in C++. OK, I knew how to print things in other languages; this one looks different, but still easy enough to remember. Beginners would even use this ‘look and feel’ to distinguish one language from another. You look at the code, and you immediately know what language it is. It took me some time of active language use to discover that the above code is not the ‘C++ way’; it is a dialect, one of many possible ones, and, incidentally, the most popular. I realized then that in the languages that I already knew, all programs are similar. There may be different libraries that provide similar functionality, but the way of doing things is always the same: you call functions in C (and no matter who wrote a library, you can only call its functions); you use classes and call their methods in Java (and no matter who wrote a library, you only call methods of some classes); you call procedures in Pascal (and no matter who wrote the library . . .); and so on. The thing that is different with C++ is that the way to do things highly depends (thanks to operator overloading and templates) on the creativity of the library designer. As a result, two C++ programs can be much more different (in ‘look and feel’) than in other languages. Moreover, I would risk claiming that two C++ ‘dialects’ can have more perceptual differences than there are between whole languages (say, Java and C#).
One of the flagship examples (and my favorite in any debate including proponents of other mainstream languages) is the Boost Spirit library. It is syntax-oriented to the extent that it becomes a separate C++ dialect. In other languages, a library for making parsers would have the same ‘look and feel’ as the library for I/O, or whatever else. Just functions all over the place, or just classes and methods all over the place. In C++, the way of using a library is part of its design, which therefore extends far beyond picking function or class names.
To summarize, C++ is different, because it can be customized.
Of course, the above may be taken as a disadvantage, especially from the point of view of the beginner. In the long run, however, I find it to be one of the most powerful features that puts C++ high above others.
(Slightly off-topic: as a scripting language, I appreciate Tcl for the same reason – it allows me to redefine its commands or define new ones to the extent that it is possible to provide complete paradigms, not only dialects. The example is the library providing generic object-oriented features.)
Maciej
Frank Birbacher adds
I like this too. However, apart from introducing new dialects, it can be used to make things work differently behind the facade of the regular syntax. It might just change the semantics of regular constructs. For example,
334
APPENDIX A
std::auto ptr<>. Objects of this class can almost be used like regular pointers with the same ‘look and
feel’, but the semantics are different: the pointed-to object gets deleted automatically.
Proxies are another example. Iterators provide the same look and feel as pointers, but actually they call regular functions on containers or whatever. In my opinion, this is a big advantage of C++.
C++ is a complex language. One has to do a lot of learning for C++. I started learning BASIC first. When I started with C++ in 1998 (I think) I had most difficulties with its syntax. As time went on, I learned the syntax and then structs/classes. I did not have much experience in OO at all, so I did not see how the classes would help me. But when I learned about the separation of concerns, I started using OO. RAII and exception safety followed. At last, I learned about templates. But after doing OO programs, I stopped using BASIC.
I learned the language slowly by asking questions on borland.public.cppbuilder.language and .students. I did not encounter major jumps during learning, but now I cannot live without classes, operator overloading, and templates. I wonder how I did before. :) This is the most surprising fact to me.
Frank
From Andy Little
I moved onto MSVC1.0 from QuickC – both Microsoft. I remember the weirdest thing was the :: operator. It appeared all over the place, and this was before namespaces. I didn’t understand what it did at all for a long time. There wasn’t (and still isn’t) anything like it in C.
Regards
Andy Little
From John Hickin
Best of luck for your new book!
Unlike most of the popular computer languages that I have needed to use previously, C++ has managed to keep up with the times, through the introduction of new features (templates are especially useful because of the unification engine that the compiler must have in order to support them). I think, therefore, that this best describes why C++ is different.
My first computer language was Fortran; this was in the days when a big machine had 16 MB of main memory; core really was magnetic cores in those days. It was mostly very useful to me, but I remember spending a lot of time as a student implementing dynamic memory allocation and recursion using a common block and ‘hand-crafted stack frames’. Not fun.
I graduated to PL/I when I became gainfully employed. This was wonderful compared to Fortran, but again my language ran out of gas. This time it was inheritance and run-time type identification that we needed (but we used the term ‘generics’ to describe these concepts and the PL/I pre-processor to implement them).
I was converted to C++ in just 30 minutes when a colleague introduced me to it. I vividly remember his description of constructors, destructors, and virtual functions, knowing that these concepts would provide everything that I had lacked in PL/I. This was in spite of the fact that the syntax looked suspiciously like that of a language that I had rejected as having a syntax that was too ugly to bear and too difficult to figure out. :-)
Regards,
John.
From Thomas Hansen
Probably, many readers of your book will come from either the Java camp, the VB6.0 camp or the. NET camp. Therefore, I think that what you should stress as one of the biggest differences is that you have to take care of memory yourself, and therefore maybe you should stress the RAII parts of the language.
THOSE WHO WENT BEFORE
335
But I think that C++’s biggest difference is that it supports so many different paradigms and ways to solve the same problem. Write out a ‘teaser’ containing 15 different ways of solving the ‘Hello World’ application (to demonstrate how rich C++ is). One with a stream taking a string, another with a stream taking an object with an implicit conversion to a std::string, another taking an object with a friend global stream operator, etc.
And maybe take in this one (which is really weird for all non-C++ coders since it turns the inheritance tree upside down and gives possibilities not even thought of by even most C++ coders):
class X { };
template<class T> class Y : public T { };
int main( )
{
Y<X> myY;
}
I think the main difference between C++ and (most) other languages is not one single feature but rather the richness of the language and the many different ways you have of expressing yourself in C++.
‘Balog Pal’ adds
Hmm, I would guess 11 of those solutions would intimidate . . . a big part of the audience. Moreover, the part impressed will be the ones already experts in C++ and peeking into the book just for fun.
Thus, I would rather use examples fit to the paradigm under consideration, and not playing mind tricks – also avoiding pure showing off. However, it may worth having a pointer to the 99 bottles of beer website.
I strongly agree with the main point. The main strength of C++ is its multi-paradigm nature and the ability to use so many different styles to solve the problem at hand.
After one has learned to use them it can give wings and avoid the mind-shrinking effect that working with single-paradigm languages (or working long on a small set of problems) so often brings.
This same thing causes difficulty to newcomers to the field. As learning the part of the rules that can be used and is worth learning is relatively easy. But when you’re given real-world code to work with, knowledge of styles and idioms will be needed, those of today and those of the past – possibly the whole history of two decades. Without those, you just keep wondering why on earth some code looks like this in one file and that in another.
Paul
From Glen Low
My history is BASIC → Pascal → C → C++. Java, C#, and Objective-C have been my post-C++ languages. Thinking back on the difficulties in transitioning to C++, in no particular order:
1.The exact syntax of declaring member functions outside of the class declaration. Especially when interacting with templates.
336
APPENDIX A
2.Subtleties with the Big 3: copy constructor, destructor, and assignment operator. When and why they get automatically defined. When and why they get invoked, e.g. copy constructor in function return,
difference between X x = 1; and X x; x = 1; . . .
3.From a Pascal background, the inverted way you declare C or C++ variables, e.g. X ^CHAR; vs. char* X;, especially with the convolutions you can get with object-oriented C++ (think pointer-to-member). Lack of sets.
4.Why arrays are treated like pointers and structs are not, i.e. why you don’t have a pointer to an array like a pointer to a struct.
Cheers,
Glen Low, Pixelglow Software
From Jean-Marc Bourguet
Well, C++ is not my second programming language. I was already more or less familiar with several variants of BASIC, several variants of Pascal (one of which was OO), several assembly languages, Algol68, Ada83, Fortran, Lisp, C, Prolog, and SmallTalk. This meant that I already had been introduced to all the concepts (often in two incarnations) supported by C++ and I already knew most of the ‘C traps and pitfalls’.
Obviously, if you start C++ without that knowledge, the major challenges are the concepts you are not familiar with. I’ll not write about that. I’ll try to list what surprises I remember (some of them from learning
C:1 –6):
1.char and bool are integral types.
2.Some surprising automatic conversions (mainly integral and pointer types → bool;enum → int).
3.Surprising relations between arrays and pointers.
4.typedef does not introduce a new type but synonyms.
5.No separate compilation, but linking of independently compiled units relying on the programmer’s discipline and/or other tools to ensure coherence.
6.Use of the macro-processor (the main use being to achieve coherence above, but then there are some others). Most of the other languages do not have macros, and those that have have them more integrated (see Lisp, PL/1, or Forth immediate words).
7.Declarations everywhere in a block.
8.It is the class which handles visibility rules (in Ada, Modula3, and some variants of Pascal, it is the module or equivalent).
9.Constructors and especially the implicitly called destructor (there is some kind of equivalent in Ada95 but I don’t remember one in another language), leading to RAII idiom and the possibility of writing exception-safe code without explicit handling of exceptions.
10.Templates need to be ‘macro-expanded’. Most other languages mandate a shared implementation (Eiffel, Modula-3; I think the proposal for Java does as well); Ada83 has both kinds of implementation, and it was a goal of Ada95 to allow the two (I think all the implementations are ‘macro-expanded’). This choice along with the possibility to do (partial) explicit specialization makes C++ templates the most powerful genericity mechanism I know.
Jean-Marc
From Chris Young
I came to C++ primarily from C. One of the biggest things to have bitten me in the early days was the use of const/volatile qualifiers. (The C compiler I used only warned about const violations, whereas the C++ compiler is a lot stricter. Therefore getting const/volatile qualifiers placed correctly
THOSE WHO WENT BEFORE
337
became very important.) http://www.xs4all.nl/ carlo17/c++/const.qualifier.html was of great help here.
Using certain bits of the Standard Library caused indecipherable error messages in the early days (before I heard of STLfilt). This is, of course, an implementation issue more than anything else, but can still be a major put-off for a learner, apt to make mistakes, who has been taught to use the standard containers for general work.
The exception-handling mechanism was difficult to get my head around, about when and how the exception object is copied. For the application that an acquaintance and I were discussing years ago, this was a big deal (we needed to be sure we were not left with a dangling reference when we threw a dynamically allocated exception object):
std::auto_ptr<std::exception> except; // ...
if (something_wrong( )) except.reset(new some_exception);
else if (something_else_wrong( )) except.reset(new other_exception);
// ...
if (except.get( )) throw *except;
Actually, the above would not work – not because of dangling references, but because the exception object is going to be sliced [clause 15, paragraphs 1 –3 of the C++ Standard]. But it was an interesting thought experiment at the time, and just showed (to me, at least) the unintuitive way exceptions are handled. This will be a surprise to, say, Java programmers; they can most certainly throw exceptions of a derived type and expect it not to be sliced:
Exception except = null; // ...
if (something_wrong( ))
except = new SomeException( ); else if (something_else_wrong( ))
except = new OtherException( ); // ...
if (except != null) throw except;
The unintuitive operation of operator bool will cane many newcomers, I think, when all they want is to be able to test an object in a Boolean context. Certainly took me a long time to appreciate why the Standard Library has, say, operator void* instead. [It is because bool has undesired implicit conversions to the fundamental arithmetic types. – Francis]
While we are on bools, there is also std::vector <bool>. This will cane C coders who have been advised to ‘use a std::vector like an array’. [I have not mentioned this issue in this book, but std::vector <bool> has some quirky behavior that you should ask about before using it. – Francis]
That is all I’ve come up with so far. I’ll try to think up more.
Cheers,
Chris K.
From Robert Kindred
One of the biggest differences of C++ from other languages is the ability to use the ‘Curiously Recurring Template Pattern’. This is not possible in any other language. I have heard of a language called Leda that can do this, but then I heard that it was compiled by C++.
