This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]