- Boost - lists.preview.boost.org

[Boost.Math] Re: [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'
by Steve M. Robbins 02 Jan '12

02 Jan '12

Hello, Boost Developers: I recently did rebuilds of all Debian packages that use Boost with Boost 1.48 and this is one of the casualties of the upgrade (from 1.46.1). On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote: > On Fri, Dec 30, 2011 at 9:53 PM, Steve M. Robbins <smr(a)debian.org> wrote: > > This package failed to build using the newest Boost version 1.48: > ... > > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp: In function 'T boost::math::detail::lgamma_small_imp(T, T, T, const mpl_::int_<0>&, const Policy&, const L&)': > ... > > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp:483:38: error: expected primary-expression before 'do' > > I'm not in a position to verify this for myself for another week, but > I have a horrible feeling I know what's wrong: Monotone defines > several one-character macros for its own use, and L() is one of them. > It looks like Boost is using L() for its own purposes and expecting it > not to be a macro. Zack, you are absolutely right. The lgamma_small header has a templated class method using "L" as one of the templates: template <class T, class Policy, class L> T lgamma_small_imp(T z, T zm1, T zm2, const mpl::int_<0>&, const Policy& pol, const L&) The compile error at line 483 is at a call to L(): result = log(gamma_imp(z, pol, L())); > I'd argue that Boost headers should take care to defend themselves > from the possibility of such macros, but fixing that in Boost might be > an enormous amount of work, and in any case, 1.48 is already out > there. Boost.Math developers: What is the right thing to do here? More descriptive class template parameters? Attached is a trivial file to reproduce the bug. Thanks, -Steve

6 6

boost modularisation status?
by Robert Ramey 02 Jan '12

02 Jan '12

https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years. Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this. What is the current status of this? Robert Ramey

9 22

[review] Boost.Context mini-review starts today, January 2nd
by Giovanni Piero Deretta 02 Jan '12

02 Jan '12

Hi all, we will start a new year of Boost reviews with a one week mini-review of the Boost.Context library of Oliver Kowalke. The review period starts today January 2nd and ends January 11. Please use [context review] as prefix of your post. Reviewers are strongly encouraged to send their reviews to the boost development mailing list as this is the I follow more assiduously. Please note that Boost.Context was already reviewed and conditionally accepted last May, so we are not voting for acceptance. Instead, this mini-review is to discuss whether the library meets the conditions on acceptance that were listed by Vicente Botet, the review manager at that time. You'll find the whole list at the end of this email. Since the end of the original review, Oliver has spent a large amount of time on a partial rewrite of the library and both me and Oliver decided to schedule this review only after we determined that all issues had been addressed or at least considered. In your review please state whether the acceptance conditions have been addressed satisfactorily. ---------------------------------------------------------------------------------- About the library: Boost.Context is a foundational library that provides a sort of cooperative multitasking on a single thread. By providing an abstraction of the current execution state in the current thread, including the stack (with local variables) and stack pointer, all registers and CPU flags, and the instruction pointer, a context instance represents a specific point in the application's execution path. This is useful for building higher-level abstractions, like coroutines and fibers. ---------------------------------------------------------------------------------- Useful Links: documentation: http://ok73.ok.funpic.de/boost/libs/context/doc/html/ library: git://github.com/olk/boost.context.git ---------------------------------------------------------------------------------- >From the original review result email: Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local).

1 0

[Graph] LEDA adapter - concept check VertexListGraph fails
by Jens Müller 01 Jan '12

01 Jan '12

Hi everyone, when running the tests for Graph, the first concept check in leda_graph_cc.cpp fails: gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o In file included from leda_graph_cc.cpp:9:0: ../../../boost/graph/graph_concepts.hpp: In destructor 'boost::concepts::VertexListGraph<G>::~VertexListGraph() [with G = leda::GRAPH<int, int>]': ../../../boost/graph/graph_concepts.hpp:168:1: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::concepts::VertexListGraphConcept<leda::GRAPH<int, int> >]' leda_graph_cc.cpp:21:5: instantiated from here ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' ../../../boost/graph/graph_concepts.hpp:189:9: note: candidate is: ../../../boost/graph/graph_concepts.hpp:45:48: note: template<class T> typename T::ThereReallyIsNoMemberByThisNameInT boost::vertices(const T&) (among some further errors, but I'd like to ask just about this one now) Apparently it cannot find a vertices() function: ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' But there is one in leda_graph.hpp: template <class vtype, class etype> inline std::pair< typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator, typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator > vertices(const leda::GRAPH<vtype,etype>& g) { typedef typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator Iter; return std::make_pair( Iter(g.first_node(),&g), Iter(0,&g) ); } So, can someone enlighten me why it isn't found? Has it something to do with #ifdef BOOST_VECTOR_AS_GRAPH_GRAPH_ADL_HACK // dwa 2003/7/11 -- This clearly shouldn't be necessary, but if // you want to use vector_as_graph, it is! I'm sure the graph // library leaves these out all over the place. Probably a // redesign involving specializing a template with a static // member function is in order :( using boost::vertices; #endif ? Best regards, Jens

2 8

Many Boost.Test unit tests fail
by Barend Gehrels 01 Jan '12

01 Jan '12

Hi, Since today or yesterday, many regression tests fail. http://www.boost.org/development/tests/trunk/developer/summary.html I believe on platforms that are recently added, at last on platforms that were not present at December 17. 1) on clang/darwin, message ../boost/test/tools/assertion.hpp:278:21: error: no member named 'forward' in namespace 'std' 2) on clang/linux, message /usr/bin/ld: skipping incompatible /sierra/Sntools/extras/compilers/gcc-4.4.4/lib/libstdc++.so when searching for -lstdc++ We have these errors in Boost.Geometry but I also noticed them in many other libraries. Regards, Barend

2 2

[filesystem] path thread safety fix impact on POSIX systems
by Beman Dawes 01 Jan '12

01 Jan '12

Class path locale initialization has suffered from a data race for several releases. See https://svn.boost.org/trac/boost/ticket/6320 for an example of code that suffers as a result. The problem was introduced when locale initialization was changed from namespace scope initialization to function scope initialization. For Windows and Mac OS X, the fix is simply to change back to namespace scope initialization. For non-BSD based POSIX systems such as Linux, the problem is more complex. These system need std::locale(""), "the locale-specific native environment". Considerations: * std::locale("") will throw if environmental variables are configured incorrectly. For example, setting LANG=foo on my Ubuntu system causes std::locale("") to throw. * std::locale("") is only needed if conversions between wide and narrow character paths occur in the program, so it would be unfortunate to have programs throw that don't actually do any such conversion. * With GCC, std::locale("") at namespace scope will throw before main() has started! That prevents catching the exception in the user code, and was what led to moving the initialization to a function scope static. Initialization as a function scope static also meant that the exception only occurred if user code actually performed wide - narrow conversions. I can see two possible fixes: (A) Use function scope locale initialization, using boost/detail/lightweight_mutex.hpp to prevent data races. (B) Use namespace scope locale initialization, defaulting the codecvt facet to UTF-8 if std::locale("") throws. The advantage of (B) is that path always initializes without throwing, and that's what users seem to expect. The initialization is correct for all those whose environments are configured correctly, and for those uses who want UTF-8 even if their environments are misconfigured. The POSIX users who prefer an exception on a misconfigured environment can always add a std::locale("") at the start of main(). Comments or opinions? --Beman

4 6

Re: [boost] matrix and vector iterators
by Larry Evans 31 Dec '11

31 Dec '11

On 06/12/01 14:50, David Abrahams wrote: > > ----- Original Message ----- > From: "Larry Evans" <jcampbell3(a)prodigy.net> > > >> David Abrahams wrote: >> >>> One problem with this is that it requires much more of the iterator in > some >>> cases than it otherwise might. In an array stored as vectors of vectors >>> of... vectors, each iterator would need to have references to all of the >>> containing vectors. >> >> Couldn't the iterator just contain a vector of indices of length == rank, >> and a pointer to the vector of vectors of... vectors (VofV), and then just > index into >> the VofV with the vector of indices. > > When you start talking about iterators containing vectors, I get worried. > >> I guess bad thing about that is that it takes longer. > > That's putting it mildly. Iterators should be lightweight. > > -Dave > > Another type of iterator which essentially flattens a multi-dimensional array and *may* be more lightweight is implemented here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/b… and demonstrated here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… A more realistic demonstration is in the Partial Differential Equation example here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which uses an axes rotation feature that, IIUC, was requested by Petros here: http://article.gmane.org/gmane.comp.lib.boost.user/68017 Its also used here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/stepper/l… which is probably a bit easier to follow than the array_dyn.diff_pde.cpp one ;) I've done no benchmarks; hence, I can't say how lightweight it is; however, since all it does is keep a stack of indices in a data structure instead of on the stack, I would think it wouldn't be that much more heavyweight than simply a nested for loop nested N deep where N is the array dimensionality. BTW, Petros, in a private email to me, has indicated he has some other method for solving the rotated axes problem; however, I've no idea if that's more or less lightweight than this one. -regards, Larry I've run no benchmarks to show how lightweight it may be. Petros, in a private email to me, says he has another way of

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 31 Dec '11

31 Dec '11

Dave Abrahams: > > No post-hock marshalling? You should be able to add marshalling to a > class without modifying its declaration. > If a class is popular enough, I often do. For example, the C++ Middleware Writer (CMW) has support for the standard containers, std::complex, multi_index_container, stable_vector and others. [...] > > No argument; I'm just sayin'. I don't have to go to any great lengths to find tests where the performance of executables that use Boost Serialization lags behind CMW based executables. I just think up a test and write it. The tests are quite basic. > > That's a fundamentally intrusive design; being able to add serialization > non-intrusively was a major design goal for Boost.Serialization. I see. One thing I didn't mention yesterday is support for stream- based constructors: class Base { template <typename R> explicit Base (ReceiveBufferFile<R>& buf); ... }; Does the Boost Serialization library have support for that? Cheers, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.Pool lost singleton_default -- replacement?
by Steve M. Robbins 31 Dec '11

31 Dec '11

Hi, Prior to 1.48, Boost.Pool's singleton_pool class used a helper class singleton_default. This was hidden in a detail header <boost/pool/detail/singleton.hpp>, yet I found 3 programs in the Debian distribution that used it directly to instantiate their own singletons. I didn't find any direct replacement for singleton.hpp in Boost 1.48. Is there any plan to introduce this later? Thanks, -Steve

3 2

Boost 1_41 Binary archive exceptions
by KARAN 31 Dec '11

31 Dec '11

I am porting from Linux 32 bit to 64 Bit(x86_64)(Boost Version :1_41). I am facing an Binary archive exceptions mainly (std::bad_alloc,St12length_error-basic_string::resize). There are no exception during the file saving, but when I do a restore I am facing the above exceptions. The same works very well if I change it to text archives. How can I make it work with binary files? The exception is happening in the below code block .Any comments please template<class Archive> void Serialise (Archive & aArchive, const unsigned int aVersion=0) { aArchive & this->A; aArchive & this->B; aArchive & this->C this->p.Serialise(aArchive, aVersion); } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-41-Binary-archive-exceptions-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 6

[interprocess] Timed locks
by Edward Diener 29 Dec '11

29 Dec '11

In boost::inteprocess timed locks are specified by giving a boost::posix_time::ptime as the absolute time until which ownership is attempted. Would it not be more usable to give a boost::posix_time::time_duration from the time in which the one attempts to acquire the lock ? I think an end-user calculation is usually one in which he says that a certain lock needs to be acquired in so many seconds ( or milliseconds ) and a boost::posix_time::time_duration would fit that calculation better.

4 5

[MPL] "Unwrap" metafunction
by Robert Kawulak 29 Dec '11

29 Dec '11

Hi, I need a metafunction to check if a type is wrapped as an argument of a template and "unwrap" it if so. Something like: template <template <typename> class T, typename C> struct unwrap { typedef C type; static const bool is_wrapped = false; }; template <template <typename> class T, typename C> struct unwrap<T, T<C>> { typedef C type; static const bool is_wrapped = true; }; So both unwrap<x, int>::type and unwrap<x, x<int>>::type are int, while unwrap<x, y<int>>::type is y<int>. Of course I can use the code above, but I'm just curious - does Boost.MPL already provide a utility that can be used to achieve the same? Thanks and best regards, Robert

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

Robert Ramey: > This first came up several years ago and I spent a little time looking at > it. > I was sort of intrigued in that the usage of TMP driven inline code should > be optimal for cases where tracking wasn't involved. And in these test > cases there isn't any tracking. So I looked a little at the tests on the > page. > > a) first I couldn't compile them so I couldn't repeat the results. > Something > was missing (I forget what now). I believe you are referring to something from several years ago here. > b) so I inspected the code. My conclusion was that the being used was > that in the i/o itself rather than the serialization. Boost serialization > relies > on streambuf to do it's i/o and the time is sensitive to things like buffer > sizes > etc. It seems that brian's code uses some other method which whose > source isn't visible to me. (SendBuffer, etc). This sounds like the present. Did you download and build the archive here -- http://webEbenezer.net/build_integration.html ? (Also in an earlier note today I mentioned recent changes to the test archive here -- http://webEbenezer.net/comp/tests.tar.bz2 .) > c) Brian did point out some cases where boost serialize could be improved > particularly using hints in std collections. These were incorporated. I > also > implemented the binary i/o in terms of streambuf rather than stream which > was a noticible improvement. Yes, now it would probably not be difficult to add support for ::std::move. I'm asking for someone to open a ticket for that so someone doesn't ask me to. ;) [...] > e) So, given tat the timings aren't that far apart, and lacking any other > information, I'm inclined to attribute any discrepencies to the way i/o is > handled > in the different systems. If one had nothing else to do he could make > a replacement for streambuf which focused on fast i/o perhaps at the > expense of portability. In particular, an asyncronous memory mapped i/o > library might be an interesting addition to boost. And that would be cool > to plug in the serialization library. While true that the timings aren't real far apart, I note that the timings of the (slightly) more complicated tests are worse for the Boost Serialization library than the simpler tests. Real uses have more than a vector<deque<double> > of complication. So there may be a compounding effect, but I'm just speculating. > Finally, I think that the scale and breadth of brian's library is much, much > smaller than boost serialization library. The breadth is smaller. I don't support text or XML based serialization. > Then there is the fact that the > distribution model is totally different than that of boost and open source > libraries in general. I just don't see how these packages/approaches > could be considered comparable in any way. While the distribution models are different, I think the binary part of the Boost Serialization library is comparable to the Ebenezer approach. Thanks for mentioning the distribution model. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

Re: [boost] Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

I found an error that affects two of my test cases -- not comparing apples to apples -- so have updated the page I linked to and the archive with the tests. Only one of the tests showed different results after the change. Rather than claiming the Boost Serialization version of the test was over 3 times slower than the Ebenezer version, I now claim it is over 2.3 times slower. Dave Abrahams: > A few: > > 1. The claim that you provide "full generation of marshalling functions" > is a little hard to swallow. In principle, it's impossible to know > based on a class declaration what to serialize, and how to serialize > it. True. In order to turn off the default generation of marshalling code, one can place a comment like this: // hand_written_marshalling_code in the body of a class. Instances of that class can still be marshalled if you provide the expected marshalling functions yourself. > 2. If you are going to compare yourself to Boost.Serialization, it would > be a good idea to replicate all of that library's tests with your own > system, to demonstrate that you cover the same expressive range. We don't cover the same range, but are working to add to the reperoire. We do have support for some things that the Boost library doesn't: iterator_range, sub_range, several Boost Intrusive containers, flex_string, segmented_array and a few others. To the best of my knowledge Boost Serialization doesn't take advantage of ::std::move. http://boost.2283326.n4.nabble.com/Serialization-and-std-move-td2598382.html I've checked the 1.48 code also. > It's usually very easy to build something that beats benchmarks of a > more-general system. Well, this is the first time I've had an archive with the tests that I link to, so at least think that is a step in the right direction. > 3. That "our approach writes marshalling functions based on the content > of the types involved" does not explain how you get past the private > member access barrier. The only legal technique I've seen for that > is at https://gist.github.com/1528856, and Boost.Serialization should > probably have support for that approach. C++ Middleware Writer users add function prototypes to their classes. The first two links on this page -- http://webEbenezer.net/rbtree_marshalling.html show an example. In that example the marshalling functions are virtual. In general they aren't required to be. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.Extension - any plans?
by Klaim - Joël Lamotte 29 Dec '11

29 Dec '11

Hi, I'd like to know if there are plans from it's author to submit Boost.Extension library for inclusion in boost? ( http://boost-extension.redshoelace.com/docs/boost/extension/index.html) Or any other plans? I remember the development was paused until some C++11 features would be available (I don't know which ones). But maybe I'm wrong. In my opinion, this library would be an excellent addition to boost. Joël Lamotte

1 1

Comparison of serialization results
by Brian Wood 29 Dec '11

29 Dec '11

I've recently updated a page -- http://webEbenezer.net/comparison.html comparing results obtained using Boost Serialization (1.48) and the C++ Middleware Writer (1.13) on both Linux and Windows7. There's an archive that has all the test files mentioned on that page here -- http://webEbenezer.net/comp/tests.tar.bz2 . In order to build the tests, you would need to build the Boost Serialization library and an Ebenezer library yourself. There's an archive on this page that has the Ebenezer library -- http://webEbenezer.net/build_integration.html . To summarize the results, the Boost versions range from 1.1 to 3 times slower than the Ebenezer versions. And the sizes of the Boost executables range from portly to obese compared to functionally equivalent Ebenezer executables. Comments on the how to improve the tests/process/etc. are welcome. Shalom Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 6

Is there any interest in command line interpreter class templates?
by alexey.tsoy 29 Dec '11

29 Dec '11

Hello everybody, The file command_line.zip in the containers directory in Boost’s vault contain command line interpreter library. There you can find simple tutorial with examples and draft documentation. The library supports variable amount of option parameters as well as automatic type casting. Note that their types may be diferent. The library doesn't require special linking because it contains headers only. You only need to type in a few lines of code to start using it. Regards Alexey -- View this message in context: http://boost.2283326.n4.nabble.com/Is-there-any-interest-in-command-line-in… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Re: [boost] [Spirit-general] [karma][fusion] Signed integer members of Boost.Fusion adapted ADTs are not output correctly with Boost.Spirit.Karma rules
by Jeroen Habraken 29 Dec '11

29 Dec '11

Hi, On 27 December 2011 00:51, Torsten Maehne <Torsten.Maehne(a)gmx.de> wrote: > Hello, > > I'm using Boost.Spirit.Karma to format the output of some nested structs > (direct access of the public member variables) and abstract data types > (ADTs) (access to the private member variables via getters and setters) > in my code. I'm using Boost.Fusion to adapt the ADTs into a sequence of > values of primitive data types for output with Boost.Karma. This worked > fine till Boost 1.44. Since Boost 1.45 up till 1.48 and the current > Boost trunk (I tested svn revs 75505, 75963, and 76196) the output of unsigned > integer members of Boost.Fusion-adapted ADTs doesn't work anymore -- > even though I took into account the change in the name of macro from > BOOST_FUSION_ADAPT_CLASS to BOOST_FUSION_ADAPT_ADT as well as the > additionally required header > boost/spirit/include/support_adapt_adt_attributes.hpp. > > The problem is demonstrated in the attached test case for rational > number ADTs and structs, which use signed integer member > variables. Compilation of this test case against Boost 1.44.0 will > succeed and it will run without any errors. Compilation of this test > case against Boost 1.45.0 and 1.46.1 will fail. Compilation against > Boost 1.47.0 and 1.48.0 will succeed, but the output of negative values > of signed integer members of Boost.Fusion-adapted ADTs will be > wrong. The minus sign is output correctly, but it is followed by a wrong > value, which seems to be yielded by a cast from a signed to an unsigned > integer value instead of taking the absolute value of the signed integer > value. This has been observed on Mac OS X 10.7.2 (x86_64) with Xcode 4.2 > using Apple's g++ 4.2.1, Apple's clang++ 3.0. Interestingly, compiling > the test case against Boost 1.47.0 or Boost 1.48.0 using MacPorts g++ > 4.5.3, will yield more output checks to fail for Boost.Fusion-adapted > ADTs used in Karma output rules. > > Compilation against Boost from the Subversion trunk (I tested > revs. 75505, 75963, and 76196) does only succeed using Apple's clang++ > 3.0 and execution will yield the same wrong output for negative values > of signed integer members of Boost.Fusion-adapted ADTs. Compilation > fails with Apple's g++ 4.2.1 and MacPorts g++ 4.5.3. > > I'm not able to locate the root cause for this problem, whether it is in > Boost.Fusion or Boost.Spirit.Karma. I would appreciate any help to > resolve this annoying issue. Until a solution is found, I'm stuck with > Boost 1.44.0. Several things seem to play a role, but I've had a look at as to why the code doesn't compile using boost-trunk and found the cause to be an ambiguity: boost/typeof/native.hpp:30:9: error: reference to 'enable_if' is ambiguous boost/utility/enable_if.hpp:36:10: error: candidates are: template<class Cond, class T> struct boost::enable_if boost/test/tree/decorator.hpp:184:23: error: class boost::unit_test::decorator::enable_if As enable_if is often used without being fully qualified this breaks in a major fashion. Since boost/test/tree/decorator.hpp seems to be quite new (added 2011-10-02 11:00:16 +0200) it might be best fixed there. > Please note that I also submitted a bug report on this issue more than 6 > weeks ago without any reaction so far: > > <https://svn.boost.org/trac/boost/ticket/6126> > > Best regards, > > Torsten Maehne Note: I've included boost(a)lists.boost.org in the discussion. Kind regards, Jeroen Habraken

2 6

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 26 Dec '11

26 Dec '11

Hi everybody, I released a new version of the DE library based on feedback I received on the initial release - see the doc at http://www.amichel.com/de/doc/html. First of all, I updated the documentation to describe in more detail what DE is, its use in one specific case, and links to descriptions of several other use cases - see the Overview page at the link above. I hope this will help make the case why a DE library would be worth being included in boost. BTW, there are already implementations in several languages and for several free or commercial products: Java, C, Matlab, Scilab, Fortran90, Python, Labview, Pascal, C#, etc. As far as the library itself, Thomas Heller noted that requiring the objective functions to be derived from the de::objective_function abstract class limited the user options by not allowing arbitrary unnamed or plain functions to be passed as objective functions. I followed his suggestion and reimplemented parts of the library as template classes, in particular the de::processor class. It is now possible to pass objective functions as: named functions, unnamed functions, functors (all with the right prototype) or objective function factories which create local copies of the objective function. All of these can be passed as either references, plain pointers or boost::shared_ptr. This change should make it easier to integrate the library within existing code. Your comments will be appreciated. Adrian

1 0

[string_algo] New Maintainer
by Pavol Droba 26 Dec '11

26 Dec '11

Dear Boosters, After a careful consideration I finally realized that I can no long act as a maintainer for String Algorithms Library. I simply don't have the required time and I thinks that the library deserves at least development. Therefore I would like to call for a volunteer(s) who would like to take String Algorithm library further. I will still be available for consultations or any such assistance if required. Hopefully I will be also able to contribute a bit if my situation changes. Now, I don't really know if there is an official process for this kind of shift. I would be nice if potential volunteers would send a few words about the future direction they would take. A community can make a decision then. Best Regards, Pavol

3 6

[config, c++11] emplace_back check?
by Tim Blechmann 26 Dec '11

26 Dec '11

hi all, i wonder, is there a way to determine, if std::vector provides emplace_back? this currently causes a compile failure for boost.heap on gcc-4.3 with c++0x enabled: it does not implement emplace_back, although it has rvalue references and variadic templates. thanks, tim

1 0

boost releases on microblogs
by Pedro Larroy 25 Dec '11

25 Dec '11

Hi Wouldn't it be nice to have twitter and identi.ca anouncements of boost releases? Regards. Pedro.

1 0

Re: [boost] FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 24 Dec '11

24 Dec '11

Hi Philip, On 12/09/2011 4:35 PM, Philip Bennefall wrote: >> The full documentation is at http://www.amichel.com/de/doc/html but I'd >> suggest these pages for a first read >> http://www.amichel.com/de/doc/html/dd/d53/overview.html and >> http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . >> >> The zip containing the DE C++ library and helper files is at >> http://www.amichel.com/de/de.zip. >> >> The DE main page is at http://www.icsi.berkeley.edu/~storn/code.html . > I took a peak at the overview and some of the other pages and from what I > can see initially, it looks like a very useful library for artificial > intelligence. I have very limited knowledge in the field but this is > something that grabs my interest, so if it's made public I'll definitely use > Thanks for your interest. DE and this library can be certainly used for AI, but many different problems in various areas can be optimized efficiently using DE (references to some of those can be found here: http://www.icsi.berkeley.edu/~storn/code.html) Best, Adrian

5 4

[geometry] MSVC needs namespace even if it is hoisted
by Barend Gehrels 24 Dec '11

24 Dec '11

Hi, We got a strange MSVC compilation problem in a Unit Test for Boost.Geometry. Attached a miminal reproduction. The essention is that we have stated: using strategy::distance::services::returning_type; and somewhere after that: typedef typename returning_type<strategy_type>::type the_return_type; but this is not accepted, in this case, by MSVC. It is well accepted by gcc, clang and comeau. If the namespace is specified, it is accepted by MSVC. The error message is: reproduce_msvc_using_bug.cpp(257): error C2059: syntax error : '<' And that is the same message as if the returning_type would not be a template. If we state: std::cout << typeid(returning_type).name() << std::endl; It compiles in MSVC, but it should not compile, because it is a template. So somehow it picks up this "returning_type" as if it is not a template. But of course it is. I've tried another (much smaller) minimal reproduction to mimic this problem but that is compiled normally by MSVC. So attached this one with (reworked) pieces from Boost.Geometry and even Boost, but still all contained in one file. We've discussed this internally and the current thought is that it is a compiler problem. If so, is this issue known to anyone on this list, or Microsoft? Otherwise I will report it. If not so, what is the problem here? It is of course easy to work around: giving the full namespace is OK for any compiler. So this is more out of curiosity: what is wrong here? Regards, Barend

3 3

TRAC hit hard last night
by Marshall Clow 23 Dec '11

23 Dec '11

We got a major infusion of garbage; strictly speaking, it doesn't appear to be spam, because it's not advertising anything, and the text doesn't contain any links. However, it doesn't have anything to do with boost. I've deleted about 40 tickets this morning. Any suggestions on how to prevent this in the future? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 2