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

Thiago Macieira thiago at
Thu Feb 21 07:29:03 GMT 2008

Matt Rogers wrote:
>Ok, so from what I understand I can have:
>void foo( int bar ) in my header file
>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

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

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

>    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) - thiago (AT)
    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: <>

More information about the kde-core-devel mailing list