DCOP slot 'char' arg types?, was Re: on the use of char

Richard Dale Richard_Dale at tipitina.demon.co.uk
Fri Jul 30 11:53:17 BST 2004


On Thursday 29 July 2004 16:03, Richard Dale wrote:
> What's the correct thing to do when sending chars over DCOP?
>
> I send out a char like this:
> *stream << (Q_INT8) stack[i].s_char;
>
> And receive a char like this:
> Q_INT8 temp;
> *stream >> temp;
>
> So should these Q_INT8 types be just 'char' instead, as they can be
> unsigned or signed on different platforms?

I defined a dcop slot like this:

k_dcop:
    char foobar(char c);

And it generated this code, which doesn't compile:

bool KBookmarkNotifier::process(const QCString &fun, const QByteArray &data, 
QCString& replyType, QByteArray &replyData)
{
    if ( fun == KBookmarkNotifier_ftable[0][1] ) { // char foobar(char)
        char arg0;
        QDataStream arg( data, IO_ReadOnly );
        arg >> arg0;
        replyType = KBookmarkNotifier_ftable[0][0];
        QDataStream _replyStream( replyData, IO_WriteOnly );
        _replyStream << foobar(arg0 );
    } else {
        return DCOPObject::process( fun, data, replyType, replyData );
    }
    return true;
}

kbookmarknotifier_skel.cc: In member function `virtual bool
   KBookmarkNotifier::process(const QCString&, const QByteArray&, QCString&,
   QByteArray&)':
kbookmarknotifier_skel.cc:27: no match for `QDataStream& >> char&' operator
/home/duke/src/kde/HEAD/qt-copy/include/qdatastream.h:72: candidates are:
   QDataStream& QDataStream::operator>>(Q_INT8&)

Should 'char arg0' be defined as 'Q_INT8 arg0' or 'Q_UINT8 arg0' instead?

-- Richard




More information about the kde-core-devel mailing list