Experimental Physics and Industrial Control System
>
> In the tutorial "dataViewer" is used in several places. I think
> you mean propertyViewer.
That pure virtual base is currently called "dataViewer", but I
agree that "propertyViewer" is probably a better name matching
well with what the intended use is. Ditto for dataManipulator =>
propertyManipulator.
I suppose one could go further with this approach to naming. One
could change the name of the library to "property access". I will
need to think about that. The name dataAccess was originally
Ralph's so it will be necessary to hear his thoughts.
>
> I can see how almost everything in the da*.h files could be
> described in Java (unsigned is one exception).
This will be a problem only when properties cross over a Java
versus C/C++ boundary. In that situation the support libraries
will need to return an error when conversion is out of range for
the primitive types on either side of the fence.
> Everyplace where dataAccess uses multiple inheritance,
> the classes are equivalent to Java interfaces.
Multiple inheritance occur in only one of the interface classes -
in pure virtual base class (PVB) daString. The daString interface
publicly inherits from PVB classes streamPosition, streamWrite,
and streamRead.
I did this because I wanted users to pass only one argument when
passing a string. I am definately open to alternatives. Perhaps a
very simple handle class that maintains internally private
references to daString, streamPosition, streamWrite, and
streamRead. To avoid overhead, there could be a complete set of
inline functions in this handle class for the member functions in
each of the interfaces.
Your alternative suggestions are enthusiastically solicited.
> If we go with the V4 DBD idea of struct and array,
> utilities like dbToStructH,etc, could generate a
> header file AND code that uses dataAccess to get/put the struct
> fields.
This occurred to me also, and this might work, but many details
still need to be considered.
Jeff
> In fact it looks easy to create an equivalent set of Java
classes
> and
> interfaces for what appears in da*.h. Of course, this is not
> the
> implementation but only the user interface.
>
> I can also see how record/device support could be written in C
> instead
> of C++ and dataAccess could still be used by iocCore supplied
> libraries
> to transport data into and out of records. If we go with the V4
> DBD idea
> of struct and array, utilities like dbToStructH,etc, could
> generate a
> header file AND code that uses dataAccess to get/put the struct
> fields.
>
> We still have lots to think about in order to implement the
> Functional
> Requirements for V4. If we decide to use dataAccess it is only
> part of
> what is required.
>
> Marty
- References:
- dataAccess Marty Kraimer
- Navigate by Date:
- Prev:
Re: EPICS base V4 Eric Norum
- Next:
Re: memory management Benjamin Franksen
- 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:
dataAccess Marty Kraimer
- Next:
Re: EPICS base V4: iocCore database Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024