alpaka-group / llama

A Low-Level Abstraction of Memory Access
https://llama-doc.rtfd.io/
Mozilla Public License 2.0
79 stars 10 forks source link

Allow string literals and reflection in/of record dimension #737

Closed bernhardmgruber closed 1 year ago

bernhardmgruber commented 1 year ago

Allows the following:

    using RecordDim = llama::Record<
        llama::NamedField<"x", int>, // NEW: NamedField with string literal
        llama::NamedField<"y", int>,
        llama::NamedField<"pos", Vec2F>,
        llama::Field<tag::Vel, llama::Record<llama::Field<tag::X, float>, llama::NamedField<"y", float>>>>;

    using namespace llama::literals;

    auto view = llama::allocView(llama::mapping::AoS{llama::ArrayExtents{1}, RecordDim{}});
    view(0)("x"_Name) = 1; // NEW: access with string literal (using literal operator _Name)
    view(0)("y"_Name) = 2;
    view(0)("pos"_Name, tag::X{}) = 3;
    view(0)("pos"_Name, tag::Y{}) = 4;
    view(0)(tag::Vel{}, tag::X{}) = 5;

Any better suggestions over NamedField and _Name?

And:

    struct MyVel
    {
        int x;
        int y;
    };
    BOOST_DESCRIBE_STRUCT(MyVel, (), (x, y));

    struct MyStruct
    {
        int a;
        int b;
        MyVel pos;
    };
    BOOST_DESCRIBE_STRUCT(MyStruct, (), (a, b, pos));

    using RecordDim = llama::ReflectToRecordDim<MyStruct>; // NEW
    auto view = llama::allocView(llama::mapping::AoS{llama::ArrayExtents{1}, RecordDim{}});

    using namespace llama::literals;

    view(0)("a"_Name) = 1;
    view(0)("b"_Name) = 2;
    view(0)("pos"_Name, "x"_Name) = 3;
    view(0)("pos"_Name, "y"_Name) = 4;
codecov[bot] commented 1 year ago

Codecov Report

Merging #737 (dc3a1b1) into develop (9d0d3a7) will decrease coverage by 0.03%. The diff coverage is 93.33%.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## develop #737 +/- ## =========================================== - Coverage 98.81% 98.79% -0.03% =========================================== Files 75 75 Lines 7167 7197 +30 =========================================== + Hits 7082 7110 +28 - Misses 85 87 +2 ```
SimeonEhrig commented 1 year ago

Why do you need to use string literals explicit for function arguments, but template arguments are implicit working.

My suggestion, for the literal: llfield or LLfield -> short for llama field.

bernhardmgruber commented 1 year ago

Why do you need to use string literals explicit for function arguments, but template arguments are implicit working.

In llama::NamedField<"x", int> I have the value "x" available as a constant expression and can meta-program on it. Specifically, I need to turn the string literal into a type. In view(0)("x") I have the value "x" available only at runtime, so I cannot meta-program. This would require constexpr function parameters, which were proposed but never accepted into C++. My workaround is to use a literal operator which turns the string literal into a type carrying the string's value.

SimeonEhrig commented 1 year ago

Why do you need to use string literals explicit for function arguments, but template arguments are implicit working.

In llama::NamedField<"x", int> I have the value "x" available as a constant expression and can meta-program on it. Specifically, I need to turn the string literal into a type. In view(0)("x") I have the value "x" available only at runtime, so I cannot meta-program. This would require constexpr function parameters, which were proposed but never accepted into C++. My workaround is to use a literal operator which turns the string literal into a type carrying the string's value.

Thanks for clarification.

psychocoderHPC commented 1 year ago

I like the idea of using string types to name the components. I suggest instead of _Name, _tag.

I'm not sure if the example with BOOST suggests making llama depending on a boost feature but I would be happy if using BOOST_DESCRIBE_STRUCT will be only an optional way and the boost dependency is in this case only optional too.

bernhardmgruber commented 1 year ago

I like the idea of using string types to name the components. I suggest instead of _Name, _tag.

How would you call NamedField then for consistency?

I'm not sure if the example with BOOST suggests making llama depending on a boost feature but I would be happy if using BOOST_DESCRIBE_STRUCT will be only an optional way and the boost dependency is in this case only optional too.

The new feature is entirely optional. It needs a recent enough Boost version.