Hi,
here is another exasperating patch:
If I compile the following code with MSVC (taken from number.h, I only
added the extra qualification cln:: to illustrate the problem)
namespace cln {
inline _class_::_class_ (const unsigned long wert)
{
extern cl_private_thing cl_I_constructor_from_UL (uint32 wert);
pointer = cln::cl_I_constructor_from_UL(wert);
}
}
then I get the following error:
./include\cln/number.h(230) : error C2039: 'cl_I_constructor_from_UL' :
is not a member of 'cln'
and of course without the cln:: qualification I get linker errors for
unresolved symbols because in cl_I_from_UL.cc the function is clearly
defined inside the cln namespace.
If I change the code to
namespace cln {
extern cl_private_thing cl_I_constructor_from_UL (uint32 wert);
inline _class_::_class_ (const unsigned long wert)
{
pointer = cln::cl_I_constructor_from_UL(wert);
}
the errors disappear.
I know that it is not desirable to move the extern declaration outside
of the function body. But for MSVC this appears to be the only way to
force the compiler to put it into the cln namespace. Therefore I would
propose the following patch for MSVC only:
// At the beginning of the file
#ifdef _MSC_VER
namespace cln {
extern cl_private_thing cl_I_constructor_from_UL (uint32 wert);
}
#endif
and the extra cln:: qualification as shown above.
This is the solution with the smallest changes. But of course it would
also be possible to create two versions of the inline functions and
choose the right one with _MSC_VER.
Please give me your opinions before I start any big edits.
Thanks,
Jan