- Boost - lists.boost.org

Google Summer of Code -- Call for Participation / Schedule
by Jeff Garland 30 Apr '06

30 Apr '06

All - (cross-posted to the user list so the larger Boost community sees this) Readers of the developer list may have seen that Boost has been accepted as a participating organization. See http://code.google.com/soc/boost/about.html for the initial Boost Summer of Code page. Now for the hard part. We have a fairly tight schedule to get organized on project proposals and student applications: May 1, 2006: - Application period opens for student proposals May 8, 2006: -Student proposals due by 17:00 Pacific Daylight Time If you are interested in mentoring or doing a project please let us know as soon as possible. If you have project ideas, please update: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… If you want to mentor or are planning a student application please either post to the list or to the moderators list (see http://www.boost.org/more/moderators.html for details). Thx! Jeff

5 6

[shmem] New bugfix version in Boost Vault and sandbox cvs
by Ion Gaztañaga 30 Apr '06

30 Apr '06

Hi to all, I've just uploaded to Boost Vault a new version of Shmem (0.92). You can download it here: http://boost-consulting.com/vault/index.php?direction=&order=&directory=Mem… Online documentation here: http://ice.prohosting.com/newfunk/boost/libs/shmem/ Changes in 0.92: ----------------- * Solved bugs in flat_xxx insert functions. * Solved ambiguous windows native function calls with some header orderings. * Changed named_mutex to support scoped_lock. * Added missing <exceptions.hpp> include in named_mutex. * Added get_instance_type, get_instance_length and get_instance_name functions to front-ends. Warning: -------- Peter Johson has detected a problems with Vc8 and global optimization (/Og). Some tests have shown a possible compiler bug. vc7.1 has no problems with /Og. I'm investigating this but meanwhile I recommend disabling /Og (which is deprecated in vc8) when using Shmem. Special thanks to Peter Johnson, Harold Pirtle and Jan Stetka for their help on this version. Regards, Ion

1 0

is_reference current implamentation (why so complex?)
by Dmitry Sychov 30 Apr '06

30 Apr '06

Hello, On my VC 8.0 I've successfully rewrote "is_reference" implementation (from is_reference.hpp) http://www.boost.org/doc/html/boost_typetraits/reference.html#boost_typetra… down to the following: //////////////////////////////////////////////////////////////////// // IMPLEMENTATION template <class T> struct _wrapper {}; template <class T> T& is_ref_fn(_wrapper<T>); char is_ref_fn(...); template <class T> struct _is_ref { static bool const value = sizeof is_ref_fn( _wrapper<T>()) == 1; }; // USAGE void main() { bool is_ref_false = _is_ref<int>::value; bool is_ref_true = _is_ref<int&>::value; } //////////////////////////////////////////////////////////////////// I understand original code - but it uses "is_reference_helper1" and "is_reference_helper2" for the same thing - ie to distingwish between fn pointer size and char size but this could be done in "one pass" (see my is_ref_fn(..) above) also why to compare against fn ptr type and char type when we can compare against 'T' type reference (sizeof(T&) >= 4) and char (sizeof(char) == 1) (see my code) Is it just because on some platforms sizeof(char) != 1 ? If yes we can change 'char' to object with size >= sizeof(T&) to avoid this. Please comment on this. Thanks, Dmitry

4 3

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