隐蔽方法在C毕业设计外文资料翻译

毕业设计外文资料翻译学 院： 信息科学与工程学院 专 业： 计算机科学与技术 姓 名： 游娟 学 号： 080702134 外文出处：Norbert PATAKI，Faculty of Electrical Engineering and Informatics, Technical University of Koice，Versita Open，2021 ：1335-8243 附 件： 1.外文资料翻译译文；2.外文原文。 指导教师评语： 签名： 2021年3月16日附件1：外文资料翻译译文隐蔽方法在C+摘要:如今复杂的软件系统的设计和实施的主要面向对象的范式的帮助。然而，面向对象的语言支持不同的方式与不同的结构面向对象的范例。C + +中有一个精良的传承符号的根底上的访问修饰符。C + +的区别虚拟的，纯粹的虚拟和非虚拟方法。Java的使用final的类和方法来禁用继承。然而，Java不支持多重继承。艾菲尔允许重命名继承的方法。在本文中我们提出的一些方法公用程式C + +中创立更平安和更灵活的面向对象的系统。我们提出如何与C + +的模板设施的帮助下实施。我们目前的情况下，可以编写更平安的代码，我们构造。 关键词：C+，方法，面向对象编程，模板1. 引言 面向对象编程OOP仍是最常见的编程范式。它代表企图以使程序更加紧密地塑造人们的思维方式和处理与世界。在编程的旧样式，一名程序员面临着一些问题，必须确定一个计算任务，需要执行为了解决这个问题。在这种方式中，编程包括找到一个指令序列，将完成这项任务。在面向对象的境界，而不是我们找对象 - 实体，有行为的任务，持有信息，并且可以彼此互动。编程由一组对象的设计模式的问题。在程序中的软件对象可以代表在问题域的真实或抽象的实体12。这是应该使设计方案更自然因此更容易得到正确的和更容易理解。许多编程语言支持objectorientationSimula的67是第一语言支持这一论断。语言，如C +，C和Java时下最有名的。艾菲尔已被开发贝特朗迈耶在1986年11，这是也面向对象的语言。脚本语言通常基于面向对象的范例。然而，对于例如当前版本支持的PHP的OOP。事实上，不同的语言支持不同的这种范式结构8。这些构造的高度分析和互相比拟，因为普及面向对象编程范式3，6，7，9。例如，C + +不具有的每一个的超类类，但在Java Object类是类层次的根。C + +的区别公共，私人和保护继承。一个可以在Java和C写的最后一堂课这是不能父1 4。C + +是一种多范例编程语言支持面向对象的范例18。多重继承是允许的，但没有语言结构最终类，最终方法，或重命名的方法2。在C + +基类中的方法是隐藏的，当一个方法在派生类中声明的名称相同，但与窗体顶端不同的参数类型和/或数量16。虽然，这可以防止使用声明，这种情况是奇怪的12。C +提供的模板编写通用的构建函数和类。然而，一个新的方向一直与这种结构称为模板元编程TMP之间等方面的优势-元编程-能够在编译时检查的条件。如果失败的条件，可以停止编译过程。然而，在本文中，我们不处理元程序，但我们模板的力量优势。我们作出的努力，使C + +的复杂得多。我们开发的C + +处理的有用的扩展面向对象更复杂的方式14,15,20,21。本文组织如下。unhidable方法在C + +，在第2节详述。方法命名方案在第3节描述。开展的最终方法是在第4节详细。我们的结果和说明我们在今后的工作在第5节。2.UNHIDABLE方法这是常见的错误，在C+ +的虚拟签名在基类和派生类的方法不同意。在这虚拟方法不能重写，但隐藏。让我们考虑以下代码片段：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()此输出似乎是奇怪的。问题的根源是虚方法的签名是不完全的在基地和派生类中的相同。有一个const修饰符在课堂上Y.应尽量防止这种情况。然而，编译器没有错误消息编译此代码，只他们中的一些给予警告。为了克服这种情况我们利用C + +模板设施和预处理用于方便地使用我们的解决方案。首先，我们包装成一个成员函数指针模板类：#define _PTR_MEM(paramlist) template struct _Ptr_Mem void (T:*p)paramlist; ;之后，我们创立的测试模板类的实例以前的模板。如果这个测试类检查两个包裹指针可以分配给对方。如果基类和派生类的方法的签名是在完全相同的，那么这个任务正常工作。但是，如果签名是不一样的，那么这个分配结果编译错误信息，它不能被转换。#define _TEST(funcname) template struct _Test _Ptr_Mem a; _Ptr_Mem b; _Test() a.p = &Base:funcname; b.p = &Der:funcname; ;这些宏后，我们开发的宏启动检查此功能。宏调用以前的宏，创立一个匿名的命名空间的新方法，称为测试，如果隐藏的方法，它调用测试模板的如果签名的默认构造函数和检查相同：#define TEST_IF_HIDDEN_METHODS( Base, Der, function, paramlist) namespace _PTR_MEM(paramlist) _TEST(f) void _test_if_hidden_methods() _Test(); 让我们考虑如何才能使用此解决方案禁用在本节第一个例子中隐藏的虚拟方法：TEST_IF_HIDDEN_METHODSX，Y F，,这个宏必须呼吁在全球空间。如果代码编译，然后签名是在相同的根底和派生类，这意味着虚拟方法的正确使用。这将导致一个最小的开销，因为它创立了一个全球测试对象，并执行两个任务之间两个成员的三分球在运行时，这是廉价的操作。否那么，代码不编译，结果在以下错误消息：error: cannot convert void (X:*)()to void (Y:*)()constin assignment在本节中，我们提供了一个解决方案，以防止问题隐藏的虚拟方法时出现签名一种方法是不一样的，在基地和派生类。3.法重新命名 在艾菲尔编程语言继承可以改名功能。当两种方法继承从不同的基类具有相同的名称，这门语言元素有助于防止在派生类中的模糊性。虽然这是强制性的，在艾菲尔歧，C + +允许我们重新定义这两种方法，一次作为一个单一的方法派生类。它可以发生，但是，这两个基地类代表不同的概念，名称冲突只是巧合。然后，我们可能要重新定义那些在派生类中的语义不同的方法ES分别只是想，如果他们有没有任何共同之处。通过简单的例子，我们展示了如何重新命名继承的方法,在C + +，从而能够覆盖同样的命名方法分开。设A和B是我们每一个都有一个基类方法foo：struct 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 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方法在Java编程语言，它可以声明作为最后的成员函数5。这意味着，该成员功能不能在子类中重写。有两个好处：第一，涉及到程序设计和代码的质量，第二个属于性能编译器可以内联这些功能。在C + +编程语言，有良好的机制，使函数内联，但没有任何语言的支持，以防止在子类中重写虚拟成员函数。Stroustrup的等。等。22提出了一种解决方案，以阻止派生一类。在本章中，我们展示了解决方案，使一个C + +虚成员函数unoverridable。让我们假设我们有一个虚拟成员函数与基类AF，我们希望它的“最终。在休息节中，我们假设是动态创立的对象，因为在C + +的多态性由指针。它作品也通过引用，但我们的解决方案是有限的指针。我们今后的工作之一，是把它扩大到作为参考好。首先，我们需要制定出每类对象A或A的子类必须创立一个具体的工厂函数，而不是编写新的。这家工厂功能检查是否函数f重写。如果不是，它创立一类的新实例，否那么会发出编译时错误消息和编译失败。实现为此，我们有私人经营的新定义在类，并宣布为朋友的工厂函数。我们需要一个辅助类，它描述了成员功能作出最后。见下文：template class Helper ;第一个模板参数是一个任意类型，第二个一个是适当的成员函数的指针。模板结构的最终检查T类是否有不同的成员函数f一:f的方法如下：template struct FinalFinal()const bool b =boost:is_sameHelper,Helper :value;BOOST_MPL_ASSERT_MSG(b,ERROR_INVALID_OVERRIDE_OF_FUNCTION,(void);原理功能是相同的10boost库提供，而且它的两个模板参数在编译时检查是否是相同的。宏升压的MPL的ASSERT味精10创立一个编译时错误消息时，它的第一个参数是假的。第二个参数是错误信息，第三个拥有某种类型的信息，这是不有必要在这里。如果T是A和子类的成员函数f不是overidden在T，那么T:f是相同的成员功能，从而为A: F两个辅助类有相同的类型。工厂的功能如下：templateT* factory()Final();T* t = new T();return t;如果它可以创立临时最终对象，这意味着该成员函数f是不被覆盖。否那么最终构造的BoostMPL的断言味精导致一个编译错误。这些源代码的大局部是由预处理产生宏在以下方式：结构Astruct Avirtual void f() PREPARE_FINAL_METHODS;SET_FINAL(A, f, void, ()SET_FINALA，F，无效的，宏准备final方法产生的私人运营商新功能的朋友声明工厂。宏集最终A，F，无效的，作为最后一个成员函数的成员函数f。宏的第一个参数是类，第二个是功能，第三个什么返回类型，而最后一个是参数类型列表。我们提供集FINALn预处理宏定义多个成员函数到：最后更新，N表示成员函数设置到最后这个宏有四个参数列印倍。四，每个成员函数想在前面的例子。下面的例子显示了这个复杂的用法解决方案：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, h, char, () )struct B : Aint g(int, double) /* . */ ;struct C : Avoid k() /* . */ ;int main()B* b = factory(); / ERRORC* c = factory(); / OK设置FINAL3宏创立的具体帮手最终类和工厂功能的成员函数F，G和，我们当前要设定最后更新。该结构乙覆盖结构的一个成员函数和结构也与成员函数K表相同。当我们当前要创立一个乙的实例，我们得到以下错误消息：assertion_failed(mpl_:failed*(Final:Final() with R = C:ERROR_INVALID_OVERRIDE_OF_FUNCTION:*)出现此错误信息，因为结构乙覆盖其基类一个Hovewer至少有一个最后更新的成员函数成员，因为我们当前可以建立一个实例结构是不是最终的功能。5.结论与未来工作 在本文中，我们提出了不同的实现面向对象的特性在的C +不提供局域网有瓜葛的构造。这些功能使开发变得更容易，更平安，更灵活。final类的想法来从Java和其实施的C + +的优势模板。unhidable方法的想法来自一个常见的错误时，继承和重载。该解决方案还采用了C + +模板的构建。定义的最后一个成员函数是既有益设计和效率的原因。虽然C + +编程语言不支持它本身，我们提出如何运用这个面向对象的特点，在解决方案的C + +。在当前的研究与开发阶段是有限制设置成员函数作为最后：如果有一个成员设置为最终没有基类中的函数F允许创立一个派生类的成员函数f即使有不同的参数类型。我们今后的工作是提高我们的解决方案，以消除此限制。附件2：外文原文复印件 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 of 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 principally. 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 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 constructs 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 (OOP) 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 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. Programming 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 programming 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 typically 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 programming 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+ 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 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 template 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 effort 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 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. Lotus 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 problem 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 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 that 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 results 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 creates 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() _Test(); 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 proper 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 void (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 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 happen, 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 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 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 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(); ;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 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 that 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 hierarchys 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 renamed 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()/ added 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. 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 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 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 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 references 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 the 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 the member function to make final. See below: template class Helper ;The first template argument is an arbitrary type and the second one is a pointer to the proper member function. The template struct Final checks whether the class T has different member func