[paho-dev] C++ library submission

[Frank Pagliughi <fpagliughi@xxxxxxxxxxxxxx>]

Hey All,

I just uploaded the C++ wrapper library that I have been working on for 
the last few weeks:
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=409174

As I mentioned in an earlier post, I wrapped the C library, and used the 
Java API as a guide. I literally cut and pasted the Javadoc from that 
project as the starting point for the C++ classes and documentation.

A few notes...

- I have only just discovered MQTT and used this library as a learning 
exercise. The submission represents everything I've ever done with MQTT 
to date, so it has yet to be used or tested in a production environment.

- I would appreciate any guidance on the direction to take the library 
in, as I plan to actually use it myself, and I will keep working on it.

- I chose to go with rather generic class names like "client" and 
"exception" in an "mqtt" namespace. I assume that I would generally keep 
the namespace closed and use the classes fully qualified, like 
"mqtt::client", etc.

- I tried to mimic the coding style of the C++ standard library. Class 
names in lower case with underscores, etc.

- I concentrated on the asynchronous library. In this version, the 
synchronous client (mqtt::client) just makes asynchronous calls and 
blocks until they complete.

- I used C++11 language and library extensions, particularly for shared 
pointers and portable thread synchronization objects. A recent compiler 
is required. I tested with GCC 4.6 and 4.7 on Linux.

- The dynamic objects (particularly messages and tokens) are intended to 
be allocated on the heap and accessed through shared pointers. The more 
static components (like clients and callback objects) can be declared 
globally or on the stack. This seemed a natural way to use the objects, 
but all of them can be created on the heap if the user wants complete 
consistency. All the classes define a shared pointer type with the 
extension "_ptr", like mqtt::message_ptr, mqtt::itoken_ptr, etc

- I used std::string to replace Java strings (not C-style char*) and 
std::vector for Java arrays. I've also assumed that a C++11 compiler 
would  provide move semantics for vectors so that returning them by 
value from a function does not have the performance hit that occurs when 
returning objects using earlier compilers (i.e. the object is moved out 
of the function rather than copied).

- Messages can use std::string for text data, but string objects can 
also be used for arbitrary binary data. In addition, the messages can be 
formed with a void* and a length.

- The exception hierarchy still needs some work.

- I haven't implemented any of the encryption or security features (yet).

Let me know what you think. Thanks.

Frank