At this point, I believe that I have converted all of the important classes to be ABI-stable. There are a few that I have missed, some probably unintentional, some because I plan on removing them. There are also a handful of classes that don't need to be(nor perhaps should be) ABI-stable - I'm thinking mostly of the LocationInfo in PR#75. We should probably allocate a few extra bytes onto the end of any classes like LocationInfo incase we ever need to add extra members(the current PR does break the ABI as it changes the size of the LocationInfo class - we don't make any claims as to being ABI-stable at the moment, so it doesn't really matter).
As per the LocationInfo, in the future we should probably make more use of std::string_view(C++17) or the equivalent boost::string_view. The string_view would be perfect for use in the LocationInfo class, since it just needs to point at a const char* but having the ability to do string-like functions would be useful. I suspect that there are several other places where we can make use of string_view as well, perhaps gaining some performance improvements. Some notes on string_view: https://rules.sonarsource.com/cpp/RSPEC-6009 I'll merge this into a new branch(log4cxx-next?) shortly, unless anybody finds any problems. Once that is complete, it should be much easier to fix problems going forward. I think my immediate plans after this would be to: * Get the multi-process RollingFileAppender working. Since you currently need a custom-built version of log4cxx to make it work, it's of somewhat limited usefulness at the moment(I don't think there are any tests at the moment either, so that's not too useful) * Remove any APR references in the header files. Since most of what we use APR for is in C++11, my plan is to try to eliminate APR for basic logging setups. e.g. the date/time that is used can be replaced with std::chrono, threads we have already switched to std::thread, networking we can switch between using APR and using boost::asio, etc. This /should/ mean that if you have a C++11 only compiler, you'll need to have boost installed to build, but if you have a C++17 compiler you won't need any dependencies to build. -Robert Middleton On Sun, Nov 7, 2021 at 12:02 PM Thorsten Schöning <[email protected]> wrote: > > Guten Tag Robert Middleton, > am Sonntag, 7. November 2021 um 17:36 schrieben Sie: > > > I don't see any advantage to this over a macro, unless you were > > thinking of something else? > > That's exactly what I meant and the benefits I see are simply avoiding > a macro and having something documented for the class as part of its > (private) API. With having that method abstract, one can even force > it's implementation in subclasses, resulting in a more uniform access > to the data across the code base etc. > > That's different with a macro, which might result in bad error > messages during compilation, might be named differently across > classes, might not be available because devs missed it etc. > > Though, it's a matter of taste most likely. > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > E-Mail: [email protected] > Web: http://www.AM-SoFT.de/ > > Tel: 05151- 9468- 0 > Tel: 05151- 9468-55 > Fax: 05151- 9468-88 > Mobil: 0178-8 9468-04 > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > > > >
