[program_options] cw9.3 failures

The current regression test results show two similar failures of program_options on cw9.3 http://tinyurl.com/6ay5m The situation is the following: parsers.hpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>&, const options_description&); parsers.cpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>& is, const options_description& desc) { ........ } template BOOST_PROGRAM_OPTIONS_DECL basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc); And the linker can't find the explicitly instantinated function. This happens only in _dll tests, so I'd suspect a bug in the compiler/linker. Can anybody sched the light on this? Thanks, Volodya

On Sep 24, 2004, at 8:11 AM, Vladimir Prus wrote:
The current regression test results show two similar failures of program_options on cw9.3
The situation is the following:
parsers.hpp contain:
template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>&, const options_description&);
parsers.cpp contain:
template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>& is, const options_description& desc) { ........ }
template BOOST_PROGRAM_OPTIONS_DECL basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc);
And the linker can't find the explicitly instantinated function. This happens only in _dll tests, so I'd suspect a bug in the compiler/linker.
Can anybody sched the light on this?
How are clients (who can view only parsers.hpp) to know that: template<> basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc); is a function to be imported from a DLL? Does adding to parsers.hpp something like: template<> __declspec(dllimport) basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc); help? -Howard

Howard Hinnant wrote:
parsers.hpp contain:
template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>&, const options_description&);
parsers.cpp contain: ...... template BOOST_PROGRAM_OPTIONS_DECL basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc);
And the linker can't find the explicitly instantinated function. This happens only in _dll tests, so I'd suspect a bug in the compiler/linker.
Can anybody sched the light on this?
How are clients (who can view only parsers.hpp) to know that:
template<> basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc);
is a function to be imported from a DLL?
I don't know ;-) Somehow, msvc and borland don't care much.
Does adding to parsers.hpp something like:
template<> __declspec(dllimport) basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc);
help?
I don't think I can do this. That's explicit specialization, and and I've be required to provide the definition for it, and for wchar_t as well, no? This means I'd have to provide two identical definitions for char and wchar_t specializations? Or use an internal function that each specialization will call? This does not sound right, I only want to explicit instnantiate the function. And I think there's no way to "forward declare" an explicit instantiation. What do you think? In the meantime, I'll try adding declspec to the primary template definition. - Volodya

Vladimir Prus wrote:
Howard Hinnant wrote:
parsers.hpp contain:
template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>&, const options_description&);
parsers.cpp contain: ...... template BOOST_PROGRAM_OPTIONS_DECL basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc);
And the linker can't find the explicitly instantinated function. This happens only in _dll tests, so I'd suspect a bug in the compiler/linker. ...... In the meantime, I'll try adding declspec to the primary template definition.
And that fixed the problem... though Intel is now unhappy, saying that declspec on template function declaration is not OK. Howard, could you clarify if requiring declspec is a bug in Metroweks, given that VC7.1 works without it, or result of a somewhat different DLL handling -- which can't be changed? - Volodya

On Sep 27, 2004, at 2:37 AM, Vladimir Prus wrote:
Howard, could you clarify if requiring declspec is a bug in Metroweks, given that VC7.1 works without it, or result of a somewhat different DLL handling -- which can't be changed?
It is difficult to say. There are no standard rules for DLL handling, and behavior varies not only from compiler to compiler, but also from OS to OS. The C++ committee is attempting to address this situation, so there is hope that the future will be brighter. For now I recommend the generous use of #ifdef . ;-( -Howard
participants (2)
-
Howard Hinnant
-
Vladimir Prus