- Boost - lists.boost.org

[serialization] Compatibility between 1.32 and 1.33
by Klaus Nowikow 06 Jul '05

06 Jul '05

Will a file created with a binary archive from Boost 1.32 be readable with Boost 1.33? I am just building the latest version from the cvs to try it myself, but I thought it would also be a good idea to ask this here. Best regards, Klaus

9 17

Problem with bjam and external library
by Steven Weiß 06 Jul '05

06 Jul '05

Hallo, for Win32GUI Lib I need to link shlwapi.lib. Since the library is built with bjam I tried to follow the advice given at http://lists.boost.org/boost/2004/05/6103.php and searched a bit in the internet. unfortunately it doesn't work - when building Win32GUI I still get Linker errors (SHCreateStreamOnFile() can't be resolved) here is the relevant code of the jamfile: ... lib win32gui : ../../src/$(SOURCES).cpp : [ common-names ] <include>../../.. <define>WIN32GUI_NO_LIB <define>WIN32GUI_BUILDING_LIB <threading>multi <library-path>"C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\lib" : debug release <debug><find-library>shlwapi<runtime-link>static <release><find-library>shlwapi<runtime-link>static ; I added the <library-path> and <find-library> instructions. what am I doing wrong? mfg Steven

3 8

[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 05 Jul '05

05 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 05 Jul '05

05 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 05 Jul '05

05 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