- Boost - lists.boost.org

Another Phoenix review
by Tom Brinkman 28 Sep '08

28 Sep '08

I vote yes. I learned functional programming from spirit and have used phoenix for few years, even though it was tucked away in the library. I'm happy that Joel moved it as a first level citizen of boost. My favorite thing about phoenix, or functional programming in general, is that it encourages you to think out of the box. I actively seek out ways to make my code more "functional', and phoenix is an important part of my toolbox. Phoenix and spirit are in my opinion two of the top libraries on boost. Phoenix is mature and deserves to be at the root of the boost tree. Thanks to the authors. Tom Brinkman

2 1

[Windows developers] Linux virtual machine for Boost developers
by Beman Dawes 27 Sep '08

27 Sep '08

In another thread, Anthony Williams wrote: > ... I'll open a trac > ticket, and fix it when I'm next using my linux box. I develop on Windows, and used keep a Linux box around for developing Linux specific code. But lately I've switched to using VirtualBox (www.virtualbox.org) for Linux development. It's free, open source, is a lot easier to use and maintain than separate machines or dual boot configurations, It is also easier to use than other virtualization approaches I've tried, which tended to be fragile. VirtualBox seems particularly well suited for developers who don't want to invest a lot of time to set up a sophisticated virtual environment. Works great with the current Ubuntu distribution. And because it runs as a regular Windows program, it has no impact whatsoever on performance when it isn't running. Works well even on a Windows laptop machine. I'm mentioning this because I'm guessing that Boost has a number of developers who usually develop on Windows, but would occasionally like to work on their libraries in a Linux environment. It can also be hosted on Linux, Mac, and OpenSolaris, and run a variety of guest operating system, but I suspect the Windows host / Linux guest configuration is the one that might particularly benefit several Boost developers, and its the one that I've actually used. --Beman

7 9

Parallelism shift
by Johan Torp 27 Sep '08

27 Sep '08

Hi, I've recently finished my master's thesis which covers the ongoing shift to parallelism. I thought some of you might be interested in reading it. It can be downloaded at www.johantorp.com Best Regards, Johan ABSTRACT The first part of the thesis is an overview of the paradigmatic shift to parallelism that is currently taking place. It explains why processors need to become parallel, how they might function and which types of parallelism there are. Given that information, it explains why threads and locks is not a suitable programming model and how threading is being improved and used to extract parallel performance. It also covers the problems that await new parallel programming models and how they might work. The final chapter surveys the landscape of existing parallel software and hardware projects and relates them to the overview. The overview is intended for programmers and architects of desktop and embedded systems. The second part explains how to use C++'s upcoming memory model and atomic API. It also relates the memory model to classical definitions of distributed computing in an attempt to bridge the gap in terminology between the research literature and C++. An implementation of hazard pointers and a lock-free stack and queue are given as example C++0x code. This part is aimed at expert C++ developers and the research community. -- View this message in context: http://www.nabble.com/Parallelism-shift-tp19704548p19704548.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Phoenix review
by Doug Gregor 27 Sep '08

27 Sep '08

My review of Phoenix follows. I focus mainly on the documentation, because I've studied the Phoenix code-base on various occasions and have always found it to be very clear and of very high quality. That, combined with its extensive use in Spirit, makes me confident in the implementation of this library. I vote to accept Phoenix into Boost. More detailed review comments follow, but my vote to accept the library is not contingent on any changes. In the "Starter Kit", it would really help to state which namespaces (in general) the various functions like "val" and "ref" come from. I don't suspect that "ref" is boost::ref or C++0x's std::ref, but I could imagine that they could possible work with Phoenix. (As an aside: I bet that the references.cpp example here won't compile in C+ +0x, since ref() will be ambiguous). In the "Arguments subsection, second paragraph: "Arguments on the other hand, evaluation to an N-ary function. An argument represents the Nth argument." That's a bit confusing. Both those sentences and the example that follows make it look like argN always returns the last argument in the call, but that's not what happens. argI is an N-ary function that can be called with N >= I arguments and will return the Ith argument. Also in the "Arguments" subsection, there's a parenthetical comment "and it's BLL counterparts: _1, _2, _3, _4, and so on). IIRC, the _# placeholders actually came from Boost.Bind; the Lambda library originally used arg1, arg2, and arg3. In the "Lazy Functions" section, I'm wondering which protocol is being used for the nested "result" class template? Is it the result_of protocol or something else? This section needs a little more information, or a link, if users are going to be able to use this "function". You might also want to make clear that this is *not* std::function or boost::function, although either of those can be used to realize a monomorphic function from a Phoenix function. In the "Organization" section, it would be really, really cool if that library-organization picture was an image map linking each box to the documentation on that section. (But, this is just a fluff comment) In the "Actors" section, there's a note about the ability to set PHOENIX_LIMIT to something other than 10, but the word "macro" never shows up. Please tell the gentle reader that this is a macro. In "Predefined Arguments", nothing says that PHOENIX_ARG_LIMIT is a macro. In "Evaluating an Argument", first sentence, typo "from the those passed in". In "Extra arguments", spello "desireable". In "Composite", PHOENIX_COMPOSITE_LIMIT is certainly a macro, but the note doesn't say so. Also in "Composite", are we talking about 0..N actors or 0..N-1 actors? In the subsection "Operation", the phrase "the containers value_type" should be "the container's value_type". In the documentation for the "switch_ statement", I suggest pointing out explicitly that, to have multiple statements in a case_ or default_, the user will need to wrap the statements in an extra set of parentheses. The alternatively, of course, is to use a syntax like: case_<1>()[cout << val("one") << '\n', cerr << val("hello")], Interestingly, catch_<exception_type>()[ ... ] uses this same syntax; why the discrepancy between case_ and catch_? Or did I miss something? Anyway, now you have me trying to figure out how to tweak switch() to fully support break_() and fall-through from one case to another :) In the "let" documentation, the note about PHOENIX_LOCAL_LIMIT doesn't say that it's a macro/preprocessor constant. In the "Visibility" section, there's this example: let(_a = 1) [ let( _a = 1 , _b = _a // Ok. _a refers to the outer _a ) [ /*. body .*/ ] ] Personally, I would like to see this example be ill-formed. I know it isn't technically feasible to make bind the "_a" in "_b = _a" to the innermost _a, so instead I'd prefer if any use of a variable whose binding has changed within the same "let" would be an error. I *think* this can be done without too much pain through a static assertion, but feel free to ignore this suggestion if I'm wrong. Is "lambda" equivalent to BLL's "unlambda" or "protect"? It might help BLL-savvy users to point out the relationship. Also, BLL's documentation points out that one should use its "protect" when receiving a function object as a parameter. The Phoenix documentation for "lambda" indicates roughly the same thing, but it could be said more directly. For example, a note that advises users to lambda()[] any function object they receive from somewhere else. What level of interoperability can we expect among Boost.Bind, Phoenix, Boost.Lambda, and TR1/C++0x's bind, if any? - Doug

7 19

svn write access
by Andrew Sutton 27 Sep '08

27 Sep '08

I was trying to commit a small bugfix in the boost/graph trunk this morning and got a 403 forbidden error (despite having an https checkout. Do I need to request write permission for the trunk? I can write changes to the sandbox. Thanks, Andrew Sutton asutton(a)cs.kent.edu

2 1

hton/ntoh template functions
by vicente.botet 27 Sep '08

27 Sep '08

Hi, currently most of the applications that must take care of endianess use ntohl/htonl ntohs/htons functions. When the size of the integer change we need to change between the -s and -l functions (or maybe remove the call for chars). I'm wondering if two template functions would improve the maintenability of the code. template <typename T> T host_to_network(T v); template <typename T> T network_to_host(T v); template <> long host_to_network<long>(long v) {return htonl(v);} template <> long network_to_host<long>(long v) {return ntohl(v);} template <> short host_to_network<long>(short v) {return htons(v);} template <> short network_to_host<long>(short v) {return ntohs(v);} we will need to add specialization for all the other integer types, and we can also include char and unsigned char template <> char host_to_network<char>(char v) {return v;} template <> char network_to_host<char>(char v) {return v;} Do you think that these template functions should be included in boost? Best regards, Vicente

4 6

Re: [boost] Answers re BENUM library for automated enum streaming
by Tony D 27 Sep '08

27 Sep '08

Hi Marcus, Thank you for your guidance, and my turn to apologise for slow turn-around and mistaking the name of EnumIO. Noted the heads-up re boost code formatting standards - will have to do something I guess :-(. As you say, my library relies on "exotic features", and while I was happy to discover Sun Studio has supported __VA_ARGS__ for a long time, VC++ support only came is 2005, and I'm not so happy to be unable to find explicit mention of it in the discussions for C++0x... so avoidance is definitely a strength for EnumIO. I did receive one suggestion elsewhere - think it's worth sharing as you might consider it for EnumIO. Idea is: "inheriting" from an existing enum and adding new values. An "extendable" enum would be packaged in a class that actually stores the value in an int and has a protected set_from_int(int) method. A derived class defines an enum with additional symbols/values, constructors from the base's enum and their own enum - both of which call the base set_from_int(). (A protected constructor from int() could be used - and might be more efficient - but in the case of BENUM would complicate end-user control over whether construction from int is implicit or explicit.) Thought that was a pretty neat idea. Lots to do on the docs, examples etc.. Regards, Tony ----- Original Message ---- From: Marcus Lindblom <macke(a)yar.nu> To: boost(a)lists.boost.org Sent: Friday, 19 September, 2008 17:53:24 Subject: Re: [boost] Answers re BENUM library for automated enum streaming (Sorry for not replying sooner) Tony D wrote: > Hi all, > > Should I expect any further feedback re BENUM? David, Marcus: we've discussed specific issues (portability of variadic macros, smart_enum features) - do you have further questions, comments re my replies, or recommended actions before submission for formal review? Should I be doing more to pursue suggestions or solicit feedback? Is anyone else currently reviewing the code in the vault, experiment with usage in a real system, or planning to do so? If so, can we keep in touch re progress? If I don't hear anything to the contrary this week, I'll start doing the preparations for requesting a formal review, specifically my TODO list currently looks like: Small detail: My little embryo is called EnumIO, not smart_enum. Smart_enum is probably something different altogether. I'm quite happy with the answers, and I think it suits as a good replacement for my lib. I took a brief look at the code, and besides it not being formatted according to boost standards, it looked pretty ok. I still think my little lib is useful, mainly because it doesn't rely on exotic features and it can also be used in a non-intrusive fashion. But I see no bigger conflict as your will probably win the future. (Besides, I'll have to figure out a few things before I can publish mine for review, as noted in the link I posted a few mails back. If I ever get there there will probably be some discussion about integration, etc.) Cheers, /Marcus _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[thread] TSS cleanup
by Felipe Magno de Almeida 26 Sep '08

26 Sep '08

Hello, I would like to know if the storage created for boost::thread_specific_ptr in the tss specific code for win32 is free'd after the destruction of said boost::thread_specific_ptr, or if it stays until the end of the process. For example: for(int i = very_big_number;i--;i > 0) boost::thread_specific_ptr<int> p(new int); To my knowledge, the pointer returned by new in this case is freed. But does the int* that is created to store the pointer to new int is also freed, or this program will get only bigger and bigger? I'm using boost 1.36. The boost in 1.34 did get bigger and bigger, and I modified to use a map, which made the complexity bigger (log N), but made it manageable to use spirit 1.8, which creates boost::thread_specific_ptr and destroys a lot of them. Thanks in advance, -- Felipe Magno de Almeida

4 7

[threadpool] sub_tasks and active waiting
by vicente.botet 26 Sep '08

26 Sep '08

Hi, How can I define pool so the following code do not deadlocks? ???? pool; int fib_seq(int n) { if (n <= 1) return n; else return fib_seq(n−1) + fib_seq(n−2); } void fib_par(int n) { if (n <= 5) // granularity ctl return fib_seq(n); else { tp::task<int> t1(pool.submit(bind(fib_par, n-1)); tp::task<int> t2(pool.submit(bind(fib_par, n-2)); return t1.get_future().get() + t2.get_future().get(); } } int main() { return fib_par(10); } Well, we can see that the number worker threads depends on the fib_par parameter. As soon as the fib_par function waits on its sub_tasks t1 and t2, the worker thread cannot handle other tasks, so we need a thread available for fib_par(9) and fib_par(8). When this worker thread call fib_par(9) after launching fib_par(8) and fib_par(7) will be blocked to manage other task, ... Evidently this do not scale very well, so we can not use the threadpool library to address this kind of problems, in which the tasks is split on sub-task launched to be run in parallel, and the the parennt task waits on its child sub-task to do somthing. IMO, what we need is that instead of creating a task we create a subtask. When the function will wait until the results of its subtasks are ready, we don't need to block the worker thread, instead we can implement replace the pasive wait by an active one, which will check if the waited task is ready and if this is not the case it will do a scheduling step on the associated thread pool and check again. void fib_par(int n) { if (n <= 5) // granularity ctl return fib_seq(n); else { tp::sub_task<int> t1(pool.submit_subtask(bind(fib_par, n-1)); tp::sub_task<int> t2(pool.submit_subtask(bind(fib_par, n-2)); return t1.get() + t2.get(); } } The submison of a sub_task can be done differently of a task, because there is a parent task that will be waiting for the end of the sub_task, so maybe we can add it on LIFO order. Do you think that this is an interesting feature for your library? could it be integrated in your library without disruption? Best, ______________________ Vicente Juan Botet Escribá

3 3

[Phoenix] Monomorphic functors don't expose result_type
by Mathias Gaunard 26 Sep '08

26 Sep '08

I thought bind was supposed to generate monomorphic functors when used with function pointers, pointers to members, or monomorphic functors. Yet the functors it generates don't expose result_type, but only the result template. Moreover, I would expect functors to stay monomorphic when generating lambdas. If foo and bar are monomorphic (and thus expose result_type), foo < bar should be monomorphic too.

2 2