See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220703588

An Empirical Study of Function Overloading in C++

Conference Paper · September 2008

DOI: 10.1109/SCAM.2008.25 · Source: DBLP

CITATIONS READS
2 194

2 authors, including:

Daqing Hou
Clarkson University
83 PUBLICATIONS 1,143 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

advising how to best use an API View project

Inference of network structure from count data View project

All content following this page was uploaded by Daqing Hou on 21 May 2014.

The user has requested enhancement of the downloaded file.

 Eighth IEEE International Working Conference on Source Code Analysis and Manipulation

An Empirical Study of Function Overloading in C++

Cheng Wang and Daqing Hou

Clarkson University
Potsdam, NY USA 13699
[email protected]

Abstract of example code that demonstrate the use of a particular

language feature, it is challenging for the programmers to
The usefulness and usability of programming tools decide what features to learn that can solve their problems
(for example, languages, libraries, and frameworks) may at hand in the best possible way. It would be ideal if for each
greatly impact programmer productivity and software qual- language feature, there is a methodology defined that guides
ity. Ideally, these tools should be designed to be both useful the programmers on what kind of a problem the feature is
and usable. But in reality, there always exist some tools useful for and how to solve the problem properly with the
or features whose essential characteristics can be fully un- feature [11].
derstood only after they have been extensively used. The The formulation of such a methodology could be best
study described in this paper is focused on discovering how done by examining and reflecting on as much as possible
C++’s function overloading is used in production code us- empirical evidence from the serious use of the particular
ing an instrumented g++ compiler. Our principal finding language feature of interest. While language designers tend
for the system studied is that the most ‘advanced’ subset of to do their best in guiding their design process with practi-
function overloading tends to be defined in only a few utility cal experience and user feedback [2, 11, 14], not all design
modules, which are probably developed and maintained by decisions are, or can be, made based on solid empirical ev-
a small number of programmers, the majority of application idence. Sometimes, there simply is not a sufficient amount
modules use only the ‘easy’ subset of function overloading of experience available at the time a particular design de-
when overloading names, and most overloaded names are cision is made [14]. For sophisticated features like over-
used locally within rather than across module interfaces. loading and templates, while there is no doubt that such a
We recommend these as guidelines to software designers. feature as a whole is useful, its interactions with other fea-
tures can be numerous and the details can be subtle to pin
down. Sometimes, decisions can be made in an arbitrary
1 Introduction and ad hoc fashion, or based on particular requirements that
are controversial (for example, the decision for C++ to sup-
Programming languages are one of the many important port implicit narrowing in overloading resolution in order
tools that programmers use in their daily problem solving. to maintain compatibility with C). For all of these reasons,
With the ever increasing size and complexity of the prob- there is always a need to examine how language features are
lems tackled by computer software rises the sophistication actually used in the wild in order to understand the conse-
of programming tools. This is a bad news for the aver- quences of such decisions, to identify typical use cases of
age programmers because to do their jobs properly, they language features, and to develop guidelines.
must master their tools first, which will require more ef- One way to gather such empirical evidence is by ana-
fort when the tools grow bigger and become more complex. lyzing the source code of large-scale systems. We chose to
In particular, current programming languages are providing study the use of the compilation-time overloading feature
programmers with an increasingly large set of features to in C++ because it involves a large set of rules that many
support them in solving diverse problems. Consequently, programmers would not be confident with. Furthermore,
mastering a whole programming language demands serious C++ overloading interacts with many other features of the
investment on the part of the programmers. 1 While it is rel- language, for example, namespaces, inheritance, and tem-
atively easy to learn how to write and compile small pieces
some of the complexity to external libraries and APIs. However, we be-
1 Recognizingthis problem of increasing language scale, some lan- lieve that learning such a minimal language can still be a challenge for the
guage designers are trying to develop a minimal core language and shift average programmers.

978-0-7695-3353-7/08 $25.00 © 2008 IEEE 47

DOI 10.1109/SCAM.2008.25
class Y; ture. That is, given an expression that applies an overloaded
class X {
public: name, a compiler needs to choose a single candidate that
operator char() const {return ’a’;} best matches the expression (overloading resolution). The
void foo (int); //f1 compiler thus needs to implement a set of rules that govern
void foo (char);//f2
void foo (double);//f3
void foo (X);//f4 1. how to identify from the surrounding scopes of the ex-
void foo (Y&);//f5 pression the set of candidate operations with the same
}; name as what is used by the expression (candidate set),
class Y: public X { };
2. how to convert from argument types appearing in the
void foo (double); //f6 calling expression to the parameter types in the defini-
void foo (int);//f7 tion of a candidate operation and rank the conversions,
void bar(Y & aY){
//C={f6,f7}, V={f6,f7} best: 3. how to determine the set of operations to whose param-
//f7<cr promotion:ck std> eter types there exist feasible conversions from types in
foo(’c’); the expression (viable set), and
//C={f6,f7},V={f6,f7} best:
//f7 <cr user:ck user->ck std>
foo(aY); 4. how to determine the best candidate from the viable set
//C={f1...f5},V={f1,f2,f3} best: as the final result that the expression should be linked
//f2 <cr std:ck ptr,cr identity:ck identity> to. If no such candidate can be found, the process fails
aY.foo(’a’);
//C={f1...f5},V={f1...f5} best: and a compilation error is given to the programmer.
//f5 <cr std:ck ptr,cr identity:ck ref bind>
aY.foo(aY);} Table 1 summarizes the implicit type conversion rules
of C++. A rank on top of the table is considered better
than ones below it. Also note that a rank may contain sub-
Figure 1. Example of function overloading categories known as kind.
and the process of overloading resolution. C Figure 1 shows a simple example designed to illustrate
stands for candidate set and V for viable set. the process of overloading resolution in C++. For each
overloaded call in bar(), its candidate set and viable set,
plates. Thus we felt that overloading would be a complex the best candidate, and the conversion sequences from ar-
feature for which a methodology is needed to guide its use. guments to parameter s are given in the comment above the
There is also doubt on the usefulness of compilation-time call. For example, foo(’c’) has a candidate set that con-
overloading [11]. We hoped that our study could shed some tains f6 and f7. Its viable set also contains f6 and f7
light on this controversy as well. since there are conversions from char to both double
In order to gather data about the use of overloading in (for f6) and int (for f7). The conversion from char to
practical systems, the GNU g++ compiler 2 is modified and int has a rank of cr promotion and a kind of ck std.
used to compile a Mozilla browser. 3 In this paper, we ana- which is represented as <cr promotion:ck std> in
lyze the data and report our findings about the use of over- the comment. Note that in this example, foo(aY) has
loading in the Mozilla code base. Analysis of data extracted a conversion sequence of length 2, and the conversion se-
from another system (MySQL 4 ) is currently under way. quences of all other calls are of length 1.
The rest of this paper is organized as follows. Section 2 Overloading, when used appropriately, can increase pro-
provides a brief overview of C++ overloading. Section 3 gram readability and clarity [10]. Without this feature, it
describes the study method, how g++ is instrumented, and would be rather difficult to designate different but meaning-
what kind of data are gathered. Section 4 presents the re- ful names to the several foo’s in Figure 1 when the opera-
sults of our analysis. Section 5 presents related work. Sec- tions have similar behavior but different parameter types.
tion 6 concludes the paper and anticipates future work. On the other hand, the size of Table 1 indicates that C++
overloading rules are rather complex to understand. But this
2 Overloading in C++ is the result of a careful design that accommodates multiple
design requirements of C++ [14]. Each conversion rule has
a reason. For example, ck std results from the design de-
Overloading allows a single name to be used to repre- cision to maintain compatibility with C’s basic types and
sent more than one operation. It is a compile-time fea- conversions (narrowing), and ck ptr from the interaction
2 http://gcc.gnu.org/ with inheritance. cr user is designed to make it possi-
3 http://www.mozilla.org/ ble for user-defined types to be used in the same way as
4 www.mysql.com primitive types. In particular, with the addition of operator

48
 rank kind an overloading call among the candidates (for exam-
cr identity ck identity (two identical ple, by designing the candidates such that they have
types), ck lvalue (e.g., array to obviously different parameters).
pointer), ck rvalue (l-value to • When a name is going to be used many times by a
r-value), ck ref bind (from a client, since the benefit of using overloading may out-
type to reference to the type). weigh its cost, its use is justified.
cr exact ck qual (adds a qualifier like • User-defined conversion operators should be used only
const to the base type in a pointer when they are going to be used many times. Control
type). the scope of their use. Consider using explicit to
cr promotion safe conversion from shorter data prevent single-parameter constructors from being used
type to longer one (widening). inadvertently as type convertors.
cr std ck std (narrowing), ck ptr (con-
version to pointer to the most ‘de- But there are still questions to be answered: What is
rived’ base type), ck base (con- overloading used to achieve? How are the various over-
version to the most ‘derived’ base loading rules used in practice? How are user-defined con-
type), ck pmem (conversion to versions used? In the next sections, we try to answer these
pointer to member function). But a questions by studying the use of overloading in Mozilla.
conversion of ck std may be given
a rank of cr promotion if, for 3 Study Method
example, in a conversion from enum
to int of kind ck std, the integral To gather data for the use of overloading in large-scale
value of the enum is known to fall systems, we decided to instrument the GNU C++ compiler
within the range of int. g++ and use it to compile open-sourced software. Our first
cr pbool An rvalue of arithmetic, enumera- test case is Mozilla. In this section, we describe how g++
tion, pointer, or pointer to member is instrumented, the data schema for the data we extracted
type can be converted to an rvalue for the definition and use of function overloading. We also
of type bool. characterize the Mozilla code base.
cr user ck user (user-defined conversion,
either via a constructor or a type 3.1 Instrumenting g++
conversion operator).
cr ellipsis Conversion to ellipsis in target type. Internally, g++ uses a tree data structure to represent pro-
cr bad No conversion possible. gram elements and symbol tables. It also provides a rich set
of macros for traversing the tree structure and accessing at-
Table 1. C++’s implicit type conversion rules tributes of individual tree nodes.
as implemented by g++. The definitions of overloaded functions and operators are
obtained by hooking into the name resolution process of
g++. Specifically, when a new function is encountered, the
overloading, it becomes possible for a user-defined type to compiler will be able to conclude whether it is overloaded
work immediately with generic algorithms and data struc- with any other functions that it has seen previously. The fact
tures without change. that a function is overloaded is intercepted and the informa-
Some advanced overloading features, like operator over- tion about the group of overloaded functions is stored in a
loading and user-defined conversions, may hinder program data structure made by us.
understanding. For example, when resolving foo(aY), in In our data structure, a group of overloaded functions is
addition to knowing the type of aY and the existence of 2 identified by a fully qualified name, absolute paths for the
foo’s found in the global scope, a programmer also needs files where the overloaded functions appear (in rare cases,
to visit the body of class Y and class X. In extreme cases, overloaded functions may originate from different header
the resolution of an overloaded operator may even require files), and the path for the file where the group becomes
the visit of as many as 7 scopes [10]. effectively overloaded. After the compilation of a transla-
Given the above analysis, it appears reasonable to pro- tion unit is completed, the information about all overloaded
pose the following guidelines for the use of overloading. names that occur inside the translation unit is persisted, one
• If a name is going to be used only a few times by line per name, into a text file, which is given a name that is
a client, use overloading only if absolutely necessary distinct to the translation unit. For example, the following
and make it as easy as possible for the client to resolve line of text captures the fact that the global operator new

49
defined in the standard C++ header file new is included in module name description
a file named nsXFontNormal.cpp, and the operator is browser Mozilla web browser
overloaded 3 times. Fields are separated by the # sign. editor a.k.a composer
::operator new#/include/c++/4.2.0/new#nsXFontNormal.cpp#3 dom Document Object Model
js JavaScript
The calls of overloaded functions and operators are ob- xpfe cross-platform front end
tained by hooking into the type checking process where layout APIs for laying out UI
the type of an expression is resolved. 5 Specifically, given content modeling contents like HTML and XML
an expression like a function call, g++ will indicate which parser HTML parser
function or operator the expression should be linked to, and netwerk networking APIs
whether the function or operator is overloaded. If an over- gfx graphics APIs
loaded function is involved, the expression is resolved by widget
selecting from multiple candidates the one that matches the view
best by following the set of overloading rules of C++. A list
rdf Resource Description Framework
of implicit conversions is produced, which indicates how
nspr netscape portable runtime
the types of the arguments can be converted to the parame-
xpcom cross-platform component model
ter types in the function being linked to.
intl internationalization
For each overloading call, the following record is pro-
duced as a line in a text file:
• a fully qualified function name that the current expres- Table 3. A subset of Mozilla modules.
sion is resolved to, intl, and nspr make up the utility layer. Modules netwerk,
• absolute file path and line number where the winning widget, view, gfx, and rdf provide various systems ser-
function is defined, vices, with modules widget and view depending on gfx.
• absolute file path and line number where the function Modules content and parser handle documents like HTML
is called, files. Module layout sits on top of all of the above mod-
• candidate set size, ules. Module xpfe provides platform-portable implementa-
• viable set size, and tion for browser. Finally, the top-most layer contains mod-
• list of ranks, kinds, and from and to types for argument ules browser, editor, dom, and js.
to parameter conversion. The xpcom module needs to be mentioned because it
makes extensive use of overloading. xpcom provides APIs
The text files generated by running the instrumented g++
for implementing the COM component model. It also pro-
compiler are then processed with awk scripts and other Unix
vides a rich set of classes for string manipulation, a template
utilities like sort and uniq to obtain the desired statistics.
class nsCOMPtr for implementing a smart pointer, as well
as support for threading, hash tables, and arrays.
3.2 Study subject: Mozilla
Given a pointer p to a class X, a smart pointer
of type nsCOMPtr<X*> can be created and used on
We chose Mozilla as the first subject of our study be-
behalf of p. In places where an X* is needed,
cause it is an open-sourced, large-scale system written in
nsCOMPtr<X*> is converted to X* automatically. The
C++. We used version 1.8b1. Table 2 shows some static
following code snippet illustrates how the conversion hap-
measures of its size before compilation to give an impres-
pens. Specifically, the user-defined conversion operator
sion of its scale.
defined in nsCOMPtr will first convert nsCOMPtr<X*>
#header files 4679 #html files 2246 to a pointer to nsDerivedSafe<X*>. Because
#cpp files 4442 #xul files 624 nsDerivedSafe<X*> is a subclass of class X, the
#c files 1515 #xml files 325 pointer is then converted to a pointer to the most derived
base type, which is X. Note that in this case, both the def-
inition and the use of user-defined conversion is confined
Table 2. Some measures of Mozilla 1.8b1 size. within the same module xpcom and can be used by a client
without knowing the exact details of the conversions.

Table 3 lists a subset of Mozilla modules for which template <class T>
class nsDerivedSafe: public T { ... }
the following module dependency exists. Modules xpcom,
template <class T>
5 Inlining class nsCOMPtr {
would have no impact on the completeness of our data as it operator nsDerivedSafe<T >* () const {...}
happens after type checking. }

50
 Figure 2. Distribution of 13817 overloaded
function names over categories.

Figure 4. Distribution of 757 class members

over the times they are overloaded.

categories of standard library (370), instantiations of class

templates (6269), operators (439), global functions (189),
constructors (5793), and member functions (757). The vast
majority of overloading is due to constructors and class
template instantiations (42% and 45%, respectively). In
particular, the 6269 overloaded names in the category of
class template instantiations are actually caused by only 11
Figure 3. Distribution of 375 classes over the names from 6 template classes, all from the module xpcom,
number of function names overloaded by a which are shown in Table 6.
class. In compiling the Mozilla browser, 5 689 classes are de-
tected (excluding those contributed by instantiating class
In Mozilla, files belonging to the same module are stored templates and the standard C++ library). Out of these,
into the same file system directory. Therefore, based on 375 classes overload at least one function name. That is,
the file path our tool extracts for each translation unit, we about 6.6 percent of the classes define overloaded mem-
are able to obtain information about the module where an ber functions. Figure 3 depicts the distribution of 375
overloading call is made as well as the module that defines classes over the number of names overloaded by each class.
the function to which the overloading call is resolved. The classes that contain 14 and 13 overloaded names are
Mozilla 1.8b1 is configured to build a Mozilla browser nsIRenderingContext and its 3 subclasses in the gfx
and is compiled with the instrumented g++ compiler. In this module. The morkStore class from module db overloads
way, both the definition and the use of overloaded functions 12 names. The xpcom module contributes 3 classes for
are obtained and the data are stored in text files, which are 11 names and 5 classes for 9 names, 6 of which are string
further processed to produce the desired statistics. classes, and 2 for COM implementation.
Figure 4 depicts the distribution of the 757 overloaded
4 Results member functions over the number of times a name is over-
loaded. To understand for what purposes certain names
This section presents the characteristics of the definition are overloaded a high number of times, we inspected the
and use of overloading in the Mozilla code base. 23 names that are overloaded 5 times or more. We found
that 16 are string operations, and 5 are graphics operations
4.1 Overall statistics of definition of function over- (GetWidth from 4 classes and DrawString). The name
loading in Mozilla source that is overloaded 9 times is nsINodeInfo::Equals,
which are used to compare between objects of various types.
A total of 13 817 overloaded names are detected. Fig- Table 4 depicts those Mozilla modules that contain more
ure 2 depicts the distribution of overloaded names over the than 10 overloaded names in member functions and the ac-

51
 editor/composer 27 layout 104 A total of 115 439 function calls are identified as call-
htmlparser 31 dom 11 ing overloaded functions. Figure 5 depicts the distribution
content 129 netwerk 14 of these function calls. Of these, 29 530 are due to class
gfx 144 intl 14 templates (no template functions are called). 3 337 are call-
view 11 xpcom 113 ing overloaded function defined in the standard C++ library.
widget 17 js 13 The remaining 82 572 calls are of non-library, non-template
overloaded functions.

Table 4. Mozilla modules that contain more ::operator delete ::operator delete []
than 10 overloaded names in class scope. ::operator new ::operator new []
std::abs std::div
tual number of overloaded names that each such module std::memchr std::strchr
contains. To gain some insights into where and how names std::strrchr std::strstr
are overloaded, we inspected a subset of the 757 overloaded std::strrpbrk
names. In general, it appears that overloading tends to be
used in modules that manipulates data structures, for ex-
ample, content for document structures, gfx for geometric Table 5. The 11 overloaded functions in the
shapes and drawing, layout for data structure traversal and standard C++ library used by Mozilla.
layout logic, and xpcom for strings and pointers. Our in-
formal inspection also reveals three patterns for function
overloading. One pattern is to overload getters and setters Table 5 depicts the 11 overloaded function names in the
to provide different ways of setting and getting object at- standard C++ library used by Mozilla. As an example of the
tributes. Another is to overload a core operation with sev- intricacy of C++ overloading rules and what it means for
eral others that are reduced to the core one. Yet another pat- C++ to maintain compatibility with C, consider the follow-
tern is to provide two ways of retrieving object attributes, ing code snippet that depicts how C++ overloads the C func-
via return values and via a parameter, respectively. tion strchr. Its purpose is to correct a type problem in the
In sum, these data indicate that only 6.6 percent of C prototype for strchr. Since the C strchr returns a
classes (375) in Mozilla overload member names, 85.6 per- pointer to the content of its first argument, which is of type
cent of these classes overload 3 or less members, and 92.6 const char *, according to C++’s typing rules, its re-
percent of the overloaded members (757) are overloaded 2 turn type should have been const char* too. To correct
or 3 times (82.8 percent are overloaded only 2 times). this problem and to maintain maximum compatibility with
C, another strchr is added in C++, which overloads the C
strchr. Note that the 2 functions are distinguished by the
4.2 Overall statistics of calls of overloaded func-
const keyword. This example demonstrates only one of
tions in Mozilla source
the many subtle rules C++ defines for function overloading.
//in string.h (C header):

char *
strchr(const char*, int)

//in cstring (C++ header):

using ::strchr;

inline char*
strchr(char* s1, int n)
{return _builtin_strchr(const_cast<const char*>(s1),n);}

In the 29 530 calls that are resolved to an overloaded

member in a class template (see Figure 5), 23 387 are calls
of template constructors, and 6 143 calls of overloaded
member functions in template instantiations. Further analy-
sis reveals that these member functions overload 11 names
in 6 template classes, all from the xpcom module. These 11
names are depicted in Table 6. Note that the nsCOMPtr
Figure 5. Distribution of 115439 calls of over- class template, which implements a smart pointer, is widely
loaded functions over categories. used (4881 times in 27 modules). Note also that 8 of the 11
overloaded names are operators.

52
 overloaded name #calls (#module) functionality overloaded names
nsReadingIterator<T>::operator++ 198 (13) string and ::Substring, ::ToLowerCase, ::ToUpper-
nsReadingIterator<T>::operator- - 30 (10) character Case, nsAString:: (Append, Assign, op-
nsWritingIterator<T>::operator++ 9 (2) erator+=, operator=) ... (26 more elided)
nsWritingIterator<T>::operator- - 3 (1) file and nsFilePath::operator=, nsFile-
nsAutoArrayPtr<T>::operator= 4 (2) stream Spec::operator=, nsFileURL::operator=,
nsAutoPtr<T>::operator= 89 (4) nsOutputFileStream::operator<<,
nsCOMPtr<T>::get address 711 (1) nsOutputStream::operator<<
nsCOMPtr<T>::operator= 4881(27) data and nsINodeInfo::Equals, nsIRendering-
nsCOMPtr<T>::swap 22 (8) graphics Context::GetWidth, nsRenderingCon-
nsRefPtr<T>::operator= 188 (8) textGTK::GetWidth, nsRendering-
nsRefPtr<T>::swap 8 (3) ContextPS::(DrawString, GetWidth),
nsRenderingContextXlib::GetWidth,
::FindInReadable, ::address of, ns-
Table 6. The 11 overloaded template member MetaCharsetObserver::Notify
functions (all defined in xpcom) and the dis-
tribution of 6143 calls of these functions over
modules. Table 8. A total of 49 overloaded names have
a candidate set size from 5 to 9.
In the 82 572 calls of non-library, non-template over-
loaded functions, 43 076 of them are calling class construc-
functionality overloaded names
tors, 22 681 are calling global functions, and 16 815 are
string and nsAString::(Assign, operator=),
calling class member functions (see Figure 5). At this stage
character nsAutoString::operator=, ... (14 more
of compilation, internally g++ names all constructors uni-
elided)
formly as base ctor and comp ctor. This makes it
file and nsFilePath::operator=, ns-
easy to remove constructor calls from the data and keep only
stream FileURL::operator=, ns-
the calls of global functions and class members. As part of
FileSpec::operator=,
its building process, Mozilla performs a variety of tests on
nsOutputFileStream::operator<<,
the g++ compiler to see if the compiler is suitable for build-
nsOutputStream::operator<<
ing Mozilla. A few hundreds of overloading calls are gen-
erated due to these tests, which do not belong to Mozilla. data Value:: (operator!=, operator==,
A further cleanup is done to remove these calls, and a total Equals, operator=), nsGlobalHis-
of 39 012 overloading calls are obtained, which are non- tory::SetRowValue
library, non-template, and non-contructor calls in Mozilla.
Table 9. A total of 32 overloaded names have
4.3 Detailed analysis of overloading calls a viable set size from 4 to 9.

In this section, overloading calls are analyzed in detail

candidate #calls #name viable #calls #name along three dimensions: the sizes of candidate sets and
2 12120 649 1 30448 692 viable sets, their distributions within and across module
3 6106 92 2 7084 174 boundaries, and how inter-module overloading calls use the
4 13600 44 3 1187 44 conversion rules. The goal of this analysis is to under-
5 2976 22 4 167 21 stand how overloading resolution may influence program-
6 3052 20 5 30 8 ming understanding and discuss its implications on the use
8 936 4 8 52 2 of various rules about overloading.
9 222 3 9 44 1 Table 7 depicts the distribution of the 39012 calls over
the various sizes of candidate set and viable set. For exam-
ple, the first row shows that 12120 calls have a candidate
Table 7. Distribution of 39012 overloading set of size 2 and are the result of calling 649 overloaded
calls over candidate set sizes (column can- names. Furthermore, 30448 calls have a viable set of size
didate) and viable set sizes (column viable). 1 and are the result of calling 692 overloaded names. Note
that 77.8 percent of all the overloading calls (30448) have
a viable set of size 1, and that 81.6 percent of calls have

53
 editor layout content parser netwerk gfx widget view xpcom
editor 248 13 28 1 3 4 3339
layout 1534 149 14 478 13 9 2553
content 76 1409 9 60 7 6 1 5947
parser 393 4 381
netwerk 133 2299
gfx 2 334 496
widget 1 1 3 12 36 362
view 27 6 58 43
xpcom 3387

Table 10. Distribution of 39012 overloading calls over module interactions. Calls within modules are
made italic and calls to xpcom bold.

a candidate set of size 4 or less. In general, this is a good to be owned by individuals or small teams that work closely
news because it means that the majority of overloading calls with each other, which in general should facilitate the use
are made with almost no extra cognitive effort from the pro- of overloading.
grammers. Programmers would be able to easily recognize
There are only 1332 (3.4 percent) inter-module overload-
the function intended to be called from other candidates be-
ing calls among application modules (as opposed to the util-
cause the function being called has either a different number
ity module xpcom). These calls are made to 86 overloaded
of arguments than that of the parameters of the candidates
names defined in 7 modules, of which 8 are global func-
or obviously incompatible types from that of the candidates
tions, and 78 class members. No operators are involved.
for which no implicit conversions are possible.
The gfx module contributes 44 names, content comes next
To gain some insights into the question as to why some with 14 names, and widget and view 1 each. In average,
names are overloaded more times than the ‘good’ ones dis- each module contributes 12 names, and a module uses a
cussed above, names resulting in large candidate sets and name 6.9 times. Furthermore, each name is used in aver-
viable sets are collected and analyzed. Table 8 depicts the age by only 2 external modules (with a range 1 to 20). This
49 names that are involved in calls that have a candidate means that application modules tend to define a small num-
set size from 5 to 9. Table 9 depicts the 32 names that are ber of overloaded names, which are in turn used by only a
involved in calls that have a viable set size from 4 to 9. small number of other application modules. This is clearly
Note that the two tables share more than 20 names, most of different from utility modules, which may define a large
which are string and file operations. 22 of the overloaded number of overloaded names that are used by a large num-
names in Table 9 are operations on string and character, and ber of application modules.
file and stream from the utility module xpcom, which pro-
grammers are likely to be familiar with due to their generic
nature. In fact, only 10 overloaded names with a viable set conversion number
size from 4 to 9 are contributed by application modules. In cr identity 2568
particular, the one with a viable set size of 9 is an oper- cr exact 100
ator (nsOutputStream::operator<<) and is called cr promotion 5
44 times. ck std 48 (int vs unsigned int), 158 (0 to
Table 10 depicts a matrix for the number of overloading pointer)
calls that modules in the left-most column made to modules ck ptr 238 (225 due to a template in xp-
in the top row. The diagonal cells represent the overload- com)
ing calls within each module, and a non-diagonal cell rep- ck base 316 (all due to strings in xpcom)
resents the interaction between modules. First note that 84 cr user 379 (all due to types defined in xp-
percent of overloading calls (32717 out of 39012) are made com)
on 182 names in the utility module xpcom. Thus each over-
loaded name in xpcom is used 180 times in average. Also
noteworthy is that for modules other than xpcom, within- Table 11. Distribution of 3812 conversions for
module calls far out-number interactions between modules. the 1332 inter-module overloading calls.
This is likely to be a good attribute because modules tend

54
 Since overloaded names on module interfaces tend to able and usable programming languages or APIs.
be defined and used by different developers who are most There are several empirical studies of language or tool
likely working on different aspects of the application, it usage. Knuth reports a study of the characteristics of For-
would be a good strategy to minimize the use of over- tran programs in order to understand the effectiveness of
loading on module interfaces, and to use the easy subset compiler optimization and how to improve it [9]. Ernst et
of overloading only. The 1332 inter-module overloading al. study the use of the C preprocessor in order to char-
calls are analyzed to understand in detail how the conver- acterize how macros are actually used in practice and the
sion rules of Table 1 are used. A total of 3812 pairs of practical implications on tool builders and software devel-
conversion between argument type and parameter type are opers [5]. English et al. investigate the use of friend key-
identified. Thus in average each overloading call requires word in practical C++ systems and the appropriateness of
less than 3 conversions. Table 11 depicts the result. Notice such use [4]. Gil and Mamon study the use of micro patterns
that the uses of the easy rules, cr identity, cr exact, in large corpus of Java code [7]. Baxter et al. investigate the
and cr promotion, occupy more than 70 percent of the power law distribution that appear in some structural prop-
3812 conversions. The data for the standard conversion are erties of Java software [1]. Murphy et al. report an analysis
broken down into 3 sub-categories. 48 of ck std convert of the data they gathered about the usage of the Eclipse en-
between integral values, which may lose precision, and vironment from actual developers and argue that such data
158 convert 0 to a pointer type. 238 conversions are from may be used to inform the future evolution of Eclipse [12].
pointer to derived type to a base type, of which, 225 are due Gannon and Horning describe a study where a set of
to a template defined in xpcom (nsDerivedSafe<T>). language features are redesigned with the objective to im-
316 derived-to-base-object conversions are between the prove program reliability, which is subsequently empiri-
various string types defined in xpcom. Finally, the cally verified in terms of both fault frequency and fault per-
379 user-defined conversions are implemented by 3 sistence [6]. Empirical studies are also conducted to under-
templates (nsCOMPtr<T>, nsGetterAddRef<T>, stand the usability tradeoffs of different API design choices,
and nsRefPtr<T>) and 3 classes in xpcom e.g., abstract factory design pattern versus constructors [3]
(nsCStringTuple, nsXPDILCString, and and the usability implications between constructors with
nsGetterCopies). The 3 templates implement the and without parameters [15].
so-called ‘smart pointer’, and the 3 classes are about strings In [8], Hoare presents his view on language design. He
and ‘smart pointer’ as well. believes that the goal of a programming language is to as-
In sum, the majority of overloading calls in Mozilla have sist programmers in the most difficult aspect of program-
a viable set of size 1 (77.8 percent) and a candidate set of ming, that is, on the design, documentation, and debug-
size 4 or less (81.6 percent). This is good because it would ging of programs, and proposes five objective language de-
imply that the programmers are benefiting from overload- sign principles to help achieve this goal: simplicity, se-
ing at almost no extra cost in performing overloading reso- curity, fast translation, efficient object code, and readabil-
lution. Furthermore, calls with a viable set size larger than 3 ity. Function overloading contributes to program readabil-
and a candidate set larger than 4 involve only 10 names from ity. In [11], Meyer expresses that useful languages can-
application modules, which would imply that the cost asso- not be small and proposes as design principles consistency,
ciated with these uses of overloading can be managed. Only uniqueness, tolerance and discipline, and methodology. In
3.4 percent of overloading calls (1332) happen between ap- particular, he advocates that the language designer should
plication modules, and the rest are calls to the utility mod- provide a methodology for the use of each language fea-
ule xpcom and within-module overloading calls, which are ture. There is also much research on designing usable
considered less a problem than inter-module calls. Finally, a programming languages. A comprehensive survey can be
detailed examination of the conversions in the inter-module found in [13]. In [2], Cordy describes how to achieve bet-
calls reveals that 70 percent of them use the easy subset ter language usability by paying attention to conciseness,
of the conversion rules (below the rank of standard conver- expressiveness, and readability in the design of the Turing
sion). For the rest 30 percent that use standard conversion language while retaining great power in the notation. He
and user-defined conversion, 24 percent are due to xpcom also emphasizes the use of user feedback as a design tool to
types. In particular, no user-defined conversion is defined shape the language design.
in application modules.
6 Conclusion and future work
5 Related work
An empirical study of the use of overloading in Mozilla
In this section we survey some related work in the areas is described. The goal is to gather evidence on how the
of empirical study of language or tool use, designing reli- feature is actually used, which can be used to inform fu-

55
 ture language design, gather typical use cases, and develop ’07: Proceedings of the 29th International Conference
usage guidelines. We conclude that overloading is useful on Software Engineering, pages 302–312, Washing-
in the systems programming area that C++ is designed for. ton, DC, USA, 2007. IEEE Computer Society.
We find that in Mozilla, the most ‘advanced’ subset of func-
[4] M. English, J. Buckley, and T. Cahill. A Friend in
tion overloading are only defined and used in a single utility
Need is a Friend Indeed. In International Symposium
module xpcom, that the majority of application modules use
on Empirical Software Engineering, pages 469 – 478,
only the ‘easy’ subset of function overloading when over-
Nov 2005.
loading names, and that most overloaded names are used
locally within the modules rather than across module inter- [5] M. D. Ernst, G. J. Badros, and D. Notkin. An Em-
faces. We feel that this is potentially a good strategy that can pirical Analysis of C Preprocessor Use. IEEE Trans.
be used to guide the use of overloading in system design. Softw. Eng., 28(12):1146–1170, 2002.
We have also reported an initial set of anecdotes and obser-
[6] J. D. Gannon and J. J. Horning. Language Design for
vations on how overloading is used in Mozilla, from which
Programming Reliability. IEEE Trans. Software Eng.,
we hope a useful set of patterns may be distilled eventually
1(2):179–191, 1975.
by further analyzing data from Mozilla and other systems.
Clearly, our findings are limited only to Mozilla. More [7] J. Y. Gil and I. Maman. Micro Patterns in Java Code.
systems need to be analyzed before generalization can be at- SIGPLAN Not., 40(10):97–116, 2005.
tempted. We are currently analyzing other C++ systems. It
[8] C. A. R. Hoare. Hints on Programming Language
would also be interesting to perform some in-depth analysis
Design. Technical Report STAN CS-73-403, Stand-
to determine whether overloaded names on module inter-
ford University, December 1973. In State of the Art
faces are necessary or gratuitous. Finally, it may be useful
Report 20: Computer Systems Reliabilty, C. Bun-
to modify our tool to make the information about overload-
yan, Ed. Pergamon/Infotech. A 1989 collection of Dr.
ing available to programmers, for example, by adding an
Hoare’s essays entitled Essays in Computing Science
option to the g++ compiler to trigger the output of such in-
published by Prentice Hall, also contains a reprint of
formation. This can be useful particularly when a program-
this paper.
mer needs to understand exactly how an overloading call
that involves user-defined conversions is resolved, or when [9] D. E. Knuth. An Empirical Study of FORTRAN Pro-
it is desired to systematically inspect all of the narrowing grams. Software: Practice and Experience, 1(2):105
conversions for reliability concerns. – 133, 1971.
[10] S. B. Lippman and J. Lajoie. C++ Primer. Addison
Acknowledgments Wesley, Reading, MA, 1998. Third Edition.

The authors are grateful to the three anonymous review- [11] B. Meyer. Principles of Language Design and Evolu-
ers for their detailed and constructive feedback that helps tion. In J. Davies, B. Roscoe, and J. Woodcok, editors,
improve both the content and the presentation of this paper. Proceedings of the 1999 Oxford-Microsoft Symposium
in Honour of Sir Tony Hoare, pages 229–246. Corner-
stones of Computing, Palgrave, 2000.
References
[12] G. C. Murphy, M. Kersten, and L. Findlater. How
[1] G. Baxter, M. Frean, J. Noble, M. Rickerby, H. Smith, Are Java Software Developers Using the Eclipse IDE?
M. Visser, H. Melton, and E. Tempero. Understand- IEEE Softw., 23(4):76–83, 2006.
ing the Shape of Java Software. In OOPSLA ’06: Pro-
[13] J. F. Pane and B. A. Myers. Usability Issues in the De-
ceedings of the 21st annual ACM SIGPLAN confer-
sign of Novice Programming Systems. Technical Re-
ence on Object-oriented programming systems, lan-
port CMU-CS-96-132, Carnegie Mellon University,
guages, and applications, pages 397–412, New York,
August 1996.
NY, USA, 2006. ACM.
[14] B. Stroustrup. The Design and Evolution of C++. Ad-
[2] J. R. Cordy. Hints on the Design of User Interface
dison Wesley, Reading, MA, 1998.
Language Features: Lessons from the Design of Tur-
ing. In B. Myers, editor, Languages for developing [15] J. Stylos and S. Clarke. Usability Implications of Re-
user interfaces, pages 329–340. A. K. Peters, Ltd., quiring Parameters in Objects’ Constructors. In ICSE
Natick, MA, USA, 1992. ’07: Proceedings of the 29th International Conference
on Software Engineering, pages 529–539, Washing-
[3] B. Ellis, J. Stylos, and B. Myers. The Factory Pat- ton, DC, USA, 2007. IEEE Computer Society.
tern in API Design: A Usability Evaluation. In ICSE

56

View publication stats