Project

General

Profile

Bug #18001

lar::ProviderPack should accept objects of classes derived from the required ones

Added by Gianluca Petrillo almost 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
Library
Target version:
-
Start date:
10/21/2017
Due date:
% Done:

100%

Estimated time:
1.00 h
Spent time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

The class lar::ProviderPack (larcorealg:source:larcorealg/CoreUtils/ProviderPack.h) is a tuple containing instances of service providers, one for each type in lar::ProviderPack template argument list. All of them must be provided, or a compilation error will ensue.

The current version requires the provider objects to be of the exact required type, which for example makes it impossible to initialise a pack requiring detinfo::LArProperties (provider interface class) with a detinfo::LArPropertiesStandard instance. While this can be worked around with a static cast, it would be better not to require such a cast.

The relevant check code is at larcorealg:source:larcorealg/CoreUtils/ProviderPack.h#L381 , where possibly std::is_same should be replaced by std::is_base_of or std::is_convertible.

Associated revisions

Revision 8e45d208 (diff)
Added by Gianluca Petrillo over 1 year ago

ProviderPack now supports initialisation from derived classes.

This should help with using parameter packs with provider interfaces.
This solves issue #18001.

History

#1 Updated by Gianluca Petrillo over 1 year ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

It was less trivial than I hoped... or I may have made the solution unnecessarily complex.
Either way, it is pushed in develop branch of larcorealg and it will be automatically part of the next LArSoft release (the one after v06_74_00).

#2 Updated by Gianluca Petrillo over 1 year ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF