[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-20 7:42:26
Message-ID: 200802200842.26807.thiago () kde ! org
[Download RAW message or body]


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.

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