Boost logo

Boost :

Subject: Re: [boost] [type_traits][function_types] Discard param const qualification, bug or feature?
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2013-10-01 12:55:39

On Tue, 01 Oct 2013 00:30:02 -0700, Jonathan Wakely
<jwakely.boost_at_[hidden]> wrote:

> On 1 October 2013 05:45, Mostafa wrote:
>> On Mon, 30 Sep 2013 19:54:56 -0700, Gavin Lambert wrote:
>>> A simple add_reference is obviously the wrong thing to be doing then.
> Indeed.
>>> In general, you can take any parameter type T and wrap it as a "const
>>> T&"
>>> (or if you prefer, "T const&") and it will do the right thing, unless
>>> T was
>>> already a reference. But note that you must use a const reference -- a
>>> non-const reference won't work.
>> Not in my particular use case. The code I was working is generated by a
>> mix
>> of PPMP and TMP techniques. The argument x is eventually forwarded to
>> some
>> user block of code, where the user expects it to be of the same type as
>> the
>> one he/she specified in the signature of SomeUserClass::foo. So had the
>> user
>> specified this instead:
>> struct SomeUserClass
>> {
>> static void foo(int x)
>> {
>> SomeCodeGenClass::foo(x);
>> }
>> };
>> Then it is expected that x would be mutable in that forwarded-to block
>> of
>> code.
> Well then you're doing it wrong. You should base the forwarded
> parameter type on decltype(x) not the parameter type in the function
> signature. The function signature doesn't include the top-level
> const, that's how C++ works.

Yup, and that's what I basically concluded way back in my response to
Sergey's post. (Though decltype was not considered since I'm targeting

Boost list run by bdawes at, gregod at, cpdaniel at, john at