On Mon, Oct 27, 2014 at 10:02:22PM +0100, Soeren Apel wrote: > > Sure, no issue there. Did you ask because it's part of the > bindings and not the C API? My intention here was to be least > intrusive, though if you see a use case for the display name being > added to the C API, that certainly would be possible.
I'm afraid I don't like the approach in these patches and you've already hit on one reason why: it's adding something to the C++ bindings that isn't in the underlying C API. The other reason is that it's a hack for a particular use case which doesn't solve the broader issue: there is a general need for clients to associate their own data with a device instance or other object. If we're going to add such a facility to the API then we should do it properly: - implement it in the C API, not just in the bindings, and - allow for arbitrary data (e.g. a void *), so that the client can attach whatever data is needed, not just the string required in this current use case. I would question though whether this is the right approach. There are other ways for clients to accomplish the same thing, e.g. keeping a map/hash structure relating devices to client data, or using wrapper objects. I know Joel favoured the latter idea for PulseView, and if things are going to go in that direction then that would remove the need for this. Martin ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
