We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In anticipation of new modules in the source code, the public header files should be re-organized.
include/us
include/<module>
All header files will be stripped of the "us" prefix and the us namespace will not be optional / changeable any more.
us
Header files also must not depend on configured information.
The text was updated successfully, but these errors were encountered:
@jeffdiclemente I like this idea ... headers in specific folders avoids conflict with similar named headers in global scope.
Would it make sense to use include/CppMicroServices instead of include/us ? I think it helps with readability in client code.
#include "CppMicroServices/Bundle.hpp" vs #include "us/Bundle.hpp"
#include "CppMicroServices/Bundle.hpp"
#include "us/Bundle.hpp"
Sorry, something went wrong.
You are right, it is definitely more expressive, but also a lot more to type. I would like to get opinions from more people about this.
I like #include "us/Bundle.hpp"
kevinleeMW
No branches or pull requests
In anticipation of new modules in the source code, the public header files should be re-organized.
include/us
include/<module>
All header files will be stripped of the "us" prefix and the
us
namespace will not be optional / changeable any more.Header files also must not depend on configured information.
The text was updated successfully, but these errors were encountered: