- Boost - lists.boost.org

Re: [boost] Including thread.hpp causes coredump on AIX
by chris.grayson＠database-brothers.com 02 May '06

02 May '06

I don't know why my posts aren't coming through - here's my third try at sending my original message, with the three source files (again). I'm trying to use the Boost threads library in an application on AIX 5.3, but I'm having serious trouble. I've narrowed it down to the test code below. When both "main.cpp" and "Class1.cpp" include <boost/thread/thread.hpp>, the compiled application coredumps whenever an exception is thrown in Class1. When the thread.hpp include statement is commented out - in either file - the exception is thrown and caught fine, with no coredump. Note that neither main.cpp nor Class1.cpp *uses* any Boost threads code. This problem occurs with both gcc 3.3.2 (as provided by IBM in their "AIX Toolbox") and gcc 3.4.6 (as built from source). In both cases, the AIX linker "ld" is used, per both IBM and GNU's recommendations. This seems to only happen on AIX 5.3. The same code on Linux, Solaris and AIX 5.1, compiled the same way, does not crash in this way. This also occurs with both Boost 1.33.0 and 1.33.1. I'm currently compiling against the latest Boost source (1.33.1), though it's not built, since I'm only including headers, and not linking anything. ---- main.cpp ---- #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; } ---- Class1.h ---- class Class1 { public: void noop(); }; ---- Class1.cpp ---- #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; } The previous files are built and run with these commands: > g++ -o crasher -I$HOME/boost/boost_1_33_1 main.cpp Class1.cpp > ./crasher I do get these linker errors: ld: 0711-224 WARNING: Duplicate symbol: ._GLOBAL__I_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: ._GLOBAL__D_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__F_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__I_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__D_thread_creds_t ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. Any help will be greatly appreciated. Thanks, Chris Grayson Database-Brothers, Inc.

2 1

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

02 May '06

----- Mensaje original ----- De: Matias Capeletto <matias.capeletto(a)gmail.com> Fecha: Lunes, Mayo 1, 2006 6:59 am Asunto: Re: [boost] [SoC] Specialized containers with Boost.MultiIndex > I am finishing my application to the (M)ulti (I)ndex (S)pecialized > (C)ontainers (from now on MISC, do you like it?) for the SoC. > I am constructing a quickbook with a formal proposal, interface > design, project plan and personal information. I want to share it with > the list. I will really appreciate some feedback before sending the > application, specially from Joaquin. Can i post it here when it is > mature enough? Sure, I'm eager to read it. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 6

[fusion] How does is_pointer< Sequence > work?
by Andreas Huber 02 May '06

02 May '06

Hi Joel & Dan Going through the fusion quick start, I'm wondering how the expression ... for_each(filter_if<boost::is_pointer<Sequence> >(seq), print_xml()); ... could ever work? Shouldn't that rather read similar to ... for_each(filter_if<boost::is_pointer<_> >(seq), print_xml()); ... so that the _ placeholder can be replaced with the individual types in the sequence? Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

4 3

Re: [boost] [Boost Review] Do property_tree and program_options overlap?"
by JOAQUIN LOPEZ MU?Z 01 May '06

01 May '06

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Lunes, Mayo 1, 2006 6:43 pm Asunto: Re: [boost] [Boost Review] Do property_tree and program_options overlap?" > "bwood" <brass(a)mailvault.com> wrote in message > > 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. > > My point was that we need another level of indirection an in-Order > indexing > (along with different orders for the same data). > Hello Gennadiy, It'd be great if you can resume that discussion of ours where we left: http://lists.boost.org/Archives/boost/2006/04/103441.php This last response I sent on Apr 20th, after some inactivity days, so maybe you just didn't notice it. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[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

The fate of Boost.Logging ?
by Zrubavel Zodikovich 01 May '06

01 May '06

Hi, Are there any life signs coming from Boost.Logging library which was withdrawn from review last November ?

3 2

[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

[soc] mentoring acceptance pending
by JOAQUIN LOPEZ MU?Z 01 May '06

01 May '06

Hello, I applied for mentorship for Boost yesterday, my application is listed as acceptance pending. Does approval depend on Google, or on the Booster who has taking on administrative responsibilities (looks like Jeff from his recent SoC activity)? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1