boostorg/hana

Your standard library for metaprogramming

Jason Rice

@ricejasonf

@ldionne When you make a new blog post could you post a link in here or on twitter or something?

Jason Rice

@ricejasonf

(please) :P

Jason Rice

@ricejasonf

Your new post made me think of your todo in or.hpp regarding forwarding of x twice into hana::if_. It seems impossible unless you put the same logic that is in eval_if to convert x to bool or an IntegralConstant that contains bool.

Jason Rice

@ricejasonf

Is it okay to do hana::optional<T> or does one have to use decltype(hana::just(std::declval<T>())? (the doc says "implementation defined" but I'm not sure to what extent)

The docs for map say hana::map< implementation_defined > but for optional it is hana::optional<...> which makes me think it might be okay.

Louis Dionne

@ldionne

I’ll change it. Technically it’s reall implementation defined. Actually, nothing’s type is optional<>, and just(x)’s type is optional<T>.

Jason Rice

@ricejasonf

so then me using hana::optional<T> and hana::optional<> directly is okay?

Louis Dionne

@ldionne

No, it isn’t in the current state of things. But perhaps it would be useful to allow it. What’s your use case?

I wasn’t clear in my original answer. What I meant is that the types were really implementation-defined, and that you shouldn’t rely on them.

Jason Rice

@ricejasonf

I'm not sure if what I am doing is a good idea yet, but I decided to not bother wrapping tuple and just represent a message as a tuple where some 'fields' like a payload might not be present.

    BOOST_HANA_CONSTANT_ASSERT(
      builder::entityMessages(entity_map, access_point)
        ==
      hana::make_tuple(
        hana::type_c<hana::tuple<
          hana::optional<>,
          channel::Upstream,
          action::Create,
          path_type,
          hana::optional<entity::E1>,
          hana::optional<>
        >>,
        hana::type_c<hana::tuple<
          hana::optional<bool>,
          channel::Downstream,
          action::Create,
          path_type,
          hana::optional<entity::E1>,
          hana::optional<>
        >>,
      )
    );

There is also this, but after a second look maybe I should have used value_or :P
https://github.com/ricejasonf/nbdl/blob/develop/src/mpdef/CollectSettings.hpp#L25
In any case it's nbd. I'll just avoid using it that way if it remains 'implementation_defined'.

hmm.. I don't think I used value_or because I wanted that map lookup to be lazy

Louis Dionne

@ldionne

Orthogonal question: Do you see a speedup with your own map implementation?

Jason Rice

@ricejasonf

the one that uses strictly types as keys?

Louis Dionne

@ldionne

Well mpdef::make_map.

Jason Rice

@ricejasonf

I didn't compare the benchmark against your version of the hash_map but the mpdef::Map registered at .5s for 200 lookups.

http://fullstackblog.com/hbench/

Louis Dionne

@ldionne

Your new post made me think of your todo in or.hpp regarding forwarding of x twice into hana::if_. It seems impossible unless you put the same logic that is in eval_if to convert x to bool or an IntegralConstant that contains bool.

That is correct, at least I think so. But I can't do that without losing the generality of or_'s current definition, because someone could define a new Logical that's not a bool or a boolean IntegralConstant. But even disregarding this issue, I feel like the Logical concept might be flawed. I tried to be very general, but it gives something that provides bad compile-time performance for such basic operations. I would perhaps make more sense to only define these operations on boolean IntegralConstants. We would lose the ability to branch on runtime values too, but the rest of the library does not support runtime conditions anymore anyways.

I didn't compare the benchmark against your version of the hash_map but the mpdef::Map registered at .5s for 200 lookups.

Care to send me the benchmark? Or did you already do it previously and I just forgot? I remember you showing me this graph before.

Jason Rice

@ricejasonf

I don't think I saved the code for it. I can just make it real fast.

Louis Dionne

@ldionne

No, it’s ok. I’ll just run my own benchmark for map and see the timings

It turns out that the pure hash_table creation itself isn’t too slow. The slowest thing seems to be creating a huge number of pairs and a huge tuple. Go figure.

The compile-time performance of hana::map is one deep freaking mystery. We made it better, but still not as good as we need for the most common use cases (types only or similar simple things).

Regarding your current issue with optional, I’m thinking about it. The thing is that constructors are documented, so it would seem to make sense that the type part of the API too (otherwise how do you call the constructor?).

Louis Dionne

@ldionne

Basically I’m trying to think about what it means to make the type part of the API in terms of loss future flexibility and code/documentation changes.

Jason Rice

@ricejasonf

in my mpdef stuff my biggest speedup was using an empty list instead of hana::tuple. It is almost exactly like hana:types only it doesn't wrap its members in hana::type.

Louis Dionne

@ldionne

You mean it doesn’t wrap its elements in hana::type when it returns them from e.g. at?

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.

Where communities thrive

People

Repo info

Activity