[Format] Asserts with non-default structure packing in 1.37 (MSVC)

I'm using MS Visual Studio 2005 to work on some legacy code that has its origins back in 16-bit Windows, and relies on the /Zp2 switch to align fields in structures in the same way as earlier versions. One of the more recent modules uses boost::format, and this has compiled correctly and been working with Boost 1.34.1. I'm trying to bring the project up-to-date using 1.37, and I am getting BOOST_STATIC_ASSERT reports when I include boost/format.hpp. I don't have to *use* format in my code, just including boost/format.hpp in a "Hello world" program is sufficient to trigger the error when using /Zp2 Is this to be expected? Is there a workaround? I know we should really use explicit pack pragmas around the structures that have to be packed in this particular way, but there are too many of them -- and they're defined all over the code -- for this to be a simple or safe process ... /Zp2 has always worked fine in the past. Cheers, Daniel (Just a user -- not to be confused with the Boost contributor of the same name)

Daniel James wrote:
I'm using MS Visual Studio 2005 to work on some legacy code that has its origins back in 16-bit Windows, and relies on the /Zp2 switch to align fields in structures in the same way as earlier versions.
One of the more recent modules uses boost::format, and this has compiled correctly and been working with Boost 1.34.1. I'm trying to bring the project up-to-date using 1.37, and I am getting BOOST_STATIC_ASSERT reports when I include boost/format.hpp.
I don't have to *use* format in my code, just including boost/format.hpp in a "Hello world" program is sufficient to trigger the error when using /Zp2
Is this to be expected?
Is there a workaround?
It appears to be a bug in MSVC's __alignof builtin operator, if you comment out the line: # define BOOST_ALIGNMENT_OF(T) __alignof(T) In line 108 of boost/type_traits/intrinsics.hpp then it all works as expected (I hope!). The problem is that __alignof(int) reports 4 even when it's actually 2 (because of /Zp2), so it looks as if we'll have to disable use of that particular intrinsic :-( HTH, John.

In article <099818F076834EA28762E7BAB3D97A53@fuji>, John Maddock wrote:
It appears to be a bug in MSVC's __alignof builtin operator ...
Hmm. Looking more closely I think _alignof does what it says on the tin, but that the problem is that /ZPn (and also #pragma pack(n) and __declspec(align(n)) ) only affect the alignment of /structures/ and not of things like int and char. This code, compiled without any /Zp switch: #pragma pack( push, 2 ) int int_2 = 0; struct s2 { int member; }; #pragma pack( pop ) int int_def = 0; struct sdef { int member; }; int __declspec( align(2) ) forced; int main(int argc, char* argv[]) { std::cout << "Alignment of int_2 is " << _alignof( int_2 ) << std::endl; std::cout << "Alignment of int_def is " << _alignof( int_def ) << std::endl; std::cout << "Alignment of s2 is " << _alignof( s2 ) << std::endl; std::cout << "Alignment of sdef is " << _alignof( sdef ) << std::endl; std::cout << "Alignment of forced is " << _alignof( forced ) << std::endl; return 0; } prints out: Alignment of int_2 is 4 Alignment of int_def is 4 Alignment of s2 is 2 Alignment of sdef is 4 Alignment of forced is 4 which appears to indicate that _alignof does correctly report the alignment of 2-byte aligned objects, but that only the alignment of structures can be specified by the user ... not sure how I might verify that, though. Incidentally, the same behaviour is seen in VS 2008.
if you comment out the line:
# define BOOST_ALIGNMENT_OF(T) __alignof(T)
In line 108 of boost/type_traits/intrinsics.hpp then it all works as expected (I hope!).
Thanks, that's looking good so far. Cheers, Daniel.
participants (2)
-
Daniel James
-
John Maddock