Hi
Any conclusion regarding this thread ?
François
On 06/10/21 7:25 pm, François Dumont wrote:
I forgot to ask if with this patch this overload:
template<typename _Ptr, typename... _None>
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>)
return std::__to_address(__ptr.base().operator->());
else
return std::__to_address(__ptr.operator->());
}
should be removed ?
Or perhaps just the _Safe_iterator_base branch in it ?
On 06/10/21 7:18 pm, François Dumont wrote:
Here is another proposal with the __to_address overload.
I preferred to let it open to any kind of __normal_iterator
instantiation cause afaics std::vector supports fancy pointer types.
It is better if __to_address works fine also in this case, no ?
libstdc++: Overload std::__to_address for
__gnu_cxx::__normal_iterator.
Prefer to overload __to_address to partially specialize
std::pointer_traits because
std::pointer_traits would be mostly useless. In the case of
__gnu_debug::_Safe_iterator
the to_pointer method is even impossible to implement correctly
because we are missing
the parent container to associate the iterator to.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h
(std::pointer_traits<__gnu_cxx::__normal_iterator<>>): Remove.
(std::__to_address(const
__gnu_cxx::__normal_iterator<>&)): New.
* include/debug/safe_iterator.h
(std::__to_address(const
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<>,
_Sequence>&)):
New.
* testsuite/24_iterators/normal_iterator/to_address.cc:
Add check on std::vector::iterator
to validate both __gnu_cxx::__normal_iterator<>
__to_address overload in normal mode and the
Tested under Linux x86_64.
Ok to commit ?
François
On 04/10/21 10:30 pm, Jonathan Wakely wrote:
On Mon, 4 Oct 2021 at 21:28, François Dumont via Libstdc++
<libstd...@gcc.gnu.org> wrote:
On 04/10/21 10:05 pm, François Dumont wrote:
On 02/10/21 10:24 pm, Jonathan Wakely wrote:
On Sat, 2 Oct 2021 at 18:27, François Dumont wrote:
I would like to propose this alternative approach.
In this patch I make __normal_iterator and random iterator
_Safe_iterator compatible for pointer_traits primary template.
Regarding pointer_traits I wonder if it shouldn't check for the
to_pointer method availability and use per default: return {
std::addressof(__e) }; otherwise. This way we wouldn't have to
provide a
pointer_to method on __normal_iterator.
But I would rather not have these members present in
vector::iterator
and string::iterator, in case users accidentally start to rely on
them
being present.
Making pointer_traits friends would help but I do not like it
neither.
Another option would be to overload std::__to_address so it knows
how
to get the address from __normal_iterator and _Safe_iterator.
.
I start thinking that rather than proposing not-useful and even
incorrect code in the case of the _Safe_iterator<> it might be a
better approach.
Even the rebind for __normal_iterator is a little strange because
when
doing rebind on std::vector<int>::iterator for long it produces
__normal_iterator<long*, std::vector<int>>, quite inconsistent
even if
useless.
