You are here:

C++/abstract classes


Hi!Can you give where c++ abstract class concept gives benifit to software developer?
I mean in what situations he can use that abstract class concept.

Abstract classes - or abstract base classes as they have to be inherited from to create types that can be instantiated - are useful whenever a developer (of any gender) wishes to define a common way of interacting with objects of a set of types but does not have specific implementations for all the defined operations (or any of the operations when modelling an interface). Such situations will become apparent during the development process.

Interfaces in particular are a powerful abstraction as they help de-couple code, allowing making the only thing common between sections of code the (abstract) interfaces. One section of code does not need to know about the specifics of another, only the interface(s) it supports.

As an example I recently defined a set of abstract base class types that defined I/O operations for reading and writing binary values to general purpose IO (GPIO) pins - in this case the language used was Python not C++ - I mention this example to show that abstract (base) classes are not just a C++ concept (although for languages like Python are less useful due to their different approach to types).

The classes were deliberately similar to some Python library IO abstract base classes (ABCs) used for file IO and the like - although not all things translated to the GPIO cases I was concerned with. In my case, as a GPIO pin could be either input (read from) or output (written to) but not both at the same time I separated the read and write cases into separate sub-abstract base classes. The root abstract base class defined only common operations such as close and a set of operations to query the capabilities of a GPIO I/O object such as closed, readable, writable. There were no sane common base implementations for any of these operations so they were all abstract - pure virtual in C++ terms. However, the reader and writer sub-ABCs that added either an abstract (pure virtual) read or an abstract write operation to the existing operations, also defined some of the query operations as in these cases a reader will be readable and not writable and a writer writable but not readable. However, concrete implementations still need to define how to close an open GPIO object, how to determine if the object is closed, and of course a read or write operation.

A C++ example I have used a couple of times before in AllExperts answers is that of an abstract base class used to define the interface to a 2D board game renderer, which is simplified from some of my own code circa 2003/2004. See:

for one such answer (the other is so old AllExperts seems no longer to have it around).

I reproduce, slightly updated, some of that answer for you here. You might like to read the original answer anyway as it makes some additional points I am not going to repeat here:

   class MGameRenderer
       void          DrawBoard
         ( ::CWindowGc & aGc
         , ::TRect const & aRegion
         ) = 0;

       void          DrawCell
         ( ::CWindowGc & aGc
         , ::TPoint const & aCell
         , ::TUint32 aNewState
         , ::TUint32 aPrevState
         ) = 0;

       virtual ~MGameRenderer();

The code that makes use of game renderers pass around MGameRenderer pointers and uses them to make calls to the MGameRenderer operations. Somewhere there is a factory object that creates objects of specific implementations of MGameRenderer e.g. by using new. The factory returns them as a MGameRenderer pointer:

   MGameRenderer * CRenderer::NewGameRenderer
   ( ::TInt aGameDimension
   , ::TRect const & aGameRect
   ) const
       return new CGameRenderer( aGameDimension, aGameRect );

Again this is a simplification of the actual situation. The CGameRenderer class provides implementations for DrawBoard and DrawCell. In the program I provide a basic implementation that draws the game board and the board cells using simple 2D graphics operations such as drawing lines and circles. A fancier implementation might use pre-drawn graphics or even animations for the board and cell states. The renderers are built as separate components so such additional renderers could be written, built and installed at a later date and the user would select the one they wish to use from the set of installed renderers.

Another example would be database interaction. A common way of interacting with relational databases is not that difficult imagine - after all they tend to do similar things in similar ways. However the specifics of interacting with different relational database systems is almost certainly going to be different for each RDBMS (Oracle, MySQL, Postgres, Sybase SQL Server, MS SQL Server, IBM DB2, Informix, SQLite, etc,).

Hope this gives you some hints at least.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2016 All rights reserved.