Bizarre problem with range/adaptor/transformed.hpp
I've traced a problem in my program to the inclusion of #include "boost/range/adaptor/transformed.hpp" Nothing is using the features in it (such things are removed from the test case build I'm using to get to the bottom of it). It compiles just as well with or without the line. But if the file is included, the program is broken. If I omit it, then the program works fine. Any suggestions would be welcome.
On 7/30/2011 6:52 PM, Nathan Ridge wrote:
But if the file is included, the program is broken.
Could you be a *little* more specific?
Regards, Nate
I posted the initial findings before investigating further, in case someone already knew of some feature of that particular include file that was known to be problematic, or a hint for me to look at. Now I've determined that it's the existence of the 'transformed' variable. Just this much: template< template<class> class Holder > struct forwarderXYZ { }; template< class T > struct transform_holderXYZ { }; static const forwarderXYZ<transform_holderXYZ> transformedXYZ = forwarderXYZ<transform_holderXYZ>(); added to my header file will cause the program to malfunction in one specific feature. —John
On 7/31/2011 5:40 PM, Nathan Ridge wrote:
will cause the program to malfunction in one specific feature.
Again, could you be more specific? How can you possibly expect anyone to guess what the problem might be without knowing how your program "malfunctions"?
Regards, Nate.
Again, I was just giving a shout to see if the community already knew of something odd or problematic within that header.
On 07/31/2011 02:00 PM, John M. Dlugosz wrote:
Just this much:
template< template<class> class Holder > struct forwarderXYZ { };
template< class T > struct transform_holderXYZ { };
static const forwarderXYZ<transform_holderXYZ> transformedXYZ = forwarderXYZ<transform_holderXYZ>();
It might be a good idea to make those PODs to avoid dynamic initialization.
On 8/1/2011 3:29 AM, Mathias Gaunard wrote:
It might be a good idea to make those PODs to avoid dynamic initialization.
They are empty, so are POD. The syntax used appears to force the compiler to use dynamic initialization anyway; in an optimized build I suppose it might be removed completely. But in debug build I noticed that it is allocated in the section with dynamically initialized objects, takes 1 byte (plus padding), and the constructor for the variable fills the padding with CC's and the single dummy byte with 0. It would indeed be nicer if the required dummy byte was initialized at compile time only, bringing the zero in with the program image, and didn't need to call a (empty) function to construct. Is there some reason why the author didn't use const forwarderXYZ<transform_holderXYZ> transformedXYZ; with default initialization? —John
participants (3)
-
John M. Dlugosz -
Mathias Gaunard -
Nathan Ridge