隱蔽方法在C++__畢業(yè)設(shè)計(jì)外文資料翻譯

1、畢業(yè)設(shè)計(jì)外文資料翻譯學(xué) 院： 信息科學(xué)與工程學(xué)院 專 業(yè)： 計(jì)算機(jī)科學(xué)與技術(shù) 姓 名： 游娟 學(xué) 號(hào)： 080702134 外文出處：Norbert PATAKI，F(xiàn)aculty of Electrical Engineering and Informatics, Technical University of Koice，Versita Open，2021 ：1335-8243 附 件： 1.外文資料翻譯譯文；2.外文原文。 指導(dǎo)教師評(píng)語： 簽名： 2021年3月16日附件1：外文資料翻譯譯文隱蔽方法在C+摘要:如今復(fù)雜的軟件系統(tǒng)的設(shè)計(jì)和實(shí)施的主要面向?qū)ο蟮姆妒降膸椭?。然而，面向?qū)ο蟮恼Z言支

2、持不同的方式與不同的結(jié)構(gòu)面向?qū)ο蟮姆独?。C + +中有一個(gè)精良的傳承符號(hào)的根底上的訪問修飾符。C + +的區(qū)別虛擬的，純粹的虛擬和非虛擬方法。Java的使用final的類和方法來禁用繼承。然而，Java不支持多重繼承。艾菲爾允許重命名繼承的方法。在本文中我們提出的一些方法公用程式C + +中創(chuàng)立更平安和更靈活的面向?qū)ο蟮南到y(tǒng)。我們提出如何與C + +的模板設(shè)施的幫助下實(shí)施。我們目前的情況下，可以編寫更平安的代碼，我們構(gòu)造。 關(guān)鍵詞：C+，方法，面向?qū)ο缶幊?，模板引?面向?qū)ο缶幊蘋OP仍是最常見的編程范式。它代表企圖以使程序更加緊密地塑造人們的思維方式和處理與世界。在編程的舊樣式，一名程序員面

3、臨著一些問題，必須確定一個(gè)計(jì)算任務(wù)，需要執(zhí)行為了解決這個(gè)問題。在這種方式中，編程包括找到一個(gè)指令序列，將完成這項(xiàng)任務(wù)。在面向?qū)ο蟮木辰纾皇俏覀冋覍?duì)象 - 實(shí)體，有行為的任務(wù)，持有信息，并且可以彼此互動(dòng)。編程由一組對(duì)象的設(shè)計(jì)模式的問題。在程序中的軟件對(duì)象可以代表在問題域的真實(shí)或抽象的實(shí)體12。這是應(yīng)該使設(shè)計(jì)方案更自然因此更容易得到正確的和更容易理解。許多編程語言支持objectorientationSimula的67是第一語言支持這一論斷。語言，如C +，C和Java時(shí)下最有名的。艾菲爾已被開發(fā)貝特朗邁耶在1986年11，這是也面向?qū)ο蟮恼Z言。腳本語言通常基于面向?qū)ο蟮姆独?。然而，?duì)于例如當(dāng)

4、前版本支持的PHP的OOP。事實(shí)上，不同的語言支持不同的這種范式結(jié)構(gòu)8。這些構(gòu)造的高度分析和互相比擬，因?yàn)槠占懊嫦驅(qū)ο缶幊谭妒?，6，7，9。例如，C + +不具有的每一個(gè)的超類類，但在Java Object類是類層次的根。C + +的區(qū)別公共，私人和保護(hù)繼承。一個(gè)可以在Java和C寫的最后一堂課這是不能父1 4。C + +是一種多范例編程語言支持面向?qū)ο蟮姆独?8。多重繼承是允許的，但沒有語言結(jié)構(gòu)最終類，最終方法，或重命名的方法2。在C + +基類中的方法是隱藏的，當(dāng)一個(gè)方法在派生類中聲明的名稱相同，但與窗體頂端不同的參數(shù)類型和/或數(shù)量16。雖然，這可以防止使用聲明，這種情況是奇怪的12。C

5、 +提供的模板編寫通用的構(gòu)建函數(shù)和類。然而，一個(gè)新的方向一直與這種結(jié)構(gòu)稱為模板元編程TMP之間等方面的優(yōu)勢(shì)-元編程-能夠在編譯時(shí)檢查的條件。如果失敗的條件，可以停止編譯過程。然而，在本文中，我們不處理元程序，但我們模板的力量優(yōu)勢(shì)。我們作出的努力，使C + +的復(fù)雜得多。我們開發(fā)的C + +處理的有用的擴(kuò)展面向?qū)ο蟾鼜?fù)雜的方式14,15,20,21。本文組織如下。unhidable方法在C + +，在第2節(jié)詳述。方法命名方案在第3節(jié)描述。開展的最終方法是在第4節(jié)詳細(xì)。我們的結(jié)果和說明我們?cè)诮窈蟮墓ぷ髟诘?節(jié)。2.UNHIDABLE方法這是常見的錯(cuò)誤，在C+ +的虛擬簽名在基類和派生類的方法不同意

6、。在這虛擬方法不能重寫，但隱藏。讓我們考慮以下代碼片段：struct Xvirtual void f()std:cout X:f() std:endl;virtual X() ;struct Y:Xvirtual void f() conststd:cout Y:f() f();delete x;x = new Y();x-f();delete x;The output of this program is the following:X:f()X:f()此輸出似乎是奇怪的。問題的根源是虛方法的簽名是不完全的在基地和派生類中的相同。有一個(gè)const修飾符在課堂上Y.應(yīng)盡量防止這種情況。然而，編

7、譯器沒有錯(cuò)誤消息編譯此代碼，只他們中的一些給予警告。為了克服這種情況我們利用C + +模板設(shè)施和預(yù)處理用于方便地使用我們的解決方案。首先，我們包裝成一個(gè)成員函數(shù)指針模板類：#define _PTR_MEM(paramlist) template struct _Ptr_Mem void (T:*p)paramlist; ;之后，我們創(chuàng)立的測試模板類的實(shí)例以前的模板。如果這個(gè)測試類檢查兩個(gè)包裹指針可以分配給對(duì)方。如果基類和派生類的方法的簽名是在完全相同的，那么這個(gè)任務(wù)正常工作。但是，如果簽名是不一樣的，那么這個(gè)分配結(jié)果編譯錯(cuò)誤信息，它不能被轉(zhuǎn)換。#define _TEST(funcname) t

8、emplate struct _Test _Ptr_Mem a; _Ptr_Mem b; _Test() a.p = &Base:funcname; b.p = &Der:funcname; ;這些宏后，我們開發(fā)的宏啟動(dòng)檢查此功能。宏調(diào)用以前的宏，創(chuàng)立一個(gè)匿名的命名空間的新方法，稱為測試，如果隱藏的方法，它調(diào)用測試模板的如果簽名的默認(rèn)構(gòu)造函數(shù)和檢查相同：#define TEST_IF_HIDDEN_METHODS( Base, Der, function, paramlist) namespace _PTR_MEM(paramlist) _TEST(f) void _test_if_hidde

9、n_methods() _Test(); 讓我們考慮如何才能使用此解決方案禁用在本節(jié)第一個(gè)例子中隱藏的虛擬方法：TEST_IF_HIDDEN_METHODSX，Y F，,這個(gè)宏必須呼吁在全球空間。如果代碼編譯，然后簽名是在相同的根底和派生類，這意味著虛擬方法的正確使用。這將導(dǎo)致一個(gè)最小的開銷，因?yàn)樗鼊?chuàng)立了一個(gè)全球測試對(duì)象，并執(zhí)行兩個(gè)任務(wù)之間兩個(gè)成員的三分球在運(yùn)行時(shí)，這是廉價(jià)的操作。否那么，代碼不編譯，結(jié)果在以下錯(cuò)誤消息：error: cannot convert void (X:*)()to void (Y:*)()constin assignment在本節(jié)中，我們提供了一個(gè)解決方案，以防止問

10、題隱藏的虛擬方法時(shí)出現(xiàn)簽名一種方法是不一樣的，在基地和派生類。3.法重新命名 在艾菲爾編程語言繼承可以改名功能。當(dāng)兩種方法繼承從不同的基類具有相同的名稱，這門語言元素有助于防止在派生類中的模糊性。雖然這是強(qiáng)制性的，在艾菲爾歧，C + +允許我們重新定義這兩種方法，一次作為一個(gè)單一的方法派生類。它可以發(fā)生，但是，這兩個(gè)基地類代表不同的概念，名稱沖突只是巧合。然后，我們可能要重新定義那些在派生類中的語義不同的方法ES分別只是想，如果他們有沒有任何共同之處。通過簡單的例子，我們展示了如何重新命名繼承的方法,在C + +，從而能夠覆蓋同樣的命名方法分開。設(shè)A和B是我們每一個(gè)都有一個(gè)基類方法foo：st

11、ruct Avirtual void foo();virtual void foo();and a derived class C:struct C : public A, public Bvirtual void foo(); / overrides both;Instead of merging the two methods into one we wouldlike to have separate methods, one for each inherited foo:struct C : public A, public Bvirtual void A_foo();virtual

12、void B_foo();We can achieve that by introducing two extra helperclasses, one for each base class, whose purpose is to renameA:foo to A foo and B:foo to B foo respectively.For symmetry reasons we present only RenA:struct RenA : public Avirtual void A_foo() A:foo(); virtual void foo() A_foo(); 4.final

13、方法在Java編程語言，它可以聲明作為最后的成員函數(shù)5。這意味著，該成員功能不能在子類中重寫。有兩個(gè)好處：第一，涉及到程序設(shè)計(jì)和代碼的質(zhì)量，第二個(gè)屬于性能編譯器可以內(nèi)聯(lián)這些功能。在C + +編程語言，有良好的機(jī)制，使函數(shù)內(nèi)聯(lián)，但沒有任何語言的支持，以防止在子類中重寫虛擬成員函數(shù)。Stroustrup的等。等。22提出了一種解決方案，以阻止派生一類。在本章中，我們展示了解決方案，使一個(gè)C + +虛成員函數(shù)unoverridable。讓我們假設(shè)我們有一個(gè)虛擬成員函數(shù)與基類AF，我們希望它的“最終。在休息節(jié)中，我們假設(shè)是動(dòng)態(tài)創(chuàng)立的對(duì)象，因?yàn)樵贑 + +的多態(tài)性由指針。它作品也通過引用，但我們的解決方

14、案是有限的指針。我們今后的工作之一，是把它擴(kuò)大到作為參考好。首先，我們需要制定出每類對(duì)象A或A的子類必須創(chuàng)立一個(gè)具體的工廠函數(shù)，而不是編寫新的。這家工廠功能檢查是否函數(shù)f重寫。如果不是，它創(chuàng)立一類的新實(shí)例，否那么會(huì)發(fā)出編譯時(shí)錯(cuò)誤消息和編譯失敗。實(shí)現(xiàn)為此，我們有私人經(jīng)營的新定義在類，并宣布為朋友的工廠函數(shù)。我們需要一個(gè)輔助類，它描述了成員功能作出最后。見下文：template class Helper ;第一個(gè)模板參數(shù)是一個(gè)任意類型，第二個(gè)一個(gè)是適當(dāng)?shù)某蓡T函數(shù)的指針。模板結(jié)構(gòu)的最終檢查T類是否有不同的成員函數(shù)f一:f的方法如下：template struct FinalFinal()const

15、bool b =boost:is_sameHelper,Helper :value;BOOST_MPL_ASSERT_MSG(b,ERROR_INVALID_OVERRIDE_OF_FUNCTION,(void);原理功能是相同的10boost庫提供，而且它的兩個(gè)模板參數(shù)在編譯時(shí)檢查是否是相同的。宏升壓的MPL的ASSERT味精10創(chuàng)立一個(gè)編譯時(shí)錯(cuò)誤消息時(shí)，它的第一個(gè)參數(shù)是假的。第二個(gè)參數(shù)是錯(cuò)誤信息，第三個(gè)擁有某種類型的信息，這是不有必要在這里。如果T是A和子類的成員函數(shù)f不是overidden在T，那么T:f是相同的成員功能，從而為A: F兩個(gè)輔助類有相同的類型。工廠的功能如下：templa

16、teT* factory()Final();T* t = new T();return t;如果它可以創(chuàng)立臨時(shí)最終對(duì)象，這意味著該成員函數(shù)f是不被覆蓋。否那么最終構(gòu)造的BoostMPL的斷言味精導(dǎo)致一個(gè)編譯錯(cuò)誤。這些源代碼的大局部是由預(yù)處理產(chǎn)生宏在以下方式：結(jié)構(gòu)Astruct Avirtual void f() PREPARE_FINAL_METHODS;SET_FINAL(A, f, void, ()SET_FINALA，F(xiàn)，無效的，宏準(zhǔn)備final方法產(chǎn)生的私人運(yùn)營商新功能的朋友聲明工廠。宏集最終A，F(xiàn)，無效的，作為最后一個(gè)成員函數(shù)的成員函數(shù)f。宏的第一個(gè)參數(shù)是類，第二個(gè)是功能，第三個(gè)什么

17、返回類型，而最后一個(gè)是參數(shù)類型列表。我們提供集FINALn預(yù)處理宏定義多個(gè)成員函數(shù)到：最后更新，N表示成員函數(shù)設(shè)置到最后這個(gè)宏有四個(gè)參數(shù)列印倍。四，每個(gè)成員函數(shù)想在前面的例子。下面的例子顯示了這個(gè)復(fù)雜的用法解決方案：struct Avirtual void f() /* . */ virtual int g(int, double) /* . */ virtual char h() /* . */ virtual void k() /* . */ PREPARE_FINAL_METHODS;SET_FINAL3(A, f, void, (),A, g, int, (int, double),A

18、, h, char, () )struct B : Aint g(int, double) /* . */ ;struct C : Avoid k() /* . */ ;int main()B* b = factory(); / ERRORC* c = factory(); / OK設(shè)置FINAL3宏創(chuàng)立的具體幫手最終類和工廠功能的成員函數(shù)F，G和，我們當(dāng)前要設(shè)定最后更新。該結(jié)構(gòu)乙覆蓋結(jié)構(gòu)的一個(gè)成員函數(shù)和結(jié)構(gòu)也與成員函數(shù)K表相同。當(dāng)我們當(dāng)前要?jiǎng)?chuàng)立一個(gè)乙的實(shí)例，我們得到以下錯(cuò)誤消息：assertion_failed(mpl_:failed*(Final:Final() with R = C:ER

19、ROR_INVALID_OVERRIDE_OF_FUNCTION:*)出現(xiàn)此錯(cuò)誤信息，因?yàn)榻Y(jié)構(gòu)乙覆蓋其基類一個(gè)Hovewer至少有一個(gè)最后更新的成員函數(shù)成員，因?yàn)槲覀儺?dāng)前可以建立一個(gè)實(shí)例結(jié)構(gòu)是不是最終的功能。5.結(jié)論與未來工作 在本文中，我們提出了不同的實(shí)現(xiàn)面向?qū)ο蟮奶匦栽诘腃 +不提供局域網(wǎng)有瓜葛的構(gòu)造。這些功能使開發(fā)變得更容易，更平安，更靈活。final類的想法來從Java和其實(shí)施的C + +的優(yōu)勢(shì)模板。unhidable方法的想法來自一個(gè)常見的錯(cuò)誤時(shí)，繼承和重載。該解決方案還采用了C + +模板的構(gòu)建。定義的最后一個(gè)成員函數(shù)是既有益設(shè)計(jì)和效率的原因。雖然C + +編程語言不支持它本身，我

20、們提出如何運(yùn)用這個(gè)面向?qū)ο蟮奶攸c(diǎn)，在解決方案的C + +。在當(dāng)前的研究與開發(fā)階段是有限制設(shè)置成員函數(shù)作為最后：如果有一個(gè)成員設(shè)置為最終沒有基類中的函數(shù)F允許創(chuàng)立一個(gè)派生類的成員函數(shù)f即使有不同的參數(shù)類型。我們今后的工作是提高我們的解決方案，以消除此限制。附件2：外文原文復(fù)印件 Subtle Methods in C+ Vol. 11, No. 3, 2021, 1116, DOI: 10.2478/v10198-011-0023-x 11SUBTLE METHODS IN C+Zalan SZU GYI, Norbert PATAKI, Jozsef MIHALICZADepartment o

21、f Programming Languages and Compilers, Eotvos Lorand University, Pazmany Peter setany 1/C, H-1117 Budapest,Hungary, e-mail: lupinludens.elte.hu, patakinoelte.hu, jmihaliczagmail ABSTRACT: Nowadays complex software systems are designed and implemented with the help of the object-oriented paradigm pri

22、ncipally. However, object-oriented languages support the object-oriented paradigm in different ways with different constructs. C+ has a sophisticated inheritance notation based on access modifiers. C+ distinguishes virtual, pure virtual and non-virtual methods. Java uses final classes and methods to

23、 disable inheritance. However, Java does not support multiple inheritance. Eiffel allows renaming inherited methods.In this paper we present some method utilities for C+ to create safer and more flexible object-oriented systems. We present how the method renaming can be implemented. We developed con

24、structs to create final and unhittable methods. These constructs are implemented with the help of C+ template facilities. We present scenarios where one can write safer code with our constructs.Keywords: C+, methods, object-oriented programming, template1. INTRODUCTIONObject-oriented programming (OO

25、P) is still the most common programming paradigm. It represents an attemptto make programs more closely model the way people think about and deal with the world. In the older styles of programming, a programmer who is faced with some problem must identify a computing task that needs to be performed

26、in order to solve the problem. In this way, programming consists of finding a sequence of instructions that will accomplish that task. In the object-oriented realm instead of tasks we find objects - entities that have behaviors, that hold information, and that can interact with one another. Programm

27、ing consists of designing a set of objects that model the problem. Software objects in the program can represent real or abstract entities in the problem domain 12. This is supposed to make the design of the program more natural and hence easier to get right and easier to understand. Many programmin

28、g languages support objectorientation.Simula 67 was the very first language that supports this paradigm. Languages like C+, C#, and Java are the most famous ones nowadays. Eiffel has been developed in 1986 by Bertrand Meyer 11, which is also an object-oriented language. Script languages are typicall

29、y not based on the object-oriented paradigm. However, for instance the current version of PHP supports OOP. In fact, different languages supportthisparadigmwithdifferentconstructs8.These constructs are highly analyzed and compared with each other because of the popularity of the object-oriented prog

30、ramming paradigm 3, 6, 7, 9.For example, C+ does not have a super class of every classes, but in Java class Object is the root of the class hierarchys+ distinguishes between public, private and protected inheritance. One can write final class in Java and C# which are cannot be super classes 1, 4.C+

31、is a multiparadigm programming language thatsupports the object-oriented paradigm 18. Multiple inheritances allowed, but there is no language construct forfinal classes, final methods, or renaming methods 2. In C+, a method in a base class is hidden, when a methodis declared in a derived class with

32、the same name but with different parameter types and/or consents 16. Although, this can be avoided with using declarations, this scenario is strange 12.C+ offers the template construct for writing generic functions and classes. However, a new direction has been developed with this construct called t

33、emplate met programming(TMP). Met programs among other advantages are able to check conditions in compilation time. If the condition fails, the compilation process can be stopped. However, in this paper we do not deal with metaprograms,but we take advantage of the power of templates. We make an effo

34、rt to make C+ much more sophisticated. We developed useful extensions for C+ to deal with object-orientation in more sophisticated way 14,15,20,21.This paper is organized as follows. Unhittable methodsin C+ are detailed in section 2. Method renaming scenarios are described in section 3. Development

35、of final methods is detailed in section 4. We conclude our results and describe our future work in section 5.2. UNHIDABLE METHODS It is common mistake in C+ that the signature of virtual methods disagree in the base and derived class. In thiscase the virtual methods are not overridden, but hidden. L

36、otus consider the hereinafter code snippet:struct Xvirtual void f()std:cout X:f() std:endl;virtual X() ;struct Y:Xvirtual void f() conststd:cout Y:f() f();delete x;x = new Y();x-f();delete x;The output of this program is the following:X:f()X:f()This output seems to be strange. The source of the prob

37、lem is that the signature of virtual method is not exactly the same in base and in derived class. There is a const modifier in class Y. This situation should be avoided. However, the compilers compile this code without error message and only some of them give a warning. To overcome this situation we

38、 take advantage of C+ templates facility and preprocessors used for making our solution convenient to use. First, we wrap a pointer to a member function into atemplate class:#define _PTR_MEM(paramlist) template struct _Ptr_Mem void (T:*p)paramlist; ;After that, we create the tester template class th

39、at instantiates the previous template. This tester class checks if thetwo wrapped pointers can be assigned to each other. If the signature of method of base and derived class is the exactly the same, then this assignment works properly. But, if the signatures are not the same, then this assignment r

40、esults compilation error message, that it cannot be converted.#define _TEST(funcname) template struct _Test _Ptr_Mem a; _Ptr_Mem b; _Test() a.p = &Base:funcname; b.p = &Der:funcname; ;After these macros, we develop the macro that start to check this feature. Macro calls the previous macros, and crea

41、tes a new method in the anonymous namespace, called test if hidden methods, which calls the Test templatesdefault constructor and checks if the signatures are same:#define TEST_IF_HIDDEN_METHODS( Base, Der, function, paramlist) namespace _PTR_MEM(paramlist) _TEST(f) void _test_if_hidden_methods() _T

42、est(); Let us consider how can one use this solution to disable hide the virtual method in this section very first example:TEST_IF_HIDDEN_METHODS( X, Y, f, () )This macro must be called in the global space. If the code compiles, then the signature is the same in base andderived class, which means pr

43、oper usage of virtual methods. This causes a minimal overhead, because it creates aglobal Test object and executes two assignment between two member-to-pointers at runtime, which is cheap operation. Otherwise, the code does not compile, results in the following error message:error: cannot convert vo

44、id (X:*)()to void (Y:*)()constin assignmentIn this section we provide a solution to avoid the problem of hidden virtual methods, which appears when the signature of a method is not the same in the base and derived class.3. METHOD RENAMINGIn the Eiffel programming language the inherited features can

45、be renamed. When two methods inherited from different base classes have the same name this language element helps to avoid ambiguity in the derived class.While this disambiguation is compulsory in Eiffel, C+ allows us to redefine both methods once as a single method of the derived class. It can happ

46、en, however, that the two base classes represents different concepts, and the name clash is simply coincidental. Then we may want to redefine those semantically different methods in the derived class(es) separately just like if they had nothing in common. Through simple example we show how to rename

47、 inherited methodsin C+ and thus be able to override equally named methods separately. Let A and B be our base classes each having method foo:struct Avirtual void foo();struct Bvirtual void foo();and a derived class C:struct C : public A, public Bvirtual void foo(); / overrides both;Instead of mergi

48、ng the two methods into one we wouldlike to have separate methods, one for each inherited foo:struct C : public A, public Bvirtual void A_foo();virtual void B_foo();We can achieve that by introducing two extra helperclasses, one for each base class, whose purpose is to renameA:foo to A foo and B:foo

49、 to B foo respectively. For symmetry reasons we present only RenA:struct RenA : public Avirtual void A_foo() A:foo(); virtual void foo() A_foo(); ;By default A foo behaves like A:foo. This way if A foo is not overridden, its calls through the derived classes will call foos original implementation in

50、 A. On the other hand, a call to foo through a pointer or reference to A. Should result in a call to A foo, this is the actual renaming step. Calls to foo through the base class interface leads, the execution to the implementation of A foo either in this or in the appropriate derived class. Note tha

51、t it is advisable to set foo final in this class to avoid misuse in derived classes by further overriding foisted of its renamed equivalent. In the internals of the C+ object model, the foo function remains present in all derived classes in the virtual dispatch table, after all it is part of the hie

52、rarchys interface. The solution for finalizinga method can be found in 4.Having this rename helper class implemented for B as well there is nothing more left than changing the base classes of C from A to Ren A and from B to Ren B respectively:struct C : public Ren A, public Ren BNow we can use the r

53、enamed methods in C as if theywere the original.This solution nicely fits to other features in connection with method overriding. The overridden version of A foocan for example call its original implementation in A by simply calling A:foo just like if we did not have the helperclass:void A_foo()/ ad

54、ded codeA:foo(); / can simply call/ base if needed/ added codeA caveat with the helper class that one should implement do-nothing forwarders for each constructor in it to make them available in the derived class. In C+ the constructorsinitializer list is allowed to refer only to direct base classes.

55、 With a few lines of preprocessing multiprogramming (see boost.preproc 10) an even more comfortablesyntax can be achieved:struct A . ;DEF_RENAMER(RenA, A,(foo) (A_foo)/ (bar) (A_bar) / we can add more/ renames easily)/ similarly for Bstruct C : public RenA, public RenB . ;4. FINAL METHODSIn the Java

56、 programming language it is possible to declare member function as final 5. It means that the member function cannot be overridden in subclasses. There are two benefits of that: first is concerning to the program design and the code quality, the second belongs to the performance(compiler can inline

57、these functions). In the C+programming language there are good mechanisms to make functions inline, but there is no language support to prevent overriding virtual member functions in subclasses.Stroustrup et. al. 22 presented a solution to stop deriving of a class. In this chapter we show a solution

58、 to make C+ virtual member function unoverridable. Let us suppose we have a base class A with a virtual member function void f(), and we want to make it “final. In the rest of the section we suppose the objects are created dynamically, because in C+ the polymorphism works by pointers. It works by re

59、ferences also but our solution is limited to pointers. One of our future work is to extend it to references aswell.First, we need to work out that every object of class A or subclasses of A must be created by a specific factory function instead of writing new. This factory function checks whether th

60、e function f() is overridden. If not, it creates new instance of the class, otherwise emits a compiletimeerror message and the compilation fails. To achieve this we have to define a private operator new in class A, and declare the factory function as friend.We need a helper class, which describes th