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

Remove Boost from API #480

Merged
merged 5 commits into from Oct 25, 2017
Merged

Remove Boost from API #480

merged 5 commits into from Oct 25, 2017

Conversation

emccorkle
Copy link

Removes Boost headers from the API. This removes the requirement for clients to have these headers when building against Cantera.

I tried to make this as backwards compatible as possible (minor/patch). The only real non-backwards compatible pieces are the removal of the (directly unused) boost header/namespace from stringUtils.h and possibly the change to the size/layout of AnyValue). Otherwise, it is opt-in with CANTERA_API_NO_BOOST.

It seems that the generic capability of AnyMap/AnyValue isn't really used within Cantera or on its interface so it could probably just be removed if you were interested in breaking changes to the API. It is technically used in a couple places but they are all calls like as that could be replaced by asString.

@codecov
Copy link

codecov bot commented Oct 23, 2017

Codecov Report

Merging #480 into master will increase coverage by 0.03%.
The diff coverage is 58.12%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #480      +/-   ##
==========================================
+ Coverage   59.94%   59.98%   +0.03%     
==========================================
  Files         382      383       +1     
  Lines       40677    40758      +81     
  Branches     6807     6810       +3     
==========================================
+ Hits        24385    24448      +63     
- Misses      14317    14333      +16     
- Partials     1975     1977       +2
Impacted Files Coverage Δ
include/cantera/base/AnyMap.h 100% <ø> (ø) ⬆️
src/thermo/PhaseCombo_Interaction.cpp 0% <0%> (ø) ⬆️
src/transport/TransportData.cpp 76.25% <0%> (ø) ⬆️
src/thermo/PDSS_IonsFromNeutral.cpp 71.9% <0%> (ø) ⬆️
src/thermo/MixedSolventElectrolyte.cpp 0% <0%> (ø) ⬆️
src/thermo/MolarityIonicVPSSTP.cpp 0% <0%> (ø) ⬆️
src/transport/LiquidTranInteraction.cpp 0% <0%> (ø) ⬆️
src/thermo/PDSS_HKFT.cpp 67.32% <0%> (ø) ⬆️
src/thermo/IdealSolnGasVPSS.cpp 56.2% <0%> (ø) ⬆️
src/thermo/MaskellSolidSolnPhase.cpp 64.91% <0%> (ø) ⬆️
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6844e52...b5b13b1. Read the comment docs.

Copy link
Member

@speth speth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for submitting this PR -- I'm certainly supportive of minimizing dependencies for downstream code. It's probably worth adding something regarding this particular issue in CONTRIBUTING.md, e.g. that Boost includes should not be made in the public interface, except if wrapped in #ifndef CANTERA_API_NO_BOOST.

If I'm reading this correctly, the only capability that you lose if you define CANTERA_API_NO_BOOST is that you can't instantiate any new specializations of anyValue.as<T>() etc., is that right? If so, that should be fine. This is a new feature added since the last release in any case, so backwards compatibility is not a concern.

#include <string>
#include <vector>
#include <memory>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should come in implicitly via global.h -> ct_def.h.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll let those chain-include then.

{

// Definitions for templated functions which require the full declaration of
// class AnyValue/AnyMap.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is no longer just those functions that require the full class declaration -- it's all of the definitions.


#include <string>
#include <vector>
#include <unordered_map>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of these includes are redundant with what's already coming in via AnyMap.h

src/base/xml.cpp Outdated
#include <sstream>
#include <fstream>

namespace ba = boost::algorithm;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering whether it would be better to just have wrappers in stringUtils.h/cpp for the 3 functions that are being used over and over again (iequals, to_lower_copy, and trim_copy), rather than the extra include and namespace declaration in so many files. Thoughts?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started down this exact path with a to_lower_copy wrapper but abandoned it as scope creep when I started hitting more "ba" functions. I do think it would be better to try to corral most of the boost usage into a couple files so I'll try another pass since it may be just those three functions.

@@ -5,6 +5,10 @@

#include "cantera/base/AnyMap.h"

#ifdef CANTERA_API_NO_BOOST
#include "cantera/base/AnyMap.inl.h"
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be unnecessary, right? CANTERA_API_NO_BOOST should never be defined when compiling Cantera, so the .inl file should have been included via AnyMap.h.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. This was an artifact from when I thought I need to do something at compile time. Removed!

@emccorkle
Copy link
Author

If I'm reading this correctly, the only capability that you lose if you define CANTERA_API_NO_BOOST is that you can't instantiate any new specializations of anyValue.as() etc., is that right?

That is correct.

@speth speth merged commit 83ffd84 into Cantera:master Oct 25, 2017
@emccorkle emccorkle deleted the rm-boost branch October 26, 2017 14:11
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

Successfully merging this pull request may close these issues.

None yet

2 participants