------- Comment #4 from lfn dot privat at mail dot dk 2009-04-03 09:41 -------
Thanks for clarifying how the compiler works. Actually this was the kind of
answer detail level I was looking for in the first place to find some kind of
work around to the problem.
Now, I assume that your answer implies that your described compiler behaviour
is C++ standard compliant - is this a correct assumption ?
I think many developers will find it easier to understand if the compiler
delayed resolution of overloads until point of use/instantiation - in this case
in the main() function. The understanding here is that the compiler should have
the following picture when compiling main():
struct MyType
{
int i;
};
namespace ReadSpace
{
static inline bool Read( const char* Str, int& v );
template< class T >
static inline bool Read( const char* Str, std::vector< T >& v );
static inline bool Read( const char* Str, MyType& v );
}
using namespace ReadSpace;
int main() // Should have all the bricks to resolve intended use ...
{
std::vector< MyType > v;
...
It appears that the compilers you refer to as broken has this picture and are
able to offer much more flexibility (maybe more than the standard states I
presume you will claim).
By the way, it is interesting that the given example works for 'int' as 'int'
is also in the global namespace (or is it implicit in any namespace ?). If you
replace ...
int main()
{
std::vector< MyType > v;
... with ...
int main()
{
std::vector< int > v;
... the example compiles. But there is a catch here. If you move the Read( int&
) overload AFTER the Read( vector< T> ) in the namespace definition, the
example does NOT compile:
namespace ReadSpace
{
template< class T >
static inline bool Read( const char* Str, std::vector< T >& v )
{
T Help;
if ( !Read( Str, Help ) )
return false;
v.push_back( Help );
return true;
}
// Moved ...
static inline bool Read( const char* Str, int& v )
{ v = 0; return true; }
}
int main()
{
std::vector< int > v; // Does NOT compile ...
// x.cpp:48: error: no matching function for call to
// âRead(const char*&, int&)â
- o -
All in all I think this compiler behaviour makes it much harder to extend
(template) libraries and developers are given much less order-of-definition
flexibility. If it is standard C++ mandated, then we will have to live with
that for now, but if it is not, I still think gcc/g++ may be broken on this
issue.
--
lfn dot privat at mail dot dk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lfn dot privat at mail dot
| |dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36982
