[
https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697416#comment-14697416
]
ASF subversion and git services commented on PROTON-865:
--------------------------------------------------------
Commit 6bef190d4303f818dddfdc4f366ae152dd8cc6fe in qpid-proton's branch
refs/heads/cjansen-cpp-client from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6bef190 ]
PROTON-865: Replace proton_handler with simpler pointer-semantic wrapper
template.
Template proton::wrapper<pn_foo_t> simply wraps a pn_foo_t*. Derived classes
such as link, terminus etc. just provide C++ convenience wrapper functions.
Wrappers are passed by value, like pointers, not by reference.
Exception 1: proton::message has value semantics (copy the message) and owns
it's
pn_message_t* but still provides access to the underlying pointer. Functions
returning a message return a message&.
TODO: return by ref is ugly, needs move semantics on C++11. Arguably should be
a plain wrapper<> and provide value semantics in separate class?
Exception 2: proton::connection - TODO.
> C++ reactor client binding
> --------------------------
>
> Key: PROTON-865
> URL: https://issues.apache.org/jira/browse/PROTON-865
> Project: Qpid Proton
> Issue Type: New Feature
> Environment: C++
> Reporter: Cliff Jansen
> Assignee: Cliff Jansen
>
> This JIRA tracks initial work on a C++ binding to the Proton reactor event
> based model with an eye to providing an API very similar to the python
> client. As stated on the Proton list, the broad goals are:
> to make it easy to write simple programs
> natural to build out more complicated ones
> very similar API to the Python client
> lean and performant
> The initial introduction with accompanying HelloWorld can be found at
> https://github.com/apache/qpid-proton/pull/18
> Ongoing work is proceeding in my github account in branch cpp-work
> https://github.com/cliffjansen/qpid-proton/tree/cpp-work
> commit 1453f57ca3f446450ef654505548f1947cb7a0f1 adds listener support,
> exceptions and a logging interface.
> The initial implementation will provide no thread safety guarantees, but the
> bone structure should allow that to be added later with no API change. I
> still hold out hope of eventually allowing multiple threads processing
> separate connections concurrently.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
