[boost] [config] [atomic] Problem with placement of BOOST_ALIGNMENT - requesting opinions/suggestions

Subject: [boost] [config] [atomic] Problem with placement of BOOST_ALIGNMENT - requesting opinions/suggestions
From: Groke, Paul (paul.groke_at_[hidden])
Date: 2017-02-27 13:31:38

While preparing a pull request for my Boost.Atomic extensions for the
z/OS compiler, I noticed that I have a slight problem there. To get the
code to work on z/OS, I changed the placement of the BOOST_ALIGNMENT
macro in atomic/detail/storage_type.hpp from...

BOOST_ALIGNMENT(16) unsigned char data[Size];

to

unsigned char data[Size] BOOST_ALIGNMENT(16);

...because unfortunately the z compiler doesn't understand the
__attribute__ ((__aligned__(x))) when it's at the beginning of a
variable/data member definition. (For the GNU __attribute__
((__aligned__(x))) the new location is also the only documented
location, although GCC doesn't seem to mind.)

While reviewing my changes I now realized that this won't do, because
BOOST_ALIGNMENT can also be defined as __declspec(align(x)) or
alignas(x), both of which are legal at the beginning but not at the end
of a variable/data member definition.
(I'm not 100% sure about valid positions of alignas (x) - the examples I
can find use alignas (x) at the beginning, but the compilers we
currently use - which include MSVC, GCC and Clang, also seem to accept
it at the end. __declspec(align(x)) definitely is a problem though.)

And now I'm wondering what to do about this.

One way to fix this would obviously be to introduce two additional
macros, e.g. BOOST_ALIGNMENT_DECLSPEC and BOOST_ALIGNMENT_ATTRIBUTE.
Only one of those would then expand to something non-empty, and both
would have to be used in variable definitions. The BOOST_ALIGNMENT macro
would remain as is for type declarations and for compatibility.
The code in storage_type.hpp would then have to be re-written as

BOOST_ALIGNMENT_DECLSPEC(16) unsigned char data[Size] BOOST_ALIGNMENT_ATTRIBUTE(16);

Which of course is very very ugly.

Another option would be a
BOOST_ALIGNED_VARIABLE(alignment, variable_definition)
macro. This would be nice in definitions like

BOOST_ALIGNED_VARIABLE(16, unsigned char data[Size]);

but much less nice in definitions like

BOOST_ALIGNED_VARIABLE(16, some_template<foo BOOST_PP_COMMA bar BOOST_PP_COMMA baz>);

And since not all compilers support variadic macros, this is probably
the best one could do.

The third option I can think of would be to leave things as they are,
which of course would mean that I can't submit my Boost.Atomic
implementation for z/OS... hm.

I realize that making things uglier for a single compiler that almost
nobody uses isn't something many people will cheer for. But then again
I'd really like to have my Boost.Atomic implementation for z/OS in the
official Boost releases :)

So I'm calling out to you for suggestions/opinions/comments. Is there
another way to combine the above mentioned square peg + round hole? And
which option would you deem favorable/acceptable?

Thank you for taking the time to read this wall of text,
Cheers,
Paul Groke

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistaedterstrasse 313