Skip to content
New issue

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

Master list of macro and symbol collision issue reports in all Boost libraries #352

Open
ned14 opened this issue Dec 16, 2019 · 5 comments

Comments

@ned14
Copy link
Member

ned14 commented Dec 16, 2019

Hopefully github will draw a line through each of these as/if they get closed so one can see an overview of progress. When/if they are all closed, build tooling ought to add a build-time check to prevent breakage of Boost library guidelines in the future.

@apolukhin
Copy link
Member

Can the boost.inspect tool be tought to detect non BOOST_ prefixed maceo?

@apolukhin
Copy link
Member

Can the boost.inspect tool be tought to detect non BOOST_ prefixed maceo?

Oh, you've already done a PR #353

@hkaiser
Copy link
Contributor

hkaiser commented Dec 18, 2019

I would like to suggest to exclude macro symbols that are used as #include guards and are otherwise guaranteed to be unique (either contain a data/time or a guid) for this. Adding a BOOST_ prefix to those does not add anything but additional effort on behalf of library maintainers.

@pdimov
Copy link
Member

pdimov commented Dec 18, 2019

The motivation for consistently applying a BOOST_ prefix even to unique include guards is that companies want to prepare private Boost releases (that can coexist with the official one, or with another private one) by renaming BOOST_ to f.ex. MYBOOST_.

@hkaiser
Copy link
Contributor

hkaiser commented Dec 18, 2019

@pdimov Thanks Peter. Makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants