Important: Please read the Qt Code of Conduct -

QIODevice: Trouble replicating writeBlock behaviour

  • I have some old, Qt3-based code that shows me how to "talk" with a linux device driver. Basically, the device is handled like a file, I write commands and read the replies.

    However, I am trying to re-write it in clean Qt4 code, and have trouble replicating the exact behavior of the QIODevice::writeBlock method.

    The existing code (which is proven to work, although I cannot currently compile it), is simple enough:

    @bool CTouchpadIO::ExchangeMessage( QString csMessage )
    if( m_DevFile.isOpen() )
    m_DevFile.writeBlock( csMessage, csMessage.length() );
    m_aReply = m_DevFile.readAll();

    return true;
    return false;

    m_DevFile is a QFile.

    In my own code, I have tried to use:
    @ QString command = sm_cCommandProvideEvents;


    However, the compiler complains about this:

    bq. error: no matching function for call to 'QFile::write(QString&, int)'

    I have looked up writeBlock in the Qt sources, and found that it also takes only const char*, not QString.
    I would happily convert the QString to a const char*, if I knew which of the multiple ways to do that leads to the correct results. Basically, there must have been an implicit conversion going on in the writeBlock call, and I would like to know it's exact behavior, so I can mimic it.

    Any suggestions?

  • There's an "FAQ":/faq/answer/how_can_i_convert_a_qstring_to_char_and_vice_versa on the conversion topic.

    And there is no "correct" way to do it, it all depends on your data. If your commands consist of 7 bit ASCII characters only, QString::toLatin1() is a good choice.

  • It seems toLocal8Bit does what I need.


  • BTW, I had read the FAQ, but in the end, trial and error proved to be the way to go.

  • Moderators

    I would recommend against using toLocal8Bit(...) here: You might end up getting different output results based on the system/user using your application!

    All of toLatin1(...), toAscii(...) and toUtf8(...) have a well defined output.

Log in to reply