Search Results

Search found 3 results on 1 pages for 'kloffy'.

Page 1/1 | 1 

  • Boost.Program_options fixed number of tokens

    - by kloffy
    Boost.Program_options provides a facility to pass multiple tokens via command line arguments as follows: std::vector<int> nums; po::options_description desc("Allowed options"); desc.add_options() ("help", "Produce help message.") ("nums", po::value< std::vector<int> >(&nums)->multitoken(), "Numbers.") ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); However, what is the preferred way of accepting only a fixed number of arguments? The only solution I could come is to manually assign values: int nums[2]; po::options_description desc("Allowed options"); desc.add_options() ("help", "Produce help message.") ("nums", "Numbers.") ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); if (vm.count("nums")) { // Assign nums } This feels a bit clumsy. Is there a better solution?

    Read the article

  • How to handle value types when embedding IronPython in C#?

    - by kloffy
    There is a well known issue when it comes to using .NET value types in IronPython. This has recently caused me a headache when trying to use Python as an embedded scripting language in C#. The problem can be summed up as follows: Given a C# struct such as: struct Vector { public float x; public float y; } And a C# class such as: class Object { public Vector position; } The following will happen in IronPython: obj = Object() print obj.position.x # prints ‘0’ obj.position.x = 1 print obj.position.x # still prints ‘0’ As the article states, this means that value types are mostly immutable. However, this is a problem as I was planning on using a vector library that is implemented as seen above. Are there any workarounds for working with existing libraries that rely on value types? Modifying the library would be the very last resort, but I'd rather avoid that.

    Read the article

  • Containers of reference_wrappers (comparison operators required?)

    - by kloffy
    If you use stl containers together with reference_wrappers of POD types, the following code works just fine: int i = 3; std::vector< boost::reference_wrapper<int> > is; is.push_back(boost::ref(i)); std::cout << (std::find(is.begin(),is.end(),i)!=is.end()) << std::endl; However, if you use non-POD types such as (contrived example): struct Integer { int value; bool operator==(const Integer& rhs) const { return value==rhs.value; } bool operator!=(const Integer& rhs) const { return !(*this == rhs); } }; It doesn't suffice to declare those comparison operators, instead you have to declare: bool operator==(const boost::reference_wrapper<Integer>& lhs, const Integer& rhs) { return boost::unwrap_ref(lhs)==rhs; } And possibly also: bool operator==(const Integer& lhs, const boost::reference_wrapper<Integer>& rhs) { return lhs==boost::unwrap_ref(rhs); } In order to get the equivalent code to work: Integer j = { 0 }; std::vector< boost::reference_wrapper<Integer> > js; js.push_back(boost::ref(j)); std::cout << (std::find(js.begin(),js.end(),j)!=js.end()) << std::endl; Now, I'm wondering if this is really the way it's meant to be done, since it seems impractical. It just seems there should be a simpler solution, e.g. templates: template<class T> bool operator==(const boost::reference_wrapper<T>& lhs, const T& rhs) { return boost::unwrap_ref(lhs)==rhs; } template<class T> bool operator==(const T& lhs, const boost::reference_wrapper<T>& rhs) { return lhs==boost::unwrap_ref(rhs); } There's probably a good reason why reference_wrapper behaves the way it does (possibly to accomodate non-POD types without comparison operators?). Maybe there already is an elegant solution and I just haven't found it.

    Read the article

1