Hi,

Should I put the operator<<() for my class (which is in a namespace) in
the namespace or make it global? If I understand the lookup rules
correctly:

If I make it global, it may be hidden if called from within a different
namespace and that other namespace has any operator<<() defined. That
doesn't seem good.

If I put it in the namespace, then it may hide calls to other
operator<<() definitions that are for classes in a different namespace
with operator<<() definitions defined at the global scope. That
doesn't seem good either.

It seems that all the code within a program must all make the same
choice for unadulterated access to all operator<<() definitions. That
can be done when all the code is within one's control but what about
when working with code from multiple sources? Or, contributing a
library to a multi-sourced program?

Thanks for any advice. I could not find a definitive "best practice"
anywhere.

Ryan

///// some code to make the above clearer

namespace my_ns {
class mine { ... };
ostream& operator<<(ostream& os, const mine& obj); // option #1
}
ostream& operator<<(ostream& os, const my_ns::mine& obj); // option
#2

namespace other_ns {
class other { ... };
ostream& operator<<(ostream& os, const other& obj);

void func() { my_ns::mine o; std::cout << o; } // fails w/
option #2
}

namespace another_ns {
class another { ... };
}
ostream& operator<<(ostream& os, const another_ns::another&);

namespace my_ns {
void another_func() { another_ns::another a; std::cout << a; } //
fails w/ option #1
}

ryan_melville@xiotech.com wrote:

Hi,
>
Should I put the operator<<() for my class (which is in a namespace) in
the namespace or make it global? If I understand the lookup rules
correctly:
>
If I make it global, it may be hidden if called from within a different
namespace and that other namespace has any operator<<() defined. That
doesn't seem good.
>
If I put it in the namespace, then it may hide calls to other
operator<<() definitions that are for classes in a different namespace
with operator<<() definitions defined at the global scope. That
doesn't seem good either.
>
It seems that all the code within a program must all make the same
choice for unadulterated access to all operator<<() definitions. That
can be done when all the code is within one's control but what about
when working with code from multiple sources? Or, contributing a
library to a multi-sourced program?
>
Thanks for any advice. I could not find a definitive "best practice"
anywhere.
>
Ryan
>
///// some code to make the above clearer
>
namespace my_ns {
class mine { ... };
ostream& operator<<(ostream& os, const mine& obj); // option #1
}
ostream& operator<<(ostream& os, const my_ns::mine& obj); // option
#2
>
namespace other_ns {
class other { ... };
ostream& operator<<(ostream& os, const other& obj);
>
void func() { my_ns::mine o; std::cout << o; } // fails w/
option #2
}
>
namespace another_ns {
class another { ... };
}
ostream& operator<<(ostream& os, const another_ns::another&);
>
namespace my_ns {
void another_func() { another_ns::another a; std::cout << a; } //
fails w/ option #1
}
>

Scott Meyers has an article about something similar in Dr. Dobbs, "How
Non-Member Functions Improve Encapsulation"...

http://www.ddj.com/dept/cpp/184401197

Jeremy Brown wrote:

>
Scott Meyers has an article about something similar in Dr. Dobbs, "How
Non-Member Functions Improve Encapsulation"...
>
http://www.ddj.com/dept/cpp/184401197

Thank you for the reply, but I don't think that article addresses the
primary issue. That article seems to focus on friend/global/member
organization for functions and not on how koenig lookup affects the
choice to make operator<<() (or similar) global or within the namespace
of the class on which it operates.

I believe I have already correctly concluded that operator<<() should
not be a method of the class nor a friend unless necessary for its
implementation.

Regards,

Ryan