- Boost - lists.boost.org

RE: [boost] Wave/flex_string with VC7.0 + dinkumware (new problem)
by Reece Dunn 22 May '04

22 May '04

Hartmut Kaiser wrote: >Reece Dunn wrote: > > > I reported that VC7 uses the correct implementation of > > reverse_iterator, and that this can be detected via > > BOOST_NO_STD_ITERATOR. Although this compiles, you cannot use > > reverse iterators. > > > > The problem is that the iterator is of the form (const) T *, > > and this fails because there is not a correct implementation > > of iterator_traits (due to a lack of partial template > > specialization) that *is* detected by BOOST_NO_STD_ITERATOR_TRAITS. > > > > The solution would therefore be to - in this case - provide > > an iterator wrapper around a standard pointer so it has the > > correct Iter::value_type, etc definitions. Is there an > > iterator_adaptor that provides this within boost? If not, > > should there be one? I am looking into this and will commit > > the solution to my iterator_adaptor-style implementation > > (sandbox/boost/fixed_string/detail/basic_string_impl.hpp). > > > > NOTE: If you want to add any of my modifications to the Wave > > flex_string implementation, feel free, but be warned that I > > haven't run full tests on it yet and thus there might be bugs > > in it (especially the pod_xxx --> traits_type::xxx, since > > these functions have different parameters). > >Thanks again for pointing that out. I'll have a look at it next week, when >I'm back home. Is this problem specific for VC7 or does it occur on the >VC7.1 platform also? If it's specific, then I would some need from somebody >to fix this, because I don't have it handy to reproduce the problem. Could >you provide a fix for Wave then? It is just a VC 7 problem, because VC 7 does not have partial template specialization. I have a fix now for this: replace std::reverse_iterator< Iterator > with boost::reverse_iterator< Iterator > (I do not have a proper diff): +# include <boost/iterator/reverse_iterator.hpp> // ... - typedef std::reverse_iterator<iterator -#ifdef BOOST_NO_STD_ITERATOR_TRAITS - , value_type -#endif - > reverse_iterator; + typedef boost::reverse_iterator< iterator > reverse_iterator; - typedef std::reverse_iterator<const_iterator -#ifdef BOOST_NO_STD_ITERATOR_TRAITS - , const value_type -#endif - > const_reverse_iterator; + typedef boost::reverse_iterator< const_iterator > const_reverse_iterator; I have this in my implementation if you want to take a look, along with several other changes to the flex_string implementation. Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

2 1

Re: PING: Lambda Documentation Problem
by Stephan T. Lavavej 21 May '04

21 May '04

[Jaakko Jarvi] > I'm reading the standard back and forth and I do not agree > with you. The Standard is not very well written when it comes to this point, yes. However, I am right, and in the course of this E-mail, you will be convinced that I am right. :-> > What do you mean by "inherently mutating sequences"? Algorithms which always modify the sequences that they are given. > Does std::replace inherently modidfy sequences? Yes, because its purpose is to write NewValue in every place that OldValue occurs. In contrast, for_each does not necessarily have to modify sequences, if given a functor that inspects its argument and mutates itself. However, the functor can modify the sequence. This caused me some confusion (I thought, as you do, that conforming implementations could implement for_each in such a way as to disallow functors from mutating the values, and hence that for_each was morally bankrupt) until I read something that cleared it up for me. http://www.cuj.com/documents/s=7998/cujcexp1902langer/ "the function object may produce an effect by modifying the input sequence, and it can produce a useful result by mutating itself in the course of its invocations" for_each is special, because all of the other "non-modifying sequence operations" are /really/ non-modifying. If you are still unconvinced, see Library DR 290, where Angelika Langer (coauthor of the above article) complains that there are insufficient restrictions on for_each's functor. Note that she asks that the functor be required to not invalidate iterators or subranges. The DR is still open, but note that the LWG's response so far is "we think this should be a blanket statement", not "what are you talking about, for_each's functor cannot mutate its argument period, much less invalidate iterators". Finally: http://www.research.att.com/~bs/3rd_printing5.html "pg 524 add at the end of the page: "The for_each() algorithm is classified as nonmodifying because it doesn't explicitly modify a sequence. However, if applied to a non-const sequence for_each() may change the elements of the sequence. For an example, see the use of negate() in 11.9." (recent standards resolution)." If your TC++PL3 is 5th printing or higher (or if it's any printing of Special), you can look on page 524, and there it is. Spoken by the Bearded One himself. Stephan T. Lavavej http://nuwen.net

2 1

Newbie to Regex simple test failure...
by Richard Latter 21 May '04

21 May '04

Hello All, I'm probably missing something obivous here.....So please fogive me if it's a basic error. I am using regex for the first time on MSVC 6 and would like to create a simple function that could pass in a string and an expression to do a regular match on it. I believe I have successfully compiled this library, but I don't understand why either of these simple functions are not working.... bool TestStr (std::string& szExpr, const std::string& szSearch) { bool bResult=false; boost::regex cExpr(szExpr); bResult = boost::regex_match(szSearch, cExpr); return bResult; } or bool TestStr2 (std::string& szExpr, std::string& szSearch) { return boost::regex_match(szSearch, boost::regex(szExpr)); } After debugging these routines, it appears thta the boost::regex declaration fails (at least for the first function) returning a Kernel32.dll exception with some kind of address. The credit card example implies that the search and the regex example I have observed keeps the regex expressions as constansts inside the function, but I would like to be able to parse in my own string Questions? 1. Wht doesn't any of the functions work? 2. Is there a tutorial outside of the regex library I could look at. 3. I would be interested to know if anyone had any POSIX regex examples.... Many thanks in advance, Richard

4 7

bjam - building binaries in one dir
by John Torjo 21 May '04

21 May '04

Hi all, Looking at how bjam makes its great subdirs - when creating binaries for a library, I see that each libs/dlls is put in its own sub-directory. As I see, anyway, the binary name already indicates the compiler + release type + etc. And all the library linkinage is solved automatically (for instance, if I need boost_date_time-vc71-mt-gd-1_31.lib, it will automatically be added to my dependencies). I would like however for all binaries for a specific library to be built in the same dir. This way all I need to remember is the directory where the library binaries are, and include that in my 'Additional library directories'. I know that the current behavior (making subdirs) is much better for existing libraries, but I would like to create a new library, and build all binaries in the same dir. Does bjam allow this? (note: I will have four binaries per compiler) Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 3

how to get the files for review?
by Oliver Kullmann 21 May '04

21 May '04

Hi, I just subscribed, and I would like to review the three--valued-logic library. So I click "Files" at the Boost home page. As a result I'm transferred to http://login.yahoo.com/config/login?.intl=us&.src=ygrp&.done=http://groups.… where my ID is asked for?!?! I have never used Yahoo, so I don't know what to do here (given that subscribing with Boost doesn't involve some ID) ?!?! Oliver

2 1

intrusive_ptr question
by Joe Gottman 21 May '04

21 May '04

The intrusive_ptr contains two functions that allow comparisons between intrusive_ptr<T> and T *. template<class T> bool operator==(intrusive_ptr<T> const & a, T * b); template<class T> bool operator==(T * b, intrusive_ptr<T> const & b); and similar operator!=() functions. I'm curious why the pointer parameters are of type T* and not T const *. Joe Gottman

3 4

[Graph] Recently introduced vc6/7 bugs
by David Abrahams 21 May '04

21 May '04

Some new problems in the Graph library on vc6 and vc7 are breaking the Boost.Python library build. See http://tinyurl.com/2j4nj for details. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Re: [license]
by Glen Knowles 21 May '04

21 May '04

> > > > Would this be appropiate too: > > > > // Copyright 2004 Joe Coder. Distributed under the Boost // > Software > > License, Version 1.0, provided this > ^^^^^^^^^^^^^ > > // copyright notice appears in all copies. (See accompanying file > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > > > > ? > > The highlighted wording is redundant; the licence itself > already requires that. Citing the FAQ once more, > My understanding was that it might be more then merely redundant, it could be interpreted as more restrictive. Possibly requiring the copyright notice to appear in compiled object code for example. Glen

4 3

Wave/flex_string with VC7.0 + dinkumware (new problem)
by Reece Dunn 21 May '04

21 May '04

I reported that VC7 uses the correct implementation of reverse_iterator, and that this can be detected via BOOST_NO_STD_ITERATOR. Although this compiles, you cannot use reverse iterators. The problem is that the iterator is of the form (const) T *, and this fails because there is not a correct implementation of iterator_traits (due to a lack of partial template specialization) that *is* detected by BOOST_NO_STD_ITERATOR_TRAITS. The solution would therefore be to - in this case - provide an iterator wrapper around a standard pointer so it has the correct Iter::value_type, etc definitions. Is there an iterator_adaptor that provides this within boost? If not, should there be one? I am looking into this and will commit the solution to my iterator_adaptor-style implementation (sandbox/boost/fixed_string/detail/basic_string_impl.hpp). NOTE: If you want to add any of my modifications to the Wave flex_string implementation, feel free, but be warned that I haven't run full tests on it yet and thus there might be bugs in it (especially the pod_xxx --> traits_type::xxx, since these functions have different parameters). Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

iterator_adaptor.hpp and python/detail/is_xxx.hpp
by Domenico Andreoli 21 May '04

21 May '04

hi, i'm wondering whether boost/iterator/iterator_adaptor.hpp really needs to include boost/python/detail/is_xxx.hpp or not. it seems this inclusion is not required, removing it does not any harm. i'm asking this because debian packages python headers in package libboost-python-dev and itarator headers in libboost-dev. this (maybe useless) inclusion forces libboost-dev to depend on libboost-python-dev making it useless as separate package from libboost-dev. i'd like to remove this inclusion, at least for what regards the debian packages. i'd be very glad to hear your thoughts about this story. cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

3 4