[Problem] Possible design flaw about overloaded method

[wwmayer]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

In ComplexGeoData there is this virtual method declared:

    virtual ElementMapPtr resetElementMap(ElementMapPtr elementMap = ElementMapPtr(),
                                          ElementMapResetPolicy forceEmpty = ForceEmptyMap);

In the sub-class TopoShape a method with the same name but different number of arguments is re-defined

    virtual Data::ElementMapPtr resetElementMap(
        Data::ElementMapPtr elementMap=Data::ElementMapPtr());

Because the method has a different signature it overloads the method of the base class instead of overriding it. This leads to the compiler warning: 'Part::TopoShape::resetElementMap' hides overloaded virtual function [-Woverloaded-virtual]
Because TopoShape is a central class that is used by a lot of classes directly or indirectly a full rebuild prints this warning a several thousand times.

Usually, in such cases one could add this line to the class declaration of TopoShape:
using ComplexGeoData::resetElementMap;
but because in both versions all argument are optional this leads of course to an error that resetElementMap is ambiguous.

So, this is a strong indication that there is a design flaw which may result into unexpected behaviour.

Full version info

Not relevant here

Subproject(s) affected?

Part

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bgbsww]

This crept in as part of the toponaming work, and is ultimately related to the elementMap in ComplexGeoData not being initialized before being used in some cases. The correct solution is likely to revert to code without the forceEmpty parameter which resolves the design flaw that was created. There is active work on solving the null elementMap problem in the toponaming team; I expect this to be resolved shortly.