If doing that much work and bumping to upgrade for C++17 compliance I would at least bump the version to 3.10.0
On Tue, Feb 18, 2025 at 8:12 PM Arjun Ray <ara...@gmail.com> wrote: > On Sun, 16 Feb 2025 23:05:09 -0500, Arjun Ray <ara...@gmail.com> > wrote: > > | To fix this, either the file m4/find_cppunit.m4 will have to be > | modified - which could be non-trivial as pkg-config is not a drop-in > | replacement for cppunit-config - or we can deploy a custom version of > | cppunit-config (that basically wraps a call into pkg-config). > > In the event, I ended up writing a cheesy shell script to return hard > coded values culled from the cppunit.pc file installed by the package. > That seemed to satisfy the build m4 macros, and everything compiled > successfully. > > All the tests passed as well (2070 regular tests, 133 integration > tests.) > > I'm now down to one warning. > > 1. The obsolete ASN1_STRING_data() function has been replaced by > ASN1_STRING_get0_data, which is obviously a drop-in replacement (it > simply "const"s the argument and return type.) This will break only > old systems (which aren't likely to have C++17 compilers anyway.) > > 2. The business with (volatile void **) has a workaround. I replaced > the call to > > : Atomics::compareAndSet((volatile void **)(&node->next), (void*)expect, > (void*)update); > > with a call to a templated function in the same file > > : Atomics::compareAndSwap<Node>(&node->next, expect, update); > > which expands to the same underlying call within Atomics.h. That > seemed to mollify the compiler. > > 3. The last remaining warning has to do with a commonly recurring > issue in the codebase: the class has a user-defined copy constructor > but no corresponding cpy-assignment operator (hence created by the > compiler, but with a warning). The offending class in this instance > is decaf::util::HashSet<int>. > > This is the Rule of Three (now Rule of Five for move semantics), where > if any of (1) destructor, (2) copy constructor, or (3) copy-assignment > operator are not defaulted (i.e left to the compiler to create > implicitly), then none of them should be (because construction / > destruction may need special treatment, such as pointer deletion.) > C++11 introduced a language feature to specify "default" or "delete" > for the declaration of these implicit functions. > > Fixing HashSet<> is complicated by its internals, which unfortunately > is clearly a remarkably wooden translation of Java code. It may turn > out to be straightforward to fix, but I'd need to be careful with such > heavily non-idiomatic code. > > > Summing up, all these changes, while extensive, are internal only. > Nothing has changed in terms of user-facing APIs. If 3.9.5 is the > current latest version, I suggest making this 3.9.6, with a prominent > annotation somewhere that this is simply an upgrade for C++17 > compliance. Those who don't need that can continue to use 3.9.5 for > the same functionality. > > > 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 > > >
