A few of you maybe aware of the book on Python I wrote, and published, last year? And I've had at least one reader get in touch for a second part. Unfortunately my gaze has passed over Python and returned to where I live. The world of C++.
I have a particular problem with the C++ developers I'm meeting of late, they're either simply not C++ programmers, being an actual mix of good and bad C programmers or just not programmers at all (in one case). Then even when they are very good C Programmers, there's been a mix of the up-take on ideas and feature benefits of modern C++ itself.
Its to and for these fair folk I have begun to write about C++, a new book, based on my own real experience but tempered with where I believe teams and individuals are going wrong when converting their skills to modern C++.
For the programmers reading here now, it starts with a chapter zero... Lets take a sneak-peek....
Chapter 0: Introducing C++
It is incredibly hard to introduce the C++ programming language without at least the most cursory glance at its direct predecessor C. C was created by Dennis Ritchie whilst at Bell Labs sometime between 1969 and 1973, in 1978 Dennis co-authored a book, the book, on the C Languages with Brian Kernighan. Together known as K&R, Kernighan and Richie's book was a great success,
spreading C into being, arguably, the most widely used programming language at the time, and still in that top ten league today.
The success of this first publication, its relative low price of entry into the fast developing world of C for an ever growing number of different machines, really did set C as the language to learn for a very long time.
"C has all the basic elements for expressing computation, it has iterations, it has data types, it has functions and that's it. It doesn't get into the game of expressing abstractions" - Bjarne Stroustrup.
So the world was until 1980, when a talented programmer by the name of Bjarne Stroustrup; working just down the hall from Brian Kernighan at AT&T began a project. He called it "C with Classes". Intended as a natural extension to C, it inherited a large part of the C language syntax as well as many of the mannerisms of C and general purpose computing from the late 1970's.
The concept of "C with Classes" was to furnish users of C with a way to allow the representation of abstractions, if one wanted to represent a car in code they could define something called a "Car", it could have internal values to represent it's speed, direction of travel, the fuel level, everything that we think of as a car could be expressed within a class. In C one has no such way to encapsulate such functionality with any form of familiarity.
Certainly in C you can have a set of variables which represent the exact same things, you can name them to have a meaning of "fuel level", however they are not within anything known as a "Car" you as the programmer has to remember where all these values are, what they are called you have no easy of recall to get back to the values you are using, the concept of a class (what today we also call an object) was one of the major drivers behind the work being carried out.
The name however, "C with Classes" was not as succinct as one might desire, and indeed a friend of Stroustrup suggest he change the name of the language to C++, as the "++" function literally means to add one, an increment. The new language is an increment over the old.
Since then C++ has been ever evolving, in 1998 the first standard version of C++ was codified, from pre-existing attempts to unify the language by both specific vendors of tools for the language (such as Borland, Microsoft or Lattice) and industry bodies (such as ANSI). Published as ISO/IEC 14882:1998 by an ISO working group, C++98 drove home that C++ was at last truly diverged from C. A language in its own right, and something which had to be thought about differently.
I myself started to learn C++ in 1996, the difference in the community before the 1998 standard and afterwards was palpable, since then four other standard have been released. 2003 brought C++03, 2011 brought a working set of revisions ultimately called C++11, but also known as C++0x (due to the new standard taking so long to finalised, it was drafted and promised many times between 2004 and 2009 hence "0x). 2014 saw a further release as C++14, then 2017 saw C++17. The next revision is slated for 2020, it's name is yet to be decided, though good money could be placed on C++20.
From this release schedule we can see the acceleration curve, the faster and faster pace at which C++ has and is diverging from it's roots in C. It has matured, expanded and at each new update become more inclusive of functionality based on abstractions.
Today you can pick up modern C++ and it contains much more than the sum of its parts, you can express everything you could in 1978 in C, but so very much more.
Unfortunately, this success in expanding it's expressive nature, incorporating ever more abstractions and structures from computing, and every-day life, is tainted with some sadness, for as much as C++ strives and drives and builds every upwards, forever it has this seemingly unbreakable umbilical back to C.
You can pick up any C++ compiler from any vendor today, on pretty much any platform, and input a huge swathe of code written not in C++, but still written in C. You can elect to put this very book down right now, pick up a copy of the same book published by Kernigham and Richie in 1978 and produce code which works and work-ably solves some parts of the computational challenges you
face.
However, none of that code will be expressed in the powerful, elegant, I think beautifully powerful manner in which C++ allows you to. Abstraction, encapsulation, expressive representation of the real world in code in a manner which betters your understanding of the topic (as the programmer) but also allows others, non-programmers, to comprehend the devil within the detail of programming a modern computer.
No comments:
Post a Comment