jniemann66

// pick a good fft size for fftw (of the form 2^a * 3^b * 5^c * 7^d * [1|11|13] )
int selectFFTSize(int n)
{
	int s = 1;

	for(int ef : {1, 11, 13}) {
		for(int d = 1 ; d <= n; d *= 7) {
			for(int c = 1; c <= n; c *= 5) {
				for(int b = 1; b <= n; b *= 3) {

jniemann66

https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/

Q: what about this (see below ) ? ... because I do shit like this all the time:

(for const Suburb& suburb : thing.getSuburbList()) 
{
}

jniemann66

// 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

jniemann66

#include <QDragEnterEvent>
#include "dragdropfilter.h"

bool DragDropFilter::eventFilter(QObject* obj, QEvent* event)
{
	auto w = qobject_cast<QWidget*>(obj);
	if(w == nullptr) {
		return true;
	}

jniemann66

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

jniemann66

#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);

jniemann66

statusIndicator->setPixmap(style()->standardPixmap(QStyle::SP_DialogOkButton));

// see https://doc.qt.io/qt-5/qstyle.html#StandardPixmap-enum

jniemann66

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

jniemann66

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.

jniemann66

//	connect(nameCompleter_, SIGNAL(activated(QString)), this, SLOT(selected(QString)));
	connect(nameCompleter_, QOverload<const QString &>::of(&QCompleter::activated), this, &ProspectFinder::selected);