9.1.p02 is -introducing- protected copy-ctr and operator= which before were not defined.
Making copies of solids is to be considered -illegal- in the user code and was not allowed in
9.1.p01 either.
The presence of copy-ctr and operator= is however required internally for proper handling
of composed solids like G4TessellatedSolid and their specialization G4ExtrudedSolid.
Any client code or package which imposes restrictions for such an update, is making an
improper use of the C++ interface defined for solids in Geant4, sorry...

Hello Gabriele,

I'm not sure I follow why the copy should be illegal.  Say, for example, I make some fairly complicated solid.  I want to save that as one solid for use in my description.  I then want to make a second solid that is the same as the first, with an additional boolean addition or subtraction.  It is illegal for me to copy the first and begin from there?

We had a problem with the interface for the python layer, where we were defining solids for (for example) detector envelopes.


Cheers,
Zach

> I'm not sure I follow why the copy should be illegal.  Say, for example, I make
> some fairly complicated solid.  I want to save that as one solid for use in my
> description.  I then want to make a second solid that is the same as the first,
> with an additional boolean addition or subtraction.  It is illegal for me to
> copy the first and begin from there?

You need to make two instances of the same solid.
Solids are unique entities in Geant4 that get registered at the time of construction,
it was not the case before 9.1.p02, where the copy constructor was not defined at all,
and forcing this would have been a real violation.
It is also true that we cannot change this rule in a patch.

> We had a problem with the interface for the python layer, where we were
> defining solids for (for example) detector envelopes.

This is not clear to me. Can you please elaborate what exactly is the problem ?

Hi Gabriele,

Now I think I understand a bit better myself, so I can try to explain.  In order to provide python access to some of our objects we have to use ROOT to create dictionaries of them.  Those objects inherit from G4VSolid (but do not implement a copy constructor).  When ROOT tries to make dictionaries, it requires several things, including a default constructor and a copy constructor.  So when ROOT tries to reflect these objects that inherit from G4VSolid, it complains that there is a protected copy constructor and dies.  Of course the copy constructor is not accessed - and we would be fine with a "Copy Constructor" that simply throws an exception - but with a protected copy constructor we cannot reflect the objects.

The only known work-around is to remove the classes from the dictionary.  That breaks some functionality, but it remains to be seen whether it is critical.


Thanks,
Zach

Hi Zach,

> In order to provide python access to some of our objects we have to use ROOT to
> create dictionaries of them.  Those objects inherit from G4VSolid (but do not
> implement a copy constructor).  When ROOT tries to make dictionaries, it
> requires several things, including a default constructor and a copy
> constructor.  So when ROOT tries to reflect these objects that inherit from
> G4VSolid, it complains that there is a protected copy constructor and dies.  Of
> course the copy constructor is not accessed - and we would be fine with a "Copy
> Constructor" that simply throws an exception - but with a protected copy
> constructor we cannot reflect the objects.

I see... this however looks to me mostly a limitation in ROOT which should be
eventually corrected.
The easiest thing I can propose is to promote to public the copy-ctor in G4VSolid
as a workaround... this is like adding a new feature in a patch, which in principle,
according to our rules in Geant4 is not allowed... If there is no objection from John
and Makoto here in CC, I have nothing against that and make it available in the
coming patch p03 for 9.1.

Cheers, Gabriele