- Boost - lists.boost.org

Release 1.33
by Robert Ramey 10 Feb '05

10 Feb '05

I would hope that soon we might think of releasing an updated version of boost - 1.33 As far as I know this might include a)bug fixes for herefore untested combinations of compilers, varients, etc b)Jonathon Turkanis stream bufffer library c)Other libraries (Ranges?) d)Serialization library - bugfixes and DLL version Robert Ramey

6 15

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor > Sent: woensdag 9 februari 2005 17:23 > To: boost(a)lists.boost.org > Subject: Re: [boost] Wave C++ Review Begins Today - February 7, 2005 > ... > Even dereferencing *last could be a bug, if it is > past-the-end. For iterators referencing contiguous memory > (vectors and pointers only, as you've said), one would need to write > > scanner.last = scanner.first + std::distance(first, last); True, but that's an partial fix. For now, I've fixed that bug too in my vector<char> wrapper but it's becoming complex. I'm afraid someone will have to write re2cpp. > > I really have to say Dinkumware did a fine job here, this > would have > > been very hard to find without these checks. > > FWIW, STLport and newer versions of GCC (Apple GCC 3.3, FSF > GCC 3.4) have similar debugging modes. They've been > invaluable in rooting out subtle bugs like those that stem > from iterator invalidation. Yep, although I'm currently wondering if they're 100% right. Is it legal to compare iterators from different containers? I can't find the appropriate wording so I'll just trust Dinkumware here. My current problem is, somewhere deep down in cpp_macromap.hpp a simple innocent if (first != last) statement (line 433) triggers another assertion. These are iterator_facade's (which I don't grok) and end up comparing iterators to two distinct containers. Looking the other way on the callstack, I see some deeply suspect iterators (singular, destroyed, ?) Too messy to say what happened. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

6 7

RE: [boost] Re: Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 10 Feb '05

10 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Mensonides > Sent: woensdag 9 februari 2005 23:44 > To: boost(a)lists.boost.org > Subject: RE: [boost] Re: Wave C++ Review Begins Today - > February 7, 2005 > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser [ attribution already lost ] > > > b. Sometimes it may be useful to be able to "partially > > > preprocess" given source. E.g. I would like to > > > have cleaner version of STLport just for my platform. > > > > > > It would be nice if I could specify list of > > > #defines and #undefines to be processed, the rest > > > left as is. > > > > Hmmm, that's more complex, I'll have to think about this. > > That is actually a lot more complex. It implies a heavy duty > dependency analysis on, for example, macros. I think that > implementing this would be more complex (to do correctly) > than the entire preprocessor altogether. I've been thinking about this as well. I'm not sure if we actually want the same, but my idea was to have a partial-evaluation mode which would replace only those tokens actually defined, and evaluate only those #ifdef( )/#if statements that depend on the macros explicitly defined or undefined. I suspect the major internal difference is that in full evaluation a macro is either defined or undefined, while in partial evaluation it can also be not evaluated. The technically tricky stuff is probably neatly rewriting complex #if (a&&b||c) conditions. Requirement-wise it's what to do with #include'd files. Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

[range] wrong OS assumed when intel compiler is used
by Martin Wille 10 Feb '05

10 Feb '05

Hi, there's again code in Boost which incorrectly assumes Windows when Intel C++ is used. E.g. I see this error here: intel-linux-C++-action ../bin/boost/libs/range/test/mfc.test/intel-8.1-linux/debug/mfc.o /boost/head-regression/boost/boost/range/detail/mfc/cstring.hpp(18): catastrophic error: could not open source file "afx.h" #include <afx.h> // for CString The range library also has problems regarding its use of Boost.Test: intel-linux-C++-action ../bin/boost/libs/range/test/std_container.test/intel-8.1-linux/debug/std_container.o ../libs/range/test/std_container.cpp(27): error: namespace "boost::unit_test" has no member "test_suite" using boost::unit_test_framework::test_suite; Regards, m

1 0

[boost.indirect container] RFC on interface changes
by Thorsten Ottosen 09 Feb '05

09 Feb '05

Dear all, I'm working on getting the indirect container library (former smart container lib) ready for a post-review. During the review it was decided to provide overloads of assign(), insert() etc that takes a Range instead of two iterators. That is often a problem because of multiple overloads, that is, we get ambiguity. Basically I think we got two alternatives: 1. template< class Iter > void container::assign( const iterator_range<Iter>& ); ... container c; c.assign( make_iterator_range( some_range ) ); 2. template< class Range void container::assign_range( const Range& ): .... container c; c.assign_range( some_range ); Which one do you prefer? Another issue relates to the null pointer policy, that is, the way we specify how the container is allowed to include nulls. Here's two alternatives: 1. container< T > // null not allowed container< nullable<T> > // null allowed 2. container<T&> // null forbidden container<T*> // null allowed Thansks for your feedback. -Thorsten -- Thorsten Ottosen ---------------------------- Dezide Aps -- Intelligent Customer Support: www.dezide.com Aalborg University --- Decision Support Systems: http://www.cs.aau.dk/index2.php?content=Research/bss C++ Boost: www.boost.org C++ Standard: http://www.open-std.org/JTC1/SC22/WG21/

2 4

Checking out latest Boost lock problem
by Edward Diener 09 Feb '05

09 Feb '05

Attempting to check out the latest Boost I am being stopped by: cvs checkout: [23:53:01] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/utility/doc

22 57

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 09 Feb '05

09 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Hartmut Kaiser > Sent: woensdag 9 februari 2005 14:42 > To: boost(a)lists.boost.org > Subject: RE: [boost] Wave C++ Review Begins Today - February 7, 2005 > > > Michiel Salters wrote: > > one serious bug in wave\cpplexer\re2clex\cpp_re2c_lexer.hpp: > > template <typename IteratorT, typename PositionT> inline > > lexer<IteratorT, PositionT>::lexer(IteratorT const &first, > > IteratorT const &last, PositionT const &pos, > > boost::wave::language_support language) > > : filename(pos.get_file()), at_eof(false) > > { > > memset(&scanner, '\0', sizeof(Scanner)); > > scanner.fd = -1; > > scanner.eol_offsets = aq_create(); > > scanner.first = scanner.act = (uchar *)&(*first); > > scanner.last = (uchar *)&(*last); > > ... > > [ IteratorT = std::string::iterator in the example ] > > > > This assumes that the range [first,last] is dereferenacable and > > contiguous in memory. This of course is not mandated by the > standard. > > Yes, this is a known problem (see the Changelog file), I > didn't realise, that it will assert on some systems. Seems, > that I'll have to fix that soon ;-). This shouldn't be a > problem on other systems, though, if you're using iterators > acting on a continuous chunk of memory (such as > std::string::iterator). No, you're mistaken here and in the Changelog as well. Even std::string::iterator doesn't have to refer to contiguous memory. std::vector<char>::iterator would, though, so I built a string around that and found the actual bug (and a VC8 bug as well I think). The bug is that context<IteratorT> stores the two iterators first and last as const&. The cpp example passed .begin() and .end(), which are temporaries and they go out of scope. The result is that the context ends up with references to destructed iterators. Again, the VC8 STL iterator debugging found the problem on first access. Line 281, cpp_context.hpp I really have to say Dinkumware did a fine job here, this would have been very hard to find without these checks. > OTOH this isn't exactly a problem in the preprocessor > library, it's merely a problem of the re2c generated lexer > used in the driver. The other provided lexer (SLEX based) > won't expose this problem (i.e. the cpp_tokens example > shouldn't assert). Might be (didn't get there yet), but it too uses cpp_context.hpp, right? BTW, if you try VC8, mail me for the string class I used. Using std::vector<char> directly appears to trigger a VC 8(beta1) bug with typenames longer than 2KB Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

3 3

BOOST_CHECK_EQUAL broken/changed?
by John Maddock 09 Feb '05

09 Feb '05

This one really bit me badly: BOOST_CHECK_EQUAL now evaluates it's arguments *more than once*, for example I have many tests that look like: BOOST_CHECK_EQUAL(*it++, 0xD800u); But the expression *it++ gets evaluated multiple times, and that really screws up the tests :-/ IMO I can't see any good reason for such a change? John.

2 1

RE: [boost] Wave C++ Review Begins Today - February 7, 2005
by Michiel Salters 09 Feb '05

09 Feb '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Brinkman > Sent: dinsdag 8 februari 2005 3:48 > To: boost(a)lists.boost.org > Subject: [boost] Wave C++ Review Begins Today - February 7, 2005 I'm currently looking at the library, trying to get the (included) command-line executable to work. So far, I've found two documentation minor nits: * Source and zip say version 1.1.2, index.html says 1.2 * index.html says program_options must be downloaded, but it's in boost 1.32 ? one serious bug in wave\cpplexer\re2clex\cpp_re2c_lexer.hpp: template <typename IteratorT, typename PositionT> inline lexer<IteratorT, PositionT>::lexer(IteratorT const &first, IteratorT const &last, PositionT const &pos, boost::wave::language_support language) : filename(pos.get_file()), at_eof(false) { memset(&scanner, '\0', sizeof(Scanner)); scanner.fd = -1; scanner.eol_offsets = aq_create(); scanner.first = scanner.act = (uchar *)&(*first); scanner.last = (uchar *)&(*last); ... [ IteratorT = std::string::iterator in the example ] This assumes that the range [first,last] is dereferenacable and contiguous in memory. This of course is not mandated by the standard. I found this, because VC8.0 has iterator debugging, and it asserted. Not sure if this is the exact cause, I just found the code in the stacktrace. I tried to hack the Scanner by replacing its uchar* with iterator's but that really doesn't work. The generated code uses memcpy's and malloc's. I'll try to see if I can avoid this, perhaps try another string type. Perhaps the command-line example should use BOOST_WAVE_STRINGTYPE iso std::string? Regards, Michiel Salters This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

2 1

[Boost-bugs] [ boost-Patches-1115576 ] Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options]
by SourceForge.net 09 Feb '05

09 Feb '05

Patches item #1115576, was opened at 2005-02-03 17:15 Message generated for change (Comment added) made by hxpro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: hxpro (hxpro) Assigned to: Nobody/Anonymous (nobody) Summary: Patch 1.32 IRIX MIPSPro 7.4.1 [Test Bind Program Options] Initial Comment: Some simple fixes to make the build work... ---------------------------------------------------------------------- >Comment By: hxpro (hxpro) Date: 2005-02-09 09:54 Message: Logged In: YES user_id=1211438 Yes, its a templated getline that is using a bare '\n' instead of a specialised form for wchar_t or calling widen() etc. Kevin ---------------------------------------------------------------------- Comment By: Vladimir Prus (vladimir_prus) Date: 2005-02-09 09:07 Message: Logged In: YES user_id=321498 I've applied the program_options patches. Thanks. Does the compiler has the same getline problem as Comeau -- calling wide version without explicit L'\n' fails? ---------------------------------------------------------------------- Comment By: hxpro (hxpro) Date: 2005-02-07 11:08 Message: Logged In: YES user_id=1211438 N.B. The boost bind patch is now in revision 1.40 in CVS see http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/bind.hpp?r1=1.40 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1115576&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0