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

[Matt Rogers]

On Wed, Feb 20, 2008 at 1:42 AM, Thiago Macieira <thiago at kde.org> wrote:
> Andre Wöbbeking wrote:
>  >On Wednesday 20 February 2008 06:04:24 Matt Rogers wrote:
>  >> Hi,
>  >>
>  >> So, I've been doing some review of decibel and I've seen some stuff
>  >> like this (from kdereview/decibel/src/server/contactmanager.h)
>  >>
>  >> Decibel::ChannelInfo
>  >> contactContactUsingAccount(const uint contact_id, const int
>  >> account_handle, const int type, const bool suppress_handler);
>  >>
>  >>
>  >> Most of us know that passing POD by value with a const qualifier is
>  >> kinda silly, since it has next to zero real effect.
>
>  I agree with Stephan and Andre here. I'll even give you examples from Qt:
>
>  src/xmlpatterns/api - headers do not include const unnecessarily
>  src/xmlpatterns/*~api - const is used on PODs
>  [That's a zsh extendedglob]
>
>
>  >It makes sense in the implementation but not in the API. As compromise
>  > we could remove the const in the header files but leave them in the
>  > source files (that is allowed for PODs).
>
>  No, it's not. Not only that, some compilers mangle the "const" as well, so
>  removing it if it was there is binary incompatible.
>
>  This applies as well to return types:
>         const int foo();
>
>  That generates a warning in gcc 4.3, but you can't remove it because it's
>  binary incompatible in MSVC.
>

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?

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

Q_SIGNALS:
    void bar(const int);

is it valid to connect it like so

    connect( this, SIGNAL(bar(int)), this, SLOT(mySlot(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.

Thanks for the feedback!
--
Matt