Char Aznable

Can the ctor not do the rounding if the input capacity hint is multiple of 128 or whatever the logic deduces the capacity to be? or whatever that would make...

I understand that the map needs to be larger than the input hint size to work. But I don't think there is anything wrong with a different concept of constructing...

Also, I think the capacity hint thing is insufficient and unnecessary to serve its purpose as you mentioned. There is no mechanism to prevent the user from attempting inserting more...

To reiterate what I showed in the OP and in: https://github.com/kokkos/kokkos/issues/4112#issuecomment-871469737 This pattern is common when the an iterative algorithm needs to construct and fill a map from the host...

The other problem with the current capacity hint is space inefficiency. Even when the user knows the actual capacity used is much smaller than what the map ctor deduced to...

Unfortunately, that doesn't work because `size()` varies a lot among the iterations

What @crtrott suggest should solve the problem if it can do away with not copying the contents, i.e., it's a `create_mirror_view` rather than `create_mirror_view_and_copy`

Whether it makes sense or not depends on the application. One can do copying between `Key` and `Foo::Key` by defining member functions. The problem here is that there is no...

@nliber IMHO, deep_copy maintains the same key -> value relationship and all the relevant internal state such as key and value indices in a concurrency independent way. For the OP...

Sorry if I was being misleading. What I am actually thinking is some functionality like (with sloppy pseudo coding): `parallel_for(key2 : m2) { m1[key1 = key2] = m2[key2]; }` so...