[Rivet] Dangerous casting to FinalState

[David Grellscheid]

The sequence

  Type label = foobar;

always calls a copy constructor of Type, it _never_ calls operator=().

If the copy constructor Type(Type) is not user-defined, it will be
created implicitly.

In your case, a FinalState(const FinalState &) will be created and used
as long as the result type of zfinder.remainingFinalState() is a
descendant of FinalState.

  David


On 08/07/15 09:14, Chris Pollard wrote:
> 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 <mailto: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
> 
>