- Boost - lists.boost.org

[iterators] Missing typedefs in v1.57
by news.gmane.org 10 Dec '14

10 Dec '14

I posted this a week ago in the user mailing list but it went unnoticed. Perhaps this developers' list is a better place to post it. The typedefs for difference_type and reference used to be in scope for classes derived from iterator_facade. Since v1.57 they have to be declared thus: typedef typename iterator_facade_::difference_type difference_type; typedef typename iterator_facade_::reference reference; This seems out of place for a class that was designed to reduce boiler plate code. However, if the change was intentional, please document it. Thanks, Keith MacDonald

3 5

[documentation] Are SVG's in documentation viable now?
by John Maddock 10 Dec '14

10 Dec '14

Folks I need your opinions, Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable. So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue. Many thanks, John. PS, I'm aware of MathJax and similar solutions for equations - but these generate so many security warnings on IE when used in local docs (not on a server), that it's a non-starter for now. Besides, we have the SVG's already, and it's a one line change to make use of them ;-)

13 22

Re: [boost] [RPC] Compile-time reflection for RPC and mocking
by Brian Wood 09 Dec '14

09 Dec '14

Peter Bindels writes: > Based on Hartmut's speech last Saturday introducing HPX and explaining a > bit about async/future/promise I tried to implement a simple RPC mechanism > that uses then to decouple work and the result I have so far is very > promising. I have a simple interface with a call that returns a future, and > the caller does not distinguish between calling the actual object and > calling on a proxy, as both return a future<T>. It does what the discussion > mentions - serialize the name of the interface and function, as well as the > arguments (basically the mangled name of the interface function) to ensure > there are no mismatches. I tend to agree with Bjorn's post about messaging middleware. For some reason, thinking in terms of messages is easier for me. For example, rather than serializing the name of the interface and function, I include a message id, which is often one byte. -- Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net

2 1

[container] locking for compact map
by Vicente J. Botet Escriba 09 Dec '14

09 Dec '14

Hi, I'm locking for a map<std::size_t, T> implemented as array<optional<T>, N>. When the key is on the range 0..N-1 and the map is dense enough, the advantages are * the whole data is much more compact, avoiding allocations and deallocations, and should reduce the cash misses. * the access insertion/removal/get is direct O(k) instead of O(logN). The liabilities, are the same as array. * iterating is not O(k), but O(N) (When the number of elements is not too high or when there is no too much holes, this should not be a problem) * The move constructor is not noexcept. An implementation using vector<optional<T>> should avoid this last issue. You could ask your self why I don't use directly array<optional<T>> or vector<optional<T>>. The answer is that I don't want the user manage the holes. I'm aware of/flat_(multi)map/set/ associative containers. The difference here is that as the key is the position on the array which make things perform even better for this particular case. Is there something similar in Boost already that I'm missing? Do you see other liabilities I have missed? Best, Vicente

2 4

Boost People section largely outdated
by Joaquin M Lopez Munoz 09 Dec '14

09 Dec '14

Hi, It is a pity that the Boost People section: http://www.boost.org/users/people.html is so outdated: many people there are no longer around, and, more importantly, many (most) current contributors are not listed. This is is a reminder for people to get themselves on that page! Instructions at http://www.boost.org/development/submissions.html#People Best Joaquín M López Muñoz Telefónica

3 2

[asio] introspecting boost::asio::detail::epoll_reactor::run
by Isidor Zeuner 09 Dec '14

09 Dec '14

Hi all, I am investigating a livelock in a running process inside boost::asio::detail::epoll_reactor::run and I was wondering if someone was in this situation before and may have some tools (gdb scripts?) handy which can be used to get a list of currently pending tasks inside the epoll reactor. Thanks in advance! Best regards, Isidor

1 0

Re: [boost] Boost 1.57 hot-out-of-Git fails to compile for Windows Phone
by Moshe Rubin 09 Dec '14

09 Dec '14

A belated "thank you" to Juergen Hunold and Oliver Kowalke for their help in solving the problem. Indeed, when "address-model=32" was added to the command line it solved the problem and enabled me to build all the Windows Phone ARM libraries in one fell swoop. Thanks very much, Moshe

2 1

boost::filesystem changes since version 1.55.0
by Armin Pies 09 Dec '14

09 Dec '14

I have tried to upgrade our software from using boost 1.55.0 to 1.57.0. Now we're getting unexpected exceptions in our code using filesystem::recursive_directory_iterator. Checking http://www.boost.org/users/history/version_1_56_0.html or http://www.boost.org/users/history/version_1_57_0.html there are no changes concerning boost::filesystem. Is there somebody who can tell me what has been changed in boost::filesystem, versions 1.56 and 1.57, and what impact it has on existing code or what I have to adapt to fix our software? Regards, Armin Pies

4 5

Re: [boost] boost::filesystem changes since version 1.55.0
by Armin Pies 09 Dec '14

09 Dec '14

Obviously the operator++ of the recursive_directory_iterator throws exceptions now, which it did not before 1.56. I have changed our code using the increment(system::error_code& ec) method to ignore the unexpected exceptions. Regards, Armin

2 2

Is Boost.Asio ported for Windows Runtime?
by Moshe Rubin 09 Dec '14

09 Dec '14

Boost.Asio is a headers-only library which makes use of Boost's 'system' library. Since the 'system' library has been ported to Windows Runtime (aka WinRT) by Steven Gates of Microsoft, I assumed that Boost.Asio should therefore work as-is for WinRT. When I wrote to Steven asking him to verify that Boost.Asio will work today for WinRT he answered: <quote> "I don't know if Boost.Asio works with the Windows Runtime. I would guess it doesn't entirely, but since it is a header file only library it might work depending on the features used. My recommendation would be to run the Windows App Cert Kit and if you didn't pull in any banned APIs then you might be good. When I look in the history of the Boost.Asio Github repository I can see the maintainer at least started some work for the Windows Runtime. I recommend you reach out to him or post of the Boost mailing forums to see." </quote> Can the Boost.Asio maintainer, or anyone else, verify if Boost.Asio can be built as-is for WinRT, or does it need to be ported? Thanks in advance, Moshe Rubin

2 1