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: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] 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
