Modifing libhid?
Ok geeklings, I could use a little advice. I’m looking at using/modifing libhid: a small but not inconsequential library. One of the primary things this library does is parse the HID report, which is a small but not inconsequential language that describes human interface devices and their data. The problem: this parsing is rather crude right now, so that doing something that should be pretty simple (say, “what is the current state of this HID device”) is pretty hard in the general case. Worse, the library’s design is itself rather nasty – or at least, it’s not what I want, which is some nicely factored data structures & functions that describe all characteristics of the HID device in a Object-Oriented way that’s easy to query. Basically, I want a parse tree of the HID report.
So I could rewrite the C library, but generating this parse tree without the facilities of an OO language is going to be ugly (or maybe that’s just because I’m not familiar with C-style). At the very least, rolling my own C data structures (like lists, and perhaps maps) is gonna be an annoyance. Also problematic will be memory allocation/deallocation (this is where C++ constructors/destructors really come in handy). Also virtual functions will be missed for querying aggregate data on the parse tree once it’s built.
Possible solutions:
- Try to use the library as it is (perhaps with a few crude extensions) and then glom a fancy OO interface layer in something like ruby that hides the ugliness. Pros: easy Cons: might not be able to keep some of the ugliness from poking through, other users of the C are still screwed
- Rewrite the parsing in C++ using the STL. Pros: Not that hard. Also a nice clean C++ interface. Cons: This is currently a C library and I’m not sure if the maintainers would appreciate C++. Increased binary size with the STL. Increased difficultly iterfacing with other langauges using swig (but not impossible).
- Rewrite the parsing in the cleanest possible C. Possibly using a C data structure library that somebody could point me to. Pros: small binary size, good C interface. Cons: Possibly hard, especially if I have to use my own data structures. Not as clean as the C++ interface (especially if somebody like me, still thinking C++-style, writes it)
What would you do?
The added size of the main stl container types is not very much. On the order of about 10K or so per type.
I’d say write what you know, especially if it is a move forward. You can always export C functions to get a good C interface build on top of your C++ interface.
Sorry it took me so long to comment on this. When I first looked at libhid, I realized it would take me a short while to read enough of it to have an opinion about what you should do.
I think it’s possible that these guys want something different than you do: libhid is for “accessing and interacting with USB HID devices,” you just want a parse tree for the HID report.
No matter what, though, your wants and their wants should be able to share a parser. If you write an event-driven parser for a language, you can layer anything on top of it and get what you want. For example, you can always layer a DOM parser on top of a SAX one. The event-based interface for parsing is the most general and reusable.
So my opinion is: see if the interface to *just* their parser can give you what you need. That is, see if you can write a program that uses the parser from libhid to build up the nice object hierarchy you want. If you can, you’re done. If not, you have two options.
Option 1 is: see if their parser is salvagable — see if it can be made generic enough that you can write that program. If you’re feeling nice, you could even port the rest of their package to use the new, more general parser.
Option 2 is: ditch their parser, start from scratch, and build a generic, event-based parser. Then you can write your tree-building program. You could also tell the libhid guys that you have built a parser that they could use, and that is more generally useful than the parser they already have.