Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Thu, 25 May 2000 13:18:56 -0600

> 
> Adding entries to the device support table is IMHO impractical now -
> different record types and device support types have already extended it
> for their own purposes.  There is no central declaration of what a struct
> DSET looks like - at least not one that is used universally.  Most device
> support layers declare the struct DSET contents for themselves, which
> means the compiler is unable to check whether you've remembered to change
> it.  

All records use the same RSET, and all devices for a
particular type of record use the same DSET. 
There is a number stored in the RSET/DSET that tells us if
the implementation is old, and therefore does not supply a new entry
at the end of the RSET or DSET.

I agree that the RSET/DSET inteface does not take advantage of compile
time error detection. And I also agree that a downside of extending the 
system this way is the potential for errors in dbCommon and in record support
that will not be detected by the compiler. However, if the device support
has correctly set the number of entries in the DSET then at least there will
minimal possibility of this sort of problem showing up in device support.

I am,  however, in favor of an expansion path which allows a modern type safe
C++ based record and device support interface to be used in parallel with 
existing devices and records based on the existing RSET/DSET, and I will
agree that an expansion path might be the best way to add new features to the
system.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System