July 2005 - Boost - lists.boost.org

[regex] Clearing failures in regex_regress on Tru64/CXX
by Markus Schöpflin 06 Jul '05

06 Jul '05

Attached patch clears the current failures in regex_regress on Tru64/CXX. Basically it adds an explicit instantiation of a template class needed because otherwise CXX ends up with multiple instances of the static variable used in the class, which is because of the template compilation model chosen for the compiler. As it shouldn't hurt other compilers, I didn't wrap it in #if ... #endif. Secondly it avoids three tricky test cases which hang the test program otherwise. Ok to commit? Markus Index: regress/info.hpp =================================================================== RCS file: /cvsroot/boost/boost/libs/regex/test/regress/info.hpp,v retrieving revision 1.3 diff -u -w -r1.3 info.hpp --- regress/info.hpp 21 Jan 2005 17:26:27 -0000 1.3 +++ regress/info.hpp 28 Jun 2005 12:52:13 -0000 @@ -140,6 +140,11 @@ : public test_info_base<char> {}; +// Explicit instantiations to avoid trouble with multiple instances +// of static variables in the test_info_base class. +template struct test_info_base<wchar_t>; +template struct test_info_base<char>; + template <class charT> std::ostream& operator<<(std::ostream& os, const test_info<charT>&) { Index: regress/test_tricky_cases.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/regex/test/regress/test_tricky_cases.cpp,v retrieving revision 1.4 diff -u -w -r1.4 test_tricky_cases.cpp --- regress/test_tricky_cases.cpp 30 Mar 2005 11:38:51 -0000 1.4 +++ regress/test_tricky_cases.cpp 28 Jun 2005 12:52:13 -0000 @@ -256,10 +256,12 @@ TEST_REGEX_SEARCH_W(L"[[:unicode:]]+", perl, L"a\x0300\x0400z", match_default, make_array(1, 3, -2, -2)); TEST_REGEX_SEARCH_W(L"[\x10-\xff]", perl, L"\x0300\x0400", match_default, make_array(-2, -2)); TEST_REGEX_SEARCH_W(L"[\01-\05]{5}", perl, L"\x0300\x0400\x0300\x0400\x0300\x0400", match_default, make_array(-2, -2)); +#if !BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590042)) TEST_REGEX_SEARCH_W(L"[\x300-\x400]+", perl, L"\x0300\x0400\x0300\x0400\x0300\x0400", match_default, make_array(0, 6, -2, -2)); TEST_REGEX_SEARCH_W(L"[\\x{300}-\\x{400}]+", perl, L"\x0300\x0400\x0300\x0400\x0300\x0400", match_default, make_array(0, 6, -2, -2)); TEST_REGEX_SEARCH_W(L"\\x{300}\\x{400}+", perl, L"\x0300\x0400\x0400\x0400\x0400\x0400", match_default, make_array(0, 6, -2, -2)); #endif +#endif // finally try some case insensitive matches: TEST_REGEX_SEARCH("0123456789@abcdefghijklmnopqrstuvwxyz\\[\\\\\\]\\^_`ABCDEFGHIJKLMNOPQRSTUVWXYZ\\{\\|\\}", perl|icase, "0123456789@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}", match_default, make_array(0, 72, -2, -2)); TEST_REGEX_SEARCH("a", perl|icase, "A", match_default, make_array(0, 1, -2, -2));

4 14

Re: [boost] [serialization] Compatibility between 1.32 and 1.33
by Martin Bonner 06 Jul '05

06 Jul '05

----Original Message---- From: Robert Ramey [mailto:ramey@rrsd.com] Sent: 05 July 2005 18:35 To: boost(a)lists.boost.org Subject: Re: [boost] [serialization] Compatibility between 1.32 and 1.33 > David Abrahams wrote: >> "Robert Ramey" <ramey(a)rrsd.com> writes: >> >> What is the mechanism at work here? Anything involving an #include >> order dependency worries me, because usually these things are a >> playground for ODR violations or other inducers of undefined >> behavior. > > The idea is that I didn't want to burden user's of the library with > loading the shared_ptr_132.hpp header if they don't need it. So if > you don't need to read older archives one can use: > > #include <boost/serialization/shared_ptr.hpp> > > which is what everyone would expect. This skips over useless and > wasteful code that is not needed. > > If one needs his code to be able to read shared_ptr archived under > the 1.32 system, he would use: > > #include <boost/serialization/shared_ptr_132.hpp> > #include <boost/serialization/shared_ptr.hpp> > > Of course an alternative would be for > <boost/serialization/shared_ptr.hpp> > to include .../shared_ptr_132.hpp but I thought people without old > archives would object to that - as I would personally. It seems to have been a major design aim of yours to minimize the amount of code dragged into the compiler and into the executable. My impression is that a LOT of the comments on the serialization library have related to the choices you have made in pursuit results of that design. I would like to suggest that you have over done it. Personally, I would expect serialization of old archives to "just work" (and would be very concerned if it didn't). In this particular case, I think shared_ptr.hpp should include shared_ptr_132.hpp /unless/ the user has defined BOOST_SERIALIZE_NO_LOAD_132_SHARED_PTR (or some more elegant name) beforehand. That way the concerned user can save themselves the overhead, whereas the default is safe. In general, I think it would be better if you worried less about including unnecessary code (I'm not saying you shouldn't worry about it, just worry less.) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 2

[home page] Marketing?
by Beman Dawes 06 Jul '05

06 Jul '05

While the redesigned Boost home page is informative and visually attractive, it doesn't seem to me to have much marketing punch because it doesn't give a viewer any idea of how useful and successful Boost has become. Thanks to stylesheet help from Rene Rivera, I've drafted a new section (currently entitled "Mini-FAQ") that is supposed to convey the marketing message that Boost is a success and useful to a lot of people. See draft version at http://www.esva.net/~beman/boost-home/index.htm Comments? Do others think this is worth adding? If we go forward with this, I'll try to get quotes from one or two other C++ luminaries to go in the "What do others say about Boost" sub-section. --Beman

12 21

[BGL] Bug and proposed patch for read_graphviz to read dos formatted .dot files
by Tan Kwee Heong 06 Jul '05

06 Jul '05

Hi, I am submitting this bug and proposed patch as outlined in the procedure in http://www.boost.org/more/bugs.htm. Let me know if more information is needed. Also, since my patch is just a proposed solution, I am open to a better solution, etc because there may be issues I am not aware of and therefore, not taken into account. Bug description : Platform - Win2K Compiler - Cygwin g++ 3.3.1 read_graphviz when compiled with g++ will only read .dot in unix format, and fails with a "Syntax error" for .dot files in dos format. For comparison, read_graphviz when compiled with VC7.1 will read .dot files created in both formats. FYI : A text file created in dos format has line terminations as \r\n while a text file created in unix forma has line terminations in \n. Proposed fix: This patch allows the graphviz_lex.ll to consider both \n and \r\n as line terminations, thereby allowing read_graphviz to work on .dot files created in dos and unix format, regardless of which platform/compiler BGL was compiled on. This is also consistent with the Windows Graphviz tools like dotty, that also work regardless of whether the .dot files are of unix or dos format. Essentially, an additional rule is added to graphviz_lex.ll to recognize and discard \r\n. Attached file : graphviz_lex.ll.patch begin 666 graphviz_lex.ll.patch M*BHJ(&=R87!H=FEZ7VQE>"YM86EN+FQL"5-U;B!*=6P@(#,@,C$Z,# Z,C,@ M,C P-0HM+2T@9W)A<&AV:7I?;&5X+FQL"5-U;B!*=6P@(#,@,C$Z,#8Z,3 @ M,C P-0HJ*BHJ*BHJ*BHJ*BHJ*BH**BHJ(#@X+#DS("HJ*BH*+2TM(#@X+#DT M("TM+2T*(" \3&ET97)A;#Y;7%Q=6UQN72 @(" @.PH@(#Q,:71E<F%L/BA; M7B)<7%TJ?%M<7%TN*2 @>R!A9&1?<W1R:6YG*'EY=&5X="D[('T*("!;(%QT M72 @(" @(" @(" @.PHK(%QR7&X@(" @(" @(" @(" ["B @7&X@(" @(" @ M(" @(" @(#L*(" N(" @(" @(" @(" @(" @>R!R971U<FX@>7ET97AT6S!= ).R!]"B @)24* ` end

2 1

[Parameter] Best Practices
by David Abrahams 06 Jul '05

06 Jul '05

According to http://lists.boost.org/boost/2004/12/17263.php we need to add a "Best Practices" section to the Parameter library documentation: I think this is the original request, from http://lists.boost.org/boost/2004/11/16298.php: 1) A "guide for library writers" that helps one organize a library properly for named parameters. For instance, where should we put keywords? I know we should use an anonymous namespace, but should that be in namespace boost? In a "keywords" subnamespace? With a follow-on, from http://lists.boost.org/boost/2004/11/15941.php, with answers in http://lists.boost.org/boost/2004/11/15991.php: > Since they may be used so often, > should they be defined in a single library-specific > header, e.g. <boost/graph/keywords.hpp>? Not neccessarily. They should probably be decoupled and included as needed in each header. > And would it > help if each name had an appropriate prefix, like > "bgl_", to help avoid object collisions? Not much; I would nest the unnamed namespace inside boost (or a sub-namespace thereof). I don't know if we have enough here to warrant a separate "best practices" guide. Did anyone have anything else in mind for this section, or should we consider rolling the answers into one of the other sections of the documentation? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Nightly CVS snapshot
by Andrey Melnikov 06 Jul '05

06 Jul '05

Do we have one now? Once I downloaded boost-CVS-HEAD-05-05-21-1305 tarbal from metacomm, but don't remember the url.. Andrey

2 1

[Boost-bugs] [ boost-Bugs-1232958 ] bjam can't handle compressed archives
by SourceForge.net 05 Jul '05

05 Jul '05

Bugs item #1232958, was opened at 2005-07-05 19:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1232958&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Sarytchev (alx_s) Assigned to: Nobody/Anonymous (nobody) Summary: bjam can't handle compressed archives Initial Comment: On some platforms (True64, e.g.) archive libraries can contain compressed members. Boost jam doesn't work properly with them. Attached is a simple fix for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1232958&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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: Customer Friendlier Boost Installation
by Martin Bonner 05 Jul '05

05 Jul '05

----Original Message---- From: Jason Earl [mailto:Jason@hybd.net] Sent: 25 May 2005 15:32 To: boost(a)lists.boost.org Subject: Re: [boost] Re: Customer Friendlier Boost Installation > I think a lot of Windows users are too used to things just working > out of the box, and give up if things don't work like that. If you change that to "A lot of Windows users are used to things just working out of the box, and give up if things don't work like that", you have it exactly right. What is wrong with such expectation? > > As for understanding what targets are etc, I think most developers > will know what targets are. I don't. If you use the Microsoft IDE, you never use the term. [snip] > Maybe it would be good to have some control over build verbosity > (there probably already is some, I just haven't looked yet), Maybe > logging the build info to a file would be better and then logging > errors, messages etc to the screen (and maybe a separate) log file. What people REALLY want, is to download headers + pre-built binaries. If they can't have that, then next best is a pretty gui which asks them all the questions (with the right defaults), and just works. If they can't have that, then really good documentation is required, and I don't think boost is there yet. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

14 38

RE: [boost] Re: Customer Friendlier Boost Installation
by Brian Braatz 05 Jul '05

05 Jul '05

Wild thought- Is there a rational way to have a "environment" checker. I am NOT a bjam expert- but it would be handy if we had some cmd line program that would follow spit out all the info BJAM looks for and finds. I am slightly half cocked in this idea, but basically it would have to be enough information that you could get a better sense for what Bjam was doing Something like C:\boost\> boostenvcheck.exe ** Enviroment Report** Python is not in the path User-config.jam file is setup to use gcc, vc7.1 Etc.... I have been using boost for (has it been that long) 2 years now. Bjam still confounds me. ( I appreciate the work effort, it is a cool tool, I remain struggling with it though) (I am also a tad frustrated because I have been trying to make vc7.1 build wave for the last 5 hours) Semi-Related: I proposed (a long time ago) building a SIMPLE gui framework- with the core elements, and then making a "boost environment checker" out of that- I.e. imagine a tree control with all the types of settings and what nots, and the ability to navigate this gui to try to determine what is not set correctly. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Lars Gullik Bjønnes > Sent: Thursday, May 26, 2005 3:27 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Customer Friendlier Boost Installation > > "Hendrik Schober" <SpamTrap(a)gmx.de> writes: > > | Lars Gullik Bjønnes <larsbj(a)gullik.net> wrote: > >> David Abrahams <dave(a)boost-consulting.com> writes: > >> > >> | We never wanted to be the sole province of experts. We always wanted > >> | widespread usage. If you want to be a member of an exclusive > >> | "experts" club this is the wrong place to find it. > >> > >> Sure. But there, imho, must be a difference expected between _users_ > >> of the libraries, and _installers_ (or packagers) of the libraries. > > > > > | How so? Shall people employ an administrator to > | install the libs they want to check out? > > No. But IMHO it should be expect that it is a bit harder to install > (and in this case it is build as well) the library than use it. > > So: Create an windows installer and then the user can use that. > > -- > Lgb > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

7 13

Re: [boost] [function_type] Tag types documentation
by Dave Gomboc 05 Jul '05

05 Jul '05

> The Function Type library uses tag types to represent a type's > attributation, such as its calling convention or wether it is > variadic. > > Tags that represent the values of a single property are called > property tags. These tags can be used to determine whether one > property of a type has a particular value. > > is_function< T, variadic > > is_function< T, default_call > > > Does it work? It's better than before. I still think you shouldn't mix "uses tag types" (plural) with "a type's attributation" (singular), but you're the author. ;-) I'd still go with "to represent attributations of types", similar to how I wrote that line previously. Oh, also, fix the spelling of "whether". > I have. Try these use cases: > > // a remove constness (of the pointee) from a member > function pointer type T > function_type<signature<T>,tag<signature<T>,non_const> >::type > > // shortcut: > function_type<T, non_const >::type > > or > > // create a (possibly decorated) function type's > variadic version > function_type<signature<T>,tag<signature<T>,variadic> >::type > > // shortcut: > function_type<T, variadic >::type Is manipulating these using MPL containers too much hassle for too little benefit? If <T, nonvariadic, variadic, variadic, nonvariadic, variadic> is really going to be the same as <T, variadic, nonvariadic, variadic>, then even testing for equivalence between tags becomes somewhat of a chore. > Well, we /could/ only allow overriding only in this very > context, however, it > would make things inconsistent and more complicated to explain, IMO. > I don't see a problem in allowing it either, because most > error situations are > pretty obvious > > a = 1; > a = 2; // <-- should this line fail to compile? No, your example above is (roughly speaking) X = tag<T, nonvariadic>; X = tag<T, variadic>; Which sequentially assigns different values to X. By writing tag<T, variadic, nonvariadic>, to my eyes you're writing something akin to "a = 1 and a = 2 (at the same time)" [One example in runtime-C++ is calling f(a=1, a=2), which does not at all guarantee that a=2 at the end of this expression! But a guru may come up with a better example.] Then, you specify a rule that says "If I assign more than one value at the same time, I really mean the last one", which is different behaviour than runtime-C++ gives. That's why this asymmetric disambiguation behaviour feels awkward to me. > plus 'tag' seldom has to be used directly by the user, anyway. > > Further there is the technical side of the story: > > tag<A,B> > > only describes a type (talking C++ type system context here) > and thus does not trigger a template instantiation. So the > error message you get would probably involve a lot of trace > (to where its PoI is) output and be questionable useful, > because of this. Explicit instantiation of templates is our friend in such cases. This is nothing new to template users. Dave

3 7