- Boost-users - lists.preview.boost.org

[boost] [review] Multiprecision review (June 8th - 17th, 2012)
by Jeffrey Lee Hellrung, Jr. 16 Jun '12

16 Jun '12

Okay, it's that time. Apologies for not sending a reminder, but there had been a lot of pre-review comments over the last week or so, so I think this has been on at least some people's radar. The original review announcement is given below. On Tue, May 29, 2012 at 2:08 PM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung(a)gmail.com> wrote: > Hi all, > > The review of the proposed Boost.Multiprecision library authored by John > Maddock and Christopher Kormanyos has been scheduled for > > June 8th - June 17th, 2012 > > and will be managed by myself. > > From the Introduction: > > -------- > "The Multiprecision Library provides *User-defined* integer, rational and > floating-point C++ types which try to emulate as closely as practicable the > C++ built-in types, but provide for more range and precision. Depending > upon the number type, precision may be arbitrarily large (limited only by > available memory), fixed at compile time values, for example 50 decimal > digits, or a variable controlled at run-time by member functions. The types > are expression-template-enabled for better performance than naive > user-defined types." > -------- > > And from the original formal review request from John: > > -------- > Features: > > * Expression template enabled front end. > * Support for Integer, Rational and Floating Point types. > > Supported Integer backends: > > * GMP. > * Libtommath. > * cpp_int. > > cpp_int is an all C++ Boost licensed backend, supports both arbitrary > precision types (with Allocator support), and signed and unsigned fixed > precision types (with no memory allocation). > > There are also some integer specific functions - for Miller Rabin testing, > bit fiddling, random numbers. Plus interoperability with Boost.Rational > (though that loses the expression template frontend). > > Supported Rational Backends: > > * GMP > * libtommath > * cpp_int (as above) > > Supported Floating point backends: > > * GMP > * MPFR > * cpp_dec_float > > cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher > Kormanyos' e_float code (published in TOMS last year). > > All the floating point types, have full std lib support (cos sin exp, pow > etc), as well as full interoperability with Boost.Math. > > There's nothing in principal to prevent extension to complex numbers and > interval arithmetic types (plus any other number types I've forgotten!), > but I've run out of energy for now ;-) > > Code is in the sandbox under /big_number/. > > Docs can be viewed online here: > http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… > -------- > Any review discussion should take place on the developers' list ( boost(a)lists.boost.org) and anyone may submit a formal review, either publicly to the entire list or privately to just myself. As usual, please consider the following questions in your formal review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And, most importantly, please explicitly answer the following question: Do you think the library should be accepted as a Boost library? Lastly, please consider that John and Christopher have compiled a TODO list [1] based on pre-review comments. Feel free to comment on the priority and necessity of such TODO items, and whether any might be show-stoppers or warrant conditional acceptance of the library. Thanks in advance; looking forward to the discussion! - Jeff (& John & Christopher) [1] http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h…

2 1

[filesystem] is path comparison case-insensitive on Windows?
by Nathan Ridge 16 Jun '12

16 Jun '12

Hi, I couldn't find this info in the Filesystem documentation, so I thought I'd ask here: is equality comparison between path objects case-insensitive on Windows? I think it ought to be, since the operating system treats two paths differing by case only to be the same, but I thought I'd double-check. Thanks, Nate

5 8

positional arguments in boost::program_options
by Evan Driscoll 15 Jun '12

15 Jun '12

Hi, I'm writing a program which will run other programs (think xargs) and I have the following question. If I am reading the docs right, I get positional arguments by doing something like 1) Make a "normal" argument --arg 2) Tell it that positional arguments map to --arg However, if I do this, that means that if someone runs my_wrapper target_program --arg a then the --arg "disappears" because boost::po treats it as an actual option and not a positional argument. I can (mostly) get around this by naming all the fake positional arguments something like --ZZZZarg and assuming no one will ever want to pass that to another program, but it's a bit unsatisfactory conceptually. Is there a better way? Evan

2 3

signals2 multithreading with dumb pointers
by Chris Stankevitz 15 Jun '12

15 Jun '12

Hello, I have a problem that is turning to a big mess. I'm having trouble wrapping my brain around it enough to even ask a good question. Can you recommend techniques/classes/patterns to get me out of this mess? Thank you! 1. I have a "model" whose state changes 2. State changes are advertised via boost::siganls2. Signals are fired at up to 30 Hz. 2a. I have a lot of signals advertising a lot of different state changes. e.g. "employee name changed; employee age changed; etc" 2b. Signals are fired from different threads 3. I have a dialog that shows the state of the model. 4. The dialog connects to the signals and update the screen to reflect the changing state of the model. 4a. (4) is somewhat complicated by the fact that screen updates must happen on a particular "main" thread. I have some plumbing to deal with this and I believe it is logically safe. 5. Unfortunately, the dialog class cannot live inside a boost::shared_ptr. This is a requirement of wxWidgets. 5a. (5) means my dialogs cannot connect to "tracked" signals. 6. Unfortunately, wxWidgets sometimes delete (in the c++ "delete" sense) the dialog 'without warning'. 6a. (6) means my dialog destructor might be called while it is simultaneously receiving a signal. 7. In my dialog destructor I disconnect all boost::signals2::connections. 8. (7) does not wait signals to complete for returning. i.e. the disconnect will return immediately eventhough the signal is still "running" 8a. (8) can cause a crash 9. I deal with (8) by adding a "dialog facade", but I'm curious about other ways to do this. 9a. The "dialog facade" receives all signals and forwards them to the dialog iff the dialog is attached. 9b. While each signal is being serviced a shared_lock is kept 9c. The "dialog facade" lives in a shared_ptr and uses boost::signals2::slot_type::track() 9d. The dialog destructor first notifies the facade to "detach" from the dialog 9e. The "detach" function grabs a unique_lock and disconnects all boost::signals2::connections. This effectively implements a blocking version of (7) 10. (9) is a lot of work for all my dialogs with all my signals. 10a. (4a) makes (9) even uglier! Can you recommend techniques/classes/patterns to get me out of this mess? Thank you, Chris

3 3

Re: [Boost-users] 1.49 header order conflicts on Windows
by Brian Wood 14 Jun '12

14 Jun '12

Lars Viklund: > Asio is "friendly" enough to define WIN32_LEAN_AND_MEAN for you, which > pretty much breaks any other consumer of Windows.h. I wasn't aware that that's a no-no and am doing the same thing. My code doesn't compile without the define so am wondering what can be done to help. I'm also having another problem on Windows https://groups.google.com/forum/?fromgroups#!topic/comp.lang.c++/Hpoi2pbQD74 Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

[Container] [Intrusive] [Interprocess] Flat Intrusive Containers?
by Hering Cheng 14 Jun '12

14 Jun '12

Hi, While Boost.Intrusive provides more varieties of containers than Boost.Container, I wonder if it would make sense to provide flat maps or sets. The application I have in mind is to use these flat containers in shared memory in such a way that application programs preallocate all memory, just like it is possible with Instrusive containers. Would this be feasible? If this makes sense, is there any plan to make this available? Thanks. Hering

3 2

1.49 header order conflicts on Windows
by Davidson, Josh 14 Jun '12

14 Jun '12

Consider this following simple app: #include <boost/thread/thread.hpp> #include <boost/asio.hpp> #include <boost/thread/recursive_mutex.hpp> int main() { return 0; } If you try to build that on Windows, you receive the following error: In file included from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/recursive_mutex.hpp:14:0, from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/recursive_mutex.hpp:14, from build.cpp:3: c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::lock()': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:52:21: error: '_InterlockedExchange' is not a member of 'boost::detail' c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::unlock()': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:71:21: error: '_InterlockedExchange' is not a member of 'boost::detail' c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::try_basic_lock(long int)': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:91:21: error: '_InterlockedExchange' is not a member of 'boost::detail' c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::try_timed_lock(long int, const boost::system_time&)': c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:102:21: error: '_InterlockedExchange' is not a member of 'boost::detail' If asio.hpp is moved ahead of the thread headers, the error goes away. We've been trying to dictate #include order to work around this problem, but it keeps cropping up.

3 9

why boost is so slow for file search?
by young 13 Jun '12

13 Jun '12

I have 2 functions for read files list in one directory. One uses Win32 and one uses boost: void GetFilesWin32(std::string dir) { std::vector<std::string> vFiles; std::string f = dir + "*.*"; std::string file; WIN32_FIND_DATA findFileData; HANDLE h = FindFirstFile(f.c_str(), &findFileData); if(h != INVALID_HANDLE_VALUE) { do { if((findFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) != FILE_ATTRIBUTE_DIRECTORY) { file = findFileData.cFileName; vFiles.push_back( file); } } while( FindNextFile( h, &findFileData) != 0); } FindClose(h); } void GetFilesBoost(std::string dir) { namespace fs = boost::filesystem; std::vector<std::string> vFiles; fs::path path(dir); fs::directory_iterator end_dir; for(fs::directory_iterator it(path); it != end_dir; it++) { if(!(fs::is_directory(it->status()))) { vFiles.push_back(it->path().filename().string()); } } } Boost takes 1.00 ms while Win32 taks 0.15 ms for same directory. Why? -- View this message in context: http://boost.2283326.n4.nabble.com/why-boost-is-so-slow-for-file-search-tp4… Sent from the Boost - Users mailing list archive at Nabble.com.

6 7

[vector, PropertyGraph] Problem declaring a class member of the "vector<int>" type
by Alex Sadovsky 13 Jun '12

13 Jun '12

Hello everyone, > >I am trying to declare, in a header file, a class that has a member of type "vector<double>" (the code is included below). The compiler complains that I haven't included the appropriate namespace (the error message reads, "ISO C++ forbids declaration of ‘vector’ with no type"), and I understand that it is looking for this: > >using namespace boost::numeric::ublas; > >However, I tried putting it in the header file in various places (haven't programmed in C++ in 10 years and couldn't find any online documentation to clarify this specific situation), and still no luck. I am definitely doing something wrong, but cannot reason out the error, as it probably has to do with the specific syntax conventions. Any help is appreciated! > >Thanks, >-Al > >P.S. Code in header file: > >////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// >// File "airspace-graph-rectilinear-edges.h" >typedef char* string; >const int PHYSICAL_SPACE_DIMENSION = 2; >// Information needed about a waypoint used in an airspace: name and physical position >class WaypointConcept{ > private: > using namespace boost::numeric::ublas; > string waypoint_name; > vector<double> waypoint_position_xyh(PHYSICAL_SPACE_DIMENSION); > public: > string GetWaypointName(); > vector<double> GetWaypointPosition(); >} > >class AirspaceGraphConcept PropertyGraphConcept<class Graph, class WaypointConcept, class vertex_index_t>; >typedef Vertex* GraphPathType; >typedef string FlightIDType; >typedef boost::unordered_map<std::FlightIDType, GraphPathType> FlightIDToPathAssignmentType; >////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > >Code in the .cpp file (which includes the above header file) I am trying to compile: >////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// >#include <boost/lambda/lambda.hpp> >#include <iostream> >#include <iterator> >#include <algorithm> >#include <boost/numeric/ublas/io.hpp> >#include <boost/numeric/ublas/vector.hpp> >#include "airspace-graph-rectilinear-edges.h" > >int main() >{ > using namespace boost::numeric::ublas; > > vector<double> v(3); > for (unsigned i = 0; i < v.size(); ++ i) > v (i) = 2.01*double(i); > > std::cout << v << std::endl; >} >////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > > > > > > > > > > > > > > > >

3 7

[lockfree] minor bug/improvement
by Brian Budge 13 Jun '12

13 Jun '12

Hi all - I'm unsure of the status of the lockfree library. Where should I be posting bugs for that? Thanks, Brian

1 0