On 2/28/2011 11:40 PM, Nate Knight wrote:
>
> On Feb 26, 2011, at 4:55 AM, Eric Niebler wrote:
>>
>> I think I know what's causing this. Can you try compiling with
>> BOOST_PROTO_STRICT_RESULT_OF?
>
> Eric,
>
> Thanks for the information. Compiling with BOOST_PROTO_STRICT_RESULT_OF
> allows the
On Feb 26, 2011, at 4:55 AM, Eric Niebler wrote:
> On 2/26/2011 8:18 AM, Nate Knight wrote:
>>
>> int main()
>> {
>>la::state_type x = {1.0,2.0};
>>la::state_type const& xc = x;
>>
>>// this compiles
>>la::EvalOpt()( lit(x)[1] );
>>
>>// this fails to compile
>>//la::Ev
On 26/02/11 12:55, Eric Niebler wrote:
But maybe it wouldn't hurt. Maybe RVO kicks in. It's worth testing. Joel
F., are you listening? Yours is probably the most performance sensitive
application of Proto. Can you try compiling with
BOOST_PROTO_STRICT_RESULT_OF and let us know if there's a perf h
On 2/26/2011 8:18 AM, Nate Knight wrote:
> I'm trying to understand why the two commented out lines fail to compile. It
> seems to me
> that ideally they would compile, but I may be missing some constraint that
> makes these
> lines incorrect. In the first case, it seems like the return type
On 26/02/11 02:18, Nate Knight wrote:
I'm trying to understand why the two commented out lines fail to compile. It
seems to me
that ideally they would compile, but I may be missing some constraint that
makes these
lines incorrect. In the first case, it seems like the return type of the
defau
I'm trying to understand why the two commented out lines fail to compile. It
seems to me
that ideally they would compile, but I may be missing some constraint that
makes these
lines incorrect. In the first case, it seems like the return type of the
default subscript evaluator
is being compu
