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

error: type/value mismatch at argument 1 in template parameter
by Lane 06 May '15

06 May '15

bounded_buffer is taken from the boost circular_buffer examples which wraps operations with lock acquisition and release (more type-safe). I've changed up the calls slightly for my app and the problem is, I am having difficulty compiling. I was hoping to make the calls like below w/o the need for a template function (as in the example) since I'm in the function where I'd like to make the calls. --- bounded_buffer<MyData> bb(200); Consumer<bounded_buffer> consumer(bb); Producer<bounded_buffer> producer(bb); boost::thread* c_thread = new boost::thread(consumer); boost::thread* p_thread = new boost::thread(producer); threads.add_thread(c_thread); threads.add_thread(p_thread); --- Here are the compile errors: error: type/value mismatch at argument 1 in template parameter list for 'template<class Buffer> class Consumer' error: expected a type, got 'bounded_buffer' The example code I'm using is, http://www.boost.org/doc/libs/1_55_0/libs/circular_buffer/example/circular_…

2 1

Can a mapped_file larger than 2GB be random seeked?
by Narcélio Filho 05 May '15

05 May '15

(I'm resending this because it seems that my other message got garbled.) I'm writting on random positions on a mapped file, but it seems that if I seek past 2GB, write something, then seek to a lower position, I got a segfault. Here is the code: #include <cassert> #include <iostream> #include <fstream> #include <boost/iostreams/stream.hpp> #include <boost/iostreams/device/mapped_file.hpp> using namespace std; using boost::iostreams::stream; using boost::iostreams::mapped_file; int main(int argc, char** argv) { const size_t GIGA = 1024l*1024l*1024l; const size_t FILESIZE = 2l * GIGA + 10000; ofstream block("file", ios::binary | ios::out); assert(block.good()); block.seekp(FILESIZE); block.write("", 1); block.close(); mapped_file mappedFile("file"); stream<mapped_file> file(mappedFile, ios::binary|ios::out); assert(mappedFile.is_open()); char buffer[10] = {0}; cout << 0 << endl; file.seekp(0); file.write(buffer, 1); cout << FILESIZE - 1 << endl; file.seekp(FILESIZE - 1); file.write(buffer, 1); cout << 1 * GIGA << endl; file.seekp(1 * GIGA); file.write(buffer, 1); return 0; } I'm compiling under Ubuntu 14.10 (amd64): $ g++ boost-mmap.cpp -lboost_iostreams $ ./a.out 0 2147493647 Segmentation fault (core dumped) Everything is 64-bits: $ file a.out a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=d39e3dc0c99e666631747e496bf798b92e4d4c71, not stripped I have the same issue compiling with Visual Studio and running under Windows 8 (amd64). What I'm doing wrong? -- []s, Narcélio.

3 4

boost thread + container.
by Andreas Hehn 05 May '15

05 May '15

Hello boost-users readers, I stumbled across some funny behavior of the headers of boost::thread and boost::container/boost::move for C++O3. I am unsure if this is a known shortcoming of those libraries or if it is a bug. I didn't find anything on the topic in the documentation so far. The problem is dependent on the include order of the two files: * boost/container/vector.hpp * boost/thread/thread.hpp The following code causes several compilation errors (boost-1.58.0/git, g++-4.9.2) related to the move emulation of boost::thread: #include <boost/container/vector.hpp> #include <boost/thread/thread.hpp> int main() { boost::container::vector<boost::thread> v; v.resize(10); return 0; } It prints several error messages starting with boost/container/detail/copy_move_algo.hpp:285:112: error: no matching function for call to ‘move(boost::thread&)’. The following error messages are also boost::move releated "failed" enable_ifs and so on. If I switch the order of the includes everything compiles just fine. Is there a requirement on the order of the includes that I overlooked or is this a bug? Best, Andreas

1 0

How to stage one sub libary in C++ boost
by J Ronald 05 May '15

05 May '15

1. I have been built one sub library as below successfully: b2 locale toolset=msvc address-model=64 link=static threading=multi runtime-link=shared variant=release 2. Then, I tried to run: b2 stage Unexpectedly, it'll build other sub libraries, instead of copy the built sub sub library to the stage directory as the document says. Is there any automatic way to get the final built result in one directory?

1 0

Efficiently pass data from thread to main
by Lane 05 May '15

05 May '15

Using boost, I start a thread from the main process as such. MyWorkThread newThread; newThread = boost::thread(newThread); And in the worker thread class (MyWorkThread), I have a read function which reads from a USB device as much data as it can deliver. This function can be called several hundred times a second. MyThread::read() } //... while () { MyData data; if (hasMore(dev, &data)) // lots of data here // need to get it back to the main thread } } } I'm trying to figure out how to efficiently get this data back to the main process to be placed in a buffer since it can be called so often. - Would making a callback to the main process be the way to go? If so, any pointers how using boost? - Or should I just have a global data buffer and store it directly?

2 1

[serialization] std::shared_ptr with Boost >= 1.53
by Rüdiger Berlich 04 May '15

04 May '15

Hi there, I need to support various versions of Boost, but am in the process of porting our entire code base to C++11. This involves replacing those constructs of Boost that are now in the standard with their C++11-counterparts. A prime example is std::shared_ptr. However, most of our code needs to be serializable. I know that serialization of std::shared_ptr is possible with Boost 1.58. But 1.53 (the oldest version I need to support) cannot serialize std::shared_ptr . Is there any reason not to include the 1.58-Version of #include <boost/serialization/shared_ptr.hpp> instead of the older version, if I detect a Boost-version < 1.58 ? Thanks and Best Regards, Beet

4 12

[Multiprecision] Get mantissa of a float
by Leonardo Yvens 04 May '15

04 May '15

Hello, I'm new to the Multiprecision library, and am trying to extract the mantissa from a float. Using cpp_bin_float, it's easy to get the exponent, but how can I get the mantissa in a normalized form (1.xxxxxxxxxx)? I tried messing with the limbs, they contain large powers of two, but I couldn't interpret that. Thank you very much, Leo Y.

2 2

Can a mapped_file bigger than 2GB be random seeked?
by Narcélio Filho 04 May '15

04 May '15

Hello! I'm writting on random positions on a mapped file, but it seems that if I seek past 2GB, write something, then seek to a lower position, I got a segfault. Here is the code: #include <iostream> #include <fstream> #include <boost/iostreams/stream.hpp> #include <boost/iostreams/device/mapped_file.hpp> using namespace std; using boost::iostreams::stream; using boost::iostreams::mapped_file; int main(int argc, char** argv) { const size_t GIGA = 1024l*1024l*1024l; const size_t FILESIZE = 2l * GIGA + 10000; ofstream block("file", ios::binary | ios::out); assert(block.good()); block.seekp(FILESIZE); block.write("", 1); block.close(); mapped_file mappedFile("file"); stream<mapped_file> file(mappedFile, ios::binary | ios::out); assert(mappedFile.is_open()); char buffer[10] = {0}; cout << 0 << endl; file.seekp(0); file.write(buffer, 1); cout << FILESIZE - 1 << endl; file.seekp(FILESIZE - 1); file.write(buffer, 1); cout << 1 * GIGA << endl; file.seekp(1 * GIGA); file.write(buffer, 1); return 0; } I compile and run on Ubuntu 14.10/amd64: $ g++ example.cpp -lboost_iostreams 0 2147493647 Segmentation fault (core dumped) I also get the same error on Windows 8/amd64. What I'm doing wrong? []s, Narcélio.

1 0

[c++now] Perhaps of interest to Boost library users
by Niall Douglas 03 May '15

03 May '15

https://plus.google.com/+nialldouglas/posts/DsAdUV4RgY5 Content of post for convenience: Just finished my C++ Now 2015 presentation with exactly one week to go! Currently 90 slides for a 90 minute long presentation, I had originally been worried I'd be boring but I think, even if I do say so myself, that this will be one of the more interesting talks at C++ Now this year. It reviews *ten* C++ 11/14 only libraries close to entering Boost, three of which in detail (Boost.AFIO, Boost.Fiber, Boost.DI) and one in very great detail (Boost.APIBind), indeed I spend about 45 slides on APIBind as I believe it provides the foundation stone for a fully modular C++ 11 only Boost 2.0 branch with very significant improvements over Boost 1.0. I also draw some sweeping personal general opinions from the ten library review, and I'll try to answer these questions: * Why do these libraries require C++ 11 or 14? From an end user perspective. * Is there a common theme of the most popular C++ 11/14 features used? * Is there a common theme in choice of library design and use of third party libraries? * Are there techniques used in one library which would make a lot of sense to be used in another library, but for some reason are not? * Do these new libraries take notice of one another and integrate themselves well with other libraries, or are they ivory towers? * How many of these forthcoming libraries explicitly seek to contribute to future C++ standardization? Boost only a few years ago was in a state of sickly malaise after the exit of several big names who had dominated it since its inception. Indeed, in 2013 no new libraries had entered in two years, and nobody could say if Boost was going to be the venue for the next generation of C++ 11/14 libraries approaching standardisation or whether some other venue (especially WG21 itself) would take over. Since 2013 *seventeen* new libraries have either entered Boost or entered the formal review queue, almost a third of which are C++ 11/14 mandatory libraries, whilst WG21's efforts to invent new libraries have not panned out well to date. Traffic on the Boost mailing lists which had become anaemic has once again returned to mass-delete-without-reading levels. It looks like Boost is going to remain the place to be for the highest quality C++ libraries, especially those intended for eventual standardisation. The big question is whether the C++ 11/14 mandatory libraries are so different from the 98/03 libraries in design and philosophy that a C++ 11/14 only Boost 2.0 distribution is warranted? Robert Ramey will be presenting on his vision for Boost 2.0 at C++ Now 2015, and he kindly has allowed me to add my ha'pennies worth after he finishes during which I will summarise my empirical findings from the ten library review. So watch out for the recorded videos! -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

[BGL] I think the invariant in ResourceExtensionFunction for r_c_shortest_paths is not correct
by Alberto Maria Santini 02 May '15

02 May '15

The documentation for 1.58.0 (http://www.boost.org/doc/libs/1_58_0/libs/graph/doc/r_c_shortest_paths.html) correctly states that: >>> The implementation is a label-setting algorithm. This means that there must be one or more resources whose cumulated consumption(s) after extension is/are always at least as high as before. This is similar to the Dijkstra algorithm for the SPP without resource constraints where the distance measure must be non-negative. It is sufficient if there is one resource with a non-negative resource consumption along all arcs (for example, non-negative arc lengths or non-negative arc traversal times). >>> But, later on, it says: >>> If ref models the ResourceExtensionFunction concept, and if the type Resource_Container models the ResourceContainer concept, after the call ref( const Graph& g, Resource_Container& new_cont, const Resource_Container& old_cont, graph_traits<Graph>::edge_descriptor ) the expression old_cont <= new_cont evaluates to true. This is because, as stated above, the implementation is a label-setting algorithm. Therefore, the Less-Than operator for ResourceContainer must compare one or more resource(s) whose resource consumption(s) along any arc is/are non-decreasing in order for the algorithm to work properly. >>> Now, saying that "old_cont <= new_cont" is much stricter than it should be. The correct requirement (first quote) is that there is **at least one** resource whose consumption monotonically doesn’t decrease. What "old_cont <= new_cont” requires, is that **all** resources’ consumptions are monotonically non-decreasing. These two things are equivalent iff the label only has one resource. Can someone confirm that my observation makes sense? In this case, I’ll open a ticket and submit a patch for the documentation. Can someone also confirm that this check is *not* enforced in r_c_shortest_paths.hpp? Thanks, AS

1 0