http://blog.qt.io/blog/2017/06/22/using-compiler-explorer-qt/
git clone https://github.com/mattgodbolt/compiler-explorer.git
Requires Node >= 8
http://blog.qt.io/blog/2017/06/22/using-compiler-explorer-qt/
git clone https://github.com/mattgodbolt/compiler-explorer.git
Requires Node >= 8
#ifdef _MSVC | |
/* MSVC: 4 params in registers, remainder on stack) */ | |
// x86-64 msvc (note:long = 32bit, long long = 64-bit) | |
long long add(int rcx, int rdx, int r8d, int r9d, int rsp40, int rsp48, int rsp56, int rsp64) { | |
return rcx + rdx + r8d + r9d + rsp40 + rsp48 + rsp56 + rsp64; // xmm0 | |
} |
// connect(nameCompleter_, SIGNAL(activated(QString)), this, SLOT(selected(QString))); | |
connect(nameCompleter_, QOverload<const QString &>::of(&QCompleter::activated), this, &ProspectFinder::selected); |
https://www.kdab.com/goodbye-q_foreach/
Conclusion
Here’s why you’ll want to port away from Q_FOREACH, ideally to C++11 ranged for-loops:
Q_FOREACH is deprectaed since 5.7
It only works efficiently on (some) Qt containers; it performs prohibitively expensive on all std containers, QVarLengthArray, and doesn’t work at all for C arrays.
Even where it works as advertised, it typically costs ~100 bytes of text size more per loop than the C++11 ranged for-loop.
Its unconditionally taking a copy of the container makes it hard to reason about the loop.
modern cmake https://cliutils.gitlab.io/modern-cmake/
cmake documentation https://cmake.org/documentation/
Cmake AntiPatterns http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/
cmake & Qt
statusIndicator->setPixmap(style()->standardPixmap(QStyle::SP_DialogOkButton)); | |
// see https://doc.qt.io/qt-5/qstyle.html#StandardPixmap-enum |
#include <cstddef> | |
#include <cstdint> | |
// gcc >= 4.8.1 | |
// clang >= 3.5 | |
uint16_t a1 = 0x0102; | |
uint32_t a2 = 0x01020304; | |
uint64_t a3 = 0x0102030405060708ull; | |
auto b1 = __builtin_bswap16(a1); | |
auto b2 = __builtin_bswap32(a2); | |
auto b3 = __builtin_bswap64(a3); |
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3092.pdf - 3.10
— An lvalue (so called, historically, because lvalues could appear on the left-hand side of an assignment expression) designates a function or an object. [ Example: If E is an expression of pointer type, then *E is an lvalue expression referring to the object or function to which E points. As another example, the result of calling a function whose return type is an lvalue reference is an lvalue. —end example ]
— An xvalue (an “eXpiring” value) also refers to an object, usually near the end of its lifetime (so that its resources may be moved, for example). An xvalue is the result of certain kinds of expressions involving rvalue references (8.3.2). [ Example: The result of calling a function whose return type is an rvalue reference is an xvalue. —end example ]
— A glvalue (“generalized” lvalue) is an lvalue or an xvalue.
— An rvalue (so called, historically, because rvalues could appear on the right-hand side of an assi
#include <QDragEnterEvent> | |
#include "dragdropfilter.h" | |
bool DragDropFilter::eventFilter(QObject* obj, QEvent* event) | |
{ | |
auto w = qobject_cast<QWidget*>(obj); | |
if(w == nullptr) { | |
return true; | |
} |
// in Widget A, residing in some other layout, but part of the same window as widget B | |
// someBox is a widget somewhere in widgetA | |
void WidgetA::resizeEvent(QResizeEvent *event) | |
{ | |
widgetB->setBoxYPos(someBox->mapTo(this->window(), someBox->rect().topLeft()).y()); | |
QWidget::resizeEvent(event); | |
} | |
// in widget B, which has a member QVBoxLayout* mainLayout |