English Empirical

Seediscussions,stats,andauthorprofilesforthispublicationat:http://www.researchgate.net/publication/4139375

AnempiricalstudyoftheuseoffriendsinC++softwareCONFERENCEPAPERJUNE2005DOI:10.1109/WPC.2005.7Source:IEEEXplore

CITATIONS5

READS41

4AUTHORS,INCLUDING:

MichaelEnglishUniversityofLimerick14PUBLICATIONS80CITATIONS

SEEPROFILE

JimBuckleyRoyalAdelaideHospital43PUBLICATIONS337CITATIONS

SEEPROFILE

TonyCahillUniversityofLimerick11PUBLICATIONS30CITATIONS

SEEPROFILE

Availablefrom:MichaelEnglishRetrievedon:24December2015

An Empirical Study of the Use of Friends in C++ Software

Michael English, Jim Buckley, Tony Cahill, and Kristian LynchDepartment of Computer Science and Information Systems, University of Limerick, Ireland.

Dept of Endocrinology, Lund University, Sweden.Michael.English, Jim.Buckley, [email protected]

[email protected]

Abstract

A commonly held belief is that the friend construct inC++ is a violation of encapsulation. However, little empir-ical analysis of its use has taken place to provide evidenceto support this claim.

This paper presents a study which assesses the designimplications of including friendship in a system. A num-ber of hypotheses are investigated based on previous workin this area by Counsell and Newson, [4]. Our initial nd-ings suggest that classes declared as friends are couplinghotspots, that the more friends a class has the more pro-tected and private members it will contain and that friend-ship is not used to access inherited protected members.

1 Introduction

Ellis and Stroustrup, [6], dene a friend of a class as afunction that is not a member of the class but is permittedto use the private and protected member names from theclass. However, a class can also be declared as a friendof class, allowing all the members of class to access theprivate and protected members of class . The friendshiprelationship is not symmetric. In other words, can bedeclared a friend of without being declared a friend of.

Different perspectives on the appropriateness of thefriend mechanism exist in the literature. Coplien, [3],claims that the encapsulation provided by the protected andprivate mechanisms is violated by friendship. Similar per-spectives can be found in [11], [9] and [7].

In contrast Stroustrup, [12], defends the friendshipmechanism, describing it as one protection domain grant-ing a read-write capability to another. He argues that thedeclaration of a friend is part of the class declaration and re-jects the argument that friendship violates encapsulation asa combination of ignorance and confusion with non-C++

terminology. Meyers, [10], also holds the view that friendscan be considered part of the classs interface.

Limited empirical evidence about the usage of the friendconstruct in the development of object-oriented softwaresystems or its impact on other language features exists. Oneexception is the study undertaken by Counsell and Newson,[4], who examined a number of hypotheses in relation tothe use of the friend mechanism with respect to other in-ternal attributes and suggests that friendship is used as analternative to inheritance. However, this study did not takea number of syntactic restrictions inherent in C++ into ac-count in evaluating the hypotheses. In addition, Counselland Newson disregarded the assymmetry of the friendshipmechanism in their analysis of coupling. These were im-portant factors in the formulation and evaluation of theirhypotheses as explained at the start of section 2. The re-mainder of this paper discusses several renements to theCounsell and Newson experiment.

2 Empirical Study

The hypotheses which are outlined below are based onthe hypotheses presented by Counsell and Newson, [4]. Thedifferences between our hypotheses and those previouslypresented, and the measures which we use in order to testthe hypotheses are discussed here:1: The use of the friend construct may be necessary in C++to facilitate operator overloading. If commutativity of ob-jects is required an operator function may have to be denedas a non-member function. If, in addition to this the func-tion needs direct access to the private or protected mem-bers in a class, then the operator function must be madea friend of the class. Such friendship should be excludedwhen counting the declared friends of a class.2: In addition we believe that due to the asymmetry offriendship, the use of the friendship mechanism will onlyimpact the coupling for a class which is declared as a friend.Briand et al., [1], have looked at coupling issues and specif-ically have dened metrics based on friendship, taking into

Proceedings of the 13th International Workshop on Program Comprehension (IWPC05) 1092-8138/05 $ 20.00 IEEE

account the one-way nature of the friend mechanism, al-though there is some variation in the literature as to the def-inition of coupling, [2], [7].

The data required for this analysis has been extractedfrom four software systems with the aid of the source codeanalysis tool, Understand for C++, [8]. The denition of themeasures used in evaluating the hypotheses are presentedbelow.

2.1 Hypotheses Denition and Discussion

The following are the hypotheses under investigation:H1: Classes declared as friends of other classes, have lessnon-friend coupling than classes which are not declared asfriends.

Since friendship is considered a form of coupling, [4],[1], and since a class declared as a friend gains direct accessto extra functionality, it might be expected that such a classneeds other forms of coupling to a lesser extent and thuswill have less non-friend coupling. Our focus is to comparethe coupling of classes which are declared as friends andthe coupling of classes which are not declared as friends,whereas Counsell and Newson argued that the more de-clared friends of a class, the less non-friend coupling of thatclass.

The CBO measure which is used here does not includecoupling due to inheritance, nor does it include couplingdue to friend classes or functions. This measure is also aone-way measure, i.e. if a class uses methods or attributesof a class , then this coupling counts towards the couplingof class but not class .

In constrast, Counsell and Newson, [4], base theirmeasure of coupling on the Number of Associations,(NAS).

H2: The more declared friends of a class, the moreprivate and protected members in that class.

This hypotheses differs from H2 of Counsell in that acount is taken of only the private and protected membersand not all members of a class, since any class, already hasaccess to the public members of another class. If the classis also a subclass in an inheritance hierarchy, then this classwill also have direct access to all protected members inher-ited by from its ancestors. These members are also con-sidered in this hypothesis.H3: Classes declared as friends of other classes, have lessinheritance than classes which are not declared as friends.

This hypothesis is the same as hypothesis H3 of Coun-sell but we measure the amount of inheritance by the DITmetric. A class lower in the inheritance hierarchy is likelyto have inherited more members and will also have used theinheritance mechanism more than a class close to the baseof the hierarchy. If this hypothesis is accepted, then it may

indicate that friendship is used as an alternative to multi-ple inheritance for classes declared as friends and whichare contained in inheritance hierarchies, but are not baseclasses.H4: Classes which declare friends and which engage ininheritance appear lower in the inheritance hierarchy thanother classes engaged in inheritance.

The lower a class is in the inheritance tree, the morefunctionality this class will have inherited and thus the morefavourable it might be to declare a friend of the class, sincethe friend, in turn, will have access to more functionality.

Counsell and Newson formed a different hypothesisbased on this rationale, stating that classes declaring friendsthat engage in inheritance have less descendants than otherclasses engaged in inheritance, (measured using the Num-ber of Descendants, (NOD).

We believe that the Depth of Inheritance Tree, (DIT), isa more accurate measure of both the amount of inheritancein a class and the extra functionality obtained through in-heritance.H5: Classes that do not engage in any inheritance havemorefriends than classes which do engage in inheritance.

This hypothesis is the same as that introduced by Coun-sell and Newson. The rationale behind the hypothesis isbased on the fact that classes not engaging in inheritancetend to use friends as an alternative to inheritance. If thishypothesis is accepted, then this would indicate that friend-ship is used as an alternative to inheritance.

2.2 Overview of the Software Systems

Four software systems were analysed as part of this em-pirical study. These systems came from various applica-tion domains. Two of the systems under study, LEDA andLibg++, were also part of the analysis undertaken by Coun-sell and Newson, [4]. However, based on the summarystatistics available, different versions of these systems wereexamined here. The two other systems were Darwin2k andBayonne. Table 1 contains summary metrics for each ofthe four systems. The usage of the friend construct variesgreatly among the four systems, (see table 1). The overallhigh usage of friendship to facilitate operator overloadingin 3 of the systems illustrates the inuence that this specicuse of the friend mechanism could have on the evaluation ofthe hypotheses if it were included in the statistical analysis.

3 Statistical Analysis and Interpretation

The Spearman correlation coefcient was used for H2,assessing the linear association between two variables. Forthe other hypotheses we used the Pearson Chi-Square Testof Association to determine whether or not there was anassociation between two groups.


Leda Libg Darw BayoVersion 4.1 2.6.2 0.90 1.2.13Classes 521 150 319 174Stand-alone Classes 198 51 74 12Inheritance Trees 53 7 6 5Avg No. Cl. per tree 6 14 41 32Maximum DIT 5 5 6 3Friends 863 296 129 138Friend Classes 215 35 71 107Friend Functions 648 261 58 31Friend Op Overloads 298 146 27 0Cl. Declared Friends 137 30 34 66Cl. Declaring Friends 152 25 31 54

Table 1. Summary Metrics for the Four Sys-tems

H1 H3 H4 H5LEDA libg++ Darwin2k Bayonne

Table 2. P-values for the Chi-Square Statisticfor Four Hypotheses

3.1 H1: Classes Declared as Friends have lessCoupling

For three of the systems the p-value is for thishypothesis, (see column 1, table 2), and therefore we canconclude that the two populations under study are differentfor these three systems.

The Darwin2k system returned a p-value of .038. How-ever, a pronounced difference between the distributions oc-curs in the lower and upper quartiles, with little differencein between. The trend seems the same as in the other threesystems but not as pronounced. Given that the Chi-Squaretest does not report a signicantly small p-value this needsfurther investigation, but it may be because the proportionof the classes declared as friends in the system is very small,(see table 1).

Our initial hypothesis was based on the premise thatfriendship might be used as an alternative to other formsof coupling and thus in classes which have a lower couplingvalue. However the opposite seems to be the case: classeswhich are declared friends have a high degree of non-friendcoupling. This seems to indicate that classes which are de-clared friends are coupling hotspots in software systems.

Leda Libg Darw BayoH2 p

Spearman H2.1 p

Spearman

Table 3. Pearson Statistics for H2 and H2.1

3.2 H2: The More Friends, the More Private andProtected Members

Table 3 shows the statistical results for hypothesis H2.We tried to determine if a linear correlation existed betweenthe number of friends in a class and the number of privateand protected members in the class. For three of the foursystems a linear correlationwas reported but this correlationwas weak. Such a correlation was not uncovered by Coun-sell and Newson as we have only included those methodsfor which friendship is necessary to provide direct access.

3.3 H3: Classes declared as Friends have less In-heritance

The results for hypothesis H3, (table 2), indicate that thedistributions of the DIT metric for classes which are de-clared as friends and for classes not declared as friends aresignicantly different for two of the four systems. One sys-tem supports the hypothesis, while the opposite seems to bethe case for the other. The distributions or at least parts ofthem may also be different for the LEDA system.

We cannot determine any relationship between DIT andclasses which are declared as friends. This may be becausewe are examining both inheritance based classes and stand-alone classes together and, given that all stand-alone classeshave a DIT of zero this may be skewing the results. A re-nement of this hypothesis might examine stand-alone andinheritance-based classes separately in relation to this hy-pothesis. It is also possible, in line with Counsell and New-sons ndings, that the declaration of a class as a friend isindependent of its placement in the inheritance hierarchy.

3.4 H4: Classes which declare friends have ahigher DIT

The p-values presented in table 2 indicate that the distri-butions differ for the LEDA and Darwin2k systems. How-ever, the opposite of the hypothesis seems true for these sys-tems. Therefore, we reject this hypothesis.

To investigate the relationship between the usage offriendship and inheritance further we have looked at a vari-ation of hypothesis H2, since we believe that it could castfurther light on the results reported here. Therefore we have


carried out a variation on H2, (henceforth referred to asH2.1). Here, instead of measuring the number of privateand protected members in total, we have only measured theinherited protected members. If a linear correlation doesnot exist between the number of friends in a class and thenumber of inherited protected members of the class, thenthis is further evidence that classes are not declared friendsof other classes for the purpose of accessing this inheritedfunctionality.

For H2.1, as table 3 indicates, the p-values suggest thata correlation exists for only two systems, but the Spearmanvalue for these systems is positive for one and negative forthe other. Therefore, we can conclude that there is no evi-dence to support a correlation between inherited protectedmembers in a class and the number of friends that class has.

3.5 H5: Stand-alone classes have more friendsthan Inheritance-based classes

Table 1 shows the statistical results for hypothesisH5. There exists a difference between the distributionsfor stand-alone classes and inheritance based classes forLibg++, Darwin2k. An examination of the distributionsprovides support for the hypothesis above. There is no evi-dence to support this claim in LEDA. For the Bayonne sys-tem, the p-value indicates that the distributions may wellbe the same, or at least that any differences in them maybe down to chance. However an examination of the distri-butions leads us to conclude that at least parts of the dis-tributions are different, lending some support to the abovehypothesis.

Given that there is a signicant difference in the num-ber of friends in stand-alone classes and inheritance basedclasses for 3 of the systems, the hypothesised relationshipmay well exist. It may also indicate that friends are usedas an alternative to inheritance, or to multiple inheritance,if the classes declared as friends of the singletons alreadyhave a parent class. Further analysis is needed to investi-gate these issues. We cannot support this hypothesis con-clusively since the hypothesis doesnt hold for LEDA.

4 Conclusion

In this paper an empirical study of four software sys-tems was carried out to investigate the use of the friendmechanism in C++ software and to try to associate its us-age with other program constructs. We have establishedthat classes which are declared as friends have considerablyhigher coupling than classes not declared as friends. Thisrelationship has heretofore not been established. This nd-ing indicates that classes declared as friends could highlightcoupling hotspots in systems.

We have also established a possible link between thenumber of friends in a class and the number of private andprotected members in the class, illustrating a very practi-cal usage of friendship, to access restricted methods anddata, which otherwise would not be accessible directly. Wehave demonstrated these ndings through a rened mea-surement process which ignores friend functions which areoverloaded operators.

From this analysis it seems clear that a much more so-phisticated set of metrics, than already exists is required forthe analysis of software systems. These metrics need to bebased on the rationality of expert programmers. Ejiogu, [5],has stated that effective software metrics should be sim-ple and computable and programming language indepen-dent. While such characteristics should be attributable tometrics from a practical perspective they are not applicableto sophisticated metrics which are required to analyse ar-chitectural tradeoffs in software development. These met-rics must be program language dependent and be based onthe rationale behind the use of constructs by appropriatelyskilled users.

A fuller version of this paper is available from:www.csis.ul.ie/research/techrpts/ul-csis-05-1.ps

References

[1] L. C. Briand, P. T. Devanbu, and W. L. Melo. An Inves-tigation into Coupling Measures for C++. In InternationalConference on Software Engineering, pages 412421, 1997.

[2] S. R. Chidamber and C. F. Kemerer. A Metrics Suitefor Object Oriented Design. IEEE Trans. Software Eng.,20(6):476493, 1994.

[3] J. O. Coplien. Advanced C++ Programming Styles and Id-ioms. Addison-Wesley Longman Publishing Co., Inc., 1992.

[4] S. Counsell and P. Newson. Use of friends in C++ software:an empirical investigation. Journal of Systems and Software,53(1):1521, 2000.

[5] L. Ejiogu. Software Engineering with Formal Metrics. QEDPublishing, 1991.

[6] M. A. Ellis and B. Stroustrup. The Annotated C++ Refer-ence Manual. Addison-Wesley Longman Publishing Co.,Inc., 1990.

[7] R. Harrison, S.Counsell, and R. Nithi. An Overview ofObject-Oriented Design Metrics. In International Con-ference on Software Technology and Engineering Prac-tice,(STEP), pages 230234. IEEE Computer Society Press,July 1997.

[8] S. T. Inc. Understand for C++. web: www.scitools.com.[9] M. Lorenz and J. Kidd. Object-Oriented Software Metrics.

Prentice-Hall, Englewood Cliffs, N.J., 1994.[10] S. Meyers. Effective C++. Addision-Wesley, 1998.[11] M. Page-Jones. What Every Programmer Should Know

About Object-Oriented Design. Dorset House Publishing,1995.

[12] B. Stroustrup. The Design and Evolution of C++. ACMPress/Addison-Wesley Publishing Co., 1994.


Documents

English Empirical