- Boost - lists.preview.boost.org

Requesting number crunchers for trial complex classes
by Daryle Walker 22 Jul '13

22 Jul '13

I just pushed out commit "aaeabbd3fcc04956c4fd3d3825f6202355ab9297" of my trial hypercomplex number classes at https://github.com/CTMacUser/Complex. The classes now have all the arithmetic operators. They already have the condition functions (norm and conj), norm functions (taxi (ex L1), abs, sup, and sgn), and equality operators. There is an output operator, but not input. There are constructors for: default (both garbage bits and all zeros), copy and move (automatically defined), component (single or list), cross version, smaller hypercomplex (single and list), and (head of) larger hypercomplex. Look at the unit tests for usage examples. I haven't done any utility or transcendental functions yet, so let me know if you need them before proceeding. I just want people who do hard-core number crunching with complex, quaternion, and/or octonion numbers to see if my classes are worth it, performance-wise. You can also use the array-of-hypercomplex to array-of-many-reals reinterpret_cast trick. Everything should have Doxygen comments. I run this code on GCC 4.7.1 off MinGW for 32-bit Windows 8 Pro, so tests on other compilers will be appreciated. (It probably can't run on Visual C++, but GCC 4.8 and Clang 3.x will probably work.) Note on octonions: a month ago I found out, while looking for online octonion calculators, that octonion (and above) multiplication isn't standardized. I'm using the same philosophy from Wikipedia, which is also used by the existing Boost.Octonion. (Actually, I found a bug in B.O.'s octonion times quaternion code, since that author manually lists all the sub-terms, and my code is more automatic. I had to do the multiplication by hand to check who had it right.) So if your octonion products are different, it may not be a bug. I've tried to make as many constructors/operators/functions constexpr as possible. (That's why no std::initializer_list.) That may help move data into ROM, but you have to force non-inline-ness when you need to test runtime performance. Daryle W.

1 0

[Locale] does generator("") deliver the system's default locale?
by Michael Schinner 22 Jul '13

22 Jul '13

boost 1.54.0 When I use boost::locale::generator and generator("") I get different results for the decimal point than using std::locale(""). Boths methods are supposted to deliver the system's default locale. Example: // windows 7, de_AT std::use_facet<std::numpunct<char> >(std::locale("")).decimal_point(); // delivers a , boost::locale::generator generator; std::use_facet<std::numpunct<char> >(generator("")).decimal_point(); // delivers a . What does generator("")) deliver? Is it wanted that a '.' is deliverd as decimal point for a german locale? Best regards, Michael

2 1

[system] Do we need this library with latest (almost C++0x) compilers?
by Tonko Juricic 22 Jul '13

22 Jul '13

Can somebody please explain what is missing in current compiler implementations? What is preventing other libraries to have a macro like: #ifdef _CPP11_THREAD_ #include <thread> #include <mutex> #include <condition_variable> #else #include <boost/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/thread/condition_variable.hpp> #endif also when it comes to error codes and conditions? Thanks, Tony

3 2

windows_shared_memory - does memory block exists?
by piotr.ns 21 Jul '13

21 Jul '13

Hi, Why native windows shared memory does not include any means to check for existance of memory block without throwing exceptions? A small function would be enough: // boost::interprocess::windows_shared_memory static bool exists(const std::string &a_path) { using namespace boost::interprocess; try { unsigned long file_map_access = winapi::page_readonly; unsigned long map_access = winapi::file_map_read; void *test_handle = winapi::open_file_mapping(map_access, a_path.c_str()); bool res = (test_handle != NULL); if(res) winapi::close_handle(test_handle); return res; } catch(...) { return false; } } Without this I have to use Boost internals (winapi::*) in my application. Would somebody consider including this code or something similar? Regards, Piotr

1 0

Status of various Boost initiatives?
by Robert Ramey 21 Jul '13

21 Jul '13

I'm trying to get a handle on the current state of the various boost migrations which have been underway. a) migration to GIT b) migration to CMake c) status of rypll when I try to track this down I find many dead links, repeated information. I also don't find some blogs I used to be able to find on these subjects. Anyone up to provide an current status snapshot? Robert Ramey

5 14

Mag Gam
by Mag Gam 21 Jul '13

21 Jul '13

http://yumaonline.it/bau/bcjk.xvdhjqpdiniqwmxf Mag Gam 7/21/2013 7:26:51 AM

1 0

Re: [boost] [regression] patch for running tests in parallel and out-of-sync files
by Robert Kawulak 20 Jul '13

20 Jul '13

> From: Robert Kawulak > When I was running tests in parallel (using b2 -j option) I was getting random > warnings in the results table because "msvc.manifest" lines were interleaved with > compile/link actions. I've fixed this with the attached patch - is it OK to apply > it to trunk/release? Due to the lack of feedback I've gone ahead and applied the fix in trunk for now. If nobody objects or reports issues, I'll merge it into release later. > BTW, I've noticed that the following files in tools/regression/src haven't been > updated in release branch even though they've been changed in trunk a long time > ago: > compiler_status.cpp (trunk date 2012-01-21, release date 2011-10-06) > library_status.cpp (trunk date 2013-03-25, release date 2013-03-09) > Is it OK to update these in release branch? Likewise, I've updated the two files in release. I've also added tools/regression/build/bin directory to ignore list (it's created when invoking b2 from tools). Best regards, Robert

1 0

[git conversion] type_traits problems; spurious headers
by Beman Dawes 20 Jul '13

20 Jul '13

libs/type_traits/include/boost has these files: aligned_storage.hpp call_traits.hpp config.hpp smart_ptr.hpp timer.hpp type_traits.hpp utility.hpp AFAIK, call_traits.hpp and type_traits.hpp are supposed to be there, but the rest are spurious, and are causing "b2 headers" to create some incorrect links that are preventing testing many libraries. --Beman

2 1

[git-help] Status?
by Rene Rivera 20 Jul '13

20 Jul '13

I started looking at making the final minor set of changes to the regression testing scripts to have the option of testing the modular git version of the boost super-project. Unfortunately it now seems that the super-project no longer has *any* of the references to the library sub-projects. Me not being able to get this work done now is rather annoying as it likely means that the testing will not be ready early in the 1.55 release cycle. Which is the release currently scheduled to switch to git. What is the status of the git transition? When will the Boost release team be able to start working on the switch? Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

5 11

Re: [boost] A more convenient Variant visitation syntax
by Charlls Quarra 19 Jul '13

19 Jul '13

________________________________ De: Dave Abrahams <dave(a)boostpro.com> Para: boost(a)lists.boost.org Enviado: sábado, 14 de abril de 2012 22:49 Asunto: Re: [boost] A more convenient Variant visitation syntax on Sat Apr 14 2012, Thomas Heller <thom.heller-AT-googlemail.com> wrote: > On Sat, Apr 14, 2012 at 5:41 PM, Mathias Gaunard > <mathias.gaunard(a)ens-lyon.org> wrote: >> On 14/04/12 17:00, Kevin Wu Won wrote: >>> >>> This is C++11 only because it's quite pointless without lambda >>> functions. I've tested it with gcc 4.7. It doesn't work on gcc 4.6, >>> which can't handle the variadic templates. >> >> >> It can be done in C++03 and expression-template-based lambdas just fine as >> well. >> >> All you need to do is generate a function object that inherits recursively >> from a set of other function objects. >> >> The function objects in question need to be either monomorphic or to be >> sufficiently constrained with SFINAE so that each operator() overload is not >> ambiguous. >> >> Unfortunately, Boost.Phoenix was never extended to support this. > > I really like the idea, and i think the C++11-based solution above is > nice! I didn't have the time yet to glance through the code though ... > > Phoenix didn't tackle that yet because it is a hard problem ... the > main problem is the syntax how to express which lambda is responsible > for what types. The above solution with C++11 lambdas is nice indeed! Yeah, the first time I've actually been happy that non-polymorphic lambdas exist! Nice idea, Kevin! > However, what's missing is something like a "catch all" aka a > templated lambda ... ...ah, yes... there's the rub. And my day is now spoiled :-) There is a catch all case. Just provide a lambda for boost::blank. See the original thread on StackOverflow where Me and R. Martinho Fernandes came up with the template syntax. There is also a complete code snippet with test cases on the post http://stackoverflow.com/q/7867555/170521

1 1