[type_erasure]suggest tuple doc contain requires clause specifying T... are unique
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. -regards, Larry
On 07/30/12 13:06, 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.
Running the attached test, which includes a tuple with duplicate tags, produces no compile error; hence, I think putting: "no diagnostic occurs" in this case in the tuple docs is justified. I thought maybe mpl::map, which is used in tuple to create the bindings, would check for duplicates; however, the second attachment, with an mpl::map containing duplicate keys, compiles OK. -regards, Larry
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. In Christ, Steven Watanabe
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
participants (2)
-
Larry Evans -
Steven Watanabe