Hartmut Kaiser wrote:
[...] I initially had the same idea. But unfortunately your assumption is not correct, as BOOST_WAVE_STRINGTYPE normally is defined as some flex_string<...> type (see the mangled names refer to flex_string as well).
You are right, of course. I've compiled instantiate_re2c_lexer.cpp with -source_listing and confirmed that BOOST_WAVE_STRINGTYPE is defined as flex_string (and that flex_string is not defined as std::string). The templates in two modules are instantiated on std::string::iterator and flex_string::iterator, respectively, and it seems to me, that the problem has something to do with fact, that underlying type for both std::string::iterator and flex_string::iterator is 'char*'. The problem is reproducible with: template struct boost::wave::cpplexer::new_lexer_gen<char*>; template struct boost::wave::cpplexer::new_lexer_gen<const char*>; instead of: template struct boost::wave::cpplexer::new_lexer_gen<std::string::iterator>; template struct boost::wave::cpplexer::new_lexer_gen<std::string::const_iterator>; but goes away with, for example, 'unsigned char*' instead of 'char*'.
I will add some safe guards to avoid this situation, though.
I don't know if this is a problem on both Tru64 and AlphaVMS, (the latter has the same compiler and STL that Tru64 and is also a non-comdat platform), but if you're planning to conditionalize the code to "avoid this situation", the condition that would work on both Tru64 and AlphaVMS is: #if defined(__DECCXX) && defined(__alpha)
Still not sure, what's going on here. I'm pretty sure I have not even touched these template instantiations for years.
This, of course, is the most interesting question: how it used to work and what change has triggered this problem. Thanks, Boris ----- Original Message ----- From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, January 24, 2007 10:30 AM Subject: Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0
Boris,
Hartmut Kaiser wrote:
Ok. But in this case the names are not 'original'. They come from manual template instatiations.
I, obviously, don't know all the details, but it seems to me that the problem has to do with manual instantiations in instantiate_re2c_lexer.cpp and instantiate_re2c_lexer_str.cpp modules:
instantiate_re2c_lexer.cpp: --------------------------- template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::iterator>; template struct boost::wave::cpplexer::new_lexer_gen< BOOST_WAVE_STRINGTYPE::const_iterator>;
instantiate_re2c_lexer_str.cpp: ------------------------------- template struct boost::wave::cpplexer::new_lexer_gen<std::string::iterator>; template struct boost::wave::cpplexer::new_lexer_gen<std::string::const_iterator>;
Assuming that BOOST_WAVE_STRINGTYPE evaluates to std::string, it results in two identical instantiations. It is OK on a platform supporting comdats, but Tru64 (and AlphaVMS for that matter) can deal with it only in local template instantiation mode. Follows an example.
Thanks for looking into this. I initially had the same idea. But unfortunately your assumption is not correct, as BOOST_WAVE_STRINGTYPE normally is defined as some flex_string<...> type (see the mangled names refer to flex_string as well). I will add some safe guards to avoid this situation, though.
Still not sure, what's going on here. I'm pretty sure I have not even touched these template instantiations for years. Regards Hartmut
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost