From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-19 07:53:56
Vladimir Prus wrote:
> > 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)
> > 2. alignment.diff
>I've some concerns.
>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
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
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
>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
>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
- 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 :).
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk