Am 06.07.21 um 11:30 schrieb Ahmad Samir: > On 06/07/2021 11:17, Till Oliver Knoll wrote: >> ... >> #include <unordered_map> #include <QUuid> ... // Won't compile >> std::unordered_map<QUuid, QString> exportPlugins; >> ... > Hello. Have a look at > https://www.kdab.com/qt-datatypes-in-standard-library/ > > I think that is the issue you're hitting.
From the article: "The Standard Library unordered associative containers (std::unordered_map, std::unordered_set, and so on), as well as other third party implementations (like the excellent robin-map <https://github.com/Tessil/robin-map>), require, by default, a specialization of std::hash to be available for the key type we want to use" That's exactly the answer I was looking for :) So thank you so much, article is now bookmarked! Yes, the "joys" of C++ and the lack of explicit interface support (I am thinking of "Java interfaces" now - to my understanding the C++20 "concepts" feature is meant to implement the "interface" concept to quite some degree). Many STL features "implicitly expect" some features of a given class/type. That is particularly true when implementing "iterators", for instance (https://www.internalpointers.com/post/writing-custom-iterators-modern-cpp) "C++ expects some properties from an iterator" What? Why? Which ones? |struct Iterator { using iterator_category = std::forward_iterator_tag; using difference_type = std::ptrdiff_t; using value_type = int; using pointer = int*; // or also value_type* using reference = int&; // or also value_type& }; | Aha: so I just have to *know* about the existence of e.g. "iterator_category". If I don't set it here my iterator code will still compile - but I can't use my iterator then for some STL algorithms later on. And it goes on with adding a begin() and end() method, which are - implicitly - called when doing a "C++ style iteration". So why are they to be called begin() and end() and return an iterator of some sort? Because you need to *know* this. And the problem with this "you need to know" concept seems to go on with this std::hash to be implemented by any given class to be used in unordered_map. To be fair, this is also kind of true for the Java equivalent HashMap - except that every Java Object already implements a (default) hashCode() method. But yes, you also need to know about its existence, in order to possibly re-implement that hashCode() method to get more meaningful hash values for your custom class - so arguably the C++ compiler barking at me if no such hash method exists is arguably better than to silently "use the default hashValue() method"? Anyway, just some random thoughts of mine about this "need to know" topic :) This question is hence fully answered for me! So thanks again for the quick reply, Oliver ||
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
