September 2005 - Boost - lists.boost.org

VC++ compiler error with boost graph library
by Chris Alvers 19 Nov '05

19 Nov '05

Hi, I tried to do a depth_first_search with the following graph type and visitor: struct CycleDetector : public boost::default_dfs_visitor { CycleDetector( bool& cycle ) : m_hasCycle(cycle) {}; void back_edge( T_Edge, const T_Graph& ) { m_hasCycle = true; } bool& m_hasCycle; }; typedef boost::adjacency_list< boost::setS, boost::listS, boost::bidirectionalS> T_Graph; bool hasCycle(false); CycleDetector cd(hasCycle); boost::depth_first_search(m_graph, visitor(cd)); Compiling this on VC++ 7.1.3 (.NET Framework 1.1) results in the following error message: \boost\boost\property_map.hpp(349): error C2678: binary '+' : no operator found which takes a left-hand operand of type 'const std::vector<_Ty>::iterator' (or there is no acceptable conversion) with [ _Ty=boost::default_color_type ] ---------------------- Changing the graph type definition to: typedef boost::adjacency_list< boost::setS, boost::vecS, boost::bidirectionalS> T_Graph; (i.e. replacing the listS by vecS) works perfectly. Is this a known restriction of the library ? Best regards Alex ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

3 2

[database]
by Brock Peabody 10 Nov '05

10 Nov '05

Hi, I've added the code for the database project to the sandbox. I've also made the following changes based on feedback from Caleb and Jonathan: 1) fixed <: digraphs 2) added transaction functions to the abstract interface. Added a reference_counted_transaction_manager class for use in implementations that don't support nested transactions. 3) made the interface support null field detection via boost.optional 4) iteration supports BiDirectional model instead of RandomAccess 5) added a transaction class for scoped transaction management on the to-do list: 1) documentation - this is going to be a word document or something at first since I know nothing about html. 2) make .jam files 3) test cases - I'm not sure how these are going to work. 4) investigate possibility of supporting a prepare_statement function

5 8

Boost's position/work on a Standard GUI Library for C++0x
by David Wehite 06 Nov '05

06 Nov '05

In his article "The Design of C++0x", published in C/C++ Users Journal, May 2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI". I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library. If and how was it addressed and pointers to work on the subject if such has been done. I just want to clarify, that when I say "standard", I mean that as long as my application source code adheres to that standard, if I take it and walk into any machine that has a C++ compiler (at least one that deserves that title), compilation would at least not fail for syntax reasons, w/o me changing a single character in the source (not even changing the case of a character), no matter how complex and/or large that source is. I don't know how to avoid a sea of answers with this mailing list arrangement (not that I think that my 2.6GB gmail box would soon fill up...), may be the few answers can be posted on the newsgroup forum? Thanks in advance for the education, David

33 162

Bounded types
by Robert Kawulak 24 Oct '05

24 Oct '05

Hi group, Some time ago I've written a set of class templates for bounded types (types whose variables may hold a value only from within a specified range). You can download the sources at http://www.rk.w.pl/progz/bounded. I've created a thread in comp.lang.c++.moderated (http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_frm/thre ad/0298fc4ac6c6d223/) as I was hoping to work the project on and maybe transform it into a proposal for the C++0x standard library, but unfortunately the feedback was very low. Just today I saw in this newsgroup a thread titled "Checked Integral Class" concerning a very similar facility so I'm writing this post to call attention to my implementation. Maybe it would be better to include such class templates in Boost first, and then think about making a proposal for the C++ standard... Unfortuantely there's no documentation yet as this is only a sketch for further refinements, but comments in the code and posts in comp.lang.c++.moderated may answer some of your questions about design decisions and usage. If not then please ask them here or on comp.lang.c++.moderated. Any comments and suggestions are welcome. I hope there are more people who need such a facility and would like to work on it, let's finally do it - C++ lacks bounded types and it's high time to fix that! ;-) Best regards, Robert Kawulak -=##############=- <gg> 6934572 </gg> <gsm> 603654215 </gsm> <www> www.rk.w.pl </www> -=##############=- "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein

14 70

[TR1 Review] TR1 Formal Review Beginning
by Beman Dawes 19 Oct '05

19 Oct '05

The formal review of the Boost TR1 Library by John Maddock begins today, Saturday, September 24th, and runs through Wednesday, October 5th. The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes: * Reference Wrappers * Smart Pointers * Class template result_of. * Function template mem_fn. * Function Object Binders. * Polymorphic function wrappers. * Type Traits. * Random Number Generators and Distributions. * Tuples. * Tuple Interface to std::pair. * Fixed Size Array. * Hash Function Objects. * Regular Expressions. * Complex Number Algorithm Overloads. * Complex Number Additional Algorithms. Functionality in TR1 but not yet available: * Mathematical Special Functions. * Unordered Associative Set (Hash Table). * Unordered Associative Map (Hash Table). * C99 C language additions. Additional information including online documentation is available at http://freespace.virgin.net/boost.regex/tr1/index.html The complete TR1 lib source and docs can be downloaded from http://freespace.virgin.net/boost.regex/tr1/tr1-20050816.zip Please help Boost by posting your formal review of this library. Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. --Beman Dawes, Review Manager

7 13

[testing] Refactoring serialization tests, and possibly others.
by Rene Rivera 19 Oct '05

19 Oct '05

After having run two cycles of tests for Boost with the mingw-3_4_2-stlport-5_0 configuration and having it take more than 14 hours on a 2.2Ghz+1GB machine, most of that in the Boost.Serialization library[*]. And reading some of the recent discussion about the desire to expand testing to include cross-version compatibility and cross-compiler compatibility, and hence having the number of tests multiply possibly exponentially. I am seriously concerned that we are going in the wrong direction when it comes to structuring tests. From looking at the tests for serialization I think we are over-testing, and we are past the point of exhausting testing resources. Currently this library takes the approach of carpet bombing the testing space. The current tests follow this overall structure: [feature tests] x [archive types] x [char/wchar] x [DLL/not-DLL] Obviously this will never scale. My first observation is that it doesn't seem that those axis look like independent features to me. That is, for example, the char/wchar functionality doesn't depend on the feature getting tested, or at least it shouldn't. And I can't imagine the library is structure internally in that way. To me it doesn't make sense to test "array" saving with each of the 3 archive types since the code for serialization of the "array" is the same in all situations. Hence it would makes more sense to me to structure the tests as: [feature test] x [xml archive type] x [char] x [not-DLL] [text archive tests] x [char] x [non-DLL] [binary archive tests] x [non-DLL] [wchar tests] x [non-DLL] [DLL tests] Basically it's structured to test specific aspects of the library not to test each aspect against each other aspect. Some benefits as I see them: * Reduced number of tests means faster turn around on testing. * It's much easier to add tests for other aspects as one only has to concentrate on a few tests instead of many likely unrelated aspects. * The tests can be expanded to test the aspects more critically. For example the DLL tests can be very specific as to what aspect of DLL vs non-DLL they test. * It is easier to tell what parts of the library are breaking when the tests are specific. [*] That's just a CPU time observation, not to mention that it takes 2.15GB of disk space out of a total of 5.09GB. And it's only one compiler variation. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

5 37

Macros at namespace scope: trailing semicolon?
by David Abrahams 15 Oct '05

15 Oct '05

I am defining a macro, BOOST_PARAMETER_KEYWORD(tag_namespace, name) that declares a keyword for the Parameter library. It has to be used at namespace scope. I have the option to define it so that correct usage requires a trailing semicolon, or so that the trailing semicolon is forbidden. Unfortunately I don't have the ability to make it optional. Which should I choose? IMO there's no chance of confusing it with a function call, since a function call would be illegal in the context in which it's used, and people are naturally more likely to add a semicolon without thinking about it, and if I design the macro so that a semicolon is required it will interact more smoothly with editors and pretty-printers. So I can't see any good reason not to require the semicolon. Arguments? -- Dave Abrahams Boost Consulting www.boost-consulting.com

19 87

What is Boost?
by David Abrahams 13 Oct '05

13 Oct '05

Hi, Last night I hosted a birds-of-a-feather session at the SD Best Practices conferences here in Boston. I was encouraged that, at a conference that only adopted a C++ track this year, we had 15 people there. It was about evenly split between people who were using Boost and those who just came to find out more about it. Those who were using Boost were really enthusiastic. I was stunned to discover that the rest of them reported that wanted to know what Boost _is_, but that the website doesn't tell them. And when they said that, it hit me like a ton of bricks: they're right! We really need a section at the top of the page titled "What is Boost?" that covers something like the following: * Boost is a collection of C++ libraries - Free for any use - Extensively peer-reviewed - Extensively Tested * When you download Boost, you get the whole collection * There are some dependencies among libraries, but they are not tightly coupled * There is a tool (bcp) for extracting the parts you want and their dependencies. * Many boost libraries can be used just by putting the library collection's top directory in your #include path. Complete instructions for getting started are at: ___ * The important features of the Boost directory structure are: - boost - libs - more - tools (with rough descriptions of each) I'd like to see some discussion of what's missing (or extra) in the list above... and a volunteer to write the introductory passage :) -- Dave Abrahams Boost Consulting www.boost-consulting.com

13 42

[signals] expected failure markup for como
by Markus Schöpflin 13 Oct '05

13 Oct '05

There are currently two test failures (dead_slot_test, and trackable_test) which are marked as expected for como. The note says: 'The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them).' Does anyone know the exact circumstances of this compiler bug or even has a small reproducer? Tru64/CXX has the same failures and I would like to submit a bug report to the vendor. Markus

2 3

[tools][bcp] using boost internally in other libraries
by Bjørn Roald 12 Oct '05

12 Oct '05

Hi boosters, In the following I have made the assumption that it is in the spirit of the Boost license for Boost to be used as foundation for other libraries, open-source, free, commercial, or whatever. In addition, that any modifications to the libraries is allowed for any such purpose. However, it is my belief that most of the developers would not like to see extensive branching in the effort of providing better Boost libraries. This would most likely stretch the potential of the C++ community in providing a better future set of standard libraries for the language. So to my main subject: I have been working for some time to get acceptance for using Boost libraries as elements in a higher level portable platform for library development. It has surprised me how hard it is to make compelling and attractive set of arguments for using Boost (or other libraries) without attempting to ignore some pretty serious concerns. These concerns are: - commercial support for our use of Boost - quality assurance of Boost itself - stability of Boost API - maintainability of Boost source code - deployability of our library into environments using different versions of Boost or libraries used in boost - configuration management issues in general for us and our customers - platform support in Boost ( or if the platform support Boost if you like ;-) All of these concerns can be declared acceptable, given that you are willing to accept trade offs and risk. The issue I try to raze is if it is possible to reduce the magnitude of these risks and trade offs. One of the key issues is that you have to decide on some strategy of how to maintain your boost version. The most obvious strategy may be to stay with the latest Boost release at any time, this will however add risk as you have to adopt new changes as they are introduced into Boost and not as it fits your own release plans. The obvious alternative is to stay with a Boost release longer, possibly until you are forced to switch. This strategy will quickly force you into maintaining your own branch as Boost developers can not be expected to support old releases. Between these there are many shades of gray which may fit more or less well depending on your project and your customers. If your customers themselves use boost you are likely to meet a added configuration management, testing and release related cost and risk. As library developers have a very different type of customer relationship than what is the case for end application developers there are a number of concerns that make adaptation of Boost, or any other 3rd party library for that sake, more problematic for library developers. The main issue is to what degree a library depends on other libraries and hence introduces indirect or direct dependencies to its users. These dependencies tend to be troublesome for the library developer to support, as well as they may be troublesome for users to accept. In fact users may easily be in situations where such dependencies are completely unacceptable. To help to understand the issue I like to define categories of libraries which affect the degree they are affected by these concerns. Cat1. open source, source distributions, allowing encapsulation Cat2. open source, source distributions in general Cat3. open source, binary distributions Cat4. closed source Cat1 and Cat2 are build-able source code distributions. This give the user the ability to build the library and ensure that it is built correctly with other library it depends on, on the target system. Cat1 add to this the ability to hide the use of it inside other libraries, i.e. it can live concurrently in an end system with other versions of the same Cat1 library. Cat3 and Cat4 are for this discussion as far as I can tell similar. Cat3 may be called open source by some, but if for a variation of reasons rebuild by user is not an option, the results in this discussion becomes the same. Boost is a Cat2 library. Even if the extensive use of headers only libraries help some of the issues addressed in this post, it is not a general solution that makes Boost or part of Boost a Cat1 library. Now an example showing some dependencies: MyCustomersApplication |---- Boost 1.33 |---- MyLib |---- Boost 1.32 If MyLib is Cat1 or Cat2 the chances are good that we may be ok. Most likely MyLib will soon adopt the migration to new Boost releases by the actions of the maintainer or by patches from end users. If however MyLib is Cat 3 or 4 we have a problem. This problem is real even if the use of Boost in MyLib is strictly internal. In my view this is an especially bad problem. Even if I do not intend to use Boost in any way in the API of MyLib I still have this issue of incompatibility. This problem will disqualify use of Boost even internally for many library developers. Now, if we assume (which in most cases is dangerous) that library developers are a skilled race among the general population of the C++ community, it is in my view sad that many of them are not able to use Boost or potentially participate professionally in the efforts to improve Boost. I am sure many actually would participate if they could use it at work. Any management with commercial goals mixed with good sense of business would also let their developers participate actively, especially if this was the best way of maintaining parts of their product. This would let their developers focus their effort on the parts of the product that is core to their business rather than the parts that can be found and downloaded on the net (read boost.org) Ok, back to the example. If MyLib have no intention of using Boost in the API, is there a way? I have been struggling with this issue for a while. The obvious solution to me is to make Boost a Cat1, the problem is how? As mentioned earlier in many threads on this list header-only libraries helps, however this does not apply to all of Boost and it is possibly other issues that I am not aware of. If we look at the C++ domain in general, there are limited ways of hiding symbols in libraries. As far as I can see, none of these are sufficiently powerful to hide boost completely. One alternative is however to let the symbols leak, but make sure none are in conflict with the other version of boost. Some sort of namespace replacement or wrapping comes to my mind. Side Note: I am aware of symbol encapsulation abilities in windows DLLs and similar new features supported by GCC, however these are not generally supported on all platforms, so I have selected to ignore them. They may however be helpful to many. The general idea is that there are no references to symbols in the boost namespace between any MyLib libraries, nor in any header files in or referenced from MyLib API. How can this be achieved? I have concluded that accessing boost trough namespace wrapping header files are unpractical at best. This needs to be designed into all of boost for this to work, and I do not know exactly how. The main challenge is #include <boost/xxxx.hpp> directives which does not refer to the wrapping headers. An alternative is to replace all references to boost namespace with e.g. MyLib::boost namespace in the boost source code and change all #include <boost/xxx.hpp> directives to #include <Mylib/boost/xxx.hpp>. This would make a buildable library which would not share symbols with other versions of boost. The result is a branch or clone if you like of Boost that can be used with the same effect as if we actually had a Cat1 boost library. There is however serious problems here. Any management with common sense would say.... hey.... stop. The prospect of undertaking maintenance of a branch or clone of Boost does not make much sense --- So, the only way this would work is to make it possible to maintain the library in the boost community and somehow make the translation to the MyLib/boost namespace a pure production step. In configuration management terms this means that the original or possibly slightly patched boost source code is under configuration control along with a tool-chain used under MyLib system build that transforms the boost source tree to the form used internally. This is where I started looking at Boost tools/bcp. The bcp (boost copy I guess) tool is an excellent starting point since it already has the ability to copy selected libraries and their dependencies from the boost distribution to project specific source tree. So in a sense it is similar in spirit, but solves primarily a different goal, which is to reduce the size of the boost distribution imported. This is complementary to what I want. I have experimented a little with some extensions to bcp using some simple regexp replace calls and got some encouraging results. I am able to build the resulting source tree using only small adjustments to top level bjam files after treatment by the modified bcp. I have yet to complete support for replacing boost with nested namespaces since it is trickier to do the replacement of the ending braces of the namespace scope. I believe other tools than the Regexp library may be more appropriate for this task. So to wrap up: I do not believe anything prevents me from going along this path if I decide to do so. I am however interested in the boost developers attitude toward this approach, and in particular if this is something you will encourage and/or support. I am willing to work on the tool support for this in boost or to maintain a modified bcp tool if that is more appropriate. Regards Bjørn Roald

9 24