On Mon, 30 Sep 2013 05:24:45 -0700, Rob Stewart wrote:

On Sep 29, 2013, at 11:00 PM, Mostafa wrote:

...

On Sun, 29 Sep 2013 14:44:52 -0700, Sergey Zhuravlev wrote:

...

Signature type int(int, const std::string) can be used as parameter for some compiletime algorithm. For example, algorithm that generate new signature type with optimal transfer arguments int (int, const std::string&) or generate signature with all argument references int (int&, const std::string&)

That was exactly the use case and the problem I had. Fortunately for me, I was able to specify the return type and parameters_type (as an mpl::vector) separately, which solved the issue. But I don't know if this is doable in general. For example, what does one do in the following scenario:

template <typename T> struct Foo { void mybar( // Construct efficient argument transfer signature for T::bar ) { T::bar(....); } };

without forcing the user to seperately specify T::bar paramtypes as a separate template parameter?

#include ... boost::call_traits<typename T::bar>::param_type

I should have been more specific, bar is some member function of T. So in Foo:mybar, the goal is to reconstruct T::bar's paramtypes as "efficient types". That's what the other person's post was also referring to. So if a client passes the following struct as a template parameter to Foo: struct ClientClass { static void bar(int const) { ... } }; the library is able to instantiate the following Foo::mybar void Foo::mybar(int const & x) { ClientClass::bar(x); }

On Mon, 30 Sep 2013 12:49:44 -0700, Jonathan Wakely wrote:

On 30 September 2013 20:22, Mostafa wrote:

...

I should have been more specific, bar is some member function of T. So in Foo:mybar, the goal is to reconstruct T::bar's paramtypes as "efficient types". That's what the other person's post was also referring to. So if a client passes the following struct as a template parameter to Foo:

struct ClientClass { static void bar(int const) { ... } };

You're presenting this class as having a function of that type, but it doesn't, your example is:

struct ClientClass { static void bar(int) { ... } };

...

the library is able to instantiate the following Foo::mybar

void Foo::mybar(int const & x) { ClientClass::bar(x); }

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.

On Mon, 30 Sep 2013 14:20:40 -0700, Jonathan Wakely 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_typesSomeUserClass::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.

On Mon, 30 Sep 2013 19:54:56 -0700, Gavin Lambert wrote:

On 10/1/2013 2:46 PM, Quoth Mostafa:

...

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)

This would also be the correct signature for foo(int x) -- because they're the same thing.

...

But, function_typesSomeUserClass::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)

A simple add_reference is obviously the wrong thing to be doing then.

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. (The fact that it's actually a reference when it arrives there is immaterial to the user.) Now, I can make a copy of x before the final stage, but that would partially defeat the purpose of passing by reference, since a copy is already made at SomeUserClass::foo. In sum, this particular problem maybe restricted to PPMP/TMP code, and it maybe that pure TMP code doesn't suffer from this.

On Tue, 01 Oct 2013 00:30:02 -0700, Jonathan Wakely 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 C++03.)

On Tue, 01 Oct 2013 03:22:10 -0700, Rob Stewart wrote:

On Sep 30, 2013, at 9:46 PM, Mostafa wrote:

...

On Mon, 30 Sep 2013 14:20:40 -0700, Jonathan Wakely 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?

Let me rephrase that. int and int const are passed from the caller to the function by value. What the function does with the parameters is immaterial to the caller, so why would you treat them differently when forwarding them?

See my last response to Gavin.

On Oct 4, 2013, at 5:43 PM, Nevin Liber wrote:

On 1 October 2013 05:22, Rob Stewart wrote:

...

No, that should be int x. The reference is a pessimization for int. For larger types, const & is appropriate, though it will apply regardless of the top-level constness of the parameter. IOW, if the type is cheap to copy, copy it, regardless of top-level constness. If it isn't, pass it by const &. That's what call_traits<T>::param_type does for you.

It's more complicated than that. When you pass by value the compiler is allowed to assume there are no aliases to your object. Put another way, passing by reference can still be a pessimization for types larger than an int (and that is even before copy elision).

Granted, but I know of no way for a library to determine when pass-by-value would be better because of those optimizations. I suppose you could offer a wrapper type that indicates the desire for pass-by-value, even when call_traits would pass by reference. The developer could try that to see whether profiling shows improvement. ___ Rob (Sent from my portable computation engine)