Proposal: Use .hpp for headers when switching to the new package name #568
Comments
|
👍 It sounds reasonable. |
jslee02
added a commit
that referenced
this issue
Jan 13, 2016
Here are exceptions: ./kido/lcpsolver/matrix.h ./kido/lcpsolver/misc.h ./kido/lcpsolver/lcp.h ./kido/lcpsolver/error.h ./kido/lcpsolver/common.h ./kido/lcpsolver/odeconfig.h ./unittests/gtest/include/gtest/gtest_pred_impl.h ./unittests/gtest/include/gtest/gtest-spi.h ./unittests/gtest/include/gtest/gtest-message.h ./unittests/gtest/include/gtest/internal/gtest-filepath.h ./unittests/gtest/include/gtest/internal/gtest-string.h ./unittests/gtest/include/gtest/internal/gtest-tuple.h ./unittests/gtest/include/gtest/internal/gtest-linked_ptr.h ./unittests/gtest/include/gtest/internal/gtest-type-util.h ./unittests/gtest/include/gtest/internal/gtest-param-util.h ./unittests/gtest/include/gtest/internal/gtest-internal.h ./unittests/gtest/include/gtest/internal/gtest-port.h ./unittests/gtest/include/gtest/internal/gtest-death-test-internal.h ./unittests/gtest/include/gtest/internal/gtest-param-util-generated.h ./unittests/gtest/include/gtest/gtest_prod.h ./unittests/gtest/include/gtest/gtest-printers.h ./unittests/gtest/include/gtest/gtest-death-test.h ./unittests/gtest/include/gtest/gtest.h ./unittests/gtest/include/gtest/gtest-param-test.h ./unittests/gtest/include/gtest/gtest-test-part.h ./unittests/gtest/include/gtest/gtest-typed-test.h ./unittests/gtest/src/gtest-internal-inl.h
Merged
|
Addressed by #693 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In various discussions, I've heard interest in the idea of having C-bindings for DART since this would enable easier interfacing with other programming languages, and therefore easier integration into other frameworks. If someone were to implement C-bindings, the most natural file organization would be to have C API headers use
.hwhile C++ API headers use.hpp, but in our current file organization all the C++ headers are already using.h.Whether or not anyone is currently planning to implement C-bindings, I think it would be good to use the
.hppconvention to allow for a clear delineation between the existing C++ API and a C API in case one is ever created. Since the package will be undergoing a highly interruptive name change in the near future anyway, I think that would be the best possible time to make a change like this.The text was updated successfully, but these errors were encountered: