mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Rojas" <alexan...@mesosphere.io>
Subject Re: Review Request 37714: Updated Multimap and multihashmap so their signatures resemble that of hashmap and hashset.
Date Wed, 16 Sep 2015 06:14:26 GMT


> On Sept. 10, 2015, 1:46 a.m., Michael Park wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp, lines 96-97
> > <https://reviews.apache.org/r/37714/diff/3/?file=1057712#file1057712line96>
> >
> >     `s/std::make_pair(key, value)/{key, value}/`

I wasn't sure if we are allowing initializer lists constructors. Some people have complained
about them in my reviews. Can you clarify? I for myself am all in.


> On Sept. 10, 2015, 1:46 a.m., Michael Park wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp, lines 107-117
> > <https://reviews.apache.org/r/37714/diff/3/?file=1057712#file1057712line107>
> >
> >     Can we just `auto` all of this away?
> >     
> >     ```
> >     auto range =
> >       std::unordered_multimap<Key, Value, Hash, Equal>::equal_range(key);
> >     for (auto it = range.first; it != range.second; ++it) {
> >       values.push_back(it->second);
> >     }
> >     ```

Same here, I have gotten complains about using auto. Are we allowed to use it, if so in which
cases?


> On Sept. 10, 2015, 1:46 a.m., Michael Park wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp, lines 34-37
> > <https://reviews.apache.org/r/37714/diff/3/?file=1057713#file1057713line34>
> >
> >     Can I ask why we want these? Presumably the purpose of these classes are to
eliminate the need for their `std::` counterparts.
> >     
> >     If we look at a class like `Set`, it inherits from `std::set` but doesn't construct
off of `std::set`. Similarly, `hashmap` inherits from `std::unordered_map`, but doesn't construct
off of `std::unordered_map`.

I have no strong feelings about removing them. But if you check `hashset` it has a constructor
from a `set` just like this one, so I am just trying to keep up with their signatures. I did
find weird to have a constructor from `set` to `hashset` though. I'll drop this and if you
think I really ought to remove it, please reopen.


- Alexander


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37714/#review98293
-----------------------------------------------------------


On Sept. 16, 2015, 8:14 a.m., Alexander Rojas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37714/
> -----------------------------------------------------------
> 
> (Updated Sept. 16, 2015, 8:14 a.m.)
> 
> 
> Review request for mesos, Joerg Schad, Michael Park, and Jan Schlicht.
> 
> 
> Bugs: MESOS-2924
>     https://issues.apache.org/jira/browse/MESOS-2924
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Adds extra template parameters to `multihashmap` which offer control over the hash function
to use as well as the equality operator.
> 
> Implements initializer_list, copy and move constructors for both, `multihashmap` and
`Multimap` in a similar way as it was done for `hashmap` and `hashset`.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp d9e4031cee64e48ad50541c04ca11e7861d0a17c

>   3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp fb3e7a1d0377001389980302342813217f49cf5f

>   3rdparty/libprocess/3rdparty/stout/tests/multimap_tests.cpp 535cd2d10e3074c86c149ce85b205e73ca42ddd3

> 
> Diff: https://reviews.apache.org/r/37714/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message