[
https://issues.apache.org/jira/browse/LOGCXX-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15199783#comment-15199783
]
Thorsten Schöning edited comment on LOGCXX-400 at 3/17/16 4:06 PM:
-------------------------------------------------------------------
I've tested with implementing the mentioned macros, but decided against it. The
macros are only ~4 chars shorter than the cast and my original goal was to wrap
all of the single chars with the macros to be able to better format the code
and such. But that introduces much more textual overhead, which mean less info
per line and more lines needed. The macros are still much to long for any
benefit. Using something extremely short like "_T" for strings on Windows would
be good, but that wouldn't fit into the current naming scheme and has a high
chance to break, because it's not unique enough.
While researching for a better solution with the error text from LOGCXX-463, I
found the following two interesting threads:
{QUOTE}
the signess of char is implementation specific. If you get this error means
that those values don't fit in a char meaning the char is signed on your
platform. Regardless, for compatibility you should declare unsigned char or
uint8_t as specified before for variables meant to hold byte values.
{QUOTE}
http://stackoverflow.com/questions/28094263/create-array-of-chars-avoiding-narrowing?rq=1#comment44564938_28094263
That makes sense, but it looks like my current compiler C++ Builder 10 Seattle
doesn't have the originally reported problem, even when the 32 or 64 Bit CLANG
with C++ 11 support is used. So I can't test any change properly and therefore
leave things as they are and only apply the changes already published in
comment 2.
The second interesting thread was the following, were some people simply wrap
the array into some class using variadic templates. Most of them work with gcc,
which I'm currently unable to test with, so I'll just leave a note again.
http://stackoverflow.com/questions/3719848/char-and-initializer-lists
was (Author: tschoening):
I've tested with implementing the mentioned macros, but decided against it. The
macros are only ~4 chars shorter than the cast and my original goal was to wrap
all of the single chars with the macros to be able to better format the code
and such. But that introduces much more textual overhead, which mean less info
per line and more lines needed. The macros are still much to long for any
benefit. Using something extremely short like "_T" for strings on Windows would
be good, but that wouldn't fit into the current naming scheme and has a high
chance to break, because it's not unique enough.
While researching for a better solution with the error text from LOGCXX-463, I
found the following two interesting threads:
{QUOTE}
the signess of char is implementation specific. If you get this error means
that those values don't fit in a char meaning the char is signed on your
platform. Regardless, for compatibility you should declare unsigned char or
uint8_t as specified before for variables meant to hold byte values.
{QUOTE}
http://stackoverflow.com/questions/28094263/create-array-of-chars-avoiding-narrowing?rq=1#comment44564938_28094263
That makes sense, but it looks like my current compiler C++Builder 10 Seattle
doesn't have the originally reported problem, even when the 32 or 64 Bit CLANG
with C++11 support is used. So I can't test any change properly and therefore
leave things as they are and only apply the changes already published in
comment 2.
The second interesting thread was the following, were some people simply wrap
the array into some class using variadic templates. Most of them work with gcc,
which I'm currently unable to test with, so I'll just leave a note again.
http://stackoverflow.com/questions/3719848/char-and-initializer-lists
> C++11 does not allow char literals with highest bit set unless cast
> -------------------------------------------------------------------
>
> Key: LOGCXX-400
> URL: https://issues.apache.org/jira/browse/LOGCXX-400
> Project: Log4cxx
> Issue Type: Bug
> Affects Versions: 0.10.0
> Environment: XCode 4.5, clang set to C++11
> Reporter: Andrew Lazarus
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> C++11 has tighter rules for widening of literals. In particular, 0xFF (for
> example) is an unsigned short unless cast otherwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
