April 2006 - Boost - lists.boost.org

[Property Tree]Problem domain
by Gennadiy Rozental 30 Apr '06

30 Apr '06

Hi, When I my review I never thought it will cause any long discussion. It's all very clear in my little corner. I must admit that my understanding significantly changed since. But my main point remains the same. I do not have time to reply to all the related messages. So let me give it another try to convey my point clearly: I don't see any reason to discuss library interfaces and even more implementation without clearly stated problem domain. How could you tell whether one interface/implementation is better than another without understanding how it's planned to be used? Now, based on library docs, we could try to give it some educated guess. Unfortunately this lead me to decide that this library is not acceptable in none of the potential problem domains. Don't get me wrong. The library could be used by some users. But the same is true for almost any one. But my criteria for library acceptance is really simple: library should be usable for most users in problem domain. "Some" users doesn't cut it. So let's see. Option 1: Library to support program runtime parameters originated in different sources ================= >From my standpoint library is missing several crucial features to qualify in this domain. a) No decent CLA parser b) No conflict resolution. If your parameter coming from different sources it's obvious that at some point you need to decide which parameter to prevail: one from config file or one from CLA. c) No automated validations Configuration even more then any other human input require strict validation (more because it's frequently produced by third parties - not library designers. That includes end-users, operation department remote library user etc). We need some notion of "schema" support. d) No automated processing/notification. Many application prefer to build their runtime parameter support as event driven system. No support for this is presented. And these are just major deficiencies. Option 2: Library for permanent storage of application configuration that does not have to be human editable . ================== My primary objection in this domain is that an alternative better solution exist. I would use Serialization library and save/load directly C++ objects. As for the "non human editable" clause, IMO if you decide to present a way for the user to edit configuration through application, no need to support also editing using some external means. If you need some of the parameter to be externally editable (but not from within application) - use separate storage for them. Option 3: Generic facility to manipulate hieratical data with permanent storage support. ========================== My main objection in this domain is that author decided that his particular data structure would be good enough for all usages. The word "particular" is main offender here. I don't believe any "particular" data structure would be good enough. Some novice users may use simple structure with class Leaf and class Brunch. Some prefer generic tree one. Some need compile time polymorphism only. Some could use runtime one. Some Would use boost::variant as value. IMO save/load side of the library like this would need to be made to work with any data structure satisfying some concept. The same applies to access methods (This is the reason why you need to switch to free function based interfaces) Option 4: Facility to manipulate hieratical application configuration that have to be human editable and application writable at the same time. ======================= First of all I need to remark that this domain is kind of limited (and internally conflicting IMO - I don't see why you need configuration editable both ways). This option struggle from the same problem as option 3 - hardcoded in-memory presentation. Also I believe that this domain also require for loaders/savers to keep original formatting and/or comments. On the other hand This library doesn't need CLA/registry support in this case. While it's config files support should be more flexible. Author need to decide which option match his understanding. But IMO library in this current form isn't acceptable in any of them. Regards, Gennadiy

6 10

[foreach] BOOST_FOREACH(x, *this)
by Shunsuke Sogame 30 Apr '06

30 Apr '06

Hi gurus, VC++7.1/8 complains: error C2355: 'this' : can only be referenced inside non-static member about: struct xxx : std::vector<int> { void test() { BOOST_FOREACH(int x, *this) { } } }; GCC compiles. Is this maybe a bug of VC++? -- Shunsuke Sogame

4 6

Re: [boost] Including thread.hpp causes coredump on AIX
by Chris Grayson 30 Apr '06

30 Apr '06

1 0

there already is an ASIO.
by James McCartney 30 Apr '06

30 Apr '06

This library's name should be changed as it will lead to confusion. There is already an audio i/o library called ASIO which has been in use for years in audio applications and supported by many software vendors and hardware manufacturers. http://en.wikipedia.org/wiki/Audio_stream_input_output http://whatis.techtarget.com/definition/0,,sid9_gci213488,00.html -- --- james mccartney

23 44

[SoC] publicity suggestion
by JOAQUIN LOPEZ MU?Z 30 Apr '06

30 Apr '06

Wouldn't it be a good idea to put a small notice on the news section of boost.org about Boost participating in the SoC project? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[pool] Patch for BCB2006
by Nicola Musatti 30 Apr '06

30 Apr '06

Hallo, if nobody has any objection I plan to commit the enclosed patch in a couple of days. Cheers, Nicola Musatti ******Index: pool_alloc.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/pool/pool_alloc.hpp,v retrieving revision 1.9 diff -d -u -r1.9 pool_alloc.hpp --- pool_alloc.hpp 28 Sep 2004 12:55:45 -0000 1.9 +++ pool_alloc.hpp 29 Apr 2006 06:47:43 -0000 @@ -19,9 +19,11 @@ // boost::singleton_pool #include <boost/pool/singleton_pool.hpp> +#include <boost/detail/workaround.hpp> + // The following code will be put into Boost.Config in a later revision -#if defined(_RWSTD_VER) || defined(__SGI_STL_PORT) - // Needed, as of bcc 5.5 and STLPort 4.5b8 +#if defined(_RWSTD_VER) || defined(__SGI_STL_PORT) || \ + BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) #define BOOST_NO_PROPER_STL_DEALLOCATE #endif

2 1

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