Title: Editorial

Early in 2003 we announced plans to award prizes (as well as fame) to the authors of the best articles in ACCU’s journals during the year. Now that 2003 is over, it’s time to determine which articles those are. Do you have opinions? (Who am I kidding – all programmers are overflowing with opinions...) Make them known to <cvu@accu.org>

It’s no secret that the declaration syntax of C and C++ is more complex than that of most other languages, and not only because it prefers symbols such as * and [] to more verbose Pascal-like notation such as POINTER TO or ARRAY OF.

Interestingly, this declaration syntax was something of an experiment, the idea being that declaring a name would look like its use. For example, derefencing the third pointer in an array looks like *array[3], so declaring it looks like element_type * array[3]. A neat idea, but in an interview available from his website^[1] Bjarne Stroustrup is quoted as saying that it is an “experiment that failed”.

I introduce this here not to discuss the pros and cons of the syntax of these languages we know and love, but as an illustration of a question I find important: how much should a competent professional know of the syntax of the programming languages in which they claim competence? In particular, if these questions arise in a job interview, how much can the interviewee reasonably be expected or required to know? How much does it matter, for example, if they can describe the exact meanings of

int * const p;
int const * q;

and

const int * r;

The answer, of course, is that it depends. A different level of accuracy might be expected for a junior position than if the interview is intended to find a mentor for other programmers’ language knowledge. It’s also fair to expect more from a candidate who describes him or herself as an expert in the use of C or C++. To echo part of a conversation recently revisited on accu-general, any programmer bold enough to claim their knowledge of (say) C++ is rated at 10 out of 10, meaning that they know everything about the language, shows that they don’t have enough awareness of what they don’t know, and might well be dangerous through not exercising enough caution.

More important than being able to parse bool (*(*p)[10])(int,int); in your head is knowing that you shouldn’t write such monstrosities when typedefs can simplify them so effectively, or knowing that should you ever need to figure out such a beast there is a widely available program by the name of cdecl^[2] that can translate many of them to English for you.

To take the example above:

$ ./cdecl
Type ‘help’ or ‘?’ for help
cdecl> explain bool
(*(*p)[10])(int,int);
declare p as pointer to array
10 of pointer to function
(int, int) returning bool
cdecl> thank you
syntax error
cdecl> quit

Now to get back to my topic – what should an interviewee know to become a valuable part of a development team? They must know how to learn new systems and tools, how to work with existing code, and how to work with other team members. Next, they should have enough immediately applicable knowledge that they can increase the team’s productivity without too much of a delay. And finally, more important than how much a developer knows is how aware they are of the limitations of their own knowledge, and how much they care to continue learning.

After reaching a certain level of familiarity or expertise with C or C++, it is common for programmers to find that there are certain features they would like to add to the language. (Some of us would also like to remove features, but that’s a tale for another time.) After deciding on the functionality that is to be added, its syntax must be considered. At this stage it is often natural to suggest using a new keyword; after all, that is likely to give the most explicit notation.

Getting a proposal requiring the addition of new keywords past the ISO standards committees, however, is not an easy task. The cost of adding new keywords weighs heavily on the minds of committee members. What costs are these? – surely any new feature has these costs in terms of compiler vendors implementing it, testing it, documenting it, and maintaining it, and users being educated in its use.

The additional cost of keywords is that they are likely to “break existing code”, and that is a big no-no. As the rationale to the 1989 C standard said: existing implementations of the language are viewed as less important than code written to use the language. That makes sense: there are maybe dozens (at most, hundreds) of implementations of C and C++ combined, but there are literally millions of programs written using the languages, totalling many billions of lines of code. Somewhere in those billions of lines of code, almost any proposed keyword is likely to have been used as an identifier, and because C and C++ reserve their keywords in all contexts, those programs would become invalid when such a new keyword was added. The C committee was very conservative when C was revised in 1999, ten years after its original standardization by ANSI, but a persuasive case was made to introduce the new keyword restrict (to grant C compilers the license to assume function arguments are alias-free, an assumption Fortran compilers have long been able to make, and one of the reasons why Fortran has continued to out-perform C in much of scientific computing).

It happens that as I was preparing this editorial I came across an example of a program using restrict as an identifier: cdecl-2.5. So, have a little sympathy for the resistance to new keywords, and maybe even for the merciless overloading of existing keywords. I won’t be surprised to see C++0x giving additional meanings to the keywords explicit and typename, and maybe even default. Any guesses what they might be?

By the time you read this, bookings for the ACCU Spring Conference 2004 should have opened. Details can be found on the centre four pages of this C Vu issue – they are also online at https://www.accu.org/conference/. It truly is an exceptional conference. If anyone knows of any event offering comparable value on this side of the pond, I would love to know of it. To risk one cliché: if you can make it to one technical conference this year, this is the one. I hope to make it back to the UK for the next one.