January 2013 - Boost-users - lists.boost.org

Boost.Process and STARTUPINFOEX
by Nelson Teixeira 23 Jan '13

23 Jan '13

Hello, First, if this is not the correct place to ask, please point me an appropriate forum/maillist about Boost.Process as I couldn't find any in their site. Thanks. I'm trying to use Boost.Process library in windows XP. I installed Boost libraries version 1.52, and used Boost.Process from this page: http://www.highscore.de/boost/process0.5/index.html however, when I made the includes in my test program, I get this error: C:\boost/boost/process/windows/executor.hpp:120:5: error: 'STARTUPINFOEX' does not name a type C:\boost/boost/process/windows/executor.hpp: In constructor 'boost::process::windows::executor::executor()': C:\boost/boost/process/windows/executor.hpp:24:24: error: 'EXTENDED_STARTUPINFO_PRESENT' was not declared in this scope C:\boost/boost/process/windows/executor.hpp:30:23: error: 'startup_info_ex' was not declared in this scope C:\boost/boost/process/windows/executor.hpp:34:9: error: 'STARTUPINFOEX' was not declared in this scope I can't find this STARTUPINFOEX. At most I have STARTUPINFO structure. Do I have to install anything else ? Can anyone help please ?/ Thanks -Nelson ------------------------------------------------- Blog: Além do Óbvio http://www.alemdoobvio.com

4 3

intrusive_ptr vs shared-ptr
by ilya shlyakhter 23 Jan '13

23 Jan '13

Dear Boosters, The documentation of intrusive_ptr says "As a general rule, if it isn't obvious whether intrusive_ptr better fits your needs than shared_ptr, try a shared_ptr-based design first." but does not explain why. If the classes involved are all my own and deriving them all from a base class that implements reference-counting is not a problem, what are some reasons to prefer shared_ptr to intrusive_ptr? Thanks, Ilya

5 8

Range library suggestion
by John M. Dlugosz 23 Jan '13

23 Jan '13

I just added my second metafunction of the form is_range_of_X<T> for use with enable_if, and although the first one took some fiddleing to pass both compilers I was using, the second was a clone of the first with the name and type changed. So it really ought to be a general purpose is_range_of<Whatever, T> metafunction. I would suggest that such a thing be added to the Range library. It is meant for overloaded forms that operate on ranges, and you don't want to accept just any ol' thing because, perhaps, you want other overloads or to get better error messages for bad arguments. A typical example would be something like: void insert (const C& x); template <typename R> typename enable_if<typename is_range_of<C,R>::type, void>::type insert (const R& range) { ⋯ } In my case, I check whether R is indeed a Range (something that appears at first to be missing from the library too, but has_range_iterator is probably what is really meant by that) and the underlying element is convertible to the desired type. In a general-purpose library you might need to put more thought into what tests are so common as to be worth reusing at that level. I think having convertable-to-C (where you just give C) and another one which lets you pass in another metafunction for matching the element would allow reuse of experly written common code that takes care of nuances across compilers, e.g. choking on value_type if the outer is NOT a range, so you need to ensure short-circuit evaluation of the meta-expression. —John

2 1

[mpl] Suggestion on handle protocol messages
by Daniele Barzotti 23 Jan '13

23 Jan '13

Dear, I need to handle a protocol defined with Protocol Buffers. My messages are defined as: enum EMessages { E_MSG_METHOD_CONNECT = 0x8001, E_MSG_EVENT_CONNECT = 0xA001, ... } struct MsgHeader { long sessionRef; long transactionId; long status; } struct MSG_METHOD_CONNECT { Messages opCode; MsgHeader header; .. other fields .. } Now, I defined an interface and a template class to add a level of indirection.. class IMessage { virtual INT getOpCode() = 0; virtual STRING getName() = 0; virtual size_t getSize() = 0; .... } template<class MESSAGE> class IMessageImpl : public IMessage { protected: MESSAGE m_Message; ///< The Message Implementation public: virtual MESSAGE& getMessage() = 0; }; Where I'll use IMessageImpl<MSG_METHOD_CONNECT> MsgConnect; Now, the problem in this situation is to build the correct message class on the receiving part, knowing only the Message opCode. I would like to manage the messages with a type list or map, but I'm a newbie in MPL... Is there a way to define something like this: boost::mpl::map<int, MESSAGE> where the key is the Message opCode and the MESSAGE is the message type? The idea was born reading this article: http://blog.florindinu.ro/posts/message-dispatching-in-c-part-1-type-lists.… Thanks in advance, Daniele.

1 0

Boost and OMPL : access graph vertex
by Dan 23 Jan '13

23 Jan '13

Hello, I'm using OMPL (the Open Motion Planning Library) that makes use of Boost. The problem I've got is that I need to access the content of the vertexes of a graph which is returned by an OMPL function. In particular, the OMPL function is const Graph& g = planner->as<ompl::geometric::PRM>()->getRoadmap(); Now, given the graph g, and a vertex v, I need to read the state contained in g[v] and copy it to an OMPL variable. I'd need something like const ompl::base::State* state = FUNCTION_GET_STATE(g,v) ; This way I would be able to extract from variable state the components x,y,z I'm interested in. Is there any way to implement the FUNCTION_GET_STATE ? Thank you! Dan -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-and-OMPL-access-graph-vertex-tp464… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

Re: [Boost-users] boost::bind/boost::function and fast, delegates
by John M. Dlugosz 23 Jan '13

23 Jan '13

On 1/22/2013 4:34 AM, boost-users-request-at-lists.boost.org |Boost/Allow to home| wrote: > And if you still wish to write such a lib(s) take a look at this article: > > http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-F… Coincedentely, that article references my project that I cited on another thread (shared pointers): > For Microsoft's (and Intel's) ugly, non-standard 12 byte |virtual_inheritance| pointers, > yet another trick is used, based on an idea invented by John Dlugosz. To pass bound member functions to legacy code (including OS API) that expects a genuine function pointer, I generated a thunk at run-time and used a compiler trick to get the information I needed regarding the 'this' adjustment. It is certainly the _fastest_ possible; but I did not elaborate on a full "bind" feature like Boost (and std) eventually came up with. In fact, I simplified my own code so that all the arguments to pass were just members of one structure, so I only worried about the case of binding to a member function with one argument. It didn't automatically capture smart-pointer objects for the binding, but I handled that separately since it was already being done for "windows" owned by the OS's reference to raw pointers; I had my own fake +1 count as part of the object, and Window objects were my primary interest. As I recall, the C++11 lambda spec provides for a primitive C function pointer to be coughed up, but I've not yet used a compiler that can do that.

1 0

Re: [Boost-users] intrusive_ptr vs shared-ptr
by John M. Dlugosz 23 Jan '13

23 Jan '13

> Well I wouldnt say these items are 'marginal', because most come from real life > scenarios. You can work around things but it is always that u have to remember that > there were some boundary cases with shared_ptr. It took me some time to convince my > colleagues to swap from raw pointers to shared pointers and having some boundary cases > doesn't help then. I still prefer shared pointers, but I am not sure if all in all they > would be better than e.g. intrusive_ptr's with ref counting (even without lacking the > weak_ptr feature). Note that i look upon this from a client perspective (i.e. large data > acquisition application), not from a library builder perspective. I really miss having a "lost and found" feature, which (in the late 90's) I wrote about as being one of the six essential features of my smart pointer design. That is, given a raw pointer p that is already known to the smart pointer system, creating another smart pointer from p will work in harmony with them, NOT break it. I've repeatedly come across code that hooks up objects with other objects in the constructor and I've had to work-around that in various ways, usually by adding a Create wrapper that finishes the work, and sometimes fiddling more than I would have wanted to with the design. I've also found cases where it is really annoying not knowing whether another smart pointer has already been created yet for the object. Anyway, for intrusive smart pointers, the "lost and found" feature is very easy and efficient to implement. So perhaps it should be part of Boost intrusive_ptr as an extension to the standard, or another class can be added with a different feature set. Anyway, if you want a class like that, feel free to grab my old code from the "Classics" or "Repertoire" project parked on github. —John

3 2

[Program Options] terminate parsing after first positional argument
by Stuart Pook 22 Jan '13

22 Jan '13

Hello, How can I tell Boost Program Options to stop parsing the arguments as soon as it finds a positional argument? I'd like to be able to parse the argument list "-v chmod -R -v 600 foo" as having one argument for my program (-v) and the rest as a std::vector of std::string (including the -v). In the attached program I have tried 2 different approaches. The first uses multitoken with the arguments "--command date -u -v", it fails because "-u" isn't known. The second uses collect_unrecognized with "chmod -R -v 600", it doesn't work because -v is interpreted by boost and doesn't end up in the vector. As someone said back in 2005, perhaps I'm trying to write xargs: http://thread.gmane.org/gmane.comp.lib.boost.user/9529/focus=9641 I know that I can ask my users to write a.out -v -- chmod -R -v 600 foo but I don't want to do that. I want them to write "a.out -v chmod -R -v 600 foo". The first positional argument should should tell boost to stop processing. Another slightly different question. If I have a multitoken option that takes doubles how can I get it to accept negative values? If I give my program "--floats 1 8 -4 6" where --floats starts a multitoken option that accepts double, I get an exception saying that "-4" is an unknown option. thanks Stuart This is what my test program gives me with boost 1.50: argv: dd --command date -u -v unrecognised option '-u' Allowed options: -v [ --verbose ] verbose --command arg command to run 2nd try argv: dd chmod -R -v 600 I'm verbose v: chmod -R 600 3rd try argv: dd --floats 1 8 -4 6 unrecognised option '-4' Allowed options: -v [ --verbose ] verbose -f [ --floats ] arg numbers and my program (formatted to fit in 80 characters) #include <boost/program_options.hpp> #include <boost/range/algorithm.hpp> #include <boost/program_options/parsers.hpp> #include <boost/program_options/options_description.hpp> #include <iostream> namespace po = boost::program_options; #define nelements(a) (sizeof (a) / sizeof (a)[0]) void print(char const * * b, char const * * e) { std::cout << "argv: "; std::copy(b, e, std::ostream_iterator<char const *>(std::cout, " ")); std::cout << std::endl; } int main(int argc, char ** argv) { { bool verbose; std::vector<std::string> command; po::options_description desc("Allowed options"); desc.add_options() ("verbose,v", po::bool_switch(&verbose)->default_value(false), "verbose") ("command", po::value<std::vector<std::string> >(&command) ->multitoken(), "command to run") ; char const * args[] = { "dd", "--command", "date", "-u", "-v", 0 }; print(args, args + nelements(args) - 1); po::variables_map vm; try { po::store(po::command_line_parser(nelements(args) - 1, args) .options(desc).run(), vm); po::notify(vm); if (verbose) std::cout << "I'm verbose\n"; std::cout << "command: "; boost::copy(command, std::ostream_iterator<std::string>(std::cout, " ")); std::cout << std::endl; } catch (boost::program_options::unknown_option & x) { std::cerr << x.what() << "\n" << desc << "\n"; } } std::cout << "2nd try\n"; { bool verbose; po::options_description desc("Allowed options"); desc.add_options() ("verbose,v", po::bool_switch(&verbose)->default_value(false), "verbose") ; char const * args[] = { "dd", "chmod", "-R", "-v", "600", 0 }; print(args, args + nelements(args) - 1); po::variables_map vm; po::parsed_options parsed = po::command_line_parser(nelements(args) - 1, args). options(desc).allow_unregistered().run(); try { po::store(parsed, vm); } catch (boost::program_options::unknown_option & x) { std::cerr << x.what() << "\n" << desc << "\n"; exit(2); } po::notify(vm); if (verbose) std::cout << "I'm verbose\n"; std::cout << "v: "; std::vector<std::string> v = po::collect_unrecognized( parsed.options, po::include_positional); boost::copy(v, std::ostream_iterator<std::string>(std::cout, " ")); std::cout << std::endl; } std::cout << "3rd try\n"; { bool verbose; std::vector<double> f; po::options_description all("Allowed options"); all.add_options() ("verbose,v", po::bool_switch(&verbose)->default_value(false), "verbose") ("floats,f", po::value<std::vector<double> >(&f)->multitoken(), "numbers") ; char const * args[] = { "dd", "--floats", "1", "8", "-4", "6", 0 }; print(args, args + nelements(args) - 1); po::variables_map vm; try { po::store(po::command_line_parser(nelements(args) - 1, args) .options(all).run(), vm); po::notify(vm); if (verbose) std::cout << "I'm verbose\n"; std::cout << "floats: "; boost::copy(f, std::ostream_iterator<double>(std::cout, " ")); std::cout << std::endl; } catch (boost::program_options::unknown_option & x) { std::cerr << x.what() << "\n" << all << "\n"; } } }

6 16

boost::program_options - undocumented "*" feature
by ST 21 Jan '13

21 Jan '13

I recently discovered an undocumented feature of `boost::program_options`, namely that it accepts "*" as a special wildcard that allows declaration of a group of options with the same prefix, like this: configOptions.add_options() ("item_*", value<int>(), "items"); This declaration worked as expected and recognized `item_1`, `item_3`, etc, while rejecting unknown options. Well now the question is, how can I write a custom validate function that will populate a map with options key and its value, like this: map<string, int> itemsMap; options_description items("items options"); items.add_options() ("item_*",value<map<string, int>>(&itemsMap)->multitoken(), "items") ; My question is - how do I get the key of the option being validated from within validate() function? template <typename T> void validate(boost::any& v, const std::vector<std::string>& values, map<string, T> *, int) Thank you, Simone

1 0

Support for windows NTLM Authentication Protocol
by Gheorghe Marinca 21 Jan '13

21 Jan '13

Hi, I use asio and need to connect to a proxy server that might require NTLM Authentication Protocol. Is there a way to use this using boost ? Thanks, -Ghita

1 0