You Can Program In C++ (2006) [eng]
.pdf
338 |
APPENDIX A |
The biggest selling point to cause me to switch from C was constructors and destructors, and the fact that they are invoked automatically. Almost all main( ) functions in C can be written as:
int main(int argc, char* argv[ ]) { init( );
run( ); shutdown( );
}
With constructors and destructors, two-thirds of this can be hidden to allow focus to be placed on the real task, namely what is in run( ).
From Stefan Heinzmann
Before getting into C++, I had experience with a number of procedural languages, mainly Pascal, but also some BASIC, C and Fortran. I also had some experience in various assembler languages and in Forth. Before getting to use C++ in earnest, I had exposure to the concept of object-oriented programming, and did some reading on this subject, which brought me into contact with other languages for OOP, such as some OO-extensions to Pascal (Modula family of languages and Eiffel), without having written anything substantial in them. So you may say that the OO paradigm had started to influence my programming style before I got into C++.
I was well aware at that time that the language you use has an influence on the way you think about the problem, and this has been a motivation to look at different languages in order to find new ways of thinking about problems. I remember having been particularly fascinated by the example of the streams library, where operator overloading was used for something that looked like a language extension, but was implemented as a library. I think to this day that this is the most fascinating aspect of C++: that it offers enough flexibility to the library programmer to tailor the language, in other words to invent your own domain-specific language and implement it as a library, rather than building a new compiler or preprocessor. Library design is language design, indeed!
I think that examples where this is used to good effect are those where C++ shines most. Besides the streams library, you could mention things like the Spirit parser library, or some numeric libraries (for matrix math).
On the other hand, it seems that in this very area the shortcomings of C++ are also felt. It makes me wish there were a language that was simplified as much as possible without giving up the possibility of implementing domain-specific languages as a library. It is this old elusive goal of making it as simple as possible, but no simpler.
C++’s ongoing development has continued to influence my programming style. The C++ I wrote at the beginning is quite different from the style I use now. This reflects the development of the C++ community as a whole – let me just mention templates and exceptions, which have required a long time to mature.
So this may be the other thing that sets C++ apart from many other languages: the development that has taken place within the language. I could say that the development of C++ over the years has allowed me to develop my skills without switching to other languages; C++ has grown with me and I grew with it, lately even to include a good deal of functional thinking. C++ has taken a tour starting at procedural programming and went through OO towards functional programming, as exemplified in the STL, and it has taken me with it.
Of course, for someone learning C++ now, it cannot be the same anymore, and maybe it should not be either. You still need to consider the history, however, in order to understand how and why things ended up the way they are now.
I hope that C++ is not going to freeze any time soon, as there remains a lot of scope for improvement, both for me and for the language.
Cheers
Stefan
THOSE WHO WENT BEFORE |
339 |
Chris Marshall adds
In my case, I had programmed in Pascal, C, early C++ (1989 –1991), and then Java – where I learned Java’s take on OOP and programming in general (namespaces and exceptions) and fell in love with it.
When I first learned Java (in 1997), my feeling was that it fixed the many ways in which C++ had been broken when I tried to make my peace with it and failed.
Shortly thereafter (1999) I had read some article Stroustrup had written on the popularity of Java and how it was being viewed as a panacea for programming ills. Stroustrup demonstrated some of what was possible in C++ then and pointed out that for its problem domain, Java was an OK language, but it had serious shortcomings outside that domain and C++ was more generally useful there. I bought Stroustrup’s book and tried to read it for a few months then gave up in disgust.
It wasn’t until late 2003, on my third or fourth attempt at the language and Stroustrup’s book, that I felt like I had broken through the barriers of understanding that had been blocking me from learning C++.
Stefan: I was well aware at that time that the language you use has an influence . . . Library design is language design, indeed!
I also felt that the design of the << and > > streams operators was brilliant.
Being able to overload those operators allowed you to extend the library without having to define subclasses – a beautiful design.
Stefan: I think that examples where this is used to good effect are those where . . . elusive goal of making it as simple as possible, but no simpler.
My personal feeling is that the biggest shortcoming of C++ is that certain books need to be written that teach you how to make the transition from other languages quickly by exploring how to write programs in various subsets of the language. I am particularly struck by the Java → C++ transition myself, of course.
Each language feature by itself in C++ is very complex when you consider all of its implications, and too many books try to cover each language feature in isolation from the rest of the language before teaching you how to write any significant programs at all. To my mind, it would require the patience of Job to read such a 1000-page monster.
We need more books written in the style of The C Programming Language. Yes, I realize C++ is a vastly more complicated language than C. I am just saying that you do not have to understand anywhere close to the majority of the language or the Standard C++ Library in order to learn enough to write significant and useful programs in C++ in various programming styles. You could have much smaller books that showed you what you needed to know quickly.
Stefan: C++’s ongoing development has continued to influence my programming . . . the development that has taken place within the language.
It has been amazing to watch C++ evolve over the years. I think it is a testament to how unique some of C++’s early, and enduring, language features were. It provides a view of programming that is unique among languages, and it has taken much longer for the consequences of its view to be worked out.
I think one of the most fascinating aspects of the language is how it makes it possible to treat class types similarly to intrinsic types (like int and float), at a time when many other OOP languages were trying to do away with intrinsic types (having an Integer type derived from Object). It was much harder and took much longer to work out the details of how everything should work the way C++ went, and I think C++ was vindicated in the end. The implications of intrinsic-like class objects are much more interesting and generally useful than the implications of attempting to do away with intrinsic types.
Stefan: I could say that the development of C++ over the years has allowed me to . . . exemplified in the STL, and it has taken me with it.
In my case, I am grateful for my time with Java, since it allowed me to learn a certain style of OOP that I kept retreating to when I would get confused in C++. Despite its many virtues, C++ has to be one of the worst teaching languages ever conceived. For people with my mindset, learning C by itself, then learning Java, and then learning C++ is a sane path, and I have trouble imagining any other path to learning C++. [My response is that many people have had a happy introduction to programming using my first book. – Francis]
THOSE WHO WENT BEFORE |
341 |
Language Magazine in 1987 because of an article on C++. Knowing that C was a powerful language, I wanted to discover what C++ had to offer. From reading the article, I understood the basic concept of object-oriented programming and got a taste of the power of encapsulation. At the time I remember thinking that C++ will add about twice the power and twice the complexity of C. Looking back on it now, it seems humorous because I have come to realize that C++ is more of an exponential evolution, probably more on the order of 10 times more powerful and 10 times more complex than C. C++ has been a long road for me because no formal courses were offered back then. I am self-taught. I bought a book on C++ and read it from cover to cover without the benefit of a compiler because the large commercial vendors had not yet come out with a version of C++. I remember there were compilers from smaller vendors that were out of reach for the average hobbyist programmer.
I had to unlearn the mindset of procedural programming and learn to design software using the object-oriented features with which C++ empowered me. Coming from C I struggled with references and preferred pointers to references for the longest time. One of the biggest experiences I remember was when I finally understood what polymorphism was about. I was writing a GUI with different types of components displayed on the screen, such as edit boxes, combo boxes, radio buttons, etc., all derived from the same base class called ViewComponent. I loaded up an array with the pointers to the base classes in order from left to right, top to bottom, as they would appear on the screen. Then I called the draw function for each component through the base-class pointer and watched each component morph itself on the screen. This seemed to be a more practical example than the shape/circle or point/line examples you see in textbooks.
Over the years, I have acquired a library of books devoted to C++. After 17 years studying the language in my spare time and watching it evolve from a language without templates and exceptions, I have come to a point where I feel comfortable that I am at least able to research a practical programming problem and come up with a reasonable solution using the language. During this past year, I feel like I have switched gears and am thinking on a completely new level in terms of idioms and patterns in order to come up with solutions to interesting and practical problems. The language is so vast that occasionally I have come up with solutions that I have never seen published anywhere, which may be undiscovered territory in C++. At any rate, it has been a long journey, with many rewards along the way. C++ makes you work hard, but from my experience it pays you back handsomely. I made up my mind a long time ago that C++ was a necessary language for the serious programmer. I have never wavered from this opinion over the years and feel even more strongly about it today. For anyone that is considering learning C++, my advice would be: ‘do it’. I did it and I will never look back.
From Emily Winch
Unusually, I came to C++ from Java. From that perspective, the major difference was almost a cultural issue – C++ programmers routinely considered the lifetimes of all kinds of resources, whereas in Java one tended to just ‘new and forget’.
I was not impressed by the overloading of the meaning of * and &, and found them confusing to remember. In addition, people used a lot more C-ish idioms such as
*a++ = *b++;
that I had never encountered in a Java program. And the idea that ‘pointer to char’ generally means ‘string’ was very strange – or that a pointer might really be an array.
In addition, I kept accidentally passing things by value when I meant to pass by reference (Java passes by reference automatically for non-built-in types). Finally, in C++ you lose my favorite Java feature – anonymous classes:
frame.addWindowListener( new WindowAdapter( ) {
public void windowClosed( WindowEvent e ) {
342APPENDIX A
//whatever
//access local variables from the surrounding function if necessary
}
}
);
I was constantly wanting to write code like that and not knowing how to. In fact, there still is not a really neat way to do that.
Emily.
From Burc Arpat
My background is Basic → Pascal → Delphi (object Pascal) → Java and Perl (at the same time) → C++ (for the last 5 years or so). I do not claim to know C as well as I do C++ (mainly because I rarely use C-only stuff such as printf family or raw pointers, or dynamic arrays for that matter). I have used Delphi, Java, and Perl pretty much for everything from multimedia apps to database apps, from scientific apps to internet apps. C++ I have used mainly for scientific coding, as that’s what I do nowadays. I am a member of ACCU – a big fan of Francis’s ‘Scribbles’ column in C Vu. I am a daily follower of the Boost list. My total coding experience is more than 10 years.
Weird stuff about C++:
The first problem I had, coming from a long Pascal history, was the lack of the with keyword. I think the question I posted about that can still be found using Google. The with problem frustrated me big time and led me to believe that C++ does not want to make life easier for the programmer. I hated being forced to declare a temporary reference to bind the contained object as a ‘shortcut’ rather than simply writing with. Later, I realized C++ was actually trying to make life safer.
The second thing was, naturally, the whole template stuff. It took me at least a month or so (and several books) to understand and appreciate why on earth we do not use virtual member functions and instead use templates to achieve all this generic wizardry. Today, I think STL and generic programming should not be shown as ‘advanced’ techniques and should be introduced pretty much at the same time as OO stuff. I started to adjust to template code only after two years with C++, because of my OO background, and I have seen several people who refuse to understand the logic of generic programming even after several months of using template code, just because they are comfortable with OO. (A Java programmer of 5 years called the template stuff ‘stupid’, ‘syntax garbage’, and ‘completely unnecessary’ right in front of me when we asked him to start contributing to the C++ portion of the code.)
Another template revelation came to me when I understood the computational power of templates (thanks to Andrei [Alexandrescu]’s book, Modern C++ Design). Even if the STL is explained in a book, the metaprogramming aspect is typically completely skipped. You would not believe the number of experienced C++ programmers I have seen who had no idea about the whole metaprogramming deal. One such programmer even said he prefers to use macros because they are equivalent to, quote, ‘fancy template stuff’. In an introductory book, it is normal not to talk about metaprogramming, but I think it would be cool to give at least one simple example just to show what can be done and then refer to an advanced template book. [I resisted the temptation and you will have to wait for the next book or read someone else’s. – Francis]
Argument-dependent Lookup (ADL, a problematic C++ mechanism that extends the search area for looking up unqualified names to the scopes of the types of the provided arguments) stuff and the whole namespace issue: hordes of C++ programmers have never heard of it, even as Koenig lookup, and thus they have no idea how it might affect them. I remember the first time I saw this code:
using std::swap; swap(lhs, rhs);
THOSE WHO WENT BEFORE |
343 |
I remember the hour-long Googling session I had to do immediately after seeing that to understand why on earth the dude who wrote that piece of code did not simply say std::swap(lhs,~rhs);.
The whole automatic conversions deal. What can I say? They are confusing.
Finally, operator overloading. It is actually not that big a deal if you think about it, but for some reason my brain was fine with function overloading but not with operator overloading when I started learning C++. I have seen other people suffering from the same problem. I guess one reason is, books typically give lots of function overloading examples but not enough operator overloading examples. [Perhaps this book is guilty of giving you too few examples of both. Operator overloading is nice if you want to allow domain experts to use the symbols with which they are familiar. In that sense, operator overloading is very much more useful than function overloading. – Francis]
Hope this helps . . .
Burch
From Greg Schmidt
Many books teach you how to write C++ programs. Many books teach you how to avoid common C++ pitfalls. There are many books that teach you how to transition from the toy programs and object hierarchies you see in other texts to writing code that solves real-world problems in the best possible way (where ‘best’ depends on the technology or paradigm the book is pushing).
What I haven’t seen are any books (not that I’ve looked too hard, mind you) that teach the other critical parts of C++ programming, which include things like making sense of compiler and linker error messages, recognizing the effects of various types of undefined behavior, and how to effectively use a debugger. I firmly believe that much of my success as a C++ programmer has come not from my ability to design effective hierarchies or write efficient code, but from my ability to quickly diagnose and correct bugs that arise during all phases of testing. In other words, I am an average programmer, but an exceptional debugger. Unfortunately, I am a lousy teacher, so I cannot write the book that fills this niche.
Like many people posting here, I got to C++ after much experience with BASIC, Pascal, and C (and less experience with a variety of others). I will try not to repeat any of the good points made previously in the thread.
I think that the difficulties encountered in learning C++ will vary greatly depending on what language you are coming to it from.
As a C programmer, I found the usefulness of the many new uses of const to be elusive, although now I cannot live without them. (Their omission is my biggest problem with Java; how can you create a language where every object is passed by reference, but have no way to disallow changes to the object?)
If I had come to C++ from BASIC or Pascal or Java, then I imagine (based on my experiences learning C) that the biggest difficulty would be the myriad ways in which you can invoke undefined behavior. Other languages do not allow you to do things so stupid as reading past the end of an array, or pretending that a memory location that holds a float actually holds an int, but C++ knows that sometimes (rarely, but sometimes) you really do need to do it, and it lets you. Of course, C++ gives you ways (vector, string, etc.) to eliminate most such problems, but they are not mandatory, and they are at best ‘one-size-fits-most’ solutions, so any serious C++ developer will eventually have to write some potentially dangerous code.
The other big difficulty for me, as others have mentioned, was learning to think in the OO way. Of course, I was learning C++ and MFC at the same time, so it was not just OO but event-driven OO, and that is very different from procedural programming.
Templates did not phase me much, although I use them infrequently enough that I still (after maybe 8 years) have to look up how to do certain things with them.
I immediately fell in love with references, default parameters, function and operator overloading, and the basics of the STL (cout, string, vector). I could feel my mind expanding just reading about them. Things that seemed to me just different (not better) ways of doing the same thing (exceptions, C++-style casts, the STL algorithms) took longer for me to realize the usefulness of.
Hmm, I am starting to ramble now, must be late.
Greg Schmidt
344 |
APPENDIX A |
From llewelly
Before I learned C++, I had brief encounters with a variety of BASICs and Pascals (I had used both Borland and Apple), Z80 and 68 k assembler, and the HyperCard scripting language. But C++ was the first language I learned well, in part because I was able to find more books, discussion, and documentation about C++. I had read only one or two books for each of the previous languages I learned before C++ (and also for most of the languages I’ve learned since then), whereas for C++, I found and read many, many books. The first five or six were truly awful, but as soon as I found The C++ Programming Language 2nd ed. by Bjarne Stroustrup, I started finding other good ones, like the Annotated C++ Reference Manual (I wish there were a 2nd edition as it’s now obsolete), books by Coplien, etc.
I think the differences which confused me most were not differences between C++ and other languages, but differences between vintages of C++. Most of these I can no longer describe – suffice it to say I did a lot (relatively) of programming with templates, starting almost as soon as I began to use C++. This should be normal now, but I learned way back in 1994 –5, when the Standard Library (and much of the semantics of templates themselves) were inaccessible figments of WG21 discussions. It seemed every compiler – even different versions of the same compiler – had wildly different notions of what template semantics were. (The concretely described differences, like for-loop scoping, never caught me off guard, that I recall.)
I realize this is not what you asked for, but I do not recall any confusion that arose from expectations based on previous languages.
From Anthony Williams
I first tried to learn C++ in 1992, knowing only Pascal (of the Borland variety), BASIC, and various assembly languages. It was hard going. I thought I understood it, but I did not. I also had a poor understanding of the available libraries – I did not even have a good grasp of the Standard C Library.
At the time, I remember thinking that templates looked really nifty, as did operator overloading, but I did not really understand either well enough to make proper use of them. I did not have a compiler that could handle templates in anything like a sensible manner either.
Over the next few years, I developed various horrendous OO designs in C++, and learned C properly, along with a smattering of Perl and UNIX shell scripting. I still felt that C++ was fundamentally just C with OO extensions, much like Borland Pascal is standard Pascal plus OO extensions.
Around 1998 I suddenly managed to grok templates, and came across the STL and the rest of the newly standardized C++ Library. It now pained me that the compiler I had to use did not support the STL, and I wrote some simple templates such as a generic list. When g++ 2.95 came out I convinced the company I was working for to switch over to it, and I have never looked back.
I learned Java after I finally grokked C++, and it seems incredibly simple in comparison, and consequently very restrictive. When I write code in Java, I keep trying to do things ‘the C++ way’, as it is shorter and more direct, and it then pains me to have to write things out longhand (e.g. having to use try/finally to get resources cleaned up properly).
So, the features that I really like about C++ are:
•Templates
•The Standard Library
•Deterministic destruction
•Operator overloading
Templates were hard to learn, but maybe because there were not any good examples around. The STL really helps, because it is standard, and because it makes good use of templates.
A key feature I had to learn is that C++ is not just C with OO; it is much, much more powerful than that.
Anthony
THOSE WHO WENT BEFORE |
345 |
From James Kanze
I am not too sure how relevant it is, but I came to C++ from C, and I found it incredibly simpler and easier. Of course, the C++ I first learned (in 1987 –88) was a bit simpler than that of today. However, I had been using C for some time, and my standard procedure in C was to define a struct and a number of functions to manipulate the struct, and then to cross my fingers that no one touched it other than through my functions. The moment I encountered private, I knew that given a choice, I would always choose C++ over C. (In fact, I did not have access to a C++ implementation until a year or so later, when I purchased the Zortech compiler for my PC. And I did not get a chance to use it professionally until 1992. However, I knew that given the chance, it would be C++ rather than C.)
David Bradley adds
Interesting – I followed much the same path. I was creating structs of function pointers. I was attempting to create an interface in C. It worked well for the task of talking to various database APIs. When I came across C++, it was a natural move. I also dabbled in Borland’s Object Pascal, as I had used Pascal in the past as well.
When I jumped into the language I quickly realized there was more I needed to know than just the syntax. Fortunately, I was able to get formal training and read decent books.
The complaints of manual memory management and erroneous memory access are from people who haven’t used the newer facilities in the Standard Library; nor have they sought out third-party libraries for smart pointers and the like. I rarely have these problems in my applications. However, I understand some of the frustration. It is a difficult language. It reminds me a little of English. A very expressive language, but very difficult to learn as a second language.
Therefore, while I enjoy the language, I think there is a fair cost to becoming proficient in the language. In addition, people believe they can jump into something like Java and do things quicker without the risks. However, even as safe as something like Java is, projects still die from the standard classic mistakes.
David Bradley
James Kanze adds
Not necessarily. If you come from C, of course, memory management in C++ seems easy. If you are coming from a higher-level language, however, it probably seems like there is still too much burden on the programmer.
I cannot say that I had memory management problems in C either. However, ensuring that I did not meant extra work. It is less work in C++ than in C, but it is even less work in Java or C++ with garbage collection.
From Brooks Moses
I came to C++ from Fortran, and . . . well, for a long time, I had been avoiding it, because I looked at the built-into-the-language ways of dealing with multidimensional arrays, and they seemed sorely lacking. (I do numerical analysis work; if I write something more complicated than ‘hello world’, it has a multidimensional array in it.) In addition, beyond that, it seemed that many other things such as the string implementation were much lower-level than I wanted to deal with.
346 |
APPENDIX A |
The crucial realization that I had when I actually started working with C++ was recognizing the paradigm that a lot of the fundamental functionality is in libraries, rather than in the core language spec. In particular, while the standard libraries do not have multidimensional arrays, they do have rather decent string implementations, and it was a matter of a few hours of work to knock together a basic multidimensional array that does everything I need.
I think that is a difference that is well worth spending some time on. The idea of operator overloading should be introduced into this very early on, too, as it is important in making library-defined functionality as easy to program with as the core-language parts are.
Brooks
Beliavsky adds
If one is using the multidimensional arrays in Fortran 90/95, where one
1.has access to intrinsic array functions like SUM and MAXVAL,
2.can broadcast ELEMENTAL functions like SIN to all array elements, and define your own ELEMENTAL functions,
3.can refer to array sections like x(1:2,:,2:10:2), and
4.can use arrays of dimensions up to at least 7 (required by the standard),
implementing all this in C++, efficiently, could take months or years. Now that I am used to such functionality, I ‘need’ it, and moving to C++ would seem like a big step backwards.
From Phil A
The main problem I found when moving to C++ was not with learning the language but more in the way some people (still) use it. Looking at a modern C++ text from Koenig, Meyers, or Alexandrescu, you learn the best techniques for programming with the language as it currently stands. However, in real-world projects, I have not seen much use of the Standard Library, exceptions, or namespaces, but I do see reams of arrays and pages of preprocessor macros.
With a language this flexible, the hardest step for me was the leap from modern textbook purity to your next job maintaining an old server application written in ’80s style C++!
From Paul Evans
As with many other posters, I came to C++ circa 1992 from an assembler, BASIC, Pascal, and C background, and had a similar revelation regarding RAII, exceptions, and templates. One thing I have not seen mentioned is an early conceptual problem I had. I could imagine classes, types, inheritance, polymorphisms, OO mappings from application domain to design plus implementation, etc., and all of that was a very exciting way to start thinking about program development (I could only imagine, as I was reading TC++PLed2 and had no access to a compiler). However, perhaps I let my imagination go too far, because I envisioned each object as having its own ‘life’ or thread. It took a few weeks to realize, in the general sense, they were dormant C structs (state) with associated member functions (behavior) that simply had an ‘under-the-hood’ ‘this’ pointer (identity) passed in to hook the state. Now with distributed and multi-threaded programming I do indeed have ‘live’ objects, but I had to work up to that from the ‘dormant’ object idea. Maybe I am just a geek with an over-active imagination, or maybe this is a more common obstacle for newbies.
In any case: many thanks to Bjarne Stroustrup for ‘making programming more fun’!
Paul
