Code review comment for lp:~epics-core/epics-base/link-support-2
Revision history for this message
| Andrew Johnson (anj) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
> Given that this isn't certain
It is certain for the input links of all the built-in record types. I think you would also be justified in printing a warning message if a subsequent getValue() disagrees with the data type or requests a larger size than the initial load*() request.
> A caller could first use dbGetLinkDBFtype()
They could, but the existing code doesn't, it relies on dbCa to handle all the data type stuff. That routine is also going to return -1 until the link gets connected, whereas if you use the hints the link would be able to subscribe sooner and so start delivering real data sooner.
> The cost of looking up a conversion function each time has never seemed like much.
It's not the cost of looking up the conversion function, but the data type and size you subscribe for that I was thinking about. If the link is an ai record asking for the first element from a waveform record and you always subscribe for the target's array size…
> A unit test would help...
Yeah, luckily there's a long wekend coming up and my wife will be away for most of it. I do have a hard deadline on some other EPICS stuff coming up, but I'll work on adding that.