Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 02:04
    pthom commented #432
  • Jan 18 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 22:27
    ricejasonf commented #434
  • Jan 05 06:22
    ricejasonf commented #330
  • Jan 03 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Jason Rice
@ricejasonf
or unpack yes
Louis Dionne
@ldionne
Ok. Yeah, hana::tuple has to have a bit of complexity to have an interface not too far from std::tuple.
Jason Rice
@ricejasonf
also mine doesn't support runtime values
Louis Dionne
@ldionne
I think the thing that’s the most expensive with hana::tuple is overload resolution on the constructors.
So, why don’t you use hana::experimental::types?
I don’t think the wrapping of elements in hana::type would cause a significant compile-time hit, really.
Jason Rice
@ricejasonf
I actually started using it, but I think it was just more work to unwrap them when I didn't need that (in my particular use case)
Louis Dionne
@ldionne
Ok. So basically you’re moving default-constructible empty objects around.
Jason Rice
@ricejasonf
yeah
Jason Rice
@ricejasonf
kind of like detail::hash_table... maybe I should be using metafunctions
Louis Dionne
@ldionne
Regarding optional, I opened boostorg/hana#254 so I don’t forget it.
Jason Rice
@ricejasonf
cool thanks
Jason Rice
@ricejasonf
Would it be a huge change to have hana::decltype_ strip cv-qualifiers or is there something that does that?
Louis Dionne
@ldionne
If you need to strip cv-qualifiers, you can use hana::traits::remove_cv. Why would you like hana::decltype_ to remove them?
By the way, the reason why hana::decltype_ strips references is because it couldn’t be implemented consistently when keeping references. So it was decided that stripping references completely, while arbitrary and limiting, was the simplest choice.
Jason Rice
@ricejasonf
I know I am misusing optional here, but...
hana::decltype_(hana::nothing) != hana::decltype_(hana::optional<>{})
ricejasonf/nbdl@aa64103
Louis Dionne
@ldionne
One’s const and the other one is non-const?
nothing is const because it’s a constexpr optional<>?
Whereas the other one falls through the T&& of hana::decltype_ since it’s a temporary, and it’s then transformed into optional<> after removing rvalue reference.
Jason Rice
@ricejasonf
I think so. I get bit by the const - not const thing a lot. With hana::hash and mpdef::Map too I had to use std::add_const.
Louis Dionne
@ldionne
Do you remember the exact problem with hash?
Jason Rice
@ricejasonf
I think I had specializations for const but you simplified it with remove_cv.
Louis Dionne
@ldionne
Regarding this whole optional thing; while I’ll probably specify its template parameters, it feels like you’re doing something wrong. I’ll try to take a deeper look at your code.
Jason Rice
@ricejasonf
You mean like with the tuple with optionals in it?
Louis Dionne
@ldionne
Yes. I feel like it might be easier to define the tuple once you have the values themselves.
Regarding hash: I just checked and you had const specializations for char and unsigned char only.
Jason Rice
@ricejasonf
I don't remember why exactly
lol
Louis Dionne
@ldionne
There were probably problems with char not being comparable to other integral types, but that was fixed separately.
What I do now for hash is simply discard the cv-qualifiers of the value in the IntegralConstant, for the cv-qualifier does not change whether two IntegralConstants are equal.
Jason Rice
@ricejasonf
ah right
Louis Dionne
@ldionne
I’m looking at your mpdef::Map right now and I see the add_const, but I don’t understand why it would ever be needed.
Jason Rice
@ricejasonf
If the map was made with a key of hana::int_c<1> that would be of type const hana::integral_constant<int> and it wouldn't match hana::integral_constant<int>
Louis Dionne
@ldionne
Oh shit, right.
But that’s an issue you run into when you use values for their type instead of “properly” storing them into hana::type or a similar container.
Jason Rice
@ricejasonf
Yeah, it's probably not something Hana needs to solve, but I run into the problem often. gtg eat ttyl
Jason Rice
@ricejasonf
#include<boost/hana.hpp>
#include<boost/hana/experimental/types.hpp>

namespace hana = boost::hana;
namespace hanax = boost::hana::experimental;

int main() {
  {
    constexpr auto xs = hanax::types<
      hana::int_<1>,
      hana::int_<2>,
      hana::int_<3>
    >{};

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(xs, hanax::make_types(
            hana::int_c<1>,
            hana::int_c<2>,
            hana::int_c<3>
        ))
    );

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(xs, hanax::make_types(
            hana::type_c<hana::int_<1>>,
            hana::type_c<hana::int_<2>>,
            hana::type_c<hana::int_<3>>
        ))
    );

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(
            hanax::make_types(xs, xs, xs),
            hanax::make_types(
                hanax::make_types(
                    hana::type_c<hana::int_<1>>,
                    hana::type_c<hana::int_<2>>,
                    hana::type_c<hana::int_<3>>
                ),
                hanax::make_types(
                    hana::int_c<1>,
                    hana::int_c<2>,
                    hana::int_c<3>
                ),
                hanax::make_types(
                    hana::int_c<1>,
                    hana::int_c<2>,
                    hana::int_c<3>
                )
            )
        )
    );
  }
}
:grin:
sorry.. maybe i should have gisted that
If I accidentally call hana::make_types it says the only candidate function takes a single argument which is really, really weird considering there is no hana::make_types
flatten doesn't work yet because it unpacks as type_impl<types<T...>>
Jason Rice
@ricejasonf
ricejasonf/hana@8cc5f32
Louis Dionne
@ldionne
Actually, if you think of it, I don’t think it makes sense for hana::experimental::types to be a Monad, since it’s not possible for it to contain another hana::experimental::types.
For some Monad M, flatten needs to havea signature M(M(T)) -> M(T), which does not make sense for experimental::types since M(M(T)) does not exist.
Jason Rice
@ricejasonf
lol.. here I am hacking it in there. What if we thought of hana::type as a singleton hana::types?
Louis Dionne
@ldionne
Well then I think M(T) wouldn’t have sense anymore, it would always be M(M(T)) (where M is experimental::types_tag and T is hana::type_tag).
I’m not sure, let me think.
Jason Rice
@ricejasonf
template <typename T>
using type = hana::types<T>;