Setting a bit
Use the bitwise OR operator (|) to set a bit.
number |= 1UL << n;
That will set the nth bit of number. n should be zero, if you want to set the 1st bit and so on upto n-1, if you want to set the nth bit.
Use 1ULL if number is wider than unsigned long; promotion of 1UL << n doesn't happen until after evaluating 1UL << n where it's undefined behaviour to shift by more than the width of a long. The same applies to all the rest of the examples.
Clearing a bit
Use the bitwise AND operator (&) to clear a bit.
number &= ~(1UL << n);
That will clear the nth bit of number. You must invert the bit string with the bitwise NOT operator (~), then AND it.
Toggling a bit
The XOR operator (^) can be used to toggle a bit.
number ^= 1UL << n;
That will toggle the nth bit of number.
Checking a bit
You didn't ask for this, but I might as well add it.
To check a bit, shift the number n to the right, then bitwise AND it:
bit = (number >> n) & 1U;
That will put the value of the nth bit of number into the variable bit.
Changing the nth bit to x
Setting the nth bit to either 1 or 0 can be achieved with the following on a 2's complement C++ implementation:
number ^= (-x ^ number) & (1UL << n);
Bit n will be set if x is 1, and cleared if x is 0. If x has some other value, you get garbage. x = !!x will booleanize it to 0 or 1.
To make this independent of 2's complement negation behaviour (where -1 has all bits set, unlike on a 1's complement or sign/magnitude C++ implementation), use unsigned negation.
number ^= (-(unsigned long)x ^ number) & (1UL << n);
or
unsigned long newbit = !!x; // Also booleanize to force 0 or 1
number ^= (-newbit ^ number) & (1UL << n);
It's generally a good idea to use unsigned types for portable bit manipulation.
or
number = (number & ~(1UL << n)) | (x << n);
(number & ~(1UL << n)) will clear the nth bit and (x << n) will set the nth bit to x.
It's also generally a good idea to not to copy/paste code in general and so many people use preprocessor macros (like the community wiki answer further down) or some sort of encapsulation.
To expand on the answer by bradtgmurray, you may want to make one exception to the pure virtual method list of your interface by adding a virtual destructor. This allows you to pass pointer ownership to another party without exposing the concrete derived class. The destructor doesn't have to do anything, because the interface doesn't have any concrete members. It might seem contradictory to define a function as both virtual and inline, but trust me - it isn't.
class IDemo
{
public:
virtual ~IDemo() {}
virtual void OverrideMe() = 0;
};
class Parent
{
public:
virtual ~Parent();
};
class Child : public Parent, public IDemo
{
public:
virtual void OverrideMe()
{
//do stuff
}
};
You don't have to include a body for the virtual destructor - it turns out some compilers have trouble optimizing an empty destructor and you're better off using the default.
Best Answer
Libraries in C++ are also considered helpful, but the way you integrate them is different to Java because the compiler only has to see the interface of the library, which is usually declared in header files. In Java, the compiler will have to inspect the actual libraries because Java doesn't have this distinction between an externally visible header file and the generated object code providing the implementation.
What you normally do is build the libraries separately, once, and put the generated lib/dll files plus the header files into a place that projects requiring the library can access. A common idiom is to put the header files into
include, the static libraries intoliband the dynamic libraries intobinsubdirectories for your compiled library.The reason you have found that most C++ libraries are provided in source code form and not in precompiled form is that every C++ compiler has a certain freedom as to how to mangle symbol names etc and the resulting object code isn't portable across compilers, let alone operating systems. So shipping the compiled code doesn't make sense for a lot of applications. You'll occasionally find it with closed-source C++ libraries on Windows (C libraries are an entirely different matter), but then the vendor will have to provide a compiled version for each and every build type (Release, Debug, 32 bit, 64 bit etc) and target compiler (various versions of Visual Studio require different binaries, then there is Borland and a bunch of other compilers) and it quickly becomes a nightmare to support...
When you take a library and build it as a dynamic library on Windows (ie, a DLL), the compiler/linker will normally generate a static 'import' library for it (same name, just with a .lib extension). When you link your project against the dynamic library, you specify the .lib file as a library dependency. Linking your application against said import library allows the linker to record the dependency on the .dll file and also which symbols it should expect the library to provide.
Making them work - in the sense of your program finding them on Windows - usually requires that the .dll file is either in the same directory as the executable or accessible via the 'PATH' environment variable and its equivalent in Visual C++.