
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code? Thanks, John.

John Maddock wrote:
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just finished Fusion-2. The code is done :) We're working on the docs. I'd like to ask for a formal review. Is it possible to ask for a review on a promise that the docs will be finished when the review starts? Just so as to get it in the review queue? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

On Sun, 20 Nov 2005 08:41:57 +0800, Joel de Guzman wrote
John Maddock wrote:
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just finished Fusion-2. The code is done :) We're working on the docs. I'd like to ask for a formal review. Is it possible to ask for a review on a promise that the docs will be finished when the review starts? Just so as to get it in the review queue?
Yes, that's allowed although our review wizards seem to be MIA. Someone was asking for a review a few weeks back and I don't think they got a response... Jeff

Jeff Garland wrote:
On Sun, 20 Nov 2005 08:41:57 +0800, Joel de Guzman wrote
John Maddock wrote:
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just finished Fusion-2. The code is done :) We're working on the docs. I'd like to ask for a formal review. Is it possible to ask for a review on a promise that the docs will be finished when the review starts? Just so as to get it in the review queue?
Yes, that's allowed although our review wizards seem to be MIA. Someone was asking for a review a few weeks back and I don't think they got a response...
Ok, well then let this be a formal review request, FWIW. We should probably have vice wizards, no? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

On Mon, 21 Nov 2005 09:48:24 +0800, Joel de Guzman wrote
Jeff Garland wrote:
Yes, that's allowed although our review wizards seem to be MIA. Someone was asking for a review a few weeks back and I don't think they got a response...
Ok, well then let this be a formal review request, FWIW. We should probably have vice wizards, no?
We do -- Tom Brinkman and Ron Garcia -- but I think they are both MIA on the list. Best to send them email direct... Jeff

On Nov 20, 2005, at 9:10 PM, Jeff Garland wrote:
On Mon, 21 Nov 2005 09:48:24 +0800, Joel de Guzman wrote
Ok, well then let this be a formal review request, FWIW. We should probably have vice wizards, no?
We do -- Tom Brinkman and Ron Garcia -- but I think they are both MIA on the list. Best to send them email direct...
Hi Jeff, Though I haven't been actively posting on the list, I have been lurking so as to act on review requests (like the one above) and update the review schedule with respect to the latest changes. Nonetheless, a direct email to me couldn't hurt. Are there any other outstanding requests that have not been acted upon? Cheers, ron

"Ronald Garcia"
Though I haven't been actively posting on the list, I have been lurking so as to act on review requests (like the one above) and update the review schedule with respect to the latest changes. Nonetheless, a direct email to me couldn't hurt.
Are there any other outstanding requests that have not been acted upon?
Shmem, by Ion Gaztanaga, on Oct 12. /Pavel

Joel de Guzman wrote:
John Maddock wrote:
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just
Oops. Lemme rephrase: The fusion code in the spirit directory *is-a* TR1 conforming tuples implementation. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just
Oops. Lemme rephrase: The fusion code in the spirit directory *is-a* TR1 conforming tuples implementation.
I've tried converting the TR1 lib to use that implementation but I'm having trouble with the std::pair interface which appears not to work: tuple_size<std::pair<int, long> > doesn't have a data member "value" apparently. BOOST_STATIC_ASSERT((::boost::is_same< ::std::tr1::tuple_element<1, std::pair<int, long> >::type, long>::value)); Fails, I'm not sure what type tuple_element is reporting though. Finally the "get" function appears not to work with pairs. BTW is this implmentation documented anywhere? Regards, John.

John Maddock wrote:
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just
Oops. Lemme rephrase: The fusion code in the spirit directory *is-a* TR1 conforming tuples implementation.
I've tried converting the TR1 lib to use that implementation but I'm having trouble with the std::pair interface which appears not to work:
tuple_size<std::pair<int, long> > doesn't have a data member "value" apparently.
BOOST_STATIC_ASSERT((::boost::is_same< ::std::tr1::tuple_element<1, std::pair<int, long> >::type, long>::value));
Fails, I'm not sure what type tuple_element is reporting though.
Finally the "get" function appears not to work with pairs.
Oops, I knew I missed something. Well, that's easy enough to add. In fact, the latest Fusion (V2) has those interfaces. I can backport them to Fusion-1 in the weekend. Is that ok?
BTW is this implmentation documented anywhere?
Sorry, no. We're documenting Fusion-V2 though, the version that I asked a boost review for. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Oops, I knew I missed something. Well, that's easy enough to add. In fact, the latest Fusion (V2) has those interfaces. I can backport them to Fusion-1 in the weekend. Is that ok?
Sure, thanks.
BTW is this implmentation documented anywhere?
Sorry, no. We're documenting Fusion-V2 though, the version that I asked a boost review for.
Understood. Are there any differences between V1 and V2 tuples that I should be aware of? Thanks, John.

John Maddock wrote:
Sorry, no. We're documenting Fusion-V2 though, the version that I asked a boost review for.
Understood. Are there any differences between V1 and V2 tuples that I should be aware of?
AFAICT, none that'll affect the TR1 interface. In fact, the TR1 module is just a thin wrapper in V2, perhaps it can be used as is? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

AFAICT, none that'll affect the TR1 interface. In fact, the TR1 module is just a thin wrapper in V2, perhaps it can be used as is?
There appear to be other problems with the comparison operators, these are required to use only operators == and < on the types held by the tuple, but given: struct strict_comparison1{}; struct strict_comparison2{}; bool operator==(const strict_comparison1&, const strict_comparison1&); bool operator<(const strict_comparison1&, const strict_comparison1&); bool operator==(const strict_comparison2&, const strict_comparison2&); bool operator<(const strict_comparison2&, const strict_comparison2&); bool operator==(const strict_comparison1&, const strict_comparison2&); bool operator<(const strict_comparison1&, const strict_comparison2&); bool operator==(const strict_comparison2&, const strict_comparison1&); bool operator<(const strict_comparison2&, const strict_comparison1&); Then trying to instantiate the operators with: // strict comparisons: const std::tr1::tuple<strict_comparison1, strict_comparison2> comp1, comp2; verify_return_type(comp1 == comp2, false); verify_return_type(comp1 != comp2, false); verify_return_type(comp1 < comp2, false); verify_return_type(comp1 > comp2, false); verify_return_type(comp1 <= comp2, false); verify_return_type(comp1 >= comp2, false); Fails with some extremely criptic error messages in operator!= test_tuple_tricky.cpp c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_not_equal_to.hpp(25) : error C2784: 'disable_if<boost::fusion::is_sequence<Seq1>,bool>::type boost::fusion::operator !=(const Seq1 &,const boost::fusion::sequence_base<Seq2> &)' : could not deduce template argument for 'const boost::fusion::sequence_base<T2> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\not_equal_to.hpp(46) : see declaration of 'boost::fusion::operator`!='' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_not_equal_to.hpp(54) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_not_equal_to_detail::call<boost::fusion::detail::sequence_not_equal_to<Seq1,Seq2>,I1,I2>(const T &,const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, T=boost::fusion::detail::sequence_not_equal_to<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>,const boost::fusion::tuple2<strict_comparison1,strict_comparison2>> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_not_equal_to.hpp(39) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_not_equal_to<Seq1,Seq2>::call<I1,I2>(const I1 &,const I2 &,boost::mpl::false_)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\not_equal_to.hpp(32) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_not_equal_to<Seq1,Seq2>::call<boost::fusion::meta::begin<Sequence>::type,boost::fusion::meta::begin<Sequence>::type>(const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Sequence=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type ] c:\data\boost\develop\boost\libs\tr1\test\test_tuple_tricky.cpp(93) : see reference to function template instantiation 'bool boost::fusion::operator !=<boost::fusion::tuple2<T0,T1>,boost::fusion::tuple2<T0,T1>>(const boost::fusion::sequence_base<Sequence> &,const boost::fusion::sequence_base<Sequence> &)' being compiled with [ T0=strict_comparison1, T1=strict_comparison2, Sequence=boost::fusion::tuple2<strict_comparison1,strict_comparison2> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_not_equal_to.hpp And then many more like that. Any ideas? Note I haven't got around to attemping mixed sequence comparisons yet, so comparing tuple<strict_compare1, strict_compare2> and tuple<strict_compare2, strict_compare1> should also work OK, and again only invoke operators == and <. Regards, John.

John Maddock wrote:
AFAICT, none that'll affect the TR1 interface. In fact, the TR1 module is just a thin wrapper in V2, perhaps it can be used as is?
There appear to be other problems with the comparison operators, these are required to use only operators == and < on the types held by the tuple, but given:
[snips] Could you please email me the tests? I'll look into them. Or, are they in the CVS somewhere? Jaakko wrote the initial TR1 tests for fusion but those were written a long time ago. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

On Nov 25, 2005, at 11:14 AM, John Maddock wrote:
AFAICT, none that'll affect the TR1 interface. In fact, the TR1 module is just a thin wrapper in V2, perhaps it can be used as is?
There appear to be other problems with the comparison operators, these are required to use only operators == and < on the types held by the tuple, but given:
struct strict_comparison1{}; struct strict_comparison2{}; bool operator==(const strict_comparison1&, const strict_comparison1&); bool operator<(const strict_comparison1&, const strict_comparison1&); bool operator==(const strict_comparison2&, const strict_comparison2&); bool operator<(const strict_comparison2&, const strict_comparison2&); bool operator==(const strict_comparison1&, const strict_comparison2&); bool operator<(const strict_comparison1&, const strict_comparison2&); bool operator==(const strict_comparison2&, const strict_comparison1&); bool operator<(const strict_comparison2&, const strict_comparison1&);
Then trying to instantiate the operators with:
// strict comparisons: const std::tr1::tuple<strict_comparison1, strict_comparison2> comp1, comp2; verify_return_type(comp1 == comp2, false); verify_return_type(comp1 != comp2, false); verify_return_type(comp1 < comp2, false); verify_return_type(comp1 > comp2, false); verify_return_type(comp1 <= comp2, false); verify_return_type(comp1 >= comp2, false);
Fails with some extremely criptic error messages in operator!=
= between the elements etc. So I think == and < should stay as they are now, but
The specification of tuples was changed in the committee from the original proposal along the way. In particular, comparison operators were changed and the implementation in Fusion reflects the old specs. According to the old implementation, each operator only relied on the same elementwise operator. E.g. != was defined in terms of != between the elements, >= only used the definition of !=, <=, >= and > should be changed to be defined in terms of == and < for tuples. Best, Jaakko

--- Jaakko Jarvi <jarvi@cs.tamu.edu> wrote:
On Nov 25, 2005, at 11:14 AM, John Maddock wrote:
There appear to be other problems with the comparison operators, these are required to use only operators == and < on the types held by the tuple, but given:
struct strict_comparison1{}; struct strict_comparison2{}; bool operator==(const strict_comparison1&, const strict_comparison1&); bool operator<(const strict_comparison1&, const strict_comparison1&); bool operator==(const strict_comparison2&, const strict_comparison2&); bool operator<(const strict_comparison2&, const strict_comparison2&); bool operator==(const strict_comparison1&, const strict_comparison2&); bool operator<(const strict_comparison1&, const strict_comparison2&); bool operator==(const strict_comparison2&, const strict_comparison1&); bool operator<(const strict_comparison2&, const strict_comparison1&);
Then trying to instantiate the operators with:
// strict comparisons: const std::tr1::tuple<strict_comparison1, strict_comparison2> comp1, comp2; verify_return_type(comp1 == comp2, false); verify_return_type(comp1 != comp2, false); verify_return_type(comp1 < comp2, false); verify_return_type(comp1 > comp2, false); verify_return_type(comp1 <= comp2, false); verify_return_type(comp1 >= comp2, false);
Fails with some extremely criptic error messages in operator!=
Joel asked me to have a look at the fusion1 TR1 stuff. I've had a go at the support for pairs in tuple_element, tuple_size, and get. I've just modified the operators based on the comments above as well. I've updated some of the fusion tests, but I've not had chance to run your TR1 test material yet. My tests were compiled against mingw gcc, and all was ok. Anyway, hope this is helpful, let me know if there are any (other) problems. Cheers Dan ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Joel asked me to have a look at the fusion1 TR1 stuff. I've had a go at the support for pairs in tuple_element, tuple_size, and get. I've just modified the operators based on the comments above as well. I've updated some of the fusion tests, but I've not had chance to run your TR1 test material yet. My tests were compiled against mingw gcc, and all was ok.
Anyway, hope this is helpful, let me know if there are any (other) problems.
There are still lots of issue with the comparison operators: The first error occurs in the < comparison, which ends up calling operator > in sequence_less.hpp: namespace sequence_less_detail { template <typename T,typename I1, typename I2> bool call(T const& self,I1 const& a, I2 const& b) { return *a < *b || !(*b > *a) && T::call(fusion::next(a), fusion::next(b)); } } The thing is that's not a "less than" relation to begin with! It's called from sequence_less::call which constructs a comparison object of type equal_to, which looks rather suspicious to me! I'm attaching the error messages below, but I think you're going to have to work with the test cases I sent you, *and* devise some runtime tests to ensure that these operators actually do what they're supposed to. Thanks for persuing this, John. c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'disable_if<boost::fusion::is_sequence<Seq1>,bool>::type boost::fusion::operator >(const Seq1 &,const boost::fusion::sequence_base<Seq2> &)' : could not deduce template argument for 'const boost::fusion::sequence_base<T2> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(46) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(56) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less_detail::call<boost::fusion::detail::sequence_less<Seq1,Seq2>,I1,I2>(const T &,const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, T=boost::fusion::detail::sequence_less<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>,const boost::fusion::tuple2<strict_comparison1,strict_comparison2>> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(41) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less<Seq1,Seq2>::call<I1,I2>(const I1 &,const I2 &,boost::mpl::false_)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\less.hpp(32) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less<Seq1,Seq2>::call<boost::fusion::meta::begin<Sequence>::type,boost::fusion::meta::begin<Sequence>::type>(const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Sequence=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type ] c:\data\boost\develop\boost\libs\tr1\test\test_tuple_tricky.cpp(102) : see reference to function template instantiation 'bool boost::fusion::operator <<boost::fusion::tuple2<T0,T1>,boost::fusion::tuple2<T0,T1>>(const boost::fusion::sequence_base<Sequence> &,const boost::fusion::sequence_base<Sequence> &)' being compiled with [ T0=strict_comparison1, T1=strict_comparison2, Sequence=boost::fusion::tuple2<strict_comparison1,strict_comparison2> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'disable_if<boost::fusion::is_sequence<Seq2>,bool>::type boost::fusion::operator >(const boost::fusion::sequence_base<Seq1> &,const Seq2 &)' : could not deduce template argument for 'const boost::fusion::sequence_base<Sequence> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(39) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'bool boost::fusion::operator >(const boost::fusion::sequence_base<Seq1> &,const boost::fusion::sequence_base<Seq2> &)' : could not deduce template argument for 'const boost::fusion::sequence_base<Sequence> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(26) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2676: binary '>' : 'const boost::add_const<T>::type' does not define this operator or a conversion to a type acceptable to the predefined operator with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'disable_if<boost::fusion::is_sequence<Seq1>,bool>::type boost::fusion::operator >(const Seq1 &,const boost::fusion::sequence_base<Seq2> &)' : could not deduce template argument for 'const boost::fusion::sequence_base<T2> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(46) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(56) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less_detail::call<boost::fusion::detail::sequence_less<Seq1,Seq2>,I1,I2>(const T &,const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison2,strict_comparison1>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison2,strict_comparison1>>::type, T=boost::fusion::detail::sequence_less<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>,const boost::fusion::tuple2<strict_comparison2,strict_comparison1>> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(41) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less<Seq1,Seq2>::call<I1,I2>(const I1 &,const I2 &,boost::mpl::false_)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison2,strict_comparison1>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison2,strict_comparison1>>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\less.hpp(32) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less<Seq1,Seq2>::call<boost::fusion::meta::begin<Sequence>::type,boost::fusion::meta::begin<const boost::fusion::tuple2<T0,T1>>::type>(const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Seq2=const boost::fusion::tuple2<strict_comparison2,strict_comparison1>, Sequence=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, T0=strict_comparison2, T1=strict_comparison1, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison2,strict_comparison1>>::type ] c:\data\boost\develop\boost\libs\tr1\test\test_tuple_tricky.cpp(110) : see reference to function template instantiation 'bool boost::fusion::operator <<boost::fusion::tuple2<T0,T1>,boost::fusion::tuple2<strict_comparison2,strict_comparison1>>(const boost::fusion::sequence_base<Sequence> &,const boost::fusion::sequence_base<boost::fusion::tuple2<strict_comparison2,strict_comparison1>> &)' being compiled with [ T0=strict_comparison1, T1=strict_comparison2, Sequence=boost::fusion::tuple2<strict_comparison1,strict_comparison2> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'disable_if<boost::fusion::is_sequence<Seq2>,bool>::type boost::fusion::operator >(const boost::fusion::sequence_base<Seq1> &,const Seq2 &)' : could not deduce template argument for 'const boost::fusion::sequence_base<Sequence> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison2,strict_comparison1>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(39) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'bool boost::fusion::operator >(const boost::fusion::sequence_base<Seq1> &,const boost::fusion::sequence_base<Seq2> &)' : could not deduce template argument for 'const boost::fusion::sequence_base<Sequence> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison2,strict_comparison1>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(26) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2676: binary '>' : 'const boost::add_const<T>::type' does not define this operator or a conversion to a type acceptable to the predefined operator with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison2,strict_comparison1>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'disable_if<boost::fusion::is_sequence<Seq1>,bool>::type boost::fusion::operator >(const Seq1 &,const boost::fusion::sequence_base<Seq2> &)' : could not deduce template argument for 'const boost::fusion::sequence_base<T2> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison2,strict_comparison1>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(46) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(56) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less_detail::call<boost::fusion::detail::sequence_less<Seq1,Seq2>,I1,I2>(const T &,const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison2,strict_comparison1>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison2,strict_comparison1>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type, T=boost::fusion::detail::sequence_less<const boost::fusion::tuple2<strict_comparison2,strict_comparison1>,const boost::fusion::tuple2<strict_comparison1,strict_comparison2>> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(41) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less<Seq1,Seq2>::call<I1,I2>(const I1 &,const I2 &,boost::mpl::false_)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison2,strict_comparison1>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison2,strict_comparison1>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\less.hpp(32) : see reference to function template instantiation 'bool boost::fusion::detail::sequence_less<Seq1,Seq2>::call<boost::fusion::meta::begin<Sequence>::type,boost::fusion::meta::begin<const boost::fusion::tuple2<T0,T1>>::type>(const I1 &,const I2 &)' being compiled with [ Seq1=const boost::fusion::tuple2<strict_comparison2,strict_comparison1>, Seq2=const boost::fusion::tuple2<strict_comparison1,strict_comparison2>, Sequence=const boost::fusion::tuple2<strict_comparison2,strict_comparison1>, T0=strict_comparison1, T1=strict_comparison2, I1=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison2,strict_comparison1>>::type, I2=boost::fusion::meta::begin<const boost::fusion::tuple2<strict_comparison1,strict_comparison2>>::type ] c:\data\boost\develop\boost\libs\tr1\test\test_tuple_tricky.cpp(116) : see reference to function template instantiation 'bool boost::fusion::operator <<boost::fusion::tuple2<T0,T1>,boost::fusion::tuple2<strict_comparison1,strict_comparison2>>(const boost::fusion::sequence_base<Sequence> &,const boost::fusion::sequence_base<boost::fusion::tuple2<strict_comparison1,strict_comparison2>> &)' being compiled with [ T0=strict_comparison2, T1=strict_comparison1, Sequence=boost::fusion::tuple2<strict_comparison2,strict_comparison1> ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'disable_if<boost::fusion::is_sequence<Seq2>,bool>::type boost::fusion::operator >(const boost::fusion::sequence_base<Seq1> &,const Seq2 &)' : could not deduce template argument for 'const boost::fusion::sequence_base<Sequence> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(39) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2784: 'bool boost::fusion::operator >(const boost::fusion::sequence_base<Seq1> &,const boost::fusion::sequence_base<Seq2> &)' : could not deduce template argument for 'const boost::fusion::sequence_base<Sequence> &' from 'const boost::add_const<T>::type' with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ] c:\data\boost\develop\boost\boost\spirit\fusion\sequence\greater.hpp(26) : see declaration of 'boost::fusion::operator`>'' c:\data\boost\develop\boost\boost\spirit\fusion\sequence\detail\sequence_less.hpp(25) : error C2676: binary '>' : 'const boost::add_const<T>::type' does not define this operator or a conversion to a type acceptable to the predefined operator with [ T=boost::mpl::v_at<boost::fusion::tuple_data2<strict_comparison1,strict_comparison2>::types,0>::type ]

--- John Maddock <john@johnmaddock.co.uk> wrote:
There are still lots of issue with the comparison operators:
The first error occurs in the < comparison, which ends up calling operator > in sequence_less.hpp:
namespace sequence_less_detail { template <typename T,typename I1, typename I2> bool call(T const& self,I1 const& a, I2 const& b) { return *a < *b || !(*b > *a) && T::call(fusion::next(a), fusion::next(b)); } }
The thing is that's not a "less than" relation to begin with!
Yes, embarrasing typo, now corrected. It passed the previous comparison tests. I extended the tests quite a bit, defect failed tests before being fixed, passes after fix.
It's called from sequence_less::call which constructs a comparison object of type equal_to, which looks rather suspicious to me!
No problem here. The equal_to usage is to compare iterators over the sequences being compared, to established the loop termination point.
I'm attaching the error messages below, but I think you're going to have to work with the test cases I sent you, *and* devise some runtime tests to ensure that these operators actually do what they're supposed to.
As mentioned above, I've extended the runtime tests to avoid this sort of typo creeping through again. I also copied the files that you sent to Joel into boost/tr1 and libs/tr1/test. I then ran all the tests with bjam -sTOOLS=gcc. Amongst the mass of messages, it seemed that tuple_test compiled, with some warnings about unused variables. I believe this is a compile time test, so this constitutes success? I hope this is how the tests were supposed to be run, if not just give me some pointers.
Thanks for persuing this,
John.
No problem, sorry about the dodgy first attempt. Cheers Dan ___________________________________________________________ WIN ONE OF THREE YAHOO! VESPAS - Enter now! - http://uk.cars.yahoo.com/features/competitions/vespa.html

As mentioned above, I've extended the runtime tests to avoid this sort of typo creeping through again. I also copied the files that you sent to Joel into boost/tr1 and libs/tr1/test. I then ran all the tests with bjam -sTOOLS=gcc. Amongst the mass of messages, it seemed that tuple_test compiled, with some warnings about unused variables. I believe this is a compile time test, so this constitutes success? I hope this is how the tests were supposed to be run, if not just give me some pointers.
Looks OK now: there are two tuple test cases in TR1, so: bjam test_tuple test_tuple_tricky builds the tests, and yes they both build Ok now, and yes they're just compile-time conceptual tests. Thanks, John.

John Maddock wrote:
As mentioned above, I've extended the runtime tests to avoid this sort of typo creeping through again. I also copied the files that you sent to Joel into boost/tr1 and libs/tr1/test. I then ran all the tests with bjam -sTOOLS=gcc. Amongst the mass of messages, it seemed that tuple_test compiled, with some warnings about unused variables. I believe this is a compile time test, so this constitutes success? I hope this is how the tests were supposed to be run, if not just give me some pointers.
Looks OK now: there are two tuple test cases in TR1, so:
bjam test_tuple test_tuple_tricky
builds the tests, and yes they both build Ok now, and yes they're just compile-time conceptual tests.
Nice! I'd like to take this opportunity to thank Dan Masden. Dan, you rock! Thanks! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Jaakko Jarvi <jarvi@cs.tamu.edu> writes:
= between the elements etc. So I think == and < should stay as they are now, but
The specification of tuples was changed in the committee from the original proposal along the way. In particular, comparison operators were changed and the implementation in Fusion reflects the old specs. According to the old implementation, each operator only relied on the same elementwise operator. E.g. != was defined in terms of != between the elements, >= only used the definition of !=, <=, >= and > should be changed to be defined in terms of == and < for tuples.
Shouldn't that be std::less instead of < ? I'm thinking of tuples of pointers, naturally. -- Dave Abrahams Boost Consulting www.boost-consulting.com

John Maddock wrote:
I've tried converting the TR1 lib to use that implementation but I'm having trouble with the std::pair interface which appears not to work:
Pardon the self-interest, but how does this cope with the less-conforming compilers, such as Borland? Will we need to retain the original tuple implementation to support a TR1-like implementation? Can they cope with fusion? Or are there too few die-hards like me left to be worth caring about? ;?) -- AlisdairM

Alisdair Meredith wrote:
John Maddock wrote:
I've tried converting the TR1 lib to use that implementation but I'm having trouble with the std::pair interface which appears not to work:
Pardon the self-interest, but how does this cope with the less-conforming compilers, such as Borland?
Will we need to retain the original tuple implementation to support a TR1-like implementation? Can they cope with fusion? Or are there too few die-hards like me left to be worth caring about? ;?)
A question for you Borland die-hards is what's up with the state of the compiler? Has it stagnated or are new developments going? I remember applying to be a Borland beta tester some years ago but it fell on deaf ears, and I never looked back again. It seems that they don't care. So why should we care? Don't get me wrong. I used to have a loyalty towards it. I learned my first Pascal program with their original compiler. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman wrote:
A question for you Borland die-hards is what's up with the state of the compiler? Has it stagnated or are new developments going? I remember applying to be a Borland beta tester some years ago but it fell on deaf ears, and I never looked back again. It seems that they don't care. So why should we care? Don't get me wrong. I used to have a loyalty towards it. I learned my first Pascal program with their original compiler.
Borland seem to have been confused trying to support a new ISO conforming compiler with an EDG front-end (released as a preview) as a new product for new customers, and maintaining their old compiler with its GUI extensions and known problems for existing customers. It seems every time they came close to shipping a product, corporate strategy moved, everyone dropped ship and moved into the other direction again :?( A new compiler is finally promised before the end of the year, so hopefully in the next 4 weeks! This will be built on the BCB6 toolchain though, not the EDG preview. I am hoping there will be progress (not least because we have a large codebase that relies on those GUI extensions, that always proves too expensive to port) but suspect it will continue to be a burden on anyone supporting that compiler in their libraries for some time to come. The Borland field test process is a closely guarded secret so I have no idea what it actually takes to get on board. If you are still interested in testing (or any other regular Boosters for that matter) I will rattle a cage or two to see if Borland will invite you onto the next FT, whenever that is. They say Boost compatibility is an important issue for them, especially as we customers keep telling them it is a concern for us! Back on topic, TR1 is an important library, and I would really like my production compiler to come as close to supporting it as possible. I am equally fed up reading through boost source with a large number of workarounds to support it. I would be very happy with an alternate implementation (such as existing tuple) that did not pollute new code, was not entirely conforming, and continued to be supported by the Borland community - much as Spirit 1.6 remains for legacy support. I guess I am trying to push more work on John, who already has his hands full trying to play header tricks already! -- AlisdairM

I've tried converting the TR1 lib to use that implementation but I'm having trouble with the std::pair interface which appears not to work:
Pardon the self-interest, but how does this cope with the less-conforming compilers, such as Borland?
At present it doesn't cope at all. I don't know whether it can be made to, Joel?
Will we need to retain the original tuple implementation to support a TR1-like implementation? Can they cope with fusion? Or are there too few die-hards like me left to be worth caring about? ;?)
I guess if the existing tuple implementation sticks around, it would be trivial for TR1 to use that for older compilers - of course the old implementation isn't TR1 conforming though :-( John.

On Sun, Nov 20, 2005 at 08:41:57AM +0800, Joel de Guzman <joel@boost-consulting.com> wrote:
John Maddock wrote:
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just finished Fusion-2. The code is done :) We're working on the docs. I'd like to ask for a formal review. Is it possible to ask for a review on a promise that the docs will be finished when the review starts? Just so as to get it in the review queue?
This might be a bit too early, since you still work on the documentation but a short peek into http://spirit.sourceforge.net/dl_more/fusion_v2/boost/fusion/ unveiled that now set and map type containers are integrated into fusion. So I really could not resist. Is the code in that directory current? I really like the code separation, that moves compile type or type oriented functions in the fusion::meta namespace, and the runtime part with the same names in the fusion namespace. Right now I am looking at the deref code in: http://spirit.sourceforge.net/dl_more/fusion_v2/boost/fusion/iterator/deref.... I somehow expected to see some traces of references. After some browsing I noticed that list and vector have a special deref_impl, which seems to add references to the value types. So iterators from the map container will use that partial specializations, because map uses the vector type container? Regards Andreas Pokorny

Andreas Pokorny wrote:
On Sun, Nov 20, 2005 at 08:41:57AM +0800, Joel de Guzman <joel@boost-consulting.com> wrote:
John Maddock wrote:
Is there any progress on a TR1 conforming tuples implementation? I seem to remember it was going to be rewritten as part of the Phoenix code?
Fusion. The fusion code in the spirit directory *is-a* conforming tuple implementation. It's been there since 1.31. We've just finished Fusion-2. The code is done :) We're working on the docs. I'd like to ask for a formal review. Is it possible to ask for a review on a promise that the docs will be finished when the review starts? Just so as to get it in the review queue?
Hi Andreas, Pardon the delay, I almost missed this post.
This might be a bit too early, since you still work on the documentation but a short peek into http://spirit.sourceforge.net/dl_more/fusion_v2/boost/fusion/ unveiled that now set and map type containers are integrated into fusion. So I really could not resist. Is the code in that directory current?
I am not sure. I update it every once in a while. If you want the latest, you can always get it from the Spirit CVS in the branch FUSION_V2.
I really like the code separation, that moves compile type or type oriented functions in the fusion::meta namespace, and the runtime part with the same names in the fusion namespace.
Thanks!
Right now I am looking at the deref code in: http://spirit.sourceforge.net/dl_more/fusion_v2/boost/fusion/iterator/deref.... I somehow expected to see some traces of references. After some browsing I noticed that list and vector have a special deref_impl, which seems to add references to the value types. So iterators from the map container will use that partial specializations, because map uses the vector type container?
It's not a partial specialization, is it? Anyway, details aside, yes, map and set are using the vector as their implementation and yes, they both tag dispatch to the proper deref_impl of the vector. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

On Fri, Nov 25, 2005 at 08:46:42AM +0800, Joel de Guzman <joel@boost-consulting.com> wrote:
I am not sure. I update it every once in a while. If you want the latest, you can always get it from the Spirit CVS in the branch FUSION_V2.
I failed to find there, using ViewCVS on sf.net. I did not want to checkout the full repository. Could you tell me where to look? There are several questions about handling the map container in my mind, I wonder where to ask them. Is the spirit-ml the right place? Regards, Andreas Pokorny

Andreas Pokorny wrote:
On Fri, Nov 25, 2005 at 08:46:42AM +0800, Joel de Guzman <joel@boost-consulting.com> wrote:
I am not sure. I update it every once in a while. If you want the latest, you can always get it from the Spirit CVS in the branch FUSION_V2.
I failed to find there, using ViewCVS on sf.net. I did not want to checkout the full repository. Could you tell me where to look?
Ok, I uploaded the latest WIP snapshot at http://spirit.sourceforge.net/dl_more/fusion_v2/boost/fusion/ http://spirit.sourceforge.net/dl_more/fusion_v2.zip The code is more or less stable. You'll notice some docs in the making.
There are several questions about handling the map container in my mind, I wonder where to ask them. Is the spirit-ml the right place?
Here or the Spirit list is ok. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (11)
-
Alisdair Meredith
-
AlisdairM
-
Andreas Pokorny
-
dan marsden
-
David Abrahams
-
Jaakko Jarvi
-
Jeff Garland
-
Joel de Guzman
-
John Maddock
-
Pavel Vozenilek
-
Ronald Garcia