This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: g++ problem
- From: Eljay Love-Jensen <eljay at adobe dot com>
- To: "Stefan Nonchev" <nonchev_stefan at hotmail dot com>, gcc-help at gcc dot gnu dot org
- Date: Fri, 20 Jun 2003 08:08:21 -0500
- Subject: Re: g++ problem
Hi Stefan,
The warning (warning, not error) is occurring because the code is somewhat
ambiguous.
Follow these steps to isolate the ambiguity:
Instead of...
if((( UCHAR )m_pSocket->m_sRxBuffer[0] == TAG ) && (( UCHAR
)m_pSocket->m_sRxBuffer[1] == XON )) {
...do this...
UCHAR* buffer = m_pSocket->m_sRxBuffer;
UCHAR bufferChar0 = buffer[0];
bool matchTag = (bufferChar0 == TAG);
if(matchTag) {
UCHAR bufferChar1 = buffer[1];
bool matchXon = (bufferChar1 == XON);
if(matchXon) {
NOTE: don't use any casts.
Reducing the line complexity is a good way to isolate the actual problem.
Removing "big hammer" casts is a good way to find root causes for compiler
confusion, when casts are involved. I recommend static_cast<UCHAR>(...) or
constructor casts instead, if you need to use a cast. C style casts are
dangerous, and when needed, should be replaced with
reinterpret_cast<UCHAR>(...) instead. The "reinterpret_cast" is
grep-able, C style casts are not.
The two if statements are to simulate the short-circuit nature of the
logical AND (&&).
I'd wager that the compiler's optimizer will produce the exact same output
whether the code is piecemeal as I've described, or
all-on-one-long-complicated-line as in your original code.
Readability and maintainability are more important in most projects, over
unnecessary obscurity and obtuseness. In my opinion.
A beneficial side-effect to the piecemeal approach is that it allows you to
use gdb to SEE what's going on with the state of the variables. Whereas
all-on-one-long-complicated-line prohibits ease of debugging.
--Eljay