compressed_pair doesn't work with an empty final struct about utility HOT 19 CLOSED

Also template<class... T> compressed_tuple: empty_value<T, i>... {} with the appropriate index_sequence magic applied. :-)

from utility.

Looking at the implementation, rather than using a wrapper class, it might be better to change the instantiation of compressed_pair_switch to check both is_empty and is_final. I think we can just use: ::boost::is_empty<T1>::value && !::boost::is_final<T1>::value, I assume we don't have to worry about old compilers with poor support for integral constant expressions anymore.

from utility.

I would suggest testing for BOOST_IS_FINAL before using boost::is_final. Otherwise it will break compressed_pair for compilers that don't support final classes.

In fact, it might make sense to detect if std::is_final is available and only use it in compressed_pair when it is available. This way we're not depending on Boost.TypeTraits implementation details, which BOOST_IS_FINAL is.

from utility.

boost::is_final returns false when it isn't supported, so it will always do the right thing for compilers that don't support final classes.

Using std::is_final could be good, but we currently don't have a mechanism for detecting it, so it's unlikely we'll get better support than boost::is_final without a fair bit of work, e.g. libstdc++ doesn't have std::is_final in C++11 mode, but does have boost::is_final.

Utility already makes heavy use of Type Traits, so we won't be adding another dependency.

from utility.

boost::is_final returns false when it isn't supported, so it will always do the right thing for compilers that don't support final classes.

Right, sorry, I didn't think it through enough.

from utility.

I've been trying to implement this for unordered, and it turns out that boost::is_final doesn't work well with templates on gcc, I created an issue at boostorg/type_traits#66. So if it can't be fixed in Type Traits, it might be best to use std::is_final when available after all.

from utility.

It looks like boost::is_empty doesn't work with final classes either.

from utility.

Looks like boost::is_empty is implemented as emulation even if a compiler intrinsic is available. @jzmaddock is there a reason for this?

from utility.

@danieljames We now also have boost::empty_value which is a slightly more flexible version of ebo_helper:

• https://www.boost.org/doc/libs/master/libs/core/doc/html/core/empty_value.html
• https://github.com/boostorg/core/blob/master/include/boost/core/empty_value.hpp

e.g. 1

template<class Allocator>
class type
    : empty_value<Allocator> {

e.g. 2

template<class InnerAllocator, class OuterAllocator, class OtherAllocator>
class type
    : empty_value<InnerAllocator, 1>
    , empty_value<OuterAllocator, 2>
    , empty_value<OtherAllocator, 3> {

That index is optional, and can be specified to create distinct base types so that the optimization still kicks in when all three Allocators are the same type.

from utility.

Wouldn't compressed_pair be easier as template<class T1, class T2> class compressed_pair: empty_value<T1, 1>, empty_value<T2, 2>?

from utility.

I think, the regular boost::tuple can implement compression, if it doesn't yet. std::tuple does.

from utility.

Some std:tuples do, some don't, I think?

boost::tuple is legacy C++03 and I don't think we can change it because I suspect much code relies on its internals. Although who knows.

from utility.

Even if someone depends on its implementation details, it shouldn't stop us from developing the library.

from utility.

Wouldn't compressed_pair be easier as template<class T1, class T2> class compressed_pair: empty_value<T1, 1>, empty_value<T2, 2>?

Yes.

from utility.

They are documented: https://www.boost.org/doc/libs/1_68_0/libs/tuple/doc/html/tuple_advanced_interface.html

So, not implementation details.

And you pretty much have to rely on them, I think, because if I recall correctly tuple<> is not the same type as tuple<>::inherited (which is what make_tuple returns.) So if you want to write a function that accepts tuples you need to handle both.

All that said, std::tuple is very slow to instantiate for reasons I always forget, so it'd probably be useful to have a Boost tuple that isn't. I'm just not sure whether it can be called boost::tuple.

from utility.

I still think we should try and improve boost::tuple, even if it involves deprecating or changing some things. Tuples are supposed to be vocabulary types, and we already have a few implementations in different libraries. Let's not make another one.

from utility.

We have one in Hana. Tuples aren't exactly vocabulary types though. std::tuple is, the rest are tuple-likes.

Never mind. :-)

from utility.

Sorry... been away and just come back to this - do we still need to fix compressed_pair?

from utility.

I fixed it in #49 . We can improve (simplify) compressed_pair, but that can happen later.

from utility.