Usage of Q_ASSUME in connect ?
-
While learning about connect I encountered this funky usage of Q_ASSUME
Q_ASSUME(connect (...))After reading the doc about Q_ASSUME I wonder why would compiler cared about (condition) during compilation.
I thought the (condition) is dynamic , hence how can it be "evaluated / assumed " during compilation ?It seem that Q_ASSUME is actually sort-of Q_VALIDATE the condition as far as syntax goes.
id Q_ASSUME(bool expr)
Causes the compiler to assume that expr is true. This macro is useful for improving code generation, by providing the compiler with hints about conditions that it would not otherwise know about. However, there is no guarantee that the compiler will actually use those hints.
Huh? Do I detect sort-of "fuzzy logic"? yes , no, maybe?This macro could be considered a "lighter" version of Q_ASSERT(). While Q_ASSERT will abort the program's execution if the condition is false, Q_ASSUME will tell the compiler not to generate code for those conditions. Therefore, it is important that the assumptions always hold, otherwise undefined behaviour may occur.
If expr is a constantly false condition, Q_ASSUME will tell the compiler that the current code execution cannot be reached. That is, Q_ASSUME(false) is equivalent to Q_UNREACHABLE().
In debug builds the condition is enforced by an assert to facilitate debugging.
Note: Q_LIKELY() tells the compiler that the expression is likely, but not the only possibility. Q_ASSUME tells the compiler that it is the only possibility.
This function was introduced in Qt 5.0.
See also Q_ASSERT(), Q_UNREACHABLE(), and Q_LIKELY().
-
@AnneRanch said in Usage of Q_ASSUME in connect ?:
After reading the doc about Q_ASSUME I wonder why would compiler cared about (condition) during compilation.
I thought the (condition) is dynamic , hence how can it be "evaluated / assumed " during compilation ?Q_ASSUMEis all about code generation. When there is an if-else block in code, the compiler will generate machine (binary) code for both branches. At runtime, depending on the condition, either path will be taken. But if you useQ_ASSUME, the code for one of the branches will not be generated at all.This potentially makes the executable smaller (because there is less code) and faster (CPU does not need to check a condition - it simply assumes it was
trueand executes the code immediately).Whether it makes any sense to wrap
connect()withQ_ASSUME- weeeell yes, but not because of the functionality described above. The point of usingQ_ASSUMEaround connect statement is to get a warning (at runtime) when connection fails - but only in debug mode. It is a tool to make sure your code is correct.Causes the compiler to assume that expr is true. This macro is useful for improving code generation, by providing the compiler with hints about conditions that it would not otherwise know about. However, there is no guarantee that the compiler will actually use those hints.
Huh? Do I detect sort-of "fuzzy logic"? yes , no, maybe?No fuzzy logic here at all. Compiler hints tell the compiler how it can optimize the code (depending on which optimization flags you pass to it when compiling) - some compilers will use those hints, some won't. Qt supports a huge array of compilers, in many versions, and the support for such hints may vary.
Think of it a bit like with performance benefits of using
const- most compilers do not care about it at all, but in theory, usingconsteverywhere should improve performance. -
@sierdzio said in Usage of Q_ASSUME in connect ?:
Compiler hints tell the compiler how it can optimize the code (depending on which optimization flags you pass to it when compiling)
Compiler hints tell the compiler how it can optimize the code (depending on which optimization flags you pass to it when compiling)
Thanks for the post.
The" Assume" does makes some sense after all. It would be less questionable if the doc said something about that it depends on optimization settings of the compiler instead of leaving it open to anything, including if it is raining or not- sort - of.'
