A recent project is to develop a framework for different product lines within the company. One problem encountered between the two is the use of the STL container, and the conclusion is that do not pass the STL container in the public interface:
- STL containers mentioned here, but mainly refer to containers and string classes, but they can be extended to any types provided in STL,
- The public interface mentioned here refers to the sdk header file to be exposed to the customer, including the function signature or class member variable;
It can also be said that do not include STL header files in the exposed header files.
Cause Analysis
We can discuss the following reasons:
- The STL versions used by the client may be different.
Because STL is used as the standard library, STL used during Framework compilation, and STL used during client compilation, the version may be different. For example, Framework is compiled and released using VC8, when the customer code is compiled and used using VC10, the STL containers understood by the Framework and the STL containers understood by the client code may have different data representations in the memory layout, errors are inevitable.
- Compilation options
Even if the Framework and client use the STL of the same version, if the compilation options are different, inconsistency may occur, and errors may occur.
- Static variables
Even if the version is consistent and the compilation options are consistent, static variables may be used in the implementation of STL containers. In the Framework module and client module, although the two pieces of code generated by template extension are consistent in general, both of them maintain a static variable, resulting in internal state inconsistency.
- The STL of the client is customized.
But from the perspective of files, the implementation of STL header files contained in the client can be completely different from the standard-as long as their interfaces are consistent with the standard. For example, if the STL used by the customer has special requirements for memory management and the default allocator is rewritten, memory problems may occur. For example, if the customer adds other member variables to the implementation, the memory layout is also inconsistent.
Although Microsoft mentioned in this article that exporting a vector is safe, this should be risky:
Unless you are sure that the user of your DLL and DLL will use the same STL-version, the compilation options are consistent, and have not been customized, the behavior may be inconsistent:
For example, you export the vector <int> In the DLL, And the stl used by this DLL is a custom version, and its memory management is implemented by itself, therefore, vector <int> may have two meanings on the customer side.
Optional
But in fact, you may still have this requirement-you need the function parameters or return values of the container class, and you may also need the class member variables of the container class. How can this problem be solved?
For the former, we can encapsulate a specific container class for a specific type, and we can still use STL container internally;
For the latter, we can use some methods to prevent the STL container from appearing in the header file;
There are several solutions:
- Provide your own container class
This is the most thorough and direct method, but it takes a lot of work to provide a set of template containers that are equivalent to STL, and it is obviously a repetitive manufacturing wheel. Note that it is not feasible to simply encapsulate the STL container because the template does not support separate compilation. This will still bring the STL container into the public interface.
- PImpl
The PImpl mode is of course very powerful and can solve this problem. However, if you only want to hide the container class, it is inevitable to use a cool tool and introduce unnecessary indirect layers and tedious scaffolding code.
- Use void * as a data member and then forcibly convert it to a container class.
Security is too ugly, and it is complicated to use. cast or below is required every time. Unless there is no other way, this solution should not be considered.
- Pre-declaration STL container
This method works in VC9, but according to the C ++ standard: 17.4.3.1 Reserved names, this method is undefined:
"
It is undefined for a C ++ program to add declarations or definitions to namespaceStdOr namespaces within namespaceStdUnless otherwise specified"
- Custom struct encapsulate container and pre-declaration
This solution is as follows: // header file
Struct PublicClassData;
Class PublicClass
{
Public:
PublicClass ();Private:
PublicClassData * m_pData;
}
// Implementation file
Struct PublicClassData
{
Vector <int> _ array;
Map <string, int> _ map;
};
PublicClass: PublicClass ()
{
M_pData = new PublicClassData;
}
Of course, note that we need to follow the following rules: rule of three, which provides the destructor, assign values, and copy constructors to manage the memory.
This solution is relatively concise and should be said to be the most practical one of the existing solutions.
Conclusion
Therefore, the conclusion is that do not use the STL container in the public interfaces of DLL/SO. If you do need it, useCustom struct encapsulate container and pre-declarationTo isolate STL containers!
