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

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-05-09 21:02:00

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.

I'm not sure how big a deal this is. In TR1 the placeholders are
extern, so it's not an issue. But I don't think that extern would be a
good idea for boost bind. I figure if at one time it mattered to users
like Yitzhak, it may matter to others again and why not give them a
choice? But again, I don't fully understand why inline functions were
under consideration in the first place. There use as a workaround for
gcc's PCH seems to have come up years later.

>
> Other comments:
>
> BOOST_WORKAROUND(BOOST_GCC, <= 0x0400) is always true when the compiler
> isn't GCC since BOOST_GCC is not defined.

Oops! Good catch. Thanks!

>
> Depending on the BOOST_GCC macro means that bind.hpp will not work as
> intended with an empty config.hpp. It did once, and I've been careful to
> retain this feature... not that it's being tested, or that anyone I know
> takes advantage of it. :-)
>
> How about just using
>
> #if defined(__BORLANDC__) || defined(__GNUC__) && (__GNUC__ * 100 +
> __GNUC_MINOR__ <= 400)
>
> ?

I just like the idea of being able to search for BOOST_WORKAROUND and
find workaround specific code. I think it should be

#if defined(__BORLANDC__) || (defined(BOOST_GCC) &&
BOOST_WORKAROUND(BOOST_GCC, <= 0x0400))

Daniel