operator[]:"index out of range"

[Christian Ehrlicher]

@jeremy_k said in operator[]:"index out of range":

agree with the sentiment. Don't capture an auto scoped variable by reference.
I'm skeptical that this is the issue here. timer1 is auto scoped to the same function, and declared after val.

This does not matter - but as @JonB pointed out it's not inside a function but inside main() so val is still alive. Even though the design is crappy.

[jeremy_k]

@Christian-Ehrlicher said in operator[]:"index out of range":

@jeremy_k said in operator[]:"index out of range":
it's not inside a function but inside main() so val is still alive. Even though the design is crappy.

main() is just another function, with the same auto scoping rules. I think we, including @JonB are all coming to the same conclusion: bad design, but not the issue at hand.

[Christian Ehrlicher]

@jeremy_k said in operator[]:"index out of range":

main() is just another function, with the same auto scoping rules.

You did not understood what I've said. val is a danling reference in this case:

void ClassFoo::foo()
{
    Speedometer *ptrSpeedometer=qobject_cast<Speedometer*>(speedometer);

    qreal val=0;
    ptrSpeedometer->setSpeed(val);

    QObject::connect(&timer1,&QTimer::timeout,[&] ()
    {
          val = val + 10;
          ptrSpeedometer->setSpeed(val);
    });
    timer1.start(100);
}

I never expected such code inside main() so ...

[JonB]

@jeremy_k
As @Christian-Ehrlicher writes. Passing a local/auto variable to a lambda as a reference is not in itself any problem. Loads of lambdas may be written which use this, e.g. (I haven't looked) perhaps some of the std:: container algorithms may use reference parameters.

The potential problem arises when it is a slot for a signal, because that continues to use the lambda after the function which does the connect() exits. Then a reference parameter to a variable local to the function would indeed be a problem, as @Christian-Ehrlicher's code shows. However, in this particular case the OP is doing it from main(), so that will not be a problem here.

[Paul Colby]

Surely the OP issue is:

QQmlApplicationEngine engine;
const QUrl url(QStringLiteral("qrc:/main.qml")); ///< You've done nothing with this yet.

QObject * object = engine.rootObjects()[0]; ///< rootObjects is empty, 0 is not a valid index.

...

engine.load(url); ///< Only now do you add anything to the engine.

return app.exec();

Presumably you need to call QQmlApplicationEngine::load() earlier, or fetch the first root-object later?

Cheers.

[JonB]

@Paul-Colby said in operator[]:"index out of range":

QObject * object = engine.rootObjects()[0]; ///< rootObjects is empty, 0 is not a valid index.

If this is indeed the cause of the "index out of range", how do you explain the OP's
@Swathika said in operator[]:"index out of range":

In the 34th line I'm getting the error

Which (when he forces us to count) appears to be within the lambda?

I don't know anything about QML, what you have said would make perfect sense but not given that line number? Unless we don't trust the OP's reports. Which is why if we were given the stack trace as previously requested we would know for sure! :)

[CPPUIX]

@JonB said in operator[]:"index out of range":

Unless we don't trust the OP's reports.

I trust the error to point the problematic line in this case, there is no operator[] in line 34, but there is one in line 24...maybe just a typo from OP?

[JonB]

@Abderrahmene_Rayene This is why users could take the 10 seconds required to put in qDebug() statements or run under debugger, instead of making readers speculate :)

[CPPUIX]

This post is deleted!

[jeremy_k]

@JonB said in operator[]:"index out of range":

@jeremy_k
As @Christian-Ehrlicher writes. Passing a local/auto variable to a lambda as a reference is not in itself any problem. Loads of lambdas may be written which use this, e.g. (I haven't looked) perhaps some of the std:: container algorithms may use reference parameters.

The potential problem arises when it is a slot for a signal, because that continues to use the lambda after the function which does the connect() exits. Then a reference parameter to a variable local to the function would indeed be a problem, as @Christian-Ehrlicher's code shows. However, in this particular case the OP is doing it from main(), so that will not be a problem here.

Yes, I did understand. It appears to be my point that was misunderstood. The code, abbreviated, was:

int main() {
    qreal val=0;
    QTimer timer1;

        QObject::connect(&timer1,&QTimer::timeout,[&] ()
         {
           val = val + 10;
        });

        timer1.start(100);
}

Given:

• Connections are broken when the object that emits the signal is destroyed.
• timer1 has the same automatic block scope as val. val is declared before timer1, and will therefore be destructed after it.
• There is no evidence of a move operation to alter the lifetime of timer1.

We can determine that the reference to val does not dangle prior to timer1 being destroyed, breaking the connection.

The situation would be the same in any function, or for any code block. main() does not alter the situation.