- Boost - lists.preview.boost.org

[interprocess] A little gentle criticism
by Tom Brinkman 22 Nov '08

22 Nov '08

>> Please Boost developers, C++ programmers deserve not to deal with C-style strings anymore. With all respect, this is not a view that I share. I'm a c++ developer who prefers C-style strings. Most of the coding standards on C++ projects that I have been on over the last 10 years or so have discouraged using C++ string wrappers. This hasn't changed recently from what I can see. I rarely if ever use std::string or std::basic_string. Many C++ developers still prefer C style string handeling. Tom

2 1

Maintenace Guidelines wiki page
by vicente.botet 22 Nov '08

22 Nov '08

Hi, I have started the Maintenace Guidelines wiki page. You can access it directly https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines or via https://svn.boost.org/trac/boost/wiki Guidelines * Maintenance Guidelines There page need to be completed and surely reworked but this is an starting point. Please be free to improve the page directly or post your comments or suggestions to this list. Hopping this goes on the right direction, Vicente

1 0

[quickbook] Problem integrating doxygen style examples into quickbook
by Joachim Faulhaber 22 Nov '08

22 Nov '08

Hello, I successfully installed the quickbook toolchain and I am joyfully using the tool to write docs for my library. (Thank you, to the authors:-) One of the things I like is the doxygen integration. But I have encountered a problem here: I guess my problem is a typical one that other authors might share. I already have example files that are using doxygen style documentation. The documenting texts are in the example file so it's easy to maintain: ----------- boost_party.cpp --------------------- /** Example boost_party.cpp \file boost_party.cpp Text documenting this example using <em>doxygen</em> style formatting features. ... Finally there is an include command that allows to insert the example code to this introductory text: \include boost_party/boost_party.cpp */ #include <boost/.../some.hpp> class to_be_documented { ... } ... //more code -------------------------------------------------- Now I would like to recycle text and code for quickbook such that (1) Text and code can stay in the example file. (2) Text and code don't have to be replicated some place else (e.g. in example.qbk). (3) There is only a minimal additional formatting noise, so the example file itself stays readable. What I've learned so far is to bring the code (or snipplet parts of it) into quickbook: ... //[example_boost_party #include <boost/.../some.hpp> class to_be_documented { ... } ... //more code //] But how to handle the text part? Cheers Joachim

1 0

[interprocess] A little gentle criticism
by Edward Diener 22 Nov '08

22 Nov '08

First of all I really appreciate the interprocess Boost library for its rich set of synchronization primitives and shared memory techniques. Now to my gentle ( maybe not so gentle ) criticism. What was the reason for using C-style null-terminated strings in much of the functionality rather than std::basic_string ? Isn't it about time, in the advanced C++ libraries of today, that we should wean ourselves aay from C-isms, which no C++ programmer, unles on pain of supporting hopelessly legacy style code, has not used in years and years ? To see constructors taking C-style strings rather than std::basic_string in a modern C++ library like interprocess is a real psychological disappointment. At the very, very least, the author of the library should have also provided the equivalent functionality with std::basic_string. Please Boost developers, C++ programmers deserve not to deal with C-style strings anymore. Personally I do not think anything new coming out of the C++, including the C++ standard committee, should have any functionality taking a 'const charType *' from now to to the end of C++ eternity <g>. Other than the above I really enjoy using interprocess and say bravo to the author of the library for a well thought out implementation. But how this C-ism got by the reviewers I will never know.

2 1

[unicode] Interest Check / Proof of Concept
by James Porter 22 Nov '08

22 Nov '08

Over the past few months, I've been tinkering with a Unicode string library. It's still *far* from finished, but it's far enough along that the overall structure is visible. I've seen a bunch of Unicode proposals for Boost come and go, so hopefully this one will address the most common needs people have. The library is based on two (immutable) string types: ct_string and rt_string. ct_strings are _C_ompile _T_ime tagged with a particular encoding, and rt_strings are _R_un _T_ime tagged with an encoding. This is to allow for faster conversion when the encoding is known at compile-time, but to allow for conversion at run-time (useful for reading XML!). General usage would look something like this: ct_string<ct::utf8> foo("Hello, world!"); ct_string<ct::utf16> bar; bar.encode(foo); rt_string baz; baz.encode(bar,rt::utf8); Note the use of ct::utf8 and rt::utf8. As you might expect from the syntax, ct::utf8 is a type, and rt::utf8 is an object. Broadly speaking, to create an encoding, you create a class with read and write methods, and then you create an instance of an rt_encoding<MyEncoding>. Most of this is laid out in the comments of my code, so I won't go into too much detail here. There's still a lot missing from the code (most notably, dynamically-sized strings and string concatenation), but here's a rundown of what *is* present: * Compile-time and run-time tagged strings * Re-encoding of strings based on compile-/run-time tags * Uses simple memory copying when source and dest encodings are the same * Forward iterators to step through code points in strings If you'd like to take a look at the code, it's available here: http://www.teamboxel.com/misc/unicode.tar.gz . I've tested it in gcc 4.3.2 and MSVC8, but most modern compilers should be able to handle it. Comments and criticisms are, of course, welcome. - Jim

11 20

[lambda][test] _set_se_translator() requires /EHa
by David Walthall 22 Nov '08

22 Nov '08

I was looking at one of the failures on vc 7.1 and noticed that there was the following warning: ..\boost\test\impl\execution_monitor.ipp(825) : warning C4535: calling _set_se_translator() requires /EHa the command line options /EHc and /GX are insufficient See: http://beta.boost.org/development/tests/release/developer/output/daw-msvc71… or: http://tinyurl.com/5osfqr Is this a spurious warning, or is really an issue? Thanks, David

3 3

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

> I have no problem with any of that. However, I would like you to > acknowledge that I *did* in fact address what you wrote, whether or not > it was what you wanted to hear. I acknowledge that you addressed what I wrote. > I'm not sure how. Would the "new" code that results from reviews have > more immediate relevance to you than it does now, in such a scheme? Yes - that's the whole point! People are not afraid to beta test when they know the code is beta/pre-release. People will be more likely to review code and participate if they know they can use it in the near-term future. People who save themselves the effort of having to invent their own (probably inferior) version of a library from scratch will also be more likely tolerate changes in the early stages. At the end of the day, most of our users are library users, not library writers. They just want to get their app up and running. Increasing your pre-release user and test base can only make the library better and applicable to more domains. One of the best things for me when working in library development was learning how people use my libraries in scenarios I haven't even thought about. Also, more participation early in the development process will give the user base a stronger sense of ownership and hence more desire to be involved. I can't tell you how often people here ask for the new libraries, only to be shot down because they are only available from release X onwards, where X > where we are now. And when I say people ask for the new libraries, I do really mean ALMOST EVERY SINGLE library that came in since 1.33.1. > >> > However, it seems that once a library is accepted, the maintainer > is > >> > pretty much free to do what they please. > >> > >> Yes. > > > > I hope behind this simple "Yes" there are alarm bells going off. > > Not really. I understand the risks and tradeoffs of that arrangement, > and I think Boost made the right choices there. IMO what's needed is > more structure to support the maintainer in making good decisions. But you also need the maintainer to actively engage the system when deciding to make drastic changes. In the Boost.Range case, it wasn't the failure of the boost.devel mailing list. The changes seem to have been made without any communication whatsoever. > I know at least one instance where breaking changes were discussed > (handling of NTBS's): > http://www.nabble.com/-Range--Expected-complexity-constraints- > tt4279749.html#a4279749 And that's the right thing to do. However, I can't find any references to indicate that the behavior of ranges is about to change in 1.35. > Yes. And as as I said, such policies often are used for *all* > dependencies because people have been burnt by *something* that may or > may not have been Boost in the past. Sure - but most other libraries we use are not the basic building blocks of most C++ applications and our entire software stack! Almost every C++ app will have use for things such as Boost.SharedPtr and Boost.Iterators but they don't all need e.g. a rule based engine. As such, boost tends to be a global dependency while other libraries are much more localized. Breaking and backing out a single application because of a broken dependency is not a big deal. Backing out and rebuilding all of the applications in the firm is a big deal. > <snaps head around> What proposal? I don't know if you're just playing with words here or not. It wasn't a "proposal" in the sense of a written document which is suitable for submission to the C++ committee. I was referring to the idea of the different release cycles for the "core" and "new" components. Tom

1 0

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

-----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of boost-request(a)lists.boost.org Sent: Thursday, November 20, 2008 5:42 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 2373, Issue 4 > Yes, this is an unfortunate situation. If you indeed want to try to > make sure this kind of silent breakage doesn't happen again, there's > something you can do about it: write a page of library maintenance > guidelines on the wiki at http://svn.boost.org. We are sorely missing a > policy on this, and when less-experienced library authors come along, > they often don't hew to the same standards that many of us take for > granted. If you don't have write permission for the wiki, please let us > know and we'll send you an invitation. Hello Dave, This is a good answer but not the one I was looking for. It's a politician's answer, in that it doesn't really answer my original query. Let me just put a few of my thoughts here: What was described in my original email are bad practices in any project, not just boost. Given that the boost developers are presented frequently as "the best", it isn't unreasonable to expect that they would understand that causing silent breakage (and the other points I made) is bad. It takes a lot of work for a library to get accepted and the library has to meet very high standards. However, it seems that once a library is accepted, the maintainer is pretty much free to do what they please. I think it may be wise to apply the same level of rigour to the continued development. Do you think that a boost library that was broken should be rolled back? About the wiki: The desire to solve this problem has to come from within, not from without. Given how big some of the personalities are on this mailing list, do you think it's likely they would listen to someone who has not contributed a complete library to boost? Finally, I'd like to mention that within a large organisation, it's not possible to upgrade to the latest version of boost as soon as it comes out. The difficulty of rebuilding all of the internal systems just makes this impractical. As you are aware, a lot of people avoid the .0 releases. What does this say to you? I understand (and applaud) boost's efforts to try to to eliminate this notion with tighter release cycles etc but the problem is that it's much harder to lose people's confidence than to regain it. I like using boost and am very grateful to all the developers who make it happen. Having said that, SNAFUs such as the current Boost.Range or the MT problem with Boost.Function in 1.34 threaten to make it irrelevant in "serious" development and relegate it to the position of a great "toy library" you can see how C++ standard compliant your compiler is. Kind regards, Tom

2 3

[test] minor spelling problem in docs
by Thorsten Ottosen 21 Nov '08

21 Nov '08

Look at http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/tutorials/new-year-… It is full of BOOST_AUTO_EST_CASE( constructors_test ) ^^^^ -Thorsten

2 1

[test] test tools for ranges - where are they?
by Thorsten Ottosen 21 Nov '08

21 Nov '08

Hi G, I couldn't find these in trunk anywhere. I thought these where added long time ago. Am I looking the wrong place? Thanks -Thorsten

2 1

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

> The key issue is: You did not pay for what you use. I am sorry to disagree but this will not solve anything. The fact is that we use other open source projects where we pay for support and the supporting organization still doesn't guarantee that nothing will break. The moment they tried, the other people would branch off the code. There has to be an agreement among the developers themselves and commitment to quality of implementation. >> The Good News (TM) is that you can pay for it now: People at >> boost-consulting can help you with your problem within a week or so >> (middleman fees to me, please ;-)). > I'll see if there's something we can do ;-) So can we pay you to roll back Boost.Range? ;) (This doesn't constitute an offer to buy or sell or do anything) >> But let us go back on the we-do-not-pay-for-it path: >> IMHO it is a severe error of your development process that you do not >> check your code with new versions of all compilers and all libraries on a >> *regular* basis. >I agree that testing needs to be made more regular and thorough. >However, IMO the universe of compilers and libraries is much too large >--- and in some cases, the software is too expensive --- for us to check >code with new versions of *all* compilers and *all* libraries. We need >to select a subset against which we'll test. Agreed. I think in general boost is very good at this and I feel developers are fairly happy to contribute back any changes to make boost work on a particular compiler. This issue is not about my code not compiling - my code compiles, it just does something completely different. No amount of compiler testing will show up this bug. As a potential middle-road (and given the size of boost now), one possible way forward would be to break up boost into a "stable" and "new" branches. Our developers frequently want to use some new library from boost. Unfortunately, since boost is always rolled out as a big package, this is not possible because as I've mentioned before, doing an entire re-release of all internal libraries built on new boost is non-trivial, along with the fear that some major component (such as boost::function) was been broken. However, if there was a "stable" boost platform to which we could add new libraries without worrying about breakage/incompatibility, we would be far more likely to bring in new libs. In return, boost would get additional testers, not to mention that I think some of the preconceptions about instability would be alleviated. Furthermore, it may become unnecessary to have frequent point releases, as people could just get "stable" and then a "latest tested" snapshot of the libraries they need or of the "new" branch. It would be necessary to decide what "new" and "stable" means; I'm sure the core could be decided fairly easily (and the fringes will be argued forever). Then what is needed is a policy on how a component becomes "stable" as opposed to "new" (e.g. 1/2 years in production). All changes to "stable" have to go through a review and cannot be brought in a single release - they must be deprecated and a migration path provided. I'm not saying this is easy. Just a few thoughts I'm having. Tom

2 1

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 21 Nov '08

21 Nov '08

On Fri, Nov 21, 2008 at 2:06 AM, Robert Jones <robertgbjones(a)gmail.com> wrote: > On Fri, Nov 21, 2008 at 6:40 AM, vicente.botet <vicente.botet(a)wanadoo.fr> > wrote: >> >> * 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. >> > > A specific maillist for reviews strikes me as an excellent idea. In Joels' > review > of his Phoenix 2.0 library there were some outstanding contributions from > people I don't see posting very often, but who apparently feel moved to do > important stuff like reviewing. These comments did much to give me some > historical context, and understanding of structure, alternatives and > implementation > decisions. These will inevitably be lost in the general background noise of > on going developments, and it would be nice to have a clear place for these > review comments. > Perhaps it would be sufficient to *strongly stress* that any post related to the ongoing review should have [review] in the subject line? (although that doesn't address the problem of having the review on both the dev and user lists...) Stjepan

1 0

Re: [boost] Breaking existing libraries
by Tomas Puverle 21 Nov '08

21 Nov '08

Hey Stephen, This is a extremely well written and reasoned post and I can't help but I agree with every point you made. > As for breaking existing use cases, this will cause us to stay at the > last release that meets our needs until the beginning of a new major > release cycle on our side, unless there's some other feature that > compels us to deal with the breaking change mid-cycle. In my previous position, I worked in the firm's infrastructure group, where we wrote and maintained libraries that were the "standard library" of the firm on which other apps/libraries were built. Given the size of the user base (in the thousands), it is simply unthinkable to rebuild the world because of a new release of boost. The current version is 1.33.1 and that's unlikely to change for a while. Finding debilitating bugs/changes in a new release makes people even less likely to want to move. This is bad for boost, too, as you lose not only direct boost users/testers, but also the feedback that developers send back to their compiler/standard library vendors. > Open-source status gives you champions in the development pit > but it doesn't change management's priorities. Nor should it make one forget that even though grateful for your efforts, there's only as much pain as people are willing to go through. Tom

1 0

Re: [boost] Breaking existing libraries
by Stephen Nuchia 21 Nov '08

21 Nov '08

> FWIW, if you're a Windows/MSVC user, then building fresh Boost > release takes about 5 mins of human work, and > boost-build(a)lists.boost.org can provide assistance if anything goes wrong. Because of the way the MSVC STL is implemented, we have to make sure the compiler options (specifically, the one disabling iterator checking in release-mode builds) match. We also want the WPO/PGO and some other settings to match. And we need to be able to change those settings globally in a build to accommodate, for instance, Compuware's code analysis tools that don't run when you enable too much optimization. So we build the compiled boost libraries we are using as part of our product build. Avoiding ODR (one-definition rule) violations is hard. Avoiding them across the MSBuild / boost build chasm is very hard. NP-annoying hard, not NP-hard hard. But hard enough. The one-on-one help you provide, Vladimir, has been of great value. I admire your energy and your dedication to the task. But I'd also like to have a design and documentation that doesn't require an entire semester of study to reach the level where I have some idea why one syntax works and another doesn't. MSBuild is no better. I have to be able to get work done in both. Sigh. -swn

2 1

[endian] cooperation with iostream
by Rutger ter Borg 21 Nov '08

21 Nov '08

Dear Beman, In my recent work on the zoneinfo database for the date_time library, I have tried the current endian-0.8 from sandbox in order read big endian data. I had partial success. Although I see a working example based on the cstdio function calls, I am primarily using an ifstream to read a binary file. I haven't been able to figure out on how to get ifstreams working in combination with big endian types. (By the way, perhaps in conjunction with iostreams, it would be nice if std::ios::big_endian would exist, and be done with it?) Is it possible to use the endian library in combination with bniary iostreams? If so, would it be possible to give an example on how that should look like? Thanks, Kind regards, Rutger

2 2

Re: [boost] Breaking existing libraries
by Stephen Nuchia 21 Nov '08

21 Nov '08

I can address this from the commercial user's point of view. I have a long history in open source and am currently working for a well-established Windows-only ISV. Boost has its own way of doing things that is poorly coupled into my environment. Adapting a new release of boost into my build scripts to evaluate it is painful and time-consuming. I have my own release cycle that has periodic windows for non-emergency updates of tools and other third-party components. If your two-week beta period happens to fall in that interval I'm likely to work with it, otherwise it's going to be whatever is stable. We have close to five million lines of our own code, a dozen or so third-party libraries of all descriptions, tools from several different vendors, and we test against every Windows version since NT4. If there were a well-maintained cookbook for testing the beta against my build I'd give it some attention. But it took me a week of pulling my hair out over the bjam / boost build documents to get it wired into my build the last time I upgraded. I'm not looking forward to doing that again, and my boss has other ideas about how I should spend my time -- up to the point where we need something from the new release. Having worked the beta cycle from both sides in the commercial software world, I can tell you it never works very well. When well-planned, well-resourced, and well-executed it can be useful. But it is seldom as useful as one might hope or imagine it could be. As for breaking existing use cases, this will cause us to stay at the last release that meets our needs until the beginning of a new major release cycle on our side, unless there's some other feature that compels us to deal with the breaking change mid-cycle. We're not using that much from boost so we'd not even notice many breaking changes but if one hit a feature we're using widely we would not / could not consider adopting that release mid-cycle without some serious bug or similar justification compelling it. Our products are used in stringently regulated environments for life-critical purposes. We aren't permitted to change anything without a good reason. The beginning of a major release cycle is the only window we have for big infrastructure changes. That's an unusual constraint but every user will have some unusual constraints on their resources and/or freedom of action. Boost competes for that limited pool of beta-participation time with all the other tool and library vendors. Open-source status gives you champions in the development pit but it doesn't change management's priorities. -swn

2 1

[Spirit] Creating a simple text format parser
by Kisso Bajslovski 21 Nov '08

21 Nov '08

Hi, I'm trying to create a simple parser to format a text input, Spirit seems to fit the bill nicely for my needs, but I'm having a few problems. First of all while the documentation is rather large, it would be sweet with some more small examples for a few small but as different as possible grammars. There's some already hidden in the docs at various places, it would be sweet if there was a section in the manual with all the code examples gathered. Anyway, on to my little problem. I'm trying to create a grammar which is fairly close to HTML in one regard, consider the following: Some default text <font=Arial><color=FFFFFF>some white arial text</font> some white text with default font</color> some text with default settings So basically I need to create a rule which when encountering a tag pushes it onto a stack, and later on pops it when the matching closing tag is found, clearing its states. I have got a bit into that part, even if I would love some suggestions on it still if anyone have done something similar in Spirit. But the real problem actually is with the text which isn't a tag. I use anychar_p for that at the moment to capture it with a simple semantic action. The problem is that anychar_p just retrieves a single character, when I'd like to actually get it in the form of a string instead. To render it 1 char at the time is highly inefficient. I could use some global string to which I accumulate the chars and then let the tags check it and render its contents, but that seems hackish at best. For a parser such as this, is there a better way perhaps? //Ylisen

3 3

[lambda] Can't see the wood for the trees"
by Robert Jones 21 Nov '08

21 Nov '08

I have a little code snippet... #include <iostream> #include "boost/range.hpp" #include "boost/function.hpp" #include "boost/lambda/lambda.hpp" int main( ) { using namespace boost::lambda; typedef int block[2][4]; boost::function< int(boost::range_value< block >::type) > third = _1[2]; block values = {{0,1,2,3},{4,5,6,7}}; std::for_each(boost::begin(values), boost::end(values), std::cout << third << "\n" ); } which I want to print the third element of each row of values. I can see that what I've written is not quite right, since the compiler quite reasonably complains that it doesn't kknow how to print a function object, but I can't seem to write the correct incantation! The error message, if it helps is... $ g++ -o junk.exe junk.cpp junk.cpp: In copy constructor `std::basic_ios<char, std::char_traits<char> >::basic_ios(const std::basic_ios<char, std:: char_traits<char> >&)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:781: error: `std::ios_base::ios_base(const std::ios_base&) ' is private junk.cpp:17: error: within this context junk.cpp: In function `int main()': junk.cpp:17: error: initializing argument 3 of `_Function std::for_each(_InputIterator, _InputIterator, _Function) [wi th _InputIterator = int (*)[4], _Function = std::basic_ostream<char, std::char_traits<char> >]' /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algo.h: In function `_Function std::for_each(_InputIterator, _Inp utIterator, _Function) [with _InputIterator = int (*)[4], _Function = std::basic_ostream<char, std::char_traits<char> >] ': junk.cpp:17: instantiated from here /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algo.h:158: error: no match for call to `(std::basic_ostream<char , std::char_traits<char> >) (int[4])' Thank Folks! - Rob.

2 1

[signals2][review] signals2 review results
by Stjepan Rajko 21 Nov '08

21 Nov '08

** signals2 review results ** I am pleased to announce that the signals2 library by Frank Mori Hess is accepted into boost, pending some conditions outlined below are met. I would like to thank the author for his work on this library, and for his very responsive participation in the review. I would also like to thank Franz Alt, Jean-Cristophe Benoist, Vicente Botet, Fabio Fracassi, Johan Råde, Ravikiran Rajagopal, Andrew Webber, and Jesse Williamson for submitting reviews, and Terry Golubiewski, Michael Marcin, and Hansjörg for additional comments regarding the library. There were 5 votes cast for the acceptance of this library, and 3 against accepting the library at this time. The reviewers that were against immediate inclusion of signals2 suggested that the library should be accepted when several stated problems are addressed adequately. Overall, the library was regarded as a much needed thread-safe successor of Boost.Signals. Those that have tried switching from Boost.Signals to signals2 have found the switch rather painless (at least in the cases that don't involve the Boost.Signals trackable interface), and some reported using signals2 and/or its previous versions in production code. Some additional improvements that were mentioned are an automatic connection management system based on shared_ptr, and a change of namespace (which avoids problems with QT). Additionally, many requests were made for improvements in the documentation, as well as some improvements in thread-related testing and some possible changes to the interface. Frank has addressed many of the issues in the review, and in many cases offered concrete steps to address the problems. Following is an overview of the most prominent issues that were raised. These issues must be addressed before this library is included in the trunk and subsequent releases: ** Boost.Signals -> signals2 transition ** There needs to be a concrete plan of migration from the current version of Boost.Signals to signals2. The almost-decided-on route is to have both Boost.Signals and signals2 co-exist in Boost for a few releases, with Boost.Signals getting deprecated. From reading the reviews, it looks like no one has a problem with this, so it seems like it's just a matter of an agreement between the library maintainers that gets posted in the documentation / on the lists. The bigger part of the problem is to make sure that users of Boost.Signals can transition to signals2 as easily as possible. Given the reports so far, this process is indeed easy, with the biggest exception being the removal of the trackable interface in signals2 (which was removed because it is not thread-safe). Frank has indicated that he will put it back into the library and make it available for single-threaded signals as a way to ease porting for Boost.Signals users, which sounds like a great step. My biggest concern here is that the signals2 interface is "gotten right" (with respect to compatibility with Boost.Signals) by the time it is included in Boost, so that porting is both easy and a fixed target. Given how easy people have found porting their code so far, it looks like restoring the trackable interface might is all that is needed. I would discourage any further breaking changes to the interface (one thing mentioned was dropping some of the template parameters), but I also recognize the opportunity to improve the interface in response to the review. Any signals2 interface changes that significantly break compatibility with Boost.Signals should be considered very carefully (even if Boost.Signals will stay on for a while), and if possible, counterbalanced by a compatibility layer put in to ease the transition for Boost.Signals users. ** Documentation ** Pretty much all reviewers noted the documentation as lacking with regard to thread-safety aspects of signals2 and other added functionality. Frank has clarified many of the questions that came up during the review, and outlined a plan of integrating the requested information into the documentation. Specific items are outlined in my notes at the end of this mail. ** Tests ** Some reviewers also noted a lack of tests for thread-related functionality. I agree that whatever can be reasonably tested should be tested. Frank has suggested he will try to adapt some of the Boost.Thread tests where adequate. As stated, the above issues should be addressed before moving the signals2 library to the boost trunk. I don't anticipate significant problems because: * the trackable interface has already been brought into signals2 at one point in the past * all documentation related questions have been clarified during the review, and Frank's suggestions for updating the documentation were agreeable * Boost.Thread tests should provide some insight into how signals2 thread-safety could be more thoroughly tested. Also, several reports have been made of signals2 already being successfully used in production settings, which speaks to its reliability. I strongly suggest that Frank make an announcement when the changes are completed, so that those interested can make sure that their concerns have been adequately addressed. Given Frank's record as a very responsive maintainer of this library in the past, and his commitment towards the peer-review process (he insisted on having this library reviewed even though it could have technically been included with Doug Gregor's approval as an upgrade to Boost.Signals), and considering that one of the reviewers has already offered to review changes to the library, I anticipate that a de facto mini-review of the library will happen at that point even though I am not requiring one formally. Finally, below are some notes on suggested changes I extracted while reading through all of the reviews. Square brackets contain initials of some of the reviewers that mentioned the issue, and double curly braces my personal comments. This is by no means a record of everything that has been mentioned, but perhaps the author will find it useful while making the post-review changes. To be clear, the below changes are not required for the inclusion of signals2 into the boost trunk, except as they pertain to the required changes outlined above. -- Implementation -- ---- * source code could be formatted more clearly [FA] * address efficiency problems where signals2 is significantly slower than signals [FA] {{ while efficiency is important, and ideally signals2 efficiency for single-threaded use cases converges to that of Boost.Signals, this is one area where improvements can painlessly continue to happen after the integration of signals2 into the trunk (as long as they don't require interface changes), so I don't consider this a priority at this point }} * clean macro names used with Boost.Preprocessor [VB] -- Interface -- ---- * portable syntax - either establish that the syntax works (and on what compilers) or consider deprecating [JW] * use Boost.Parameter for signal template parameters due to so the user doesn't have to specify default template parameters. [VB][FA] {{ if there are any arguments against changing the signal class template to use Boost.Parameter directly, you could still provide a metafunction that uses Boost.Parameter to provide the signal type. This would allow, e.g.: signal_type<void(int, int), mutex_type<signals2::mutex> >::type my_signal; }} * use template parameters such as single_threaded or multi_threaded instead of the mutex type. [vb] {{ it should be possible to allow the Mutex parameter to be either a mutex class or a special (or policy) type that maps to a particular mutex }} {{ this suggestion was given in conjunction to a proposal for allowing external locking mechanisms, but it seems like external locking should be possible with what the library already offers - perhaps an example of this would be useful }} -- Documentation -- * update code examples in tutorial to contain fixes already present in the package [JW] {{ if you aren't already, consider using the quickbook import facility to keep the compiled code snippets and docs in sync }} * FAQ should be mentioned earlier / information in the FAQ should be more visible [JW][VB] * while the Beginner/Intermediate/Advanced designations have been found useful [FA], the tutorial has also been found readable beginning to end without much use for the designations [JW] * clarify call ordering between grouped / ungrouped slots [JW] * clarify optional_last_value [JW] [AW] * clarify the way slot::track works [VB][JW] {{ the documentation says we "pass the shared_ptr to the slot via its slot::track method before connecting", but the clarification given to Jesse Williamson also explains that the *pointer* held by shared_ptr is passed to the slot_type constructor. This seems easy to trip over - some syntactic sugar that avoids using the shared_ptr twice in the expression in two different ways might be helpful }} * offer / point to some documentation on, and provide an example for postconstructible / predestructable / deconstruct_ptr. [FA][AW][VB][FF] * document / provide example for extended_slot_type [FA] [FF] * expand the documentation of various mutexes that can be used and their properties [VB] also in regards with co-use with Boost.Thread [FF] {{ I can find the mutexes explained in the reference documentation, but an overview at the tutorial level would be nice }} * expand discussion on thread-safety: ** how exactly is signals2 thread-safe? [JB][RR] ** explain behavior in various threading circumstances [JB] * mention the benefits of the new connection management based on shared_ptr over old trackable interface (e.g., allowing non-intrusive use with 3rd party classes) [FF] * consider making the portable syntax examples less prominent [FF] -- Testing -- * add multi-threading tests [JB] * include performance tests [VB] Again, thanks and congratulations to Frank Mori Hess, and thanks to all of the reviewers. Kind regards, Stjepan

3 3

[xpressive] Is there a way to test for an empty regex?
by Michael Goldshteyn 20 Nov '08

20 Nov '08

What is the best way to test for an empty boost::xpressive::regex object? That is, if I have code like: boost::xpressive::sregex re; ... // Test if re is empty and should not be used to perform a regex_search if (?????) Thanks, Michael Goldshteyn

3 8

math statistical distribution: multivariate gaussian
by Thijs van den Berg 20 Nov '08

20 Nov '08

Hi, I'm about to start implementing a library for multivariate Gaussian distribution. The goal is to build a lib that provides a container for the definition of multivariate Gaussian, as well as implement various identities of that distributions. The identities are things like mean, variance but also conditional distributions, density gradients vector, linear combinations of multivariate Gaussian, Gaussian chain rule etc. I've seen request for something like this in the boost:math/statistical_distributions todo's list, and was wondering if it's possible to team up, or -if nobody is working on it- initiate development. Best, Thijs -- SITMO Quantitative Financial Consultancy - Software Development M.A. (Thijs) van den Berg Tel.+31 (0)6 2411 0061 Fax.+31 (0)15 285 1984 thijs(a)sitmo.com <mailto:thijs@sitmo.com> - www.sitmo.com <http://www.sitmo.com>

4 17

[config] typo on doc
by vicente.botet 20 Nov '08

20 Nov '08

Hi, there are some typos in the table " Macros that describe C++0x features not supported " BOOST_NO_DEFAULTED_FUNCTIONS The compiler does not support defaulted (= default) functions. [[BOOST_NO_DELETED_FUNCTIONS The compiler does not support deleted (= delete) functions. BOOST_NO_UNICODE_LITERALS The compiler does not support Unicode (u8, u, U#) literals. ]] [[BOOST_NO_VARIADIC_TEMPLATES` The compiler does not support variadic templates. Can some macros be added to emulate the compiler behavior when BOOST_NO_DEFAULTED_FUNCTIONS BOOST_CONSTRUCTOR_DEFAULT BOOST_COPYCONSTRUCTOR_DEFAULT BOOST_NO_DELETED_FUNCTIONS BOOST_CONSTRUCTOR_DELETE BOOST_COPYCONSTRUCTOR_DELETE Best, Vicente

2 2

[boostbock] failed to load external entity warning
by vicente.botet 20 Nov '08

20 Nov '08

Hi, while building the docs of one of the Boost libraries trunc I get the following error (I think that these errors do not depend on the release but on my configuration) warning: failed to load external entity "/home/Vicente/SVN/tools/boostbook/xsl/docbook.xsl" cannot parse /home/Vicente/SVN/tools/boostbook/xsl/docbook.xsl warning: failed to load external entity "/home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl" cannot parse /home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl intro.qbk: error: Could not open input file. Have other find the same problem? What is going wrong on my configuration? trunk + cygwin Thanks for your help, Vicente ========================= Traces ========================= xslt-xsltproc ../bin.v2/libs/asio/doc/gcc-3.4.4/debug/asio_doc.docbook warning: failed to load external entity "/home/Vicente/SVN/tools/boostbook/xsl/docbook.xsl" cannot parse /home/Vicente/SVN/tools/boostbook/xsl/docbook.xsl XML_CATALOG_FILES=../bin.v2/boostbook_catalog.xml export XML_CATALOG_FILES "C:/cygwin/home/Vicente/boost/quickbook/bin/xsltproc.exe" --stringparam boost.libraries "../../libs/libraries.htm" --stringparam chapter.autolabel "0" --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "8" --stringparam generate.section.toc.level "1" --stringparam generate.toc "chapter nop section nop" --stringparam root.filename "boost_asio" --stringparam toc.max.depth "1" --stringparam toc.section.depth "2" --xinclude -o "../bin.v2/libs/asio/doc/gcc-3.4.4/debug/asio_doc.docbook" "/home/Vicente/SVN/tools/boostbook/xsl/docbook.xsl" "../bin.v2/libs/asio/doc/gcc-3.4.4/debug/asio_doc.xml" ...failed xslt-xsltproc ../bin.v2/libs/asio/doc/gcc-3.4.4/debug/asio_doc.docbook... ...skipped <phtml>asio_HTML.manifest for lack of <p../bin.v2/libs/asio/doc/gcc-3.4.4/debug>asio_doc.docbook... xslt-xsltproc ../bin.v2/libs/accumulators/doc/gcc-3.4.4/debug/accdoc-xml.doxygen warning: failed to load external entity "/home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl" cannot parse /home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl XML_CATALOG_FILES=../bin.v2/boostbook_catalog.xml export XML_CATALOG_FILES "C:/cygwin/home/Vicente/boost/quickbook/bin/xsltproc.exe" --stringparam doxygen.xml.path "/home/Vicente/SVN/bin.v2/libs/accumulators/doc/gcc-3.4.4/debug/accdoc-xml" --xinclude -o "../bin.v2/libs/accumulators/doc/gcc-3.4.4/debug/accdoc-xml.doxygen" "/home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl" "/home/Vicente/SVN/bin.v2/libs/accumulators/doc/gcc-3.4.4/debug/accdoc-xml/index.xml" ... quickbook.quickbook-to-boostbook ../bin.v2/libs/functional/hash/doc/gcc-3.4.4/debug/hash.xml Generating Output File: ../bin.v2/libs/functional/hash/doc/gcc-3.4.4/debug/hash.xml intro.qbk: error: Could not open input file. tutorial.qbk: error: Could not open input file. portability.qbk: error: Could not open input file. disable.qbk: error: Could not open input file. changes.qbk: error: Could not open input file. links.qbk: error: Could not open input file. thanks.qbk: error: Could not open input file. xslt-xsltproc ../bin.v2/libs/interprocess/doc/gcc-3.4.4/debug/autodoc-xml.doxygen warning: failed to load external entity "/home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl" cannot parse /home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl XML_CATALOG_FILES=../bin.v2/boostbook_catalog.xml export XML_CATALOG_FILES "C:/cygwin/home/Vicente/boost/quickbook/bin/xsltproc.exe" --stringparam doxygen.xml.path "/home/Vicente/SVN/bin.v2/libs/interprocess/doc/gcc-3.4.4/debug/autodoc-xml" --xinclude -o "../bin.v2/libs/interprocess/doc/gcc-3.4.4/debug/autodoc-xml.doxygen" "/home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl" "/home/Vicente/SVN/bin.v2/libs/interprocess/doc/gcc-3.4.4/debug/autodoc-xml/index.xml" ...failed xslt-xsltproc ../bin.v2/libs/interprocess/doc/gcc-3.4.4/debug/autodoc-xml.doxygen... Vicente@viboes1 ~/SVN/libs/functional/hash/doc $ ls -l total 73 -rwxrwxrwx 1 Vicente Aucun 52 Nov 3 15:00 CMakeLists.txt -rwxrwxrwx 1 Vicente Aucun 932 May 21 2008 Jamfile.v2 -rwxrwxrwx 1 Vicente Aucun 3000 Nov 11 22:34 changes.qbk -rwxrwxrwx 1 Vicente Aucun 1430 Mar 30 2008 disable.qbk -rwxrwxrwx 1 Vicente Aucun 716 Mar 30 2008 hash.qbk -rwxrwxrwx 1 Vicente Aucun 1832 Mar 30 2008 intro.qbk -rwxrwxrwx 1 Vicente Aucun 1085 Mar 30 2008 links.qbk -rwxrwxrwx 1 Vicente Aucun 3361 Mar 30 2008 portability.qbk -rwxrwxrwx 1 Vicente Aucun 30709 May 21 2008 ref.xml -rwxrwxrwx 1 Vicente Aucun 1257 Mar 30 2008 thanks.qbk -rwxrwxrwx 1 Vicente Aucun 6604 Mar 30 2008 tutorial.qbk $ ls -l /home/Vicente/SVN/tools/boostbook/xsl/doxygen/collect.xsl -rwxrwxrwx 1 Vicente Aucun 2007 Aug 25 06:44 /home/Vicente/SVN/tools/boostbook/x sl/doxygen/collect.xsl $ ls -l /home/Vicente/SVN/tools/boostbook/xsl/docbook.xsl -rwxrwxrwx 1 Vicente Aucun 16566 Nov 11 22:34 /home/Vicente/SVN/tools/boostbook/ xsl/docbook.xsl

2 1

Re: [boost] [unicode] Interest Check / Proof of Concept
by Kasra 20 Nov '08

20 Nov '08

Hi guys, I have been reading this thread with enthusiasm. I like the idea of unicode string class. However, since unicode is rather different from the old fashioned ANSI string literals some interfaces might need to be changed. Maybe what I have to say could help you in one form or the other: \+ typedef std::basic_string<uint32_t> unicode_string; this string class will have all of the normal std::string interface as all of the unicode encoding is mapped within a 32-bit integral type. we could then have a class called encoding; such that it allows for static conversion from unicode_string type to utf8, utf16, etc. for example: \+ unicode_string s = U"Hello Wolrd!"; \+ utf8_string utf8 = encoding::utf32::to_utf8(s); // also we could have a implicit conversion such that utf8 could // perform the conversion from utf32 string I personally like this approach a lot. Since when you think about it the interface does not changed we could still have efficient iterators and insertion, at the same time whenever there is a need for memory compact encoding we convert to the desired encoding as required. So in a sense what I am saying is keep the encoding using utf32 for performance on memory however, when we want to export the encoding (to screen, file and etc) convert to the desired encoding. If there is any interest for this approach drop me a line and I will send you the interface which I have for this. With best regards Kasra

1 0

[function] minor doc issues
by Thorsten Ottosen 20 Nov '08

20 Nov '08

Hi, Reading http://www.boost.org/doc/libs/1_36_0/doc/html/function/reference.html it says: A function object f is compatible if for the given set of argument types Arg1, Arg2, ..., ArgN and a return type ResultType, the appropriate following function is well-formed: // if ResultType is not void ResultType foo(Arg1 arg1, Arg2 arg2, ..., ArgN argN) { return f(arg1, arg2, ..., argN); } // if ResultType is void ResultType foo(Arg1 arg1, Arg2 arg2, ..., ArgN argN) { f(arg1, arg2, ..., argN); } I believe the "If ResultType is void" is not needed. We can return void in C++. -Thorsten

2 5