Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

What is the lifetime of this temporary?



  • socket->sendBinaryMessage(QByteArray(msgpack_buf.data(), msgpack_buf.size()));
    

    My gut says create the byte array before the call. My curiosity says let the world burn.
    sendBinaryMessage is wanting a reference, btw. This is a websockets call.



  • https://en.cppreference.com/w/cpp/language/lifetime

    Temporary objects are created when a prvalue is materialized so that it can be used as a glvalue, which occurs (since C++17) in the following situations:

    * binding a reference to a prvalue 
    

    [...]

    All temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created, and if multiple temporary objects were created, they are destroyed in the order opposite to the order of creation. This is true even if that evaluation ends in throwing an exception.

    There are two exceptions from that:

    * The lifetime of a temporary object may be extended by binding to a const lvalue reference or to an rvalue reference (since C++11), see reference initialization for details.
    * The lifetime of a temporary object created when evaluating the default arguments of a default or copy constructor used to initialize an element of an array ends before the next element of the array begins initialization. 
    

    The LaTeX source for the relevant standard section is at https://github.com/cplusplus/draft/blob/master/source/basic.tex

    The QByteArray will be created prior to binding it to the reference passed to sendBinaryMessage, and destroyed when the function returns.

    One technique for experimentally exploring this type of problem is to add print statements to constructors, destructors, and operater= overloads to clarify when and how an object is accessed.

    eg:

    class MyByteArray: public QByteArray {
        MyByteArray(...) : QByteArray(...) { printf("MyByteArray()\n"); }
    };
    


  • https://en.cppreference.com/w/cpp/language/lifetime

    Temporary objects are created when a prvalue is materialized so that it can be used as a glvalue, which occurs (since C++17) in the following situations:

    * binding a reference to a prvalue 
    

    [...]

    All temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created, and if multiple temporary objects were created, they are destroyed in the order opposite to the order of creation. This is true even if that evaluation ends in throwing an exception.

    There are two exceptions from that:

    * The lifetime of a temporary object may be extended by binding to a const lvalue reference or to an rvalue reference (since C++11), see reference initialization for details.
    * The lifetime of a temporary object created when evaluating the default arguments of a default or copy constructor used to initialize an element of an array ends before the next element of the array begins initialization. 
    

    The LaTeX source for the relevant standard section is at https://github.com/cplusplus/draft/blob/master/source/basic.tex

    The QByteArray will be created prior to binding it to the reference passed to sendBinaryMessage, and destroyed when the function returns.

    One technique for experimentally exploring this type of problem is to add print statements to constructors, destructors, and operater= overloads to clarify when and how an object is accessed.

    eg:

    class MyByteArray: public QByteArray {
        MyByteArray(...) : QByteArray(...) { printf("MyByteArray()\n"); }
    };
    


  • This is interesting:

        // if argument is a const then lifetime of temporary is extended
        auto func = [](const QByteArray& str){
            qDebug() << str;
        };
    
        func(QByteArray("hello"));
        QByteArray str2("world");
        func(str2);
    

    @jeremy_k , Like the references you provided say it will not compile unless that function is a const. This makes sense to me the way this behaves.


Log in to reply