Experimental Physics and Industrial Control System
On Thursday 16 June 2005 17:34, Marty Kraimer wrote:
> Benjamin Franksen wrote:
> >I am astonished that we have this kind of discussion again. I may be
> >mistaken but I had the impression that it was agreed upon to use DA
> > for IOC internal acess to records and to abandon the efforts Marty
> > started to define internal implementation of epics types until we
> > have got the interfaces right. And that dbd definitions should be
> > compiled into C/C++ code implementing DA interfaces, views, etc.pp.
> >
> >If indeed DA does not suffice as a (the) generic interface to record
> >fields, as Andrew suggested, then maybe DA should be extended or
> >revised accordingly?
>
> At some point something other than interfaces has to be created!!
> What Andrew and I are attempting is to define a small basic set of
> standard types including strings and arrays that have built-in
> support. For these types it should be easy to gererate code that
> implements dataAccess interfaces to access the data.
>
> Does anyone really want to have record support, device support, etc
> ALL access data only via dataAccess?
> That means everything will need to provide it's own set of code to
> use dataAccess. I am again haunted by Doug's request for "hello
> world".
My apologies, I didn't quite get the point here, obviously.
Of course, we need a /representation/ of the various kinds of data that
can be specified in a dbd file. And of course record support
should /not/ need to go through DA to access its own record data but
instead should access this data in the most direct manner possible.
I always imagined the data representation to be as low-level and
immediate as possible. I see no need to make access to it generic in
any way, other than providing the DA interface.
For instance, a dbd-struct is translated as a C struct. No more, no
less. No need for introspection, since the record support (or struct
support, if there is one) includes the header file and is anyway
specialized to this one record type only. Everything else is taken care
of by the generated implementation of the DA interface which, I repeat,
will typically not be used by record support. After reading teh
epicsTypes document, I think we agree here.
Regarding enums: Have I mentioned that enums are just a special case of
tagged unions? <grin> Anyway, these can be represented as a C struct
containing tag (integer) and optionally a C union containing additional
data. For plain enums the C union is left out, thus there are no other
fields beside the tag in this struct. I really don't see the point in
carrying a pointer to the table of string representations (plus a
pointer to the virtual function table) along with each copy of the
index value, as is done in class EpicsEnum. Why not simply /generate/
overloaded C++ inline functions for each enum type that handle the
string-to-index (and vice versa) conversion, using the array of strings
specified as a property to the enum field? I take it the
string-array /itself/ (though not its data) is a statically known
entity and its address can thus be hard-coded into these generated
routines. And since now each enum field has its own type (because it is
always wrapped inside a struct) we can use C++ overloading to
statically dispatch on the type at compile time. And BTW, please let us
use plain int for the index and /not/ epicsUInt16 or the like. A size
locked type is /not/ necessary here, and saving the two bytes is
ridiculous if one is OTOH willing to carry alltogether *two* pointers
along with each enum value, both of which are absolutely unnecessary
with the approach I sketched above. And also BTW, having a separate
type for each of these enum fields is Good Thing, since mixing
different enum indexes in an expression is most probably an error.
(Multidimensional) arrays and strings are an alltogether different
matter. The reason is that they require dynamic memory management;
arrays and strings have no fixed size. I agree that there is a need to
provide ADTs for these, and it probably makes sense to provide an
abstract framework to capture the commonalities.
Morale: The key points to make low-level access to record fields type
safe, convenient and still as efficient as possible are:
* C++'s ability to dispatch on types at compile time (overloading)
* C++'s inline functions
* a decision to generate from dbd definitions not only data layout but
also a number of (low-level) access routines exploiting the above
features
Cheers,
Ben
- References:
- RE: Fundamental Types document Jeff Hill
- Re: Fundamental Types document Benjamin Franksen
- Re: Fundamental Types document Marty Kraimer
- Navigate by Date:
- Prev:
Re: Fundamental Types document / unsigned integers Eric Norum
- Next:
RE: Fundamental Types / Gateway Jeff Hill
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Fundamental Types document / unsigned integers Jeff Hill
- Next:
V4 Data Types: Request for tagged unions Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024