In practice, the difference is in the location where the preprocessor searches for the included file.
For #include <filename>
the preprocessor searches in an implementation dependent manner, normally in search directories pre-designated by the compiler/IDE. This method is normally used to include standard library header files.
For #include "filename"
the preprocessor searches first in the same directory as the file containing the directive, and then follows the search path used for the #include <filename>
form. This method is normally used to include programmer-defined header files.
A more complete description is available in the GCC documentation on search paths.
Setting a bit
Use the bitwise OR operator (|
) to set a bit.
number |= 1UL << n;
That will set the n
th bit of number
. n
should be zero, if you want to set the 1
st bit and so on upto n-1
, if you want to set the n
th 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 n
th 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 n
th 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 n
th bit of number
into the variable bit
.
Changing the nth bit to x
Setting the n
th 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 n
th bit and (x << n)
will set the n
th 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.
Best Answer
Assuming you're coding these in two different libraries static or dynamic (DLLs on windows shared libraries on Linux and other *nix variants) The biggest concerns I have are as follows:
They are compiled with the same compiler. While this isn't necessary if all C++ exports are exported with a C-style naming convention it is necessary for C++ to C++ calls to class instances between the two C++ modules. This is necessary due to how different compilers mangle C++ exports differently.
Do not cast a C++ class as a C struct. They aren't the same under the covers, even if the layout of fields are the same. C++ classes have a "v-table" if they have any virtual members; this v-table allows the proper calling of inherited or base class methods.
This is true of C to C or C++ to C++ as well as C to C++. Ensure both use the same byte alignment for the output library. You can only determine this by reading your compiler or development environments documentation.
Don't mix malloc/free with new/delete. More specifically don't allocate memory with new and free memory with "free" and vice versa. Many compilers and operating systems handle memory management differently between the two.
Passing function pointers: So long as they are exposed to/from C++ as ''extern "C"'' this should be fine. (You'll either need to reference your compilers documentation on how to determine when a header is being compiled as C or C++ to maintain this in one file, or you will need two separate copies of the same function declaration in each project -- I recommend the first)
Passing doubles: This is a built-in type in both C and C++ and should be handled the same.
If you must share an instance of a C++ object with a C function, and act on it from within C code, expose a set of C-exported helper functions which call the appropriate methods on the C++ object. Pure C code cannot properly call methods on C++ objects.