Re: proposal for implementing unsigned

[Marty K. <mrk...@co...>]

On 02/08/2012 07:10 AM, dav...@di... wrote:
> This seems to be the opposite of what we agreed at the meeting.
>
> What we agreed was that the get should return the "safe" wider type and there should be a getRaw that should return the underlying signed type:
>
> interface PVUByte extends PVScalar {
>       byte getRaw();
>       short get ();
> }
>
>
> interface PVULong extends PVScalar {
>       long getRaw();
>       BigInteger getRaw();
> }

Three observations.

1) What about PVIntArray? To do as you suggest get will require an 
argument of UIntArrayData instead of IntArrayData. In order to satisfy 
both get, getRaw, and serialize/deserialize the implementation will have 
to keep both a short[] and a byte[] AND make sure the two stay in sync.
2) Neither C++ or Java traps exceptions for integer overflow.
3) The above breaks a lot of existing code.

What the proposal specifies should not affect code that uses pvData or 
pvAccess.
It only requires changes to the implementation.

Marty
> We didn't actually specify the put functions - maybe we need put() and putRaw as well.
>
> Dave.
>
>
> Dr David  Hickin
> Software Systems Engineer, Controls Group
> Diamond Light Source Ltd
> Diamond House
> Harwell Science&  Innovation Campus
> Didcot, Oxfordshire, OX11 0DE
>
> --
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
> -----Original Message-----
> From: Marty Kraimer [mailto:mrk...@co...]
> Sent: 08 February 2012 11:52
> To: epi...@li...
> Subject: proposal for implementing unsigned
>
> Matej and I would like to add the following as part of implementing
> unsigned:
>
> For Java a new method will be available for each of the PVUxxx interfaces.
>
> For unsigned scalar types the method will be named getWider and it will return the next wider type.
> Examples are
>
> interface PVUByte extends PVScalar {
>       byte get();
>       void put(byte value);
>       short getWider();  // NEW METHOD
> }
>
> interface PVULong extends PVScalar {
>       long get();
>       void put(long value);
>       BigInteger getWider(); // NEW METHOD }
>
>
> For unsigned array types the method will be get but with different args:
> Examples are
>
> public interface PVByteArray extends PVScalarArray{
>       int get(int offset, int length, ByteArrayData data);
>       int put(int offset,int length, byte[] from, int fromOffset);
>       void shareData(byte[] from);
>       int get(int offset, int length, short[] dest, int toOffset);   //
> NEW METHOD
> }
>
> public interface PVLongArray extends PVScalarArray{
>       int get(int offset, int length, LongArrayData data);
>       int put(int offset,int length, long[] from, int fromOffset);
>       void shareData(byte[] from);
>       int get(int offset, int length, BigInteger[] dest, int toOffset);
> // NEW METHOD
> }
>
> Since it has already been decided that we give up on complete compatibility between Java an C++ there will be one additional change while implementing unsigned.
>
> For C++ the type associated for  anything associated with length will be size_t instead of int.
> This means that on a 64 bit architecture C++ will support arrays>  2 giga elements in size.
> If an application creates arrays>  2 giga elements than the array can not be shared with a Java client or with a 32 bit C++ client.
>
> Note that the pvAccess network specification already supports this.
>
> Marty and Matej
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>