Re: [boost] [test] retrieve_framework_parameter

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-27 22:43:29

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message 
> news:m2d5e05btv.fsf_at_coppi.local...
>> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
>>
>>>> An ipp file is not typically a translation unit by itself.
>>>
>>> Ignoring technicalliy it is in my case.
>>
>> I don't know what you mean.
>
>
> My TU is
>
> #define BOOST_TEST_SOURCE
> #include <boost/test/impl/unit_test_parameters.ipp>

OK.  Not important.

>>>>  It is included by test_tools.hpp
>>>
>>> It's not. unit_test_parameters.ipp is only included by ":included"
>>> components of Boost.Test.
>>
>> I don't know what that means either.
>
> "included" means here a single header that includes whole
> implementation of Boost.Test component. For example
>
> boost/test/included/unit_test.hpp

Okay.

>>>> which gets included in many of the
>>>> serialization tests...  or at least, it is indirectly included by
>>>> libs/serialization/test/test_exported.cpp, and the only test header I
>>>> can see there is boost/test/test_tools.hpp.
>>
>> So, if not via test_tools.hpp, then how does it end up in that
>> translation unit?
>
> No idea. Maybe you somehow modified sources? Or maybe compiler
> somehow peaks into implementation (I expirienced something similar
> with sunpro compiler).  Though I don't know how is it possible.

Well, looking at the preprocessed sources, I don't see it there.  So I
must've been wrong about that all along.

>>> and I don't have spirit to replicate the error.
>>
>> So download it.  It takes about ten seconds over a fast connection.
>> Or don't, if you don't want to look at this problem.
>
> I don't even know where to look for it.

I gave you the exact command to launch that test.  What more do you
need?

>> But my question remains: why is that function in a header when it
>> could be compiled into the library?  Seems pretty inefficient, at
>> least for Boost, which runs many many tests using your library, to
>> compile that function body over and over.
>
> IT'S NOT. Why are you so sure it's my problem?

W.R.T. the above paragraph, I'm sorry.  I must've mis-analyzed the
situation.  I don't think the crash is your problem exactly; it's
surely a codegen bug.  However, I believe it's in your power to work
around the bug.

> Gennadiy
>
> P.S. I do have an access to borland 5.6.4. And I do not have any
> problems compiling with it.

The only compile-time problem here is in the compiler.  You can only
experience that problem at runtime :)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com