Using ShellAnything as a shared library.

[end2endzone]

Is your feature request related to a problem? Please describe.
To allow other software to use ShellAnything as a reusable library, the code must be simplified and cleaned up. The use of classes from standard library in header files makes the library incompatible across multiple compilers. For example, compiling the library with Visual Studio 2017 will make the library unsafe to use with Visual Studio 2019. At best, you can expect memory corruption.

Describe the solution you'd like
The following code changes must be implemented:

• Remove usage of standard library in header files. Private implementation pattern can be used to solve this problem.
• Replace usage of the Node class by something else. The Menu and Configuration classes use the Node class for storing children. Replace by method names such as AddMenu(), AddConfiguration() and GetChildCount().
• Create a single class (or a Template class) that can be easily used as an implementation of a Shell Extension.
• Convert shellanything library to a DLL with a C++ interface.

Describe alternatives you've considered
Binding for a C api could be created. This would be longer to implement.

Additional context
N/A

[end2endzone]

References:

• https://stackoverflow.com/questions/5736289/binary-compatibility-of-stl-containers
• https://stackoverflow.com/questions/8395742/stl-containers-and-binary-interface-compatibility
• https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts
• https://stackoverflow.com/questions/37149479/when-do-we-break-binary-compatibility
• https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-160

[end2endzone]

Partially implemented features in commit e381d08.

[end2endzone]

From commit 5b59f64 :

Restored code for String class, ListsBody.inc and ListsDeclaration.inc from the following commits:

e381d08 2792c81 88722ad af0dd4d 4d1a67c 7904429 9b6d925 3960a4c 60df745 934d061 01fc6fb deccf01

[end2endzone]

Leaving this issue open for the moment. It may be revisited at a later time. Here are some thoughts on how to improve the previous failed design:

• Create a String class based on code in commit 5b59f64. This class should be a transparent replacement from std::string.
  • The methods that starts with a capital letter should be discarded. These methods were created in order to comply with the coding standard.
  • Add a comment above the declaration of the class with something that says A string class that provides a safe ABI around std::string.
• Class members that are based on std::vector, std::map or std::set should implement the Private Implementation design pattern as much as possible.
• For classes that provide a getter of their internal list (eg: Context::GetElements()), the files ListsBody.inc and ListsDeclaration.inc should be used.