- Boost - lists.boost.org

Please add to boost/type_traits/intrinsics.hpp
by Walter Bright 29 Apr '06

29 Apr '06

Please add to boost/type_traits/intrinsics.hpp the following slice: ---------------------------- #if defined(__DMC__) && (__DMC__ >= 0x848) // For Digital Mars C++, www.digitalmars.com # define BOOST_IS_UNION(T) (__typeinfo(T) & 0x400) # define BOOST_IS_POD(T) (__typeinfo(T) & 0x800) # define BOOST_IS_EMPTY(T) (__typeinfo(T) & 0x1000) # define BOOST_HAS_TRIVIAL_CONSTRUCTOR(T) (__typeinfo(T) & 0x10) # define BOOST_HAS_TRIVIAL_COPY(T) (__typeinfo(T) & 0x20) # define BOOST_HAS_TRIVIAL_ASSIGN(T) (__typeinfo(T) & 0x40) # define BOOST_HAS_TRIVIAL_DESTRUCTOR(T) (__typeinfo(T) & 0x8) # define BOOST_HAS_NOTHROW_CONSTRUCTOR(T) (__typeinfo(T) & 0x80) # define BOOST_HAS_NOTHROW_COPY(T) (__typeinfo(T) & 0x100) # define BOOST_HAS_NOTHROW_ASSIGN(T) (__typeinfo(T) & 0x200) # define BOOST_HAS_VIRTUAL_DESTRUCTOR(T) (__typeinfo(T) & 0x4) # define BOOST_HAS_TYPE_TRAITS_INTRINSICS #endif ----------------------------- which will enable better boost support for Digital Mars C++. Thanks! -Walter Bright Digital Mars

2 2

[Boost Review] Property Tree Library Review Extended
by Thorsten Ottosen 29 Apr '06

29 Apr '06

Dear All, The review period is extended to Sunday the 30th. The original announcement may be found below. best regards -Thorsten, review manager --------------------------- Dear All, I have the great pleasure to announce that the formal boost-review of Marcin Kalicinski Property Tree Library begins now (the 18th of April) and runs through the 27th of April. Introduction ------------ This fairly high-level library consists of the following facilities: 1. a generic recursive property-tree data-structure 2. generic conversions to/from this data-structure from/to a. xml-files b. ini-flies c. json-files d. windows registry files As an example of how powerful the library is, consider this tutorial: - http://kaalus.atspace.com/ptree/doc/index.html#five_minute_tutorial The library may be downloaded from - the boost file vault http://boost-consulting.com/vault/ (property_tree_rev5.zip) - tinyurl: http://tinyurl.com/fkt7r - boost sandbox: http://www.boost.org/more/mailing_lists.htm#sandbox (look in boost/property_tree and libs/property_tree) The documentation may be viewed online at - http://kaalus.atspace.com/ptree/doc/index.html If your find the above interesting, please consider submitting a review to the boost developer mailing list: - http://www.boost.org/more/mailing_lists.htm#main You might end up using several hours on a review, but the end result could be a superb library that will save you weeks of work. Notes for reviewers ------------------- When writing your review, you may wish to consider the following questions: * 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. In particular, consider if you can answer the following questions: - was the library suitable for your daily xml-tasks? If not, what was missing? - was the library's performance good enough? If not, can you suggest improvements? - was the library's design flexible enough? If not, how would you suggest it should be redesigned to broaden its scope of use? best regards Thorsten Ottosen, Review Manager

2 1

coroutine library?
by Victor Condino 29 Apr '06

29 Apr '06

Has anyone considered developing/submitting a coroutine library for boost? I've been developing C/C++ for years, and only just discovered how incredibly useful userspace single-threaded multitasking is, if you want to avoid the huge overhead of POSIX threads, and don't mind having to explicitly yield to other threads in your code (indeed, this makes the issues of concurrency and synchronization between threads just much simpler). I've written a wrapper around PCL (http://www.xmailserver.org/libpcl.html) and have since found it to be at least as useful as many of the other boost libraries in my last few projects, in particular in a select-driven single-thread socket server which i am working on now.

5 9

Re: [boost] [SoC] Specialized containers with Boost.MultiIndex
by Matias Capeletto 29 Apr '06

29 Apr '06

Hi, all, especially Joaquin... I am planning to submit an application to SoC. I will love to make real the specialized containers you mention and try to include some useful others. I want to get involved in this project as a way to learn a lot and get close to boost. I already been active in some discussion here and I like it very much. I live in Argentina, so we can communicate in spanish if you wish too :) This is my last year in electronic engineering, in my university you are allowed to choose the course of your study... I am specialized in signal processing, algorithms and data structure and math. I am that kind of electronic guy that was seeking to reach the bottom of the silice and when finally get there, realized that he likes a little more abstraction and get back to programming. I love the math that supports electronics (Fourier, theory of operators, functional analysis), the engineering view, etc... but give me a language like C++ to tell the machine what I want to do. Is the list the place to talk this about of? I'm sending some comments on the requirements... > Requirements > > * Intermediate-to-high level in C++, with emphasis in generic > programming (templates). high level in C++, love the language, love the standard that is behind it, love the way boost is trying to enhance it. > * Knowledge of the STL framework and design principles. Of course, knowledge > of Boost in general and Boost.MultiIndex in particular is a big plus. I have read a lot and thought a lot about the stl. I am very familiar to the framework. The last 6 months I spend several hours reading boost documentation, because I was fascinating by the clean design and power of each library. After reading the kind of discussion in this list (I have read every mail sent to the list from two weeks ago) I'm starting to understand why this is possible... B.MI was one of my favorites. > * Acquaintaince with at least two different C++ programming evironments. I usual program in VS2005, but I have a Linux system with g++ to test my designs. > * Some fluency in the English language; subsequent reviews of the documentation > can help smooth rough edges here, though. No problems here (I think, maybe my English is not good enough) > * A mathematical inclination and previous exposure to a formal Algorithms course > would help very much. Love math, love algorithms. I have taken several courses in algorithm and theory of algorithms. > * A craving for extreme quality work. I'm a lit bit obsessive about quality. :)

2 1

[plugin] problems with plugin base class
by Tim Blechmann 29 Apr '06

29 Apr '06

hello boost devs, using the plugin library from the boost-sandbox, i experience problems in the following two cases: - the base class of the plugin accepts parameters: *** Creating an instance of plugin class Could not load weapon: Boost.Plugin: Can't cast to the right factor type - the base class of plugin is inherited from another class: Could not load weapon: Boost.Plugin: Could not open shared library './library.so' i've added both cases to the example sources and attached them, would be awesome, if this could be made working ... although i'm not really familiar with the plugin internals, i'd be willing to test any code, the plugin developers send me... thanks in advance ... tim ps: please cc any response to me, since i'm a posting-only member. pps: since sourceforge currently seems to have some problems with synchronizing anonymous and developer's cvs, please also send me patches -- TimBlechmann(a)gmx.de ICQ: 96771783 http://www.mokabar.tk Linux is like a wigwam: no windows, no gates, apache inside, stable.

1 0

Re: [boost] Possible class submission: Sparse Array
by Sohail Somani 29 Apr '06

29 Apr '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Spencer Collyer > Sent: Thursday, April 27, 2006 12:11 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Possible class submission: Sparse Array > > On Wed, 26 Apr 2006 12:33:06 -0700, Sohail Somani wrote: > > > Would there be a bounds type for specifying runtime bounds? > It seems the > > upper bound if specified, can only be specified at compile > time and this > > would limit the size of your arrays... Or is this by design? > > Because the bounds checking is specified using an inherited > policy class, > there is in principle no reason why run-time bounds cannot be > used, and I > did indeed look at doing this. I had figured this was the case, just wasn't sure :) > The option I came up with was to have a set_limit function on > the bounds > policy which you would call to define the limits at run time. The only > reason I haven't gone ahead and done the work to implement run-time > limits as yet is because I'm still not sure about the answers to a few > questions: I think you can have the sparse array implementation have an overloaded constructor that takes an instance of the policy. With a set_limit you may end up having invalid arrays for some length of time. Then, I don't think there is anything stopping you from having a reset_bounds/resize type function, but I'd rather only have them be set once as you suggested. To be honest, I'm quite used to having runtime dimensions specified and ublas's sparse arrays interface is pretty good this way. Thanks for your email! Sohail

2 2

Report from Berlin C++ Standards Committee meeting
by Beman Dawes 29 Apr '06

29 Apr '06

The C++ Standards Committee met last week in Berlin, Germany. Of interest to Boosters: * All of TR1 except special functions has been voted into C++0x, the next standard. Special functions were supported by the Library Working Group (LWG), including vendors such as Dinkumware, but they didn't fly in full committee. Compiler vendors indicate great worry about support costs. This vote isn't necessarily the end of the story since support for special functions was strong, although not quite enough to achieve the consensus needed. (The committee will only go ahead if there is consensus - a simple majority isn't good enough.) * Boost Filesystem was voted into TR2. * Boost Lexical Cast has been tentatively accepted by the LWG for TR2. * Boost Any has been tentatively accepted by the LWG for TR2. * A Boost Date-Time query was presented at the last meeting, and LWG members again in Berlin indicated interest in seeing a full proposal for TR2. * A Boost Networking [asio] query was presented, and the LWG has indicated their interest in a full proposal for TR2. The developer of a competing proposal has graciously thrown his support behind the Boost proposal, and may propose some additional higher level functionality. * Boost Threads has been reaffirmed as the LWG's choice as the basis for a TR2 threading library. Pete Becker's www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1907.html is the most recent version of the proposal. It will be refined and modified as work progresses. Howard Hinnant plans to propose unifying the lock classes into scoped_lock/shared_lock and possibly one other class. Pete will propose a function to access the underlying operating system handles to allow access to non-portable functionality. I've committed to review error handling to ensure handling of operating system errors is consistent between all TR2 libraries. * It looks more and more likely that Concepts will go into C++0x. If Concepts do go into the core language, the LWG has indicated their intent to percolate Concepts throughout the Standard Library. (Concepts were being held up by two competing proposals, but those two proposals are in process of being coalesced into a single proposal by Bjarne Stroustrup and Doug Gregor.) The next committee meetings are: October, 2006, Portland, Oregon. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1946.htm Spring, 2007, Oxford, England. Fall, 2007, Kona, Hawaii This coming October is the deadline for TR2 proposals. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html --Beman

19 54

[plugin] problem with headers in different objects
by Tim Blechmann 28 Apr '06

28 Apr '06

hi all, currently it's not possible to include boost/plugin.hpp or boost/plugin/virtual_constructors.hpp from different object files with gcc-3.4.6 including plugin.hpp from two object files: tim@laptop ~/sandbox $ g++ main.cpp t1.o t2.o t2.o: In function `boost::dynamic_visitor_base::~dynamic_visitor_base()': t1.cpp:(.text+0x0): multiple definition of `boost::dynamic_visitor_base::~dynami c_visitor_base()' t1.o:t1.cpp:(.text+0x0): first defined here t2.o: In function `boost::dynamic_visitor_base::~dynamic_visitor_base()': t1.cpp:(.text+0x28): multiple definition of `boost::dynamic_visitor_base::~dynam ic_visitor_base()' t1.o:t1.cpp:(.text+0x28): first defined here t2.o: In function `boost::dynamic_visitor_base::~dynamic_visitor_base()': t1.cpp:(.text+0x50): multiple definition of `boost::dynamic_visitor_base::~dynam ic_visitor_base()' t1.o:t1.cpp:(.text+0x50): first defined here t2.o:(.bss+0x0): multiple definition of `(anonymous namespace)::_1' t1.o:(.bss+0x0): first defined here t2.o:(.bss+0x1): multiple definition of `(anonymous namespace)::_2' t1.o:(.bss+0x1): first defined here t2.o:(.bss+0x2): multiple definition of `(anonymous namespace)::_3' t1.o:(.bss+0x2): first defined here t2.o:(.bss+0x3): multiple definition of `(anonymous namespace)::_4' t1.o:(.bss+0x3): first defined here t2.o:(.bss+0x4): multiple definition of `(anonymous namespace)::_5' t1.o:(.bss+0x4): first defined here t2.o:(.bss+0x5): multiple definition of `(anonymous namespace)::_6' t1.o:(.bss+0x5): first defined here t2.o:(.bss+0x6): multiple definition of `(anonymous namespace)::_7' t1.o:(.bss+0x6): first defined here t2.o:(.bss+0x7): multiple definition of `(anonymous namespace)::_8' t1.o:(.bss+0x7): first defined here t2.o:(.bss+0x8): multiple definition of `(anonymous namespace)::_9' t1.o:(.bss+0x8): first defined here collect2: ld returned 1 exit status t1.cpp & t2.cpp contain: #include "boost/plugin.hpp" main.cpp contains: int main(){return 0;} similar things happen with boost/plugin/virtual_constructors.hpp ... not sure, if it's a but in the library, or a compiler bug ... cheers ... tim -- TimBlechmann(a)gmx.de ICQ: 96771783 http://www.mokabar.tk You can play a shoestring if you're sincere John Coltrane

3 3

Re: [boost] [Boost Review] Do property_tree and program_options overlap?
by bwood 28 Apr '06

28 Apr '06

: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message :>"Ivan Vecerina" <ivec_at_[hidden]> wrote in message :> It's not like boost::serialize currently dominates the world :> of persistent storage. : :So? I see a potencial for it to become a standard like iostreams now. I'm glad you added the part about iostreams as I think it hits the nail on the head. I agree with Andrei's opinions of iostreams. http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread /86a5a3f804c84ea4/48842ae2fd029ce6?hl=en#48842ae2fd029ce6 While iostreams is a part of the standard that doesn't mean it is a healthy part of it. I think eventually someone will develop something better. You've been touting multi_index here as well. I wouldn't balk if you suggested adding it to the standard. Brian www.webEbenezer.net

3 4

Property Tree library review
by Jose 28 Apr '06

28 Apr '06

I vote a weak NO. I would change this to yes once the library has some decent functionality to select values by path (see the related thread on testing the PT xml parser) I also have some general comments about the name, scope and design of the library: 1. The library name I think the library should be named after what it does (not how it does it). The property tree is the container but in this case the library is about program configuration - Boost.ProgramConfiguration (there are other libraries where a more technical name is better because of the library scope, like the property map library, but not for this one) 2. Relation to other libraries I think the relation to the Boost.ProgramOptions library is not clear. Maybe it should ! Without having used the PO lib, I think the PT lib is a superset, focusing on both command-line and file-based configuration. The use of the Spirit library for the xml parser is good. Using other boost libraries like serialization, .. do not seem correct for this specific library. 3. The scope This is the strong point of this library. I has the potential to be widely useful as it can be used in any program to load and save the program settings 4. The design * The strong points: I think the only strong point is the focus on simplicity. I think this attracts everybody attention as the library can be quickly used and everybody sees and specific use right away but I see many design issues too - see below * The weak points: a) The container The use of a generic tree container has not been seriously considered. The argument against using a generic container is that it would complicate the library. I don't agree. For a specific example check the tree.hh library: an STL-like C++ tree class http://www.aei.mpg.de/~peekas/tree/ This library provides a generic tree container and well thought-out interfaces. It is as easy or easier to use than the PT lib b) The parsers (library vs utilities) It is not clear whether the parsers are utilities or whether the PT lib is supposed to provide some framework to build specific parsers. E.g. * How easy is to use this existing file format with ":" separator name1: value1 name2: value2 * How easy is to use a more advanced format, e.g. a CSS file h1 { font-family: arial; font-size: 12px; } .show { ... } This also should be explained in the docs. d) Relation to standards The library has been presented many times as a sort of DOM ... >From the docs: "One can think of it as a sort of Document Object Model, which is minimalistic, ..." I think this is a fallacy, because there are standards like the W3 DOM and XPath that are widely useful and widely used, and taking these out of the design just limits what the library can do (if the standards were both not widely useful and widely used then I would think otherwise). Again, the argument is simplicity but I think with a generic tree container, like tree.hh, these standards can be supported without complicating the usage. Conclusion ---------------- Maybe one way out of this conundrum is to consider the current library as the basic one and later have an advanced version that really provides the generic container and the proper query mechanisms.

4 5