jmdavison46 commented on pull request #86:
URL: https://github.com/apache/logging-log4cxx/pull/86#issuecomment-1003830945
The point is to allow the developer to recover the major/minor/patch/tweak
fields from an integer-valued LOG4CXX_VERSION; one use case is the act of
logging the major/minor/patch/tweak fields, in human-readable form, based on a
LOG4CXX_VERSION-format integer that has been passed to it. The
LOG4CXX_VERSION-format integer in question, and consequently the
major/minor/patch/tweak fields in the log message, need not correspond to the
LOG4CXX_VERSION that was defined at the time of compilation. (If this sounds
too abstract, consider that client code that must be compiled against various
releases of apache-log4cxx must not only be able to perform preprocessor logic
based on the current version, but may also need to define other
LOG4CXX_VERSION-format to delineate the lifetimes of features or bugs in the
history of the library. There may be log messages that describe the lifetimes
of log4cxx bugs/features.)
The utility of LOG4CXX_VERSION_GET_{MAJOR,MINOR,PATCH,TWEAK} would be more
obvious if we were to add a version identifier object (i.e. an externally
visible integer value) to the DSO/DLL, which is something we should eventually
do, arguably in the next release, to assess library version compatibility at
run time. Such a version identifier would allow the client code to compare the
compile-time LOG4CXX_VERSION to the LOG4CXX_VERSION baked into the DSO/DLL in
use, and the LOG4CXX_VERSION_GET_{MAJOR,MINOR,PATCH,TWEAK} macros would allow
the code to report the (potentially conflicting) values in a human-readable
manner instead of the unreadable LOG4CXX_VERSION format.
In short, the utility of these macros becomes apparent when developing
long-lived code that is expected to build against a range of releases of
apache-log4cxx and provide human-readable error/status information concerning
the version of apache-log4cxx version against which the code was compiled and
against which it is/was linked. Compile-time and link-time/run-time
version-reflection functionality is properly expected from non-throwaway
libraries, and It’s time for apache-log4cxx to add it. Macros to parse version
number components out of a packed version number integer are necessary for
human readability (e.g. rendering the version number to stdout), code
readability, and separation of concerns (the parsing should be hidden in the
macro, not leaked into user code).
From: Robert Middleton ***@***.***>
Reply-To: apache/logging-log4cxx ***@***.***>
Date: Saturday, 2022-01-01/ at 8:39 AM
To: apache/logging-log4cxx ***@***.***>
Cc: jmdavison46 ***@***.***>, Author ***@***.***>
Subject: Re: [apache/logging-log4cxx] Update log4cxx.h.in (PR #86)
@rm5248 commented on this pull request.
In src/main/include/log4cxx/log4cxx.h.in:
> +#define LOG4CXX_VERSION_GET_MAJOR(version) (((version) >> 24) & 0xFF)
+#define LOG4CXX_VERSION_GET_MINOR(version) (((version) >> 16) & 0xFF)
+#define LOG4CXX_VERSION_GET_PATCH(version) (((version) >> 8) & 0xFF)
+#define LOG4CXX_VERSION_GET_TWEAK(version) ((version) & 0xFF)
Maybe I'm missing something here, but what is the point of this? If you do
LOG4CXX_VERSION_GET_MAJOR(LOG4CXX_VERSION), that will give you exactly the same
as the LOG4CXX_VERSION_MAJOR macro, which is defined above.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
