Reputation: 7317
I'm trying to write a class that implements 64-bit ints for a compiler that doesn't support long long
, to be used in existing code. Basically, I should be able to have a typedef somewhere that selects whether I want to use long long
or my class, and everything else should compile and work.
So, I obviously need conversion constructors from int
, long
, etc., and the respective conversion operators (casts) to those types. This seems to cause errors with arithmetic operators. With native types, the compiler "knows" that when operator*(int, char)
is called, it should promote the char
to int
and call operator*(int, int)
(rather than casting the int
to char
, for example). In my case it gets confused between the various built-in operators and the ones I created.
It seems to me like if I could flag the conversion operators as explicit somehow, that it would solve the issue, but as far as I can tell the explicit
keyword is only for constructors (and I can't make constructors for built-in types).
So is there any way of marking the casts as explicit? Or am I barking up the wrong tree here and there's another way of solving this? Or maybe I'm just doing something else wrong...
EDIT:
A little clarification on what I want to do: I have a project that uses 64-bit ('long long`) operations in many places, and I am trying to port it to a platform that doesn't have built-in support for 64-bit variables/operations. Even though I have the source for the project, I would really prefer not to have to go over the thousands of places where built-in operators and C-style casts are and change them around.
As for the code itself, the project has the following definitions and kinds of code:
typedef long long i64; // I would like to only have to change this to use my class instead of "long long"
int a;
unsigned b;
int c = ((i64)a*b)>>32;
As for the class implementation, I have the following:
class Long64 {
public:
Long64();
Long64(const Long64&);
Long64(int);
Long64(long);
Long64(unsigned int);
Long64(unsigned long);
operator int() const;
operator long() const;
operator unsigned int() const;
operator unsigned long() const;
friend Long64 operator*(int l, const Long64& r);
friend Long64 operator*(const Long64& l, int r);
friend Long64 operator*(long l, const Long64& r);
friend Long64 operator*(const Long64& l, long r);
}
Upvotes: 4
Views: 1556
Reputation: 4345
To avoid the compiler to be confused, you will help it by defining the combination of your class and the built-in types for all the arithmetic operator. For example for operator+, you will need to define + the unsigned ones
MyClass operator+(char, MyClass const&);
MyClass operator+(MyClass const&, char);
MyClass operator+(short, MyClass const&);
MyClass operator+(MyClass const&,short);
MyClass operator+(MyClass const&,int);
the compiler will prefer overloads that don't need to use conversion operators.
Of course all these methods will use the overload MyClass operator+(MyClass const&,MyClass const&);
by explicitly converting one of the parameters to your class MyClass
MyClass operator+(char c, MyClass const& m) { return MyClass(c)+m;}
This is a little bit cumbersome, I know, but it should avoid the conflicts.
Upvotes: 3
Reputation: 170499
You should create methods with meaningful names instead of conversion operators - like toLongLong()
instead of operator long long()
- this way you will be able to write code that both people and the compiler will easily understand. That's the only reasonable solution when you have so many conversion operators that even the compiler can't get what you want.
Upvotes: 2