Dear all, Consider this: ---[code]--- #include <boost/mpl/front.hpp> #include <boost/mpl/set.hpp> #include <boost/type_traits/is_same.hpp> #define BOOST_TEST_MODULE "boost::mpl::set tests" #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE( mpl_set ) { typedef boost::mpl::set<int,long,char> s; BOOST_CHECK( (boost::is_same<int, boost::mpl::front<s>::type>::value) ); // Test #1 BOOST_CHECK( (boost::is_same<long, boost::mpl::front<s>::type>::value) ); // Test #2 BOOST_CHECK( (boost::is_same<char, boost::mpl::front<s>::type>::value) ); // Test #3 } ---[/code]--- Reading the docs http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/set.html the "front" of a set<t1,t2,...,tn> return the first element type in s which for me is t1 So what I expect is the test to fail on tests #2 and #3 and hence to succeed on test #1 Instead the test fails on tests #1 and #2 and succeeds on test #3. Looking inside the code I find out this is OK since a setN<T1,..,TN> is defined from TN and set{N-1}<T1,...,T{N-1}>, resulting in TN be the very front element Anyway, in my opinion this is counterintuitive. Maybe a note in the document would be helpful. What do you think? Thank you very much! Cheers, -- Marco
On Mon, Aug 31, 2009 at 2:20 AM, Marco Guazzone<marco.guazzone@gmail.com> wrote:
Dear all,
Consider this:
---[code]--- #include <boost/mpl/front.hpp> #include <boost/mpl/set.hpp> #include <boost/type_traits/is_same.hpp>
#define BOOST_TEST_MODULE "boost::mpl::set tests" #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_CASE( mpl_set ) { typedef boost::mpl::set<int,long,char> s; BOOST_CHECK( (boost::is_same<int, boost::mpl::front<s>::type>::value) ); // Test #1 BOOST_CHECK( (boost::is_same<long, boost::mpl::front<s>::type>::value) ); // Test #2 BOOST_CHECK( (boost::is_same<char, boost::mpl::front<s>::type>::value) ); // Test #3 } ---[/code]---
Reading the docs http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/set.html the "front" of a set<t1,t2,...,tn> return the first element type in s which for me is t1 So what I expect is the test to fail on tests #2 and #3 and hence to succeed on test #1
Instead the test fails on tests #1 and #2 and succeeds on test #3.
Looking inside the code I find out this is OK since a setN<T1,..,TN> is defined from TN and set{N-1}<T1,...,T{N-1}>, resulting in TN be the very front element
Anyway, in my opinion this is counterintuitive.
Maybe a note in the document would be helpful.
What do you think?
Thank you very much!
I do not know of set being ordered or any implementation I use (considering that runtime sets are generally hash maps), so I would not expect that to be ordered personally. I would use vector if I want something ordered.
On Mon, Aug 31, 2009 at 10:30 AM, OvermindDL1<overminddl1@gmail.com> wrote:
I do not know of set being ordered or any implementation I use (considering that runtime sets are generally hash maps), so I would not expect that to be ordered personally. I would use vector if I want something ordered.
You're right and in fact the runtime std::set does not provide a "front" operation. I think you've got the problem: since sets are usually unordered a "front" operation may introduce ambiguities. Since mpl::set provides this operation I think its behavior should be made more explicit in order to avoid any ambiguities (like the ones I've described in the previous email) -- Marco
On Mon, Aug 31, 2009 at 2:37 AM, Marco Guazzone<marco.guazzone@gmail.com> wrote:
On Mon, Aug 31, 2009 at 10:30 AM, OvermindDL1<overminddl1@gmail.com> wrote:
I do not know of set being ordered or any implementation I use (considering that runtime sets are generally hash maps), so I would not expect that to be ordered personally. I would use vector if I want something ordered.
You're right and in fact the runtime std::set does not provide a "front" operation.
I think you've got the problem: since sets are usually unordered a "front" operation may introduce ambiguities.
Since mpl::set provides this operation I think its behavior should be made more explicit in order to avoid any ambiguities (like the ones I've described in the previous email)
Yea, I agree that the documentation on this should be cleared, not necessarily by saying that front returns possibly any element, but rather how it internally stores the type so we know what things like front/back/etc. will actually do. :)
On Mon, Aug 31, 2009 at 10:51 AM, OvermindDL1<overminddl1@gmail.com> wrote:
Yea, I agree that the documentation on this should be cleared, not necessarily by saying that front returns possibly any element, but rather how it internally stores the type so we know what things like front/back/etc. will actually do. :)
Hmmm... But in this way (i.e., tying an high-level behavior to a low-level detail) we (as users) loose any advantage of encapsulation. I think it would be better to fix (and document) the behavior of "front< set >" regardless of the internal representation of a set. That is, the front element of a set is "blah blah blah" regardless of how a set is internally implemented. Another solution is to deprecate and subsequently remove this operation from sets; but probably this impacts on backward compatibility. Ah, obviously the same issue apply to mpl::map (didn't tried yet but conceptually the front of a map has an ambiguos meaning) -- Marco
On Tue, Sep 1, 2009 at 2:18 AM, Marco Guazzone<marco.guazzone@gmail.com> wrote:
On Mon, Aug 31, 2009 at 10:51 AM, OvermindDL1<overminddl1@gmail.com> wrote:
Yea, I agree that the documentation on this should be cleared, not necessarily by saying that front returns possibly any element, but rather how it internally stores the type so we know what things like front/back/etc. will actually do. :)
Hmmm... But in this way (i.e., tying an high-level behavior to a low-level detail) we (as users) loose any advantage of encapsulation.
I think it would be better to fix (and document) the behavior of "front< set >" regardless of the internal representation of a set. That is, the front element of a set is "blah blah blah" regardless of how a set is internally implemented.
Another solution is to deprecate and subsequently remove this operation from sets; but probably this impacts on backward compatibility.
Ah, obviously the same issue apply to mpl::map (didn't tried yet but conceptually the front of a map has an ambiguos meaning)
I just think of it this way, front() will get the first element in a container, now sometime those containers are linear, like vector or list or cons, but other times they are not linear, then who knows what I may get first, like with set and map. Besides, is it not more proper to use an iterator? I have never personally used front, always use an iterator since I need all elements to test with when using a set/map, only ever used it with vector/list/cons, where it makes sense.
On Tue, Sep 1, 2009 at 10:39 AM, OvermindDL1<overminddl1@gmail.com> wrote:
I just think of it this way, front() will get the first element in a container, now sometime those containers are linear, like vector or list or cons, but other times they are not linear, then who knows what I may get first, like with set and map. Besides, is it not more proper to use an iterator? I have never personally used front, always use an iterator since I need all elements to test with when using a set/map, only ever used it with vector/list/cons, where it makes sense.
Well, as I said previously, I completely agree with you. I've used front just for trying all mpl::set operations. But the point is that "front" is defined for sets (and maps) so we and possible future users need a clear definition of its behavior on these data structures, or at least a big-note beside it saying "Please don't use this operation for XXX since it is implementation dependent" where XXX in {"mpl::set", "mpl::map"} I'm curious what MPL authors think about this. -- Marco
On Tue, Sep 1, 2009 at 2:59 AM, Marco Guazzone<marco.guazzone@gmail.com> wrote:
On Tue, Sep 1, 2009 at 10:39 AM, OvermindDL1<overminddl1@gmail.com> wrote:
I just think of it this way, front() will get the first element in a container, now sometime those containers are linear, like vector or list or cons, but other times they are not linear, then who knows what I may get first, like with set and map. Besides, is it not more proper to use an iterator? I have never personally used front, always use an iterator since I need all elements to test with when using a set/map, only ever used it with vector/list/cons, where it makes sense.
Well, as I said previously, I completely agree with you. I've used front just for trying all mpl::set operations.
But the point is that "front" is defined for sets (and maps) so we and possible future users need a clear definition of its behavior on these data structures, or at least a big-note beside it saying "Please don't use this operation for XXX since it is implementation dependent" where XXX in {"mpl::set", "mpl::map"}
I'm curious what MPL authors think about this.
I am curious too, wonder where they are... ;-)
participants (2)
-
Marco Guazzone -
OvermindDL1