Programming: Principles and Practice Using C++ (2014)

---

27.1 C and C++: siblings

The C programming language was designed and implemented by Dennis Ritchie at Bell Labs and popularized by the book The C Programming Language by Brian Kernighan and Dennis Ritchie (colloquially known as “K&R”), which is arguably still the best introduction to C and one of the great books on programming (§22.2.5). The text of the original definition of C++ was an edit of the text of the 1980 definition of C, supplied by Dennis Ritchie. After this initial branch, both languages evolved further. Like C++, C is now defined by an ISO standard.

We see C primarily as a subset of C++. Thus, from a C++ point of view, the problem of describing C boils down to two issues:

• Describe where C isn’t a subset of C++.

• Describe which C++ features are missing in C and which facilities and techniques can be used to compensate.

Historically, modern C and modern C++ are siblings. Both are direct descendants of “Classic C,” the dialect of C popularized by the first edition of Kernighan and Ritchie’s The C Programming Language plus structure assignment and enumerations:

The version of C that is used today is still mostly C89 (as described in the second edition of K&R), and that’s what we are describing here. There is still some Classic C in use and some C99, but that should not cause you any problems when you know C++ and C89.

Both C and C++ were “born” in the Computer Science Research Center of Bell Labs in Murray Hill, New Jersey (for a while, my office was a couple of doors down and across the corridor from those of Dennis Ritchie and Brian Kernighan):

Both languages are now defined/controlled by ISO standards committees. For each, many supported implementations are in use. Often, an implementation supports both languages with the desired language chosen by a compiler switch or a source file suffix. Both are available on more platforms than any other language. Both were primarily designed for and are now heavily used for hard system programming tasks, such as

• Operating system kernels

• Device drivers

• Embedded systems

• Compilers

• Communications systems

There are no performance differences between equivalent C and C++ programs.

Like C++, C is very widely used. Taken together, the C/C++ community is the largest software development community on earth.

27.1.1 C/C++ compatibility

It is not uncommon to hear references to “C/C++.” However, there is no such language, and the use of “C/C++” is typically a sign of ignorance. We use “C/C++” only in the context of C/C++ compatibility issues and when talking about the large shared C/C++ technical community.

C++ is largely, but not completely, a superset of C. With a few very rare exceptions, constructs that are both C and C++ have the same meaning (semantics) in both languages. C++ was designed to be “as close as possible to C, but no closer”:

• For ease of transition

• For coexistence

Most incompatibilities relate to C++’s stricter type checking.

An example of a program that is legal C but not C++ is one that uses a C++ keyword that is not a C keyword as an identifier (see §27.3.2):

int class(int new, int bool); /* C, but not C++ */

Examples where the semantics differ for a construct that is legal in both languages are harder to find, but here is one:

int s = sizeof('a'); /* sizeof(int), often 4 in C and 1 in C++ */

The type of a character literal, such as 'a', is int in C and char in C++. However, for a char variable ch we have sizeof(ch)==1 in both languages.

Information related to compatibility and language differences is not exactly exciting. There are no new neat programming techniques to learn. You might like printf() (§27.6), but with that possible exception (and some feeble attempts at geek humor), this chapter is bone dry. Its purpose is simple: to allow you to read and write C if you need to. This includes pointing out the hazards that are obvious to experienced C programmers, but typically unexpected by C++ programmers. We hope you can learn to avoid those hazards with minimal grief.

Most C++ programmers will have to deal with C code at some point or another, just as most C programmers will have to deal with C++ code. Much of what we describe in this chapter will be familiar to most C programmers, but some will be considered “expert level.” The reason for that is simple: not everyone agrees about what is “expert level” and we just describe what is common in real-world code. Maybe understanding compatibility issues can be a cheap way of gaining an unfair reputation as a “C expert.” But do remember: real expertise is in the use of a language (in this case C), rather than in understanding esoteric language rules (as are exposed by considering compatibility issues).

References

ISO/IEC 9899:1999. Programming Languages — C. This defines C99; most implementations implement C89 (often with a few extensions).

ISO/IEC 9899:2011. Programming Languages — C. This defines C11.

ISO/IEC 14882:2011. Programming Languages — C++.

Kernighan, Brian W., and Dennis M. Ritchie. The C Programming Language. Prentice Hall, 1988. ISBN 0131103628.

Stroustrup, Bjarne. “Learning Standard C++ as a New Language.” C/C++ Users Journal, May 1999.

Stroustrup, Bjarne. “C and C++: Siblings”; “C and C++: A Case for Compatibility”; and “C and C++: Case Studies in Compatibility.” The C/C++ Users Journal, July, Aug., and Sept. 2002.

The papers by Stroustrup are most easily found on my publications home page.

27.1.2 C++ features missing from C

From a C++ perspective, C (i.e., C89) lacks a lot of features, such as

• Classes and member functions

• Use struct and global functions.

• Derived classes and virtual functions

• Use structs, global functions, and pointers to functions (§27.2.3).

• Templates and inline functions

• Use macros (§27.8).

• Exceptions

• Use error codes, error return values, etc.

• Function overloading

• Give each function a distinct name.

• new/delete

• Use malloc()/free() and separate initialization/cleanup code.

• References

• Use pointers.

• const, constexpr, or functions in constant expressions

• Use macros.

• bool

• Use int.

• static_cast, reinterpret_cast, and const_cast

• Use C-style casts, e.g., (int)a rather than static<int>(a).

Lots of useful code is written in C, so this list should remind us that no one language feature is absolutely necessary. Most language features — even most C language features — are there for the convenience (only) of the programmer. After all, given sufficient time, cleverness, and patience, every program can be written in assembler. Note that because C and C++ share a machine model that is very close to the real machine, they are well suited to emulate varieties of programming styles.

The rest of this chapter explains how to write useful programs without those features. Our basic advice for using C is:

• Emulate the programming techniques that the C++ features were designed to support with the facilities provided by C.

• When writing C, write in the C subset of C++.

• Use compiler warning levels that ensure function argument checking.

• Use lint for large programs (see §27.2.2).

Many of the details of C/C++ incompatibilities are rather obscure and technical. However, to read and write C, you don’t actually have to remember most of those:

• The compiler will remind you when you are using a C++ feature that is not in C.

• If you follow the rules above, you are unlikely to encounter anything that means something different in C from what it means in C++.

With the absence of all those C++ facilities, some facilities gain importance in C:

• Arrays and pointers

• Macros

• typedef (the C and C++98 equivalent to simple using declarations; see §20.5, §A.16)

• sizeof

• Casts

We give examples of a few such uses in this chapter.

I introduced the // comments into C++ from C’s ancestor BCPL when I got really fed up with typing /* . . . */ comments. The // comments are accepted by most C dialects including C99 and C11, so it is probably safe just to use them. Here, we will use /* . . . */ exclusively in examples meant to be C. C99 and C11 introduced a few more C++ features (as well as a few features that are incompatible with C++), but here we will stick to C89, because that’s far more widely used.

27.1.3 The C standard library

Naturally, a C++ library facility that depends on classes and templates is not available in C. This includes

• vector

• map

• set

• string

• The STL algorithms: e.g., sort(), find(), and copy()

• iostreams

• regex

For these, there are often C libraries based on arrays, pointers, and functions to help compensate. The main parts of the C standard library are

• <stdlib.h>: general utilities (e.g., malloc() and free(); see §27.4)

• <stdio.h>: standard I/O; see §27.6

• <string.h>: C-style string manipulation and memory manipulation; see §27.5

• <math.h>: standard floating-point mathematical functions; see §24.8

• <errno.h>: error codes for <math.h>; see §24.8

• <limits.h>: sizes of integer types; see §24.2

• <time.h>: date and time; see §26.6.1

• <assert.h>: debug assertions; see §27.9

• <ctype.h>: character classification; see §11.6

• <stdbool.h>: Boolean macros

For a complete description, see a good C textbook, such as K&R. All of these libraries (and header files) are also available in C++.

27.2 Functions

In C:

• There can be only one function of a given name.

• Function argument type checking is optional.

• There are no references (and therefore no pass-by-reference).

• There are no member functions.

• There are no inline functions (except in C99).

• There is an alternative function definition syntax.

Apart from that, things are much as you are used to in C++. Let us explore what that means.

27.2.1 No function name overloading

Consider:

void print(int); /* print an int */
void print(const char*); /* print a string */ /* error! */

The second declaration is an error because there cannot be two functions with the same name. So you’ll have to invent a suitable pair of names:

void print_int(int); /* print an int */
void print_string(const char*); /* print a string */

This is occasionally claimed to be a virtue: now you can’t accidentally use the wrong function to print an int! Clearly we don’t buy that argument, and the lack of overloaded functions does make generic programming ideas awkward to implement because generic programming depends on semantically similar functions having the same name.

27.2.2 Function argument type checking

Consider:

int main()
{
f(2);
}

A C compiler will accept this: you don’t have to declare a function before you call it (though you can and should). There may be a definition of f() somewhere. That f() could be in another translation unit, but if it isn’t, the linker will complain.

Unfortunately, that definition in another source file might look like this:

/* other_file.c: */

int f(char* p)
{
int r = 0;
while (*p++) r++;
return r;
}

The linker will not report that error. You will get a run-time error or some random result.

How do we manage problems like that? Consistent use of header files is a practical answer. If every function you call or define is declared in a header that is consistently #included whenever needed, we get checking. However, in large programs that can be hard to achieve. Consequently, most C compilers have options that give warnings for calls of undeclared functions: use them. Also, from the earliest days of C, there have been programs that can be used to check for all kinds of consistency problems. They are usually called lint. Use a lint for every nontrivial C program. You will find that lint pushes you toward a style of C usage that is rather similar to using a subset of C++. One of the observations that led to the design of C++ was that the compiler could easily check much (but not all) of what lint checked.

You can ask to have function arguments checked in C. You do that simply by declaring a function with its argument types specified (just as in C++). Such a declaration is called a function prototype. However, beware of function declarations that do not specify arguments; those are notfunction prototypes and do not imply function argument checking:

int g(double); /* prototype — like C++ function declaration */
int h(); /* not a prototype — the argument types are unspecified */

void my_fct()
{
g(); /* error: missing argument */
g("asdf"); /* error: bad argument type */
g(2); /* OK: 2 is converted to 2.0 */
g(2,3); /* error: one argument too many */

h(); /* OK by the compiler! May give unexpected results */
h("asdf"); /* OK by the compiler! May give unexpected results */
h(2); /* OK by the compiler! May give unexpected results */
h(2,3); /* OK by the compiler! May give unexpected results */
}

The declaration of h() specifies no argument type. This does not mean that h() doesn’t accept arguments; it means “Accept any set of arguments and hope they are correct for the called function.” Again, a good compiler warns and lint will catch the problem.

There is a special set of rules for converting arguments where no function prototype is in scope. For example, chars and shorts are converted to ints, and floats are converted to doubles. If you need to know, say, what happens to a long, look it up in a good C textbook. Our recommendation is simple: don’t call functions without prototypes.

Note that even though the compiler will allow an argument of the wrong type to be passed, such as a char* to a parameter of type int, the use of such an argument of a wrong type is an error. As Dennis Ritchie said, “C is a strongly typed, weakly checked, programming language.”

27.2.3 Function definitions

You can define functions exactly as in C++ and such definitions are function prototypes:

double square(double d)
{
return d*d;
}

void ff()
{
double x = square(2); /* OK: convert 2 to 2.0 and call */
double y = square(); /* argument missing */
double y = square("Hello"); /* error: wrong argument type */
double y = square(2,3); /* error: too many arguments */
}

A definition of a function with no arguments is not a function prototype:

void f() { /* do something */ }

void g()
{
f(2); /* OK in C; error in C++ */
}

Having

void f(); /* no argument type specified */

mean “f() can take any number of arguments of any type” seemed really strange. In response, I invented a new notation where “nothing” was explicitly stated using the keyword void (void is a four-letter word meaning “nothing”):

void f(void); /* no arguments accepted */

I soon regretted that, though, since that looks odd and is completely redundant when argument type checking is uniformly applied. Worse, Dennis Ritchie (the father of C) and Doug McIlroy (the ultimate arbiter of taste in the Bell Labs Computer Science Research Center; see §22.2.5) both called it “an abomination.” Unfortunately, that abomination became very popular in the C community. Don’t use it in C++, though, where it is not only ugly, but also logically redundant.

C also provides a second, Algol60-style function definition, where the parameter types are (optionally) specified separately from their names:

int old_style(p,b,x) char* p; char b;
{
/* . . . */
}

This “old-style definition” predates C++ and is not a prototype. By default, an argument without a declared type is an int. So, x is an int parameter of old_style(). We can call old_style() like this:

old_style(); /* OK: all arguments missing */
old_style("hello", 'a', 17); /* OK: all arguments are of the right type */
old_style(12, 13, 14); /* OK: 12 is the wrong type, */
/* but maybe old_style() won’t use p */

The compiler should accept these calls (but would warn, we hope, for the first and third).

Our recommendation about function argument checking:

• Use function prototypes consistently (use header files).

• Set compiler warning levels so that argument type errors are caught.

• Use (some) lint.

The result will be code that’s also C++.

27.2.4 Calling C from C++ and C++ from C

You can link files compiled with a C compiler together with files compiled with a C++ compiler provided the two compilers were designed for that. For example, you can link object files generated from C and C++ using your GNU C and C++ compiler (GCC) together. You can also link object files generated from C and C++ using your Microsoft C and C++ compiler (MSC++) together. This is common and useful because it allows you to use a larger set of libraries than would be available in just one of those two languages.

C++ provides stricter type checking than C. In particular, a C++ compiler and linker check that two functions f(int) and f(double) are consistently defined and used — even in different source files. A linker for C doesn’t do that kind of checking. To call a function defined in C from C++ and to have a function defined in C++ called from C, we need to tell the compiler what we are doing:

// calling C function from C++:

extern "C" double sqrt(double); // link as a C function

void my_c_plus_plus_fct()
{
double sr = sqrt(2);
}

Basically extern "C" tells the compiler to use C linker conventions. Apart from that, all is normal from a C++ point of view. In fact, the C++ standard sqrt(double) usually is the C standard library sqrt(double). Nothing is required from the C program to make a function callable from C++ in this way. C++ simply adapts to the C linkage convention.

We can also use extern "C" to make a C++ function callable from C:

// C++ function callable from C:

extern "C" int call_f(S* p, int i)
{
return p->f(i);
}

In a C program, we can now call the member function f() indirectly, like this:

/* call C++ function from C: */

int call_f(S* p, int i);
struct S* make_S(int,const char*);

void my_c_fct(int i)
{
/* . . . */
struct S* p = make_S(x, "foo");
int x = call_f(p,i);
/* . . . */
}

No mention of C++ is needed (or possible) in C for this to work.

The benefit of this interoperability is obvious: code can be written in a mix of C and C++. In particular, a C++ program can use libraries written in C, and C programs can use libraries written in C++. Furthermore, most languages (notably Fortran) have an interface for calling to/from C.

In the examples above, we assumed that C and C++ could share the class object pointed to by p. That is true for most class objects. In particular, if you have a class like this,

// in C++:
class complex {
double re, im;
public:
// all the usual operations
};

you can get away with passing a pointer to an object to and from C. You can even access re and im in a C program using a declaration:

/* in C: */
struct complex {
double re, im;
/* no operations */
};

The rules for layout in any language can be complex, and the rules for layout among languages can even be hard to specify. However, you can pass built-in types between C and C++ and also classes (structs) without virtual functions. If a class has virtual functions, you should just pass pointers to its objects and leave the actual manipulation to C++ code. The call_f() was an example of this: f() might be virtual and then that example would illustrate how to call a virtual function from C.

Apart from sticking to the built-in types, the simplest and safest sharing of types is a struct defined in a common C/C++ header file. However, that strategy seriously limits how C++ can be used, so we don’t restrict ourselves to it.

27.2.5 Pointers to functions

What can we do in C if we want to use object-oriented techniques (§14.2-4)? Basically, we need an alternative to virtual functions. For most people, the first idea that springs to mind is to use a struct with a “type field” that describes what kind of shape a given object represents. For example:

struct Shape1 {
enum Kind { circle, rectangle } kind;
/* . . . */
};

void draw(struct Shape1* p)
{
switch (p->kind) {
case circle:
/* draw as circle */
break;
case rectangle:
/* draw as rectangle */
break;
}
}

int f(struct Shape1* pp)
{
draw(pp);
/* . . . */
}

This works. There are two snags, though:

• For each “pseudo-virtual” function (such as draw()), we have to write a new switch-statement.

• Each time we add a new shape, we have to modify every “pseudo-virtual” function (such as draw()) by adding a case to the switch-statement.

The second problem is quite nasty because it means that we can’t provide our “pseudo-virtual” functions as part of a library, because our users will have to modify those functions quite often. The most effective alternative involves pointers to functions:

typedef void (*Pfct0)(struct Shape2*);
typedef void (*Pfct1int)(struct Shape2*,int);

struct Shape2 {
Pfct0 draw;
Pfct1int rotate;
/* . . . */
};

void draw(struct Shape2* p)
{
(p->draw)(p);
}

void rotate(struct Shape2* p, int d)
{
(p->rotate)(p,d);
}

This Shape2 can be used just like Shape1.

int f(struct Shape2* pp)
{
draw(pp);
/* . . . */
}

With a little extra work, an object need not hold one pointer to a function for each pseudo-virtual function. Instead, it can hold a pointer to an array of pointers to functions (much as virtual functions are implemented in C++). The main problem with using such schemes in real-world programs is to get the initialization of all those pointers to functions right.

27.3 Minor language differences

This section gives examples of minor C/C++ differences that could trip you up if you have never heard of them. Few seriously impact programming in that the differences have obvious work-arounds.

27.3.1 struct tag namespace

In C, the names of structs (there is no class keyword) are in a separate namespace from other identifiers. Therefore, every name of a struct (called a structure tag) must be prefixed with the keyword struct. For example:

struct pair { int x,y; };
pair p1; /* error: no identifier pair in scope */
struct pair p2; /* OK */
int pair = 7; /* OK: the struct tag pair is not in scope */
struct pair p3; /* OK: the struct tag pair is not hidden by the int */
pair = 8; /* OK: pair refers to the int */

Amazingly enough, thanks to a devious compatibility hack, this also works in C++. Having a variable (or a function) with the same name as a struct is a fairly common C idiom, though not one we recommend.

If you don’t want to write struct in front of every structure name, use a typedef (§20.5). The following idiom is common:

typedef struct { int x,y; } pair;
pair p1 = { 1, 2 };

In general, you’ll find typedefs more common and more useful in C, where you don’t have the option of defining new types with associated operations.

In C, names of nested structs are placed in the same scope as the struct in which they are nested. For example:

struct S {
struct T { /* . . . */ };
/ * . . . */
};

struct T x; /* OK in C (not in C++) */

In C++, you would write

S::T x; // OK in C++ (not in C)

Whenever possible, don’t nest structs in C: their scope rules differ from what most people naively (and reasonably) expect.

27.3.2 Keywords

Many keywords in C++ are not keywords in C (because C doesn’t provide the functionality) and can be used as identifiers in C:

Don’t use these names as identifiers in C, or your code will not be portable to C++. If you use one of these names in a header file, that header won’t be useful from C++.

Some C++ keywords are macros in C:

In C, they are defined in <iso646.h> and <stdbool.h> (bool, true, false). Don’t take advantage of the fact that they are macros in C.

27.3.3 Definitions

C++ allows definitions in more places than C89. For example:

for (int i = 0; i<max; ++i) x[i] = y[i]; // definition of i not allowed in C

while (struct S* p = next(q)) { // definition of p not allowed in C
/* . . . */
}

void f(int i)
{
if (i< 0 || max<=i) error("range error");
int a[max]; // error: declaration after statement not allowed in C
/* . . . */
}

C (C89) doesn’t allow declarations as initializers in for-statements, as conditions, or after a statement in a block. We have to write something like

int i;
for (i = 0; i<max; ++i) x[i] = y[i];

struct S* p;
while (p = next(q)) {
/* . . . */
}

void f(int i)
{
if (i< 0 || max<=i) error("range error");
{
int a[max];
/* . . . */
}
}

In C++, an uninitialized declaration is a definition; in C, it is just a declaration so that there can be two of them:

int x;
int x; /* defines or declares a single integer called x in C; error in C++ */

In C++, an entity must be defined exactly once. This gets a bit more interesting if the two ints are in different translation units:

/* in file x.c: */
int x;

/* in file y.c: */
int x;

No C or C++ compiler will find any fault with either x.c or y.c. However, if x.c and y.c are compiled as C++, the linker will give a “double definition” error. If x.c and y.c are compiled as C, the linker accepts the program and (correctly according to C rules) considers there to be just one x that is shared between code in x.c and y.c. If you want a program where a global variable x is shared, say so explicitly:

/* in file x.c: */
int x = 0; /* the definition */

/* in file y.c: */
extern int x; /* a declaration, not a definition */

Better still, use a header file:

/* in file x.h: */
extern int x; /* a declaration, not a definition */

/* in file x.c: */
#include "x.h"
int x = 0; /* the definition */

/* in file y.c: */
#include "x.h"
/* the declaration of x is in the header */

Better still, avoid the global variable.

27.3.4 C-style casts

In C (and C++), you can explicitly convert a value v to a type T by this minimal notation:

(T)v

This “C-style cast” or “old-style cast” is beloved by poor typists and sloppy thinkers because it’s minimal and you don’t have to know what it takes to make a T from v. On the other hand, this style of cast is rightfully feared by maintenance programmers because it is just about invisible and leaves no clue about the writer’s intent. The C++ casts (named casts or template-style casts; see §A.5.7) were introduced to make explicit type conversion easy to spot (ugly) and specific. In C, you have no choice:

int* p = (int*)7; /* reinterpret bit pattern: reinterpret_cast<int*>(7) */
int x = (int)7.5; /* truncate double: static_cast<int>(7.5) */

typedef struct S1 { /* . . . */ } S1;
typedef struct S2 { /* . . . */ } S2;
S2 a;
const S2 b; /* uninitialized consts are allowed in C */

S1* p = (S1*)&a; /* reinterpret bit pattern: reinterpret_cast<S1*>(&a) */
S2* q = (S2*)&b; /* cast away const: const_cast<S2*>(&b) */
S1* r = (S1*)&b; /* remove const and change type; probably a bug */

We hesitate to recommend a macro (§27.8) even in C, but it may be an idea to express intent like this:

#define REINTERPRET_CAST(T,v) ((T)(v))
#define CONST_CAST(T,v) ((T)(v))

S1* p = REINTERPRET_CAST (S1*,&a);
S2* q = CONST_CAST(S2*,&b);

This does not give the type checking done by reinterpret_cast and const_cast, but it does make these inherently ugly operations visible and the programmer’s intent explicit.

27.3.5 Conversion of void*

In C, a void* may be used as the right-hand operand of an assignment to or initialization of a variable of any pointer type; in C++ it may not. For example:

void* alloc(size_t x); /* allocate x bytes */

void f (int n)
{
int* p = alloc(n*sizeof(int)); /* OK in C; error in C++ */
/* . . . */
}

Here, the void* result of alloc() is implicitly converted to an int*. In C++, we would have to rewrite that line to

int* p = (int*)alloc(n*sizeof(int)); /* OK in C and C++ */

We used the C-style cast (§27.3.4) so that it would be legal in both C and C++.

Why is the void*-to-T* implicit conversion illegal in C++? Because such conversions can be unsafe:

void f()
{
char i = 0;
char j = 0;
char* p = &i;
void* q = p;
int* pp = q; /* unsafe; legal in C, error in C++ */
*pp = -1; /* overwrite memory starting at &i */
}

Here we can’t even be sure what memory is overwritten. Maybe j and part of p? Maybe some memory used to manage the call of f() (f’s stack frame)? Whatever data is being overwritten here, a call of f() is bad news.

Note that (the opposite) conversion of a T* to a void* is perfectly safe — you can’t construct nasty examples like the one above for that — and those are allowed in both C and C++.

Unfortunately, implicit void*-to-T* conversions are common in C and possibly the major C/C++ compatibility problem in real code (see §27.4).

27.3.6 enum

In C, you can assign an int to an enum without a cast. For example:

enum color { red, blue, green };
int x = green; /* OK in C and C++ */
enum color col = 7; /* OK in C; error in C++ */

One implication of this is that we can use increment (++) and decrement (--) on variables of enumeration type in C. That can be convenient but does imply a hazard:

enum color x = blue;
++x; /* x becomes green; error in C++ */
++x; /* x becomes 3; error in C++ */

“Falling off the end” of the enumerators may or may not have been what we wanted.

Note that like structure tags, the names of enumerations are in their own namespace, so you have to prefix them with the keyword enum each time you use them:

color c2 = blue; /* error in C: color not in scope; OK in C++ */
enum color c3 = red; /* OK */

27.3.7 Namespaces

There are no namespaces (in the C++ sense of the word) in C. So what do you do when you want to avoid name clashes in large C programs? Typically, people use prefixes or suffixes. For example:

/* in bs.h: */
typedef struct bs_string { /* . . . */ } bs_string; /* Bjarne’s string */
typedef int bs_bool ; /* Bjarne’s Boolean type */

/* in pete.h: */
typedef char* pete_string; /* Pete’s string */
typedef char pete_bool ; /* Pete’s Boolean type */

This technique is so popular that it is usually a bad idea to use one- or two-letter prefixes.

27.4 Free store

C does not provide the new and delete operators dealing with objects. To use the free store, you use functions dealing with memory. The most important functions are defined in the “general utilities” standard header <stdlib.h>:

void* malloc(size_t sz); /* allocate sz bytes */
void free(void* p); /* deallocate the memory pointed to by p */
void* calloc(size_t n, size_t sz); /* allocate n*sz bytes initialized to 0 */
void* realloc(void* p, size_t sz); /* reallocate the memory pointed to by p
to a space of size sz */

The typedef size_t is an unsigned type also defined in <stdlib.h>.

Why does malloc() return a void*? Because malloc() has no idea which type of object you want to put in that memory. Initialization is your problem. For example:

struct Pair {
const char* p;
int val;
};

struct Pair p2 = {"apple",78};
struct Pair* pp = (struct Pair*) malloc(sizeof(Pair)); /* allocate */
pp->p = "pear"; /* initialize */
pp->val = 42;

Note that we cannot write

*pp = {"pear", 42}; /* error: not C or C++98 */

in either C or C++. However, in C++, we would define a constructor for Pair and write

Pair* pp = new Pair("pear", 42);

In C (but not C++; see §27.3.4), you can leave out the cast before malloc(), but we don’t recommend that:

int* p = malloc(sizeof(int)*n); /* avoid this */

Leaving out the cast is quite popular because it saves some typing and because it catches the rare error of (illegally) forgetting to include <stdlib.h> before using malloc(). However, it can also remove a visual clue that a size was wrongly calculated:

p = malloc(sizeof(char)*m); /* probably a bug — not room for m ints */

Don’t use malloc()/free() in C++ programs; new/delete require no casts, deal with initialization (constructors) and cleanup (destructors), report memory allocation errors (through an exception), and are just as fast. Don’t delete an object allocated by malloc() or free() an object allocated bynew. For example:

int* p = new int[200];
// . . .
free(p); // error

X* q = (X*)malloc(n*sizeof(X));
// . . .
delete q; // error

This might work, but it is not portable code. Furthermore, for objects with constructors or destructors, mixing C-style and C++-style free-store management is a recipe for disaster.

The realloc() function is typically used for expanding buffers:

int max = 1000;
int count = 0;
int c;
char* p = (char*)malloc(max);
while ((c=getchar())!=EOF) { /* read: ignore chars on eof line */
if (count==max-1) { /* need to expand buffer */
max += max; /* double the buffer size */
p = (char*)realloc(p,max);
if (p==0) quit();
}
p[count++] = c;
}

For an explanation of the C input operations, see §27.6.2 and §B.11.2.

The realloc() function may or may not move the old allocation into newly allocated memory. Don’t even think of using realloc() on memory allocated by new.

Using the C++ standard library, the (roughly) equivalent code is

vector<char> buf;
char c;
while (cin.get(c)) buf.push_back(c);

Refer to the paper “Learning Standard C++ as a New Language” (see the reference list in §27.1) for a more thorough discussion of input and allocation strategies.

27.5 C-style strings

In C, a string (often called a C string or a C-style string in C++ literature) is a zero-terminated array of characters. For example:

char* p = "asdf";
char s[] = "asdf";

In C, we cannot have member functions, we cannot overload functions, and we cannot define an operator (such as ==) for a struct. It follows that we need a set of (nonmember) functions to manipulate C-style strings. The C and C++ standard libraries provide such functions in <string.h>:

size_t strlen(const char* s); /* count the characters */
char* strcat(char* s1, const char* s2); /* copy s2 onto the end of s1 */
int strcmp(const char* s1, const char* s2); /* compare lexicographically */
char* strcpy(char* s1,const char* s2); /* copy s2 into s1 */

char* strchr(const char *s, int c); /* find c in s */
char* strstr(const char *s1, const char *s2); /* find s2 in s1 */

char* strncpy(char*, const char*, size_t n); /* strcpy, max n chars */
char* strncat(char*, const char, size_t n); /* strcat with max n chars */
int strncmp(const char*, const char*, size_t n); /* strcmp with max n chars */

This is not the full set, but these are the most useful and most used functions. We will briefly illustrate their use.

We can compare strings. The equality operator (==) compares pointer values; the standard library function strcmp() compares C-style string values:

const char* s1 = "asdf";
const char* s2 = "asdf";

if (s1==s2) { /* do s1 and s2 point to the same array? */
/* (typically not what you want) */
}

if (strcmp(s1,s2)==0) { /* do s1 and s2 hold the same characters? */

}

The strcmp() function does a three-way comparison of its two arguments. Given the values of s1 and s2 above, strcmp(s1,s2) will return 0, meaning a perfect match. If s1 was lexicographically before s2, it would return a negative number, and if s1 was lexicographically after s2, it would return a positive number. The term lexicographical means roughly “as in a dictionary.” For example:

strcmp("dog","dog")==0
strcmp("ape","dodo")<0 /* "ape" comes before "dodo" in a dictionary */
strcmp("pig","cow")>0 /* "pig" comes after "cow" in a dictionary */

The value of the pointer comparison s1==s2 is not guaranteed to be 0 (false). An implementation may decide to use the same memory to hold all copies of a character literal, so we would get the answer 1 (true). Usually, strcmp() is the right choice for comparing C-style strings.

We can find the length of a C-style string using strlen():

int lgt = strlen(s1);

Note that strlen() counts characters excluding the terminating 0. In this case, strlen(s1)==4 and it takes 5 bytes to store "asdf". This little difference is the source of many off-by-one errors.

We can copy one C-style string (including the terminating 0) into another:

strcpy(s1,s2); /* copy characters from s2 into s1 */

It is your job to be sure that the target string (array) has enough space to hold the characters from the source.

The strncpy(), strncat(), and strncmp() functions are versions of strcpy(), strcat(), and strcmp() that will consider a maximum of n characters, where n is their third argument. Note that if there are more than n characters in the source string, strncpy() will not copy a terminating 0, so that the result will not be a valid C-style string.

The strchr() and strstr() functions find their second argument in the string that is their first argument and return a pointer to the first character of the match. Like find(), they search from left to right in the string.

It is amazing both how much can be done with these simple functions and how easy it is to make minor mistakes. Consider a simple problem of concatenating a user name with an address, placing the @ character in between. Using std::string this can be done like this:

string s = id + '@' + addr;

Using the standard C-style string function we can write that as

char* cat(const char* id, const char* addr)
{
int sz = strlen(id)+strlen(addr)+2;
char* res = (char*) malloc(sz);
strcpy(res,id);
res[strlen(id)+1] = '@';
strcpy(res+strlen(id)+2,addr);
res[sz-1]=0;
return res;
}

Did we get that right? Who will free() the string returned from cat()?