[mpl] broken count and at metafunctions
As much as I love MPL, I have come across a couple more problems. First, on MSVC++ 7.1, "count" returns 0 with maps, when there is an element in the map with the specified key (and probably on other compilers as well, though I haven't checked the implementation). As well, while a 3-argument form of "at" is described in documentation (where the third argument is the default type returned by "at" if an element with the provided key does not exist in the container), it does not appear to be implemented in 1.33. -Matt Calabrese
Matt Calabrese <rivorus@gmail.com> writes:
As much as I love MPL, I have come across a couple more problems. First, on MSVC++ 7.1, "count" returns 0 with maps, when there is an element in the map with the specified key
That behavior matches the specified semantics of "count" perfectly: http://www.boost.org/libs/mpl/doc/refmanual/count.html Elements of a map are pairs.
(and probably on other compilers as well, though I haven't checked the implementation). As well, while a 3-argument form of "at" is described in documentation (where the third argument is the default type returned by "at" if an element with the provided key does not exist in the container), it does not appear to be implemented in 1.33.
You're right. Aleksey? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 8/30/05, David Abrahams <dave@boost-consulting.com> wrote:
Matt Calabrese <rivorus@gmail.com> writes:
That behavior matches the specified semantics of "count" perfectly:
http://www.boost.org/libs/mpl/doc/refmanual/count.html
Elements of a map are pairs.
There appears to be a conflict in documentation, then. While the count description reads as you claim, check the documentation of count listed in map's description: http://www.boost.org/libs/mpl/doc/refmanual/map.html Taken directly from that page: " count<m,k>::type The number of elements with the key k in m; see Associative Sequence." In this case, I guess it's the documentation that must be changed. -Matt Calabrese
On 8/30/05, Matt Calabrese <rivorus@gmail.com> wrote:
In this case, I guess it's the documentation that must be changed.
-Matt Calabrese
Actually, I take that back. I believe I was correct in my first post. Counting by key is how count should be defined for associative containers, just like it is with STL containers. Don't change the documentation for count listed in Associative Sequence and map documentation, since counting by entire element type in a map wouldn't exactly be very useful and wouldn't be consistent with the STL. I stand by my original statement that it's the implementation which should be changed, not the documentation. For now, I can always just use has_key and use that value as a 1 or a 0 for count, but that doesn't exactly help out since I would like my code to also work with theoretical associative sequences which can have multiple mapped values per key, such as with a theoretical ::boost::mpl::multimap. MPL's count should be like STL's count for associative containers. Also, as a side note, the templates key_type and value_type are great, however, can I suggest possibly changing value_type to mapped_type? The reason being to be consistent with the STL, since an STL container's value_type for a map would be the pair, while the mapped_type is what would be the mapped type of the associative sequence. This isn't as big of a deal, but if you are concerned with consistency, it might be a good idea to change (or at least add a mapped_type template and leave value_type so that it doesn't break old code). -Matt Calabrese
Forgive me for posting three times in a row, but I just realized that the reason why this conflict appears in the first place is because of the difference between <algorithm> count and count as a member of associative sequences in the STL. Since there is currently no distinction between these two types of count in MPL, the conflict simply cannot be resolved (it is conceivable that in certain cases you may wish to count by value_type whereas sometimes you may wish to count by key_type, such as the STL allows, so both forms of count should be useable for associative sequences). It seems as though the only way to resolve this would be to have two differently named counts, such as count and count_by_key appropriately. -Matt Calabrese
Matt Calabrese <rivorus@gmail.com> writes:
Forgive me for posting three times in a row, but I just realized that the reason why this conflict appears in the first place is because of the difference between <algorithm> count and count as a member of associative sequences in the STL. Since there is currently no distinction between these two types of count in MPL, the conflict simply cannot be resolved (it is conceivable that in certain cases you may wish to count by value_type whereas sometimes you may wish to count by key_type, such as the STL allows, so both forms of count should be useable for associative sequences). It seems as though the only way to resolve this would be to have two differently named counts, such as count and count_by_key appropriately.
I'm not ignoring you, but Aleksey is really responsible for most of the implementation stuff so I'll leave it to him to respond. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Matt Calabrese writes:
Forgive me for posting three times in a row, but I just realized that the reason why this conflict appears in the first place is because of the difference between <algorithm> count and count as a member of associative sequences in the STL.
Yep.
Since there is currently no distinction between these two types of count in MPL, the conflict simply cannot be resolved (it is conceivable that in certain cases you may wish to count by value_type whereas sometimes you may wish to count by key_type, such as the STL allows, so both forms of count should be useable for associative sequences). It seems as though the only way to resolve this would be to have two differently named counts, such as count and count_by_key appropriately.
I'd go with 'key_count' for the latter, but otherwise I agree with the analysis. -- Aleksey Gurtovoy MetaCommunications Engineering
From: David Abrahams <dave@boost-consulting.com>
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
I'd go with 'key_count' for the latter, but otherwise I agree with the analysis.
"count_key" sounds more natural to me, FWIW.
I'd say it isn't a matter of whether it sounds "natural" but that this is an algorithm and should be described by a verb or verbal phrase. IOW, I agree that "count_key" is better. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
I'd go with 'key_count' for the latter, but otherwise I agree with the analysis.
"count_key" sounds more natural to me, FWIW.
I'd say it isn't a matter of whether it sounds "natural" but that this is an algorithm and should be described by a verb or verbal phrase.
That's a little less clear in a pure functional system. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
I'd go with 'key_count' for the latter, but otherwise I agree with the analysis.
"count_key" sounds more natural to me, FWIW.
I'd say it isn't a matter of whether it sounds "natural" but that this is an algorithm and should be described by a verb or verbal phrase.
That's a little less clear in a pure functional system.
Well, if you don't think that's a good basis for choosing the name, then "key_count" sounds like the number of keys, and "count_key" sounds like a command, so the former seems more appropriate. That is, the computation results in a value and that value's name is "key_count." IOW, which sounds "natural" really depends upon how you view the expression. If it is an action/command/algorithm, then "count_key" is more appropriate. If it is a result, then "key_count" is more appropriate. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Matt Calabrese writes:
Also, as a side note, the templates key_type and value_type are great, however, can I suggest possibly changing value_type to mapped_type? The reason being to be consistent with the STL, since an STL container's value_type for a map would be the pair, while the mapped_type is what would be the mapped type of the associative sequence. This isn't as big of a deal, but if you are concerned with consistency, it might be a good idea to change (or at least add a mapped_type template and leave value_type so that it doesn't break old code).
I agree that 'mapped_type' would be a better name here, but then I find the whole '_type' convention for these two suboptimal: 1. It makes it sound like the templates are trivial metafuntions for the corresponding STL typedefs, which is not the case. 2. Pretty much everything in MPL is a type; the '_type' suffix doesn't add any semantic value to the names besides contributing to #1, and, I believe, is somewhat misleading: "What do you mean, key _type_? It's key's value!". So, if we were to rename/introduce synonyms for these, I'd rather keep 'key'/'value' terminology and replace '_type' with something more explicit/less ambiguous, e.g.: +-------------------------------+---------------------------------------------------------------+ | ``key_part<s,x>::type`` | The key part of the element ``x`` that would be | | | used to identify ``x`` in ``s``; see |key_part|. | +-------------------------------+---------------------------------------------------------------+ | ``value_part<s,x>::type`` | The value part of the element ``x`` that would be | | | used for ``x`` in ``s``; see |value_part|. | +-------------------------------+---------------------------------------------------------------+ -- Aleksey Gurtovoy MetaCommunications Engineering
On 8/31/05, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
I agree that 'mapped_type' would be a better name here, but then I find the whole '_type' convention for these two suboptimal:
1. It makes it sound like the templates are trivial metafuntions for the corresponding STL typedefs, which is not the case.
2. Pretty much everything in MPL is a type; the '_type' suffix doesn't add any semantic value to the names besides contributing to #1, and, I believe, is somewhat misleading: "What do you mean, key _type_? It's key's value!".
So, if we were to rename/introduce synonyms for these, I'd rather keep 'key'/'value' terminology and replace '_type' with something more explicit/less ambiguous [key_part and value_part table]
Definately agreed on those points, though I still say it should be mapped_part as opposed to value_part as it's the mapped part of the value (again, to stay consistent with STL naming). -- -Matt Calabrese
David Abrahams writes:
(and probably on other compilers as well, though I haven't checked the implementation). As well, while a 3-argument form of "at" is described in documentation (where the third argument is the default type returned by "at" if an element with the provided key does not exist in the container), it does not appear to be implemented in 1.33.
You're right. Aleksey?
It's a known issue, see "Outstanding issues" list at the top of http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?MPL_TODO_List. Patches are welcome! -- Aleksey Gurtovoy MetaCommunications Engineering
participants (4)
-
Aleksey Gurtovoy -
David Abrahams -
Matt Calabrese -
Rob Stewart