@starseeker up until now, our public headers have been intentionally C headers with C++ types limited to the brep bits. I think we should keep things that way.
While there's no problem having C libraries that make use of C++ in the backend implementation, it's a whole other can of worms to expose C++ in a public header for any of those libs. STL types are particularly problematic.
From a design standpoint, HACKING intentionally calls out the api and handling of C++. It does so to help ensure that the API remains clean, consistent, and compatible among other desirable traits.
@Sean Agreed - I was thinking about internal, private headers, which may be C++ - I wasn't sure if in that case you wanted to specify hpp (similar to how cpp is preferred over cxx).
I see no benefit to requiring it be either way for implementation code. I would probably switch the few .hpp's to .h before trying to label all the c++ .h's as .hpp's just as the shorter of paths to homogeny, but it would be to no productive end. it's not causing any problem that I'm aware of, thus HACKING wouldn't have merit dictating.
Last updated: Jan 09 2025 at 00:46 UTC