$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-04 17:12:23
Dave Gomboc wrote:
>>The Function Type library uses tag types to represent a type's
>>attributation, such as its calling convention or wether it is
>>variadic.
>>
>>Tags that represent the values of a single property are called
>>property tags. These tags can be used to determine whether one
>>property of a type has a particular value.
>>
>> is_function< T, variadic >
>> is_function< T, default_call >
>>
>>Does it work?
>
>
> It's better than before. I still think you shouldn't mix "uses tag
> types" (plural) with "a type's attributation" (singular), but you're
> the author. ;-) I'd still go with "to represent attributations of
> types", similar to how I wrote that line previously. Oh, also, fix
> the spelling of "whether".
>
I'm not a native English speaker and I know English has tighter restrictions than
my mother language at this point. So there's a good chance my sentence is indeed
ill-formed.
The Function Type library uses tag types to represent one or more properties
of a type. Each property describes an optional attribuation.
The object of the sentence is plural now.
>
>
>>I have. Try these use cases:
>>
>> // a remove constness (of the pointee) from a member
>>function pointer type T
>> function_type<signature<T>,tag<signature<T>,non_const>
>>::type
>>
>> // shortcut:
>> function_type<T, non_const >::type
>>
>>or
>>
>> // create a (possibly decorated) function type's
>>variadic version
>> function_type<signature<T>,tag<signature<T>,variadic>
>>::type
>>
>> // shortcut:
>> function_type<T, variadic >::type
>
>
> Is manipulating these using MPL containers too much hassle for too
> little benefit?
In case you are referring to the shortcut: It's just syntactic sugar.
In case you are referring to the tags: It would be overkill - tags hold
expressions of bitwise integral arithmetic.
In case you are referring to the function's component types:
These /are/ specified by MPL sequences. If they are specified by a type that is
not a sequence, a shortcut is triggered to create a sequence (signature<T>) from
that type.
Did any answer fit your question? I'ld be curious to know which one, then.
>
> If <T, nonvariadic, variadic, variadic, nonvariadic, variadic> is
> really going to be the same as <T, variadic, nonvariadic, variadic>,
> then even testing for equivalence between tags becomes somewhat of a
> chore.
>
You shouldn't test tags for equivalence and the design keeps you from doing it.
<snip>
I cut this part of the discussion because it's based on a misunderstanding and far
away from bringing us further. I'll try to clarify my point by ansering a tiny
part of it:
> "If I assign more than one value at the same time, I really mean the
> last one", which is different behaviour than runtime-C++ gives.
Why are you looking at a specialization of 'tag' being an assignment? It's a
function! We can define functions like 'tag' in runtime C++ as well:
tag_t tag(tag_t tag1, tag_t tag2)
{
// for each property in tag2:
// assign that property value of tag2 to tag1
// return changed tag1
}
Are you trying to say that a good interface must not contain such a function?
> That's why this asymmetric disambiguation behaviour feels awkward to
> me.
>
Please note that the asymmetric behaviour is _essential_ and not for disambiguation:
tag<signature<T>,a_property_tag>
describes a transformation of T's properties. 'signature<T>' already contains all
properties, the property value described by 'a_property_tag' is overridden!
As a conclusion I will use this ^^ example in place of the obviously confusing
"tag<variadic,non_variadic> nonsense".
I apologize for adding to this confusion by my "loud thinking" in the previous post!
Thanks,
Tobias