Stream: brlcad

Topic: c++ headers


view this post on Zulip Sean (May 27 2020 at 05:02):

@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.

view this post on Zulip Sean (May 27 2020 at 05:05):

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.

view this post on Zulip Sean (May 27 2020 at 05:12):

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.

view this post on Zulip starseeker (May 27 2020 at 12:25):

@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).

view this post on Zulip Sean (Jun 02 2020 at 07:24):

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: Oct 09 2024 at 00:44 UTC