Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: M3
    • Component/s: C++ Client
    • Labels:
      None

      Description

      (See API proposal in QPID-664)

      Currently the C++ client API is like this:

      Connection myConnection;
      myConnection.open(...);
      Channel myChannel;
      myConnection.openChannel(myChannel);
      myChannel.dostuff...

      I would like to change it to be like this:

      Connection::shared_ptr myConnection = Connection::open(...);
      Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
      myChannel->dostuff...

      There are two problems with the current approach:

      • constructor creates "lame" objects, need an open() call to make them
        useful.
      • Letting user call constructor directly means we can't change the
        implementation class, whereas the second approach allows us to return
        anything inheriting from the user-visible class.

        Issue Links

          Activity

          Hide
          Alan Conway added a comment -

          We need to go a bit further and provide a full Pimpl client API to provide a binary compatibility safeguard. (http://en.wikipedia.org/wiki/Pimpl for definition of Pimpl) We should use shared_ptr to get normal copy semantics and automated memory management and templatize as much repetative code as possible.

          Show
          Alan Conway added a comment - We need to go a bit further and provide a full Pimpl client API to provide a binary compatibility safeguard. ( http://en.wikipedia.org/wiki/Pimpl for definition of Pimpl) We should use shared_ptr to get normal copy semantics and automated memory management and templatize as much repetative code as possible.
          Hide
          Alan Conway added a comment -

          The new API proposal covers the user-visible aspects of this issue. A separate JIRA can be raised for the binary-compatibility and protocol-version independence aspects.

          Show
          Alan Conway added a comment - The new API proposal covers the user-visible aspects of this issue. A separate JIRA can be raised for the binary-compatibility and protocol-version independence aspects.

            People

            • Assignee:
              Unassigned
              Reporter:
              Alan Conway
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development