- Boost - lists.boost.org

Liohyjdxevcm
by jewillco＠osl.iu.edu 02 Feb '04

02 Feb '04

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.

1 0

Re: problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 02 Feb '04

02 Feb '04

Dave Abrahams wrote: >Robert Ramey wrote: >> it seems to me that it is implemented for non - random access >> iterators by incrementing one iterator until it equals the other and >> return the number of times the increment occured. >Yeah, it's a mistake. It shouldn't use distance, but operator-. >That way neither one of your subtractions would compile. >From the documentation: counting_iterator requirements The Incrementable argument shall be Copy Constructible and Assignable. If iterator_category is convertible to forward_iterator_tag or forward_traversal_tag, the following must be well-formed: Incrementable i, j; ++i; // pre-increment i == j; // operator equal Suppose I had used a different iterator as a base - not an input iterartor but some kind of forward transveral iterator. Would that have been ok? Now if I understand correctly? the only difference between the single pass transveral and forward transversal is the ability to "rewind". As far as I can see the ability doesn't affect the requirement stated above. Are sure that the requirement isn't too strong. The fact that it "accidently" works seems to suggest this. from the nomenclature, example, other "counting iterators", and common sense, I would expect an example such as the one I presented to function as I expected. And in fact it did in the previous release candidate. That is, its natural to expect the following to function std::fstream is; std::input_iterator begin(is), end(); int filesize = end - begin; Can the design and implement (of off course document) be adjusted to permit this? If such a seemingly natural usage is not possible, it should be trapped at compile time (as you suggested) and the reason why it can't be supported described in the documentation. Robert Ramey

2 1

Re: problem with new iterators in 1.31 Release Candidate # 2 (repost)
by Robert Ramey 01 Feb '04

01 Feb '04

I didn't get the formating correct on this so I want to repost it so it makes more sense. >David Abrahams wrote: >>Robert Ramey <ramey(a)rrsd.com> writes: >> I have a problem with the latest version of the new iterators. >> This is illustrated in the following example. >> >> #include <strstream> >> #include <iterator> >> #include <boost/iterator/counting_iterator.hpp> >> >> main(){ >> std::istrstream is("abcdefg"); >> typedef boost::counting_iterator<std::istream_iterator<char> > ci; >> const ci end = std::istream_iterator<char>(); // note the const !!! >I don't see why the const should be relevant. >From looking at the code for counting iterator it seems to me that it is implemented for non - random access iterators by incrementing one iterator until it equals the other and return the number of times the increment occured. (I concede that I've had difficulty following the implementation so I could be wrong). So if one of the iterators is const - that one can't be the one that's incremented. >> ci begin = std::istream_iterator<char>(is); >Hmm, the implicit conversions from istream_iterator to the >counting_iterator above are troubling. I think those constructors >should be explicit. Hmmm - From looking at the documentation and the code, I get absolutly no indication that the counting iterator requires a random access iterator. In fact, looking at the code suggests that there is code especially included to handle any forward transversal iterators. And the first invocation below DOES work - I can't believe that's an accident. >> unsigned int size; >> >> // the following should fail at compilation ? >Why? OK, maybe it would be better to make it fail because the >iterator is not in fact a random-access iterator. > // in fact it compiles are returns a value of -7 !!! > size = begin - end; > > // the following should compile and return a value of 7 > // in fact, it compiles but goes into an infinite loop > size = end - begin; > } My mistake - I wrongly presumed that only the second iterator would be incremented and since its const it should fail. It looks like the code intends to select which iterator to increment depending on const. So this first case looks ok to me now. >I don't see why you think the first should compile but the second >should not. If they're not random-access iterators, it seems to me >that there's no reason you should be able to subtract them in any >order. If they were random-access iterators, it would be unreasonable >to expect the compiler to detect which one had an earlier position >and disallow one subtraction. So my position is that both compile (as they should). The first works as one would expect while the second results in an infinite loop. I'm sorry but I don't see how this can be correct. >> Note that this problem did not appear with the first release candidate. > >> Also, if one follows the links from the main documentation page, one >> is directed to the documentation of the old iterators. This is >> extremely confusing. This has been pointed out before. >That's a serious problem which I'll fix immediately. Robert Ramey

1 0

[config] BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC
by Gennaro Prota 01 Feb '04

01 Feb '04

A while ago I pointed out that BOOST_EXPLICIT_TEMPLATE_TYPE_SPEC and its three variations (in config/suffix.hpp) are useless for VC6 (the only compiler, IIRC, for which the non-_SPEC versions were introduced). http://article.gmane.org/gmane.comp.lib.boost.devel/23486/ I thought they had been removed but I see that they are still there. There's one usage, in variant/detail/forced_return.hpp. Is it really needed? Why? Genny.

1 0

Re: problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 01 Feb '04

01 Feb '04

Robert Ramey <ramey(a)rrsd.com> writes: > I have a problem with the latest version of the new iterators. > This is illustrated in the following example. > > #include <strstream> > #include <iterator> > #include <boost/iterator/counting_iterator.hpp> > > main(){ > std::istrstream is("abcdefg"); > typedef boost::counting_iterator<std::istream_iterator<char> > ci; > const ci end = std::istream_iterator<char>(); // note the const !!! I don't see why the const should be relevant. >From looking at the code for counting iterator it seems to me that it is implemented for non - random access iterators by incrementing one iterator until it equals the other and return the number of times the increment occured. (I concede that I've had difficulty following the implementation so I could be wrong). So if one of the iterators is const - that one can't be the one that's incremented. > ci begin = std::istream_iterator<char>(is); Hmm, the implicit conversions from istream_iterator to the counting_iterator above are troubling. I think those constructors should be explicit. Hmmm - From looking at the documentation and the code, I get absolutly no indication that the counting iterator requires a randome access iterator. In fact, looking at the code suggests that there is code especially included to handle any forward transversal iterators. And the first invocation below DOES work - I can't believe that's an accident. > unsigned int size; > > // the following should fail at compilation ? Why? OK, maybe it would be better to make it fail because the iterator is not in fact a random-access iterator. > // in fact it compiles are returns a value of -7 !!! > size = begin - end; > > // the following should compile and return a value of 7 > // in fact, it compiles but goes into an infinite loop > size = end - begin; > } My mistake - I wrongly presumed that only the second iterator would be incremented and since its const it should fail. It looks like the code intends to select which iterator to increment depending on const. So this first case looks ok to me now. I don't see why you think the first should compile but the second should not. If they're not random-access iterators, it seems to me that there's no reason you should be able to subtract them in any order. If they were random-access iterators, it would be unreasonable to expect the compiler to detect which one had an earlier position and disallow one subtraction. So my position is that both compile (as they should). The first works as one would expect while the second results in an infinite loop. I'm sorry but I don't see how this can be correct. > Note that this problem did not appear with the first release > candidate. > > Also, if one follows the links from the main documentation page, one > is directed to the documentation of the old iterators. This is > extremely confusing. This has been pointed out before. That's a serious problem which I'll fix immediately. Robert Ramey

2 1

mpl lambda question
by Eyal Farago 01 Feb '04

01 Feb '04

hi, I'm trying to use mpl lambda on vc.6.5, it seems that for some reason when applying lambda on the expression the compiler tries to instantiate the wrong specialisation(the one with the boost::mpl::arg<1> as a template parameter. this is the test program: #include <boost/mpl/lambda.hpp> #include <boost/tuple/tuple.hpp> template< class T_ > struct head_type { typedef typename T_::head_type type; BOOST_MPL_AUX_LAMBDA_SUPPORT( 1, head_type, ( T_ ) ); }; void main() { typedef boost::tuples::tuple< int > int_tuple_t; typedef head_type< int_tuple_t >::type head_of_int_tuple_t; typedef head_type< boost::mpl::_1 > exp_t; typedef boost::mpl::lambda< exp_t >::type exp_lambda_t; //this line causes the compilation error typedef boost::mpl::apply1< exp_lambda_t, int_tuple_t >::type int_tuple_head_type; } and this is the compiler's output: --------------------Configuration: boost_tests - Win32 Debug-------------------- Compiling... main.cpp C:\c++\boost_tests\main.cpp(7) : error C2039: 'head_type' : is not a member of 'arg<1>' c:\c++\boost_1_30_0\boost\mpl\aux_\preprocessed\msvc60\arg.hpp(28) : see declaration of 'arg<1>' c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(64) : see reference to class template instantiation 'head_type<struct boost::mpl::arg<1> >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(80) : see reference to class template instantiation 'boost::detail::does_conversion_exist<struct head_type<struct boost::mpl::arg<1> > &>::result_<struct boost::detail::int_convertible >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(184) : see reference to class template instantiation 'boost::detail::is_convertible_basic_impl<struct head_type<struct boost::mpl::arg<1> > &,struct boost::detail::int_convertible>' be ing compiled c:\c++\boost_1_30_0\boost\type_traits\is_convertible.hpp(239) : see reference to class template instantiation 'boost::detail::is_convertible_impl<struct head_type<struct boost::mpl::arg<1> > &,struct boost::detail::int_convertible>' being co mpiled c:\c++\boost_1_30_0\boost\type_traits\is_enum.hpp(54) : see reference to class template instantiation 'boost::is_convertible<struct head_type<struct boost::mpl::arg<1> > &,struct boost::detail::int_convertible>' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_enum.hpp(91) : see reference to class template instantiation 'boost::detail::is_enum_helper<0>::type<struct head_type<struct boost::mpl::arg<1> > &>' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_enum.hpp(108) : see reference to class template instantiation 'boost::detail::is_enum_impl<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_scalar.hpp(30) : see reference to class template instantiation 'boost::is_enum<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_scalar.hpp(50) : see reference to class template instantiation 'boost::detail::is_scalar_impl<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_class.hpp(78) : see reference to class template instantiation 'boost::is_scalar<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\type_traits\is_class.hpp(93) : see reference to class template instantiation 'boost::detail::is_class_impl<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\mpl\aux_\has_rebind.hpp(32) : see reference to class template instantiation 'boost::is_class<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\mpl\aux_\preprocessed\msvc60\template_arity.hpp(27) : see reference to class template instantiation 'boost::mpl::aux::has_rebind<struct head_type<struct boost::mpl::arg<1> > >' being compiled c:\c++\boost_1_30_0\boost\mpl\aux_\preprocessed\msvc60\lambda_no_ctps.hpp(150) : see reference to class template instantiation 'boost::mpl::aux::template_arity<struct head_type<struct boost::mpl::arg<1> > >' being compiled C:\c++\boost_tests\main.cpp(17) : see reference to class template instantiation 'boost::mpl::lambda<struct head_type<struct boost::mpl::arg<1> >,1>' being compiled Error executing cl.exe. boost_tests.exe - 1 error(s), 0 warning(s) eyal.

2 1

ICE with is_abstract on VC 7.0
by Robert Ramey 01 Feb '04

01 Feb '04

When I compile anything that includes is_abstract.hpp I get a compiler ICE with VC 7.0 since is_abstract.hpp is included by type_traits.hpp it means that a large part of boost 1.31 release candidate 2 is now uncompilable on this platform. is_abstract was known to test the limits of many platforms. It is incredible to me that this could be dropped into "release candidate # 2" without having been part of the development tree for a reasonable amount of time. When can we expect 1.31 release candidate # 3? Robert Ramey

5 6

1.31.0 Release candidate 2 available
by Beman Dawes 01 Feb '04

01 Feb '04

Release candidate 2 is available at http://www.esva.net/~beman/boost_1_31_0_rc2.zip Feedback appreciated! Boost developers should limit changes to the RC_1_31_0 branch to fixes for showstoppers. Anything less should go in the next release. --Beman

14 25

problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 31 Jan '04

31 Jan '04

I have a problem with the latest version of the new iterators. This is illustrated in the following example. #include <strstream> #include <iterator> #include <boost/iterator/counting_iterator.hpp> main(){ std::istrstream is("abcdefg"); typedef boost::counting_iterator<std::istream_iterator<char> > ci; const ci end = std::istream_iterator<char>(); // note the const !!! ci begin = std::istream_iterator<char>(is); unsigned int size; // the following should fail at compilation ? // in fact it compiles are returns a value of -7 !!! size = begin - end; // the following should compile and return a value of 7 // in fact, it compiles but goes into an infinite loop size = end - begin; } Note that this problem did not appear with the first release candidate. Also, if one follows the links from the main documentation page, one is directed to the documentation of the old iterators. This is extremely confusing. This has been pointed out before. This above example is using 1.31. "release candidate" #2 compiled with VC 7.0 Robert Ramey

2 1

Re: [boost] [filesystem] On POSIX, any reliable way to find file size?
by Beman Dawes 31 Jan '04

31 Jan '04

At 01:29 PM 1/31/2004, Christoph Ludwig wrote: >I don't know whether there is a solution within any formally defined >Unix or Posix standard. But according to >http://www.suse.de/~aj/linux_lfs.html the Linux 2.4 kernel supports >the Large File Support (LFS) interface. There is also a link to the >LFS specification: >http://ftp.sas.com/standards/large.file/x_open.20Mar96.html Thanks. I think that is a bit dated, but Jens' reply seems reflect actual practice and that should be enough to get started with. --Beman

1 0