DevelopMentor Whitepaper, Vol.3,  1998
Angelika Langer

Abstract

Download

To give you an idea of what is awaiting you, here is a list of the major new features:

• The standard library provides a rich set of efficient building blocks such as strings, containers, algorithms, complex numbers, streams, locales, and many more. There is neither a justification for reinventing the wheel again and implementing yet another string or linked list class, nor is there any need to resort to vender-specific foundation classes any longer.
• Templates . Class and function templates add another dimension of programming power to the C++ language. Computation of constants, evaluation of expressions, polymorphic dispatch of functions are examples of tasks that - using templates - can be solved at compile time rather than at run time. I will never forget the committee meeting where a colleague of mine stepped into the plenary session with a program that did not even compile, but computed the prime numbers and emitted them in successive error messages. The program was stupid, but demonstrated impressively the power of compile time computations. Even if you do not want to unleash this power, templates make life a lot easier. Whenever you find yourself tempted to solve a problem by "copy and paste" pause for a second and consider using a template instead. Let the compiler do the work instead of doing the tedious job yourself.
• Exception handling . In pre-standard C++, it was cumbersome to indicate failure of constructors. The common technique of error indication via return codes does not work for functions such as constructors, destructors, or cast operators that do not have a return code or for yet another category of functions whose return code is used for purposes other than error indication. First, it was kind of tedious to report errors from such functions and secondly it was inevitable to put the burden of recognizing the error onto the user's shoulders. By and large, error handling in pre-standard C++ was unreliable and error-prone. The language feature of exceptions solves this problem and provides a uniform means for error indication and error handling.
• Namespaces . Name collisions happen more often than many engineers believe. Overloaded binary operators, for instance, must be implemented as global friend functions in order to make them behave symmetrically. The stream inserters and extractors are classical examples of such friend functions. If programmer A implements an inserter for objects of type X and programmer B implements yet another version of the same inserter, then we have name clash that cannot be avoided, because operators have a name that we cannot change without losing the convenience of the operator notation. ANSI C++ introduced the concept of namespace to address this (and other) problems.
• The new-style casts . The classic C-style cast had a multitude of meanings and purposes. The new-style casts replace it completely and document more clearly the intent of a cast. Additionally, they enable the compiler to perform certain checks. For instance, in ANSI C++ we have a safe downcast that checks type information at run time.
• The explicit keyword . Unsolicited type conversions can happen if we provide one-argument constructors. These "converting constructors" are used by the compiler whenever it must set up a sequence of implicit type conversions. Often, the results are surprising. To prevent the compiler from silently using one-argument constructors from implicit conversions, the explicit keyword was introduced.
• The mutable keyword . Sometimes you have to cast away the constness of an object. In ANSI C++, some of these cases can be eliminated by using the mutable keyword, which is for qualification of data members of a class, so that they can be modified from within a const member function without having to cast away the constness of the this pointer.

#include <iostream.h>
#include <fstream.h>
#include <stdlib.h>
#include <string.h>

void doIt(const char* in,const char* out)
{
   /* allocate buffer with initial capacity */
   size_t bufSiz =1024;
   char** buf = (char**) malloc(sizeof(char*)*bufSiz);
   if (buf == 0) quit();
   size_t linCnt = 0;
   buf[linCnt] = 0;

   /* allocate line buffer as destination for read */
   size_t linBufSiz = 256; 
   char* linBuf = (char*) malloc(sizeof(char)*linBufSiz);
   if (linBuf == 0) quit();
   linBuf[0] ='\0'; 
   
   /* open input file */
   ifstream inFile(in);

   /********************************************************/
   /*                       read input                     */
   while (!(inFile.getline(linBuf,linBufSiz)).eof() && !inFile.bad())
   {/* while there is still input */
      expandLinBuf(linBuf,linBufSiz,inFile);
      storeTok(buf,linCnt,bufSiz,linBuf);
   }

   /* sort strings */
   qsort(buf, linCnt ,sizeof(char*), (int(*)(const void*,const void*))strcmp);
      
   /* open output file and write sorted strings to output file */
   ofstream outFile(out);
   for (size_t i = 0; i<linCnt;i++)
      outFile<<buf[i]<<endl;
}

static void quit()
{ cerr << "memory exhausted" << endl;
  exit(1);
}

static void expandLinBuf(char*& linBuf, size_t& linBufSiz,ifstream& inFile )
{
      while (!inFile.eof()&&!inFile.bad()&&strlen(linBuf)==linBufSiz-1)
      { /* while line does not fit into string buffer */

        /* reallocate line buffer */
        linBufSiz += linBufSiz; 
        linBuf = (char*) realloc(linBuf,sizeof(char)*linBufSiz);
        if (linBuf == 0) quit();

        /* read more into buffer */
        inFile.getline(linBuf+linBufSiz/2-1,linBufSiz/2+1);
      }
}

static void storeTok(char**& buf, size_t& linCnt, size_t& bufSiz, const char* token)
{
         /* allocate memory for a copy of the token */
         size_t tokLen =strlen(token);
         buf[linCnt] = (char*) malloc(sizeof(char)*tokLen+1);
         if (buf[linCnt] == 0) quit();

         /* copy the token */
         strncpy(buf[linCnt++],token,tokLen+1);

         /* expand the buffer, if full */
         if (linCnt == bufSiz)
         {  bufSiz +=bufSiz;
            buf = (char**) realloc(buf,sizeof(char*)*bufSiz);
            if (buf == 0) quit();
         }
}

In ANSI C++ the read-sort-write program boils down to something as concise and elegant as this:

#include <fstream>
#include <string>
#include <set>
#include <algorithm>
using namespace ::std;

void doIt(const char* in,const char* out)

{

   set<string> buf;

   string linBuf;

   ifstream inFile(in);

   while(getline(inFile,linBuf))

       buf.insert(linBuf);

   ofstream outFile(out);

   copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));

}

void doIt(const char* in,const char* out)
{
   vector<string> buf;
   vector<string>::iterator insAt = buf.end();
   string linBuf;
   ifstream inFile(in);

   while(getline(inFile,linBuf))
         buf.insert(insAt,linBuf); 

   sort(buf.begin(),buf.end());

   ofstream outFile(out);
   copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));
}

We need to look under the hood of the vector container if we want to understand what is happening here. How is vector organized and what precisely does the insert() function do? A vector internally is a contiguous memory space. Insertion into a vector means that all elements after the point of insertion are moved to the back, in order make room for the new element, and then the new element is added to the collection. A side effect is that all references to elements after the point of insertion become invalid. Now, the insert() function inserts the new element before the specified location. The point of insertion itself, in our example designated by the iterator insAt , becomes invalid as a side effect of the insertion. Any subsequent access to the element referred to by insAt might lead to a crash. This explains why our innocent program crashes after the first insertion of a line into the vector container.

There are several solutions to this problem. The insert() function returns an iterator to the newly inserted element and we can use this new, valid position as the point of insertion for subsequent additions to the vector. It would look like this:

void d(Itconst char* in,const char* out)
{
   vector<string> buf;
   vector<string>::iterator insAt = buf.end();
   string linBuf;
   ifstream inFile(in);

   while(getline(inFile,linBuf))
         insAt = buf.insert(insAt,linBuf); 

   sort(buf.begin(),buf.end());

   ofstream outFile(out);
   copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));

More elegant and easier to comprehend is the use of the push_back() function instead of the insert() function. It inserts elements at the end of a vector . Our example then looks like this:

void doIt(const char* in,const char* out)
{
   vector<string> buf;
   string linBuf;
   ifstream inFile(in);

   while(getline(inFile,linBuf))
         buf.push_back(linBuf); 

   sort(buf.begin(),buf.end());

   ofstream outFile(out);
   copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));

What do we conclude from the program crash that we inadvertently caused? To effectively use the standard library, and all the other new language features, we need to thoroughly understand them. They come with subtle pitfalls that we need to know, so that we can avoid them.

Before you get scared and think: "Well, the new stuff looks cool and will most likely save me lot of work, but it also lures me into lots of booby traps - is it really worth it?", let me tell you that we have barely touched on the possibilities that open up for you by using the standard library. Just as an example: How are the lines ordered in the code snippet above? We didn't care, so what happens? Basically, what happens is a strcmp() style comparison: the strings are ordered by comparing the ASCII codes of the contained characters. Where did we say so? Well, we did not. It is the default behavior of the sort() algorithm. If no compare function, in ANSI C++ more generally called a comparitor , is provided to the sort() function, then it uses the operator<() of the element type, which in our example is string . The ANSI string class has an operator<() defined and this operator performs an ASCII compare. The sort() algorithm implicitly uses it as the sorting criteria in the example above.

Equipped with this knowledge, we can consider other sorting orders. Ordering by ASCII codes does not meet the requirements of dictionary like sorting, where upper case letters appear next to their lower case equivalents. In ASCII the capital letters precede all the lower case letters, so that capital 'Z' precedes lower case 'a' . Can we provide a dictionary type ordering instead of the ASCII default? How about a case-sensitive ordering? How about culture dependent sorting? Foreign alphabets include interesting special characters. How do they affect the sorting order? Lots of questions ....

As an example, let us consider a culture sensitive sorting order. The standard library includes predefined abstractions for internationalization of programs. Among them is class locale , which provides culture dependent string collation via its overloaded function call operator. An object of a class type that has the function call operator overloaded is called a functor in ANSI C++ and can be invoked like a function. In particular, we can pass it to the sort() algorithm as the sorting criteria. Here is the respective code:

#include <fstream>
#include <string>
#include <vector>
#include <algorithm>
#include <locale>
using namespace ::std;

void doIt(const char* in,const char* out)
{
   vector<string> buf;
   string linBuf;
   ifstream inFile(in);

   while(getline(inFile,linBuf))
         buf.push_back(linBuf); // works

   sort(buf.begin(),buf.end(),locale("German"));

   ofstream outFile(out);
   copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));
}

If you are interested to hear more about this and related topics you might want to check out the following seminars:   Reliable C++ - Avoiding commpn traps and pitfalls in C++ programming 3-day seminar (open enrollment and on-site) Effective STL Programming - The Standard Template Library in Depth 4-day seminar (open enrollment and on-site) IOStreams and Locales - Standard C++ IOStreams and Locales in Depth 5-day seminar (open enrollment and on-site) Template Programming - All you ever wanted to know about templates 3-day seminar (open enrollment and on-site)   This document was  published as vol. 3 of Develop Mentor's series of white papers and is available in PDF format: New Features in ANSI C++  - White Paper PDF (229k)