Skip to content

messy and hardcoded types in alias defintions in datatypes.h #419

Open

Description

@klappi-s

1

In src/manager/datatypes.h we have leftover code inherited form the old alpine/ExamplesWithoutPicManager/chargedparticles.hpp, where an alias for a partially specialized ippl::field template with hardcoded type double is set.

This should be avoided:

template <typename T, unsigned Dim = 3, class... ViewArgs>
using Field = ippl::Field<T, Dim, Mesh_t<Dim>, Centering_t<Dim>, ViewArgs...>;

template <unsigned Dim, class... ViewArgs>
using Field_t = Field<double, Dim, ViewArgs...>;

template <typename T = double, unsigned Dim = 3, class... ViewArgs>
using VField_t = Field<Vector_t<T, Dim>, Dim, ViewArgs...>;

2

Further the template defaults and the use of the subscript _t in the whole file seem to be somewhat inconsistent...

3 minimal fix preposition:

Create meaningful distinction between Field and Field_t and Vector and Vector_t, we could include default template specialisations for aliases with subscript _t similar to the different other aliases in datatypes.h:

e.g:

template <typename T, unsigned Dim >
using Vector = ippl::Vector<T, Dim>;

template <typename T = double, unsigned Dim = 3>
using Vector_t = ippl::Vector<T, Dim>;

template <typename T, unsigned Dim, class... ViewArgs>
using Field = ippl::Field<T, Dim, Mesh_t<Dim>, Centering_t<Dim>, ViewArgs...>;

template <typename T=double, unsigned Dim=3, class... ViewArgs>
using Field_t = Field<double, Dim, ViewArgs...>;

template <typename T = double, unsigned Dim = 3, class... ViewArgs>
using VField_t = Field<Vector_t<T, Dim>, Dim, ViewArgs...>;

3.1

good -> with this the use in our examples in alpine, cosmology etc with Field_t<3> should still be valid?
bad -> need to check we don't rely on default of alias of Field<T, Dim=3>
(+ maybe issue deprecation warning of default? )

template <typename T, unsigned Dim = 3, class... ViewArgs>
using Field = ippl::Field<T, Dim, Mesh_t<Dim>, Centering_t<Dim>, ViewArgs...>;

4 in General

create "uniform meaning" for the use of _t in type aliases and maybe extend this concept further tothe other type aliases...

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions