Experimental Physics and
Industrial Control System

Timo Korhonen via Core-talk <[email protected]> · Fri, 27 Sep 2019 12:57:32 +0000

>    Still, what works well for the Java implementation may not be best for the C++ implementation.
>    One point of the alternate libs is to use the best of each language, not having to settle for the worst of both ;-)

Fully agree but I am just wondering how to explain the general concept in a way that neither Java nor C++ programmers get confused when they start looking at the code.
If the implementations are totally different then the reader should be made aware of that. 
Anyway, the point that I wanted to make in the explanations is that the structure information is exchanged only at connection time. 
I think that is an important concept to understand. (And I hope I have understood it correctly...)

Cheers,

Timo

On 27/09/19 14:33, "Kasemir, Kay" <[email protected]> wrote:

    Hi:

    >I guess that a similar rewrite will also happen for the C++ code and if I skip or reduce the text about introspection, a similar pattern will apply for both C++ and Java?
    The alternative C++ implementation is just being started.
    Can't say for sure if it will also just have 'containers'.
    For the Java code, that seems to work great. Much smaller API, looks like I can do everything that's required: server & client, info/read/write/subscribe/RPC.
    Only shortcoming would be that 'info' operations hands you an empty container.
    So instead of for example
       StructureDescriptor "timeStamp": { LongDescriptor "secondsPastEpoch", IntDescriptor "nanoseconds", ... }
    you get a
       PVAStructure "timeStamp": { PVALong "secondsPastEpoch" = 0, PVAInt "nanoseconds" = 0, ... }
    The caller of PVAChannel.info() needs to know that the obtained PVAStructure is empty, it's only meant to describe the data.
    Nothing keeps you from printing the timestamp with secondsPastEpoch, nanoseconds, .. and then you see that all values are 0, NaN, [].
    Yes, that means inside the client you now have a PVALong with 8 wasted bytes for the long value = 0, a PVAInt with 4 wasted bytes for the int value = 0.
    But in the bigger picture, those long, int, double values don't waste much space.
    Would be bad if fetching the info for an NTNDArray got the actual int[2,000,000] data array, but all you get is int[0].
    So memory-wise we're fine.
    More important, the API is simpler, and the usage inside all the other operations might actually be faster, since you get the containers right away, no need to first allocate memory for the description hierarchy, then turn that into a container hierarchy, freeing the description hierarchy, ..
    Still, what works well for the Java implementation may not be best for the C++ implementation.
    One point of the alternate libs is to use the best of each language, not having to settle for the worst of both ;-)

    Thanks,
    Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System