On Wed, 15 Dec 2021 at 21:16, François Dumont wrote:
> Here is what I eventually would like to commit.
>
> I was not able to remove the _Safe_iterator_base branch in ptr_traits.h.
> When adding the _Safe_iterator overload in C++20 and removing the branch
> the 20_util/to_address/debug.cc test
Here is what I eventually would like to commit.
I was not able to remove the _Safe_iterator_base branch in ptr_traits.h.
When adding the _Safe_iterator overload in C++20 and removing the branch
the 20_util/to_address/debug.cc test started to fail because it was not
calling my overload. I
On Tue, 14 Dec 2021 at 06:53, François Dumont wrote:
> 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
> > constexpr auto
> > __to_address(const _Ptr&
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
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
if constexpr
I forgot to ask if with this patch this overload:
template
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
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
On Mon, 4 Oct 2021 at 21:28, François Dumont via Libstdc++
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
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
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
On Sat, 2 Oct 2021 at 14:08, François Dumont wrote:
>
> On 02/10/21 12:29 am, Jonathan Wakely wrote:
> > On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
> > wrote:
> >> Here is the _Safe_iterator one.
> >>
> >> Doing so I noticed that pointer_traits rebind for __normal_iterator was
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
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:
On 02/10/21 12:29 am, Jonathan Wakely wrote:
On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
wrote:
Here is the _Safe_iterator one.
Doing so I noticed that pointer_traits rebind for __normal_iterator was
wrong and added tests on it.
Oops, thanks!
For _Safe_iterator maybe I
On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
wrote:
>
> Here is the _Safe_iterator one.
>
> Doing so I noticed that pointer_traits rebind for __normal_iterator was
> wrong and added tests on it.
Oops, thanks!
> For _Safe_iterator maybe I should specialize only when instantiated
Here is the _Safe_iterator one.
Doing so I noticed that pointer_traits rebind for __normal_iterator was
wrong and added tests on it.
For _Safe_iterator maybe I should specialize only when instantiated with
__normal_iterator ? Or maybe limit to random_access_iterator_tag ?
Whatever the
This allows std::__to_address to be used with __normal_iterator in
C++11/14/17 modes. Without the partial specialization the deduced
pointer_traits::element_type is incorrect, and so the return type of
__to_address is wrong.
A similar partial specialization is probably needed for
16 matches
Mail list logo
