Overloaded =

[jonnin]

I have a simple scaled integer class that overloads the = operator for double and uint64_t. It works fine under visual studio, defaulting to the integer if you do not cast each call, which is not optimal burden free usage but we live with it. If you assign it an integer it computes the related double and if you assign it a double it computes the scaled integer. Simple, easy to use class.

BUT

g++ will not have anything to do with the code. It says the overloaded operators are ambigious. What can I do here to minimize the changes to the code and have it work? Our usage requires both directions -- Basically, we set the max/min/bits/signed of the specific piece of data once, and from then on if we recieve it we convert to double and use, if we send it we convert from double to scaled int and send it out. It would be *nice* to retain the simple syntax of the operator, of course if nothing else will do I can make it a function instead.

[Danny]

I ned to see the actual prototypes of these operators and which compilation error you get with g++. Notice that __uint64 isn't a standard type so there's a bit of controversy among compilers about it. On teh one hand, it isn't a built-in type (officially at least) but on the other hand, it isn't a user-defined type either so compilers may disagree about it.

[jonnin]

void ScaledInt_t::operator =(double dAsgn);
void ScaledInt_t::operator =(int64_t i64Asgn);

Note that visual studio has __int64 mapped to the 64 bit int and g++ is using long long or unsigned long long. I dont think thats the problem so much as both are built in numerical types that can be converted one to another. I want it to know

x = 10.0; is different from
x = 10;

Both cygwin (3.3.3) and fedora (4.0.bignumberofquestionableorigin) do the same thing:
ambigious operatior overloaded possible candidates ...

Probably does not have to be 64 bits. Thats the max size defined in a spec that proceeds to not use ANY 64 bit variables... but we are sticking to spec as best we can.

[jonnin]

default smiles are on again... you might want to poke at that again Danny.

[Danny]

I don't see any default simles on my client. Where do you see them?

[Danny]

void ScaledInt_t::operator =(double dAsgn);
void ScaledInt_t::operator =(int64_t i64Asgn);

Note that visual studio has __int64 mapped to the 64 bit int and g++ is using long long or unsigned long long. I dont think thats the problem so much as both are built in numerical types that can be converted one to another. I want it to know

x = 10.0; is different from
x = 10;

Both cygwin (3.3.3) and fedora (4.0.bignumberofquestionableorigin) do the same thing:
ambigious operatior overloaded possible candidates ...

Probably does not have to be 64 bits. Thats the max size defined in a spec that proceeds to not use ANY 64 bit variables... but we are sticking to spec as best we can.

OK, here lies the problem:

x = 10.0; is different from
x = 10;

when you do something like x=10, there a conversion of 10 is required because its of type int. int is neither double nor int_64, but the compiler has no priorities in this case becuase int_64 isn't defined as an integral type, just a numeric type (I guess). So the compiler has to choose between two viable candiates of conversion, and this ambguity causes the error. To solve this, you probably need to decorate the literal 10 with: 10i64 or 10LL, or 10ULL, so that its type becomes int_64 and therefore, no conversion will be required. The problem is that VC++ and G++ disagree about these affixes. g++ probably accepts LL and ULL, whereas VC++ doesn't.

[jonnin]

There are no literals in the code actually, I checked it again. Its all

x = (uint64_t) variable; or
x = (double) variable;

I added a cast to every usage to convince .net to use the correct one. g++ simply wont take it so far.

I had tried at one point to create a suffix macro to convert .net's suffix to ull but it just cannot be done, so even my constants are shoved into 'variables' before usage.

Any other hints or should I just make it a pair of functions?

[Danny]

How is variable declared? If the operand and the matching overloaded operators have precisely the same type, there should be no ambiguity. Troubles start when the operand needs to be converted implicitly. In any case, you need a pair of functions.

[Danny]

default smiles are on again... you might want to poke at that again Danny.

Here's the deal: when the code isn't wrapped in a pair of tags, similies are on because vBulletin assumes that it's plain text. In code blocks, smilies are off. We can turn them off completely but some people do expect similies to work in their messages. If you find this annoying, I will turn them off completely, leaving only the choice of embedding explicit emoticons in the text.

[jonnin]

I can deal either way on those smilies, just noticed it zapped some code I pasted and mentioned it. Knowing HOW it works helps =)

Variable is often of smaller types -- even down to char. I am going to create the assignments for all int/float types and if that does not work I will just pull the operators out and make a pair of safe functions.

[jonnin]

I got it -- it was a signed vs unsigned issue. M$ does not care because they only support signed 64's while linux determined there was a problem.

Thanks again -- its done now, only 2 small issues, a few headers with uppercase/lowercase problems, and had to re-write my sockets from winsock to bsd ones (pretty easy actually). A nice port all in all...