Re: [boost] [wave] Recent check-ins broke wave onTru64/CXX/RC_1_34_0

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2007-01-24 20:19:13

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_at_[hidden]>
To: <boost_at_[hidden]>
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
>
>