Opened 7 years ago
Closed 4 years ago
#11869 closed Bugs (invalid)
Boost should consistently use BOOST_ for all #defines and standardize header guards
Reported by: | Owned by: | ||
---|---|---|---|
Milestone: | To Be Determined | Component: | None |
Version: | Boost 1.61.0 | Severity: | Problem |
Keywords: | Cc: |
Description
I use boost in my own code, and I've recently had to make it work with a 3rd party that uses boost as well, but they're on a different version. Getting them to update versions is going to take a long time, and I have no other choice of vendor for this particular product, so a coworker was forced to write a script to try and rename all the #defines and symbol names (boost -> bxxst) in order to have the two versions coexist in the same binary.
This works, but it's forced to have a lot of special cases due to two issues:
-Header guard style is basically random, I've seen 5+ different variants.
-A random assortment of #define's that have no indication in their name that they come from boost that I have to just hard code into my script.
Seeing as the first is a style inconsistency it would be desirable to fix anyway, and the latter is bad for interoperability with other libraries (prefixing #define's with your library's name is pretty standard practice in the C/C++ world), and I've heard of others dealing with my problem before, I figured it merited a bug report.
Fixing it won't help me for now because any changes will only be in newer versions obviously, but it would it make it easier to deal with going forward and have the other mentioned benefits.
Change History (2)
comment:1 by , 7 years ago
comment:2 by , 4 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I'd suggest to do the following:
- Submit pull request with your proposal of
development/requirements.html
changes to https://github.com/boostorg/website/blob/master/ - Post your proposal to the Boost mailing list with request for comments
- Create new issue for each concerned library separately at https://github.com/boostorg/ as @viboes suggests
For the second point I recommend you to create a ticket for each concerned library as concrete as possible.
For the first point, I believe that the battle is lost in advance.