- Boost - lists.preview.boost.org

Boost Inter-Project Dependencies: Graphs Generated
by Christoph Heindl 20 Dec '08

20 Dec '08

Dear developers and members, I'm using boost for quite a while now and it helped me a LOT in my daily work! I wanted to give something back to the community and started a boost inter-project dependency parser project. The aim of the project is to generate boost inter-project dependencies by parsing boost header files and aggregate them in managable images. First results can be found at http://picasaweb.google.com/christoph.heindl/BoostDependencies1370# Please find the code, additional information and limitations at http://cheind.blogspot.com/2008/12/generic-dependency-parser-boost.html I hope this is useful to somebody :) Best regards, Christoph

3 4

Re: [boost] interest in properties library
by Daniel Oberhoff 20 Dec '08

20 Dec '08

Hi, On Fri, Dec 19, 2008 at 5:50 AM, Daniel Oberhoff < daniel.oberhoff_at_[hidden]> wrote: > Hi, > > I am thinking about submitting a library proposal and would like to query > wether there is any interest in such a library and chance of success of such > a proposal. > > The basic idea is to implement the possibility to decorate a class with > named properties, such that given a pointer to an instance properties can be > accessed by name rather than using set/get methods. Also the type of the > instance should not need to be known at compile time, other than that it > derives from a suitable base class describing the property mechanisms. > > There is a rough implementation existing and used in a product environment. > Setting and getting is done using appropriate boost functions. Type > resolution is done using RTTI (especially dynamic cast). Complex inheritance > hierarchies are supported through virtual inheritance from the base class, > such that several classes along the hierarchy can contribute property slots. > CRTP and static initialization is used to register properties. Convenient > setter/getter function generators are provided as is a mechanism to access > nested properties using dot notation. I'm not sure I follow exactly what you mean, could you give a small example of the interface and usage? It sounds like you are referring to something along the lines of C# properties though I don't immediately see what you are using dynamic casting for or what exactly this provides as a benefit over get/set methods. Thanks. Well, yes, it is in one way like c# (or ObjC 2.0) properties, in that you can have direct access to the variables first, and then override setters/getters later. But the difference is, that properties are accessed by name, and the type of the object does not need to be known. That is set/get methods of the object would never be visible. You only need to know, that the object derives from a HasPropertiesBase class. That is also where dynamic cast comes in, in order to hand the right pointer to the setter method (you may be surprised, but in the case of virtual inheritance the pointer returned by dynamic cast actually points to a different address). I use it in a setting where I generate objects from a factory, and they are returned as pointers to an abstract base class, and the actual type is never exposed. Also accessing properties by name makes scripting very easy. btw, I hope I got this reply addressed right. the problem is I thought this list is identical to boost.users on gmane, so I turned of mail reply, but it seems this is a different list. anyhow, is there general interest in such a library? Daniel -- -Matt Calabrese

1 0

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 20 Dec '08

20 Dec '08

On Thu, Nov 20, 2008 at 11:40 PM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: > > I would like to make some suggestion to improve the review management: > Thank you for starting this discussion. > * I had notice only at the end of the the review that the review tokes place on two mailing lists (devel ans user). Maybe this is usaual on Boost reviews but I was not aware. It will be more transaparent if all the reviews were posted to the same mailing list, maybe a specific one should be created. Yes, this is a bit of an issue. I mentioned that both lists are used in my post that opened the review (in my notes to first-time reviewers) to try to give people a heads-up (but... I often get long-winded and I'm sure it's easy to miss parts of my posts :-)). Having a dedicated, or at least recommended mailing list (either dev or user) might be a good thing. The only problem I see regarding a completely separate mailing list is that it requires active effort to sign-up for and follow. I think that for many people (even those that are genuinely interested in the library), the fact that the review is happening at time X-Y very easily slips off the radar. Having the e-mails constantly appear in the common lists also serves to remind everyone of the ongoing review, and I suspect it leads to many valuable impromptu comments and even full reviews from people that perhaps weren't originally planning on participating in the review, but end up following the review because it happens on the list (I recall being in this situation myself several times). > > * From the 5 committing reviewers making this review possible only 3 made a review and 2 of them late. I'm wondering if this new rule must be preserved as the review can be accepted without the commiting reviewers review. Trying to use committed reviewers was a new thing for this review (it was proposed by others in http://tinyurl.com/48tdjs) Now that it has been tried out, it would be good to reflect on how things went. For the reviews that were late, the reviewers were very diligently contacting me about their changing time constraints and offered times that would work for them, and I found those times acceptable. Out of the two committed reviewers that did not submit, one also diligently worked with me on setting up an alternative timeline, but in the end contacted me saying that a full review would not be possible after all, and offered a brief report of looking into the library and a brief rationale for acceptance (as the points matched those of other reviewers, I didn't forward it to the list). I was not able to contact the final reviewer after a certain point. I think the major benefit of the committed reviewers is the high probability that they actually will submit a review. Things always happen, and boost contributions are all volunteer time, but I found that overall the committed reviewers *very responsibly* succeeded in keeping their commitment as well as they could. Were they not committed reviewers, I suspect many of them would have considered giving up. In addition, the extensions that the committed reviewers negotiated gave other reviewers a chance to contribute. So, I feel that committed reviews are a good way of reasonably making sure that a certain number of reviews will be submitted. I'm not sure that the library acceptance / rejection should be influenced by the number of committed reviews (reviews from others are a perfectly good substitute). While we're on this topic... The one thing that the number of committed reviewers should definitely influence is whether the review happens in the first place. We were fortunate to get 5 people sign up, which was the only threshold proposed, so we followed through with the review. I was wondering what to do if the threshold wasn't crossed, and I think what I would have proposed is some sort of a holding pattern, where the review schedule page is updated to say something like "signals2 - reviewers needed, contact review manager to sign up as a reviewer". Once the threshold is crossed, the reviewers, manager and author can schedule a time. Another thing... many of the committed reviewers reported that they were first time reviewers (and the reviews they submitted were impressively detailed and very valuable). Personally, I was thrilled by this, since getting new participation in boost is critical to sustaining its quality . Perhaps some combination of allowing reviewers to commit beforehand, and explicitly encouraging reviews focused on the user perspective (another suggestion from the http://tinyurl.com/48tdjs thread), helped in getting first-time reviewers (perhaps the reviewers can comment on this?). > > * There were some reviews that came into this list by the intermediation of the review manager with a delay between the posting of the reviwer and forward from the RM. One negative review posted the 4th and reveived in this list the 11th other positive posted the 2nd and received in this list 3rd. I think that the review manager should not encourage the reviewers to send the reviews to himself. This will avoid this kind of delays. So I purpose that only the reviews sent to this single mailing list must be taken in account. Yes, this particular delay is entirely my fault. I can't explain why I didn't notice this email until so late (which is the point where I contacted the poster notifying him I would like to forward the mail, and forwarded it the following morning). Allowing reviews to be sent to the review manager is straight from http://www.boost.org/community/reviews.html (Introduction paragraph). There are two valid reasons for this, IMO: * the reviewer is only subscribed to one of {boost, boost-user, boost-announce} lists, and would like the reviewer to be forwarded to both boost and boost-user lists (if there was a dedicated review list, like you suggest, that was also open to all posters, then this reason would go away) * the reviewer would like to remain anonymous to the list (granted, this could also be accomplished by sending from an anonymous e-mail). If this stays as it is, the RM should be more diligent about monitoring her personal mail, which I apparently wasn't. > > * Even if the review was over the 10th there were 2 accepting reviews comming from the commiting reviewers just some hours before the review result annoncement 19th. I think that the review manager must state clearly when the review is over and do not accept any review after. This do not means that the RMcannot change this date, but annnce it clearly. I tried to keep my timeline as transparent as possible. In my review-closing email, I asked people to let me know if they were considering writing a review. Those that contacted me were informed of the timeline of pending reviews. When the last promised review was submitted, I set a hard deadline. Given the uncertainty in people's schedules, I decided to approach this in a flexible way. That was just my personal preference - I'm sure setting a hard deadline earlier would have been a fine choice as well. > > I hope this will help to improve future reviews, > Thanks again for starting this discussion and for your suggestions - I also hope good improvements will come out of it. Stjepan

5 8

Re: [boost] Asking for feedback for book (in German) about the Boost C++ libraries
by Boris 19 Dec '08

19 Dec '08

On Mon, 15 Dec 2008 02:30:16 +0100, Jeff Dunlap <jeff_j_dunlap(a)yahoo.com> wrote: > Wow, you cover alot of libraries and I like the examples! Will it be > written in English too? Thank you! Currently I've no plan to translate the book. I'll add more chapters to cover more Boost libraries though. As this is already quite a lot of work another volunteer needs to translate. ;) Boris > [...]

2 3

Re: [boost] [uuid] Interface
by Vladimir Batov 19 Dec '08

19 Dec '08

>> ... > No. The input iterator constructs from the raw octets, expecting them > as in 4.1.2. Layout and Byte Order Well, I obviously confused the construction from a string and the construction from the raw octets. Quite embarassing. My mind is obviously already chasing that Christmas goose. > I'm still not convinced that that providing the default constructor is > such a bad thing, so I would still like Andy's #define to allow it. I'd like the default constructor as well. Very much in fact. The problem is that our expectations of what that constructor needs to do are quite different. The behavior of the default constructor that you'd like to see (apologies if I got it wrong) is to create an invalid uuid. I feel that is not the canonical use of the default constructor. Indeed, that usage of the default constructor *not* to actually create an object has become quite popular. It does not make it right though. I find it unfortunate and hackish. I feel that the default constructor should indeed construct... with all the default "parameters"... as the language prescribes... as other constructors do. In uuid context it'd be to let the OS/infrastructure decide what is best. That way we'd achieve the best portability without sactificing the quality and I am sure for that reason it'll be the most popular deployment. That's why I'd like that behavior assigned to the simplest available (default) constructor. I do not want to be forced to choose a certain generator just to discover it is not supported on another platform. Having said that I do not see my view getting far. In that case, I'd prefer not to have the default cnstr at all as IMHO it sends the wrong message and enforces the wrong programming practice. Just my view, of course. OK, I guess, it is indeed time for me to tune out and get into that Christmas spirit. Happy Christmas and Happy New Year everyone (pick whichever appropriate). Best, Vladimir.

3 2

accumulators + complex
by Neal Becker 19 Dec '08

19 Dec '08

I'm interested in 2nd order stats for complex numbers. typedef std::complex<double> complex_t; typedef accumulator_set<complex_t, stats<tag::mean, tag::moment<2> > > acc_t; 2 issues: 1) Need template<typename flt_t> inline std::complex<flt_t> operator/ (std::complex<flt_t> const& a, unsigned long int b) { return std::complex<flt_t> (real (a)/b, imag (a)/b); } 2) What do I get for moment<2> in the case of complex (and does this match the usual mathematical definition?)

2 3

[accumulators] misprint in accumulators users guide
by Neal Becker 19 Dec '08

19 Dec '08

The example under 'Defining a New Feature' says: typedef impl::mean_accumulator< mpl::_1 > impl; I think it needs to say: typedef accumulators::impl::mean_accumulator< mpl::_1 > impl;

2 1

interest in properties library
by Daniel Oberhoff 19 Dec '08

19 Dec '08

Hi, I am thinking about submitting a library proposal and would like to query wether there is any interest in such a library and chance of success of such a proposal. The basic idea is to implement the possibility to decorate a class with named properties, such that given a pointer to an instance properties can be accessed by name rather than using set/get methods. Also the type of the instance should not need to be known at compile time, other than that it derives from a suitable base class describing the property mechanisms. There is a rough implementation existing and used in a product environment. Setting and getting is done using appropriate boost functions. Type resolution is done using RTTI (especially dynamic cast). Complex inheritance hierarchies are supported through virtual inheritance from the base class, such that several classes along the hierarchy can contribute property slots. CRTP and static initialization is used to register properties. Convenient setter/ getter function generators are provided as is a mechanism to access nested properties using dot notation. I would very much like to put this work into the community as I think it will only make it better, plus I want to give back to boost since it has been a lot of help to me and still is. Best Daniel Oberhoff Fraunhofer FIT Schloss Birlinghoven St. Augustin Germany

2 1

[Msm] New version available
by Christophe Henry 19 Dec '08

19 Dec '08

Hi, Santa was a bit early this year and he just brought into the vault (http://www.boostpro.com/vault/index.php?direction=&order=&directory=Msm&) the new version of Msm, 1.10. You will find inside support for: - explicit entries - fork - entry pseudo states - exit pseudo states - conflicting transitions And a few bugfixes. It lasted a while, but I hope you will have fun with it. I will be thankful for any comment I will get. Cheers, Christophe

1 0

Asking for feedback for book (in German) about the Boost C++ libraries
by Boris 19 Dec '08

19 Dec '08

I've written a book in German about the Boost C++ libraries and uploaded it to http://www.highscore.de/cpp/boost/. As this is the very first version it's currently only available in HTML. I would appreciate any feedback about the content, presentation, examples, typos :) etc. Thanks, Boris

3 4

Re: [boost] [uuid] Interface
by Vladimir.Batov＠wrsa.com.au 19 Dec '08

19 Dec '08

>> Great in theory, but I think it'll break >> lexical_cast<uuid>("21f7f8de-8051-5b89-8680-0195ef798b6a"), since the >> lexical_cast wants to default-construct the target type into which it >> will read. Yes, the default lexical_cast behavior requires the default constructor. Having said that I've been routinely specializing lexical_cast to optimize away the overhead. Something like namespace boost { template<> inline std::string lexical_cast<std::string> (std::string const& v) { return v; } template<> inline std::string lexical_cast<std::string> (char const* const& v) { return v; } template<> inline std::string lexical_cast<std::string> (bool const& v) { return v ? "yes" : "no"; } } If we do that for boost::uuid, then the user gets the familair interface and we have our class clean and minimal. Having said that I am honestly unsure about uuid id = lexical_cast<uuid>(str); as it seems already covered by template<typename InputIterator> uuid(InputIterator, InputIterator); I certainly want the explicitness of "string str = lexical_cast<string>(id);" though. Still, keeping the bidirectional nature of lexical_cast is probably important for the user. Therefore, I'd *probably* have namespace boost { template<> inline boost::uuid lexical_cast<std::string> (std::string const& v) { return boost::uuid(v.begin(), str.end()); } } >> template <typename ByteInputIterator> >> uuid(ByteInputIterator begin, ByteInputIterator end); Can we take it one step further and replace it with a more generic: template<class ForwardReadableRange> uuid(ForwardReadableRange const& range) { typedef typename boost::range_iterator< ForwardReadableRange >::type Iterator; Iterator begin = boost::begin(range); Iterator end = boost::begin(end); ... the rest is the same. } That way uuid id(string) is supported without the need for an explicit "uuid::uuid(string const&)" constructor as other containers as well. >> > // valid expression >> > // generator() - result type must be convertible to a uuid >> > template <typename Generator> >> > explicit uuid(Generator & generator); I feel that the "generator() - result type must be convertible to a uuid" requirement is somewhat excessive. Given the rest of the code it results in a generator having to know and even be able to create boost::uuid. That seems like an unnecessary coupling. I think generators should know *nothing* about uuid and certainly *not* create those. Instead, the generators should provide the necessary *ingredients* but it'd be uuid (well, its uuid(generator) constructor) actually creating an uuid instance. That might be as straghtforward as template<class Generator> uuid(Generator const& gen) { std::pair<Iterator, Iterator> range = gen(); ... something that uuid(begin, end) or uuid(range) does. } That way, the requirements for a generator are looser as all it needs is to provide a range. More so, the design maintains the locality of uuid creation and destruction -- those are created and destructed in the conventional way, i.e. by the uuid constructor and destructor (rather than created by a generator but destroyed by the uuid::~uuid()). As Scott noted template<class Generator> uuid(Generator const& gen) constructor is somewhat redundant. However, I'd personally like to keep it as it communicates to the user one of the main ways of creating a uuid. >> bool is_nil() const; >> operator unspecified_bool_type() const; // return !is_nil(); It's a minor point but I'd ask whay we need both? The reason I greatly favor "bool" converter is that it is idiomatic and does *not* introduce a new vocabulary. That is important from the usability point of view as any new vocabulary is obviously only usable *after* one learnt it. Why ask the user to learn something (like "is_nil") if he can get by without? Thanks, Vladimir.

2 1

[swap] How to fix ADL barrier for XL, Intel, GCC, Sun and Como?
by Niels Dekker - mail address until 2008-12-31 19 Dec '08

19 Dec '08

The boost::swap utility from Joseph Gauterin has an ADL barrier against infinite recursion or ambiguity, as recommended by Steven Watanabe and David Abrahams, last year at the mailing list: "Re: [boost] Koenig lookup swap." http://lists.boost.org/Archives/boost/2007/08/125938.php Last Friday I added "test_adl_barrier" to test this ADL barrier. Unfortunately it fails on many compilers, including XL (AIX), Intel (version 9 and 10), GCC, Sun and Como: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html While I usually use MSVC, and for that specific compiler, the ADL barrier appears successful! Do you know how to fix the ADL barrier for the other compilers? I'm afraid we'll need to have #if BOOST_WORKAROUND statements in there... FYI, the boost::swap utility is at: http://svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp The ADL barrier test is at: http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/test_adl_barrie… Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

5 26

Single letter template type causes errors in compile of program_options and filesystem boost libraries
by Mike Collier 19 Dec '08

19 Dec '08

Hi, Problem lIbraries: program_options and filesystems Version: Release 1.37.0 System: Mac OS X 10.5.6, Red Hat Linux Enterprise 4, Red Hat Linux Enterprise 3 Compiler : gcc 4.0 and gcc 3.3 I have just started trying to use the boost libraries. I tried starting with program options and filesystem. Unfortunately both of these do not compile in my environment because of the use of single letter variable and template types. For example in alignment_of.hpp the template: template <unsigned A, unsigned S> struct alignment_logic { BOOST_STATIC_CONSTANT(std::size_t, value = A < S ? A : S); }; causes error and in operators.hpp the template: // Import a 3-type-argument operator template into boost (if necessary) and // provide a specialization of 'is_chained_base<>' for it. # define BOOST_OPERATOR_TEMPLATE3(template_name3) \ BOOST_IMPORT_TEMPLATE3(template_name3) \ template<class T, class U, class V, class B> \ struct is_chained_base< ::boost::template_name3<T, U, V, B> > { \ typedef ::boost::detail::true_t value; \ }; causes errors. The errors are the result of using single letters for variables or template types. The reason for the errors is in my compile environment ( electrical engineering related ) defines are used for the convenience of writing units in code. These defines exist in a vendor supplied header in my project: #define A #define V #define W #define s #define S #define J among many others to denote units ( in these defines the units are Amps, Volts, Watts, Seconds, and Joules ). These defines come from the vendor of the software I am using and can't be easily changed. I believe the correct change is to use longer names for variables and template types in the boost library headers, which means changing the boost library headers. I can do this locally in my copy of the headers, but it seems to me a better design is to use longer names in the boost libraries in first place. I don't see any benefit to using the single letter names in the boost library headers. Does anyone have other solutions to this problem or know of reasons why single letter variable and template type names are used in the boost libraries? Thanks, Mike

6 9

[test][doc] non-working link
by Rutger ter Borg 19 Dec '08

19 Dec '08

Dear Gennadiy, the link in http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/utf/intro.html to "collection of examples", pointing to http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/example-toc.html, seems to be broken. Kind regards, Rutger

3 2

Unit Test Framework - strange behaviour of test_unit::depends_on
by Me here 19 Dec '08

19 Dec '08

Hi there, Why the code below does not run test case TC_TestCase and reports that the whole test suite is skipped? Nothing is executed from my code. If the line /*1*/ is commented out, then behaviour is as expected. I use MSVC 2008 SP1 Win32, boost 1.36.0 or boost 1.37.0. I have to admit that test_unit::depends_on is not documented. Unit test framework is changed in 1.37.0 but changes are not documented anywhere. Regards, Alexander ----------- code in question ------ #include <boost/test/included/unit_test.hpp> using boost::unit_test::test_suite; void Dependency() { BOOST_MESSAGE( "Dependency!" ); BOOST_CHECK( 1 ); } void TC_TestCase() { BOOST_MESSAGE( "A test case!" ); BOOST_CHECK( 1 ); } test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* ts = BOOST_TEST_SUITE( "Test_Test" ); ts->add( BOOST_TEST_CASE( &TC_TestCase ) ); /*1*/ ts->depends_on( BOOST_TEST_CASE( &Dependency ) ); return ts; } -------- end code in question ------ ------------ output ----------- Running 1 test case... Entering test suite "Master Test Suite" Test suite "Test_Test"is skipped Leaving test suite "Master Test Suite" *** No errors detected ---------- end output -----------

2 1

[release][website] updating info
by JOAQUIN M. LOPEZ MUÑOZ 18 Dec '08

18 Dec '08

I've just added a new library (flyweight) to the release branch and I have a couple of questions regarding the associated update of website material: Where can I find the Version 1.38.0 news entry to add the blurb for the new lib? Is it my responsability (as the author of the new lib) to update public_html/beta/doc/libraries.xml, or public_html/live/doc/libraries.xml, both or none? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

building boost (regex) in mingw
by Lorenzo Bettini 18 Dec '08

18 Dec '08

Hi I'm trying to install boost regex library under mingw but I can't seem to succeed... the simple configure way does not work I've also tried bjam --build-dir=./tmp --toolset=gcc stage --with-regex but this does not create .a .so files, but only .lib files that I cannot use with mingw compiler... any help please? thanks in advance Lorenzo

3 17

[interprocess] Suspicious code in detail/segment_manager_helper.hpp
by Markus Schöpflin 18 Dec '08

18 Dec '08

Hello, this file contains at line 384 the following method of index_data: void *value() const { return static_cast<void>(detail::get_pointer(m_ptr)); } Either the declaration of the return value or the cast seems to be wrong. Markus

1 1

Re: [boost] [utility/swap] Internal compiler error Siliconmanborland-6.10.0 (CodeGear?)
by Niels Dekker - mail address until 2010-10-10 18 Dec '08

18 Dec '08

David (siliconman) wrote: > It had already been logged when I got to looking: > <http://qc.codegear.com/wc/qcmain.aspx?d=68959> Thanks, David. I've been searching through qc.codegear.com before, but I hadn't found it. I guess I just chose the wrong keyword to search for, e.g., "template", and "Fatal F1004". BTW, I decided to submit the report myself, because I don't have access to borland-6.10.0. As far as I know, it isn't available for free. (I do have the free Turbo C++ 2006 Explorer installed, though.) If I had access to borland-6.10.0, I would have tried to make a smaller test program to reproduce the internal compiler error. Because I wonder if it is specific to the current implementation of the boost::swap utility... Please let me know if you have any suggestion for boost::swap (or its specialized_in_std.cpp test) to work around the compiler error. Kind regards, Niels PS Your replies don't appear on the mail archives: http://lists.boost.org/Archives/boost/2008/11/index.php http://thread.gmane.org/gmane.comp.lib.boost.devel/182214 Is that intentional?

2 6

[detail/lightweight_mutex] Win32 threading selection in boost/detail/lightweight_mutex.hpp
by joaquin＠tid.es 18 Dec '08

18 Dec '08

Hello, This is a followup of a discussion we had some time ago: http://lists.boost.org/Archives/boost/2007/09/127115.php Lines 31-40 of boost/detail/lightweight_mutex.hpp read like this: #if !defined(BOOST_HAS_THREADS) # include <boost/detail/lwm_nop.hpp> #elif defined(BOOST_HAS_PTHREADS) # include <boost/detail/lwm_pthreads.hpp> #elif defined(WIN32) || defined(_WIN32) || defined(__WIN32__) # include <boost/detail/lwm_win32_cs.hpp> #else // Use #define BOOST_DISABLE_THREADS to avoid the error # error Unrecognized threading platform #endif I think the conditions for selecting boost/detail/lwm_win32_cs.hpp are suboptimal because they're ruling out the case where the user's disabled Pthreads in cygwin/mingw by explicitly defining BOOST_HAS_WINTHREADS, a case covered by boost/config/platform/cygwin.hpp: in such a situation, Win32 threading is available but none of WIN32 and similar are defined by default (unless <windows.h> has been previously included, which makes boost/detail/lightweight_mutex.hpp context dependent). Wouldn't it be better to change the selection code to the following? #elif defined(BOOST_HAS_WINTHREADS) # include <boost/detail/lwm_win32_cs.hpp> #else Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[serialization] serializing std::string*
by Zach Laine 17 Dec '08

17 Dec '08

It appears that std::string* is not serializable. I have need to serialize them, and I'm considering adding the old, unused code in boost/serialization/string.hpp (the stuff #if 0-ed out and marked with "left over from a previous incarnation - strings are now always primitive types") to serialize std::string*'s. I have 2 questions before doing so. 1) What is the rationale for making std::string a primitive, track_never type? After an extensive rereading of the docs, I'm left with only a hazy understanding of what the implications are for primitive vs. non-primitive status. 2) Can Robert (or anyone else) give me a sense for how likely I am to get myself into trouble doing this? If it matters, I don't need to be able to read old archives containing std::string's. Thanks, Zach Laine

2 4

[date_time][graph] Merge required
by Steve M. Robbins 17 Dec '08

17 Dec '08

Hi, The enclosed trivial fixes have already been applied on the trunk some time ago but were never merged. Could someone please merge changesets 47957 (date_time) and 49000 (graph)? --- boost-posix-2008-03-21.orig/boost/date_time/time.hpp +++ boost-posix-2008-03-21/boost/date_time/time.hpp @@ -77,14 +77,14 @@ /*! Optional bool parameter will return time zone as an offset * (ie "+07:00"). Empty string is returned for classes that do * not use a time_zone */ - std::string zone_name(bool as_offset=false) const + std::string zone_name(bool = false) const { return time_system::zone_name(time_); } /*! Optional bool parameter will return time zone as an offset * (ie "+07:00"). Empty string is returned for classes that do * not use a time_zone */ - std::string zone_abbrev(bool as_offset=false) const + std::string zone_abbrev(bool = false) const { return time_system::zone_name(time_); } --- boost-posix-2008-03-21.orig/boost/graph/topological_sort.hpp +++ boost-posix-2008-03-21/boost/graph/topological_sort.hpp @@ -37,7 +37,7 @@ : m_iter(_iter) { } template <typename Edge, typename Graph> - void back_edge(const Edge& u, Graph&) { throw not_a_dag(); } + void back_edge(const Edge&, Graph&) { throw not_a_dag(); } template <typename Vertex, typename Graph> void finish_vertex(const Vertex& u, Graph&) { *m_iter++ = u; } Thanks, -Steve

2 3

Re: [boost] [Boost-users] [non Boost] Template troubles.
by Robert Jones 17 Dec '08

17 Dec '08

On Fri, Dec 12, 2008 at 5:52 PM, Noah Roberts <roberts.noah(a)gmail.com>wrote: > Noah Roberts wrote: > Neil, Noah, Kim - Thanks all for your input. Although no perfect solution has emerged it is always good to see a few good minds looking at it. - Rob.

3 2

Re: [boost] New XML library
by Themis Vassiliadis 16 Dec '08

16 Dec '08

> > On Tue, 09 Dec 2008 22:05:55 +0100, Themis Vassiliadis > <tvassiliadis_at_[hidden]> wrote: > >> Hi, >> >> I have been working in a C++ library like Apache Digester >> (http://commons.apache.org/digester) I'm intending to convert it >> following boost policies described in Requirements and Guidelines. >> >> What are the chances of it become a Boost library ? > > Is your digester a XML library or built on top of a XML library? > > Boris > I have made something really basic to parse xml. I have just started but if I could use XERCES I would save a lot of time. Boost's polices accept it ? Regards, -- Themis Vassiliadis

3 3

[repost][release][flyweight] permission for merging to release
by Joaquin M Lopez Munoz 16 Dec '08

16 Dec '08

Hello, reposting this to gain some release manager's attention... 1.38 release rules say I have to be given explicit to merge a new library into release and the deadline for doing that is Dec 20th... Hello, I hereby request permission to merge Boost.Flyweight into the release branch in time for Boost 1.38: Docs: http://tinyurl.com/6jvfss Trunk test results: http://tinyurl.com/6ogxkt Trunk test results are satisfactory to me (many yellow cells are actually due to environmental problems with the regression testers, or else correspond to plain broken testers). I don't foresee any complication in the merging process. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0