You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Arjun Ray <ar...@gmail.com> on 2025/02/28 22:50:45 UTC
New PR #21 AMQCPP-756 Changes for C++17 compliance
I've submitted a pull request to the repo:
https://github.com/apache/activemq-cpp/pull/21
with all the changes needed for C++17 compliance. See also
https://issues.apache.org/jira/browse/AMQCPP-756
Someone with committer privileges will need to pick up the ball from
here. I'm not sure what else is needed to cut/tag a 3.9.6 release,
but at a minimum I figure
1. Updating the pom.xml files to reflect the new version number.
2. An appropriate Changelog entry.
Apropos of a bump to 3.10.x, I note that the branch was cut some time
in 2018 or 2019 (!), and has commits already that are not in 3.9.x. It
looks like this was done when 3.9.4 was the latest release tag.
I'm nowhere near enough of a git maven to mess with the merging of
divergent branches, so I'll leave that to someone who knows what to
do. But it does seem that the 3.10.x bump may not be straightforward.
Arjun
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Arthur Naseef <ar...@apache.org>.
Agree on version 4.x - no need to go there now.
For the 3.10.x branch - how about we treat 3.10.0 as "dead" and skip to
3.11.0 - then, leave that branch and work on a fresh 3.11.0 branch.
Lingering, incomplete work from the past should not hold us up. I was
thinking to suggest renaming the branch, but that could be ugly with
distributed git repos.
If some of the content on the 3.10.x is desireable, then we work it in
later.
Art
On Tue, Mar 4, 2025 at 11:37 AM Arjun Ray <ar...@gmail.com> wrote:
> On Tue, 4 Mar 2025 10:38:08 -0500, Christopher Shannon
> <ch...@gmail.com> wrote:
>
> | I've actually been wondering if we should just bump the major version to
> | 4.0.0, but at the very least with all the work here certainly 3.10.0
> |
> | One other thing to note is the OpenWire version is probably out of date
> | (OpenWire is up to 12 and eventually will go to 13 if we add shared
> | subscription support and other changes). At some point this could be
> | brought up to date although the generator that was being used in the
> | ActiveMQ project no longer works on newer versions so that would need to
> be
> | figured out.
>
> I think the version bump to 4.0.0 should wait until the Openwire
> update. That could potentially be a major change, justifying the
> change in the major version number.
>
> Right now, the API hasn't been impacted at all - the changes have been
> internal, just beefing up the code base.
>
> A quick note, that the 3.10.x branch already exists, forked off
> release 3.9.4 a while back, with at least one important fix. I'm not
> sure if that fix was replicated in 3.9.5. At any rate some intelligent
> merging will be needed.
>
> Right now, my PR is for a merge into 3.9.x. Say we tag the result
> 3.9.6. On 3.10.x, we can tag the current state at 3.10.0, then
> merge/rebase 3.9.6 on top of that and tag it 3.10.1, for releaae. Or
> is that too involved?
>
> Arjun
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Arjun Ray <ar...@gmail.com>.
On Tue, 4 Mar 2025 10:38:08 -0500, Christopher Shannon
<ch...@gmail.com> wrote:
| I've actually been wondering if we should just bump the major version to
| 4.0.0, but at the very least with all the work here certainly 3.10.0
|
| One other thing to note is the OpenWire version is probably out of date
| (OpenWire is up to 12 and eventually will go to 13 if we add shared
| subscription support and other changes). At some point this could be
| brought up to date although the generator that was being used in the
| ActiveMQ project no longer works on newer versions so that would need to be
| figured out.
I think the version bump to 4.0.0 should wait until the Openwire
update. That could potentially be a major change, justifying the
change in the major version number.
Right now, the API hasn't been impacted at all - the changes have been
internal, just beefing up the code base.
A quick note, that the 3.10.x branch already exists, forked off
release 3.9.4 a while back, with at least one important fix. I'm not
sure if that fix was replicated in 3.9.5. At any rate some intelligent
merging will be needed.
Right now, my PR is for a merge into 3.9.x. Say we tag the result
3.9.6. On 3.10.x, we can tag the current state at 3.10.0, then
merge/rebase 3.9.6 on top of that and tag it 3.10.1, for releaae. Or
is that too involved?
Arjun
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Christopher Shannon <ch...@gmail.com>.
Sounds like great progress, thanks Art and Arjun.
I've actually been wondering if we should just bump the major version to
4.0.0, but at the very least with all the work here certainly 3.10.0
One other thing to note is the OpenWire version is probably out of date
(OpenWire is up to 12 and eventually will go to 13 if we add shared
subscription support and other changes). At some point this could be
brought up to date although the generator that was being used in the
ActiveMQ project no longer works on newer versions so that would need to be
figured out.
On Sun, Mar 2, 2025 at 7:12 PM Arjun Ray <ar...@gmail.com> wrote:
> On Sat, 01 Mar 2025 11:00:29 -0500, I wrote:
>
> | The significant part of that update is my workaround for the m4 macros
> | in the build system needing the obsolete (and dropped) cppunit-config
> | program. Eventually, the m4 macros themselves need to be revised so
> | that this workaround isn't necessary. I've attached an example script
> | to the distribution, and tried to make it clear that to be used at all
> | it needs adaptation to the local environment.
>
> 1. Good news! Art Naseef has done some heavy lifting for us and
> produced an updated version of a m4 script, that uses pkg-config to
> configure Cppunit if the obsolete cppunit-config program is not
> available.
>
> The workaround script may still be necessary, but now in much rarer
> circumstances.
>
> 2. He also found a problem with the library code for handling longs
> that comes up only in builds with optimization turned on ('-O2'). This
> causes one of the unit tests to fail.
>
> For now, I think it's best to leave that be, as fixing it may not be
> worth the effort (aggressive optimization is a nice-to-have extra at
> best).
>
> 3. Another issue he uncovered was that the unit test for the Date
> handling logic was not timezone agnostic. That was an easy fix.
>
> 4. The README file needs updating. That seems the only remeaining
> item that can be immediately looked into.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
>
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Arjun Ray <ar...@gmail.com>.
On Sat, 01 Mar 2025 11:00:29 -0500, I wrote:
| The significant part of that update is my workaround for the m4 macros
| in the build system needing the obsolete (and dropped) cppunit-config
| program. Eventually, the m4 macros themselves need to be revised so
| that this workaround isn't necessary. I've attached an example script
| to the distribution, and tried to make it clear that to be used at all
| it needs adaptation to the local environment.
1. Good news! Art Naseef has done some heavy lifting for us and
produced an updated version of a m4 script, that uses pkg-config to
configure Cppunit if the obsolete cppunit-config program is not
available.
The workaround script may still be necessary, but now in much rarer
circumstances.
2. He also found a problem with the library code for handling longs
that comes up only in builds with optimization turned on ('-O2'). This
causes one of the unit tests to fail.
For now, I think it's best to leave that be, as fixing it may not be
worth the effort (aggressive optimization is a nice-to-have extra at
best).
3. Another issue he uncovered was that the unit test for the Date
handling logic was not timezone agnostic. That was an easy fix.
4. The README file needs updating. That seems the only remeaining
item that can be immediately looked into.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Arjun Ray <ar...@gmail.com>.
On Sat, 1 Mar 2025 07:10:28 -0600, Matt Pavlovich
<ma...@apache.org> wrote:
| I commented on your PR and will help support your efforts, despite
| my C++ experience being rusty =).
Thank you :-)
I believe Art Naseef has also offered to help, although he may be busy
at the moment.
I just updated the PR to include some adminstrative stuff, including
your important reminder that the README.txt (not .md yet) files need
updating. There are two of them, so I added the new text to both,
pending a comprehensive edit combining them into a single README.md.
The significant part of that update is my workaround for the m4 macros
in the build system needing the obsolete (and dropped) cppunit-config
program. Eventually, the m4 macros themselves need to be revised so
that this workaround isn't necessary. I've attached an example script
to the distribution, and tried to make it clear that to be used at all
it needs adaptation to the local environment.
I'm not sure where the MS Visual Studio build stands. I have VS 2019
installed on my Windows 10 box, but have never really used it. I dread
the prospect, especially installing the external dependencies (the APR
libraries, Cppunit, etc) and jiggering the configs just right for
Visual Studio, a well-known finicky process.
Any help in that area would be vastly appreciated!
Arjun
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Matt Pavlovich <ma...@apache.org>.
Hi Arjun-
Thank you for your efforts on the ActiveMQ C++ library!
I commented on your PR and will help support your efforts, despite my C++ experience being rusty =).
Thank you!
Matt Pavlovich
ActiveMQ PMC Member
> On Feb 28, 2025, at 11:11 PM, Arjun Ray <ar...@gmail.com> wrote:
>
> On Fri, 28 Feb 2025 19:08:37 -0500, Christopher Shannon
> <ch...@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-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Arjun Ray <ar...@gmail.com>.
On Fri, 28 Feb 2025 19:08:37 -0500, Christopher Shannon
<ch...@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-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: New PR #21 AMQCPP-756 Changes for C++17 compliance
Posted by Christopher Shannon <ch...@gmail.com>.
Hi Arjun,
Thanks for the PR! It's very much appreciated to have some help with
the C++ client.
In terms of the 3.10.x branch, I honestly would probably just start
over. 3.9.x has been updated more recently as you noted, so I think it
would probably be best to start fresh with 3.10.x on a new branch
(using this release as the basis).
Once we bump the version we can go and see if there's anything that
was applied to the really old 3.10.x that we want to try and cherry
pick or manually move over as I really doubt we can merge with all the
changes you made without doing it manually.
Chris
On Fri, Feb 28, 2025 at 5:51 PM Arjun Ray <ar...@gmail.com> wrote:
>
>
> I've submitted a pull request to the repo:
>
> https://github.com/apache/activemq-cpp/pull/21
>
> with all the changes needed for C++17 compliance. See also
>
> https://issues.apache.org/jira/browse/AMQCPP-756
>
> Someone with committer privileges will need to pick up the ball from
> here. I'm not sure what else is needed to cut/tag a 3.9.6 release,
> but at a minimum I figure
>
> 1. Updating the pom.xml files to reflect the new version number.
> 2. An appropriate Changelog entry.
>
> Apropos of a bump to 3.10.x, I note that the branch was cut some time
> in 2018 or 2019 (!), and has commits already that are not in 3.9.x. It
> looks like this was done when 3.9.4 was the latest release tag.
>
> I'm nowhere near enough of a git maven to mess with the merging of
> divergent branches, so I'll leave that to someone who knows what to
> do. But it does seem that the 3.10.x bump may not be straightforward.
> Arjun
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
> For additional commands, e-mail: dev-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@activemq.apache.org
For additional commands, e-mail: dev-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact