Hi,
On 11/05/2013 04:51 PM, Jonathan Wakely wrote:
On 3 November 2013 11:30, Paolo Carlini wrote:
On 11/03/2013 12:19 PM, Jonathan Wakely wrote:
Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
patch coming. Luc is there any reason not to just replace all those large
cons
On 3 November 2013 11:30, Paolo Carlini wrote:
> On 11/03/2013 12:19 PM, Jonathan Wakely wrote:
>>
>> Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
>> patch coming. Luc is there any reason not to just replace all those large
>> constants with 0x1234ABCD, which fits in a lon
On 2013-11-03 12:19, Jonathan Wakely wrote:
On 3 November 2013 09:49, Andreas Schwab wrote:
Jonathan Wakely writes:
+ {
+std::experimental::optional o { std::experimental::in_place,
0x1234ABCDF1E2D3C4 };
+auto copy = o;
+VERIFY( copy );
+VERIFY( *copy == 0x1234ABCDF1E2D3C4 )
On 11/03/2013 12:19 PM, Jonathan Wakely wrote:
Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
patch coming. Luc is there any reason not to just replace all those
large constants with 0x1234ABCD, which fits in a long on 32-bit targets?
By the way, that's what I did/hacke
On 3 November 2013 09:49, Andreas Schwab wrote:
> Jonathan Wakely writes:
>
>> + {
>> +std::experimental::optional o { std::experimental::in_place,
>> 0x1234ABCDF1E2D3C4 };
>> +auto copy = o;
>> +VERIFY( copy );
>> +VERIFY( *copy == 0x1234ABCDF1E2D3C4 );
>> +VERIFY( o && o ==
Jonathan Wakely writes:
> + {
> +std::experimental::optional o { std::experimental::in_place,
> 0x1234ABCDF1E2D3C4 };
> +auto copy = o;
> +VERIFY( copy );
> +VERIFY( *copy == 0x1234ABCDF1E2D3C4 );
> +VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
> + }
experimental/optional/cons/
On 2013-11-02 23:31, Paolo Carlini wrote:
In general we are very careful with code bloat, but free functions which just
forward to other functions should be definiyely inline, otherwise typically at
widely used optimization levels like -O2 users get suboptimal performance for
no reason. But
Hi
>I see. It didn't occur to me to declare it inline, as I only ever use
>the keyword to satisfy
>ODR requirements. E.g. the non-member swap isn't declared inline
>either.
>
>For future reference, is there a rule of thumb in use?
In general we are very careful with code bloat, but free functio
On 2013-11-02 19:02, Paolo Carlini wrote:
Can you expand? I think it's just as much inline as the other overload
-- does it need to be different?
The other overload is constexpr thus it's implicitly inline. The fall back is
very simple too and I think it should be declared inline, unless you
>Can you expand? I think it's just as much inline as the other overload
>-- does it need to be different?
The other overload is constexpr thus it's implicitly inline. The fall back is
very simple too and I think it should be declared inline, unless you analyzed
the assembly and believe it norm
On 2013-11-01 21:46, Paolo Carlini wrote:
Hi,
Il giorno 01/nov/2013, alle ore 21:09, Jonathan Wakely
ha scritto:
Here's the final version of Luc's optional implementation that I'm
committing, tested on x86_64-linux.
Great. Just noticed a minor nit: the fallback __constexpr_addressof appears
Hi,
> Il giorno 01/nov/2013, alle ore 21:09, Jonathan Wakely
> ha scritto:
>
> Here's the final version of Luc's optional implementation that I'm
> committing, tested on x86_64-linux.
Great. Just noticed a minor nit: the fallback __constexpr_addressof appears not
to be inline.
Paolo
Doh, that had yesterday's date on the ChangeLog entry, I've just fixed
it with the next commit.
On 1 November 2013 20:09, Jonathan Wakely wrote:
> Here's the final version of Luc's optional implementation that I'm
> committing, tested on x86_64-linux.
>
> (It occurs to me that we might want to mo
13 matches
Mail list logo
