boostorg/hana

Your standard library for metaprogramming

Maik Klein

@MaikKlein

yes

note: candidate template ignored: substitution failure [with X = <const std::reference_wrapper<breeze::util::container::handle_container<position, std::vector<position, std::allocator<position> > > > &, const std::reference_wrapper<breeze::util::container::handle_container<velocity, std::vector<velocity, std::allocator<velocity> > > > &>]
            auto operator()(X&& ...x) const -> filter_indices<

nvm oh my god

Maik Klein

@MaikKlein

I am so stupid

Jason Rice

@ricejasonf

What does your contains_type function return?

Maik Klein

@MaikKlein

lol

constexpr auto contains_type(Tup&& tup, T)

forgot to make it T&

god damn it that should have been obvious

Jason Rice

@ricejasonf

for a parameter that isn't used?

Maik Klein

@MaikKlein

yes

I thought it shouldn'T matter

Jason Rice

@ricejasonf

lol.... "shouldn'T"

Maik Klein

@MaikKlein

template <class Tup, class T>
constexpr auto contains_type(Tup&& tup, T&)
{
  return hana::contains(tup, hana::type_c<T>);
}

Jason Rice

@ricejasonf

ooh

Maik Klein

@MaikKlein

Not quite sure why I got the error with static_castthough.

btw I have gcc 5.3 so I think my library should be recent enough?

Could you compile this with master?

```
struct position
{
  float x, y;
};
struct velocity
{
  float x, y;
};

int main()
{
  auto tup = hana::make_tuple(position{1,2}, velocity{1,2});
  auto tup_ref =  hana::transform(tup, [](auto& t) { return std::ref(t); });
  auto test = hana::filter(tup_ref, [](auto& tref){
    return hana::bool_c<true>;
  });
}

Jason Rice

@ricejasonf

yes

Maik Klein

@MaikKlein

does it also ice for you?

Jason Rice

@ricejasonf

ice?

Maik Klein

@MaikKlein

internal compiler error

Jason Rice

@ricejasonf

Maik Klein

@MaikKlein

hm k

Jason Rice

@ricejasonf

It could be that you are still using an old version of libstd++ on your system

I don't remember how I fixed that on mine.

Maik Klein

@MaikKlein

I think that is the problem

readelf -sV /usr/lib/libstdc++.so.6 | sed -n 's/.*@@GLIBCXX_//p' | sort -u -V | tail -1

gives me version 3.4.21

Jason Rice

@ricejasonf

I want to say changing the symlink for the g++ binary fixed it.

Maik Klein

@MaikKlein

does the command above print 5.1 for you?

Jason Rice

@ricejasonf

jason@jason-nuc:/usr/lib/gcc/x86_64-linux-gnu/5.1.0$ readelf -sV libstdc++.so | sed -n 's/.*@@GLIBCXX_//p' | sort -u -V | tail -1
3.4.21

Jason Rice

@ricejasonf

@ldionne It occurred to me that I could give you push access to my fork if that is easier than having a branch in the upstream repo. (wrt #226)

Louis Dionne

@ldionne

Or I could just create that damn branch on the upstream. I’m sorry it’s been so long. The thing is that this PR is actualy a huge chunk; it’s hard to tell whether we’re improving or not, and there are also other approaches (hashing) available. 1 minute

Jason Rice

@ricejasonf

I'm not in a hurry or anything so no rush. ;)

We could always have multiple branches with different tweaks to run benchmarks on and contrast and compare.

I was actually thinking about making another PR to attempt to improve hana::pair. (maybe it would be faster if it wasn't a wrapper for a basic_tuple idk)

Louis Dionne

@ldionne

Yes, in retrospect I think that would be better. You can see my (rather extensive) changes here

I also removed the fast lane for looking up hana::types, since it was broken (the specialization would never match), and I did not take time to reimplement it properly.

I also rebased the branch on top of develop. Check the changes out, then we’ll discuss them.

Louis Dionne

@ldionne

@ricejasonf I added comments. In retrospect, some of my changes should be reverted to what you did, or a slight variation of it.

Jason Rice

@ricejasonf

get_map_elt_type was like a workaround to a forwarding reference issue that no longer existed after making the three overloads of map_get_helper. lol sorry about that one.

Jason Rice

@ricejasonf

I think the at_key.lookup is a better benchmark because the size of the map is constant and it tests the lookup time of finding the nth element which is O(1) for map and O(n) for the others.

Jason Rice

@ricejasonf

85% of it was hana::make_pair btw. (as well as constructing the pairs manually)

Louis Dionne

@ldionne

Right; I do think that we’ll have to check the benchmarks out and make sure we’re benchmarking the right thing. It’s just very difficult to properly benchmark compile-times.

Jason Rice

@ricejasonf

Somewhere along the line I gained the incorrect assumption that unused parameters were strictly used for overloading and didn't result in a copy if you didn't specify const&. :open_mouth:

It was probably here: http://www.boost.org/community/generic_programming.html#tag_dispatching

Even an empty struct gets copied.

; Function Attrs: uwtable
define i32 @main() #3 {
  %1 = alloca %struct.Silent, align 1
  call void @_Z5helloI6SilentEvT_()
  ret i32 0
}

; Function Attrs: nounwind uwtable
define linkonce_odr void @_Z5helloI6SilentEvT_() #4 comdat {
  %1 = alloca %struct.Silent, align 1
  ret void
}

@ldionne Did your clang built-in ever get looked at?

Jason Rice

@ricejasonf

The search bar in the docs appears to be broken.

Where communities thrive

People

Repo info

Activity