Experimental Physics and
| |||||||||||||||
|
Here's my dreigroschen: I find exposing internal C structures to the client a very brittle API that calls for trouble. How will you be organizing the necessary locking? How will you make sure the client does not completely screw up your structure by writing out-of-bounds of arrays/strings? IMHO the better interface would be a functional one. Define a few setters and getters (can be taking the parameter name as an argument), and you'll be type-safe, can add sanity checks to values you get from the client, all locking is internal and in the scope of your library, and you are free to change your parameter structure as needed at any time. Such a functional API can easily be interfaced using standard device support (one jump table per record type you want to support) or through ASYN's C++ driver class (one set of methods for each data type you need to get/set). Cheers, ~Ralph On Mon, Oct 9, 2017 at 3:49 PM, Arnold, Ned D. <[email protected]> wrote:
| ||||||||||||||
ANJ, 21 Dec 2017 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |