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-09-30 21:46:50


On Mon, 30 Sep 2013 14:20:40 -0700, Jonathan Wakely
<jwakely.boost_at_[hidden]> wrote:

> On 30 September 2013 21:53, Mostafa wrote:
>>>
>>> Why do you choose a different "efficient type" for an 'int' parameter
>>> vs a 'const int' parameter?
>>>
>>
>> You're most likely reading this message out of context. If you start
>> with
>> Sergey's response it'll probably make more sense.
>
> No, I've read the whole thread.
>
> It sounds like your code to generate signatures has a bug and doesn't
> model the rules of C++.
>
> I repeat: Why would you choose a different "efficient type" for an
> 'int' parameter vs a 'const int' parameter?
>
> I would say if you're doing that then you're doing something wrong, so
> should fix it to remove top-level const, because that's what C++ does
> and because it's probably the right thing to do anyway.

Ah, ok, I had the use case reversed. Let's try this:

struct SomeUserClass
{
   static void foo(int const x)
   {
     SomeCodeGenClass::foo(x);
   }
};

SomeCodeGenClass::foo is a mere parameter forwarder, so the goal is to do
it as efficiently as possible. It's signature is constructed from
SomeUserClass::foo. For correctness, that should be:

void SomeCodeGenClass::foo(int const & x)

But, function_types<SomeUserClass::foo>::arg1_type resolves to int, so
that add_reference'ing will give the following signature for the TMP
constructed SomeCodeGenClass::foo

void SomeCodeGenClass::foo(int & x)

Which will give a compiler error for SomeUserClass::foo. Note, this is a
really watered down example, so if function_types doesn't work with static
member functions make the functions free, etc...

And I'm not arguing that either type_traits or function_types should
behave differently, I was wondering if a general solution exists for such
a situation.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk