On 6/8/26 6:29 PM, Robert Schöftner wrote:
Multiple implementations of access to hal shared memory are to be
avoided if possible, I would make some exceptions for C++ template code
if it is warranted (e.g. by making python bindings easier via pybind).
Multiple implementations of access to HAL shared memory are to be avoided.
To say it in Highlander mode: There can be only one.
Making exceptions is why we are in the trouble we are in. Halmodule
using pybind does not need any low-level access to shared memory. A C++
wrapper for other code doesn't need access to shared memory either.
Everything can be mapped using the C API (which does need some
adjustments from the current state, regardless).
We must keep the single API approach. That is the only way to guarantee
that you can change the underlying stuff in HAL-lib without breaking
code that uses the abstraction.
I would probably keep some sort of "type", even if the underlying bits
will eventually be double or whatever, just as a hint for the user and
GUIs. Also the difference between parameter and pin should be kept as
some sort of "metadata"
And that is exactly what is done today. No change of model needed. Just
update/modernize the implementation.
Another approach that would be possible in principle with accessors
would be to do conversion between types in the setter/getter functions.
That is exactly the idea. If you change the underlying model, then the
code does not need adjusting because the getter/setter code will capture
and adapt to the changes so your API is a constant.
The disadvantage would be that this could lead to surprising behaviour
and you can't explicitely decide if you want to truncate, saturate,
round or whatever to convert a value.
FWIW, the current code assumes truncation nearly everywhere. Otherwise
it codes around the problem (or crashes if the programmer didn't care to
take account for it).
Conversions are always a problem regardless which system you use. At
least with the getter/setter approach you provide a uniform API for the
programmer. All software (primarily interfacing hardware) is already
confronted with the problem. There is no one-answer here and it always
depends on what you are trying to achieve. Therefore, I cannot see any
disadvantage. Surprising behaviour is caused by code that does not know
its boundary conditions (i.e. programmer error). But remember, there is
a clear distinction between how this is handled internally (components)
verses externally (user interfacing).
--
Greetings Bertho
(disclaimers are disclaimed)
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
