The behavior depends on what conversions and operator overloads are defined for these types of objects.
To simplify the discussion, let’s say that the objects you’re talking about are instances of class X. According to the C++ standard, bitwise operators will only work with “integral or unscoped enumeration operands.” For simplicity, we’ll just say that the operand(s) of a bitwise operator must be of integral type.
If class X doesn’t define an implicit user-defined conversion of the object into an integral type, and X doesn’t overload the bitwise operator you’re attempting to use, and no other function outside of X (inside another class or outside of any class) overloads that bitwise operator for X, then use of that bitwise operator on your object(s) will result in a compilation error. The errors vary across implementations, but it would likely be something like “no operator matches these operands.”
If it makes sense to provide an implicit user-defined conversion of X to an integral type, you can accomplish this in the class X by defining the appropriate conversion member function. For example,
class X
{
public:
// ...
operator int(); // implicit conversion from X to int
// ...
};The implementation of that conversion function would need to return an int that is the integer equivalent value of the X object.
Once X defines an implicit user-defined conversion of X to an integral type, then an expression attempting to use objects of type X as operands to a bitwise operator will cause the compiler to generate code to perform the implicit conversion (by calling the conversion member function, or producing the code inline) before performing the bitwise operation.
If it makes sense to provide an overloaded bitwise operator member function in class X, then the operator can be overloaded to work directly with objects of type X. For example,
class X
{
public:
// ...
X operator^(const X &rhs) const; // overload XOR operator
// ...
};The implementation of that overloaded operator member function would need to perform the desired operation (whatever than may be) between the object pointed to by the this pointer (the object on the left side of the operator) and the object referred to by rhs, returning the result to the caller.
Once X defines an overloaded bitwise operator like this, then an expression attempting to use objects of type X as operands to this operator will cause the compiler to generate code to perform the operation by calling (or inlining) the matching overloaded operator member function.
If it makes sense to provide an overloaded bitwise operator member function outside of class X, the operator can be overloaded to work directly with objects of type X. For example,
// outside of any class
X operator^(const X &lhs, const X &rhs); // overload XOR for X operands
The implementation of that overloaded operator function would need to perform the desired operation (whatever than may be) between the object referred to by lhs and the object referred to by rhs, returning the result to the caller.
Once the operator is overloaded like this, then an expression attempting to use objects of type X as operands to this operator will cause the compiler to generate code to perform the operation by calling (or inlining) the matching overloaded operator function.
The operators could be overloaded to work with operands of mixed types as well, where one operand is of type X, either inside or outside of a class.
In answer your “what would happen” question, the behavior depends completely on what the defined conversion and/or overloaded operator functions actually do.
Notice the repeated introductory phrase “if it makes sense.” All of these things can be done, but the real question is whether they should be done. Provide implicit conversions and overloaded operators only if it makes sense for the data type you’re defining, and only if it enhances the usability of the data type, and the overall readability and maintainability of the code. Conversion functions and overloaded operator functions that do wild, unexpected, astonishing, non-intuitively-obvious things invariably lead to short-term or long-term pain. The Principle of Least Astonishment applies.