Re: [boost] Re: New iterator adaptors and bjam builds
Beman Dawes <[EMAIL PROTECTED]> wrote: > At 01:27 PM 7/11/2003, David Abrahams wrote: > >Jens Maurer <[EMAIL PROTECTED]> writes: > There seem to be a number of files in boost-root/libs/utility that are > holdovers from the prior version of iterator adaptors. I'll fix this situation. > Is the plan to remove all iterator related files from > boost-root/libs/utility and replace them with files in > boost-root/libs/iterator (or its sub-directories)? Yes. That's the plan, AFAIK. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
At 01:27 PM 7/11/2003, David Abrahams wrote: >Jens Maurer <[EMAIL PROTECTED]> writes: > >> The following libraries are now broken and should be fixed: >> - filesystem >> - graph >> - multi_array >> - random_demo >> - signals >> - tokenizer >> - utility > >What problems are you having with the utility lib? I don't see any. There seem to be a number of files in boost-root/libs/utility that are holdovers from the prior version of iterator adaptors. Is the plan to remove all iterator related files from boost-root/libs/utility and replace them with files in boost-root/libs/iterator (or its sub-directories)? --Beman PS: I just read the proposal carefully, and it seems quite nice. Seems more understandable than the old version, too. The one thing I'm missing is a really simple iterator_facade example so I can verify that my understanding is correct. Hopefully such an example will come as the docs mature. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
David Abrahams <[EMAIL PROTECTED]> wrote: > Jens Maurer <[EMAIL PROTECTED]> writes: >> May I suggest that you remove (for example) >>(ALL_LOCATE_TARGET)/status/bin/transform_iterator_example.test > > No wonder! That's not the utility suite; that's the iterator_adaptors > suite. Mostly an easy fix. There are already replacement tests in > libs/iterator/test. Yep, I'll remove these artifacts. Pardon the confusion. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
David Abrahams wrote: > That's really odd. > > Everything works perfectly on my machine with gcc-3.2 and CWPro8.3 > except for a numeric_traits_test failure with gcc-3.2 and that has no > relation to iterator_adaptors. I can't believe it. Very strange. I've just removed libs/utility and re-"cvs update"d it. I'm reading (for example) libs/utility/transform_iterator_example.cpp which contains: typedef boost::transform_iterator_generator::type doubling_iterator; And this is gone for good, I thought. So this should fail the compile. If it doesn't, for you, then either the XML post-processing is doing something wrong, or the dependency checking of bjam isn't doing its job. May I suggest that you remove (for example) (ALL_LOCATE_TARGET)/status/bin/transform_iterator_example.test and try re-running the regression tests? If this shows a different result, you may want to clean ALL_LOCATE_TARGET completely. :-) Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
David Abrahams wrote: > In what sense? If a C++ source file includes a header (even > indirectly) and the header changes, the source file should be > recompiled. No recompilation is neccessary just because an > application links to a built library whose sources include a header > file that changed. That's right, I was misled by the fact that boost/iterator/* was checked in on Monday, but I started to see regression test failures only yesterday. Further investigation showed that libraries include boost/iterator_adaptors.hpp, and that file was changed to use boost/iterator/* only yesterday. Sorry for the confusion. Jens Maurer ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: New Iterator Adaptors
David Abrahams wrote: > > Done. > > What's done? Sorry, seems, that I've stripped of from my mail all of the useful information :-) I've added a new file boost/iterator_adaptors.hpp to the boost-sandbox CVS, which contains nothing more, than #define BOOST_ITERATOR_ADAPTORS_VERSION 0x0200 #include as we've discussed it recently. Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: New Iterator Adaptors
David Abrahams wrote: > > What about re-introducing the boost/iterator_adaptors.hpp file: > > > > #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 > > #include > > > > This would allow for some version tracking and a smooth > migration path > > for those libraries, willing to support both, the new _and_ the old > > iterator libs. Thought's? > > OK, that seems reasonable. Libraries can check to see if > BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different > code in that case. Done. Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New Iterator Adaptors
On Wed, 11 Jun 2003, David Abrahams wrote: > [EMAIL PROTECTED] (Hartmut Kaiser) writes: > > What about re-introducing the boost/iterator_adaptors.hpp file: > > > > #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 > > #include > > > > This would allow for some version tracking and a smooth migration path > > for those libraries, willing to support both, the new _and_ the old > > iterator libs. Thought's? > > OK, that seems reasonable. Libraries can check to see if > BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different code in > that case. Can't we just use BOOST_VERSION? (1.31.0 will have the new iterator adaptors anyway) Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: New Iterator Adaptors
David Abrahams wrote: > > Hmmm... You're removed the boost/iterator_adaptors.hpp file > > intentionally, right? This makes it even more problematic, because, > > there is no chance to circumvent compilation errors. > > There are going to be compilation errors anyway, since the > interface is drastically different. Sure, but I said, that without boost/iterator_adaptors.hpp there is no way to circumvent them. > > What about re-introducing the boost/iterator_adaptors.hpp file: > > > > #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 > > #include > > > > This would allow for some version tracking and a smooth > migration path > > for those libraries, willing to support both, the new _and_ the old > > iterator libs. Thought's? > > OK, that seems reasonable. Libraries can check to see if > BOOST_ITERATOR_ADAPTOR_VERSION is defined and use different > code in that case. Fine, looking forward. Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: New Iterator Adaptors
David Abrahams wrote: > > As a last resort this certainly helps. And in a year or so > nobody will > > talk about the transitional CVS versions. But now it would be very > > helpful, if there was a separate BOOST_ITERATOR_ADAPTOR_VERSION pp > > constant, which could be used for this needs (BTW Spirit has such a > > constant from the early beginnings). Please don't get me > wrong, I do > > not want to have a very fine granulated version tracking > constant. My > > point is, that such interface breaking changes _must_ be track-able. > > Well, here are the problems: > > 1. There's no definition of this macro in the current sources > > 2. The new iterator adaptors don't use the same file paths, >e.g. boost/iterator/iterator_adaptor.hpp vs >boost/iterator_adaptors.hpp. > > I'm certainly open to any concrete solutions to this problem. > Just tell me how to do it. Hmmm... You're removed the boost/iterator_adaptors.hpp file intentionally, right? This makes it even more problematic, because, there is no chance to circumvent compilation errors. What about re-introducing the boost/iterator_adaptors.hpp file: #define BOOST_ITERATOR_ADAPTOR_VERSION 0x2000 #include This would allow for some version tracking and a smooth migration path for those libraries, willing to support both, the new _and_ the old iterator libs. Thought's? Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: New Iterator Adaptors
David Abrahams wrote: > > Is there any way to tell, which version of the iterator library is > > installed on a target system? I could think of some pp > constant, which > > allows to configure a piece of code to use the 'old' or the 'new' > > iterator lib. This would allow for a smooth transition of existing > > libraries depending on the iterator_lib and looses the > otherwise tight > > coupling between some user code and a specific Boost version. > > Cute idea. Unless you want to account for all the > transitional versions in CVS, you could always > > #include > > and check BOOST_VERSION As a last resort this certainly helps. And in a year or so nobody will talk about the transitional CVS versions. But now it would be very helpful, if there was a separate BOOST_ITERATOR_ADAPTOR_VERSION pp constant, which could be used for this needs (BTW Spirit has such a constant from the early beginnings). Please don't get me wrong, I do not want to have a very fine granulated version tracking constant. My point is, that such interface breaking changes _must_ be track-able. Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New Iterator Adaptors
On Sun, May 11, 2003 at 01:47:00PM -0400, David Abrahams wrote: > > I have a suggestion for another "orthogonal" feature of iterators, which is > > available for plain pointers : NULL. More precisely, the fact that the > > default initialized iterator is a unique (singular) value which you can > > reliably test equality with. > > > > It is very useful to have this capability : in the CGAL library, we store > > the nodes of a graph in containers. Graphs are a bunch of nodes storing > > pointers/iterators to each other. Having a value like NULL is very useful > > there, because the alternative is either to allocate a specific object > > whose iterator you use for this purpose (but it requires access to the > > associated container to test with, which is painful), or storing a bool, > > which is a waste of memory. > > > > I don't know if these issues arise in the BGL as well. > > > > I think this feature doesn't make sense for all iterators, especially for > > Input and Output iterators. However, for iterators connected with > > containers, they are usually trivial to provide because the iterator > > usually stores a pointer, which can then be default initialized to NULL. > > > > In the case of CGAL, it would simply allow us to re-use the standard > > containers for storing our graphs, while right now we re-implement > > containers... > > What, specifically, would allow you to re-use the standard > containers? I'm looking for a statement along the lines of, "if ... > then we could re-use the standard containers". > > I'm guessing "..." is something like, "if default-constructed standard > container iterators were non-singular and guaranteed to be unequal to > any iterator obtained by other means". That would be something more like "if default-constructed standard container iterators were non-singular and guaranteed to be unequal to any iterator obtained by other means, and compare equal to any default-constructed iterator." I.e. the default constructed value must be unique (as far as operator== is concerned). > > Another feature (less important but connected to the previous one) that > > pointers have and iterators don't : automatic conversion to bool. > > > > What do you think ? > > It sounds like a useful concept, if I've understood you correctly. > > At the same time, I doubt it belongs in our proposal: we don't say > anything about containers (except vector, and then only in the > rationale). You should write a proposal for extension and submit it > to the commitee if you care about this. It should be easy, compared > to the iterator adaptors/categories proposal. OK. I'll think about writing something. -- Sylvain ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New Iterator Adaptors
"Gustavo Guerra" <[EMAIL PROTECTED]> writes: > The diagrams are missing Fixed now, thanks. >> http://boost-consulting.com/writing/facade-and-adaptor.html >> http://boost-consulting.com/writing/new-iter-concepts.html -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
