[martis42]

Related to #263

This does not change the preprocessing logic. C++14 did not add or changelanguage features relevant for preprocessing. However, we require an explicit C++14 mode so we can set __cplusplus correctly during preprocessing of C++14 projects.

As agreed on in #264 we are from now on using the concrete names need_cpp14() and BOOST_WAVE_SUPPORT_CPP14 instead of cpp1y.

I did think again about all the BOOST_WAVE_SUPPORT_CPP* macros. There was the idea of not using macros anymore for new standards. Besides this missing final confirmation, this does imho not apply to C++14, which is sandwiched in between standards already using the macro pattern.

---

A note on BOOST_WAVE_SUPPORT_CPP* beyond what this PR does.

Imho we can't drop the macro pattern from new standards like C++26. Adding C++26 guarded only behind the language setting interface means one can no longer opt out supporting / compiling newer languages standards by manipulating BOOST_WAVE_SUPPORT_CPP*. In other words, adding C++26 without the macros would break the pattern created by the language macros. To my understanding getting rid of the language level macros is only feasible in a sane and consistent matter by starting with the oldest language standards. Meaning, first removing BOOST_WAVE_SUPPORT_CPP0X, then BOOST_WAVE_SUPPORT_CPP14, then BOOST_WAVE_SUPPORT_CPP1Z and so on. At least from a logical and consistency point of view.

I would be willing to have a look at such a cleanup. I believe it is either a lot of trivial changes and done without taking too much time, or one finds fastish places not working with only the language selection interface as input and this is a result too.
That much said, I would not do anything until there is a clear agreement:

• It is fine to change the code in a lot of places "just" for the sake of making it simpler / easier to maintain
• We are reasonably sure boost.wave is not used in some project where performance is highly critical and they use old C/C++, where they would not want code with if/else branches never relevant for them.
• It is fine to have a breaking change taking away the BOOST_WAVE_SUPPORT_CPP* macros from users with the argumentation the programmatic language feature selection is to be used.

[codecov]

Codecov Report

❌ Patch coverage is 33.33333% with 14 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (develop@f88fdd4). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...ude/boost/wave/cpplexer/re2clex/cpp_re2c_lexer.hpp	40.00%	0 Missing and 3 partials ⚠️
include/boost/wave/util/cpp_macromap.hpp	40.00%	1 Missing and 2 partials ⚠️
include/boost/wave/util/cpp_macromap_predef.hpp	0.00%	3 Missing ⚠️
test/testwave/testwave_app.cpp	33.33%	0 Missing and 2 partials ⚠️
samples/cpp_tokens/slex/cpp_slex_lexer.hpp	0.00%	0 Missing and 1 partial ⚠️
samples/list_includes/lexertl/lexertl_lexer.hpp	0.00%	0 Missing and 1 partial ⚠️
samples/token_statistics/xlex/xlex_lexer.hpp	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             develop     #275   +/-   ##
==========================================
  Coverage           ?   33.90%           
==========================================
  Files              ?       76           
  Lines              ?     7391           
  Branches           ?     4105           
==========================================
  Hits               ?     2506           
  Misses             ?     2369           
  Partials           ?     2516           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jefftrull]

Let's leave the macros alone for now, I think it's outside the scope of this work (beyond introducing CPP14, that is)

[jefftrull]

Thanks for this contribution! I see you caught a missing test for the module keyword - much appreciated.

Can I ask for the flag in t_5_014.cpp be changed to the new C++14 enablement? It tests digit separators. I guess we were using C++17 for that. I also see it's not checked anywhere 🤦 but that's not your fault.

[martis42]

Let's leave the macros alone for now, I think it's outside the scope of this work (beyond introducing CPP14, that is)

Should I create an issue as reminder for this topic? I definitely would not touch the macros in this PR. I just had no other place to share my thoughts and offer looking into it (if desired).

Can I ask for the flag in t_5_014.cpp be changed to the new C++14 enablement?

Done

[jefftrull]

Should I create an issue as reminder for this topic? I definitely would not touch the macros in this PR. I just had no other place to share my thoughts and offer looking into it (if desired).

Changing those macros is simultaneously very tedious and of low value IMO and if you are excited to work on Wave I would recommend you do something more fun :) Have you had a look at our issues? Also I'm interested in some cleanups, like:

1. code modernization - I think we could aim for C++17
2. Replacing the core Spirit Classic (deprecated) with something like Boost.Parser

although those may be larger projects

[martis42]

Should I create an issue as reminder for this topic? I definitely would not touch the macros in this PR. I just had no other place to share my thoughts and offer looking into it (if desired).

Changing those macros is simultaneously very tedious and of low value IMO and if you are excited to work on Wave I would recommend you do something more fun :) Have you had a look at our issues? Also I'm interested in some cleanups, like:

1. code modernization - I think we could aim for C++17
2. Replacing the core Spirit Classic (deprecated) with something like Boost.Parser

although those may be larger projects

I will try to work on some issues beyond C++ versions support, since my project depends on boost.wave in some configurations.

I have no strong opinion here. I am also fine not doing this. It was merely an offer. To me editing/maintaining the code seems needlessly tedious due to the macro pattern. That much said, it "only" gets worse every 3 years 😅

[jefftrull]

it "only" gets worse every 3 years

You've captured my feelings perfectly.

If you have a proposal for making this easier and feel motivated to work on it I have no objection. Still hoping @hkaiser can chime in on the original motivation and whether it still applies, in his opinion.