On Fri, 28 Feb 2025 19:08:37 -0500, Christopher Shannon <christopher.l.shan...@gmail.com> wrote:
| Thanks for the PR! It's very much appreciated to have some help with | the C++ client. Let's hope the PR can be merged into the repo expeditiously! There are 4 people "officially" (I don't know the correct term here) associated with the repo as reviewers/committers, but none of them seems active. There have been PRs and JIRAs over the past decade, but the last real activity seems to date to early 2019. I think it needs to be said that while my work looks extensive, it really isn't. The bulk of it took only a weekend. Just about all of it could have been done a decade ago by tackling the official C++11 deprecations (viz., std::auto_ptr and throw specifications.) The only extra work was cleaning up the warnings. Which, of course, raises the old meta-issue of why interest in working on the C++ client has languished. Not that there is any dearth of users. I think there are two basic reasons for this, which in turn don't bode well for the future. The first reason is the overtly Java-esque character of the code base. Java people have no idea how off-putting and disincentivizing reams of sustained non-idiomatic C++ code can be, especially when it's clear that an alien idiom is being used instead. Which C++ programmer would even want to work on a code base where in order to understand it, he has to "think" like a Java programmer? I spent time struggling with this myself when I was fixing the warnings. I had to check, as best I could, that my replacement code wasn't tripping up some Java-ish assumption I wasn't aware of. My only assurance that I may have got it right is that the code compiles cleanly and all tests pass. But I wouldn't be suprised in the least that I've introduced new bugs waiting to bite, when I emended some Java-influenced infelicities. The second reason is perhaps fundamental. It's related to the first in being Java-inspired. The code base systematically heap-allocates _everything_, using smart pointers to handle the ensuing difficulties. This is inefficient, clumsy, and profoundly anti-C++ in spirit. This is also reflected in the CMS API itself, where the objects and their methods practically force user level code to work with heap-allocating code. I mentioned this problem, and how to tackle it, on this list four years ago. https://lists.apache.org/thread/v66hx30fcwb79pps3sxq1nq3q6j2vygy Rather than persevere with the C++ API, i think the effort going forward should be to develop an equivalent C API. A library implemented in C++ exposing a C API is by no means unusual or uncommon. It's an itegral part of the so-called Hourglass API pattern (not to be confused with the hourglass graphic.) https://blog.sigbusfactor.com/2022/05/29/efficient-hourglass-api.html (For a quick introduction, see https://www.linkedin.com/pulse/hourglass-interface-cc-apis-c-libraries-jarno-ralli-phd-lfgrf) A CMS-like C++ API can be built on it for those that need it, but the real benefit of a C API is the stable ABI and bindings to other languages (especially scripting ones.) I have some materials of a simplified API built on treating CMS objects as "typed void pointers", with working examples, here: https://github.com/arayq2/utility/tree/master/amq Arjun --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
