Thinking about this a bit more still, I think we can do this in two
ways to make everything work properly. We can check for the
__cpp_lib_string_view macro and/or _MSVC_LANG(because windows always
needs to be different), and if the compiler supports std::string view
we use that at compile-time to
Guten Tag Robert Middleton,
am Sonntag, 2. Januar 2022 um 02:38 schrieben Sie:
> 2. Create a constexpr function that we control[...]
> 3. Use std::string_view(for C++17) or
> boost::string_view(pre-c++17).[...]
Just to make sure I understand correctly: The difference between 2 and
3 is using a
On Sat, Jan 01, 2022 at 08:38:43PM -0500, Robert Middleton wrote:
> The full path is already in the compiled code anyway, this would
> simply add the ability to get the filename from the full path(so
> another member to the LocationInfo class). I can see certain
> circumstances where it is useful
This is already provided by
```
#define LOG4CXX_LOCATION ::log4cxx::spi::LocationInfo()
#include
```
On Sun, Jan 2, 2022 at 12:38 PM Robert Middleton
wrote:
> The full path is already in the compiled code anyway, this would
> simply add the ability to get the filename from the full path(so
>
The full path is already in the compiled code anyway, this would
simply add the ability to get the filename from the full path(so
another member to the LocationInfo class). I can see certain
circumstances where it is useful to have the full path, for example
when you have two files named the
I prefer option 2 if it is possible.
I do not think it is useful to have the full path name (of the build
directory) in shipped binaries.
On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton
wrote:
> PR #75 adds a new option for displaying the short filename of the log
> location, which is probably
PR #75 adds a new option for displaying the short filename of the log
location, which is probably a good idea to have, as in my experience,
the whole path of the file is not that useful, especially when the
binary is from a build server where the path is something like
