My archetypal reader programs in both languages. Because of legacy code, safety issues, and so on, such readers must still code in C; however, to keep current, they must also program in C++. This column helps balance these opposing time demands, taking advantage of language similarities whenever possible. Another column motif is "helping C programmers on their terms."

I have no intention of abandoning C, and will favor those aspects of C++ most like C. I find explaining C++ language and design concepts in C terms genuinely helps C programmers understand this new and at times daunting world.

I also find C++ programmers become seduced early on by the Siren songs of polymorphism, overloading, and the like, without truly mastering the language's underlying C nature. So emphasizing C++'s dominant C gene, I believe, benefits programmers of either language.

Informally, I have a four-fold charter, to wit:

• Bolster fundamental knowledge of both languages, for newcomers as well as more experienced programmers.
• Help you design C code that can migrate relatively easily to C++.
• Nudge programmers, who have hit a wall in C, over that wall to C++.
• As heretical as it may seem, offer reasons against migration to C++.

To start that teaching, I'll spend the first two columns reviewing some basic vocabulary, addressing practical issues you will encounter as a programmer. The C and C++ language standards define vocabulary for these issues; my colleagues and I will be using this vocabulary. This includes terms you've probably seen but may not be familiar with. I also define some personal nomenclature that should make future discussions simpler.

Anyone living with children recognizes this pattern of questioning: every definition you give introduces yet another thing requiring definition. There is no absolute end; after a time, one party gives up, deciding the definitions are enough. The question of how much terminology is enough — that is, the point at which all parties can say "we agree" — is a serious one for program language design and specification. The C++ committees have spent years seeking a balance between defining the language completely enough for compiler writers to implement it, and succinctly enough for programmers to compose in it. To find that balance, the committee members must somehow measure just how complete or precise a particular definition is.

int a[10];

a[10] = 1;

• undefined
• unspecified
• implementation-defined
• locale-specific

I summarize each behavior below, giving examples in the text and in the code listings.

#include <limits.h>
void f(void)
    {
    int x = INT_MAX;  /* largest signed int */
    x++;
    }

• INT_MIN(wrap-around with overflow ignored)
• INT_MAX (original value unchanged)
• zero
• random
• no value — the program terminates

Undefined behavior — behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately valued objects, for which the standard imposes no requirements. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating translation or execution (with the issuance of a diagnostic message).

Uh, right. Well, that's a little turgid, so let's try the Rationale:

Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose.

void f(int a, int b);

int n = 0;
f(n++, n+1);

Your temptation may be to say a gets 0 (the value of n before ++ is evaluated) and b gets 2 (the value of n after both ++ and +1). Your answer assumes the compiler evaluates function arguments left-to-right. But in fact, the compiler may also choose to evaluate the arguments right-to-left, resulting in a still getting 0, but b getting 1. I suppose an implementation could use a random-number generator to determine the order, so that the same program could behave differently between successive runs. While this may seem far-fetched, the rise of parallel-processing architectures presents the possibility of such behavior. The order of function-argument evaluation is an example of unspecified behavior. Unspecified and undefined behaviors are much alike, with one key difference: While undefined behavior may result from erroneous C constructs, unspecified behavior arises from a correct program using correct data. Your program is right — you are just using some of those fuzzy (but correct) areas of the language.

Unspecified behavior gives the implementor less latitude than does undefined behavior. In particular, the implementation must translate the program — that is, it must catch the questionable behavior. Your program will compile and run, although you may not know exactly how it will behave. Although unspecified behavior is safer than undefined behavior — after all, your program is valid C — you still don't know which correct behavior will happen.

int b = -1; /* or 0xFFFF */

b >> 1;

islower('A');

islower('a');

islower('');

islower('\xAB);

Locale-specific behavior — behavior that depends on local conventions of nationality, culture, and language that each implementation shall document.

In the examples above, the result of islower for anything other than the minimal C character set is locale-specific. Such behavior is much like implementation-defined behavior, with a key difference: a strictly conforming program (described below) can use locale-specific features, thereby ruining such programs' chances of being unambiguously portable.

• a conforming implementation is defined to accept any conforming program (with possibly some limitation on that program's use of standard library features).
• a conforming program is defined as any acceptable to a conforming implementation.

Happily, the standard rescues us with the notion of a strictly conforming program. More restrictive than a conforming program, a strictly conforming program uses only those parts of the language that the Standard fully defines and specifies. Such a program cannot use undefined, unspecified, or implementation defined behavior; nor can the program exceed minimum guaranteed implementation limits. The goal of strictly conforming programs is portability. Such programs generally behave the same on all conforming implementations, within the bounds of those behaviors the Standard specifies.

However, even this guarantee of portability is not iron-clad, for such programs can have different behaviors depending on locale, and conforming implementations can define their own locale-specific behavior. Moral: There is no such thing as a completely portable C program. As a rule, when I discuss Standard C, I am assuming language features contained in a strictly conforming program translated by a conforming implementation. That way, I know we are all singing from the same hymnal.

Instead, C++ introduces the concept of a program being well formed, that is, a program conforming to the syntax and semantic rules of C++. But to me, this all implies 1) these rules are deterministic and complete, and 2) an implementation can tell when a program is well formed, all of which makes me wonder what those rules have achieved. It looks as if the committees still believe in strict conformance in their hearts, if not in their minds. I guess that looking down and seeing one or two turtles beneath them provides enough comfort. The abandonment of conformance affects C++'s notion of portability. C++ still uses C's terms (undefined behavior, unspecified behavior, and so on); however, rather than finding a theoretical foundation for such terms, the C++ Standard cites specific examples of each type of portability. In the end, while conformance and portability do not have the same official hold in C++ as they do in C, they are nonetheless useful concepts for discussion, and I will apply them freely to both languages. What may be impossible for language implementors to achieve in principle is still useful for language users in practice.

extern int errno;
char const string[] = "Doug Payne";
static struct s *p;

• An object that can be referenced by multiple declarations, even declarations in different translation units, has external linkage.
• An object that can be referenced by multiple declarations in the same translation unit has internal linkage.
• An object that can be declared only once has no linkage.

• dynamic duration — the object is born and dies as execution enters and leaves the object's scope, typically living on the stack or in a machine register. Dynamic duration is explicitly indicated by keywords auto and register.
• static duration — the object lives the entire time the program lives, typically in a dedicated static memory location. Static duration is explicitly indicated by keywords extern and static. In a sense, static duration is an extreme case of dynamic duration that starts and stops with the program. Unfortunately, C uses the same keywords to specify both linkage and duration. Also unfortunately, the lack of any duration keyword has different implied meanings, depending on context.

char *f(void)
    {
    char c= 'a'; /* c has dynamic duration, and
                 probably lives on the stack */
    return &c; /* bad idea - returning pointer to
                storage that no longer exists after
                function returns */
    }

void main(void)
    {
    char *p;
    p = f();  /* p now contains a "random" address*/
    *p = 'b'; /* writing into invalid location
               all bets are off */
    }

static char c ='a';

A declaration specifies the interpretation and attributes of a set of identifiers. A declaration that also causes storage to be reserved for an object or function named by an identifier is a definition.

The C++ standard, paraphrased, says

A declaration introduces one or more names into a program and gives each name a meaning. A declaration is a definition unless it declares one of a cetain set of things (followed by a list of said things).

Note the difference: C considers definitions as exceptional declarations, while C++ considers declarations as exceptional definitions. I summarize these by saying a declaration "declares" or proclaims an object's existence and nature, while a definition also "defines," or creates and initializes, that object. Given all this, is the statement

int d;

• source language
• the object's scope, linkage, and duration
• whether the declaration initializes the object
• whether the object has been previously declared in a visible scope

• C programming inspired by C++, including OOP in C.
• moving you and your programs from C to C++, and porting issues you'll encounter along the way
• heuristics for choosing which language to use
• safe programming in either language

References