[Interest] Some Qt classes (QUuid) do not work with std C++ containers (unordered_map)? [C++ question]

Ahmad Samir a.samirh78 at gmail.com
Tue Jul 6 11:30:50 CEST 2021


On 06/07/2021 11:17, Till Oliver Knoll wrote:
> Dear all,
> 
> Disclaimer: my C++ knowledge is a bit rusty, especially as far as
> standard C++ containers and modern features (C++11, 17, 20) are
> concerned. That's exactly the reason why I have started another small
> open source project, and also the reason why I now tend to use C++
> standard containers (instead of the Qt ones - for no other reason to get
> more knowledge about them).
> 
> Every then and when I stumble over some Qt classes which do not work
> with some given C++ container classes. In some cases I could explain
> this for myself based on some "web research", e.g. the "shared data"
> concept of e.g. QString does not work with the concept of "unique
> pointers" (which are to be stored in some C++ container. And I
> intuitively understand that.
> 
> But now I stumbled over the following example for which I do not find
> any relevant "web research" results (specific to Qt classes). I am
> trying to create an unordered hashmap, with QUuid as key, as in:
> 
> #include <unordered_map> #include <QUuid> ... // Won't compile
> std::unordered_map<QUuid, QString> exportPlugins;
> 
> The compiler (I am currently using the default compiler being used on
> macOS 11.4 "Big Sur", with the open source Qt 5.12.2) is complaining
> with several error messages (see below for complete error messages), but
> they seem to be related to an "implicitly-deleted default constructor"
> 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/unordered_map:435:
> Fehler: call to implicitly-deleted default constructor of
> 'std::__1::hash<QUuid>'
> 
> which seems to be caused by some explicitly deleted default constructor:
> 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/utility:1564:5:
> note: '__enum_hash' has been explicitly marked deleted here
> 
> Looking at the QUuid class declaration I do not find anything suspicious
> at first glance. Specifically I do see a default constructor (but I do
> understant that the error message is referring to some other default
> constructor of __enum_hash, in the <utility> header). In fact, when I
> exchange QUuid with QString, as in:
> 
> // This works std::unordered_map<QString, QString> exportPlugins;
> 
> then everything compiles fine.
> 
> This is with a CMake based project, with
> 
> set(CMAKE_CXX_STANDARD17)
> 
> set(CMAKE_CXX_STANDARD_REQUIREDON)
> 
> So this should be using a C++17 compliant compiler.
> 
> Questions:
> 
> I can use a QString instead of a QUuid here just fine (or use some Qt
> container class here instead, namely QMap), but I am curious about
> "what's going on here":
> 
> * Is this a known limitation of QUuid (and possibly other classes), that
> it cannot be used in C++ container classes?
> 
> * Or asked differently: why does the "template expansion" (?) get into
> the case of __enum_hash (when using QUuid), which apparently has an
> explicitly deleted default constructor (or why is the default
> constructor of QUuid not sufficient)?
> 
> * Is there a way to tell (given the Qt's class declaration) whether a Qt
> class is suitable for C++ container classes?
> 
> * Or am I doing something wrong here (wrong compiler, wrong project
> settings, missing includes, ...)?
> 
> As this is most likely a basic C++ noob question I am fine with any RTFM
> answers here :) But again, so far I did not find anything related to
> QUuid and C++ container classes on the web.
> 
> Thank you so much,
> 
> Oliver
> 
> 

Hello. Have a look at https://www.kdab.com/qt-datatypes-in-standard-library/

I think that is the issue you're hitting.


[...]
-- 
Ahmad Samir


More information about the Interest mailing list