-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uncompile-able results due to namespacing #236
Comments
I'll add this bug to the known bugs PR: #229 |
Hi @lyskov, 7b47e78 causes a new issue for me. If I add the following to
, test compilation fails:
Even though this is perfectly ok C++ code. E.g. run this minimal example:
|
Revert "using fully qualified insertion operator name when binding `__str__` (fixing RosettaCommons#236)" This reverts commit 7b47e78.
@hogabrie ah, - i had encounter this or very similar issue before, it became particularly obvious when class and friend function is templated (issue is not specific to operator<<). Solution that i used is to separate declaration of function from it definition. It is a bit verbose but so far this is the only solution that seems to work. Please try following example, it have worked for me: namespace aaaa {
struct T
{
friend std::ostream & operator<<(std::ostream & s, T const &);
};
inline std::ostream & operator<<(std::ostream & s, T const &) { return s << "hi..."; }
} |
Thank you @lyskov for the quick support and the amazing binder project. For now I reverted the commit in our fork. When I find the time I will adapt our huge templated library with this proposal to get the bindings working with the latest binder version. |
TLDR:
binder
sees the stream operator<<
in some namespace,B
, then tries to define__str__
using<<
without referencingB
.Consider:
Where
a.conf
is just+class A
. We end up withIf you try to compile this, it will fail because
<<
will not be in scope, since the<<
operator was defined in the namespaceB
.Possible solution: Change binder to be explicit with
A::operator<<(s, o)
(I like this idea; it is ugly, but this code is autogenerated so that's fine). One other benefit is this would make it clear which<<
operator is being called in the case that multiple are defined at different scopes.The text was updated successfully, but these errors were encountered: