Re: [boost] [bind][tr1] patch for more compliant placeholders

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-05-10 11:16:39

On 5/10/07, Peter Dimov <pdimov_at_[hidden]> wrote:
> Daniel Walker wrote:
> > On 5/9/07, Peter Dimov <pdimov_at_[hidden]> wrote:
> >> Daniel Walker wrote:
> >>
> >>>>> I've attached a patch that leaves borland and g++ <= 4.0 as they
> >>>>> were. I also changed my little addition to the documentation to
> >>>>> reflect this. And one more thing, I couldn't find a macro
> >>>>> analogous to BOOST_MSVC for gcc's version number that I could use
> >>>>> with BOOST_WORKAROUND. I added one (BOOST_GCC) in
> >>>>> boost/config/compilers/gcc.hpp that does the same things as MPL's
> >>>>> gcc config file. Let me know if there's some other way this should
> >>>>> have been done.
> >>
> >> I'd like to understand the motivation behind
> >> BOOST_BIND_ENABLE_INLINE_PLACEHOLDERS.
> >
> > I'm not sure if I entirely understand it either. ;-)
> >
> > I was trying to figure out why the placeholders were implemented as
> > functions at all. Apparently, around version 1.5 of placeholders.h,
> > inline functions were introduced for all compilers based on a
> > suggestion from Yitzhak Sapir. I haven't gone back through the list
> > archives to see what was under discussion at that time, but I assumed
> > that an inline function implementation saved some overhead in the
> > .data sections of object files. Or perhaps there was some other
> > reasons that made defining the objects repeatedly in each compilation
> > unit unattractive.
>
> See
>
> http://lists.boost.org/Archives/boost/2002/03/26490.php
>
> and the associated thread. The specific 1.5 change is caused by Borland PCH
> problems. 1.6 has probably come right after one regression test cycle.
>
> placeholders.hpp has evolved into its current form since many compilers
> prefer one of the implementations and have problems with the others,
> especially when using precompiled headers.

OK, so this has always been related to PCH. In that case, if there's
no other use for the inline functions there's no reason to complicate
matters by allowing users to change the placeholder implementation
with a macro. Since the bulk of my patch is adding documentation for
that macro it doesn't really save you time. Could just qualify the gcc
preprocessor condition for gcc <= 4.0 by hand and commit it to CVS?

Daniel