Re: [jamboost] Re: [BBv2] alignment feature and msvc assembler support

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-19 07:53:56

Vladimir Prus wrote:
>Hi Reece,
>
> > I have added this in the msvc-asm.diff patch as well as moving the
> > safe-asynch-exceptions feature to this patch. I also fixed a few things
> > like adding .ASM in init ( ... ).
> >
> > The dependancies are now:
> > 1. empty-optional.diff (from Alexey Pakhunov)
>
>Committed now.

Cool :).

> > 2. alignment.diff
>
>I've some concerns.

Go ahead...

>1. What are use cases for <alignment>? If that's for specific layout for
>specific structures, you've better off using pragmas, no? In that case,
>there's little point in feature.

In large projects, especially where you are serializing/deserializing data, 
having the correct alignment is *vital*. Granted, you could place pragmas 
around these data structures, but what about types not in your control (e.g. 
OS or standard structures) such as the point/rect structures provided by 
various OSs?

I am not sure of exact use cases, but what if you are using boost::serialize 
to save window position information that will be processed by different 
applications built with different compilers? Compilers offer the ability to 
locally control (through pragmas) and globally control (through the command 
line) the structure alignment. It is easy to say:

exe myapp : ... : <cxxflags>-align 8 ;

but this is (1) compiler specific (alignment is set with different switches 
depending on the toolset), and (2) you can't auto-inherit alignment if you 
say:

lib foo : ... : <cxxflags>/Zp2 ; # what does /Zp2 do again?
exe : bar : ... //foo ; # oops - alignment mismatch
exe : bar2 : ... //foo : <cxxflags>/Zp8 ; # oops - alignment mismatch

This is what the build system is for: provide a uniform mechanism for 
configuring a build and reducing common errors.

Or what about different alignment/performance issues between 32-bit and 
64-bit platforms? I do not have experience developing for 64-bit platforms, 
but there could be alignment issues here.

Likewise, if you want to send data from a Windows application (built with 
msvc) to a Linux application (built with gcc) using Boost.Serialization 
using data out of your control (such as the C or posix date/time 
structures), having explicit control over alignment can be one step to 
producing binary interoperability.

>2. Do you really ever want to build the same projects with several 
>alignments,
>and have several build directories, one for each alignment? Does not seem
>likely for me. And if not, the feature should be incidental.

Ok. The main point is consistency of alignment between applications that can 
potentially share binary data. What you are suggesting makes sense.

>3. If <safe-asynch-exceptions> is so specific to msvc, why adding a 
>feature.
>Won't <cxxflags>/safeseh work just as well?

Yes, but it should be <linkflags>/safeseh and <asmflags>/safeseh. You could 
specify one and miss the other. Also, I am not sure whether other Windows 
compilers support SEH/safeseh functionality (like mwcw with MS-compatible 
exceptions).

- That reminds me, the asm target should have an <asmflags> feature :).

>4. Note the "link-incompatible" attribute of feature is not tested, never
>worked nice, and probably does not work at all now. I suggest avoiding it,
>and will remove it from the docs soon.

Noted: I will remove it in my next patch :).

> > 3. msvc-asm.diff
>
>Is ia64 variable used anywhere?

Not yet (nor is the amd64 variable). I added those so that the 
i386/ia64/amd64 "shortcuts" could be added as one (they should really be a 
separate patch). This should help when Alexey adds the ia64/amd64 support 
patch for msvc-8.0 :).

- Reece