Skip to content

Generic Makefiles with GCC and GNU Make – Part 2

Introduction

In the previous article on this subject (which you should read first) I looked at how to go about creating a simple generic makefile for a C++ project which allowed you to add source files to the project without modifying the makefile, and which generated dependency information for you automatically. In this article I look at expanding this makefile to work with multiple directories. Makefile sources, and example C++ projects,  can be found here, in the srcinc subdirectory.

Motivation

The simple makefile presented in the previous article wound up putting all the C++ source files and header files in a single directory together with the .o and .d intermediate compiler-produced files, and the final executables.  This organisation (or lack of it) is viable for small projects but quickly becomes hard to navigate and manage for larger ones. It’s better to split things into different directories based on the different file types – the organisation I routinely use for medium-sized C++ projects looks like this, using the program presented previously as an exemplar:

srcinc
    bin
        rollem.exe
    inc
        dice.h
        report.h
    obj
        dice.d
        dice.o
        main.d
        main.o
    src
        dice.cpp
        main.cpp
    makefile

The srcinc directory is the project root (in a real project I would probably give it the same name as the executable) and contains the makefile that builds the project. The bin directory contains the final executable program the compiler (controlled by the makefile) produces.. The source files are placed in the src directory, and the headers they #include are placed in inc.  The compile-produced intermediate .o and .d files are created by the compiler in the obj directory. From the compiler’s point of view, there’s nothing  magical about any of these names – you could call them whatever you like.

Changing the makefile

The key changes we need to make to the makefile to use this directory structure are to the rules that build the .o and the .d files. The previous makefile featured rules like this:

%.o: %.cpp
    $(CXX) $(CXXFLAGS) $(INCDIRS) -c $< -o $@

To work with different directories, we need to change the rules to say things like “to build a .o file in the obj directory, you need to compile the C++ file in the src directory”. Here’s a slightly cut down version of the new makefile:

PRODUCT := rollem.exe 
BINDIR := bin 
INCDIR := inc 
SRCDIR := src 
OBJDIR := obj 

CXX := g++ 
LINKER := g++ 
INCDIRS := -I$(INCDIR) 
CXXFLAGS := -std=c++11 -Wall -Wextra
 
SRCFILES := $(wildcard $(SRCDIR)/*.cpp) 
OBJFILES := $(patsubst $(SRCDIR)/%.cpp,$(OBJDIR)/%.o,$(SRCFILES)) 
DEPFILES := $(patsubst $(SRCDIR)/%.cpp,$(OBJDIR)/%.d,$(SRCFILES)) 

$(BINDIR)/$(PRODUCT): $(OBJFILES) 
    $(LINKER) $(CXXFLAGS) $^ -o $@ 

$(OBJDIR)/%.o: $(SRCDIR)/%.cpp 
    $(CXX) $(CXXFLAGS) $(INCDIRS) -c $< -o $@ 

$(OBJDIR)/%.d: $(SRCDIR)/%.cpp 
    $(CXX) $(INCDIRS) -MM $< \
      | sed -e 's%^%$@ %' -e 's% % $(OBJDIR)/%'\ > $@

-include $(DEPFILES)

The first thing the makefile does is to specify the directory names for the project:

BINDIR := bin
INCDIR := inc
SRCDIR := src
OBJDIR := obj

As I said earlier, these names are not significant to the compiler, and can be changed to your own personal preferences.

The C++ compiler options are the same as those for the original makefile, with one exception:

INCDIRS := -I$(INCDIR)

which specifies that the compiler should look in the inc directory for user-written header files. The generation of lists of project filenames is also similar to the original:

SRCFILES := $(wildcard $(SRCDIR)/*.cpp) 
OBJFILES := $(patsubst $(SRCDIR)/%.cpp,$(OBJDIR)/%.o,$(SRCFILES))
DEPFILES := $(patsubst $(SRCDIR)/%.cpp,$(OBJDIR)/%.d,$(SRCFILES))

except that the generated filenames are preceded by directories in which we are going to locate the files – the C++ .cpp sources going in the src directory, and the compiler-generated .o and .d files in the obj directory.

The rule to build the final executable says to output the executable file in the bin directory:

$(BINDIR)/$(PRODUCT): $(OBJFILES)
    $(LINKER) $(CXXFLAGS) $^ $(LIBS) -o $@

The rule for building object files now looks like this:

$(OBJDIR)/%.o: $(SRCDIR)/%.cpp
    $(CXX) $(CXXFLAGS) $(INCDIRS) -c $< -o $@

This says that the .o files in the obj directory are dependent on the .cpp files in the src directory, and specifies how to use the C++ compiler to build them.

The last (and most complex) rule needs to specify how to build the .d files containing the dependency information generated for us by GCC. This needs to change the lines that GCC produces which look like this:

main.o: src/main.cpp inc/dice.h inc/report.h

into lines that look like this:

obj/main.d obj/main.o: src/main.cpp inc/dice.h inc/report.h

Once again, we use the sed stream editor to perform this conversion:

$(OBJDIR)/%.d: $(SRCDIR)/%.cpp
    $(CXX) $(INCDIRS) -MM $< \
      | sed -e 's%^%$@ %' -e 's% % $(OBJDIR)/%'\
      > $@

There are a couple of things to note here – the backslashes are used to escape end-of-lines in the rule so that the compiler/sed invocation is seen by the shell as being all on one line. The ‘%’ characters are used as delimiters in the sed search-and-replace expressions because forward-slashes, which you would normally use, are needed to specify the directory paths.

Finally, we need to include the dependency files we generated:

-include $(DEPFILES)

and we are done! You can now add .cpp files to the src directory, and headers to inc, and running  make will automatically pick them up and build the object files and executable for you.

Conclusion

This article has demonstrated how to use a makefile in a project which has been split up into sub-directories. In  a future article I’ll demonstrate how to modify this makefile to build debug and release versions of the product.

Generic Makefiles with GCC and GNU Make

Introduction

This article looks at the dependency generation feature of the GCC compiler and its use with GNU Make to create generic makefiles which do not require maintenance as a project grows. Sample makefiles and C++ projects using them are provided on Bitbucket. The projects were created and tested using TDM GCC and MSYS on Windows, but should also work on Linux. You will need to have some familiarity of the C and C++ separate compilation model in order to fully understand the article – I have a few articles on this beginning here.

Make 101

Here, I’m going to give a brief introduction to the GNU Make utility. You are strongly advised to also read the excellent documentation for GNU Make.

Make is a program for building things from separate components. The things built are often executable programs, but they don’t have to be. For example, at a training company I used to work for we used Make to construct our courseware documentation from typesetting instructions in troff files, images, program code and various other sources.

Make is controlled by a makefile, which is a text file (usually named “makefile”) containing a number of rules which specify how to build the product(s) we are interested in. Each rule looks something like this:

to-build-this : from-these
    do-this

where “to-build-this” is the name of the component we are trying to build (such as an executable, a library, or an object code file) and “from-these” is a list of files from which the component will be built (in a C or C++ project these would be source and header files); the component we are trying to build is said to be dependent on these files- if any of them change the component needs to be re-built. Handling these dependencies is the basic task that Make performs for us. The component name and the dependency list are separated by a colon.

The third element of a Make rule is the command that will be used to make the component. This command must be indented from the other elements using a TAB character (using spaces will result in strange error messages from Make) and will usually be something like a compiler or linker command line. You can actually specify any number of commands – all must be indented using spaces. The command is invoked if any dependent file has a modification date later than that of the component being built, or if the component does not exist.

Here’s a simple example of a rule:

myprog.exe : main.cpp utils.cpp utils.h
    g++ –g main.cpp utils.cpp –o myprog.exe

which says that the executable called myprog.exe is dependent on the source files main.cpp and utils.cpp, and the header file utils.h – if any of these files change, then make should rebuild the executable using the supplied g++ command line.With that rule in place in a makefile, we can build myprog.exe simply by typing make at the command line prompt.

GCC Dependency Generation

Unfortunately, although manually editing the makefile is do-able for small projects, as the project increases in size this becomes harder and harder, as source files include headers, which include other headers, and so on. It would be nice to have a utility which looked up the #include directives that cause the dependencies for us, and in fact there is such a tool – the GNU GCC compiler collection.

Given the example files above we can run GCC on the .cpp files like this:

$ g++ -MM *.cpp
main.o: main.cpp utils.h
utils.o: utils.cpp utils.h

The use of the –MM option tells GCC to read the input source files and extract the dependency information from the #include directives. The dependency information is then written to standard output. Notice there is no command specified, only dependency information. When make sees lines like this, it then knows what a product is dependent on, but doesn’t know how to build the product from the dependencies.

A Generic Makefile

Now that we have a means of automatically producing dependency information, we need to write a generic makefile that can use it. The makefile I present here is for the simple project on Bitbucket where all the source (two .cpp files and two .h files – take a look at the project to fully understand what follows) and compiler-generated files are contained in the same directory. The makefile in the project Mercurial tree  is also pretty simple (though slightly more complicated than this tutorial example), and is quite heavily commented – here it is without the comments, and slightly simplified (but still functional):

PRODUCT := rollem.exe

CXX := g++
LINKER := g++
INCDIRS := -I.
CXXFLAGS := -std=c++11 -Wall -Wextra

SRCFILES := $(wildcard *.cpp) 
OBJFILES := $(patsubst %.cpp,%.o,$(SRCFILES))
DEPFILES := $(patsubst %.cpp,%.d,$(SRCFILES))

$(PRODUCT): $(OBJFILES)
    $(LINKER) $^ -o $@

%.o: %.cpp
    $(CXX) $(CXXFLAGS) $(INCDIRS) -c $< -o $@

%.d: %.cpp
    $(CXX) $(INCDIRS) -MM $< > $@

-include $(DEPFILES)

I’ll now go over the makefile’s contents in some detail. The first part sets up a bunch of Make variables, which traditionally are spelled in upper-case. Here:

PRODUCT := rollem.exe

we set up a variable PRODUCT which contains the name of the final executable the makefile is going to produce. The next section sets up some compiler options:

CXX := g++
LINKER := g++
INCDIRS := -I.
CXXFLAGS := -std=c++11 -Wall -Wextra

The CXX and LINKER variables say which C++ compiler and linker to use – in this simple example  we will use the g++ driver program to perform both tasks. The INCDIRS variable will be used to say where the  compiler should look for #included header files (the current directory, in this case), and CXXFLAGS specifies some standard C++ compiler options.

The next section is a bit more interesting – it uses some of Make’s built-in functions to build lists of files we are interested in. Here:

SRCFILES := $(wildcard *.cpp)

we use the wildcard function (a bit like the ls or dir commands) to generate a list of all files which end with the .cpp extension (extensions are called suffixes in Make-speak) and assigns the list to the SRCFILES variable. The $( … ) syntax is used in Make to both call functions and to fetch the contents of a variable. So, we now have a list of our C++ source files. Next:

OBJFILES := $(patsubst %.cpp,%.o,$(SRCFILES))

we use the patsubst (it stands for “pattern substitution” – a bit like the sed command) function to generate a list of object files from the list of source files we just created by replacing all .cpp suffixes with .o.

The last list of files we need is one containing the names of files that will contain the dependency information we are going to create using the –MM option of GCC, as described in the previous section. One such file will be generated for each .cpp file.

The creation of these file lists, and of the other variables, will always be performed whenever Make is run on this makefile. The next section of the file contains the rules that will be used to build the various components – these will only run if directly invoked, or when dependent files have changed. The first rule:

$(PRODUCT): $(OBJFILES)
    $(LINKER) $^ -o $@

This rule (because it is the first rule in the makefile, it is the default rule, invoked when you simply type make at the command line prompt) says that the product we are trying to produce is dependent on the files in the list OBJFILES. It also says that to build the product Make needs to invoke the LINKER (i.e. g++) command. The special symbols $^ and $@ are special Make variables – the first evaluates to the list of dependencies, and the second to the name of the product. So, what this rule expands to when variable contents are used is:

rollem.exe: main.o dice.o
    g++ main.o dice.o -o rollem.exe

and will be invoked if either of main.o or dice.o is newer than rollem.exe, or if rollem.exe does not exist.

The next two rules use wild-carding to specify how to build the object and dependency files. This rule:

%.o: %.cpp
    $(CXX) $(CXXFLAGS) $(INCDIRS) -c $< -o $@

says to Make – “A file with a .o suffix is dependent on a file with the same name, but with a .cpp suffix, and here’s how you build one from the other”. This rule will be applied following the first rule if either main.o or dice.o needs to be re-built. With variable expansion, the command to do the re-build will be (for main.o):

g++ -std=c++11 -Wall -Wextra -I. -c main.cpp -o main.o

The last rule says how to use the –MM option of GCC to generate the .d dependency files. Here’s the command it produces (for main.d):

g++ -I. -MM main.cpp > main.d

Here we use shell indirection to write the output the –MM option to a file. This generates a .d dependency files which looks like this:

main.o: main.cpp dice.h report.h

which says that main.o is dependent on main.cpp, dice.h and report.h. A similar .d file is generated for the dice.cpp source file.

The last bit of the makefile is probably hardest to understand. It looks like this:

-include $(DEPFILES)

which should pull in the .d files, much like #include works in a C or C++ program. However, this isn’t exactly what happens. If the .d files already exist, then they are simply included in the makefile, and Make reads the dependency information from them. However, if they don’t exist (as they won’t the first time Make is run using this makefile) Make will look to see if there is a rule to create them. There is (the last rule) so Make runs the command associated with that rule to create the .d files and then re-reads the whole makefile. This time the .d files do exist (because we just created them), so they are read by the simple include mechanism.

Running Make

Phew! That’s quite a lot to take in (and it took me some time to get the makefile right when I first started working on this article). Let’s see what happens when we run the makefile for the very first time:

$ make
g++ -I. -MM main.cpp > main.d
g++ -I. -MM dice.cpp > dice.d
g++ -std=c++11 -Wall -Wextra -I. -c dice.cpp -o dice.o
g++ -std=c++11 -Wall -Wextra -I. -c main.cpp -o main.o
g++ dice.o main.o -o rollem.exe

You can see that the dependency information files are generated, then the .cpp files are compiled to .o files, and finally the .o files are linked to create the executable. Notice that none of the names of the .d, or .cpp files are explicitly mentioned in the makefile.

Now, let’s run Make again:

$ make
make: `rollem.exe' is up to date.

Make sees that nothing has changed, so there is nothing to do. Now let’s touch one of the .cpp files (touch changes the modification date on the file) and run Make again:

$ touch dice.cpp
$ make
g++ -I. -MM dice.cpp > dice.d
g++ -std=c++11 -Wall -Wextra -I. -c dice.cpp -o dice.o
g++ dice.o main.o -o rollem.exe

Make has to re-build both the dice.d dependency file, the dice.o file and the executable. However, it does not rebuild main.d or main.o.

Now, let’s touch one of the headers:

$ touch dice.h
$ make
g++ -std=c++11 -Wall -Wextra -I. -c dice.cpp -o dice.o
g++ -std=c++11 -Wall -Wextra -I. -c main.cpp -o main.o
g++ dice.o main.o -o rollem.exe

Both of the .cpp files need to be re-compiled as both contain #includes referencing the dice.h header file. However, the dependency files are not re-built, and this is a problem, which I address below.

Lastly, let’s create a new .cpp file:

$ touch foobar.cpp
$ make
g++ -I. -MM foobar.cpp > foobar.d
g++ -std=c++11 -Wall -Wextra -I. -c foobar.cpp -o foobar.o
g++ dice.o foobar.o main.o  -o rollem.exe

The new .cpp is recognised, dependency information is generated, and the file is correctly compiled and linked, all without the makefile needing to be changed in any way.

Forcing Dependency Generation

The rules the makefile contains so far will force regeneration of the .d files if the corresponding .cpp file is changed. For simple projects, this will work 90% of the time, but we would really like the .d file for a given .cpp file to be re-built if any of the dependencies of the specific .cpp file change – for example, if we add a #include directive to a header file, we have created a new dependency on the newly-included header, and we would like the dependencies to be updated to reflect that. In other words, instead of:

main.o: main.cpp dice.h report.h

we need to produce;

main.d main.o: main.cpp dice.h report.h

and the same for the dice.* files.

Neither Make nor GCC provide a simple, built-in way of doing this, so we need to resort to one of the other command line tools, the sed stream editor. I don’t propose to give a sed tutorial here, but what we need to do is to change the rule for generating .d files to:

%.d: %.cpp
    $(CXX) $(INCDIRS) -MM $< | sed 's/^/$@ /' > $@

which uses sed to edit the dependency to begin with whatever %.d actually is when the makefile is run, which will be the name of the .d file we are generating. With this rule in place, whenever we add a dependency to existing dependencies, the .d file files will be automatically updated with the new dependency information when we run Make.

Conclusion

This article has presented a simple generic makefile which can be used to build multi-file C++ projects, with dependency information being provided by the GCC compiler rather than being hard-coded (possibly incorrectly) in the makefile by the developer. In a future article I’ll look at how this makefile can be expanded to work with multi-directory projects and with debug and release builds of the product(s) being developed.

Common C++ Error Messages #2 – Undefined reference

Introduction

In this article I’ll be looking at the “undefined reference” error message (or “unresolved external symbol, for Visual C++ users). This is not actually a message from the compiler, but is emitted by the linker, so the first thing to do is to understand what the linker is, and what it does.

Linker 101

To understand the linker, you have to understand how C++ programs are built. For all but the very simplest programs, the program is composed of multiple C++ source files (also known as “translation units”). These are compiled separately, using the C++ compiler, to produce object code files (files with a .o or a .obj extension) which contain machine code. Each object code file knows nothing about the others, so if you call a function from one object file that exists in another, the compiler cannot provide the address of the called function.

This is where the the linker comes in. Once all the object files have been produced, the linker looks at them and works out what the final addresses of functions in the executable will be. It then patches up the addresses the compiler could not provide. It does the same for any libraries (.a and .lib files) you may be using. And finally it writes the executable file out to disk.

The linker is normally a separate program from the compiler (for example, the GCC linker is called ld) but will normally be called for you when you use your compiler suite’s driver program (so the GCC driver g++ will call ld for you).

Traditionally, linker technology has lagged behind compilers, mostly because it’s generally more fun to build a compiler than to build a linker. And linkers do not necessarily have access to the source code for the object files they are linking. Put together, you get a situation where linker errors, and the reasons for them, can be cryptic in the extreme.

Undefined reference

Put simply, the “undefined reference”  error means you have a reference (nothing to do with the C++ reference type) to a name (function, variable, constant etc.) in your program that the linker cannot find a definition for when it looks through all the object files and libraries that make up your project. There are any number of reasons why it can’t find the definition – we’ll look at the commonest ones now.

No Definition

Probably the most common reason for unresolved reference errors is that you simply have not defined the thing you are referencing. This code illustrates the problem:

int foo();

int main() {
    foo();
}

Here, we have a declaration of the function foo(), which we call in main(),  but no definition. So we get the error (slightly edited for clarity):

a.cpp:(.text+0xc): undefined reference to `foo()'
error: ld returned 1 exit status

The way to fix it is to provide the definition:

int foo();

int main() {
    foo();
}

int foo() {
    return 42;
}

 

Wrong Definition

Another common error is to provide a definition that does not match up with declaration (or vice versa). For example, if the code above we had provided a definition of foo() that looked like this:

int foo(int n) {
    return n;
}

then we would still get an error from the linker because the signatures (name, plus parameter list types) of the declaration and definition don’t match, so the definition actually defines a completely different function from the one in the declaration. To avoid this problem, take some care when writing declarations and definitions, and remember that things like references, pointers and const all count towards making a function signature unique.

Didn’t Link Object File

This is another common problem. Suppose you have two C++ source files:

// f1.cpp
int foo();

int main() {
    foo();
}

and:

// f2.cpp
int foo() {
    return 42;
}

If you compile f1.cpp on its own you get this:

f1.cpp:(.text+0xc): undefined reference to `foo()'

and if you compile f2.cpp on its own, you get this even more frightening one:

crt0_c.c:(.text.startup+0x39): undefined reference to `WinMain@16

In this situation, you need to compile both the the source files on the same command line, for example, using GCC:

$ g++ f1.cpp f2.cpp -o myprog

or if you have compiled them separately down to object files:

$ g++ f1.o f2.o -o myprog

For further information on compiling and linking multiple files in C++, particularly with GCC, please see my series of three blog articles starting here.

 

Wrong Project Type

The linker error regarding WinMain  above can occur in a number of situations, particularly when you are using a C++ IDE such as CodeBlocks or Visual Studio. These IDEs offer you a number of project types such as “Windows Application” and “Console Application”. If you want to write a program that has a int main() function in it, always make sure that you choose “Console Application”, otherwise the IDE may configure the linker to expect to find a WinMain() function instead.

No Library

To understand this issue, remember that a header file (.h) is not a library. The linker neither knows nor cares about header files – it cares about .a and .lib files. So if you get a linker error regarding a name that is in a library you are using, it is almost certainly because you have not linked with that library. To perform the linkage, if you are using an IDE you can normally simply add the library to your project, if using the command line, once again please see my series of blog articles on the GCC command line starting here, which describes some other linker issues you may have.

Conclusion

The unresolved reference error can have many causes, far from all of which have been described here. But it’s not magic – like all errors it means that you have done something wrong, in you code and/or your project’s configuration, and you need to take some time to sit down, think logically, and figure out what.

My C++ Interview Questions

Introduction

Over the years, I’ve done my share (more, it has often seemed) of interviewing candidates for C++ programming posts. During this time I’ve zeroed in on a small subset of questions I ask candidates. These have no correct answers, do not refer to manhole covers, and require no maths ability to answer. They have, however, proved effective in deciding if the candidate actually has some knowledge of C++. I present them for your delectation.

“Tell me about the copy constructor”

This is my start-off question. If people look blank when I ask it (and depressingly, lots do), then I write out the signature of the constructor for them. If they still look blank, the interview terminates – this has saved me a lot of time over the years.

What I’m looking for here is someone that knows how important copying is in C++, where it takes place, and how it can be avoided. I’d expect a decent C++ programmer to be able to talk for around 15 minutes on this, with me asking subsidiary questions.

“What are your favourite C++ books? And why are they your favourites?”

C++ is a very complex language, and to learn it thoroughly you simply have to read several good books – internet resources will not be enough. I don’t particularly care which books the candidate talks about, providing there is more than one of them, and they can come up with some convincing reasons for liking them.

“Write a program to…”

I’m not a big fan of getting candidates to write code in interviews. Often, the problem they are asked to solve is too small to prove anything, and they are unfamiliar with the setup on your specific workstations, so you are really testing how quickly they can get to grips with a toolset. However, sometimes HR or senior management will insist on a coding test. If that’s the case, then I set this problem, or something very like it, which tests the candidate’s familiarity with the C++ Standard Library in several ways:

Write a program that can be called from a command line environment like this:

myprog.bible.txt

The file bible.txt, which is provided, contains the text of the King James Bible. Your program should read this file and output the 10 most frequently occurring words, together with their frequency,  ignoring any punctuation and character case. Use the style of coding, commenting etc. that you would for a large program.

As with the other questions here, I’m not particularly interested in the details of the solution, provided they show a knowledge of Standard Library classes like strings and maps, and that the program actually works.

“What do you think the three most important features of C++11 are?”

Or similar – if the candidate has professed a knowledge of a library like Boost, I might ask about that instead. Once again, I don’t particularly care what the candidate thinks are important, only that they can talk about them articulately and knowledgably.

“If you were interviewing me, what question would you ask me”

This one is down to a guy I worked with at the now defunct Lehman Brothers (thank you, Mr James). He interviewed me, and after a couple of  questions said, “Well, you obviously know a lot more about C++ than I do, so tell me, if you were interviewing me, what questions would you ask?” I thought that was brilliant at the time, and still do – use it if you are interviewing a self-styled guru. Of course, you have to ask them why they would ask that question!

Conclusion

From the above, I think you can see that you do not have to ask candidates trick questions, or puzzles about manhole covers. Instead, you should be trying to get them to talk at length about their knowledge of the C++language and how it can and should be used.

Languages A-Z Challenge

I was futzing around with my CV today, and this question suddenly occurred to me:

Do I know a language for each letter of the alphabet?

And it turns out, no I don’t. here’s my best shot of an alphabetic  list of languages I do know reasonably well, and have been paid for writing programs in:

  • Awk
  • BASIC
  • COBOL
  • dBase II
  • E??????
  • FORTH
  • Gupta SQLWindows
  • H??????
  • IBM JCL
  • Java
  • K??????
  • Lahey FORTRAN
  • MASM
  • Nomad/2
  • Object Pascal
  • PHP
  • Quick C
  • Rexx
  • SeaChange
  • Transact SQL
  • U??????
  • Visual C++
  • W??????
  • X??????
  • Yacc
  • Z80 Assembler

The ?????? entries are ones I can’t provide.

Obviously, I know more languages than are listed here (many beginning with the letter C). The challenge I lay down is to produce a 26-element list of languages  given these rules:

  • You must have been paid for writing code in the language. For example, I have programmed in Haskell (which would give me the H entry), but nobody has ever paid me to do so.
  • You can use specific implementation names (like Visual C++), but a language (C++)  must be appear  only once in the list.

A small no-prize of  golden NULL pointer will be awarded for anyone that convincingly comes up with a 26 element list!