- Boost - lists.boost.org

[smart_ptr] shared_ptr<T> T destructor required even if a deleter function is provided
by vicente.botet 29 Sep '08

29 Sep '08

Hello, I have compiled the example Preventing delete px.get()and every thing is OK until we use the reset function because shared_ptr<X> request that the destructor of X must be public even if a deleter function is provided. I'm wondering if this is a BUG on the smart pointer library Next follows the trace: ../../../boost/checked_delete.hpp: In function `void boost::checked_delete(T*) [ with T = X]': ../../../boost/detail/shared_count.hpp:91: instantiated from `boost::detail::s hared_count::shared_count(Y*) [with Y = X]' ../../../boost/shared_ptr.hpp:173: instantiated from `boost::shared_ptr< <temp late-parameter-1-1> >::shared_ptr(Y*) [with Y = X, T = X]' ../../../boost/shared_ptr.hpp:394: instantiated from `void boost::shared_ptr< <template-parameter-1-1> >::reset(Y*) [with Y = X, T = X]' test_shared_ptr.cpp:37: instantiated from here test_shared_ptr.cpp:13: error: `X::~X()' is private ../../../boost/checked_delete.hpp:34: error: within this context And here it is the source code #include <boost/shared_ptr.hpp> using namespace boost; class X { private: ~X(){}; class deleter; friend class deleter; class deleter { public: void operator()(X * p) { delete p; } }; public: static shared_ptr<X> create() { shared_ptr<X> px(new X, X::deleter()); return px; } }; int main () { shared_ptr<X> ptr = X::create(); ptr.reset(X::create().get()); return 0; } ______________________ Vicente Juan Botet Escribá

2 4

[threadpool] relation with TR2 proposal
by joaquin＠tid.es 29 Sep '08

29 Sep '08

Hello, I learnt yesterday that there is a TR2 proposal for a thread_pool, sponsored by our Boost colleague Anthony Williams: http://www2.open-std.org/JTC1/sc22/wg21/docs/papers/2007/n2276.html What is the relationship with this proposal of the threadpool library that is being discussed these days here at the Boost list? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 24

[lightweight_mutex] Patch to support new thread api
by Frank Mori Hess 29 Sep '08

29 Sep '08

Here is a patch which makes boost::detail::lightweight_mutex conform to the Lockable concept from the new Boost.Thread api. It shouldn't break backwards compatibility for code already using it. Note I haven't tested it much, especially the windows part (which I haven't even tried to compile), but the changes are pretty straightforward.

1 0

[serialization] merge to releasse ready
by Robert Ramey 28 Sep '08

28 Sep '08

I want to merge the current trunk version of the serialization library into the release-ready version. I've checked the wiki page and it seems that I've met all the criteria. I'm just double checking. There are some changes that I'm not included right now. Basically these are the original versions of certain modules located in the boost directory. E.G boost/static_warning.hpp. The serialization library doesn't use them any more and each one has been modified to include a #error -... in case someone has used them. I haven't recieved any reports that this has broken anything so I'm presuming that no other library - and perhaps no user application is including them. The question of whether these should be removed is separate from the above. I just thought I'd post this comment before removing them. Robert Ramey

3 4

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