On 06/03/19 11:56 +0200, Ville Voutilainen wrote:
On Wed, 6 Mar 2019 at 11:33, Jonathan Wakely wrote:
>+ else if constexpr (is_rvalue_reference_v<_Tp&&>)
I know what this is doing, but it still looks a little odd to ask if
T&& is an rvalue-reference.
Would it be clearer to structure this
On Wed, 6 Mar 2019 at 11:56, Ville Voutilainen
wrote:
> > This one definitely needs to be cast to void* and needs to use
> > addressof (or __addressof), otherwise ...
>
>
> Sure thing; an incremental diff attached.
And here's the whole shebang.
diff --git a/libstdc++-v3/include/std/variant b/libs
On Wed, 6 Mar 2019 at 11:33, Jonathan Wakely wrote:
> >+ else if constexpr (is_rvalue_reference_v<_Tp&&>)
>
> I know what this is doing, but it still looks a little odd to ask if
> T&& is an rvalue-reference.
>
> Would it be clearer to structure this as:
>
> if constexpr (is_lvalue_refe
On 05/03/19 23:27 +0200, Ville Voutilainen wrote:
On Mon, 4 Mar 2019 at 01:43, Ville Voutilainen
wrote:
On Mon, 4 Mar 2019 at 01:26, Ville Voutilainen
wrote:
> I consider variant to no longer be in the state of sin after this.
Sigh, except for the places where it self-destructs or placement-
On Mon, 4 Mar 2019 at 01:43, Ville Voutilainen
wrote:
>
> On Mon, 4 Mar 2019 at 01:26, Ville Voutilainen
> wrote:
> > I consider variant to no longer be in the state of sin after this.
>
> Sigh, except for the places where it self-destructs or placement-news
> over things that it shouldn't. That'
On 04/03/19 01:26 +0200, Ville Voutilainen wrote:
On Wed, 6 Feb 2019 at 15:12, Ville Voutilainen
wrote:
And, to emphasize, the most important reason for this was to be able
to write straightforward
code for the special member functions, with the hope that it wouldn't
have a negative codegen
ef
On Mon, 4 Mar 2019 at 01:26, Ville Voutilainen
wrote:
> I consider variant to no longer be in the state of sin after this.
Sigh, except for the places where it self-destructs or placement-news
over things that it shouldn't. That's hopefully
the next bit that I'll rectify, Real Soon Now.
On Wed, 6 Feb 2019 at 15:12, Ville Voutilainen
wrote:
> And, to emphasize, the most important reason for this was to be able
> to write straightforward
> code for the special member functions, with the hope that it wouldn't
> have a negative codegen
> effect. Our Microsoft friends described the g
On Wed, 6 Feb 2019 at 12:21, Ville Voutilainen
wrote:
> > I think the assumption was this would produce smaller code. Does that
> > hold true?
>
> I think the assumption was that this produces equivalent or better
> code than fixing the current
> semantics bugs with some sort of separate constexpr
On Wed, 6 Feb 2019 at 12:13, Jonathan Wakely wrote:
> Did you compare the codegen?
No. Getting the metaprograms to work took all the time I had thus far. :)
> I think the assumption was this would produce smaller code. Does that
> hold true?
I think the assumption was that this produces equival
On 06/02/19 00:05 +0200, Ville Voutilainen wrote:
Okay then. This patch takes the hopefully biggest steps towards
a std::variant rewrite. The problem we have with the current
approach is that we'd really like to write fairly straightforward
code for variant's special member functions, but can't,
Okay then. This patch takes the hopefully biggest steps towards
a std::variant rewrite. The problem we have with the current
approach is that we'd really like to write fairly straightforward
code for variant's special member functions, but can't, because
the specification suggests fairly straightfo
12 matches
Mail list logo
