$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-11-27 18:35:28
Hi Steven,
nice to hear from you, again.
Steven Watanabe wrote:
> Suppose I want to change a function's calling convention.
> function_type<components<int(...)>, tag<components<int(...)>,
> stdcall_cc> >::type
Actually,
function_type< int(...), tag<components<int(...)>, stdcall_cc> >::type
is equivalent and doesn't read too bad, does it?
> This is awkward even if the function to be modified is simple.
> If on the other hand it is needed for a computed function type
> where typedef is impossible e.g. a function declaration....
> I believe this is one of the reasons MPL chose to pass containers
> to algorithms instead of iterator pairs.
>
> Now, about actually removing tags.
>
> How often are the cv tags likely to be used? They are redundant
> since for member functions this information is already available
> in the first parameter. If they are not a very common thing to
> need, I would propose simply removing them from the interface.
It might not be wise to throw out that feature. Currently cv-qualified function types are illegal, but it is likely they will be allowed in some contexts in the future (there is a defect report on that part of the standard). Further, these tags might come handy to work around BCC deficiencies.
> If you stick to the MPL sequence representation, what about
> adding the variable argument list onto the end?
> function_type<mpl::vector<int, int, varargs> >::type
> that way it looks more like the actual function type.
It's a cool idea, for sure! I'll pick it up in case I can eliminate all tag types except calling conventions (maybe by exploiting cv-keywords as mentioned in reply to Doug Gregor - but the syntax in that post is too irregular for my taste, still).
Regards,
Tobias