- Boost - lists.boost.org

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

[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 vladimir_prus 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: 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

Re: [boost] Re: [serialization] automatic linking andintrusiveserialization support
by JOAQUIN LOPEZ MU?Z 09 Feb '05

09 Feb '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Miércoles, Febrero 9, 2005 0:20 am Asunto: [boost] Re: [serialization] automatic linking andintrusiveserialization support [...] > fJOAQUIN LOPEZ MU?Z wrote: [...] > > So far so good. Boost 1.33 release of Boost.Serialization, > > if I'm not wrong, will include automatic linking, and here comes > > the problem: when doing the upgrade to 1.33, user2 will be > > delighted that he'll no longer need to do the linking stuff by > > himself; > > > but user1 will get mysterious "not found" linking errors, > > or worse yet, he'll have Boost.Serialization automagically > > bundled into his final executable, when he never explictly > > dealed with this lib in the program! > > I don't believe this is the case. Templated code is not emitted unless > explictly invoked. If user2 never serializes anything the then > the member > serialization template won't be expanded. This view is supported > by the > fact that if serialization isn't used - then no *_iarchive.hpp > file is > included so the template argument Archive has no known value so its > impossible for the compiler emit the code. > I think I'm not explaining myself clearly. I agree with you that user1 won't cause any serialization-related code to be emited by the *compiler*. The problem is that, by virtue of the internal #include <boost/serialization/access.hpp> in foo.h, he will get Boost.Serialization autolinked, because <boost/serialization/access.hpp> (or some other serialization header, don't know precisely) ultimately includes auto_link.hpp. In other words: he will stumble upon Boost.Serialization binary without ever explicity mentioning or trying to use this library. At the risk of repeating myself, try compiling the following: #include <boost/serialization/access.hpp> int main(){} If I'm correct, autolinking will kick in yet the program does not use Boost.Serialization at all. Of course the program has included a serialization header so it should face the consequences, but in the problem I describe that header is included internally and the user who won't be using serialization capabilities shouldn't be forced to explicitly disable autolinking. Get my point? If so, and if you agree with my analysis, do you think the workaround I propose would work? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[range] iterator_range fixes for gcc-2.95.x
by Jonathan Turkanis 09 Feb '05

09 Feb '05

Hi Thorsten, I see that gcc-2.95.x is not one of the supported platforms for range, and I assume that there is a good reason for this. However, I have a couple small changes to iterator_range which will make it work well enough on gcc-2.95 for the purposes of the iostreams library, and I'd like permission to commit. I also added some fixes for Intel. Here are the tests I've conducted: VC7.1: passes all tests but mfc Intel 8.0 (windows): passes all tests but mfc Borland 5.6.4: passes all tests but mfc and array (failure in Boost.Test) GCC 3.4.1: passes all tests but mfc GCC 3.2 (MinGW): passes all tests but mfc VC7.0: passes no tests, but same was true prior to the changes, on my installation (although the regression reports show three tests passing) Also, I've updated mfc/cstring and carray to use the new metafunction names, and made some fixes so that they compile on windows, but have not tried linking them. Jonathan

3 4

RE: [boost] class diagrams for template heavy design
by Randy Bowen 09 Feb '05

09 Feb '05

There's an Eclipse plug-in available for feature modeling, described in a paper by Czarnecki (http://www.swen.uwaterloo.ca/~kczarnec/etx04.pdf) > -----Original Message----- > From: Iain K. Hanson [mailto:ikh@hansons.demon.co.uk] > Sent: Tuesday, February 08, 2005 6:05 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] class diagrams for template heavy design > > On Sun, Feb 06, 2005 at 08:57:30AM -0700, Jeff Garland wrote: > > On Sun, 06 Feb 2005 07:32:53 +0100, Vasco Lohrenscheit wrote > > > > > > > Also, if you are willing to go outside UML pick up a copy of > > Generative Programming -- they describe other visual > modeling techniques. > > > > Czarneecki, Krzysztof and Eisenecker, Ulrich, "Generative > Programming: > > Methods, Tools, and Applications", Addison-Wesley, 2000 > > There are no case tools that I know of that do this but the > techniquck is callled FODA ( Feature oriented Domain Analysis > ). I think Don Batory at utexaqs first came up with it. It is > closley associated with a method called GenVoca. Krzysztof > Czarnecki wrote a book and his web page has a downloadable > chapter on FODA. > > I don't know if it is still there but Beman Dawes wrote an > article on how to do this on the boost site. > > Take care > > /ikh > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

class diagrams for template heavy design
by Vasco Lohrenscheit 09 Feb '05

09 Feb '05

Hi, sorry if this offtopic, but I don't know any other good place to ask this question: I'm currently in the situation to document a heavy templated class design (generic with templated policies and partial specializations, but nothing too exotic like boost::mpl ;-). I always prefer graphical UML like class diagrams to describe the basic design. Now I wonder if there are any good graphical representations for templated code but haven't found anything on this with a quick google search. As there are so many template wizards on this list, has someone any hints, links, suggestions on this? Thanks. best regards, Vasco Lohrenscheit

3 2

[serialization] automatic linking and intrusive serialization support
by JOAQUIN LOPEZ MU?Z 08 Feb '05

08 Feb '05

Suppose I'm the user of a class called foo which supports serialization through intrusive methods. So, foo.h will look like: // foo.h #include <boost/serialization/access.hpp> // other, non serialization-related includes class foo { ... }; Now, a programmer uses foo, but does not take advantage of its serialization capabilities. // user.cpp #include <foo.h> // use foo and a second programmer uses foo *and* serializes it. //user2.cpp #include <foo.h> #include <boost/archive/text_oarchive.hpp> // use foo and its serialization capabilities. So far so good. Boost 1.33 release of Boost.Serialization, if I'm not wrong, will include automatic linking, and here comes the problem: when doing the upgrade to 1.33, user2 will be delighted that he'll no longer need to do the linking stuff by himself; but user1 will get mysterious "not found" linking errors, or worse yet, he'll have Boost.Serialization automagically bundled into his final executable, when he never explictly dealed with this lib in the program! Of course, user1 can set BOOST_SERIALIZATION_NO_LIB and be done, but this is a burden which I'd like to save users from, if possible. So, here comes the question. Suppose the implementer of foo changes foo.h as follows (please bear with any preprocessor mistake by my part if there's any, I hope you get the point nonetheless): // foo.h #if defined(BOOST_SERIALIZATION_DYN_LINK) # define BACKUP1 #endif #if defined(BOOST_SERIALIZATION_NO_LIB) # define BACKUP2 #endif #undef BOOST_SERIALIZATION_DYN_LINK #define BOOST_SERIALIZATION_NO_LIB #include <boost/serialization/access.hpp> #if defined(BACKUP1) # define BOOST_SERIALIZATION_DYN_LINK #endif #if defined(BACKUP2) # define BOOST_SERIALIZATION_NO_LIB #endif // other, non serialization-related includes class foo { ... }; Now, if my idea is correct, user1 won't get Boost.Serialization autolinked (since <boost/serialization/access.hpp> was included with BOOST_SERIALIZATION_NO_LIB), and user2 will benefit from autolinking, as he included another Boost.Serialization header on his own. The best of both worlds. Do you think this approach would work? Any foreseeable problem? Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1