Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 8 Jul 2005 12:03:03 +0200

On Friday 08 July 2005 01:23, Andrew Johnson wrote:
> Benjamin Franksen wrote:
> > What I proposed for the IVOA/IVOV example is easily adapted to
> > other scenarios, like simulation stuff, or alarm limit handling.
> > Ok, all this needs a developer who writes the code and (more
> > importantly) designs an appropriate interface that is general
> > enough to be used in any record type that needs such a facility.
>
> I think you persuaded me about that, although I think I might
> simplify your syntax a little (and forget what I said earlier about
> separating class and struct).  How about this DBD syntax:
>
> struct (drvLimits, ValType) {
>      field(high, ValType)
>      field(low, ValType)
>      method("STATUS constrain(ValType &value)")
> }

I'm fine with this. I didn't give the concrete syntax a lot of thought. 
Personally, I don't like the C++-template syntax at all, it is much too 
verbose for my taste. The above proposal is better, although one could 
nitpick that it is a bit irregular, since the first element of the list 
in '(structName, TypeVar1, TypeVar2,...)' has different meaning than 
the following ones. I don't have a better proposal at hand, though.

Another point: What is the use of the method definition, apart from 
generating a C++ member declaration? If there is no other use, we can 
avoid it by using a regular top-level procedure, as shown in my 
proposal on the wiki. I ask because I find it somewhat ugly to cite a 
foreign language (C++) term inside the dbd file. I know, we already do 
this for DBF_NO_ACCESS fields, but I never liked that one either (and I 
believe it can be avoided, too).

> The presence of one or more ValType arguments after the struct name
> causes a template struct definition to be generated (without it, we
> just get a regular struct definition):
>
> template <typename ValType>
> struct drvLimits {
>      ValType high;
>      ValType low;
>      STATUS constrain(ValType &value);
> }
>
> The implementation of the drvLimits::constrain() method has to be
> provided externally, just as with your code

One minor detail: We should have a consistent scheme for C/C++ entities 
generated from dbd definitions. If record types are translated to 
'struct xxxRecord {...}' as before (and not just 'struct ao {...}', 
then we should also generate

  struct drvLimitsStruct {...}

and also name menu type definitions generated from

  menu(scan) {
    choice(passive,"Passive")
    ...
  }

as

  enum scanMenu {
    scanPassive,
    ...
  }

plus

  epicsString scanMenuNames[];

> > OTOH, it would of course be great if we could assemble all these
> > pieces at record load time, rather than compile it into the record
> > type, so that each record will only have what it really uses. I
> > just can't see how to do this in a manner that is at the same time
> > efficient and safe. Well, apart from developing yet another
> > programming language for the task.
>
> Unfortunately that's probably what we'd have to do, so I'm not trying
> to think that one out any more.

Wow. A dedicated DBD/DB extension language. Let me think a while 
about /that/ one, before I comment...

Cheers,
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System