minor adl fixes in kdevplatform

[floris]

On Thu, 2010-12-30 at 22:00 -0300, Nicolás Alvarez wrote:
> On 30/12/2010, Milian Wolff <mail at milianw.de> wrote:
> > Nicolás Alvarez, 30.12.2010:
> >> On 30/12/2010, floris <flo.ruijt at hotmail.com> wrote:
> >> > here's two classe which have a qHash in the global namespace. that isn't
> >> > correct. they should be in the same namespace as the class to make adl
> >> > work. I think PovAddict has a similar patch, but he hasn't responded on
> >> > irc to me.
> >> >
> >> > Floris
> >>
> >> I'll commit this now.
> >
> > you still didn't proof that this is what is required.
> >
> > I still find this very strange.
> 
> Just try compiling KDevelop 4.2 0c0f4332aa or later, against
> KDevPlatform 1.2 687ae6b804 or older (just make sure 9fd32f1b18 isn't
> there, which is the qHash ADL patch).
> 
> 
> /usr/include/qt4/QtCore/qhash.h: In member function ‘QHashNode<Key,
> T>** QHash<Key, T>::findNode(const Key&, uint*) const [with Key =
> KDevelop::RangeInRevision, T = QHashDummyValue]’:
> /usr/include/qt4/QtCore/qhash.h:752:   instantiated from ‘QHash<Key,
> T>::iterator QHash<Key, T>::insert(const Key&, const T&) [with Key =
> KDevelop::RangeInRevision, T = QHashDummyValue]’
> /usr/include/qt4/QtCore/qset.h:176:   instantiated from
> ‘QSet<T>::const_iterator QSet<T>::insert(const T&) [with T =
> KDevelop::RangeInRevision]’
> ./kdevelop42/projectmanagers/cmake/tests/cmakeduchaintest.cpp:280:
> instantiated from here
> /usr/include/qt4/QtCore/qhash.h:875: error: no matching function for
> call to ‘qHash(const KDevelop::RangeInRevision&)’
> 
> I agree that it's strange, though.
> 
> -- 
> Nicolas
> 
I too find it strange, but I remember having read the boost-hash stuff
quite some time ago, it made a few remarks about adl and why the hash
should be in the same namespace as the class iirc. I couldn't find the
appropriate paragraph in the standard though. 
i think the logic should be that it looks first in the 'home' namespace
of the class and if it finds any function with the correct name there,
it stops, else it should check the enclosing namespace of the call.



<don't read if bored>
anyway i had something similar a while ago in a private project:
bool collide (t_obj_1 o1, t_obj_2 o2);

struct t_obj_1{
void collide(t_obj_3);
void func(t_obj_2 o2){
if(collide(*this,o2)){} //FAILS!!!!
}
};

the call fails because a member-function has been found which has been
found at which point the compiler won't look outside this
"namespace"(struct), making it fail to find the two parameter func...
also a few of my favorites: 

boost::bind( overloaded_func, all,the,params);
//trying to take address of unresolved overloaded function-type

for(std::vector<T>::iterator i=vec.begin/*NO ()*/; ...
//trying to convert overloaded functiontype to non-scalar gnu_cxx::....

that last one really made me cringe since begin ìs overloaded but only
on constness of *this so i was really puzzled at first(thinking the
error was in the next line). 
</don't read if bored>