-4
#include <iostream>
#include <math.h>
#include <conio.h>

using namespace std;


class hugeint 
{
public:
    int size;
    int number[100];


    friend istream& operator>>(istream&,hugeint&);
    friend ostream& operator<<(ostream&,hugeint&);
};


istream& operator>>(istream& in,hugeint& c)
{
    // code not shown
    return in;
}


ostream& operator<<(ostream& out,hugeint& c)
{
    return out;
}


void main()
{
    system( "color 70" ); 

    hugeint o;
    hugeint y;
    hugeint z;

    cin >> o;
    cout<<"now y "<<endl;
    cin>>y;
}

The compiler complains that operator >> is ambigious... what should I do ?

dyp
  • 38,334
  • 13
  • 112
  • 177

2 Answers2

1

Nope, the code compiles.

However please note that I did also remove your extraneous and non-C++ headers, and fixed your incorrect main return type.

Community
  • 1
  • 1
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • Please note that the friend lookup rules were changed in C++11, so it may fail to compile on a C++03 compiler. – Puppy Jul 18 '13 at 14:22
  • @DeadMG: That ideone.com post is running in C++03 mode. [Here's an example with GCC 4.3.2](http://ideone.com/uMTirh). [Here's an example in C++11 mode](http://ideone.com/gJ7ELq). It's valid, valid, valid! – Lightness Races in Orbit Jul 18 '13 at 14:23
  • 1
    @DeadMG What do you mean with "friend lookup rules"? In both C++03 and C++11, [namespace.memdef]/3 "If a friend declaration in a non-local class first declares a class or function the friend class or function is a member of the innermost enclosing namespace." Do you refer to operator overload resolution? – dyp Jul 18 '13 at 14:29
-1

Try putting the operator<< and operator>> functions in the std namespace

rabensky
  • 2,864
  • 13
  • 18
  • **No, please don't.** There's already been an answer like this one (has been deleted by the poster). First of all, **it is not allowed to put overloads in namespace `std`**. Second, there is no problem with operator overloading in the OP's code (see Lightness' answer). Unqualified name lookup and ADL will happily find this global `operator >>`, no ambiguities exist. – dyp Jul 18 '13 at 19:21
  • @DyP - Hmm, well I have seen cases where putting the `operator<<` in `namespace std` was the only solution. Specifically, if OP's class was in its own namespace, `operator<<` has to be in one of the namespaces. And if you want to add an `operator<<` to, e.g. `std::vector`, IIRC you HAVE to put it in `namespace std`. (g++ doesn't follow the standard, so it also looks for it in global namespace, but clang++ follows the standard so it doesn't) – rabensky Jul 18 '13 at 20:51
  • Putting `operator<<` in `namespace std` is no solution IMO -- it's just not allowed. The only case I know of that is problematic is the one you mentioned with the example of `std::vector`, namely, if both arguments of a binary operator are of types of namespace `std`. Because there are some `operator >>` functions in that namespace, argument-dependent lookup will stop and overload resolution begins, not finding any global `operator >>`. A workaround for this is to wrap the `std::vector` in a wrapper type of an own namespace. – dyp Jul 18 '13 at 21:48
  • See [my question on this topic](http://stackoverflow.com/questions/16548379/dependent-name-resolution-namespace-std-standard-library), including Andy Prowl's answer and the workaround. And that's not even a problem in this particular case, as the call doesn't come from inside namespace `std`. – dyp Jul 18 '13 at 21:53
  • The wrapper workaround doesn't work if you have a template function that prints (operator<<) arguments as well as uses them (unless you suggest I have to completely "rewrite" any stl class I want to use with this template). You keep saying that "it is not allowed to put overloads in std", and I'd like some reference to this as I've never heard it - there is a lot of overloading in std already, and we add to them at work when needed. If there is a good reason not to do so I'd like to know to see if we can do something else instead. – rabensky Jul 18 '13 at 22:04
  • 1
    You could wrap the whole `vector`, too, in something similar to `std::ref`, but in your own / global namespace (this doesn't solve everything, though). As for the reference: [namespace.std]/1 "The behavior of a C ++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified." – dyp Jul 18 '13 at 22:31
  • 1
    Ok then. Thanks a lot! I guess I have some work to do come Monday :) I also understand better why this is so: If two different people implement `operator<<` for `vector`, you get conflicting definitions you can't fix with a namespace. Cheers! – rabensky Jul 19 '13 at 00:45