[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:       Andre =?iso-8859-1?q?W=F6bbeking?= <Woebbeking () kde ! org>
Date:       2008-02-20 7:56:59
Message-ID: 200802200856.59331.Woebbeking () kde ! org
[Download RAW message or body]

On Wednesday 20 February 2008 08:42:26 Thiago Macieira 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.

I'm not speaking about BIC or BC.

> 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.

AFAIK it's OK to have parameters without const in the declaration and with 
const in the implementation. Not sure about return values.

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