Concurrent map equivalent

[Defohin]

struct NameHelper
{
    NameHelper(const QString &extra) : _extra(extra) { }

    typedef QString result_type;

    QString operator()(const QString &name)
    {
        for(int i = 0; i < 999999; ++i) {
            qDebug() << "block";
        }

        return QString("Hello %1 %2").arg(name).arg(_extra);
    }

    QString _extra;
};

QStringList names = { "john", "jane" };
QString extra = "doe";

QFuture<QString> example = QtConcurrent::mapped(names, NameHelper(extra));

[VRonin]

operator() will be executed in another thread, it will not block the GUI thread, it will not return until completed (of course)

[Defohin]

@VRonin But why is it not appearing the window If it's running in another thread?

[VRonin]

@Defohin said in Concurrent map equivalent:

But why is it not appearing the window If it's running in another thread?

WOW! we are taking this on a whole new level here! you need a QFutureWatcher on the QFuture and a slot connected to the resultReadyAt signal to display the results in the GUI

[Defohin]

You are a god, thank you.

[VRonin]

I definitely am not, trust me.

Just as a final remark, in your case, if you can use C++11, I'd use std::bind over the function object

[Defohin]

I'm using std::bind now... I realized something:
THe threads is not closing if the application closes, meaning that if I close the window it will still open. (if I do a heavy work inside the called function).

[VRonin]

Since you are using mapped you can call cancel() to signal to abort the calculation

[Defohin]

@VRonin Do I have to connect that to a signal from the window for when it's closing or something?

[VRonin]

• If you want to stop the calculation when the widget is closed reimplement the closeEvent and call cancel on the QFuture
• If you want to stop the calculation when the widget is destroyed reimplement the destructor and call cancel on the QFuture

[Defohin]

@VRonin Thank you very much.