views:

82

answers:

3

Hi,

I want to overload the assignment operator for types like "int", "long" etc. That is, I want to use code like:

class CX {
private:
  int data;
...
};

CX obj;
int k;
k = obj;  // k should get the value of obj.data

Apparently assignment operators cannot be friend functions. How do I achieve the above?

I maybe missing something simple but just cant figure out the syntax/method to do this.

Also, one IMP restriction - we CANNOT use get/set methods because :: In release code, we will have CX typedefed as int or long (as required), but in DEBUG code, we want to have it as a class (for automatic type checking in thousands of places). The code needs to be common. Reason is that the compiler (atleast the version we are using) is somehow not able to optimize all the operations if CX is made a class.


One issue is - I dont want this to pass:

CX x; long p; p = x;

I assume the casting solution below will implicitly make the code for long/short etc pass too. (If not, then it is exactly what I am looking for!).

On a related note, answering David's question - the reason I want to refactor is - we want the ability to switch CX to be 32 bit or 64 bit. As such, we want to disallow any implicit conversions and catch them at compile time. Now, the reverse - (disallowiong

CX x = some_64_bit_int;

but allowing

CX x = some_32_bit_int;

I achieved by using a templatized = operator that asserts on compile time by default, but overloading it for my desired type.


In-case you feel this is a bad design or that I should try other alternatives - The reason why I need is this: We have thousands of lines of legacy code, where something is just typedefed to "int".

typedef int CX;

There are assignments all over the place like:

CX x; int k; k = x;    // Writing the simplified relevant code here

I am working on a project to change CX to a class. In the first phase, we want to fix all compilation errors (that come on making CX a class) making as little changes to code as possible.

+7  A: 

You could add a cast operator to your class if the only thing you want is conversion to int.

class ABC
{
public:
    operator int() { return data; } // cast operator
private:
    int data;
...
};
Nikola Smiljanić
Exactly what I was thinking when I read the question. Since int is not a class, you cannot overload it's `operator=()` - but you can approach the problem "from the other side of the '=' sign" as you suggested.
DevSolar
+1 Short and exact.
Valentin Heinitz
Beware: conversions kick in when you want, but they may also kick in when you don't want them to... this should not be a problem in code where `ABC` was originally a typedef to int but it is not a nice solution in the long term.
David Rodríguez - dribeas
@David: Exactly the problem. I dont want the int() cast to pass when someone tries to assin this class to a "long" variable.
JP19
A: 

You can have CX as a class and have Conversion functions in the class for type int. That way your class can work this way

siddhusingh
One issue is - I dont want this to happen: CX x; long p; p = x; I assume this casting will implicitly make the code for long/short etc pass too. On a related note, answering David's question - the reason I want to refactor is - we want the ability to switch CX to be 32 bit or 64 bit. As such, we want to disallow any implicit conversions and catch them at compile time. Now, the reverse - (disallowiong CX x = some_64_bit_int; but allowing CX x = some_32_bit_int; I achieved by overloading = operator for CX, and using a template function that asserts on compile time for all other types).
JP19
Template functions are not considered if a base type conversion can do. I doubt that this template assert will work.
Jan
+1  A: 

You cannot do this. operator=() has to be a member function and cannot be overloaded for int. I see these possibilities:

  • Rely on an implicit conversion operator in your class. I would advice against that. I cannot remember a single time I have done this where I have not regretted and removed it later.
  • Write an explicit member function int get() const {return data;} and call this.
  • Ask yourself why you want to wrap that int in a class, but still want to allow assignment to plain int. That smells.
sbi
One IMP restriction is - we CANNOT use get/set methods because ::In release build, we have CX typedefed as int or long (as required), Reason is that the compiler (atleast the version we are using) is somehow not able to optimize all the operations if CX is made a class. In DEBUG build, we want to have it as a class (for automatic type checking in thousands of places). The code needs to be common.
JP19