Ok, so it seems there are two main concerns related with fixing my problem:
1. We want to maintain backward compatibility.
2. We want to prepare for OCF 1.0 and be able to support 64 bit
integers.
Here's my proposal:
I'll make OCRepresentation use only int64_t internally. I'll explicitly write
what (get|set)Value<int>() is supposed to do, so that it cast "int64_t" to
"int", BUT the retrieved value is greater/smaller than INT_MAX/INT_MIN,
getValue<int>() will return the same value it currently does in case of an
error (which is zero).
This way all previous applications will work the way they used to, since they
relied only on "int" anyway, so we shouldn't expect values outside of this
scope. If someone was trying to use other values, then their applications
didn't work properly anyway. Also, anyone who consciously uses 64-bit value
will be able to do so.
What do you think?
Thanks,
Pawel
-----Original Message-----
From: ??? (Uze Choi) [mailto:[email protected]]
Sent: Wednesday, January 11, 2017 19:14
To: 'Thiago Macieira' <thiago.macieira at intel.com>; Pawel Winogrodzki
<pawelwi at microsoft.com>
Cc: iotivity-dev at lists.iotivity.org
Subject: RE: [dev] Integer representation in OCRepresentation, OCRepPayload and
cbor encoder
Proposal to selecting C API had been proposed before but discarded in the
IoTivity initial time.
Now, already IoTivity C and C++ language ecosystems are working and people are
using both.
Let's concentrate on how to correctly support them.
In case of using integer in the 32 bit machine with C++ and Java language,
During casting, data will be lost and especially distorted in case of minus
value.
Changing and limiting into int32_t will be only way to resolve them I think.
Additionally we need to make sure 32 bit size for OCF integer authorized.
If not need more consideration.
BR, Uze Choi
-----Original Message-----
From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-
[email protected]] On Behalf Of Thiago Macieira
Sent: Thursday, January 12, 2017 4:46 AM
To: Pawel Winogrodzki
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Integer representation in OCRepresentation, OCRepPayload and
cbor encoder
On quarta-feira, 11 de janeiro de 2017 19:41:09 PST Pawel Winogrodzki wrote:
> If the C++ APIs may be modified with disregard to backwards
> compatibility, then I should be able to switch OCRepresentation to use
> int64_t as the only supported integer type and thus be compatible with
the rest of the code.
>
> I would need to know, if there is a IoTivity-wide approval to perform
> such changes, before I start working on them.
In my opinion, it should. The distinction between the C and the C++ API exists
for reasons that are no longer valid. The C API is too low-level to the point
of being obfuscated, like a function "do" that takes 9 parameters, while the
C++ API is too high level and does not get enough attention, not to
C++ mention
that it was designed with intentional disregard for compatibility with older,
non-C++11 compilers.
We should have a unified API in one language only -- I understand Microsoft's
preference would be for a C API.
We do need an IoTivity-wide approval for replacement, but we can start adding
one meanwhile, intermediate to the existing two, and leave the approval to when
it's complete and can show its own benefits.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
