April 2006 - Boost - lists.preview.boost.org

[numeric/conversion] Patch for BCB2006
by Nicola Musatti 02 May '06

02 May '06

Hallo, The following patch appears to be necessary to get BCB2006 to pass the conversion tests. If nobody has any objections (Fernando?) , I'll commit it in a few days. Cheers, Nicola Musatti ******Index: cast.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/conversion/cast.hpp,v retrieving revision 1.8 diff -d -u -r1.8 cast.hpp --- cast.hpp 27 Jun 2005 15:05:12 -0000 1.8 +++ cast.hpp 27 Apr 2006 20:43:24 -0000 @@ -22,7 +22,7 @@ #include <boost/detail/workaround.hpp> -#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, == 0x564) +#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) # include<boost/numeric/conversion/detail/old_numeric_cast.hpp>

2 3

[SoC][Act]Concurrency library
by Matt Calabrese 01 May '06

01 May '06

For the past month or so I've been working on a concurrency library which brings active types, atomic types, and parallel loop constructs and algorithms to C++. I am familiar with some of the concurrency projects already underway, though I'm sure my library would be able to coexist. I plan on proposing through SoC sometime later this week. Over the past two days I've also begun writing up some documentation using QuickBook to give a general idea as to the design of the library. Though I do have a lot of features already implemented, there is still a very large amount of work to be done prior to completion. Some feedback before I make the formal proposal would be nice, and it'd also be great to see if anyone is interested. Keep in mind that the documentation is only a rough outing and so there are a few unconnected links, but I do include a brief introduction and some basic usage examples including code snippets. The library is reference to as Surge.Act as that is the namespace I use for my personal libraries, though it will of course be changed to Boost.Act if it were to be accepted. http://members.gamedev.net/Rivorus/surge/html/index.html For those familiar with the concept of futures and are confused as to why they are not mentioned, I will be adding all of that information to the rationale over the upcoming few days. I also apologize for not having better code examples. -- -Matt Calabrese

4 7

Re: [boost] [Boost Review] Do property_tree and program_options overlap?"
by bwood 01 May '06

01 May '06

Gennadiy Rozental wrote: >> You've been touting multi_index here as well. > >Not at all. If you follow my recent concern with multi_index design I >actually believe it's lacking. I read those and was sympathetic to the terminology arguments you made. L?pez Mu?oz believes it is too late to make those sort of changes. I disagree with him on that, but it isn't clear enough yet to me what would be better terminology. I didn't follow the other matter you raised in those posts. Please correct me if I'm wrong, but it seems B.MI's serialization forces you to receive a B.MI instance with the same number of indices as was sent. While on one level it is impressive that B.MI preserves the relative order of equal elements, it has a cost. If you have a B.MI with 3 indices in a server and only need one or two indices in a client, you have some work to do. In order to accomplish this I think you would have to receive a B.MI with the same indices as was sent and then write code that copies the contents of that B.MI to either a simpler B.MI or an STL container. Does the preservation of the relative order of elements matter more than this sort of flexibility? Brian www.webEbenezer.net

2 1

[filesystem] Some questions about string use
by Ion Gaztañaga 01 May '06

01 May '06

Hi to all, While revising a bit the boost::filesystem error/exception use for looking a model for interprocess library and after reading the N1934 "Filesystem Library Proposal for TR2 (Revision 2)" I'm a bit concerned about the heavy use of std::string/string_type in the library. The following functions return some kind of path as value type: // observers const string_type string() const; const string_type file_string() const; const string_type directory_string() const; const external_string_type external_file_string() const; const external_string_type external_directory_string() const; string_type root_name() const; string_type root_directory() const; basic_path root_path() const; basic_path relative_path() const; string_type leaf() const; basic_path branch_path() const; I know that syntactically this is nicer and we can have RVO: string_type str = path.string(); But when iterating through directories I find that that returning a temporary object that must allocate/copy/deallocate hurts my performance paranoia. Even with move semantics we have a an overhead: std::vector<std::path> paths; //fill with paths std::path::iterator beg = paths.begin(), end = paths.end(); for(; beg != end; ++it){ std::path::string_type str = it->root_name();//temporary created str += "append some data"; std::cout << str; } Couldn't be better (although uglier) to take a reference to a string that will be filled? void fill_root_name(string_type &root_name) const; ... //////////////////////////////////////////////////////////////////// std::vector<std::path> paths; //fill with paths std::path::string_type root_name; root_name.reserve(PATH_LENGTH); std::path::iterator beg = paths.begin(), end = paths.end(); for(; beg != end; ++it){ it->fill_root_name(root_name); str += "append some data"; std::cout << str; } This way we only allocate memory if we don't have enough place in our string. We can also reserve it beforehand to speed up code. Apart from this I see that path::iterator has a string member. dereference will return a reference to that member but an iterator is supposed to be a "lightweight" pointer-like abstraction, which is value-copied between functions. A string member, in my opinion, converts an iterator in a heavy class (that depends on the string length, but an small string optimization of 16 bytes is not going to help much). Now that filesystem is proposed for the standard I would like to ask boosters (and Beman, of course) if they find these performance concerns serious enough. Regards, Ion

10 29

Re: [boost] [SoC] Specialized containers with Boost.MultiIndex
by JOAQUIN LOPEZ MU?Z 01 May '06

01 May '06

----- Mensaje original ----- De: Matias Capeletto <matias.capeletto(a)gmail.com> Fecha: Sábado, Abril 29, 2006 4:54 am Asunto: Re: [boost] [SoC] Specialized containers with Boost.MultiIndex > Hi, all, especially Joaquin... > > I am planning to submit an application to SoC. I will love to make > realthe specialized containers you mention and try to include some > useful others. [...] > Is the list the place to talk this about of? Hello Matías, good to know a Spanish-speaking fellow, we're only a handful round here. The way SoC is organized, I think the procedure involves your sending an application thru SoC online tool starting May 1st. Yours, along with all other applications related to Boost, will then be routed by Google to Boost mentors, which will do then the selection and P2P discussion with applicants. In your case, since you're interested in the B.MI proposal, I understand it's gonna be I who will be evaluating your application. I don't really know what the application format and required information are (that depends on the SoC online tool, I guess) but I can tell you what I'd like to see in those submissions under my evaluation responsibility: * As much CV data as possible, academic performance, programming-related courses, etc. * Programming experience: University assignments, open source projects, freelance activities, whatever. If you can point to some code of yours, so much the better. * As per the concrete proposal, expand on the idea described on the Boost wiki along the following directions: * A detailed description of your activity, specially if you plan to add some extra bonuses to the original idea (some other specialized container, for instance). Do not make a wishlist, but rather provide a realistic statement of goals you feel confident to achieve within the time schedule imposed by SoC. * Environmental details: IDEs you'll be using, how you'll do the docs, etc. * A roadmap of the project, or some approximation to it. In general, take into account there can be other applicants for the same project, so not only must you be convincing the mentors you're fit for the project, you must make it it clear you're the fittest :) Good luck with your application, I'll be seeing you around during these weeks, come back here if you have tecnhical doubts while designing your application. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

New Code Of Summer project
by Carlo Wood 01 May '06

01 May '06

Hi, I just subbed. Before, I was only on boost-users, where there was a single mail about Code of Summer 2006. That mail said that if you had a new idea for a project, then you could add it to the wiki. I've added it to the wiki now, but I suppose it has to be approved too more or less. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summe… -- Carlo Wood <carlo(a)alinoe.com>

3 5

Including thread.hpp causes coredump on AIX
by Chris Grayson 30 Apr '06

30 Apr '06

#include <iostream> #include "Class1.h" #include <boost/thread/thread.hpp> main () { std::cout << "starting main()" << std::endl; Class1 c; c.noop(); std::cout << "exiting main() normally" << std::endl; } #include <iostream> #include "Class1.h" #include <boost/thread/thread.hpp> void Class1::noop () { std::cout << "entering Class1::noop()" << std::endl; try { std::cout << "..throwing exception" << std::endl; throw (2.1); } catch (...) { std::cout << "..caught exception in Class1.noop()" << std::endl; } std::cout << "..leaving Class1.noop()" << std::endl; return; } class Class1 { public: void noop(); };

2 2

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

30 Apr '06

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

29 208

Re: [boost] [Boost-users] portable uuid generator
by Tim Blechmann 30 Apr '06

30 Apr '06

hi andy, to use your guid library with gcc-4.1, i had to change it according to the attached patch ... cheers ... tim -- TimBlechmann(a)gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

1 0

[Boost Review] Property tree review
by Jeff Hardy 30 Apr '06

30 Apr '06

I'm going to vote YES on inclusion of the Property Tree library. It has its faults, but I think it's useful enough right now to be part of Boost. * What is your evaluation of the design? The most valuable parts of the library are the parsers and the path functions. I agree with what others have mentioned: the paths should be seperate from the tree. I would be using it to parse various file formats into a tree, and then use my own path language on top of that. For me, then, the parsers are the most important part of this library. Having a (mostly) common structure is very nice. The reading and writing interface is as simple as possible; navigating the tree is also resonably simple. * What is your evaluation of the implementation? I didn't inspect the implementation closely, but I did notice some things during use. I don't like how XML attributes are stored. It should at least be an option to treat <x y="1" z="2" /> and <x> <y>1</y> <z>2</z> </x> as the same structure, without the "<xmlattrs>" node. If there's a confilict between an attribute name and a child element name, then reading/writing should fail. The ability to preserve comments in a file would be very nice. * What is your evaluation of the documentation? A bit sparse. The reference was mostly what I used, but more examples in the docs is always a good idea. A better "mission statement" about what the library is for would help as well; right now, it's not very clear what the author thinks the library is trying to do. The tree descriptions used in the descriptions of the parsers are not very clear; specifying what is in child.second.data() and what is in child.first should be explicit. An example of directly manipulating the tree (without using get()/put()) would be useful as well. * What is your evaluation of the potential usefulness of the library? As a general XML parser, it's not very useful (no namespaces, etc.); as a generic tree, it's not very useful (not general enough). As a utility for parsing various file formats into similar data structures (and writing them back), it's useful. Loading program configuration seems to be the primary goal, and it does that well enough. Trying to get the library to do other things might be stretching it too far. * Did you try to use the library? With what compiler? Did you have any problems? Yes, with MSVC 8. I had no problems beyond my own reading incomprehension. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I adapted the backend of my own configuration system (which previously used TinyXML) to use property trees. However, I didn't use the get*() functions, since I have my own path system already built. * Are you knowledgeable about the problem domain? Resonably. I plan on using the library whether it is accepted into Boost or not, and I'd like to thank Marcin for his work. -Jeff Hardy

8 14

[SoC] new bcp
by Felipe Magno de Almeida 30 Apr '06

30 Apr '06

Hi, I would like to propose creating a new bcp tool. Using the BGL and Wave for handling better the dependencies. Would it have any chance of getting accepted? How much people need this? Thanks, -- Felipe Magno de Almeida

6 6

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

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