A class library generating method independent of development environment

Abstract

The application discloses a class library generating method independent of development environment and belongs to the technical field of software engineering. There is no general C++ class library standard in the Windows platform, and the MFC extended DLL of Microsoft is used to produce the class library at present, but the same development environment as that in production must be used in the use, which brings great inconvenience to users, so the problem needs to be solved urgently. The class member functions of the application are virtualized, the position of the exported functions in vtab is analyzed, and the information of the base class is removed from the header file of the exported class while the corresponding number of pure virtual functions are inserted. The method is verified and implemented on the Windows platform and for the development tools of Microsoft, and the above problems are solved by using the method. The method is simple and easy to use, and special class library production tools are not needed. The base class of the exported class can be MFC or not. The final class library header file only has the information of the exported class and has no information of the parent class, which is convenient for users and protects the technical secret of the class library author.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, specifically relating to a method for generating class libraries that does not depend on a development environment. Background Technology

[0002] Currently, on the Windows platform, exporting a C++ class is generally achieved through an MFC extension DLL. However, MFC extension DLLs have a limitation: the development environment using the class library must be the same as the development environment of the production class library. This requirement severely restricts the scope of the class library's use.

[0003] Therefore, in C++ development, there is an urgent need for a method that can produce class libraries that are cross-development environments and that is simple and easy to use. Summary of the Invention

[0004] To address the lack of a widely accepted cross-development environment C++ class library standard on the Windows platform, this invention provides a class library generation method that does not depend on the development environment. This method can produce cross-development environment class libraries. It is simple to use and does not require special (class library) production tools.

[0005] To achieve the above objectives, the present invention employs the following technical solutions:

[0006] A method for generating class libraries that does not depend on a development environment includes the following steps:

[0007] Step 1: Modify the member functions of the class to be exported to virtual functions, and generate an MFC regular DLL;

[0008] The specific process of step 1 is as follows:

[0009] Step 1.1: If the exported class is derived from MFC, create a new MFC regular DLL project (shared MFC); if the exported class is not based on MFC, create a new regular DLL project. The following example uses an exported class based on MFC.

[0010] Step 1.2: Create a class to be exported, CDigitalClock (class CDigitalClock :CStatic).

[0011] Step 1.3: Modify the function to be exported in CDigitalClock to a virtual function. The exported virtual function must be guaranteed not to be overridden. In practice, the function name must be guaranteed to be unique in the exported class, parent class and its inheritance series.

[0012] Step 1.4: In the header file DigitalClock.h of CDigitalClock, adjust the declaration position of the exported functions so that they are placed before other member functions (non-exported functions);

[0013] Step 1.5: The destructor must also be virtualized and placed before all exported functions;

[0014] Step 1.6: Create a global function CDigitalClock*CreateObj(void) that can create an instance of CDigitalClock and return its pointer; create a local function CDigitalClock::Release(void) that can destroy the instance of this object;

[0015] Step 1.7: Export the CreateObj function described above using a .def file.

[0016] At this point, the export of the CDigitalClock class is complete. There are three useful files: a DLL file, a LIB file, and a header file. The class library can now be used, but the development environment used for use must be the same as the production environment. To use it across development environments, the header file must be modified. The modification steps are described below.

[0017] Step 2: Analyze the position of the exported functions in vtab;

[0018] The specific process of step 2 is as follows:

[0019] Step 2.1: Create a new MFC EXE project using Microsoft's development tools (the same ones used when generating the class library);

[0020] Step 2.2: Add the CDigitalClock class;

[0021] Step 2.3: Call the first exported function;

[0022] Step 2.4: Disassemble the call process of the first exported function and analyze its position in vtab, or without disassembling, use a user-defined function to calculate its position in vtab; Appendix Figure 1 It is the source code when the class is called.

[0023] from Figure 2As can be seen, the Draw_Digit function is stored at an offset of 0xC8H bytes from the beginning of vtab, and 0xC8H bytes correspond to the 0xC8H / 4=50th entry in vtab. This is in the class header file. Figure 3 As can be seen from this, Draw_Digit, which we are analyzing, is the third function, so the first function CreateTheCon is in the 50-2=48th entry of vtab.

[0024] If using VS2015, the first function `CreateTheCon` is in entry 93 of vtab. This is the root cause of the library's incompatibility across different development environments.

[0025] Since the virtual functions of the subclass are stored consecutively in the table (except for the destructor, no override occurs), the virtual functions of the entire derived class start at the 48th entry in vtab.

[0026] In addition, the authors developed a subroutine that can automatically calculate the position of virtual functions of exported classes in the vtab table. Therefore, there is no need to disassemble the source code.

[0027] Step 3: Based on the above analysis results, insert the corresponding number of pure virtual functions into the header file of the exported class, and remove the base class information. The specific process is as follows:

[0028] Step 3.1: Copy only the DigitalClock.h file;

[0029] Step 3.2: In the class declaration, replace the base class with a fictitious base class CBlank, class CDigitalClock :public CStatic;

[0030] Step 3.3: In the DigitalClock.h file, delete all member variables and functions except for exported functions;

[0031] Step 3.4: Construct class CBlank. In Blank.h, declare multiple pure virtual functions. The number of pure virtual functions is equal to the offset of the virtual functions of the exported class in the vtab (in the DLL). In this example, it is 48. Considering that the destructor in class CDigitalClock is virtual, the actual number of pure virtual functions should be 48-1. The constructed CDigitalClock and Cblank are as follows:

[0032] Contents of DigitalClock_new.h:

[0033] class CDigitalClock :public CBlank

[0034] {

[0035] public:

[0036] CDigitalClock();

[0037] virtual ~CDigitalClock();

[0038] virtual int CreateTheControl(CWnd * Pfather ,UINT resid);

[0039] virtual int Permit(UINT var);

[0040] virtual int Draw_Digit( char * sdigit) ;

[0041] virtual void SetTextColor(COLORREF crText);

[0042] ……

[0043] };

[0044] Contents of Blank.h:

[0045] class CBlank

[0046] {

[0047] public:

[0048] CBlank();

[0049] virtual ~CBlank();

[0050] virtual void blank1() =0;

[0051] virtual void blank2() =0;

[0052] ……

[0053] virtual void blank46() =0;

[0054] virtual void blank47() = 0;

[0055] };

[0056] Step 4: Construction complete.

[0057] Ultimately, the client receives two header files: DigitalClock_new.h and Blank.h, plus two library files: DigitalClock.lib and DigitalClock.DLL. These four files can be used with any Microsoft compiler.

[0058] Compared with the prior art, the present invention has the following advantages:

[0059] 1. The class library produced by the method of this invention can be used in different Microsoft development environments, which improves the reusability of the class library and facilitates C++ practitioners around the world;

[0060] 2. The class library produced by the method of this invention can replace the class libraries produced by Microsoft's MFC extension DLL and ActiveX controls, and the production and use of the class library are more convenient;

[0061] 3. This class library can implement all the functions of the C++ language. In the past, in order to adapt to different development environments, it was mainly released in the form of functions (such as regular DLLs), which could not implement all the functions of the C++ language.

[0062] 4. For submodules in large C++ software projects, programmers can use their preferred development environment to generate class libraries for the submodules, instead of having to use a specified development environment, thus reducing the requirements for programmers. Attached Figure Description

[0063] Figure 1 Source code diagram;

[0064] Figure 2 Disassembler diagram;

[0065] Figure 3 A diagram illustrating the class header file;

[0066] Figure 4 A diagram illustrating the usage of the class library (derived from MFC);

[0067] Figure 5 A diagram illustrating the usage of a class library (not derived from MFC). Detailed Implementation

[0068] Example 1: Using a exported class (derived from MFC)

[0069] 1. Create a new dialog-based MFC project (any compiler version is acceptable; this example uses VS2015); (or create a new console project (win32 console app) (without using MFC in the exported classes).

[0070] 2. Copy the four files DigitalClock_new.h, Blank.h, DigitalClock.lib, and DigitalClock.DLL to the current directory.

[0071] 3. Instructions for use:

[0072] TestControlVCDlg.h: Header file:

[0073] #include "DigitalClock_new.h"

[0074] #pragma comment(lib,"DigitControl.lib")

[0075] extern CDigitalClock *GetTheCon(void);

[0076] class CTestControlVCDlg : public CDialogEx ......

[0078] In the TestControlVCDlg.cpp file:

[0079] In the test button event handler function:

[0080] if(0==be_create)

[0081] {

[0082] pCon = ::GetTheCon();

[0083] / / CDigitalClock *pCon is already defined;

[0084] be_create= pCon->CreateTheControl(this ,IDC_STATIC_digit);

[0085] / / IDC_STATIC_digit is the resource ID (Text Control type) on the dialog box.

[0086] return;

[0087] }

[0088] pCon->Draw_Digit("12.345");

[0089] The results are shown in the attached figure. Figure 4 As shown.

[0090] This class library (CDigitalClock) was generated by VC6 but is used by VS2015. The code shows that once the global function GetTheCon() is called, subsequent use of this class is exactly the same as the native class.

[0091] Example 2 uses a exported class (the exported class is not derived from MFC).

[0092] 1. The following table shows the complete code for the pre-exported class Cout:

[0093]

[0094] 2. Follow step 1 (except for creating a new regular DLL project, everything else is exactly the same as step 1) to generate the class library. This project generates three files: out.DLL, out.LIB, and out.h.

[0095] 3. Analyze the position of the exported functions in vtab according to step 2; the first function of class Cout, add, is the third entry in the vtab table.

[0096] 4. Following step 3: Insert 3-1=2 pure virtual functions into the header file of the exported class, and remove the base class information. The final result is as follows:

[0097]

[0098] 5. Create a new console application (win32 console app) project (any compiler version is acceptable).

[0099] 6. Copy the four files Cout.h, Blank.h, Cout.lib, and Cout.DLL to the current directory.

[0100] 7. The source code for the experiment is as follows:

[0101]

[0102] The differences between the MFC extension DLL and this application are shown in the table below:

[0103]

[0104] Contents not described in detail in this specification are prior art known to those skilled in the art. Although illustrative specific embodiments of the invention have been described above to facilitate understanding by those skilled in the art, it should be understood that the invention is not limited to the scope of the specific embodiments. Various modifications are readily apparent to those skilled in the art as long as they fall within the spirit and scope of the invention as defined and determined by the appended claims, and all inventions utilizing the concept of this invention are protected.

Claims

1. A method for generating class libraries that does not depend on a development environment, characterized in that: Includes the following steps: Step 1: Modify the member functions to be exported into virtual functions to generate an MFC regular DLL; Step 2: Analyze the position of the exported functions in vtab; Step 3: Insert the appropriate number of pure virtual functions into the header file of the exported class, and remove the base class information; The specific process of step 1 is as follows: Step 1.1: Create a new MFC rule DLL project; Step 1.2: Create a class CDigitalClock to be exported. The exported virtual functions must ensure that they do not override functions in the base class. Step 1.3: Modify the function to be exported in CDigitalClock to a virtual function; Step 1.4: In the header file DigitalClock.h of CDigitalClock, adjust the declaration position of the exported function so that it is placed before other member functions; Step 1.5: The destructor must be virtualized and placed before all exported functions; Step 1.6: Create a global function CDigitalClock*CreateObj that can create an instance of CDigitalClock and return its pointer; create a local function CDigitalClock::Release that can destroy the instance of this object; Step 1.7: Export the CreateObj function described above using a .def file; The specific process of step 2 is as follows: Step 2.1: Create a new MFC EXE project using Microsoft's development tools; Step 2.2: Add the CDigitalClock class; Step 2.3: Call the first exported function; Step 2.4: Disassemble the first exported function and analyze its position index in vtab, or do not disassemble and use a custom function to calculate its position in vtab; The specific process of step 3 is as follows: Step 3.1: Copy only the DigitalClock.h file; Step 3.2: In the class declaration `class CDigitalClock :public CStatic`, replace the base class with a fictitious base class `CBlank`, `class CDigitalClock :public CBlank`; Step 3.3: In the DigitalClock.h file, delete all member variables and functions except for exported functions; Step 3.4: Construct class CBlank; In Blank.h, multiple pure virtual functions are declared. The number of pure virtual functions is equal to the position number analyzed in step 2.4 minus one.

Images