[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: passing POD by value with const qualifiers. Silly or not?
From:       Thiago Macieira <thiago () kde ! org>
Date:       2008-02-21 7:29:03
Message-ID: 200802210829.03743.thiago () kde ! org
[Download RAW message or body]


Matt Rogers wrote:
>Ok, so from what I understand I can have:
>
>void foo( int bar ) in my header file
>and
>void foo( const int bar) in my source file and be ok. Correct?

That's what Andre claims, yes.

I doubt that's portable.

>Does this have any effect on signals and slots? So, IOW, if I have the
>following:

Slots are normal functions, so the same applies to them.

Signals are not. They are functions implemented by moc, not you.

>Q_SIGNALS:
>    void bar(const int);

This will make moc implement the signal as:
void Classname::bar(const int _t1)
{
    void *_a[] = { 0, const_cast<void*>(reinterpret_cast<const 
void*>(&_t1)) };
    QMetaObject::activate(this, &staticMetaObject, 1, _a);
}

There's a const_cast there, so this code will probably compile. But I fail 
to see the point in forcing the const.

>is it valid to connect it like so
>
>    connect( this, SIGNAL(bar(int)), this, SLOT(mySlot(int));

Yes, normalisation transforms
	const int		-> int
	int const		-> int
	const int &	-> int
	int const &	-> int

>where mySlot is declared as:
>
>public Q_SLOTS:
>    void mySlot(int);
>
>IIRC, it is, since moc strips off the const qualifiers, but I would
>like clarification on that as well.
>
>As suggested, since there seem to be places in the API that const
>qualify POD types, I will be cleaning those up soon.

I'd expect you to place const in your slot, not in your signal.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]