Tuesday, December 11, 2012

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;
    sprintf(&str[i], "%d", !!(m & val));  
    m = m >> 1;
  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)));

Tuesday, November 13, 2012

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;

Saturday, November 10, 2012

#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
struct foo
    int member;
#endif /* GRANDPARENT_H */


Compiler#pragma once
Comeau C/C++Supported[11]
Digital Mars C++Supported[12]
Intel C++ CompilerSupported[14]
Microsoft Visual C++Supported[15]
C++Builder XE3Supported[16]

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

Saturday, September 8, 2012