-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add ext_iterator_interface_compat
, a portable alternative to iterator_interface
.
#13
Conversation
Added a build option, BEMAN_ITERATOR_INTERFACE26_USE_DEDUCING_THIS, that switches between the deducing this implementation and that used by stl_interfaces. It defaults to whether the compiler supports deducing this. This element of configuration is placed in a generated config.hpp. This was chosen, as opposed to using a define passed as a compiler flag, to avoid ODR violations with larger projects with incoherent flag usage. The `iterator_interface_access` struct was moved to its own header since it is needed by both the deducing this and stl_interfaces implementations. The stl_interfaces implementation was modifed to use this so it better conforms to the paper. Some cleanup is still needed before this gets merged in: - There are optional26 remnants where stl_interfaces was brought in from. - Documentation is needed to explain when the extra template parameter is required. BEMAN_ITERATOR_INTERFACE26_USE_DEDUCING_THIS() should probably also be mentioned in that context. The intent is to address these once the overall approach has consensus. Fixes bemanproject#10 and depends on bemanproject#12.
843054c
to
8cf8b53
Compare
This fixes an issue where testing wasn't enabled by default. I followed the suggestion made at bemanproject/exemplar#60 (comment)
This is more ergonomic than having two different versions of interator_interface without having different names.
iterator_interface
.
iterator_interface
.ext_iterator_interface_compat
, a portable alternative to iterator_interface
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this was part of this change, but
https://github.com/beman-project/iterator_interface/pull/13/files#diff-7d7f79f7e81b3a5127eb407b43c39c90befb00593ef4d6721ee28edf4e87f9f9R179-R184
is now generating a dangling temporary warning?
Added #15 to address this. I couldn't figure out the cause with an initial look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM+
The
iterator_interface
class template requires deducing *this support which came in C++23 and is not yet widely available. This PR introduces an alternative class templateext_iterator_interface_compat
which requires an additional template argument (for RAII support), but otherwise has the same functionality ofiterator_interface
without the deducing *this dependency.ext_
to make it clear that this is an extension to theiterator_interface
paper. It may be interesting to adopt this as a convention for Beman libraries in general.BEMAN_ITERATOR_INTERFACE26_USE_DEDUCING_THIS
, thatindicates whether deducing *this is available. This element of configuration is placed in a generated
config.hpp
. This was chosen, as opposed to using a define passed as a compiler flag, to avoid ODR violations with larger projects with incoherent flag usage.ext_iterator_interface_compat
is implemented withiterator_interface
. If it is not available, instantiation ofiterator_interface
results in a helpful error message andext_interator_interface_compat
is implemented using an in-source copy ofBoost.Stl_Interfaces
with the following modifications:beman::iterator_interface26::iterator_interface_access
for access control for consistency.The intent is to add documentation in a separate PR once this gets moved in.
Fixes #10.