[Rivet] Dangerous casting to FinalState

[Chris Pollard]

but... going back to Frank's Example1: I don't see a FinalState(Projection)
constructor. Won't operator =(Projection) be called in the first line of

      FinalState remainder = zfinder.remainingFinalState();
      addProjection(remainder, "RFS");

since no appropriate constructor exists? Or will some implicit copy
constructor be called not via operator=?

Chris

On Tue, Jul 7, 2015 at 9:52 PM, David Grellscheid <
david.grellscheid at durham.ac.uk> wrote:

> Maybe the confusion comes from the fact that
>
>   Foo a = 7;
>
> does not call operator=(), but calls the constructor Foo(int). It's just a
> different way of writing a constructor. operator=() is only called here:
>
>   Foo a;
>   a = 7;
>
> I still haven't had a chance to look at it in detail, sorry!
>
> See you,
>
>   David
>
>
>
> On 07/07/2015 21:49, Andy Buckley wrote:
>
>> Hmm, I certainly implemented it hoping that code with copy assignments (as
>> opposed to copy constructions, which should perhaps also be banned to
>> forbid an alternative-syntax route to achieving the same misguided goal)
>> would now fail to compile. I based that on some StackOverflow reading
>> since
>> I was short of time to make an explicit test case of my own.
>>
>> I was *hoping* (and convinced from that reading) that it would not be
>> legal
>> for a private virtual method on a base class to be overloaded as public
>> (and certainly not *automatically*) on a derived class. It would be a huge
>> pain if those operators need to be *explicitly* private'd on every derived
>> Projection.
>>
>> Aaaaand back to holiday ;-)
>> AB
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20150708/9b78d204/attachment.html>