-
-
Notifications
You must be signed in to change notification settings - Fork 911
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No way to enumerate Options #854
Comments
I notice that GetNodeStatistics has, in effect, got an out parameter of list, and some std::strings. I plan to add something like |
I'd prefer to keep it at the simplest layer - ie, a uint8* as that would avoid any issues with Compilers if we go for ABI compatibilities later on Windows. |
Achieving ABI compatibility for a C++ interface is essentially impractical. You may as well just write a C interface, or a "CLASS" style C interface (http://rfc.zeromq.org/spec:21). You can't pass ownership of memory across the boundary. You can't use any std collections such as std::string as arguments or return values. Objects that are instantiated can't contain std::strings or any other such classes as members. You can't even use the primitive long data type in the interface (different size on MSVC 64 as on GCC 64). Not sure I understand how an interface would be structured to use a uint8*. |
there is already a private member "map<string,Option*> m_options" so you probably would only need a getter, but then it would be necessary to export the explicit template instantiation on windows |
I have a bunch of changes for this, I just haven't yet had time to put in a pull request. I will try and collect together my commits and put one in. |
We print out the options after Locking the options class now (to the Log File). I'll add a Iterator to this soon as well. |
I'd like to be able to list through the options in the Options object, but there's no method for doing that, I need to know what option I'm looking for (I want to dump out for debug purposes, and I'd rather do it directly, rather than reading the XML file in some way).
I'm quite happy to add this and send a pull request, if I can get an opinion on the preferred interface.
I notice for example, that to list scenes, the interface is to pass out a uint8* that must be freed, rather than, for example, to pass in a std::vector by reference that gets populated.
The simplest method of enumerating the options is to have a method that returns a std::vector(or set) of std::string, or passes one of those in to be populated, but I was worried that would not be idiomatic for this project. I don't see any particular reason to avoid that style (there are already classes that clients can construct instances of on the stack that contain STL objects, so client and openzwave already have to agree on compiler etc)
Thanks.
The text was updated successfully, but these errors were encountered: