Creating bit function

char* bits(unsigned int val) 
returns a character string holding the bit pattern of val (i.e cout<<bits(0xF7)<<endl, will print 11110111)

char* bits(unsigned int val) {
  unsigned int m = 1 << (sizeof(val)*8 -1); 
  char* str = new char[sizeof(val)*8];
  int i = 0;
  while(m){  
    sprintf(&str[i], "%d", !!(m & val));  
    m = m >> 1;
    i++;
  }
  return str;
}

Sets the "bitNo" bit of val to the "bitVal" value

void setBit(unsigned int& val, unsigned int bitNo, bool bitval) {
  val = bitval ? (val | (1 << bitNo)) : (val & (~(1 << bitNo)));
}

How to set a pointer to NULL

 

1. CField* _fld[C_MAX_NO_FIELDS] = {0};

2. CField* _fld[C_MAX_NO_FIELDS];

    memset(_fld, 0, sizeof(_fld));

3. CField* _fld[C_MAX_NO_FIELDS];

    for( i = 0; i < sizeof(_fld) / sizeof(CField*); i++) {

         _fld[i] = NULL;

    }  

 

#pragma once

I just wondered what the differences between #pragma once and safeguard are. So I found a useful information from Wikipedia

 Advantages and disadvantages

Using #pragma once instead of include guards will typically increase compilation speed since it is a higher-level mechanism; the compiler itself can compare filenames or inodes without having to invoke the C preprocessor to scan the header for #ifndef and #endif.

Common compilers such as GCC, Clang, and EDG-based compilers include special speedup code to recognize and optimize the handling of include guards, and thus little or no speedup benefit is obtained from the use of #pragma once.^[2][3][4]

Again because the compiler itself is responsible for handling #pragma once, it is not necessary for the programmer to create new macro names such as GRANDPARENT_H in the Include guard article's example. This eliminates the risk of name clashes, meaning that no header file can fail to be included at least once.

However, this high-level handling is not perfect; the programmer must rely on the compiler to handle #pragma once correctly. If the compiler makes a mistake, for example by failing to recognize that two symbolic links with different names point to the same file, then the compilation will fail. Compilers with #pragma once-related bugs included LCC-Win32 as of 2004^{[citation needed][5][6]} and GCC as of 1998.^[7] GCC originally gave a warning declaring #pragma once"obsolete" when compiling code that used it. However, with the 3.4 release of GCC, the #pragma once handling code was fixed to behave correctly with symbolic and hard links. The feature was "un-deprecated" and the warning removed.^[8][9]

Both #pragma once and include guards can be used to write portable code that can also take advantage of the #pragma once optimization if the compiler supports it:

File "grandparent.h"

#pragma once
#ifndef GRANDPARENT_H
#define GRANDPARENT_H
 
struct foo
{
    int member;
};
 
#endif /* GRANDPARENT_H */

Portability

Compiler	#pragma once
Clang	Supported[10]
Comeau C/C++	Supported[11]
Digital Mars C++	Supported[12]
GCC	Supported[13]
Intel C++ Compiler	Supported[14]
Microsoft Visual C++	Supported[15]
C++Builder XE3	Supported[16]

                                       From Wikipedia <http://en.wikipedia.org/wiki/Pragma_once>

Welcome to Youngjae Kim's Blog.