Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-11-19 03:28:05

Steven Watanabe wrote:
>>Tobias Schwinger wrote:
>>>Now folks complain more about the tags than before. Worse
>>>than that, I haven't been presented a single clearly
>>>superior alternative!
> Because there isn't one?

Maybe. I wouldn't want to claim that while I can neither prove nor disprove it.
I'm just trying to show that the design is reasonable.

>>>Steven Watanabe wrote:
>>>>For both components and the synthesis metafunctions,
>>>>having the result type as the first element of the sequence
>>>>doesn't really make sense to me. I would expect that
>>>>the return type would often need to be handled separately
>>>>from the parameters in the cases where anything other than
>>>>simply passing the result of components to function_type<...>
>>>>is needed.
>>>I found it preferable to have a one-type representation,
>>>but I'm currently not feeling to strong about it anymore.
>>>Your proposal might be a good idea -- I'll think about it.
> I don't have anything in particular against a one type representation.
> It is probably quite useful. I just don't think giving an mpl
> sequence a special meaning is the right way to do it.

I don't see it this way: a function is a compound type and the mpl sequence contains the component types. They are ordered left to right which seems pretty common, too.

>>>Two things:
>>>1. How to specify the properties for type synthesis?
>>>You proposed to strip it out, but I think that the compromising the symmetry of the library is far
>>>to high of a price for unspecified aesthetical reasons.
> If the tags can't be cleanly eliminated from the synthesis
> metafunctions too, then I agree completely.
> I can only think of two ways to do this.

I'm not sure I understand you correctly, here. To do what? Eliminate the tags? ...

> Neither
> one is completely satisfactory.
> 1.
> template<class R, class Args, class Option1, class Option2, class Option3>
> struct function_type :
> original_function_type<typename mpl::push_front<Args, R>::type,
> tag<Option1, Option2, Option3> > {};
> 2.
> template<class ReturnTypeAndArgsAndTagsRolledIntoASingleType>
> struct function_type : ... {};

... If so, I can't see any "tag elimination"...

> The first may be a little better, but then again it could work
> even with tags--in which case it is just extra syntactic sugar.
> The second one would basically be the inverse of components.
> In the second case a "constructor" for components with signature
> template<class R, class Args, class ... Options>
> would be needed.

... Both alternatives even seem to increase the presence of tags in the interface ...

I considered the first alternative when redesigning the library, but I chose the current design because it doesn't redundantly introduce lots of rarely needed template parameters.

>>2. The primary interface would be "shape shifting" based on the configuration:
>> is_fastcall_cc
>> is_stdcall_cc
>> is_*_cc
> What about is_same<calling_convention<F>::type, fastcall_cc>?

... Same here: The return type of that metafunction would be a tag again, wouldn't it?
Maybe I just lost track because of a missing sentence or something like that.



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