On Jan 11, 2017 3:00 PM, "Morten Nielsen" <mn at iter.dk> wrote:
... For example you could change this C-SDK member: /** * This function gets the byte string from the payload. * * @param payload Pointer to the payload from which byte string needs to be retrieved. * @param name Name of the byte string. * @param value Byte string and it's length. * * @note: Caller needs to invoke OCFree on value.bytes after it is finished using the byte string. * * @return true on success, false upon failure. */ bool OCRepPayloadGetPropByteString(const OCRepPayload* payload, const char* name, OCByteString* value); to this: /** * This function gets the byte string from the payload. * * @param [in] payload Pointer to the payload from which byte string needs to be retrieved. * @param [in] name Name of the byte string. * @param [out] value Byte string and it's length. * * @note: Caller needs to invoke OCFree on value.bytes after it is finished using the byte string. * * @return true on success, false upon failure. * \public \memberof OCRepPayload So you annotate each C fn with a classname? Hmm, I'd have to mull that over. It might work for your purposes but I'm not sure it's such a great idea in general. Doesn't hurt, I guess, but I think I would be more inclined to put that kind of info in a separate layer. Separation of concerns - C is not OO, I think of it more in functional terms, fwiw. Mapping to oo is fine but we also have non-OO (specifically functional) languages to think about. in the case of iotivity just having doxygen would be a bigly improvement. g -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170111/8c29527a/attachment.html>
