This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/23668 (FNAL account required)
Originally created by @PetrilloAtWork on 2019-11-29 22:40:11
FHiCL officially supports get'ing and put'ing custom data types via encode() and decode() functions.
In my experience, this is often done parsing a parameter in the standard FHiCL way, and then taking further actions. The most common action I take is to decode() a parameter into a C++ string and then parse it.
FHiCL standard types (including std::string) already do that, and do it right. It would be useful for them to be exposed to the public interface rather than being hidden behind the implementation detail wall.
In alternative, functionally-equivalent functions might be provided (e.g. fhicl::decodeParameter(std::any, std::string&) etc.).
Also, part of the public protocol (encode's return values ps_atom_t and ps_sequence_t) are currently behind the same wall.
This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/23668 (FNAL account required)
Originally created by @PetrilloAtWork on 2019-11-29 22:40:11
FHiCL officially supports
get'ing andput'ing custom data types viaencode()anddecode()functions.In my experience, this is often done parsing a parameter in the standard FHiCL way, and then taking further actions. The most common action I take is to
decode()a parameter into a C++ string and then parse it.FHiCL standard types (including
std::string) already do that, and do it right. It would be useful for them to be exposed to the public interface rather than being hidden behind the implementationdetailwall.In alternative, functionally-equivalent functions might be provided (e.g.
fhicl::decodeParameter(std::any, std::string&)etc.).Also, part of the public protocol (
encode's return valuesps_atom_tandps_sequence_t) are currently behind the same wall.