"Gennadiy Rozental" <gennadiy.rozental@thomson.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:m2d5e05btv.fsf@coppi.local...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> 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