【文章內(nèi)容簡介】 cript languages are typically not based on the objectoriented paradigm. However, for instance the current version of PHP supports OOP. In fact, different languages supportthisparadigmwithdifferentconstructs[8].These constructs are highly analyzed and pared with each other because of the popularity of the objectoriented 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 hierarchy’s++ 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 that supports the objectoriented paradigm [18]. Multiple inheritances allowed, but there is no language construct for final classes, final methods, or renaming methods [2]. In C++, a method in a base class is hidden, when a method is 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 pilation time. If the condition fails, the pilation 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 objectorientation in more sophisticated way [14,15,20,21].This paper is anized 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 . UNHIDABLE METHODS It is mon mistake in C++ that the signature of virtual methods disagree in the base and derived class. In this case the virtual methods are not overridden, but hidden. Lotus consider the hereinafter code snippet: struct X { virtual void f() { std::cout X::f() std::endl。 } virtual ~X() {} }。 struct Y:X { virtual void f() const {std::cout Y::f() std::endl。 } }。 int main() { X* x = new X()。 xf()。 delete x。 x = new Y()。 xf()。 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 pilers pile this code without error message and only some of them give a warning. To overe 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 a template class: define __PTR_MEM(paramlist) template \ class T \ 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 the two 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 pilation error message, that it cannot be converted. define __TEST(funame) template \ class Base, class Der \ struct __Test \ { \ __Ptr_MemBase a。 \ __Ptr_MemDer b。 \ __Test() \ { \ = amp。Base::funame。 \ = amp。Der::funame。 \ } \ }。 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 template’sdefault 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() \ { \ __TestBase, Der()。 \ } \ } 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 piles, then the signature is the same in base and derived class, which means proper usage of virtual methods. This causes a minimal overhead, because it creates a global Test object and executes two assignment between two membertopointers at runtime, which is cheap operation. Otherwise, the code does not pile, results in the following error message: error: cannot convert 39。void (X::*)()39。 to 39。v