- Boost - lists.boost.org

Possible class submission: Sparse Array
by Spencer Collyer 30 Apr '06

30 Apr '06

I'd like to canvas opinions on whether it is worth submitting a class I've developed to Boost. It is a policy-based sparse array class. I'm aware there is a sparse_vector class in the uBLAS library, but when I looked at it it didn't seem to offer the degree of flexibility I needed, so I developed my own. Like a lot of things, it grew a little during development, but I've tried to keep the interface as close to std::vector as seemed sensible. To try and make it as flexible as possible, I've implemented it using four policies, as follows: bounds: This determines what the bounds on the sparse_array are, and how values that exceed them are handled. For example, the 'unbounded' policy allows virtually any positive value of the subscript type to be used, 'bounded' only allows values within the (compile-time specified) max value and throws if a subscript exceeding this is given, while 'clamped' makes such value equal to the max value. iterator: This determines how the limits on iterators are defined. So it is possible to specify that iteration should be over the whole range of the sparse_array, or that it should only be from the lowest assigned subscript to the highest assigned subscript. value: This policy is currently used to define the default value for unassigned elements of the sparse_array, and also to determine how default values are handled in cases such as assigning from one sparse_array to another. storage: This allows the user to specify how the underlying storage for the sparse_array is handled. Currently I only have one policy defined (std_map, which unsurprisingly uses a std::map for the storage), but policies to use hash maps or something akin to Loki's AssocVector could be easily defined. I'd like to know if people would be interested in seeing such a class in Boost before I plunge into writing up the documentation (which is currently pretty sparse, and consists primarily of the comments in the code) and finishing off all the test programs prior to submission. -- <<< Eagles may soar, but weasels don't get sucked into jet engines >>> 5:43pm up 39 days 5:16, 19 users, load average: 0.06, 0.05, 0.04 Registered Linux User #232457 | LFS ID 11703

6 18

[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 29 Apr '06

29 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 29 Apr '06

29 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