re-visit the design of customisation points
Currently, the property parser uses:
using Gaudi::Parsers::parse;
auto sc = parse(T& dest, const std::string& source)
to parse items of type T
. In case T
is a user-defined type, this implies that a suitable overload of parse
must be found, either because it is injected in the namespace Gaudi::Parsers
, or it is looked up by ADL. In practice, this implies that one eg. adds a friend StatusCode parse(MyType&,const std::source&)
in the declaration of class MyType
. However, in case T
is eg. a container defined in the std
namespace, one is not allowed to inject parse
into the std
namespace, and one has to define a parse
in Gaudi::Parsers
. But this must be done prior to the use of this function, which happens to be in the Property.h header (as it is used in a templated function). So one must take care to make the declaration of parse
available prior to the inclusion of Property.h, which can be difficult, and brittle as Property.h may be included indirectly, and the order may change.
There are other techniques available, see eg here, and here, and even this standards proposal, and we should investigate whether these alternatives are applicable, and more robust -- especially because I expect that we will want more customisation points to make it easier to extend the framework.