Skip to content
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

Open
tomq42 opened this issue Apr 14, 2016 · 6 comments
Open

No way to enumerate Options #854

tomq42 opened this issue Apr 14, 2016 · 6 comments
Milestone

Comments

@tomq42
Copy link

tomq42 commented Apr 14, 2016

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.

@tomq42
Copy link
Author

tomq42 commented Apr 14, 2016

I notice that GetNodeStatistics has, in effect, got an out parameter of list, and some std::strings.

I plan to add something like
GetOptionNames(list&)

@Fishwaldo
Copy link
Member

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.

@tomq42
Copy link
Author

tomq42 commented Apr 26, 2016

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*.

@gms1
Copy link

gms1 commented Jun 7, 2016

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
see:
https://support.microsoft.com/en-us/kb/168958
quote: Also note that some STL containers (map, set, queue, list, deque) cannot be exported.

@tomq42
Copy link
Author

tomq42 commented Jun 7, 2016

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.

@Fishwaldo Fishwaldo added this to the Version 1.6 milestone May 30, 2017
@Fishwaldo
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants