Add libcpp multimap and unordered_multimap

[Dobatymo]

These two containers are still missing from libcpp.

[scoder]

Thanks. Could you please make sure that all methods that can raise C++ exceptions are marked with except +?

[Dobatymo]

@scoder I think I got all of them. Usually the constructor, insert and at methods can throw exceptions. Since there are not at methods on multisets, it's only the first two.

Because the methods have the correct types, it actually leads to some issues, because iterator cannot be converted to const_iterator automatically.
so multimap.insert(multimap.begin(), multimap.end()) doesn't work, although it shouldn't be a problem in pure C++. I don't know if that's a Cython issue, or if something needs to be improved with the definition of the Iterator classes (for other containers as well).

See my comment here as well #4410 (comment)

[da-woods]

Because the methods have the correct types, it actually leads to some issues, because iterator cannot be converted to const_iterator automatically.
so multimap.insert(multimap.begin(), multimap.end()) doesn't work, although it shouldn't be a problem in pure C++. I don't know if that's a Cython issue, or if something needs to be improved with the definition of the Iterator classes (for other containers as well).

I think this may be because Cython insists of specifying all the template arguments (so it generates code like multimap.insert<std::multimap<...>::iterator>(multimap.begin(), multimap.end()). It'd be nice to have some way to override that because it causes problems all over the place. It's not entirely trivial because Cython still needs to understand the template arguments for the return type though.

The best thing for the moment is just to omit the methods until we have a good solution.

[Dobatymo]

Actually my previous comment is slightly wrong. insert does work, it uses the templated type correctly. erase didn't work because that required the implicit conversion from iterator to const_iterator.
But that can actually be fixed if the conversion is done explicitly (although in pure c++ it would happen implicitly).

cdef multimap[int, int] m = multimap[int, int]()
m.erase(multimap[int, int].const_iterator(m.begin()), multimap[int, int].const_iterator(m.end()))

compiles fine.

[scoder]

@scoder I think I got all of them. Usually the constructor, insert and at methods can throw exceptions. Since there are not at methods on multisets, it's only the first two.

Basically anything that does memory allocation can fail with a C++ exception. I would guess that the iterator constructors also do that.

[da-woods]

Basically anything that does memory allocation can fail with a C++ exception. I would guess that the iterator constructors also do that.

I can't find a definitive reference for all the iterator constructors, but that begin and end look to be noexcept and they return iterators, it must be possible to construct an iterator without risking an exception.

[scoder]

I can't find a definitive reference for all the iterator constructors, but that begin and end look to be noexcept and they return iterators, it must be possible to construct an iterator without risking an exception.

I was more thinking of constructors like const_iterator(iterator). Or are those just some kind of cast?

[da-woods]

I was more thinking of constructors like const_iterator(iterator). Or are those just some kind of cast?

So the copy constructor and copy assignment (iterator to iterator) is explicitly safe (as a reference, section E.4.4 https://www.stroustrup.com/3rd_safe.pdf). I'm not sure if iterator to const_iterator is explicitly included in that, but I don't see why it'd need to throw an exception if you can copy without needing to, and construct a new iterator in begin without needing to.

[scoder]

Ok, I guess we're safe then. Everything else seems to be returning by reference or by value.

[scoder]

Thanks