summaryrefslogtreecommitdiffstats
path: root/src/corelib/doc/snippets/code/src_corelib_tools_qhash.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix some syntax errors in snippetsSzabolcs David2023-06-081-1/+1
| | | | | | | | | | | | - The following error occurs when trying to use these example codes: "error: expected primary-expression before ‘!=’ token" - Rename "map" to "hash" in the QHash snippet Amends 7d542e1daf09caadf6d3e36c4b09bdf94952c5a1. Pick-to: 6.6 6.5 Change-Id: I1ad5b799f444bf074dbfb44223c00770ecf456c7 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Brush up the container code snippetsFriedemann Kleint2023-05-041-29/+23
| | | | | | | | | | | | | | | | | | | | - Bring iterator loops into a consistent form using auto and creating and end variable, use cbegin()/cend() where suitable - Use (std::)endl instead of Qt::endl for iostreams - Fix removed container conversion API (QList::fromSet, QSet::toList()) - Use range-based for instead of foreach - Use initializer lists - Use qPrintable(QString) for output to std::ostream - Use qsizetype - Remove some unused snippets Complements f6b137bdc43d4021cbbe602759dbcced2e04d638. Pick-to: 6.5 Change-Id: I8a167099cdb224f45b984fa834d46269144a7ef0 Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Remove unused documentation code snippetsFriedemann Kleint2023-04-171-12/+0
| | | | | | | | | | | | | | | | | | | Modules: - Core - Gui - Widgets - Open(Widgets) - PrintSupport - Sql - Network - Concurrent - Testlib Pick-to: 6.5 Change-Id: I63e58c01bec4bd162486020f0085227fdaa83b18 Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QtBase/doc: fix examples for QHash/QMap/QMultiMap::erase()Christian Ehrlicher2023-03-311-28/+12
| | | | | | | | | | | | | QHash/MultiHash & QMap/MultiMap::erase() do no longer take an iterator in Qt6. Clean up the examples by only providing one example, the rest is common c++ which should not be handled in the Qt documentation. Also mention erase_if() and remove references to the (soon to be deprecated) Java-style iterators. Pick-to: 6.5 6.2 Fixes: QTBUG-105109 Change-Id: I47b11f3b5dcc173494e5c6f9ad0167c613b12209 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QHash: tame HasQHashSingleArgOverload ODR violationsGiuseppe D'Angelo2022-11-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qhashfunctions.h defines a catch-all 2-arguments qHash(T, seed) in order to support datatypes that implement a 1-argument overload of qHash (i.e. qHash(Type)). The catch-all calls the 1-argument overload and XORs the result with the seed. The catch-all is constrained on the existence of such a 1-argument overload. This is done in order to make the catch-all SFINAE-friendly; otherwise merely instantiating the catch-all would trigger a hard error. Such an error would make it impossible to build a type trait that detects if one can call qHash(T, size_t) for a given type T. The constraint itself is called HasQHashSingleArgOverload and lives in a private namespace. It has been observed that HasQHashSingleArgOverload misbehaves for some datatypes. For instance, HasQHashSingleArgOverload<int> is actually false, despite qHash(123) being perfectly callable. (The second argument of qHash(int, size_t) is defaulted, so the call *is* possible.) -- Why is HasQHashSingleArgOverload<int> false? This has to do with how HasQHashSingleArgOverload<T> is implemented: as a detection trait that checks if qHash(declval<T>()) is callable. The detection itself is not a problem. Consider this code: template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; class MyClass {}; size_t qHash(MyClass); static_assert(HasQHashSingleArgOverload<MyClass>); // OK Here, the static_assert passes, even if qHash(MyClass) (and MyClass itself) were not defined at all when HasQHashSingleArgOverload was defined. This is nothing but 2-phase lookup at work ([temp.dep.res]): the detection inside HasQHashSingleArgOverload takes into account the qHash overloads available when HasQHashSingleArgOverload was declared, as well as any other overload declared before the "point of instantiation". This means that qHash(MyClass) will be visible and detected. Let's try something slightly different: template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; size_t qHash(int); static_assert(HasQHashSingleArgOverload<int>); // ERROR This one *does not work*. How is it possible? The answer is that 2-phase name lookup combines the names found at definition time with the names _found at instantiation time using argument-dependent lookup only_. `int` is a fundamental type and does not participate in ADL. In the example, HasQHashSingleArgOverload has actually no qHash overloads to even consider, and therefore its detection fails. You can restore detection by moving the declaration of the qHash(int) overload *before* the definition of HasQHashSingleArgOverload, so it's captured at definition time: size_t qHash(int); template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; static_assert(HasQHashSingleArgOverload<int>); // OK! This is why HasQHashSingleArgOverload<int> is currently returning `false`: because HasQHashSingleArgOverload is defined *before* all the qHash(fundamental_type) overloads in qhashfunctions.h. -- Now consider this variation of the above, where we keep the qHash(int) overload after the detector (so, it's not found), but also prepend an Evil class implicitly convertible from int: struct Evil { Evil(int); }; size_t qHash(Evil); template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */; size_t qHash(int); static_assert(HasQHashSingleArgOverload<int>); // OK Now the static_assert passes. HasQHashSingleArgOverload is still not considering qHash(int) (it's declared after), but it's considering qHash(Evil). Can you call *that* one with an int? Yes, after a conversion to Evil. This is extremely fragile and likely an ODR violation (if not ODR, then likely falls into [temp.dep.candidate/1]). -- Does this "really matter" for a type like `int`? The answer is no. If HasQHashSingleArgOverload<int> is true, then a call like qHash(42, 123uz); will have two overloads in its overloads set: 1) qHash(int, size_t) 2) qHash(T, size_t), i.e. the catch-all template. To be pedantic, qHash<int>(const int &, size_t), that is, the instantiation of the catch-all after template type deduction for T (= int) ([over.match.funcs.general/8]). Although it may look like this is ambiguous as both calls have perfect matches for the arguments, 1) is actually a better match than 2) because it is not a template specialization ([over.match.best/2.4]). In other words: qHash(int, size_t) is *always* called when the argument is `int`, no matter the value of HasQHashSingleArgOverload<int>. The catch-all template may be added or not to the overload set, but it's a worse match anyways. -- Now, let's consider this code: enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); This code compiles, although we do not define any qHash overload specifically for enumeration types (nor one is defined by MyEnum's author). Which qHash overload gets called? Again there are two possible overloads available: 1) qHash(int, size_t). E1 can be converted to `int` ([conv.prom/3]), and this overload selected. 2) qHash(T, size_t), which after instantiation, is qHash<MyEnum>(const MyEnum &, size_t). In this case, 2) is a better match than 1), because it does not require any conversion for the arguments. Is 2) a viable overload? Unfortunately the answer here is "it depends", because it's subject to what we've learned before: since the catch-all is constrained by the HasQHashSingleArgOverload trait, names introduced before the trait may exclude or include the overload. This code: #include <qhashfunctions.h> enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); static_assert(HasQHashSingleArgOverload<MyEnum>); // ERROR will fail the static_assert. This means that only qHash(int, size_t) is in the overload set. However, this code: struct Evil { Evil(int); }; size_t qHash(Evil); #include <qhashfunctions.h> enum MyEnum { E1, E2, E3 }; qHash(E1, 42uz); static_assert(HasQHashSingleArgOverload<MyEnum>); // OK will pass the static_assert. qHash(Evil) can be called with an object of type MyEnum after an user-defined conversion sequence ([over.best.ics.general], [over.ics.user]: a standard conversion sequence, made of a lvalue-to-rvalue conversion + a integral promotion, followed by a conversion by constructor [class.conv.ctor]). Therefore, HasQHashSingleArgOverload<MyEnum> is true here; the catch-all template is added to the overload set; and it's a best match for the qHash(E1, 42uz) call. -- Is this a problem? **Yes**, and a huge one: the catch-all template does not yield the same value as the qHash(int, size_t) overload. This means that calculating hash values (e.g. QHash, QSet) will have different results depending on include ordering! A translation unit TU1 may have #include <QSet> #include <Evil> QSet<MyEnum> calculateSet { /* ... */ } And another translation unit TU2 may have #include <Evil> #include <QSet> // different order void use() { QSet<MyEnum> set = calculateSet(); } And now the two TUs cannot exchange QHash/QSet objects as they would hash the contents differently. -- `Evil` actually exists in Qt. The bug report specifies QKeySequence, which has an implicit constructor from int, but one can concoct infinite other examples. -- Congratulations if you've read so far. ========================= === PROPOSED SOLUTION === ========================= 1) Move the HasQHashSingleArgOverload detection after declaring the overloads for all the fundamental types (which we already do anyways). This means that HasQHashSingleArgOverload<fundamental_type> will now be true. It also means that the catch-all becomes available for all fundamental types, but as discussed before, for all of them we have better matches anyways. 2) For unscoped enumeration types, this means however an ABI break: the catch-all template becomes always the best match. Code compiled before this change would call qHash(int, size_t), and code compiled after this change would call the catch-all qHash<Enum>(Enum, size_t); as discussed before, the two don't yield the same results, so mixing old code and new code will break. In order to restore the old behavior, add a qHash overload for enumeration types that forwards the implementation to the integer overloads (using qToUnderlying¹). (Here I'm considering the "old", correct behavior the one that one gets by simply including QHash/QSet, declaring an enumeration and calling qHash on it. In other words, without having Evil around before including QHash.) This avoids an ABI break for most enumeration types, for which one does not explicitly define a qHash overload. It however *introduces* an ABI break for enumeration types for which there is a single-argument qHash(E) overload. This is because - before this change, the catch-all template was called, and that in turn called qHash(E) and XOR'ed the result with the seed; - after this change, the newly introduced qHash overload for enumerations gets called. It's very likely that it would not give the same result as before. I don't have a solution for this, so we'll have to accept the ABI break. Note that if one defines a two-arguments overload for an enum type, then nothing changes there (the overload is still the best match). 3) Make plans to kill the catch-all template, for Qt 7.0 at the latest. We've asked users to provide a two-args qHash overload for a very long time, it's time to stop working around that. 4) Make plans to switch from overloading qHash to specializing std::hash (or equivalent). Specializations don't overload, and we'd get rid of all these troubles with implicit conversions. -- ¹ To nitpick, qToUnderlying may select a *different* overload than the one selected by an implicit conversion. That's because an unscoped enumeration without a fixed underlying type is allowed to have an underlying type U, and implicitly convert to V, with U and V being two different types (!). U is "an integral type that can represent all the enumerator values" ([dcl.enum/7]). V is selected in a specific list in a specific order ([conv.prom]/3). This means that in theory a compiler can take enum E { E1, E2 }, give it `unsigned long long` as underlying type, and still allow for a conversion to `int`. As far as I know, no compiler we use does something as crazy as that, but if it's a concern, it needs to be fixed. [ChangeLog][Deprecation Notice] Support for overloads of qHash with only one argument is going to be removed in Qt 7. Users are encouraged to upgrade to the two-arguments overload. Please refer to the QHash documentation for more information. [ChangeLog][Potentially Binary-Incompatible Changes] If an enumeration type for which a single-argument qHash overload has been declared is being used as a key type in QHash, QMultiHash or QSet, then objects of these types are no longer binary compatible with code compiled against an earlier version of Qt. It is very unlikely that such qHash overloads exist, because enumeration types work out of the box as keys Qt unordered associative containers; users do not need to define qHash overloads for their custom enumerations. Note that there is no binary incompatibity if a *two* arguments qHash overload has been declared instead. Fixes: QTBUG-108032 Fixes: QTBUG-107033 Pick-to: 6.2 6.4 Change-Id: I2ebffb2820c553e5fdc3a341019433793a58e3ab Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use SPDX license identifiersLucie Gérard2022-05-161-49/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Associative containers: add a way to obtain a key/value rangeGiuseppe D'Angelo2022-03-041-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our associative containers' iterator's value_type isn't a destructurable type (yielding key/value). This means that something like for (auto [k, v] : map) doesn't even compile -- one can only "directly" iterate on the values. For quite some time we've had QKeyValueIterator to allow key/value iteration, but then one had to resort to a "traditional" for loop: for (auto i = map.keyValueBegin(), e = keyValueEnd(); i!=e; ++i) This can be easily packaged in an adaptor class, which is what this commmit does, thereby offering a C++17-compatible way to obtain key/value iteration over associative containers. Something possibly peculiar is the fact that the range so obtained is a range of pairs of references -- not a range of references to pairs. But that's easily explained by the fact that we have no pairs to build references to; hence, for (auto &[k, v] : map.asKeyValueRange()) doesn't compile (lvalue reference doesn't bind to prvalue pair). Instead, both of these compile: for (auto [k, v] : map.asKeyValueRange()) for (auto &&[k, v] : map.asKeyValueRange()) and in *both* cases one gets references to the keys/values in the map. If the map is non-const, the reference to the value is mutable. Last but not least, implement pinning for rvalue containers. [ChangeLog][QtCore][QMap] Added asKeyValueRange(). [ChangeLog][QtCore][QMultiMap] Added asKeyValueRange(). [ChangeLog][QtCore][QHash] Added asKeyValueRange(). [ChangeLog][QtCore][QMultiHash] Added asKeyValueRange(). Task-number: QTBUG-4615 Change-Id: Ic8506bff38b2f753494b21ab76f52e05c06ffc8b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QHash: support std::hash as hashing functionGiuseppe D'Angelo2020-11-301-0/+10
| | | | | | | | | | | | | | | | | | | | In addition (and as a fallback) from requiring qHash, add support for std::hash specializations. This catches two birds with one stone: 1) users of Qt can simply specialize std::hash for their datatypes, and use them in both QHash and stdlib unordered associative containers; 2) we get QHash support for any (stdlib) datatype that is hashable without having to overload qHash for them. [ChangeLog][QtCore][QHash] QHash, QMultiHash and QSet now support for key types anything that can be hashed via std::hash, instead of always requiring a qHash() overload. Change-Id: Ib5ecba86e4b376d318389500bd24883ac6534c5f Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Remove documentation for removed qHash overloadVolker Hilsheimer2020-10-291-4/+0
| | | | | | | | QPair is an alias to std::pair in Qt 6, so no need for two qHash functions. Also remove note and snippet from std::pair overload documentation. Change-Id: Ica8f6961af1eac493e909ad06fe46f8f68542bc5 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Long live qHashMulti(Commutative)Giuseppe D'Angelo2020-05-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Add a helper function so that we have a shortcut. Instead of writing: QHashCombine hash; seed = hash(seed, fieldA); seed = hash(seed, fieldB); // etc. return seed; one can now simply write: return qHashMulti(seed, fieldA, fieldB, fieldC); Port a few usages inside qtbase as a demonstration. [ChangeLog][QtCore][QHash] Added the qHashMulti and qHashMultiCommutative functions as convenience helpers to calculate a hash from multiple variables (typically, data members of a class). Change-Id: I881a9ad41168df20ceecc6588a94abe7ddc6a532 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Change qHash() to work with size_t instead of uintLars Knoll2020-04-091-8/+8
| | | | | | | | | | | This is required, so that QHash and QSet can hold more than 2^32 items on 64 bit platforms. The actual hashing functions for strings are still 32bit, this will be changed in a follow-up commit. Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-02-041-2/+2
|\ | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf examples/widgets/widgets/imageviewer/imageviewer.cpp src/corelib/text/qchar.cpp src/corelib/time/qdatetime.cpp Change-Id: I9762f5c4ff650799219729d6aee79ac07ce9024a
| * Change examples and snippets to pass QDate and QTime by valueEdward Welbourne2020-01-301-2/+2
| | | | | | | | | | | | | | They're value types, so we should show them being used as such. Change-Id: If9f0c366fac66306b7861f04e2f047540d444acc Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
* | Qt 6: Deprecate QHash::insertMultiLars Knoll2019-12-121-16/+0
|/ | | | | | | | | [ChangeLog][QtCore][QHash] insertMulti(), unite() and values(const Key &key) are now deprecated. Please use QMultiHash instead. Change-Id: Ic14907fd5fd38d585708e2dcf2c0200d221ebb25 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Prefix textstream operators with Qt::Lars Knoll2019-05-021-14/+14
| | | | | | | As the non prefixed variants are deprecated Change-Id: I2ba09d71b9cea5203b54297a3f2332e6d44fedcf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Doc: Move literal code block to a separate fileCristian Maureira-Fredes2018-10-151-0/+20
| | | | | | | | | | | We need to override this snippet for the documentation we generate for Qt for Python, and it is easier to have it on a separate file. Task-number: PYSIDE-801 Task-number: PYSIDE-691 Change-Id: Ideb5b6af25024279f167137d3b65660bb9c96a7e Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Unify license header usage.Jani Heikkinen2016-03-291-3/+13
| | | | | | | | | Update files using old header.LGPL3 to header.LGPL Update files using old FDL template to use new one Update files using old BSD template to use new one Change-Id: I36a78272516f9953d02956522f285b40adfc8915 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Examples/Doc snippets: Fix single-character string literals.Friedemann Kleint2015-10-131-3/+3
| | | | | | | Use character literals where applicable. Change-Id: I79fa5018f05735201ae35ee94ba0d356fcad1056 Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
* Introduce QHash key iteratorsSérgio Martins2015-07-281-0/+19
| | | | | | | | | | | So we can have interoperability with algorithms. Motivated by inefficient code like qDeleteAll(hash.keys()) [ChangeLog][QtCore][QHash] Added key iterators, accessible through keyBegin() and keyEnd(). Change-Id: I1f9db8a7a4294e1556cbb50b8fe5ebdcf0dc29a2 Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Updated BSD licensed file headersJani Heikkinen2015-02-151-3/+3
| | | | | Change-Id: I6441ff931dbd33b698d762e6f6784898f3f60fe7 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Update copyright headersJani Heikkinen2015-02-111-5/+5
| | | | | | | | | | | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Outdated header.LGPL removed (use header.LGPL21 instead) Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing combination. New header.LGPL-COMM taken in the use file which were using old header.LGPL3 (src/plugins/platforms/android/extract.cpp) Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license combination Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
* Add qHashRange and qHashRangeCommutativeMarc Mutz2015-01-091-0/+14
| | | | | | | | | | | | | | | | | | | qHashRange() takes an (input iterator) range and hashes each element, combining the hash values using the hash combiner from Boost/N1837 with the magic number 0x9e3779b9, as described here: http://stackoverflow.com/questions/4948780/magic-number-in-boosthash-combine qHashRangeCommutative() does the same but with a cummutative combiner (unsigned addition) to create hash values that are order-independent, e.g. for hashed containers. The obvious combiner, XOR, is a bad one because it eliminates duplicate elements. Signed addition cannot be used, since signed overflow leads to undefined behavior. [ChangeLog][QtCore] Added qHashRange() and qHashRangeCommutative() functions to aid implementing qHash() overloads for custom types. Change-Id: I3c2bbc9ce4bd0455262a70e0cf248486525e534f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add qHashBits(), a hash function for a memory blockMarc Mutz2014-02-281-0/+10
| | | | | | | | | | | The function arguments have been chosen to avoid caller-side casting of argument types, when passing object addresses and type sizeof()s. [ChangeLog][QtCore] Added qHashBits() to aid implementing qHash() overloads for custom types. Change-Id: I983a8560769bb27e489f23ebb6db51850ddd65f2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update copyright year in Digia's license headersSergio Ahumada2013-01-181-1/+1
| | | | | Change-Id: Ic804938fc352291d011800d21e549c10acac66fb Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Change copyrights from Nokia to DigiaIikka Eklund2012-09-221-6/+6
| | | | | | | | Change copyrights and license headers from Nokia to Digia Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e Reviewed-by: Lars Knoll <lars.knoll@digia.com> Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
* Doc: Prepare for building modular QtCore docs.Casper van Donderen2012-04-191-0/+299
This change fixes most qdoc errors in QtCore. There are about 900 left. The main thing this change does is moving documentation from qtcore from /doc/src to /src/corelib/doc. Other issues resolved are mis-use of qdoc commands. Change-Id: I002d01edfb13575e8bf27ce91596a577a92562d1 Reviewed-by: Lars Knoll <lars.knoll@nokia.com> Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com> Reviewed-by: Jerome Pasion <jerome.pasion@nokia.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 06:30:38 +0000