corrade icon indicating copy to clipboard operation
corrade copied to clipboard

[WIP] add structured binding forward declaration

Open sthalik opened this issue 3 years ago • 1 comments

This commit adds std::tuple_element and std::tuple_size forward declarations to avoid slurping in thousands of lines worth of STL headers. For unsupported STL versions, <array> is included instead.

sthalik avatar Feb 19 '22 12:02 sthalik

Codecov Report

Base: 97.96% // Head: 97.96% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (b771fe5) compared to base (6f115b2). Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #127   +/-   ##
=======================================
  Coverage   97.96%   97.96%           
=======================================
  Files         135      135           
  Lines       10940    10943    +3     
=======================================
+ Hits        10717    10720    +3     
  Misses        223      223           
Impacted Files Coverage Δ
src/Corrade/Containers/OptionalStl.h 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

codecov[bot] avatar Feb 19 '22 16:02 codecov[bot]

Since I'm deep in the reviews already, let's unblock this too, finally (it's from February? wow :sweat_smile:).

As the change now boils down to #include <utility> to get declarations of std::tuple_element and std::tuple_size, I don't think it's needed to invent any special forward-declarating header for these two -- the size of <utility> is rather small, while maintenance cost of the forward-declaring header and potential for strange breakages after compiler upgrades would be far higher than that. So just drop the TupleStl.h altogether.

What's left is that I assume you'd want to use C++17 auto [a, b] = someType; for as many Corrade/Magnum types as possible, right? In case of Corrade that'd be mainly these I suppose:

  • Containers::Pair, for which the std::tuple_whatever specializations could go into the already-existing Containers/PairStl.h, and a corresponding new C++17-only PairStlCpp17Test.cpp
  • Containers::Triple, for which the std::tuple_whatever specializations could go into the already-existing Containers/TripleStl.h, and a corresponding new C++17-only TripleStlCpp17Test.cpp
  • Containers::StaticArrayView, for which it could go into the already-existing Containers/ArrayViewStl.h, and a corresponding new ArrayViewStlCpp17Test.cpp

For completeness there's also Containers::StaticArray but it doesn't have a corresponding StaticArrayStl.h header yet, that one you'd have to create, and a new StaticArrayStlCpp17Test.cpp as well. (It's also fine if you implement just the Pair and Triple, those are the most important ones.)

It seems like a lot of new test files, but my assumption is that there will be more and more C++14/17/20-specific features (such as your constexpr additions), and the new test files will be reused for those as well.

The std::tuple_element / std::tuple_size is a C++11 feature already so I wouldn't hide them in any #if compiling_as_cpp17. Having them exposed unconditionally would mean std::get<N>() working with Corrade/Magnum types even under C++11, for example.

In case of Magnum I assume you'd want Math::Vector exposed this way, so that'd be a new VectorStl.h, and a corresponding new C++17-only VectorStlCpp17Test.cpp.

mosra avatar Oct 19 '22 10:10 mosra

The std::tuple_element / std::tuple_size is a C++11 feature already so I wouldn't hide them in any #if compiling_as_cpp17. Having them exposed unconditionally would mean std::get<N>() working with Corrade/Magnum types even under C++11, for example.

For types without an already-existing get<N> member function, this makes the implementation uglier since if constexpr is from C++17 and functions can't be partially specialized.

sthalik avatar Nov 11 '22 13:11 sthalik

So, not going to do the specializations for other containers either? I'll convert that to an issue, then, in case it eventually becomes useful for someone else.

mosra avatar Nov 12 '22 18:11 mosra

I still plan on doing it for Pair and Triple at least, but have more pressing issues at this time.

sthalik avatar Nov 12 '22 18:11 sthalik

For anyone still subscribed to this PR, a variant of the above together with structured bindings for StridedDimensions was added in 087ead32ce60655676ab0cb9f001e182aba1d4af and 5f4fc52ad2f07c4e022e8ba8e770144becb69b17.

mosra avatar Dec 08 '23 23:12 mosra