passing POD by value with const qualifiers. Silly or not?

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080221/dea170d4/attachment.sig>