On 07/30/12 16:58, Steven Watanabe wrote:
AMDG
On 07/30/2012 11:06 AM, Larry Evans wrote:
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/...
Specifies that the T... are placeholders; however, it doesn't specify that they be unique; hence,
tuple<concept,_a,_a> x(int(0),std::vector<int>(0));
would satisfy the current description but wouldn't be right. Of course no one would intentionally do that; however, if the Tags are calculated in some meta-program, it might happened accidentally. Hence the requires class should also say, "If T... are not unique, no diagnostic occurs", or something similar.
The reason I think "no diagnostic occurs" is that I've looked briefly in tuple.hpp, at the:
::boost::type_erasure::cons<Concept, T...> impl;
in the class tuple definition and the cons definition, and I don't see any check for duplicates.
The placeholders don't have to be unique, but if a placeholder is used more than once, the corresponding constructor arguments all need to be the same type. This is another instance of the same bug that you reported earlier (with the any constructor.). A fix to that, will automatically fix this as well.
Confirmed, as show by running the attached with the fix to any.hpp suggested here: http://article.gmane.org/gmane.comp.lib.boost.devel/233104 The output of running the attached is: ./tuple_dup_tags.exe v<3>() v<2>() v<1>() v<1>( v<1> const&) v<2>( v<2> const&) v<2>( v<3> const&) &t=0x7fffcd6f8e60 Showing that the first arg to the any CTOR corresponding to a _b is the one that determines the type of _b. As shown by the output, even though the 2nd _b is created with a v<3> argument, a v<2> is created. However, I think the docs should point out that this is what happens because some user might expect that a _b in the above test would map to a v<3> instead of a v<2>. -regards, Larry