Overloaded =


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 11 of 11

Thread: Overloaded =

  1. #1
    Join Date
    Dec 2003
    Posts
    3,366

    Overloaded =

    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.

  2. #2
    Join Date
    Nov 2003
    Posts
    4,118
    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.
    Danny Kalev

  3. #3
    Join Date
    Dec 2003
    Posts
    3,366
    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.

  4. #4
    Join Date
    Dec 2003
    Posts
    3,366
    default smiles are on again... you might want to poke at that again Danny.

  5. #5
    Join Date
    Nov 2003
    Posts
    4,118
    I don't see any default simles on my client. Where do you see them?
    Danny Kalev

  6. #6
    Join Date
    Nov 2003
    Posts
    4,118
    Quote Originally Posted by jonnin
    Code:
    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

    Code:
    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:
    Code:
    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.
    Danny Kalev

  7. #7
    Join Date
    Dec 2003
    Posts
    3,366
    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?

  8. #8
    Join Date
    Nov 2003
    Posts
    4,118
    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.
    Last edited by Danny; 10-26-2005 at 09:27 AM.
    Danny Kalev

  9. #9
    Join Date
    Nov 2003
    Posts
    4,118
    Quote Originally Posted by jonnin
    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.
    Danny Kalev

  10. #10
    Join Date
    Dec 2003
    Posts
    3,366
    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.

  11. #11
    Join Date
    Dec 2003
    Posts
    3,366
    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...

Similar Threads

  1. Is C# more powerful than VB .NET?
    By Carl in forum .NET
    Replies: 33
    Last Post: 08-05-2002, 06:08 PM
  2. Replies: 1
    Last Post: 06-13-2002, 02:52 PM
  3. Replies: 18
    Last Post: 11-09-2001, 01:07 PM
  4. VB.NET is a disaster!
    By John Franco in forum .NET
    Replies: 59
    Last Post: 09-23-2001, 01:48 PM
  5. How To Do It - Shared Class Variables Part IV
    By Patrick Ireland in forum .NET
    Replies: 3
    Last Post: 05-07-2001, 03:04 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center