Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename point_traits.h into type_traits.h #3698

Merged
merged 2 commits into from
Mar 24, 2020

Conversation

kunaltyagi
Copy link
Member

Can we change the name of point_traits.h to type_traits.h? Will this be a breaking change? if so, should we have a redirect to the new name?

At first sight yes, yes and yes.

Originally posted by @SergioRAgostinho in #3651 (comment)

@kunaltyagi kunaltyagi added needs: more work Specify why not closed/merged yet changelog: deprecation Meta-information for changelog generation effort: low Rough estimate of time needed to fix/implement/solve labels Mar 1, 2020
@kunaltyagi kunaltyagi marked this pull request as ready for review March 1, 2020 17:33
@kunaltyagi kunaltyagi added needs: code review Specify why not closed/merged yet and removed needs: more work Specify why not closed/merged yet labels Mar 1, 2020
@kunaltyagi kunaltyagi added this to the pcl-1.11.0 milestone Mar 1, 2020
Copy link
Member

@taketwo taketwo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. You prefer to not merge it before 1.10.1?

@kunaltyagi
Copy link
Member Author

kunaltyagi commented Mar 4, 2020

Yes. Deprecation between minor releases doesn't sit right by me.

@kunaltyagi kunaltyagi added needs: pr merge Specify why not closed/merged yet and removed needs: code review Specify why not closed/merged yet labels Mar 4, 2020
@aPonza
Copy link
Contributor

aPonza commented Mar 4, 2020

Sorry to bother in a seemingly unrelated issue, but I think this header could be kept/subdivided. Let me explain. From #3701 (comment) I have, among the other questions, this:

  • 16x "warning: Detected potential recursive class relation between class and base class " can be fixed with a /** \cond NO_WARN_RECURSIVE */-/** \endcond */ pair for all four traits (as per this SO answer) but it'd need a new header: just adding the pair leads to "warning: Conditional section with label 'NO_WARN_RECURSIVE' does not have a corresponding \endcond command within this file.". The solutions seems to be moving
    // name
    /* This really only depends on Tag, but we go through some gymnastics to avoid ODR violations.
    We template it on the point type PointT to avoid ODR violations when registering multiple
    point types with shared tags.
    The dummy parameter is so we can partially specialize name on PointT and Tag but leave it
    templated on dummy. Each specialization declares a static char array containing the tag
    name. The definition of the static member would conflict when linking multiple translation
    units that include the point type registration. But when the static member definition is
    templated (on dummy), we sidestep the ODR issue.
    */
    template<class PointT, typename Tag, int dummy = 0>
    struct name : name<typename POD<PointT>::type, Tag, dummy>
    {
    // Contents of specialization:
    // static const char value[];
    // Avoid infinite compile-time recursion
    BOOST_MPL_ASSERT_MSG((!std::is_same<PointT, typename POD<PointT>::type>::value),
    POINT_TYPE_NOT_PROPERLY_REGISTERED, (PointT&));
    };
    // offset
    template<class PointT, typename Tag>
    struct offset : offset<typename POD<PointT>::type, Tag>
    {
    // Contents of specialization:
    // static const std::size_t value;
    // Avoid infinite compile-time recursion
    BOOST_MPL_ASSERT_MSG((!std::is_same<PointT, typename POD<PointT>::type>::value),
    POINT_TYPE_NOT_PROPERLY_REGISTERED, (PointT&));
    };
    // datatype
    template<class PointT, typename Tag>
    struct datatype : datatype<typename POD<PointT>::type, Tag>
    {
    // Contents of specialization:
    // using type = ...;
    // static const std::uint8_t value;
    // static const std::uint32_t size;
    // Avoid infinite compile-time recursion
    BOOST_MPL_ASSERT_MSG((!std::is_same<PointT, typename POD<PointT>::type>::value),
    POINT_TYPE_NOT_PROPERLY_REGISTERED, (PointT&));
    };
    // fields
    template<typename PointT>
    struct fieldList : fieldList<typename POD<PointT>::type>
    {
    // Contents of specialization:
    // using type = boost::mpl::vector<...>;
    // Avoid infinite compile-time recursion
    BOOST_MPL_ASSERT_MSG((!std::is_same<PointT, typename POD<PointT>::type>::value),
    POINT_TYPE_NOT_PROPERLY_REGISTERED, (PointT&));
    };
    and
    #define POINT_CLOUD_REGISTER_FIELD_NAME(r, point, elem) \
    template<int dummy> \
    struct name<point, pcl::fields::BOOST_PP_TUPLE_ELEM(3, 2, elem), dummy> \
    { \
    static const char value[]; \
    }; \
    \
    template<int dummy> \
    const char name<point, \
    pcl::fields::BOOST_PP_TUPLE_ELEM(3, 2, elem), \
    dummy>::value[] = \
    BOOST_PP_STRINGIZE(BOOST_PP_TUPLE_ELEM(3, 2, elem)); \
    /***/
    #define POINT_CLOUD_REGISTER_FIELD_OFFSET(r, name, elem) \
    template<> struct offset<name, pcl::fields::BOOST_PP_TUPLE_ELEM(3, 2, elem)> \
    { \
    static const std::size_t value = offsetof(name, BOOST_PP_TUPLE_ELEM(3, 1, elem)); \
    }; \
    /***/
    #define POINT_CLOUD_REGISTER_FIELD_DATATYPE(r, name, elem) \
    template<> struct datatype<name, pcl::fields::BOOST_PP_TUPLE_ELEM(3, 2, elem)> \
    { \
    using type = boost::mpl::identity<BOOST_PP_TUPLE_ELEM(3, 0, elem)>::type; \
    using decomposed = decomposeArray<type>; \
    static const std::uint8_t value = asEnum<decomposed::type>::value; \
    static const std::uint32_t size = decomposed::value; \
    }; \
    /***/
    and
    #define POINT_CLOUD_REGISTER_POINT_FIELD_LIST(name, seq) \
    template<> struct fieldList<name> \
    { \
    using type = boost::mpl::vector<BOOST_PP_SEQ_ENUM(seq)>; \
    }; \
    /***/
    into a new header with an appropriate name. Do I have the ok and which name would you like?

I'm thinking these bits I need from point_traits.h could be kept where they are and integrated with the register_point_struct.h bits. The rest of the point_traits.h code should then be moved to type_traits.h together with an #include <pcl/point_traits.h>.

Am I incorrectly understanding the code? Would you rather have a different header (point_struct_traits.h) or fix?

@kunaltyagi kunaltyagi added needs: more work Specify why not closed/merged yet and removed effort: low Rough estimate of time needed to fix/implement/solve needs: pr merge Specify why not closed/merged yet labels Mar 12, 2020
@kunaltyagi kunaltyagi added needs: code review Specify why not closed/merged yet and removed needs: more work Specify why not closed/merged yet labels Mar 23, 2020
@kunaltyagi kunaltyagi force-pushed the type_traits branch 4 times, most recently from a638ac7 to ff5cea6 Compare March 23, 2020 07:13
Copy link
Member

@SergioRAgostinho SergioRAgostinho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After you resolve the conflict feel free to merge.

@SergioRAgostinho SergioRAgostinho removed the needs: code review Specify why not closed/merged yet label Mar 24, 2020
@SergioRAgostinho SergioRAgostinho added the needs: more work Specify why not closed/merged yet label Mar 24, 2020
@kunaltyagi
Copy link
Member Author

I'll rebase it a bit first.

@kunaltyagi kunaltyagi added needs: feedback Specify why not closed/merged yet and removed needs: more work Specify why not closed/merged yet needs: feedback Specify why not closed/merged yet labels Mar 24, 2020
@kunaltyagi kunaltyagi merged commit faca2e5 into PointCloudLibrary:master Mar 24, 2020
@kunaltyagi kunaltyagi deleted the type_traits branch March 24, 2020 12:58
@taketwo taketwo changed the title Adding type_traits as the more common name Rename point_traits.h into type_traits.h Mar 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog: deprecation Meta-information for changelog generation module: common
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants