- Boost - lists.preview.boost.org

[interest] underlying type library
by Julian Gonggrijp 24 Aug '11

24 Aug '11

Dear Boost developers, std::swap is commonly implemented by copying the arguments. For non-POD types this can be very inefficient. Two solutions are available. The first option, which is commonly employed, is to manually override std::swap for every non-POD type, making use of the implementation details of the type. The other option is to provide a library which makes it possible to implement the swap algorithm once, in a way that is efficient for any type (POD or non-POD), and which works even if a type isn't copyable. The latter is what I'll be proposing here. Back in March, Vicente Botet posted a link to the highly inspiring 'Notes on Programming' by Alexander Stepanov [1]. Lectures 4 and 5 cover the (hypothetical) move_raw algorithm and the (hypothetical) UNDERLYING_TYPE type function, as well as their relevance to the swap algorithm. I'll try to reproduce the essential points of this discussion below. move_raw(s, t) moves the value of s to t. t is guaranteed to be left in a valid state but s isn't. In particular, the destruction of s might corrupt t because they point to the same additional resources. Another move operation into s, say, move_raw(r, s) will however restore s into a new valid state. UNDERLYING_TYPE(T) represents a type which is (conceptually speaking) a POD-type with the same member data (and hence the same alignment) as T. The underlying type can be used to allocate space for a T object and to temporarily store the state of a T object. Using move_raw and UNDERLYING_TYPE, a swap algorithm can be implemented which works and is efficient for any type: template <class T> void swap (T& x, T& y) { UNDERLYING_TYPE(T) temp; move_raw (x, temp); move_raw (y, x); move_raw (temp, y); } The benefits of an underlying type library go far beyond the swap algorithm. For a start, any algorithm which moves values around without an inherent need to copy them could use the same mechanism as the swap algorithm above. Apart from that, it can help to simulate rvalue references and move semantics in pre-C++11 compilers in an efficient way. Concluding, a library which provides these tools has an immense potential for improving efficiency and convenience anywhere C++ is used. After reading the lecture notes, I came up with an idea on how to realise such a library in a fully generic way. Alexander Stepanov and Sean Parent have been so kind to review my idea. The idea seemed feasible and they encouraged me to submit something to Boost. In the meanwhile I have successfully managed to implement my idea, so here I am. :-) Apart from its fundamental nature in general, my library might bear special relevance to Boost.Swap and Boost.Move. Is your interest piqued? Kind regards, -Julian [1] http://www.stepanovpapers.com/notes.pdf

16 72

[proto] Problems with operator <<
by John Maddock 24 Aug '11

24 Aug '11

Folks, I'm having no end of problems with operator<< and proto. In the beginning, operator << was overloaded for stream output and everything worked OK, then I added the left shift operator<< to the list of protoized operators in the grammar and everything broke. The strange thing is that: std::cout << a+b; correctly finds my stream out overload: template <class Exp> inline std::ostream& operator << (std::ostream& os, const big_number_exp<Exp>& r) But std::cout << a; no longer calls: template <class Backend> inline std::ostream& operator << (std::ostream& os, const big_number<Backend>& r) But calls the proto << operator instead. I'm at a complete loss to explain this, both of my overloads are in the same namespace as their respective types, and as far as I can see both should be preferred to the proto versions. Before I start tearing my hair out, anyone any ideas? Thanks, John.

2 1

Re: [boost] [Boost-users] [Containers] Marshalling deques
by Brian Wood 24 Aug '11

24 Aug '11

Ion Gazta?aga: > >El 22/08/2011 19:44, Brian Wood escribi?: >> Would you be willing to add a function that gives that? Tia. > > Yes, I think we need to think about a useful interface for that, maybe > something like local_iterator in unordered containers or something like > segmented iterator described by Matt Austern in his "Segmented Iterators > and Hierarchical Algorithms" paper If I could get the number of elements in the first chunk and the size of the chunks, that would be sufficient. (I believe the size of the chunks is constant within a deque instance.) I find it disappointing that the latest version of the standard doesn't have anything related to this and would rather just get something working than figuring out what would be a flexible, general interface. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

[Locale] On Mac OS X 10.6 fails to find iconv
by Artyom Beilis 24 Aug '11

24 Aug '11

Hello, I need a help from Mac OS X users, I have many faults on Darwin: http://beta.boost.org/development/tests/trunk/developer/locale.html Where all GCC's are related to inability to find iconv for some reason. On my darwin 8.01 x86 I have no problems to compile this simple program: has_iconv.cpp #include <iconv.h> int main() { iconv_t d = iconv_open(0,0); (void)(d); } With g++ has_iconv.cpp -liconv Also BBv2 script of Boost.Locale finds the iconv without a problem, so I'm quite lost. So if anybody that uses Boost from svn-trunk can check why has_iconv test fails (if it is on their machines) and see if ./bjam libs/locale/test prints ....... - iconv (libc) : no - iconv (separate) : no ....... And for what reason (if the sample code above compiles) I would be grateful. Because I have no idea what happens there and I don't have Mac only Darwin 8 which handles it properly. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 5

[Boost.Interprocess] Chronic performance on Win7
by Gav Wood 24 Aug '11

24 Aug '11

Hi, we're using the Boost Interprocess layer to do some shared-memory-based IPC and after getting awful performance characteristics out of sync primitives (in particular the condition variables, but similar results with semaphores) decided to do some profiling. Our platform is a (dual-core) Intel Core 2 Duo, running 64-bit Windows 7 and a 64-bit build environment in MSVC 10. One thing we wished to see was the performance of process hand-offs; i.e. getting one process to block as it unblocked a second symbiotic process and vice versa. To this aim we made a tight loop looking like: boost::interprocess::named_mutex m(boost::interprocess::create_or_open, "ProfileCache-Mutex"); boost::interprocess::named_condition c(boost::interprocess::create_or_open, "ProfileCache-Condition"); scoped_lock<named_mutex> l(m); for (int i = 0; i < 1024; ++i) { c.notify_all(); c.wait(l); } and another, running in another process with the wait & notify_all() reversed. It was checked to make sure that hand-offs were happened properly (no spurious wakeups &c.). I don't have any graphs to hand (though they would be quite easy to create), but as a rough figure, assuming a relatively unfettered execution environment - no browsers running/music playing - we were getting about 45 second run times. That's approximately 40ms per round-trip between the processes or 20ms per forced context switch. I suspect it's no mere coincidence that the Windows scheduling timeslice happens to be 20ms in duration; for Windows the sched_yield call is implemented by a Sleep(1); this, on Windows 7 at least, has the effect of putting the thread to sleep for the rest of its timeslice. Not ideal for low-latency IP-hand-offs. The obvious way to gain far higher performance is to Sleep(0). This has had the meaning since Vista of "run any other thread that's ready to run" (it used to mean any other thread of equal priority that's ready to run, hence priority inversion could ensue and people favoured the more aggressively passive Sleep(1)). Changing to a Sleep(0)-based sched_yield gave appropriately speedy results; of the order of 600us for the 1024 roundtrips, about 300ns per forced context switch. Though the loop around the Sleep(0) is a nice, yielding spin loop, if all processes are waiting (perhaps on an external event), then it will needlessly use 100% of each of the used cores. Also far from ideal. My proposed solution, for which I have attached a draft patch, introduces an argument to sched_yield ("_iteration"), in order to allow sched_yield to customise its behaviour depending on how long it has been waiting so far. All loops around sched_yield() (yield-loops) have been changed to track the number of iterations and pass it as an argument to sched_yield(). Ideally we would like to Sleep(0) in the case that the yield-loop's exit condition will be satisfied within the next 20ms and Sleep(1) in all other cases. As a completely unknown prior, we can use an exponential PDF with the 0.5 point occuring at the duration that we have already been waiting for. Optimising for this model, we Sleep(1) once we have already been waiting 20ms, which puts it at around 50000-100000 Sleep(0) calls. The was tested empirically and gave a simple Sleep(0)-yield performance, but while reducing the CPU consumption to near 0 on indefinite wait()s. We tested to make sure performance wasn't hindered should the threads be of unequal priorities; this indeed wasn't the case. Comments? Regards, Gavin -- Save Ferris!

4 7

Conversion review
by Jeroen Habraken 23 Aug '11

23 Aug '11

My review of the Conversion library: Please note that I'll be referring to the pre-review thread which can be found here: http://lists.boost.org/Archives/boost/2011/07/183525.php. * What is your evaluation of the design? Please refer to the section discussing the potential usefulness of this library. * What is your evaluation of the implementation? The code looks clean but I'm worried about the abundant use of boost::enable_if. While it is a useful tool SFINAE does make code fragile, possibly using something akin the following is an option: template <typename Target, typename Source, bool CA, bool EEC, bool A> struct assigner_impl { // No cookies BOOST_STATIC_ASSERT(sizeof(Target) == 0); }; template <typename Target, typename Source> struct assigner_impl<Target, Source, true, true, false> { // Copy-assignable, extrinsically explicitly convertible and not assignable ... }; template <typename Target, typename Source, bool CA, bool EEC> struct assigner_impl<Target, Source, CA, EEC, true> { // Assignable ... }; template <typename Target, typename Source> struct assigner : assigner_impl< Target, Source, is_copy_assignable<Target>::value, is_extrinsically_explicitly_convertible<Source, Target>::value is_assignable<Target, Source>::value > { }; (Note, this was written on the fly in this email, it may not actually compile.) * What is your evaluation of the documentation? Everything seems to be covered well, small comment though: template <> struct is_assignable<X&, X const&> : true_type { }; I initially missed that true_type is boost::true_type, this should be made more obvious. * What is your evaluation of the potential usefulness of the library? Let me tackle this in several parts: - type-to-string and string-to-type conversions In the pre-review we came to the following conclusions: "Coming back to the string to int conversion, if we can not have a default string-to-type or type-to-string, Boost.Conversion must remove these specializations." "I don't think that Boost.Conversion can provide a string-to-type conversion that is configurable. It could provide one if there is a consensus of a default. We should see Boost.Conversion customization as if we were adding some methods to one of the classes. For the string to float conversions, it is as if we were adding explicit operator float() const; to the std::string class. " I still maintain that this is the case, there is no sane way to let the user select between Convert or LexicalCast at the moment and possibly Coerce in the future and it's not something this library should be tackling. - STL conversions I believe these functions are of little use as when I would have to convert a list of integers to a list of doubles I'd simply write a loop (possibly aided by BOOST_FOREACH) instead of looking up a library (and reading the necessary documentation) to do it for me. With the offered customization points the cure seems to be worse than the disease, if I had to convert a std::pair<int, int> to a std::pair<double, double> I'd write a quick function to do so. The Conversion documentation however shows the following: template <typename Target1, typename Target2, typename Source1, typename Source2> struct implicit_converter_cp< std::pair<Target1,Target2>, std::pair<Source1, Source2> , typename enable_if_c< is_extrinsically_convertible<Source1, Target1>::value && is_extrinsically_convertible<Source2, Target2>::value >::type > : true_type { std::pair<Target1, Target2> operator()(std::pair<Source1, Source2>& v) { return std::pair<T1, T2>(implicit_convert_to<T1>(from.first), implicit_convert_to<T2>(from.second)); } }; This is a more generic solution but it seems like an awful lot of trouble for something this simple. - The Boost conversions These do seem very useful, but as discussed in the pre-review: "You are right and the same applies to any type-to-type conversion. And maybe this is the MAJOR flaw of Boost.Conversion: to think that we can define extrinsically THE conversion between two types. Every body admit that if a class T defines a constructor from a std::string THE conversion from std::string to T is the one defined by this constructor." I do believe that this library isn't the place for the conversions, they should be added to the specific libraries themselves in the form of constructors. * Did you try to use the library? With what compiler? Did you have any problems? I've tried several examples with GCC 4.2.1 (the default shipped with OS X), 4.5.3 and clang 2.9 on OS X. Both versions of GCC worked fine, clang however was unable to compile the examples with the following error: In file included from no_throw.cpp:13: In file included from ../../../boost/conversion/include.hpp:20: In file included from ../../../boost/conversion/convert_to.hpp:22: In file included from ../../../boost/conversion/explicit_convert_to.hpp:38: In file included from ../../../boost/conversion/implicit_convert_to.hpp:40: In file included from ../../../boost/conversion/type_traits/is_convertible.hpp:25: In file included from ../../../../library/boost-trunk/boost/fusion/tuple.hpp:10: In file included from ../../../../library/boost-trunk/boost/fusion/tuple/tuple.hpp:11: In file included from ../../../../library/boost-trunk/boost/fusion/container/vector/vector.hpp:11: In file included from ../../../../library/boost-trunk/boost/fusion/container/vector/detail/vector_n_chooser.hpp:14: In file included from ../../../../library/boost-trunk/boost/fusion/container/vector/vector10.hpp:14: In file included from ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/begin.hpp:17: In file included from ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11: In file included from ../../../../library/boost-trunk/boost/fusion/iterator/segmented_iterator.hpp:13: In file included from ../../../../library/boost-trunk/boost/fusion/container/list/cons.hpp:14: In file included from ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/end.hpp:17: ../../../../library/boost-trunk/boost/fusion/sequence/intrinsic/detail/segmented_end.hpp:33:70: error: invalid use of incomplete type 'fusion::nil' segmented_end_impl<Sequence, fusion::nil>::call(seq, fusion::nil())); ^~~~~~~~~~~~~ Not sure what's going on here exactly. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something between a quick reading and an in-depth study. * Are you knowledgeable about the problem domain? As the author of Coerce I'm knowledgeable about the string-to-type and type-to-string domain, less so about the generic type-to-type domain though. * 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. NO, the library should not be accepted as a Boost library in the current form. However the following should be done: - There are several type traits which can possibly be added to Boost.TypeTraits. This is not something I can judge, it is up to the auteurs of Conversion and TypeTraits to judge which are useful. - The conversions regarding Boost classes should be added to the respective libraries in the form of constructors if the respective auteurs believe this adds value to their library. Kind regards, Jeroen Habraken

3 4

[GSoC] Coerce summary and request for feedback
by Jeroen Habraken 23 Aug '11

23 Aug '11

Hi, As the Google Summer of Code has ended yesterday I'd like to thank Google and my mentor Hartmut Kaiser for the opportunity and guidance. Whilst Coerce is an on-going project (it's more than a year old already, time does fly when you're having fun) the GSoC sped up development significantly. To summarize Coerce for those not familiar with it, it's a type-to-string and string-to-type conversion library aiming at speed and extensibility. During the GSoC the following major things have happend: * Added tests, catching bugs and allowing me to prevent bugs in the future (hopefully). * Rewritten the tag system to be more flexible. * Added documentation, the latest version of which can be found over at http://vexocide.org/coerce/. In general the library matured, and while it's not done yet (the documentation in particular) I believe it's approaching production stability with the number of impacting changes dropping significantly over time. The current code can be found at http://svn.boost.org/svn/boost/sandbox/coerce/ and as usual I'd be grateful for any comments or critique. If you have questions do not hesitate to contact me. Kind regards, Jeroen Habraken P.S. If you're still using construe_cast (a previous incarnation of this project) please consider migrating to Coerce as I plan on removing https://github.com/VeXocide/construe_cast soon.

1 0

[Units] test_trig fails on Sandia-darwin-4.4 (caused by compile-time evaluation of math functions)
by Michel MORIN 23 Aug '11

23 Aug '11

The Units' test (libs/units/test/test_trig.cpp) fails on Sandia-darwin-4.4: http://tinyurl.com/3wherck The failure is caused by the fact that the results of `std::acos(0.2)` and `std::acos(d)` (double d = 0.2) are NOT equal on Sandia-darwin-4.4. On gcc-4.3 and newer versions, built-in math functions having constant arguments are evaluated at compile time using the MPFR (Multiple Precision Floating-Point Reliable) library. This happens even if optimization is disabled. So, the results of std::acos(0.2); // evaluated by the MPFR library at compile time and double d = 0.2; std::acos(d); // evaluated by the built-in function at run time are different. (If we compile with optimization enabled, the latter code is also evaluated by the MPFR library at compile time.) The solution to this problem is * Change BOOST_CHECK_EQUAL to BOOST_CHECK_CLOSE_FRACTION. or * Change `std::acos(0.2)` to `std::acos(d)` (with `double d = 0.2`) An interesting thing is that the test fails only on Sandia-darwin (x86-64) platform. On other platforms using gcc 4.3-4.6, the test runs successfully. I suspect that they have 80-bit registers and so the result of `std::acos(d)` is as accurate as the result of the MPFR library. Do you have any thoughts about this? Regards, Michel

3 3

[odeint] GSoC Summary and Feedback request
by Mario Mulansky 23 Aug '11

23 Aug '11

Hi, this is a summary of the progress of the odeint-library during this years GSoC. First of all I would like to thank Andrew for mentoring this project and also for the many fruitful comments and hints he gave during the past months. The aim of the project was to finalize odeint and prepare it for a boost review. This goal has been, more or less, achieved, I think. Although some work on docs and maybe some minor usability improvements are to be done we think we have reached a state of development ready for a review and we might try take this step in the near future. The puropose of odeint is to provide algorithms to numerically solve ordinary differential equations (ODEs) given as initial value problems: x'(t) = f(x,t) , x(0) = x0. It is written by Karsten Ahnert and myself. Please visit the docs to find out more about the features and abilities of odeint: http://headmyshoulder.github.com/odeint-v2/doc/index.html During the GSoC project, we switched from a svn branch in the boost sandbox to a new git project called odeint-v2: https://github.com/headmyshoulder/odeint-v2 In terms of code, I have made the following improvements to odeint: * Implementation and performance tests of a generic Runge-Kutta algorithm. * Implementation of several algorithms using the generic Runge-Kutta scheme (rk4, rk54ck, rk78) * Redesign of the construction/destruction of temporary states by use of a state_wrapper * Redesign of the resizing functionality by usage of boost::bind * Redesing of the algebra implementation to now use instances instead of static functions. * Creating mkl_operations to make use of Intel's MKL for optimal performance * major refactorings (e.g. renaming stepper classes) * Implementation of a Bulirsch-Stoer stepper with dense output * Improvement of integrate functions so they have consistent behavior * Adding integrate_times function to allow for observation at user defined time points * Adding unit tests for integrate functions Additionally, I worked on the documentation: * Created an overview over all implemented algorithms * Adding a resizing example to the tutorials section * Adding a description of the integrate functions * Adding a brief concept description of steppers, system and observer * Adding a brief overview on the Algebra/Operations and how they interact Besides his fruitful input and discussions related to my work presented above, Karsten also put quite some effort into odeint during the GSoC period, e.g. providing examples and tutorials in the docs section or adding multistep and implicit algorithms (adams-bashforth, rosenbrock4). We are very happy about any feedback on the work done within this GSoC or on odeint in general. If you have any further question please feel also invited to contact us. Finally, I want to thank the boost communtity for giving me the possibility to take part in this years GSoC as part of the boost organization. I have learned a lot during this time and I think odeint took a major step forward in terms of design and extent. Regards, Mario

4 5

Boost.Conversion review
by Gordon Woodhull 22 Aug '11

22 Aug '11

Hi all, The review of Vicente Botet Escriba's Conversion library starts this Saturday August 20 and continues through August 29. This library provides a general system for type-to-type conversion. As such, it can be thought of either as a substitute for overloading static_cast, or as an alternative to lexical_cast when the intermediate conversion to text is not wanted. The code is in the sandbox: http://svn.boost.org/svn/boost/sandbox/conversion/ And the docs are here: http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… I'll send out a formal announcement when the review begins, but I wanted to send out this reminder because participation in summer months tends to be somewhat low. Your review and/or discussion would be greatly appreciated. As always, please post to the main Boost list if possible, or the boost-users list, or you can send your review directly to the Review Managers. Thanks, Gordon Woodhull, Review Manager Espen Harlinn, Review Manager Assistant

5 13

[containers] Templated map::find?
by Lars Viklund 22 Aug '11

22 Aug '11

Hi list. I was asked today why the std::map container didn't have templated versions of functions like find, lower_bound, and so on. I could not give a good answer on why there could not exist such a thing, assuming that the comparator had sufficient symmetric overloads for the real Key type and the FauxKey that the query would be performed with. Would something like this be possible to add to Boost.Containers, considering that going through the typical standard routes would have a latency of a couple years at best? I'm told that the Boost.Intrusive containers already supports this. Some use cases would be querying with a type that's convertible (in an expensive way) to the held key type, or querying with a key type that has only the fields that affect ordering in the case of a rich key type. -- Lars Viklund | zao(a)acc.umu.se

4 4

[Locale] Request to merge to release branch
by Artyom Beilis 22 Aug '11

22 Aug '11

Hello, I want to request a permission to merge Boost.Locale to the release branch. Testing Status: =============== Link:http://beta.boost.org/development/tests/trunk/developer/locale.html Fully tested and pass 100% compilers/platforms: ----------------------------------------------- Compilers: - MSVC-8,9,10 with native libraries - GCC all versions - Intel - on Linux - Visual Age on Linux Current major faults: --------------------- - Sun Studio - reported bug in Boost.Thread - Intel on Darwin - seems to be general compiler regression for all libraries (not related to Boost.Locale) - MSVC for Windows Mobile - not supported, will not be supported due to lack of standard library functionality - Visual Age/AIX - iconv has poor implementation on AIX and ICU not provided on the testing machine so, there is no way to test. Minor faults: ------------- - GCC prior to 4.5 on Windows - will not work with dynamic build (dll) due to lack of linking with dynamic runtime (libstdc++6.dll) - Pathscale-4 and MSVC-9 with STL-Port: minor fults in wide file I/O where invalid UTF-8 prevents reading valid part. Can't debug it due to lack of access to platform and compiler. Thank you very much, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 6

[fusion] segmented fusion 2.0
by Eric Niebler 22 Aug '11

22 Aug '11

I took the liberty of rewriting all my old broken segmented fusion code and checked in something (hopefully) a bit more maintainable and friendly. Along with the changes, I added an algorithm called segmented_fold_until. Many of the existing algorithms have segmented versions that can be implemented trivially in terms of this one. (Recall that the biggest problem with the old implementation was the need to write a separate implementation of every algorithm for segmented data structures, which was very complicated. Now that's almost trivial.) I hope in the coming weeks and months to produce segmented versions of most of the existing fusion algorithms. Once that's done, I hope to "bake it in" by making the existing algorithms select the segmented flavors automatically. Also, some containers and views are naturally segmented, like joint_view. Practically all of joint_view's implementation, including its iterator, would vanish if it just advertised itself as segmented. Thoughts? Objections? -- Eric Niebler BoostPro Computing http://www.boostpro.com

7 26

[intrusive] Move constructors
by Rei Thiessen 21 Aug '11

21 Aug '11

Could we add move constructors to all intrusive containers? Rei

2 2

[enums] Request for comments on an enum-oriented library
by Beren Minor 21 Aug '11

21 Aug '11

Hi all, I'm currently writing a C++ library to add some functionalities to enums, and am looking for comments and feedbacks. Boost is a reference, and I would be glad if some C++ expert here could take a moment to look at what I've written and tell me his thoughts. I know that there was already some discussions about enums here, and some early implementations of enum libraries at Boost, but I couldn't find any that fitted my requirements, or any that was in an stable enough stage. My goal wasn't to submit another one to Boost (although I would be really proud of it, I'm not thinking about it yet, just looking for comments), but to implement something usable for some of my specific needs. Initially I was only looking for enum (de)serialization, however I think that these needs can be quite common, and that the library could be used by others as well. That's why I'm trying to find some comments and to share my work. My goal was to implement a library following these requirements : - Extend the enum concept with different flavors. - Scope the enum constants out of namespace scope. - Do not get rid of implicit integer cast, or at least, try to provide enum/integer interoperability so we don't have to cast all the time. - No overhead, keep the enum constants as light as they are natively. For the first requirement, I wanted to add three new flavors to enums, that I've called "static enums", "dynamic enums" and "bit fields". The main difference between them is the way these enums are (de)serialized and the available enum / enum and enum / integer operators when this is meaningful (only when using C++0x, with scoped enums). - Static enums only allow explicitly defined constants (with specified or implicit integer values), any other value will result in a (de)serialization to special value "unknown". - Dynamic enums allow explicitly defined constants and offsets from these constants, within a given global range (from the first constant to the specified upper integer limit). Every value within the range will be serializable, any other will result in "unknown". An integer value between two enum constants will be (de)serialized as the nearest lower enum constant plus an offset. For example, if the enum is defined as { value1 = 1, value2 = 5..., unknown = 10 }, the available range would be from 1 to 9, and the integer 4 will be serialized as "value1#3" which means (value1 + 3). - Bit fields enums only allow combination of explicitely defined constants. These will be (de)serialized as a combination of every defined enum constants, any other value will be (de)serialized as "unknown". This flavor restricts constants values to bitwise distinct integers, and to values different from 0 in order to be able to decompose the enum into the specified enum constants. 0 being the special "unknown" value for this flavor. For example, for an enum defined as { bit1 = 0b001, bit2 = 0b010, bit3 = 0b100... }, an instance of this enum with an integer value of 3 will be serialized as "bit1+bit2", and "bit1+bit3" will be deserialized as an enum instance of integer value 5. As I said, the library obviously uses Boost, and in an extensive way Boost Preprocessor macros, and tries to integrate nicely with Boost libraries. Serialization, for example, is done through stream template operators, and should be usable with the Boost Lexical Cast library. These isn't any real documentation yet, except from doxygen (although not yet complete, I've tried to be verbose), but I think that the library is simple enough to be understood by reading the source code, and I've got some unit tests to help getting the genereal idea. Lastly, I still have some issues about some points, mostly because of the use of macros and boilerplate code, but I hope to be able to fix them. - No namespace support. - Enum declaration comes with the serialization code. I would like to be able to separate definition and declaration of this code, but I'm not sure how to do that properly without overhead for the developer. I'll have to think about it. - The writing overhead of the enum declaration (compared to plain old enum) is still a little bit too much for my taste, but I don't know if I'll be able to do much better without introducing some obscure and meaningless helper macros. This is mainly because of the need of declaring the enum constants in a Boost Preprocessor sequence, in order to be able to use it at various places to generate the enum declaration as well as the serialization code. - Also, the declaration could be cleaner if I could find a way to implement optional parameters in macros, but that seems like difficult to do (or I haven't found out yet how to do). - I don't have any other environment available except from my Debian Linux box, so I couldn't test on anything else than gcc. I don't really expect it to work with anything else. Actually, my main build scripts themselves are probably broken on anything else than my computer. [1] That said, if anyone wants to take a look at it and share his thoughts, the library can be found here : https://github.com/berenm/libtenum Best regards, Beren Minor Notes: [1] I've added a "portable-build" branch to my git repo if anyone want to try running the tests cases somewhere else. Build is done with bjam.

3 3

Intel compiler and Boost libraries
by Edward Diener 20 Aug '11

20 Aug '11

I normally do not mind paying for software that much but because of the tight economic times for myself I am a bit loth to pay for a version of the Intel C++ compiler, which is not exactly cheap, in order to just test out my Boost libraries. Ordinarily I can use gcc in Linux and Windows, clang on Linux, or VC++ on Windows. But I am aware that the more compilers I can test my libraries with, the better off my library will be and in the review of my TTI library one of the points made is that I need to test it and guarantee that it will work on a wider variety of C++ compilers. I am wondering how others have come by their copies of Intel C++ ? Have you bought it, have you gotten it on some sort of academic pricing, have you acquired a license as part of your job, does Intel offer an inexpensive or free version of their compiler for C++ experts like Boost developers who are helping to test their compiler against the most rigorous C++ code as Boost libraries usually are, or what is the situation for others who test their libraries using Intel C++ ? I realize there is a 30-day free trial but after that 30 days one can not use the compiler for a particular OS without having a valid license for it.

3 3

Re: [boost] [Containers Library Review] The review of the Containers library by Ion Gaztanaga starts today
by Ion Gaztañaga 19 Aug '11

19 Aug '11

El 19/08/2011 23:55, Dave Abrahams escribió: > Find the performance tests being used by clang's libc++ and try those? Thanks, is that code license-compatible with Boost license? Best, Ion

1 0

[UUID] seed_rng.hpp contains invalid forward declaration of random_device
by Johan Lindvall 19 Aug '11

19 Aug '11

The following fails to compile with 1.47.0: #include <boost/uuid/seed_rng.hpp> #include <boost/random/random_device.hpp> It used to work with 1.46.1 (using nondet_random.hpp) Filed as https://svn.boost.org/trac/boost/ticket/5794 -- /Johan.

1 0

[random] uniform_smallint
by Agustín K-ballo Bergé 19 Aug '11

19 Aug '11

boost::uniform_smallint<> distribution defaults its min and max constructor arguments to 0 and 9 respectively. While arbitrary, this may make sense for default constructed distributions. However, its easy to trigger an assert at runtime by calling its constructor with a single value (min > 9). Could this constructor be splitted into a default constructor and one that takes *both* min and max? I tried to check whether the standard mandates this, but couldn't find the FDIS online anymore (on a separate note, anyone knows where to find it?). Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com

1 0

[gsoc] Request Feedback for Boost.Ustr Unicode String Adapter
by Soares Chen Ruo Fei 19 Aug '11

19 Aug '11

Hi all, A while ago I gave some previews of my Unicode String Adapter library to the boost community but I didn't receive much feedback. Now that GSoC is ending I'd like you all to take a look at my project again and provide feedback on the usefulness of the library. Following are the links to my project repository and documentation: GitHub repository: https://github.com/crf00/boost.ustr Documentation: http://crf.scriptmatrix.net/ustr/index.html Recently there was some threads in the mailing list mentioning about Unicode issues and forcing the use of UTF-8 encoding in std::string again. I feel certain that few of the key people involving in the debates should have at least read my project proposal before and understand what Boost.Ustr was trying to achieve, however it seems like my approach is not much favored by anyone. So here I'd also like to know from these people why my approach on using Unicode string adapter is not the best way to solve the Unicode problem in C++. I understand that the requirement to alter existing APIs might be the biggest barrier to make Boost.Ustr adopted by everyone, but I think here is the key question: if you have the chance to go back in time and restart your project from scratch, are you willing to use Boost.Ustr in your library APIs and do you think that it could have solved the Unicode problems you're having right now? Thanks. Best Regards, Soares Chen

14 61

Re: [boost] New version of Boost.Algorithm (proposed) in the vault
by TONGARI 17 Aug '11

17 Aug '11

2011/8/18 Marshall Clow <mclow.lists(a)gmail.com> > > On Aug 17, 2011, at 9:28 AM, TONGARI wrote: > > > 2011/4/19 Marshall Clow <mclow.lists(a)gmail.com> > > > >> < > >> > http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.… > >>> > >> > >> Changes since -008: > >> > >> * Better documentation all around - including doxygen. > >> * Fixed typo-style bugs in all.hpp, and added tests to make sure they > stay > >> dead. > >> * Better comments in clamp.hpp, and better tests. > >> * The search algorithms now deal correctly with zero-length patterns and > >> corpuses, and have tests for that. > >> * The search algorithms now have tests for the compile-time assertions. > >> * MSVC 10 compatibility > >> > >> Please download, try it out, and let me know! > >> > > > > I was trying to use KMP and got some errors: > > * No CHAR_BIT declared. > > * template boost::algorithm::knuth_morris_pratt does not accept plain > > pointer type. > > What compiler and version (and OS)? > g++4.5.2/MinGW, on XP SP3, compiled with c++0x enabled. But I don't think it's compiler specific, I can locate the errors...

2 1

[filesystem] Documentation error?
by John Maddock 17 Aug '11

17 Aug '11

The filesystem docs mention: #include <boost/filesystem> But of course no such file exists. John.

1 0

[vmd] Variadic Macro Data library updated to version 1.5 in the sandbox
by Edward Diener 17 Aug '11

17 Aug '11

I have updated the variadic_macro_data library in the sandbox 'variadic_macro_data' directory to version 1.5. The variadic_macro_data library, or VMD for short. adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. The changes in this version are: 1) The library now operates in one of two modes. The 'native' mode, which is the default, uses the library's own coding for various macros. The 'pplib' mode uses the code of the Boost PP library on the trunk for various macros. The documentation gives the equivalent Boost PP trunk macros for VMD macros. 2) Individual header files can be included instead of the vmd.hpp header file. 3) Macros have been added for detecting and removing beginning parens. 4) A macro has been added for testing for emptiness using variadic macros. 5) Macros have been added for verifying Boost PP data types. 6) Added control macros for controlling the variadic macro availability, mode, and data verification. There is a readme.txt in the top-level sandbox directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.3.3, 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1, 4.6.0 and VC++ 8.0, 9.0, 10.0. It should also work with other compilers which support variadic macros. Questions, comments, suggestions, and bug reports are all welcome.

1 1

New version of Boost.Algorithm (proposed) in the vault
by Marshall Clow 17 Aug '11

17 Aug '11

<http://www.boostpro.com/vault/index.php?action=downloadfile&filename=Boost.…> Changes since -008: * Better documentation all around - including doxygen. * Fixed typo-style bugs in all.hpp, and added tests to make sure they stay dead. * Better comments in clamp.hpp, and better tests. * The search algorithms now deal correctly with zero-length patterns and corpuses, and have tests for that. * The search algorithms now have tests for the compile-time assertions. * MSVC 10 compatibility Please download, try it out, and let me know! Thanks! -- 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

Help tracking down a GCC codegen issue
by Matt Fischer 17 Aug '11

17 Aug '11

Hi all. I'm trying to compile boost under GCC for ARM, and am running into an instance of some bad assembly code being generated. The actual problem seems likely to be an issue with GCC itself, or possibly some kind of modification that the vendor, CodeSourcery, made to it. I've contacted them about the problem [1], but in order to diagnose it, they need a reduced test case that doesn't involve the boost library. I'm attempting to dig out the relevant code and use it to construct a test case, but I'm having some trouble navigating the boost codebase, and was wondering if anybody could provide some assistance. A program that illustrates the problem is the following (compiled on Windows, using GCC 4.5.2 with Boost 1.40): ----------------------------------------------------------- #include <boost/signal.hpp> bool func() { return false; } int main(int argc, char *argv[]) { boost::signal<bool ()> sig; sig.connect(func); bool result = sig(); } ----------------------------------------------------------- Normally this works fine, but if I compile for GCC under ARM with -mthumb -Os, one of the instantiated template functions has some bogus assembly code in it (prepare for wall-of-text): 00000000 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int (boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)>: 0: b537 push {r0, r1, r2, r4, r5, lr} 2: 1c05 adds r5, r0, #0 4: ac01 add r4, sp, #4 6: 1c29 adds r1, r5, #0 8: 1c20 adds r0, r4, #0 a: f7ff fffe bl 0 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>(boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)> e: 1c28 adds r0, r5, #0 10: f7ff fffe bl 0 <boost::detail::postfix_increment_result<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, bool const&, boost::single_pass_traversal_tag>::type boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>(boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<bool>::caller<boost::function<bool ()()> >, boost::signals::detail::named_slot_map_iterator>, bool, boost::single_pass_traversal_tag, bool const&, int>&, int)> 14: 7820 ldrb r0, [r4, #0] 16: bc37 pop {r0, r1, r2, r4, r5} 18: bc02 pop {r1} 1a: 4708 bx r1 The error is on line 14 and 16: we load up the return value from this function (a bool) into r0 in preparation for return, but then turn around and pop off a bunch of values from the stack, placing one into r0, which overwrites the return value and causes garbage to be returned to the caller. If I can produce a standalone test function that illustrates the problem, the compiler folks can probably figure it out. I've been trying to make one, but all of the template magic is making it difficult for me to track down where this function is coming from in the source code, and what a suitable standalone equivalent might be. Is there anybody who is familiar with all of the slot code that might be able to help out with this? Thanks, Matt 1. Original posting at http://www.codesourcery.com/archives/arm-gnu/msg04302.html

1 0