- Boost-users - lists.boost.org

ProgramOptions: explicit empty string argument
by Akim Demaille 30 Jan '15

30 Jan '15

Hi, I would like to be able to support an empty optional argument for long options. This is something that is supported by gnu getopt_long and argp. Consider for instance a simplified version of the first simple example program: #include <iostream> #include <boost/program_options.hpp> int main(int ac, char* av[]) { namespace po = boost::program_options; using namespace std; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("compression", po::value<string>()->implicit_value(""), "set compression level") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); if (vm.count("help")) cout << desc << "\n"; else if (vm.count("compression")) cout << "Compression level was set to " << vm["compression"].as<string>() << ".\n"; else cout << "Compression level was not set.\n"; } when I run it, in "typical cases", I have: $ ./a.out Compression level was not set. $ ./a.out --compression=foo Compression level was set to foo. $ ./a.out --compression foo Compression level was set to foo. $ ./a.out --compression Compression level was set to . all of this is fine. However, how can I explicitly pass the empty string? $ ./a.out --compression= libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::invalid_command_line_syntax> >: the argument for option '--compression' should follow immediately after the equal sign zsh: abort ./a.out --compression= Of course I could simply to my user that there is a special token, say '-', that means "empty", but it is still more complex than simply accepting the empty string to mean the empty string. Thanks! (There are some stack overflow questions, but they do not address this particular point, --foo='').

1 0

[interprocess] Bizarro File Names (Windows)
by Aaron_Wright＠selinc.com 29 Jan '15

29 Jan '15

I have a service that is running in Windows Server 2008 R2 SP1 that uses shared memory. It runs fine for a month or so, but then stops working correctly. When I check the C:\ProgramData\boost_interprocess\*\ folder, I get a bunch of weird file names, such as: 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EBFFFFFF 88C861CD6DE2CF01EBA2F0CC1200D001A4070000ECFFFFFF 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EDFFFFFF 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EEFFFFFF 88C861CD6DE2CF01EBA2F0CC1200D001A4070000EFFFFFFF 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F0FFFFFF 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F1FFFFFF 88C861CD6DE2CF01EBA2F0CC1200D001A4070000F2FFFFFF 88C861CD6DE2CF014B04F3CC1200D001A40700000AFFFFFF 88C861CD6DE2CF014B04F3CC1200D001A40700000BFFFFFF 88C861CD6DE2CF014B04F3CC1200D001A40700000CFFFFFF 88C861CD6DE2CF014B04F3CC1200D001A40700000DFFFFFF ... (and so on) These are not even close to the names that are supposed to be used. They seem to increment a bit, then shift slightly, and start incrementing again. When I restart the service I get similar named files and patterns, and my services crashes because it can't grow shared memory (presumably because the file names are not correct). I have to restart the box in order to get the correct behavior. Has anyone seen this behavior before? --------------------------------------------------------- Aaron Wright

1 1

[mpl] lazy condition in enable_if
by Sam Fisher 29 Jan '15

29 Jan '15

Hi, I need to run boost::mpl::for_each<> function with template condition, like: boost::mpl::for_each< vector_of_types, boost::mpl::make_identity<boost::mpl::_1> > (Functor< condition >()); I'm trying to implement lazy binding in enable_if. Visual studio fails with error "'X<IsFoo<boost::mpl::_>>::operator ()' : ambiguous call to overloaded function" minimal test code which fail on boost 1.57 #include <boost/mpl/for_each.hpp> #include <boost/mpl/lambda.hpp> #include <boost/mpl/bind.hpp> #include <boost/mpl/vector.hpp> #include <boost/core/enable_if.hpp> #include <iostream> #include <type_traits> template <int> struct dummy { dummy(int) {} }; // from doc struct Foo {}; struct Bar {}; template <typename T> struct IsFoo { typedef typename std::is_same<T, Foo>::type type; }; #define generate_type(_fn) \ typename boost::mpl::apply<boost::mpl::bind< \ boost::mpl::lambda< _fn <boost::mpl::_> >::type, \ boost::mpl::bind<typename boost::mpl::lambda<_Pred>::type, U> \ > >::type #define enable_type generate_type(boost::enable_if) #define disable_type generate_type(boost::disable_if) template <typename _Pred> struct X { template <typename U> enable_type operator()(boost::mpl::identity<U>, dummy<0> = 0) const { std::cout << "enable: " << typeid(U).name() << std::endl; } template <typename U> disable_type operator()(boost::mpl::identity<U>, dummy<1> = 0) const { std::cout << "disable: " << typeid(U).name() << std::endl; } }; int main() { X<IsFoo<boost::mpl::_> > x; x(boost::mpl::identity<Foo>()); x(boost::mpl::identity<Bar>()); return 0; }

1 0

[release] Release schedule changes..
by Rene Rivera 28 Jan '15

28 Jan '15

After some discussion in the Boost Release Team we've decided on an ongoing schedule for releases. Taking into account the realities of how long it takes for authors and the release team to work on a release we've decided to move to *three* releases a year. The targets for the releases will now be: * Spring release on the second Wednesday of April. * Summer release on the second Wednesday of August. * Fall/Winter release on the second Wednesday of December. There will be no January release. This will allow for the fact that most people are on extended holidays during Winter. It will also allow for people to work on larger changes that require more testing time during the longer Winter period. We are also moving to Wednesday release to allow the release managers non-weekend time to work before and after the release. Please consult the Boost calendar for specific dates and merge schedule for the next release. Thanks, the Boost Release Team. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[multi state machine/ MSM] execute_queued_events
by Steve Hickman 27 Jan '15

27 Jan '15

In the MSM doc section "Enqueueing events for later processing", you state that "Calling execute_queued_events() will then process all enqueued events (in FIFO order)." You also said in a previous post that MSM is not thread safe, thus requiring an external mechanism to insure thread safety. I don't see a mechanism to execute a single event at a time, which would be preferable if I have to lock the queue while processing events. Having said that, a cursory examination of the "execute_queued_events" code makes me think it only processes one event per call. Which is correct? Is the documentation correct that it actually processes all queued events? If not, can the documentation be corrected? If so, is there a publicly usable call to process a single queued event? If there is no publicly available call for processing a single queued event, how do you recommend processing queued events in a thread safe manner that won't lock the queue for extended periods of time?

4 7

[multi_index] recursive declaration of MIC with a value which contains references of its kind
by Nick Stokes 27 Jan '15

27 Jan '15

I have a value type (Foo) which is supposed to contain references to some multi_index_container of its type, like so: struct Foo { int property1; int property2; FooMIC* other; // this (the pointer value) may or may not be indexed upon }; typedef multi_index_container< Foo, indexed_by < sequenced<> , ordered_unique< member<Foo, int, &Foo::property1> > , ... >> FooMIC; Due to recursive nature of this, I wasn't able to figure out how do declare such a thing (other than unsafely using void* references in Foo). Any ideas? Thanks many, Nick

2 2

Re: [Boost-users] [boost] [Review] Boost.Endian mini-review
by Beman Dawes 27 Jan '15

27 Jan '15

On Sun, Jan 25, 2015 at 6:12 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Sun, Jan 25, 2015 at 8:21 AM, Beman Dawes <bdawes(a)acm.org> wrote: > >> On Sat, Jan 24, 2015 at 2:25 AM, Jason Newton <nevion(a)gmail.com> wrote: >> > I think the only thing that I have no interest in using - a kind way of >> > saying its probably unneeded bloat IMO is the arithmetic types. I prefer >> > native types and using conversion functions. But maybe they could >> improve >> > my code - its something I toss back and forth a little and haven't >> > attempted embracing. >> >> Because even the endian buffer and arithmetic types that appear most >> expensive generate only short sequences of code, the optimizing >> compilers often generate exactly the same instructions regardless of >> endian approach. On Intel machines, that often distills down to a >> single bswap instruction since the value is already in a register. >> >> That isn't always true, so you do need to measure performance of >> various approaches in the context of your actual application. But if >> use of the buffer or arithmetic types would otherwise improve your >> code, please don't reject them without actually testing performance >> first. >> > > Allow me to clarify: I meant code bloat, not speed. Sorry - your original post was clear, but I misinterpreted. I have not systematically measured code bloat. Maybe I can do that at least for some common use cases. Thanks, --Beman

1 0

Re: [Boost-users] [boost] [Review] Boost.Endian mini-review
by Beman Dawes 26 Jan '15

26 Jan '15

On Sat, Jan 24, 2015 at 2:25 AM, Jason Newton <nevion(a)gmail.com> wrote: ... > As a long time user of the Boost.Endian library (applying patches to the > distribution I maintain), I am happy to see it finally up for uh... > mini-review. Hoping to see it get to formal review and included... further > hoping it makes it into the next C++ standard! The library went through formal review in 2011, so will go into Boost as soon as the mini-review is over. And, yes, I do plan to propose it to the standards committee. > It is ready in my opinion. I've seen it go through some topical changes > over the years but the only thing I've used from it are the conversion > functions which have been great for implementing proper io in the range of > network socket io / serial with various protocols and stored data from > varies devices/sensors) if a specification enforces byte order. It > fullfills my needs and always did fairly well on performance with gcc/clang. Depending on what version you have been using, the performance may now be even better. > I think the only thing that I have no interest in using - a kind way of > saying its probably unneeded bloat IMO is the arithmetic types. I prefer > native types and using conversion functions. But maybe they could improve > my code - its something I toss back and forth a little and haven't > attempted embracing. Because even the endian buffer and arithmetic types that appear most expensive generate only short sequences of code, the optimizing compilers often generate exactly the same instructions regardless of endian approach. On Intel machines, that often distills down to a single bswap instruction since the value is already in a register. That isn't always true, so you do need to measure performance of various approaches in the context of your actual application. But if use of the buffer or arithmetic types would otherwise improve your code, please don't reject them without actually testing performance first. > > This library should not be looked at as fulfilling an uncommon need - and > should even be part of future C++ standards because the usual > macro/functions (e.g. htons) in the in arpa/inet.h are widely used outside > of inet related code (see above examples) and have the types encoded in the > name making them not easily usable/composable in contrast to something > template based which the library offers. Further IEEE 754 support - > especially for double floating point types. The library definitely fills > that gap and has for years IMO. Thanks for the kind words! --Beman

1 0

[thread] await hangs when using boost::promise/future
by TONGARI J 26 Jan '15

26 Jan '15

Hi, The sample code is here: https://gist.github.com/jamboree/3b8716ad1922749e77ae The boost::future adaption code is adapted from N4286. Tested with VS2015 preview. If std::promise is passed, the code works fine. Any clue why it hangs if boost::promise is passed? Thanks.

3 10

[Graph] source vertex colour at start of BFS or DFS
by Jeremy Murphy 24 Jan '15

24 Jan '15

Hi, I'm wondering, why do the BFS and DFS algorithms not inspect the colour of the source vertices given to them? If a source vertex is already black, shouldn't the search effectively be a no-op? Currently the source vertex is 'discovered' and coloured grey regardless of its previous colour. I know it might seem weird to pass a black vertex as the source, but I guess I see it as similar to passing an empty range to an algorithm: it's valid but nothing happens. Thanks, cheers. Jeremy

1 0