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:

• [x] Remove usage of standard library in header files. Private implementation pattern can be used to solve this problem.
• [x] 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 e381d080ad242e71ced27993436a652e8b11fcd8.

[end2endzone]

From commit 5b59f646b8b18fdb4a6761b8ce4fbcfd28c86258 :

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

e381d080ad242e71ced27993436a652e8b11fcd8 2792c8138e56f3cc07efea780056f8a3a759cd79 88722adbddca3b83cddababf43dd0ec26387647f af0dd4d0f010e5e965cf54d4ee8b50032b0d7ac5 4d1a67ca2bbf1ce3bf5ed5397afeef32fe858714 7904429f91872e0bccec233f5c5a8a855334528a 9b6d925e2db66f4a3b8177fa46f60f725c61ce4a 3960a4c20af6148c1c019ca7772f76b2448daf42 60df74568ec5d8ddb53d3b3bd42285b4db4540c8 934d0616988cb2a13759c2a1f891695250ed76f1 01fc6fbfe9fae6b770cae20b6b45ba627e64a37e deccf01173ce5a01491f1537736bf552427f6907

[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 5b59f646b8b18fdb4a6761b8ce4fbcfd28c86258. 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.