May 2005 - Boost - lists.boost.org

[1.33.0] We're moving in the right direction...
by Doug Gregor 10 May '05

10 May '05

Since the last time I sent out status information, we've cleared up about 500 failures. Way to go! Let's keep on chipping away at those failures. Doug

1 0

[sandbox cvs][fsm] Rename from fsm -> statechart pending
by Andreas Huber 10 May '05

10 May '05

FYI: A few hours ago I've submitted a request to have the fsm directories in the sandbox renamed to statechart. After that has happened, checkouts of these modules will not compile until I've had the chance to apply the necessary changes. I'll let you know as soon as everything is in order again. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 1

Re: [boost] Re: FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <loom.20050509T200130-152(a)post.gmane.org> nesotto(a)cs.aau.dk (Thorsten Ottosen) wrote (abridged): > > Also it requires users to #include <iterator> in order to use the new > > looping construct. There's precedent for that, though, because users > > must #include <typeinfo> to use typeid. I can't decide how I feel > > > about that. Perhaps there's another way. > > I spoke with several implementers and they all said that we need to > include some special header...otherwise it is very problematic to let > the compiler and standard library work together. Could you include a very specific header, eg called <for>, with just whatever it is "for" needs, and require that header to be #included by <iterator> and <vector> and the other containers? Or some similar mechanism... obviously there needs to be a way for end users to get the support for their own containers, and although I suppose just #including <iterator> would do, a smaller header might be better for the same reason that <vector> doesn't #include <iterator>. I appreciate that having standard headers document what other headers they include is a new thing. Would it be a problem in this case? -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <427FB7C9.9030708(a)systemhaus-gruppe.de> sstrasser(a)systemhaus-gruppe.de (Stefan Strasser) wrote (abridged): > > Although it doesn't seem to say whether "vec" is hoisted, and the > > given translation suggests that it isn't. > > maybe "hoisting" was not the right word, I only know it from a post by > eric. "Hoisting" is fine for the purposes of this thread. > what I meant was copy-the-value-of-end()-at-the-start-of-the-loop. > and the proposal does that, see 3. It says end(vec) is hoisted, but doesn't say whether vec itself is hoisted. In "for (int i: vec )" is vec evaluated once or twice? I believe BOOST_FOR evaluates it exactly once. The translation given in the proposal is: using std::begin; // enable ADL using std::end; // ditto for( auto __begin = begin(vec), __end = end(vec); __begin != __end; ++__begin ) { int i = *__begin; std::cout << i; } which apparently evaluates vec twice. A variable __end is introduced explicitly for end(vec), but there is no analogous variable __vec. I guess we ought to find out for sure which it will be, and then make BOOST_FOR do the same. -- Dave Harris, Nottingham, UK.

2 1

Re: [boost] FOREACH / C++ "for" proposal
by brangdon＠cix.compulink.co.uk 10 May '05

10 May '05

In-Reply-To: <427F7635.4010303(a)systemhaus-gruppe.de> sstrasser(a)systemhaus-gruppe.de (Stefan Strasser) wrote (abridged): > you might be interested in this document from the new c++0x mailing: > > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html > > for the naming discussion, proposed syntax is for(int i : vec) > (personally I don't care if it's called BOOST_FOREACH or BOOST_FOR) I don't mind if it is BOOST_FOR_EACH or BOOST_FOR :-) > I've questioned in the past if it is expected behaviour to do > "hoisting". the proposal does. Although it doesn't seem to say whether "vec" is hoisted, and the given translation suggests that it isn't. I imagine that is an oversight in the presentation rather than the intended semantics. Interestingly he gives an example of an adaptor which could potentially be evaluated multiple times. The proposal says: The user is required to include the standard header <iterator> in which the default version of begin()/end() is defined which seems wrong to me. #include<vector> ought to be enough to use for with std::vector, if it's a built-in facility. -- Dave Harris, Nottingham, UK.

3 2

[gcc regressions] what's up with them
by Thorsten Ottosen 10 May '05

10 May '05

Hi, When I look at something like http://tinyurl.com/9v2as I assume the error is not in my library. Should/Can we do anything to fix it? -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 12

[boost.assign] help with borland, sunpro & cw 8.3
by Thorsten Ottosen 10 May '05

10 May '05

Hi All, If anyone thinks these compilers are important to support in boost.assign, I will need your help to make these regressions run. Otherwise I will flag the errors as "expected failure". -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 5

boost log lib 1.3 compile failure w/gcc
by Neal Becker 10 May '05

10 May '05

I am looking at boost log library 1.3. I tried to compile "simple" example with gcc-3.4.3 (linux), here's what happens: g++ -o main main.cpp -I ../../../../ In file included from ../../../../boost/log/detail/ts.hpp:37, from ../../../../boost/log/log_fwd.hpp:34, from ../../../../boost/log/log.hpp:36, from ../../../../boost/log/log_impl.hpp:33, from main.cpp:4: ../../../../boost/log/detail/ts_posix.hpp: In constructor `boost::logging::threading::mutex::mutex()': ../../../../boost/log/detail/ts_posix.hpp:54: error: no matching function for call to `pthread_mutex_t::._10(int)' /usr/include/bits/pthreadtypes.h:87: note: candidates are: pthread_mutex_t::._10() /usr/include/bits/pthreadtypes.h:87: note: pthread_mutex_t::._10(const pthread_mutex_t&) In file included from ../../../../boost/log/log_impl.hpp:33, from main.cpp:4: ../../../../boost/log/log.hpp: At global scope: ../../../../boost/log/log.hpp:277: error: declaration of `bool boost::logging::logger_keeper_is_enabled<is_compile_time, is_enabled>::is_enabled(boost::logging::logger&) const' ../../../../boost/log/log.hpp:276: error: shadows template parm `bool is_enabled' ../../../../boost/log/log.hpp:277: error: declaration of `bool boost::logging::logger_keeper_is_enabled<is_compile_time, is_enabled>::is_enabled(boost::logging::logger&) const' ../../../../boost/log/log.hpp:276: error: shadows template parm `bool is_enabled' C

2 4

Re: [dynamic_bitset] Stream extraction failures on CodeWarrior 9.4
by Gennaro Prota 10 May '05

10 May '05

--- Howard Hinnant <hinnant(a)twcny.rr.com> wrote: > I know the Metrowerks library inside/out. I started looking at this > last night but I'm pretty lost in the test code. I see. It's not the clearest code in the world. It is logically simple but a bit hard to debug due to the high number of combinations (and workarounds) involved. > > Here's what I have so far: > > Failure inside of: > > template<typename Stream, typename String> > static void stream_extractor(Bitset& b, > Stream& is, > String& str > ) > > at: > > if(stream_was_good) > BOOST_CHECK(remainder == str.substr(after_digits)); > > At this point remainder is a zero-length string, after_digits is 0 and > str is length 359. That's odd. after_digits is the position of the first character that follows 1s and 0s. The 359-characters str parameter should be the long string defined in bitset.hpp, thus you should have at least after_digits==359. I may be wrong because I don't have the necessary time and calm to check the code from the office but it might be worth examining this part. In particular if, for some reason, is_one_or_zero() is immediately returning false. > > On entry to this routine b has length 1 and that element is true. I > believe, but I am not positive that str is unmodified through this > test, despite being passed by reference (as opposed to const ref). > > I've so far been unable to determine the state of the stream is on > entry. But it looks completely hosed by the time the BOOST_CHECK is > triggered. For example the iostate has the value 0x7E even though the > highest numerical state it can possibly have is 0x07. That's odd too. I'll continue reading this thread via mail. Please keep me informed and sorry for not being able to dig into this myself. -- Genny Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html

1 0

Standard Library Extension TR2 Call for Proposals
by Beman Dawes 10 May '05

10 May '05

The C++ Standards Committee has begun work on a second library technical report. A Call for Proposals is available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html --Beman

1 0